[alsa-devel] [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
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 benzh@chromium.org --- sound/soc/codecs/rt5677.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 5d317c68..384281d 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -20,6 +20,7 @@ #include <linux/i2c.h> #include <linux/platform_device.h> #include <linux/spi/spi.h> +#include <linux/acpi.h> #include <linux/firmware.h> #include <linux/gpio.h> #include <sound/core.h> @@ -4525,6 +4526,43 @@ static int rt5677_parse_dt(struct rt5677_priv *rt5677, struct device_node *np) return 0; }
+#ifdef CONFIG_ACPI + +static unsigned long long rt5677_parse_acpi_entry(struct device *dev, + acpi_string name) +{ + acpi_handle handle = ACPI_HANDLE(dev); + unsigned long long val; + acpi_status status; + + status = acpi_evaluate_integer(handle, name, NULL, &val); + if (ACPI_FAILURE(status)) { + dev_err(dev, "Failed to parse ACPI entry %s, default to 0: %d\n", + name, status); + return 0; + } + return val; +} + +static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev) +{ + rt5677->pdata.dmic2_clk_pin = (enum rt5677_dmic2_clk) + rt5677_parse_acpi_entry(dev, "DCLK"); + rt5677->pdata.in1_diff = (bool)rt5677_parse_acpi_entry(dev, "IN1"); + rt5677->pdata.in2_diff = (bool)rt5677_parse_acpi_entry(dev, "IN2"); + rt5677->pdata.lout1_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT1"); + rt5677->pdata.lout2_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT2"); + rt5677->pdata.lout3_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT3"); + rt5677->pdata.jd1_gpio = rt5677_parse_acpi_entry(dev, "JD1"); + rt5677->pdata.jd2_gpio = rt5677_parse_acpi_entry(dev, "JD2"); + rt5677->pdata.jd3_gpio = rt5677_parse_acpi_entry(dev, "JD3"); +} +#else +static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev) +{ +} +#endif + static struct regmap_irq rt5677_irqs[] = { [RT5677_IRQ_JD1] = { .reg_offset = 0, @@ -4604,6 +4642,7 @@ static int rt5677_i2c_probe(struct i2c_client *i2c, if (pdata) rt5677->pdata = *pdata;
+ rt5677->pow_ldo2 = -EINVAL; if (i2c->dev.of_node) { ret = rt5677_parse_dt(rt5677, i2c->dev.of_node); if (ret) { @@ -4611,8 +4650,8 @@ static int rt5677_i2c_probe(struct i2c_client *i2c, ret); return ret; } - } else { - rt5677->pow_ldo2 = -EINVAL; + } else if (ACPI_HANDLE(&i2c->dev)) { + rt5677_parse_acpi(rt5677, &i2c->dev); }
if (gpio_is_valid(rt5677->pow_ldo2)) { @@ -4708,10 +4747,19 @@ static int rt5677_i2c_remove(struct i2c_client *i2c) return 0; }
+#ifdef CONFIG_ACPI +static const struct acpi_device_id rt5677_acpi_id[] = { + { "RT5677CE", 0 }, + { } +}; +MODULE_DEVICE_TABLE(acpi, rt5677_acpi_id); +#endif + static struct i2c_driver rt5677_i2c_driver = { .driver = { .name = "rt5677", .owner = THIS_MODULE, + .acpi_match_table = ACPI_PTR(rt5677_acpi_id), }, .probe = rt5677_i2c_probe, .remove = rt5677_i2c_remove,
The PDM output clock can use a divider of 1/2/3/4 based on the system clock
Signed-off-by: Ben Zhang benzh@chromium.org --- Documentation/devicetree/bindings/sound/rt5677.txt | 5 +++++ include/sound/rt5677.h | 8 ++++++++ sound/soc/codecs/rt5677.c | 7 +++++++ 3 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/rt5677.txt b/Documentation/devicetree/bindings/sound/rt5677.txt index 740ff77..141f3e1 100644 --- a/Documentation/devicetree/bindings/sound/rt5677.txt +++ b/Documentation/devicetree/bindings/sound/rt5677.txt @@ -27,6 +27,10 @@ Optional properties: Boolean. Indicate MIC1/2 input and LOUT1/2/3 outputs are differential, rather than single-ended.
+- realtek,pdm_clk_div + Select 0/1/2/3 as PDM clock divider 1/2/4/3 respectively. + PDM clock = system clock / PDM clock divider + - realtek,gpio-config Array of six 8bit elements that configures GPIO. 0 - floating (reset value) @@ -71,6 +75,7 @@ rt5677 { realtek,pow-ldo2-gpio = <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>; realtek,in1-differential = "true"; + realtek,pdm_clk_div = <1> /* PDM clock = system clock / 2 */ realtek,gpio-config = /bits/ 8 <0 0 0 0 0 2>; /* pull up GPIO6 */ realtek,jd2-gpio = <3>; /* Enables Jack detection for GPIO6 */ }; diff --git a/include/sound/rt5677.h b/include/sound/rt5677.h index d9eb7d8..368aa33 100644 --- a/include/sound/rt5677.h +++ b/include/sound/rt5677.h @@ -17,6 +17,12 @@ enum rt5677_dmic2_clk { RT5677_DMIC_CLK2 = 1, };
+enum rt5677_pdm_clk_div { + RT5677_PDM_CLK_DIV1 = 0, + RT5677_PDM_CLK_DIV2 = 1, + RT5677_PDM_CLK_DIV4 = 2, + RT5677_PDM_CLK_DIV3 = 3, +};
struct rt5677_platform_data { /* IN1/IN2/LOUT1/LOUT2/LOUT3 can optionally be differential */ @@ -27,6 +33,8 @@ struct rt5677_platform_data { bool lout3_diff; /* DMIC2 clock source selection */ enum rt5677_dmic2_clk dmic2_clk_pin; + /* System clock to PDM filter divider */ + enum rt5677_pdm_clk_div pdm_clk_div;
/* configures GPIO, 0 - floating, 1 - pulldown, 2 - pullup */ u8 gpio_config[6]; diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 384281d..383cb61 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -4502,6 +4502,8 @@ static int rt5677_parse_dt(struct rt5677_priv *rt5677, struct device_node *np) "realtek,lout2-differential"); rt5677->pdata.lout3_diff = of_property_read_bool(np, "realtek,lout3-differential"); + of_property_read_u32(np, "realtek,pdm_clk_div", + &rt5677->pdata.pdm_clk_div);
rt5677->pow_ldo2 = of_get_named_gpio(np, "realtek,pow-ldo2-gpio", 0); @@ -4548,6 +4550,8 @@ static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev) { rt5677->pdata.dmic2_clk_pin = (enum rt5677_dmic2_clk) rt5677_parse_acpi_entry(dev, "DCLK"); + rt5677->pdata.pdm_clk_div = (enum rt5677_pdm_clk_div) + rt5677_parse_acpi_entry(dev, "PCLK"); rt5677->pdata.in1_diff = (bool)rt5677_parse_acpi_entry(dev, "IN1"); rt5677->pdata.in2_diff = (bool)rt5677_parse_acpi_entry(dev, "IN2"); rt5677->pdata.lout1_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT1"); @@ -4730,6 +4734,9 @@ static int rt5677_i2c_probe(struct i2c_client *i2c, RT5677_GPIO5_DIR_OUT); }
+ regmap_update_bits(rt5677->regmap, RT5677_PDM_DATA_CTRL1, + RT5677_PDM_DIV_MASK, rt5677->pdata.pdm_clk_div); + rt5677_init_gpio(i2c); rt5677_irq_init(i2c);
On Fri, Nov 14, 2014 at 10:56:47PM -0800, 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
This actually does two things - it adds the ACPI device probing and it adds the ACPI platform data. That last bit is a bit fun, I've added several of the people working on ACPI here since this is another variant on the whole ACPI platform data thing which probably needs addressing in the best practice dissemination which ought to be going on now.
+static unsigned long long rt5677_parse_acpi_entry(struct device *dev,
acpi_string name)+{
- acpi_handle handle = ACPI_HANDLE(dev);
- unsigned long long val;
- acpi_status status;
- status = acpi_evaluate_integer(handle, name, NULL, &val);
- if (ACPI_FAILURE(status)) {
So, here were defining what's essentially an ACPI property read API which uses something other than _DSD which is the way all the ACPI platform data specification for devices is apparently supposed to be going in order to reuse work between DT and ACPI.
+static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev) +{
- rt5677->pdata.dmic2_clk_pin = (enum rt5677_dmic2_clk)
rt5677_parse_acpi_entry(dev, "DCLK");- rt5677->pdata.in1_diff = (bool)rt5677_parse_acpi_entry(dev, "IN1");
- rt5677->pdata.in2_diff = (bool)rt5677_parse_acpi_entry(dev, "IN2");
- rt5677->pdata.lout1_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT1");
- rt5677->pdata.lout2_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT2");
- rt5677->pdata.lout3_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT3");
- rt5677->pdata.jd1_gpio = rt5677_parse_acpi_entry(dev, "JD1");
- rt5677->pdata.jd2_gpio = rt5677_parse_acpi_entry(dev, "JD2");
- rt5677->pdata.jd3_gpio = rt5677_parse_acpi_entry(dev, "JD3");
Here we read a bunch of properties named with a most definitely non-DT idiom. The names here don't look great in general, in particular all the properties for differential outputs are just boolean flags for the output name which I'd expect to be flags saying if the output is in use or not rather than saying if it's in differential mode or single ended mode. Things like foo_DIFF would seem better.
My understanding is that best practice for ACPI is to use the new device_property_read_ APIs which idiomatically take DT style property names. However if there's BIOSs out there we need to support perhaps we just have to deal with this but judging from your e-mail address it seems this may be for a system intended to run Linux natively so perhaps that's not an issue.
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang benzh@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 benzh@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-UUI...
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.
g.
sound/soc/codecs/rt5677.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 5d317c68..384281d 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -20,6 +20,7 @@ #include <linux/i2c.h> #include <linux/platform_device.h> #include <linux/spi/spi.h> +#include <linux/acpi.h> #include <linux/firmware.h> #include <linux/gpio.h> #include <sound/core.h> @@ -4525,6 +4526,43 @@ static int rt5677_parse_dt(struct rt5677_priv *rt5677, struct device_node *np) return 0; }
+#ifdef CONFIG_ACPI
+static unsigned long long rt5677_parse_acpi_entry(struct device *dev,
acpi_string name)+{
acpi_handle handle = ACPI_HANDLE(dev);unsigned long long val;acpi_status status;status = acpi_evaluate_integer(handle, name, NULL, &val);if (ACPI_FAILURE(status)) {dev_err(dev, "Failed to parse ACPI entry %s, default to 0: %d\n",name, status);return 0;}return val;+}
+static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev) +{
rt5677->pdata.dmic2_clk_pin = (enum rt5677_dmic2_clk)rt5677_parse_acpi_entry(dev, "DCLK");rt5677->pdata.in1_diff = (bool)rt5677_parse_acpi_entry(dev, "IN1");rt5677->pdata.in2_diff = (bool)rt5677_parse_acpi_entry(dev, "IN2");rt5677->pdata.lout1_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT1");rt5677->pdata.lout2_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT2");rt5677->pdata.lout3_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT3");rt5677->pdata.jd1_gpio = rt5677_parse_acpi_entry(dev, "JD1");rt5677->pdata.jd2_gpio = rt5677_parse_acpi_entry(dev, "JD2");rt5677->pdata.jd3_gpio = rt5677_parse_acpi_entry(dev, "JD3");+} +#else +static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev) +{ +} +#endif
static struct regmap_irq rt5677_irqs[] = { [RT5677_IRQ_JD1] = { .reg_offset = 0, @@ -4604,6 +4642,7 @@ static int rt5677_i2c_probe(struct i2c_client *i2c, if (pdata) rt5677->pdata = *pdata;
rt5677->pow_ldo2 = -EINVAL; if (i2c->dev.of_node) { ret = rt5677_parse_dt(rt5677, i2c->dev.of_node); if (ret) {@@ -4611,8 +4650,8 @@ static int rt5677_i2c_probe(struct i2c_client *i2c, ret); return ret; }
} else {rt5677->pow_ldo2 = -EINVAL;
} else if (ACPI_HANDLE(&i2c->dev)) {rt5677_parse_acpi(rt5677, &i2c->dev); } if (gpio_is_valid(rt5677->pow_ldo2)) {@@ -4708,10 +4747,19 @@ static int rt5677_i2c_remove(struct i2c_client *i2c) return 0; }
+#ifdef CONFIG_ACPI +static const struct acpi_device_id rt5677_acpi_id[] = {
{ "RT5677CE", 0 },{ }+}; +MODULE_DEVICE_TABLE(acpi, rt5677_acpi_id); +#endif
static struct i2c_driver rt5677_i2c_driver = { .driver = { .name = "rt5677", .owner = THIS_MODULE,
.acpi_match_table = ACPI_PTR(rt5677_acpi_id), }, .probe = rt5677_i2c_probe, .remove = rt5677_i2c_remove,-- 2.1.0.rc2.206.gedb03e5
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tue, 2014-11-25 at 12:11 +0000, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang benzh@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 benzh@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-UUI...
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
On 11/25/14 06:28, Liam Girdwood wrote:
On Tue, 2014-11-25 at 12:11 +0000, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang benzh@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 benzh@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-UUI...
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?
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 +0000, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang benzh@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 benzh@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-UUI...
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
On 11/25/14 04:11, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang benzh@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 benzh@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-UUI...
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.
Right. The ACPI/UEFI forum is managing the creation of new DSD bindings and ensuring they are documented online. I believe this is the... 3rd so far? So we're still optimizing the process. But yes, please, send the schema itself for review and let's get this documented and migrated over to _DSD.
On Tue, Nov 25, 2014 at 08:00:12AM -0800, Darren Hart wrote:
On 11/25/14 04:11, Grant Likely wrote:
Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom.
Right. The ACPI/UEFI forum is managing the creation of new DSD bindings and ensuring they are documented online. I believe this is the... 3rd so far? So we're still optimizing the process. But yes, please, send the schema itself for review and let's get this documented and migrated over to _DSD.
To be clear the main reason I'm querying this is that it doesn't appear to be a _DSD based binding at all (as far as I understand it, the API it's using is from before the dawn of time or at least the dawn of git).
Given the design of _DSD is to share with DT and we already have device tree bindings for the device we should be using, it's not clear to me if we want to grind them all through UEFI and I suspect they'd be unhappy if we tried but pretty much all audio CODECs are good candidates for use with ACPI given the new hardware designs Intel have so if we are doing it I ought to be bouncing everyone to UEFI forum.
On 11/25/14 09:21, Mark Brown wrote:
On Tue, Nov 25, 2014 at 08:00:12AM -0800, Darren Hart wrote:
On 11/25/14 04:11, Grant Likely wrote:
Also, since this patch is targeted at v3.19 or later, the device-properties API should be used. Don't create something custom.
Right. The ACPI/UEFI forum is managing the creation of new DSD bindings and ensuring they are documented online. I believe this is the... 3rd so far? So we're still optimizing the process. But yes, please, send the schema itself for review and let's get this documented and migrated over to _DSD.
To be clear the main reason I'm querying this is that it doesn't appear to be a _DSD based binding at all (as far as I understand it, the API it's using is from before the dawn of time or at least the dawn of git).
Given the design of _DSD is to share with DT and we already have device tree bindings for the device we should be using, it's not clear to me if we want to grind them all through UEFI and I suspect they'd be unhappy if we tried but pretty much all audio CODECs are good candidates for use with ACPI given the new hardware designs Intel have so if we are doing it I ought to be bouncing everyone to UEFI forum.
Right, I realized between sending and driving into the office that my statement might be construed this way. I meant *new* _DSD bindings should go through the ACPI/UEFI forum. Where we can reuse DT bindings, we should absolutely do that, agreed. We should still document this and link to the DT binding so it can be referenced and used even when Linux is not the target OS.
On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
On 11/25/14 09:21, Mark Brown wrote:
Given the design of _DSD is to share with DT and we already have device tree bindings for the device we should be using, it's not clear to me if we want to grind them all through UEFI and I suspect they'd be unhappy if we tried but pretty much all audio CODECs are good candidates for use with ACPI given the new hardware designs Intel have so if we are doing it I ought to be bouncing everyone to UEFI forum.
Right, I realized between sending and driving into the office that my statement might be construed this way. I meant *new* _DSD bindings should go through the ACPI/UEFI forum. Where we can reuse DT bindings, we should absolutely do that, agreed. We should still document this and link to the DT binding so it can be referenced and used even when Linux is not the target OS.
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
On 11/25/14 10:43, Mark Brown wrote:
On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
On 11/25/14 09:21, Mark Brown wrote:
Given the design of _DSD is to share with DT and we already have device tree bindings for the device we should be using, it's not clear to me if we want to grind them all through UEFI and I suspect they'd be unhappy if we tried but pretty much all audio CODECs are good candidates for use with ACPI given the new hardware designs Intel have so if we are doing it I ought to be bouncing everyone to UEFI forum.
Right, I realized between sending and driving into the office that my statement might be construed this way. I meant *new* _DSD bindings should go through the ACPI/UEFI forum. Where we can reuse DT bindings, we should absolutely do that, agreed. We should still document this and link to the DT binding so it can be referenced and used even when Linux is not the target OS.
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
I don't know if we want to have a list of them here, or if a separate document is needed. The important point is that it is independent from the ACPI specification itself so that it can be updated out of band with the specification, and not be subject to rather plodding pace that would imply.
Rafael, I've missed several of these meetings unfortunately, and I'm not sure if we've closed on this point. Do you know?
On Tue, Nov 25, 2014 at 11:07:06AM -0800, Darren Hart wrote:
On 11/25/14 10:43, Mark Brown wrote:
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
I don't know if we want to have a list of them here, or if a separate document is needed. The important point is that it is independent from
Seems to me like some indirection is going to be better rather than having one big document if there's widespread adoption, avoids lots of document churn.
the ACPI specification itself so that it can be updated out of band with the specification, and not be subject to rather plodding pace that would imply.
Rafael, I've missed several of these meetings unfortunately, and I'm not sure if we've closed on this point. Do you know?
OK, I'll see if any of the people at work have been following as well. For now continuing to just document everything as DT bindings in the way we are already seems like a sensible interim approach.
On Tuesday, November 25, 2014 07:36:23 PM Mark Brown wrote:
--njUEgrJvs9ryr/H/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
On Tue, Nov 25, 2014 at 11:07:06AM -0800, Darren Hart wrote:
On 11/25/14 10:43, Mark Brown wrote:
Link from where - do we want to talk to the ACPI/UEFI forum and=20 figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for=20 example? We also ought to work out how to make sure ACPI IDs are=20 registered there as well, should be possible to have something=20 simple as part of that.
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-=
UUID.pdf
I don't know if we want to have a list of them here, or if a separate document is needed. The important point is that it is independent from
Seems to me like some indirection is going to be better rather than having one big document if there's widespread adoption, avoids lots of document churn.
the ACPI specification itself so that it can be updated out of band with the specification, and not be subject to rather plodding pace that would imply.
Rafael, I've missed several of these meetings unfortunately, and I'm not sure if we've closed on this point. Do you know?
OK, I'll see if any of the people at work have been following as well. For now continuing to just document everything as DT bindings in the way we are already seems like a sensible interim approach.
Yes, that currently is the case in my view too.
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
On 11/25/14 10:43, Mark Brown wrote:
On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
On 11/25/14 09:21, Mark Brown wrote:
Given the design of _DSD is to share with DT and we already have device tree bindings for the device we should be using, it's not clear to me if we want to grind them all through UEFI and I suspect they'd be unhappy if we tried but pretty much all audio CODECs are good candidates for use with ACPI given the new hardware designs Intel have so if we are doing it I ought to be bouncing everyone to UEFI forum.
Right, I realized between sending and driving into the office that my statement might be construed this way. I meant *new* _DSD bindings should go through the ACPI/UEFI forum. Where we can reuse DT bindings, we should absolutely do that, agreed. We should still document this and link to the DT binding so it can be referenced and used even when Linux is not the target OS.
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
I don't know if we want to have a list of them here, or if a separate document is needed. The important point is that it is independent from the ACPI specification itself so that it can be updated out of band with the specification, and not be subject to rather plodding pace that would imply.
Rafael, I've missed several of these meetings unfortunately, and I'm not sure if we've closed on this point. Do you know?
This hasn't been discussed a lot at the meetings I attended.
The bindings management process is being set up within the UEFI Forum, but I'm not sure if/how the existing DT bindings documented in the kernel tree are going to be covered by it ATM.
On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
This hasn't been discussed a lot at the meetings I attended.
The bindings management process is being set up within the UEFI Forum, but I'm not sure if/how the existing DT bindings documented in the kernel tree are going to be covered by it ATM.
Al Stone (CCed) pointed me at the following two documents:
http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
(the first one being the actual process in so far as it exists). The process appears to be to mail requests in a specific format to the ASWG chairperson (the address is apparently supposed to be awsg@uefi.org). It looks like all the properties are expected to end up in one or more PDF files like the second one.
My initial thought would be to require that we send any DT properties defined for devices with ACPI identifiers registered there and hope the volume doesn't DoS them.
A more defined format for DT documentation that we can script into the ASWG format (or vice versa) might be helpful here, and we should add notes to the DT documentation if this is how we want to proceed.
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
--ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
This hasn't been discussed a lot at the meetings I attended.
The bindings management process is being set up within the UEFI Forum, but I'm not sure if/how the existing DT bindings documented in the kernel tree are going to be covered by it ATM.
Al Stone (CCed) pointed me at the following two documents:
http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
(the first one being the actual process in so far as it exists). The process appears to be to mail requests in a specific format to the ASWG chairperson (the address is apparently supposed to be awsg@uefi.org). It looks like all the properties are expected to end up in one or more PDF files like the second one.
My initial thought would be to require that we send any DT properties defined for devices with ACPI identifiers registered there and hope the volume doesn't DoS them.
We absolutely need to start registering the existing bindings in there, but that needs to be rate limited somehow, because the process may not be very efficient to start with.
A more defined format for DT documentation that we can script into the ASWG format (or vice versa) might be helpful here, and we should add notes to the DT documentation if this is how we want to proceed.
That's a good point.
Unfortunately, the timing is pretty bad (Thanksgiving) and the closest ASWG meeting is next Thursday, but that one's likely to be busy for other reasons. I presume, then, that the earliest we can seriously get back to that in the ASWG is mid-December.
On Tue, Nov 25, 2014 at 10:40:53PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
My initial thought would be to require that we send any DT properties defined for devices with ACPI identifiers registered there and hope the volume doesn't DoS them.
We absolutely need to start registering the existing bindings in there, but that needs to be rate limited somehow, because the process may not be very efficient to start with.
Well, my upstream connection is 20Mbit or something, that's a limit :P
More seriously there's not that many devices and not much use of the properties API yet so no concrete users; it's three audio CODECs that I'm aware of which should use it and are in tree now so probably actually a reasonable thing to throw out there for people to have a look at. Liam, do you think some of the Intel audio people could look into the code side? I'm tempted to send at least one document myself for pipe cleaning purposes.
A more defined format for DT documentation that we can script into the ASWG format (or vice versa) might be helpful here, and we should add notes to the DT documentation if this is how we want to proceed.
That's a good point.
Unfortunately, the timing is pretty bad (Thanksgiving) and the closest ASWG meeting is next Thursday, but that one's likely to be busy for other reasons. I presume, then, that the earliest we can seriously get back to that in the ASWG is mid-December.
OK, not the most pressing matter I guess.
+Duncan who works on our firmware project.
Please correct me if I'm wrong. Here is the summary of what I understand. Looks like the recommended practice for passing device platform data is using _DSD and the new device_property_read_ API from include/linux/property.h
For example, the firmware (coreboot) should specify something like: Device (CODC) { Name (_HID, "RT5677CE") ... Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package (2) {"realtek,in1-differential", 1}, Package (2) {"realtek,in2-differential", 0}, Package (2) {"realtek,gpio-config", Package (6) { 0, 0, 0, 0, 0, 2 }}, ... } }) ... }
And the kernel driver should query with something like: static void rt5677_read_platform_data(struct rt5677_priv *rt5677, struct device *dev) { u8 val;
device_property_read_u8_array(dev, "realtek,in1-differential", &val, 1); rt5677->pdata.in1_diff = (bool)val; device_property_read_u8_array(dev, "realtek,in2-differential", &val, 1); rt5677->pdata.in2_diff = (bool)val;
device_property_read_u8_array(dev, "realtek,gpio-config", rt5677->pdata.gpio_config, RT5677_GPIO_NUM); ... } And the device property API should work for both DT and ACPI.
Also these device property name keys should be registered with the ACPI working group following http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf
On Tue, Nov 25, 2014 at 1:40 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
--ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
This hasn't been discussed a lot at the meetings I attended.
The bindings management process is being set up within the UEFI Forum, but I'm not sure if/how the existing DT bindings documented in the kernel tree are going to be covered by it ATM.
Al Stone (CCed) pointed me at the following two documents:
http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
(the first one being the actual process in so far as it exists). The process appears to be to mail requests in a specific format to the ASWG chairperson (the address is apparently supposed to be awsg@uefi.org). It looks like all the properties are expected to end up in one or more PDF files like the second one.
My initial thought would be to require that we send any DT properties defined for devices with ACPI identifiers registered there and hope the volume doesn't DoS them.
We absolutely need to start registering the existing bindings in there, but that needs to be rate limited somehow, because the process may not be very efficient to start with.
A more defined format for DT documentation that we can script into the ASWG format (or vice versa) might be helpful here, and we should add notes to the DT documentation if this is how we want to proceed.
That's a good point.
Unfortunately, the timing is pretty bad (Thanksgiving) and the closest ASWG meeting is next Thursday, but that one's likely to be busy for other reasons. I presume, then, that the earliest we can seriously get back to that in the ASWG is mid-December.
-- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
On Tue, Nov 25, 2014 at 02:41:28PM -0800, Ben Zhang wrote:
+Duncan who works on our firmware project.
Please correct me if I'm wrong. Here is the summary of what I understand. Looks like the recommended practice for passing device platform data is using _DSD and the new device_property_read_ API from include/linux/property.h
Your understanding matches mine here. Doesn't mean I'm not confused though!
On Tue, 25 Nov 2014 22:40:53 +0100 , "Rafael J. Wysocki" rjw@rjwysocki.net wrote:
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
--ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
This hasn't been discussed a lot at the meetings I attended.
The bindings management process is being set up within the UEFI Forum, but I'm not sure if/how the existing DT bindings documented in the kernel tree are going to be covered by it ATM.
Al Stone (CCed) pointed me at the following two documents:
http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
(the first one being the actual process in so far as it exists). The process appears to be to mail requests in a specific format to the ASWG chairperson (the address is apparently supposed to be awsg@uefi.org). It looks like all the properties are expected to end up in one or more PDF files like the second one.
My initial thought would be to require that we send any DT properties defined for devices with ACPI identifiers registered there and hope the volume doesn't DoS them.
We absolutely need to start registering the existing bindings in there, but that needs to be rate limited somehow, because the process may not be very efficient to start with.
Beyond having the document point to the existing DT binding documentation, I think this is a non-starter. It won't be helpful for anyone to have two separate repositories containing the same bindings. They will get out of sync and we will have pain as a result.
For existing bindings we need to have a way to share the documentation, and I don't think we can even talk about whether it makes sense to migrate the documetation to the UEFI managed repo before the UEFI process is fully flushed out.
g.
On Thu, Dec 04, 2014 at 10:48:19AM +0000, Grant Likely wrote:
On Tue, 25 Nov 2014 22:40:53 +0100
We absolutely need to start registering the existing bindings in there, but that needs to be rate limited somehow, because the process may not be very efficient to start with.
Beyond having the document point to the existing DT binding documentation, I think this is a non-starter. It won't be helpful for anyone to have two separate repositories containing the same bindings. They will get out of sync and we will have pain as a result.
Right, I think we have to pick one and reference it from the other. Having the one place be inside the Linux kernel doesn't seem super awesome.
For existing bindings we need to have a way to share the documentation, and I don't think we can even talk about whether it makes sense to migrate the documetation to the UEFI managed repo before the UEFI process is fully flushed out.
We definitely don't want to start dumping everything in immediately but but starting the conversation to both provide urgency and requirements and and be engaged in the process seems sensible. Let's try to take advantage of the recent changes in UEFI governance to help shape the firmware interfaces we'll be working with.
On Thursday, December 04, 2014 10:48:19 AM Grant Likely wrote:
On Tue, 25 Nov 2014 22:40:53 +0100 , "Rafael J. Wysocki" rjw@rjwysocki.net wrote:
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
--ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
This is a current topic with the ACPI working group. We have the following document:
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUI...
This hasn't been discussed a lot at the meetings I attended.
The bindings management process is being set up within the UEFI Forum, but I'm not sure if/how the existing DT bindings documented in the kernel tree are going to be covered by it ATM.
Al Stone (CCed) pointed me at the following two documents:
http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
(the first one being the actual process in so far as it exists). The process appears to be to mail requests in a specific format to the ASWG chairperson (the address is apparently supposed to be awsg@uefi.org). It looks like all the properties are expected to end up in one or more PDF files like the second one.
My initial thought would be to require that we send any DT properties defined for devices with ACPI identifiers registered there and hope the volume doesn't DoS them.
We absolutely need to start registering the existing bindings in there, but that needs to be rate limited somehow, because the process may not be very efficient to start with.
Beyond having the document point to the existing DT binding documentation, I think this is a non-starter. It won't be helpful for anyone to have two separate repositories containing the same bindings.
If they *are* the same, it won't. But at least in some cases (eg. GPIO) they won't be the same.
Also we need a way to say "this binding has been documented elsewhere, see XYZ and this is how to translate the format" in the UEFI documentation for the existing bindings that will be the same.
They will get out of sync and we will have pain as a result.
For existing bindings we need to have a way to share the documentation, and I don't think we can even talk about whether it makes sense to migrate the documetation to the UEFI managed repo before the UEFI process is fully flushed out.
Agreed.
On 11/25/14 10:43, Mark Brown wrote:
On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
On 11/25/14 09:21, Mark Brown wrote:
Given the design of _DSD is to share with DT and we already have device tree bindings for the device we should be using, it's not clear to me if we want to grind them all through UEFI and I suspect they'd be unhappy if we tried but pretty much all audio CODECs are good candidates for use with ACPI given the new hardware designs Intel have so if we are doing it I ought to be bouncing everyone to UEFI forum.
Right, I realized between sending and driving into the office that my statement might be construed this way. I meant *new* _DSD bindings should go through the ACPI/UEFI forum. Where we can reuse DT bindings, we should absolutely do that, agreed. We should still document this and link to the DT binding so it can be referenced and used even when Linux is not the target OS.
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
As to registering ACPI IDs, I believe this is the right link: http://www.uefi.org/PNP_ACPI_Registry
Or did you mean a HID/CID<->DSD mapping?
On Tue, Nov 25, 2014 at 05:48:24PM -0800, Darren Hart wrote:
On 11/25/14 10:43, Mark Brown wrote:
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
As to registering ACPI IDs, I believe this is the right link: http://www.uefi.org/PNP_ACPI_Registry
No, those are vendors as far as I can tell. I mean identifiers for specific devices - it appears to be common for for example Intel to allocate identifiers for devices they don't produce, I'd expect there to be some effort to keep track of that especially given that _DSD properties may well end up being specific to the identifier used to register in cases of parallel evolution.
Or did you mean a HID/CID<->DSD mapping?
I don't really know what that is, sorry.
On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
--4mL5lf+nIvB09VHj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Tue, Nov 25, 2014 at 05:48:24PM -0800, Darren Hart wrote:
On 11/25/14 10:43, Mark Brown wrote:
Link from where - do we want to talk to the ACPI/UEFI forum and figure out some kind of fast track process for them to add an "it's already covered by DT, see here" entry to their database for example? We also ought to work out how to make sure ACPI IDs are registered there as well, should be possible to have something simple as part of that.
As to registering ACPI IDs, I believe this is the right link: http://www.uefi.org/PNP_ACPI_Registry
No, those are vendors as far as I can tell. I mean identifiers for specific devices - it appears to be common for for example Intel to allocate identifiers for devices they don't produce, I'd expect there to be some effort to keep track of that especially given that _DSD properties may well end up being specific to the identifier used to register in cases of parallel evolution.
The vendor (or more precisely the owner of the initial 3 or 4 letter code) is supposed to do that. I'm not aware of any common registry of those IDs for all vendors.
Or did you mean a HID/CID<->DSD mapping?
I don't really know what that is, sorry.
The device ID is supposed to determine the way all of the ACPI objects for that device will work, including what is returned by _DSD. Pretty much in analogy with PCI device IDs.
On Thu, Nov 27, 2014 at 12:09:55AM +0100, Rafael J. Wysocki wrote:
On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
As to registering ACPI IDs, I believe this is the right link: http://www.uefi.org/PNP_ACPI_Registry
No, those are vendors as far as I can tell. I mean identifiers for specific devices - it appears to be common for for example Intel to allocate identifiers for devices they don't produce, I'd expect there to be some effort to keep track of that especially given that _DSD properties may well end up being specific to the identifier used to register in cases of parallel evolution.
The vendor (or more precisely the owner of the initial 3 or 4 letter code) is supposed to do that. I'm not aware of any common registry of those IDs for all vendors.
OK, we probably should have one to aid discoverability since as far as I can tell what's happening is that people (hi Intel!) are allocating their own identifiers for devices produced by other vendors that turn up on their boards. If people can find the set of IDs in use there's more chance they'll use the same ones as other people.
Or did you mean a HID/CID<->DSD mapping?
I don't really know what that is, sorry.
The device ID is supposed to determine the way all of the ACPI objects for that device will work, including what is returned by _DSD. Pretty much in analogy with PCI device IDs.
So the HID and CID are device IDs then? Please bear in mind that we're not all familiar with the acronym soup that tends to go along with ACPI!
If those are device IDs then what you're saying is what I'd expect to happen and it's part of the reason I'd expect us to be registering IDs along with registering properties - if people are defining device specific properties they really ought to be tied to the IDs that are in use especially if (as seems likely to be the case with the current state of the world) people are doing things without attempting to coordinate and we're ending up trying to document the deployed reality.
On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
--k9ssVBY1NpawPNl1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Thu, Nov 27, 2014 at 12:09:55AM +0100, Rafael J. Wysocki wrote:
On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
As to registering ACPI IDs, I believe this is the right link: http://www.uefi.org/PNP_ACPI_Registry
No, those are vendors as far as I can tell. I mean identifiers for specific devices - it appears to be common for for example Intel to allocate identifiers for devices they don't produce, I'd expect there to be some effort to keep track of that especially given that _DSD properties may well end up being specific to the identifier used to register in cases of parallel evolution.
The vendor (or more precisely the owner of the initial 3 or 4 letter code) is supposed to do that. I'm not aware of any common registry of those IDs for all vendors.
OK, we probably should have one to aid discoverability since as far as I can tell what's happening is that people (hi Intel!) are allocating their own identifiers for devices produced by other vendors that turn up on their boards. If people can find the set of IDs in use there's more chance they'll use the same ones as other people.
There's the PRP0001 ID that can be use to in combination with the "compatible" property which then works the same way as for DT.
That should be sufficient if the properties are going to be the same for ACPI (_DSD) and DT.
Or did you mean a HID/CID<->DSD mapping?
I don't really know what that is, sorry.
The device ID is supposed to determine the way all of the ACPI objects for that device will work, including what is returned by _DSD. Pretty much in analogy with PCI device IDs.
So the HID and CID are device IDs then? Please bear in mind that we're not all familiar with the acronym soup that tends to go along with ACPI!
Yes, they are supposed to be treated this way.
If those are device IDs then what you're saying is what I'd expect to happen and it's part of the reason I'd expect us to be registering IDs along with registering properties - if people are defining device specific properties they really ought to be tied to the IDs that are in use especially if (as seems likely to be the case with the current state of the world) people are doing things without attempting to coordinate and we're ending up trying to document the deployed reality.
The rule of thumb (in my view) should be that if the device object's _DSD is going to return the same set of properties as for DT and no other special handling determined by the ID is required (ie. nothing along the lines of "if the device ID is X, the _ABC method works like that" which has to be known by the driver), "PRP0001" should be returned by _HID and then the value of the "compatible" property should be the same as for DT.
In other words, "PRP0001" means "a generic device with properties as returned by _DSD".
Otherwise, a new device ID needs to be allocated for the device and _HID should return that ID. Also, if the device is compatible with another device with an already allocated ID (for _HID), _CID may return the device ID of the compatible device. [Of course, it's better if _HID is the same for identical devices.]
On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
OK, we probably should have one to aid discoverability since as far as I can tell what's happening is that people (hi Intel!) are allocating their own identifiers for devices produced by other vendors that turn up on their boards. If people can find the set of IDs in use there's more chance they'll use the same ones as other people.
There's the PRP0001 ID that can be use to in combination with the "compatible" property which then works the same way as for DT.
That should be sufficient if the properties are going to be the same for ACPI (_DSD) and DT.
We've got people making BIOSs right now for systems you can actually buy that are intended to run Windows which we need to support; right now the pressing problem I'm seeing is that we've got BIOS vendors not using properties at all and we're going to be ending up with configuration coming from big DMI tables instead which is miserable, Windows is perfectly happy to have custom drivers installed per machine. Do we know if Windows supports PRP0001 as it currently stands?
If those are device IDs then what you're saying is what I'd expect to happen and it's part of the reason I'd expect us to be registering IDs along with registering properties - if people are defining device specific properties they really ought to be tied to the IDs that are in use especially if (as seems likely to be the case with the current state of the world) people are doing things without attempting to coordinate and we're ending up trying to document the deployed reality.
The rule of thumb (in my view) should be that if the device object's _DSD is going to return the same set of properties as for DT and no other special handling determined by the ID is required (ie. nothing along the lines of "if the device ID is X, the _ABC method works like that" which has to be known by the driver), "PRP0001" should be returned by _HID and then the value of the "compatible" property should be the same as for DT.
This is a reasonable idea but we do need it to be compatible with Windows and we still need to make sure we have a process in place that BIOS authors and driver authors focused on Windows can reasonably be expected to work with. That's not something we have right now for DT (our DT process involves contributing to Linux) so the problem remains effectively the same.
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
Otherwise, a new device ID needs to be allocated for the device and _HID should return that ID. Also, if the device is compatible with another device with an already allocated ID (for _HID), _CID may return the device ID of the compatible device. [Of course, it's better if _HID is the same for identical devices.]
I honestly don't see BIOS authors as being likely to care about adding things to the CID if their systems are working (I'm assuming that HID is the primary device ID and CID are further backup compatible IDs).
On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
--9GYGtdBumnmR69ER Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
OK, we probably should have one to aid discoverability since as far as I can tell what's happening is that people (hi Intel!) are allocating their own identifiers for devices produced by other vendors that turn up on their boards. If people can find the set of IDs in use there's more chance they'll use the same ones as other people.
There's the PRP0001 ID that can be use to in combination with the "compatible" property which then works the same way as for DT.
That should be sufficient if the properties are going to be the same for ACPI (_DSD) and DT.
We've got people making BIOSs right now for systems you can actually buy=20 that are intended to run Windows which we need to support; right now the pressing problem I'm seeing is that we've got BIOS vendors not using properties at all and we're going to be ending up with configuration coming from big DMI tables instead which is miserable, Windows is perfectly happy to have custom drivers installed per machine. Do we know if Windows supports PRP0001 as it currently stands?
No, it doesn't.
Separate device IDs are necessary for Windows compatibility AFAICS.
But that also means any device ID registered by us won't be suitable in that case, because Windows won't use it.
There are two different problems here, though. The first one is a way to provide the existing Linux drivers with the information expected by them via ACPI and that's what _DSD (plus PRP0001 optionally) is. The second one is to be able to handle systems with ACPI tables from a random vendor who only cares about Windows and that's more difficult to address, because our ecosystem is different from theirs.
There basically are two ways around that. The first one is to have all knowledge related to device IDs in drivers (which effectively is what Windows does and which implies "board files" of sorts) and the second one is to make it possible to use overlays on top of the existing ACPI tables that will allow people to provide the properties expected by a more generic driver (this way, if the vendor didn't care to provide _DSD, for example, in the original ACPI tables, the system integrator would be able to use an overlay in an initramfs or boot partition to amend them).
There is a plan to do the latter, but that is going to take some time to complete.
If those are device IDs then what you're saying is what I'd expect to happen and it's part of the reason I'd expect us to be registering IDs along with registering properties - if people are defining device specific properties they really ought to be tied to the IDs that are in use especially if (as seems likely to be the case with the current state of the world) people are doing things without attempting to coordinate and we're ending up trying to document the deployed reality.
The rule of thumb (in my view) should be that if the device object's _DSD=
is
going to return the same set of properties as for DT and no other special handling determined by the ID is required (ie. nothing along the lines of "if the device ID is X, the _ABC method works like that" which has to be =
known
by the driver), "PRP0001" should be returned by _HID and then the value o=
f the
"compatible" property should be the same as for DT.
This is a reasonable idea but we do need it to be compatible with Windows and we still need to make sure we have a process in place that BIOS authors and driver authors focused on Windows can reasonably be expected to work with. That's not something we have right now for DT (our DT process involves contributing to Linux) so the problem remains effectively the same.
We can't make Windows use our stuff and they have a different model (a custom driver per device ID vs a common driver per IP block possibly matching multiple device IDs).
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
What do you mean by "something UEFI specific"?
Otherwise, a new device ID needs to be allocated for the device and _HID should return that ID. Also, if the device is compatible with another device with an already allocated ID (for _HID), _CID may return the devic=
e ID
of the compatible device. [Of course, it's better if _HID is the same for identical devices.]
I honestly don't see BIOS authors as being likely to care about adding things to the CID if their systems are working (I'm assuming that HID is the primary device ID and CID are further backup compatible IDs).
They will if they care to be compatible with old (binary) OSes that didn't know about the new device ID, but shipped drivers that could handle the device (although possibly in a "crippled" way).
On Sat, Nov 29, 2014 at 11:27:52PM +0100, Rafael J. Wysocki wrote:
On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
There's the PRP0001 ID that can be use to in combination with the "compatible" property which then works the same way as for DT.
That should be sufficient if the properties are going to be the same for ACPI (_DSD) and DT.
We've got people making BIOSs right now for systems you can actually buy=20 that are intended to run Windows which we need to support; right now the pressing problem I'm seeing is that we've got BIOS vendors not using properties at all and we're going to be ending up with configuration coming from big DMI tables instead which is miserable, Windows is perfectly happy to have custom drivers installed per machine. Do we know if Windows supports PRP0001 as it currently stands?
No, it doesn't.
Separate device IDs are necessary for Windows compatibility AFAICS.
OK, then PRP0001 is a complete non-starter for the applications I'm looking at.
But that also means any device ID registered by us won't be suitable in that case, because Windows won't use it.
The dream here is that people working on building systems, people working on Windows drivers and people working on Linux drivers will at some point be able to collaborate. If we're going to go off and do our own thing for Linux without talking to anyone that's not really addressing the issue.
There are two different problems here, though. The first one is a way to provide the existing Linux drivers with the information expected by them via ACPI and that's what _DSD (plus PRP0001 optionally) is. The second one is to be able to handle systems with ACPI tables from a random vendor who only cares about Windows and that's more difficult to address, because our ecosystem is different from theirs.
There basically are two ways around that. The first one is to have all knowledge related to device IDs in drivers (which effectively is what Windows does and which implies "board files" of sorts) and the second one is to make it possible to use overlays on top of the existing ACPI tables that will allow people to provide the properties expected by a more generic driver (this way, if the vendor didn't care to provide _DSD, for example, in the original ACPI tables, the system integrator would be able to use an overlay in an initramfs or boot partition to amend them).
There's also the option that Windows drivers start using _DSD themselves which is, I understand, the goal towards which the people working on at least audio are heading.
There is a plan to do the latter, but that is going to take some time to complete.
Like I keep saying we have people trying to ship systems now, you can buy affected systems already and there's going to be more coming and I'm not convinced it's going to be fun for system integrators (distros?) to have to quirk every system that comes out.
This is a reasonable idea but we do need it to be compatible with Windows and we still need to make sure we have a process in place that BIOS authors and driver authors focused on Windows can reasonably be expected to work with. That's not something we have right now for DT (our DT process involves contributing to Linux) so the problem remains effectively the same.
We can't make Windows use our stuff and they have a different model (a custom driver per device ID vs a common driver per IP block possibly matching multiple device IDs).
The hardware already doesn't match the Windows model well here, it's causing them some problems too (and it's making life miserable for the CODEC vendors who want to ship both Windows and Linux drivers too). We should at least try to pull things together so we get something that works for everyone; in Linux we have quite a bit of experience with this sort of system which we can hopefully share with the Windows people to help make everyone's lives better.
One of the things that would help this would be if we were able to give people a way to write their ACPI tables in a way that is likely to both work well for us and avoid lots of make work for the Windows people.
Note that all this discussion is pretty much about drivers for single devices which can be wired into the system in a flexible manner, even in a Windows world you won't vary the device ID. At present we're quirking on DMI.
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
What do you mean by "something UEFI specific"?
Sorry, I mean ACPI specific (UEFI forum).
Otherwise, a new device ID needs to be allocated for the device and _HID should return that ID. Also, if the device is compatible with another device with an already allocated ID (for _HID), _CID may return the devic=
e ID
of the compatible device. [Of course, it's better if _HID is the same for identical devices.]
I honestly don't see BIOS authors as being likely to care about adding things to the CID if their systems are working (I'm assuming that HID is the primary device ID and CID are further backup compatible IDs).
They will if they care to be compatible with old (binary) OSes that didn't know about the new device ID, but shipped drivers that could handle the device (although possibly in a "crippled" way).
It's not just the device IDs you need, it's the properties too.
On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
--MRL9B5bOucwGAkwp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
On Sat, Nov 29, 2014 at 11:27:52PM +0100, Rafael J. Wysocki wrote:
On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
There's the PRP0001 ID that can be use to in combination with the "compatible" property which then works the same way as for DT.
That should be sufficient if the properties are going to be the same for ACPI (_DSD) and DT.
We've got people making BIOSs right now for systems you can actually buy=20 that are intended to run Windows which we need to support; right now the pressing problem I'm seeing is that we've got BIOS vendors not using properties at all and we're going to be ending up with configuration coming from big DMI tables instead which is miserable, Windows is perfectly happy to have custom drivers installed per machine. Do we know if Windows supports PRP0001 as it currently stands?
No, it doesn't.
Separate device IDs are necessary for Windows compatibility AFAICS.
OK, then PRP0001 is a complete non-starter for the applications I'm looking at.
But that also means any device ID registered by us won't be suitable in that case, because Windows won't use it.
The dream here is that people working on building systems, people working on Windows drivers and people working on Linux drivers will at some point be able to collaborate. If we're going to go off and do our own thing for Linux without talking to anyone that's not really addressing the issue.
Well, that's already going on in the DT land, isn't it? It has been going on for quite a while AFAICS.
There are two different problems here, though. The first one is a way to provide the existing Linux drivers with the information expected by them via ACPI and that's what _DSD (plus PRP0001 optionally) is. The second one is to be able to handle systems with ACPI tables from a random vendor who only cares about Windows and that's more difficult to address, because our ecosystem is different from theirs.
There basically are two ways around that. The first one is to have all knowledge related to device IDs in drivers (which effectively is what Windows does and which implies "board files" of sorts) and the second one is to make it possible to use overlays on top of the existing ACPI tables that will allow people to provide the properties expected by a more generic driver (this way, if the vendor didn't care to provide _DSD, for example, in the original ACPI tables, the system integrator would be able to use an overlay in an initramfs or boot partition to amend them).
There's also the option that Windows drivers start using _DSD themselves which is, I understand, the goal towards which the people working on at least audio are heading.
Technically, Windows driver writers can evaluate _DSD and handle the information the way we do, but I'm not sure if this is really convenient for them.
We use _DSD, because we want drivers to work with DT as well with ACPI without adding special DT-specific or ACPI-specific code to them. The people who work on Windows drivers don't have this problem, so as I said, if they care about Linux at all, that may be a good enough motivation for them to look at _DSD, but if they don't, I honestly don't see why they would do that.
There is a plan to do the latter, but that is going to take some time to complete.
Like I keep saying we have people trying to ship systems now, you can buy affected systems already and there's going to be more coming and I'm not convinced it's going to be fun for system integrators (distros?) to have to quirk every system that comes out.
I'm not sure what we can do to prevent the above from happening, realistically. Yes, we are late. No, we can't speed up things too much AFAICS.
This is a reasonable idea but we do need it to be compatible with Windows and we still need to make sure we have a process in place that BIOS authors and driver authors focused on Windows can reasonably be expected to work with. That's not something we have right now for DT (our DT process involves contributing to Linux) so the problem remains effectively the same.
We can't make Windows use our stuff and they have a different model (a custom driver per device ID vs a common driver per IP block possibly matching multiple device IDs).
The hardware already doesn't match the Windows model well here, it's causing them some problems too (and it's making life miserable for the CODEC vendors who want to ship both Windows and Linux drivers too). We should at least try to pull things together so we get something that works for everyone; in Linux we have quite a bit of experience with this sort of system which we can hopefully share with the Windows people to help make everyone's lives better.
That would be a great outcome, but I'm kind of cautious here ...
One of the things that would help this would be if we were able to give people a way to write their ACPI tables in a way that is likely to both work well for us and avoid lots of make work for the Windows people.
Note that all this discussion is pretty much about drivers for single devices which can be wired into the system in a flexible manner, even in a Windows world you won't vary the device ID. At present we're quirking on DMI.
So the answer to that in my view is: Use _DSD and allocate your own device IDs for Windows drivers to bind to.
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
What do you mean by "something UEFI specific"?
Sorry, I mean ACPI specific (UEFI forum).
Do you mean a special device ID of some sort, then?
Otherwise, a new device ID needs to be allocated for the device and _HID should return that ID. Also, if the device is compatible with another device with an already allocated ID (for _HID), _CID may return the devic=
e ID
of the compatible device. [Of course, it's better if _HID is the same for identical devices.]
I honestly don't see BIOS authors as being likely to care about adding things to the CID if their systems are working (I'm assuming that HID is the primary device ID and CID are further backup compatible IDs).
They will if they care to be compatible with old (binary) OSes that didn't know about the new device ID, but shipped drivers that could handle the device (although possibly in a "crippled" way).
It's not just the device IDs you need, it's the properties too.
I suppose you have some specific examples in mind that I may not be familiar with and we may spend an arbitrary amount of time speaking past each other. :-)
I'm quite confident that _DSD can be used to address the problem at hand, but for that it needs to be adopted by platform firmware writers. I personally have no power to make that happen and even then it would not be realistic to expect that to happen overnight.
Overlays can be used as a workaround here, but as I said it is going to take some time to make them work reliably enough.
That's where we are today. Do you have any suggestions on what else we can do?
On Mon, Dec 01, 2014 at 11:16:31PM +0100, Rafael J. Wysocki wrote:
On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
The dream here is that people working on building systems, people working on Windows drivers and people working on Linux drivers will at some point be able to collaborate. If we're going to go off and do our own thing for Linux without talking to anyone that's not really addressing the issue.
Well, that's already going on in the DT land, isn't it? It has been going on for quite a while AFAICS.
In theory (and where it's actually relevant in practice to at least some extent) this stuff is all OS neutral, there's a definite willingness for it to be so.
There's also the option that Windows drivers start using _DSD themselves which is, I understand, the goal towards which the people working on at least audio are heading.
Technically, Windows driver writers can evaluate _DSD and handle the information the way we do, but I'm not sure if this is really convenient for them.
I'm not sure how convenient it is, though I'm reasonably sure a helper library could make it so.
We use _DSD, because we want drivers to work with DT as well with ACPI without adding special DT-specific or ACPI-specific code to them. The people who work on Windows drivers don't have this problem, so as I said, if they care about Linux at all, that may be a good enough motivation for them to look at _DSD, but if they don't, I honestly don't see why they would do that.
They care about getting properties out, or at least they should, and in this market many of the device vendors care about Linux at least as much as they do Windows (sometimes even more than they care about Windows, there's overlap with the Android market).
Note that all this discussion is pretty much about drivers for single devices which can be wired into the system in a flexible manner, even in a Windows world you won't vary the device ID. At present we're quirking on DMI.
So the answer to that in my view is: Use _DSD and allocate your own device IDs for Windows drivers to bind to.
Right, so we circle back to the original question about documenting those IDs and _DSD properties. :)
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
What do you mean by "something UEFI specific"?
Sorry, I mean ACPI specific (UEFI forum).
Do you mean a special device ID of some sort, then?
No, just a regular one.
It's not just the device IDs you need, it's the properties too.
I suppose you have some specific examples in mind that I may not be familiar with and we may spend an arbitrary amount of time speaking past each other. :-)
Things like Documentation/devicetree/bindings/sound/wm8962.txt (at least the optional properties), basically "how is this device wired into the board" properties.
That's where we are today. Do you have any suggestions on what else we can do?
I'd like to see a space where people working with a device can publish what they've done in terms of firmware binding for it in a manner that might work for them; at present it seems like the UEFI forum is the best place to start doing that, there's the start of a register and process for updating it there at least.
On Monday, December 01, 2014 10:19:07 PM Mark Brown wrote:
On Mon, Dec 01, 2014 at 11:16:31PM +0100, Rafael J. Wysocki wrote:
On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
The dream here is that people working on building systems, people working on Windows drivers and people working on Linux drivers will at some point be able to collaborate. If we're going to go off and do our own thing for Linux without talking to anyone that's not really addressing the issue.
Well, that's already going on in the DT land, isn't it? It has been going on for quite a while AFAICS.
In theory (and where it's actually relevant in practice to at least some extent) this stuff is all OS neutral, there's a definite willingness for it to be so.
There's also the option that Windows drivers start using _DSD themselves which is, I understand, the goal towards which the people working on at least audio are heading.
Technically, Windows driver writers can evaluate _DSD and handle the information the way we do, but I'm not sure if this is really convenient for them.
I'm not sure how convenient it is, though I'm reasonably sure a helper library could make it so.
Well, for that we'd need to find a Windows developer willing to write one I suppose ...
We use _DSD, because we want drivers to work with DT as well with ACPI without adding special DT-specific or ACPI-specific code to them. The people who work on Windows drivers don't have this problem, so as I said, if they care about Linux at all, that may be a good enough motivation for them to look at _DSD, but if they don't, I honestly don't see why they would do that.
They care about getting properties out, or at least they should, and in this market many of the device vendors care about Linux at least as much as they do Windows (sometimes even more than they care about Windows, there's overlap with the Android market).
OK
Note that all this discussion is pretty much about drivers for single devices which can be wired into the system in a flexible manner, even in a Windows world you won't vary the device ID. At present we're quirking on DMI.
So the answer to that in my view is: Use _DSD and allocate your own device IDs for Windows drivers to bind to.
Right, so we circle back to the original question about documenting those IDs and _DSD properties. :)
IDs are allocated by whoever owns the device description (the starting 3 or 4 code letters need to be registered via the UEFI Forum/ASWG).
Properties can be registered with the UEFI Forum via the ASWG too.
We also need a way of getting the word out to people that they should be doing this (also a problem no matter if we use PRP0001 or something UEFI specific).
What do you mean by "something UEFI specific"?
Sorry, I mean ACPI specific (UEFI forum).
Do you mean a special device ID of some sort, then?
No, just a regular one.
It's not just the device IDs you need, it's the properties too.
I suppose you have some specific examples in mind that I may not be familiar with and we may spend an arbitrary amount of time speaking past each other. :-)
Things like Documentation/devicetree/bindings/sound/wm8962.txt (at least the optional properties), basically "how is this device wired into the board" properties.
That's where we are today. Do you have any suggestions on what else we can do?
I'd like to see a space where people working with a device can publish what they've done in terms of firmware binding for it in a manner that might work for them; at present it seems like the UEFI forum is the best place to start doing that, there's the start of a register and process for updating it there at least.
That's correct.
On Sat, 29 Nov 2014 23:27:52 +0100 , "Rafael J. Wysocki" rjw@rjwysocki.net wrote:
On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
--9GYGtdBumnmR69ER Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
OK, we probably should have one to aid discoverability since as far as I can tell what's happening is that people (hi Intel!) are allocating their own identifiers for devices produced by other vendors that turn up on their boards. If people can find the set of IDs in use there's more chance they'll use the same ones as other people.
There's the PRP0001 ID that can be use to in combination with the "compatible" property which then works the same way as for DT.
That should be sufficient if the properties are going to be the same for ACPI (_DSD) and DT.
We've got people making BIOSs right now for systems you can actually buy=20 that are intended to run Windows which we need to support; right now the pressing problem I'm seeing is that we've got BIOS vendors not using properties at all and we're going to be ending up with configuration coming from big DMI tables instead which is miserable, Windows is perfectly happy to have custom drivers installed per machine. Do we know if Windows supports PRP0001 as it currently stands?
No, it doesn't.
Separate device IDs are necessary for Windows compatibility AFAICS.
But that also means any device ID registered by us won't be suitable in that case, because Windows won't use it.
There are two different problems here, though. The first one is a way to provide the existing Linux drivers with the information expected by them via ACPI and that's what _DSD (plus PRP0001 optionally) is. The second one is to be able to handle systems with ACPI tables from a random vendor who only cares about Windows and that's more difficult to address, because our ecosystem is different from theirs.
It is a problem if the expected binding method is different between Linux and Windows. This is a problem we've hit before where the platform /may/ try to get both right, but in reality only one works, or even implemented.
I predict that PRP0001 is only going to be practical when the hardware is only ever going to be driven by Linux or other PRP0001 aware OS. ie. A Minnowboard Max with a custom expansion board attached. When the hardware is supported under both Windows and Linux then it will probably be best for Linux to attempt to bind using the device id before attempting to use PRP0001.
There basically are two ways around that. The first one is to have all knowledge related to device IDs in drivers (which effectively is what Windows does and which implies "board files" of sorts) and the second one is to make it possible to use overlays on top of the existing ACPI tables that will allow people to provide the properties expected by a more generic driver (this way, if the vendor didn't care to provide _DSD, for example, in the original ACPI tables, the system integrator would be able to use an overlay in an initramfs or boot partition to amend them).
Either approach amounts to pretty much the same thing. The kernel/distribution needs to carry around device specific driver data which is exactly how we've supported x86 hardware. Whether the data is in-kernel or in-userspace is kind of an implementation detail. :-)
_DSD support is a different situation though. Even if Windows doesn't care to directly support _DSD, drivers are free to use _DSD properties. This is the scenario where the shared binding repository will be important.
g.
On Thu, Dec 04, 2014 at 11:12:34AM +0000, Grant Likely wrote:
On Sat, 29 Nov 2014 23:27:52 +0100
There basically are two ways around that. The first one is to have all knowledge related to device IDs in drivers (which effectively is what Windows does and which implies "board files" of sorts) and the second one is to make it possible to use overlays on top of the existing ACPI tables that will allow people to provide the properties expected by a more generic driver (this way, if the vendor didn't care to provide _DSD, for example, in the original ACPI tables, the system integrator would be able to use an overlay in an initramfs or boot partition to amend them).
Either approach amounts to pretty much the same thing. The kernel/distribution needs to carry around device specific driver data which is exactly how we've supported x86 hardware. Whether the data is in-kernel or in-userspace is kind of an implementation detail. :-)
This isn't entirely what we've doing for x86 up until now - there's always been an expectation that the firmware will be setting things up to work by default (or so we can read the setup back from the hardwaer when we take over) and we're mostly just carrying quirk data when that doesn't pan out.
_DSD support is a different situation though. Even if Windows doesn't care to directly support _DSD, drivers are free to use _DSD properties. This is the scenario where the shared binding repository will be important.
Right, this would be ideal for the devices we're looking at.
participants (6)
-
Ben Zhang -
Darren Hart -
Grant Likely -
Liam Girdwood -
Mark Brown -
Rafael J. Wysocki