Discussion:
[PATCH] drm/i915/intel_dsi: Add acpi_gpio_mapping for the panel-enable GPIO
(too old to reply)
Hans de Goede
2018-06-29 11:32:58 UTC
Permalink
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.

Note this patch is untested as I don't have hardware to test this,
but it should fix things.

Signed-off-by: Hans de Goede <***@redhat.com>
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b7acb5a70b3..b2b75ed3cbf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -29,6 +29,7 @@
#include <drm/drm_edid.h>
#include <drm/i915_drm.h>
#include <drm/drm_mipi_dsi.h>
+#include <linux/acpi.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include "i915_drv.h"
@@ -1713,6 +1714,13 @@ static void intel_dsi_add_properties(struct intel_connector *connector)
}
}

+static const struct acpi_gpio_params panel_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping panel_gpios[] = {
+ { "panel", &panel_gpio, 1 },
+ { },
+};
+
void intel_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -1811,6 +1819,7 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
*/
if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
(dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)) {
+ devm_acpi_dev_add_driver_gpios(dev->dev, panel_gpios);
intel_dsi->gpio_panel =
gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
--
2.17.1
Ville Syrjälä
2018-06-29 11:51:38 UTC
Permalink
Post by Hans de Goede
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.
Note this patch is untested as I don't have hardware to test this,
but it should fix things.
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b7acb5a70b3..b2b75ed3cbf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -29,6 +29,7 @@
#include <drm/drm_edid.h>
#include <drm/i915_drm.h>
#include <drm/drm_mipi_dsi.h>
+#include <linux/acpi.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include "i915_drv.h"
@@ -1713,6 +1714,13 @@ static void intel_dsi_add_properties(struct intel_connector *connector)
}
}
+static const struct acpi_gpio_params panel_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping panel_gpios[] = {
+ { "panel", &panel_gpio, 1 },
+ { },
+};
Named initializers please.
Post by Hans de Goede
+
void intel_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -1811,6 +1819,7 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
*/
if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
(dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)) {
+ devm_acpi_dev_add_driver_gpios(dev->dev, panel_gpios);
Some explanation on what this actually does would be nice. There is no
documentation that I can see so it's totally unclear why this is needed.

Also IIRC this gpio comes straight from the pmic driver and not from
acpi. So I don't really understand why acpi stuff must be involved here.

ccing Andy for a clue...
Post by Hans de Goede
intel_dsi->gpio_panel =
gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
--
2.17.1
--
Ville Syrjälä
Intel
Hans de Goede
2018-06-29 12:05:58 UTC
Permalink
Hi,
Post by Ville Syrjälä
Post by Hans de Goede
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.
Note this patch is untested as I don't have hardware to test this,
but it should fix things.
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b7acb5a70b3..b2b75ed3cbf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -29,6 +29,7 @@
#include <drm/drm_edid.h>
#include <drm/i915_drm.h>
#include <drm/drm_mipi_dsi.h>
+#include <linux/acpi.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include "i915_drv.h"
@@ -1713,6 +1714,13 @@ static void intel_dsi_add_properties(struct intel_connector *connector)
}
}
+static const struct acpi_gpio_params panel_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping panel_gpios[] = {
+ { "panel", &panel_gpio, 1 },
+ { },
+};
Named initializers please.
These structs are used in many other drivers without using named initializers
and using it with named-initializers will make the mapping table much harder
to read if there is more then 1 entry.

I don't believe named initializers are necessary / useful here, on the
contrary I believe them to be counter-productive in this case.
Post by Ville Syrjälä
Post by Hans de Goede
+
void intel_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -1811,6 +1819,7 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
*/
if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
(dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)) {
+ devm_acpi_dev_add_driver_gpios(dev->dev, panel_gpios);
Some explanation on what this actually does would be nice. There is no
documentation that I can see so it's totally unclear why this is needed.
Also IIRC this gpio comes straight from the pmic driver and not from
acpi. So I don't really understand why acpi stuff must be involved here.
It has always come through ACPI, without adding code to manually search
for a GPIO chip (and using a different way to get the gpio_desc) all
GPIOs are always looked up through ACPI resource tables on x86.

Now it might point to a GPIO on the PMIC in some cases. But it does not
always point to the PMIC, e.g. here are the GFX0 resources from the
Microsoft Surface 3 (non pro version) :

Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOut
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003F
}
})

Notice how it is using a GPIO on GPO1, so not on the PMIC.

As for why this is necessary ACPI based GPIO lookups so far where unique in
that they ignored the passed in name, relying on the index instead and in
the i915 code, since no index is passed in simply blindly taking the first GPIO
in the resources table.

While doing various cleanups to the ACPI GPIO code Andy introduced *mandatory*
GPIO mappings for ACPI to map resource indexes to names as used on other
platforms.

Regards,

Hans
Ville Syrjälä
2018-06-29 12:10:37 UTC
Permalink
Post by Hans de Goede
Hi,
Post by Ville Syrjälä
Post by Hans de Goede
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.
Note this patch is untested as I don't have hardware to test this,
but it should fix things.
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b7acb5a70b3..b2b75ed3cbf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -29,6 +29,7 @@
#include <drm/drm_edid.h>
#include <drm/i915_drm.h>
#include <drm/drm_mipi_dsi.h>
+#include <linux/acpi.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include "i915_drv.h"
@@ -1713,6 +1714,13 @@ static void intel_dsi_add_properties(struct intel_connector *connector)
}
}
+static const struct acpi_gpio_params panel_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping panel_gpios[] = {
+ { "panel", &panel_gpio, 1 },
+ { },
+};
Named initializers please.
These structs are used in many other drivers without using named initializers
and using it with named-initializers will make the mapping table much harder
to read if there is more then 1 entry.
I don't believe named initializers are necessary / useful here, on the
contrary I believe them to be counter-productive in this case.
I have no idea what these magic numbers mean, and I don't want to have
to look up the struct definition everyt time I read this code.
Post by Hans de Goede
Post by Ville Syrjälä
Post by Hans de Goede
+
void intel_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -1811,6 +1819,7 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
*/
if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
(dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)) {
+ devm_acpi_dev_add_driver_gpios(dev->dev, panel_gpios);
Some explanation on what this actually does would be nice. There is no
documentation that I can see so it's totally unclear why this is needed.
Also IIRC this gpio comes straight from the pmic driver and not from
acpi. So I don't really understand why acpi stuff must be involved here.
It has always come through ACPI, without adding code to manually search
for a GPIO chip (and using a different way to get the gpio_desc) all
GPIOs are always looked up through ACPI resource tables on x86.
So what is the gpio lookup thing in intel_soc_pmic_core.c ?
Post by Hans de Goede
Now it might point to a GPIO on the PMIC in some cases. But it does not
always point to the PMIC, e.g. here are the GFX0 resources from the
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOut
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003F
}
})
Notice how it is using a GPIO on GPO1, so not on the PMIC.
As for why this is necessary ACPI based GPIO lookups so far where unique in
that they ignored the passed in name, relying on the index instead and in
the i915 code, since no index is passed in simply blindly taking the first GPIO
in the resources table.
While doing various cleanups to the ACPI GPIO code Andy introduced *mandatory*
GPIO mappings for ACPI to map resource indexes to names as used on other
platforms.
Regards,
Hans
--
Ville Syrjälä
Intel
Hans de Goede
2018-06-29 12:28:09 UTC
Permalink
Hi,
Post by Ville Syrjälä
Post by Hans de Goede
Hi,
Post by Ville Syrjälä
Post by Hans de Goede
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.
Note this patch is untested as I don't have hardware to test this,
but it should fix things.
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b7acb5a70b3..b2b75ed3cbf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -29,6 +29,7 @@
#include <drm/drm_edid.h>
#include <drm/i915_drm.h>
#include <drm/drm_mipi_dsi.h>
+#include <linux/acpi.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include "i915_drv.h"
@@ -1713,6 +1714,13 @@ static void intel_dsi_add_properties(struct intel_connector *connector)
}
}
+static const struct acpi_gpio_params panel_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping panel_gpios[] = {
+ { "panel", &panel_gpio, 1 },
+ { },
+};
Named initializers please.
These structs are used in many other drivers without using named initializers
and using it with named-initializers will make the mapping table much harder
to read if there is more then 1 entry.
I don't believe named initializers are necessary / useful here, on the
contrary I believe them to be counter-productive in this case.
I have no idea what these magic numbers mean, and I don't want to have
to look up the struct definition everyt time I read this code.
Ok, fair enough.
Post by Ville Syrjälä
Post by Hans de Goede
Post by Ville Syrjälä
Post by Hans de Goede
+
void intel_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -1811,6 +1819,7 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
*/
if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
(dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)) {
+ devm_acpi_dev_add_driver_gpios(dev->dev, panel_gpios);
Some explanation on what this actually does would be nice. There is no
documentation that I can see so it's totally unclear why this is needed.
Also IIRC this gpio comes straight from the pmic driver and not from
acpi. So I don't really understand why acpi stuff must be involved here.
It has always come through ACPI, without adding code to manually search
for a GPIO chip (and using a different way to get the gpio_desc) all
GPIOs are always looked up through ACPI resource tables on x86.
So what is the gpio lookup thing in intel_soc_pmic_core.c ?
Oh, right <stunned silence>. I had forgotten all about that.

I got contacted by an user of a Surface 3 which is seeing a whole bunch of
new errors after jumping from a somewhat old kernel to 4.18, of which not
being able to get the panel-gpio is one error, so I thought I would go and
fix that one, since the acpi_gpio_mapping stuff is fairly new. He could
not test because the Surface 3 won't boot because of the other errors,
I guess those other errors are also causing issues with the PMIC code.

You are right that in this case we are already manually adding a non
ACPI based mapping, so we should probably not be adding the ACPI based
mapping, my bad.

TL;DR: You are right we already have a hardcoded mapping to the PMIC for
this and my patch is bogus and should be dropped.

Regards,

Hans
Post by Ville Syrjälä
Post by Hans de Goede
Now it might point to a GPIO on the PMIC in some cases. But it does not
always point to the PMIC, e.g. here are the GFX0 resources from the
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x002C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOut
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003F
}
})
Notice how it is using a GPIO on GPO1, so not on the PMIC.
As for why this is necessary ACPI based GPIO lookups so far where unique in
that they ignored the passed in name, relying on the index instead and in
the i915 code, since no index is passed in simply blindly taking the first GPIO
in the resources table.
While doing various cleanups to the ACPI GPIO code Andy introduced *mandatory*
GPIO mappings for ACPI to map resource indexes to names as used on other
platforms.
Regards,
Hans
Andy Shevchenko
2018-06-29 16:12:24 UTC
Permalink
I saw that the change was discarded but I would comment about the GPIO
ACPI mapping tables.
Post by Ville Syrjälä
Post by Hans de Goede
+ devm_acpi_dev_add_driver_gpios(dev->dev,
panel_gpios);
Some explanation on what this actually does would be nice. There is no
documentation that I can see so it's totally unclear why this is needed.
Documentation is here Documentation/acpi/gpio-properties.txt.

The key phrase is
"...the driver is supposed to know what to use the GpioIo()/GpioInt()
resources for once it has identified the device. Having done that, it
can simply assign names to the GPIO lines it is going to use and provide
the GPIO subsystem with a mapping between those names and the ACPI GPIO
resources corresponding to them.

To do that, the driver needs to define a mapping table..."
--
Andy Shevchenko <***@linux.intel.com>
Intel Finland Oy
Patchwork
2018-06-29 14:15:03 UTC
Permalink
== Series Details ==

Series: drm/i915/intel_dsi: Add acpi_gpio_mapping for the panel-enable GPIO
URL : https://patchwork.freedesktop.org/series/45658/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4404 -> Patchwork_9484 =

== Summary - SUCCESS ==

No regressions found.

External URL: https://patchwork.freedesktop.org/api/1.0/series/45658/revisions/1/mbox/

== Possible new issues ==

Here are the unknown changes that may have been introduced in Patchwork_9484:

=== IGT changes ===

==== Possible regressions ====

***@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
{fi-cfl-8109u}: PASS -> INCOMPLETE


== Known issues ==

Here are the changes found in Patchwork_9484 that come from known issues:

=== IGT changes ===

==== Issues hit ====

***@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#106103, fdo#102614)


{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (45 -> 39) ==

Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600


== Build changes ==

* Linux: CI_DRM_4404 -> Patchwork_9484

CI_DRM_4404: ceaab659002c938f1788b7458d5081fadc3c1ddc @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4531: a14bc8b4d69eaca189665de505e6b10cbfbb7730 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9484: 4bcc6e626b5f674eed2461a35309824856eb97c7 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

4bcc6e626b5f drm/i915/intel_dsi: Add acpi_gpio_mapping for the panel-enable GPIO

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9484/issues.html
Patchwork
2018-06-29 15:40:57 UTC
Permalink
== Series Details ==

Series: drm/i915/intel_dsi: Add acpi_gpio_mapping for the panel-enable GPIO
URL : https://patchwork.freedesktop.org/series/45658/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4404_full -> Patchwork_9484_full =

== Summary - WARNING ==

Minor unknown changes coming with Patchwork_9484_full need to be verified
manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9484_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.



== Possible new issues ==

Here are the unknown changes that may have been introduced in Patchwork_9484_full:

=== IGT changes ===

==== Warnings ====

***@gem_exec_schedule@deep-blt:
shard-kbl: PASS -> SKIP


== Known issues ==

Here are the changes found in Patchwork_9484_full that come from known issues:

=== IGT changes ===

==== Issues hit ====

***@gem_exec_schedule@pi-ringfull-vebox:
shard-kbl: NOTRUN -> FAIL (fdo#103158)

***@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
shard-glk: PASS -> FAIL (fdo#105703)

***@kms_available_modes_crc@available_mode_test_crc:
shard-kbl: NOTRUN -> FAIL (fdo#106641)

***@kms_flip@flip-vs-expired-vblank-interruptible:
shard-glk: PASS -> FAIL (fdo#105363)

***@kms_flip_tiling@flip-to-y-tiled:
shard-glk: PASS -> FAIL (fdo#103822, fdo#104724)

***@kms_sysfs_edid_timing:
shard-kbl: NOTRUN -> FAIL (fdo#100047)


==== Possible fixes ====

***@drv_selftest@live_gtt:
shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> PASS

***@kms_flip@2x-flip-vs-expired-vblank-interruptible:
shard-hsw: FAIL (fdo#102887) -> PASS

***@kms_flip@2x-plain-flip-fb-recreate-interruptible:
shard-glk: FAIL (fdo#100368) -> PASS


fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4404 -> Patchwork_9484

CI_DRM_4404: ceaab659002c938f1788b7458d5081fadc3c1ddc @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4531: a14bc8b4d69eaca189665de505e6b10cbfbb7730 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9484: 4bcc6e626b5f674eed2461a35309824856eb97c7 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9484/shards.html
Continue reading on narkive:
Loading...