linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
       [not found]   ` <CAMxBKG1670TFuV3nHP7Yk8s6H+oBF7iiyiB-b=PvKv9hcH22xQ@mail.gmail.com>
@ 2023-01-29 18:24     ` Jonathan Cameron
       [not found]       ` <CAMxBKG0tyLSpaDPGBXsJbqgHSG9rH6owtSJsLw_ekmTA3Kyvdw@mail.gmail.com>
  0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-01-29 18:24 UTC (permalink / raw)
  To: Darrell Kavanagh; +Cc: lorenzo, lars, linux-iio, linux-kernel, carnil

On Sun, 29 Jan 2023 17:03:51 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> Hi,
> 
> I raised this bug in Debian, and have been asked to raise it upstream and
> was given your addresses to do so. Will this email be OK, or should I raise
> it in a bug tracking system somewhere?

Email is the right option.

> 
> Many thanks,
> Darrell
> 
> 
> 
> 
> ---------- Forwarded message ---------
> From: Salvatore Bonaccorso <carnil@debian.org>
> Date: Sat, 28 Jan 2023 at 20:33
> Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> 
> 
> Hi Darrell,
> 
> On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > Package: src:linux
> > Version: 6.1.4-1
> > Severity: normal
> > File: linux
> > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> >
> > Dear Maintainer,
> >
> > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> device
> > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> and the
> > sysfs trees are created at  
> devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> but
> > no driver is loaded.

At least this is using the ST PNP ID which is better than average
(long story!)

The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
does not currently have an ACPI support.  It should be straight forwards
to add though the driver first needs converting to use
device_get_match_data() with appropriate fallback so that it will match on
ACPI, OF or original spi_device_id tables

Completely untested but something like the following
(the offset in the enum is needed to allow us to tell if we got a result when
calling device_get_match_data() as it returns NULL on failure IIRC)

I'm not sure how sucessful the driver will be at finding any interrupts etc, but
it may get you basic functionality.

Good luck and others more familiar with the driver may well tell me what I forgot
when hacking the below ;)

diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
index 499fcf8875b4..2617ce236ddc 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
@@ -39,7 +39,7 @@
 #define ST_ISM330IS_DEV_NAME   "ism330is"
 
 enum st_lsm6dsx_hw_id {
-       ST_LSM6DS3_ID,
+       ST_LSM6DS3_ID = 1,
        ST_LSM6DS3H_ID,
        ST_LSM6DSL_ID,
        ST_LSM6DSM_ID,
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
index df5f60925260..ecfceb2fb3db 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
@@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
 
 static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
 {
-       const struct i2c_device_id *id = i2c_client_get_device_id(client);
-       int hw_id = id->driver_data;
+       int hw_id;
        struct regmap *regmap;
 
+       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
+       if (!hw_id)
+               hw_id = i2c_client_get_device_id(client)->driver_data;
+       if (!hw_id)
+               return -EINVAL;
+
        regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
        if (IS_ERR(regmap)) {
                dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
@@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
 
+static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
+       { "SMO8B30", ST_LSM6DS3TRC_ID, },
+};
+
 static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
        { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
        { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
@@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
                .name = "st_lsm6dsx_i2c",
                .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
                .of_match_table = st_lsm6dsx_i2c_of_match,
+               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
        },
        .probe_new = st_lsm6dsx_i2c_probe,
        .id_table = st_lsm6dsx_i2c_id_table,


> >
> > The device is identifying itself to the kernel with PNP id SMO8B30:
> > physical_node:
> >       modalias=acpi:SMO8B30:SMO8B30:
> >       name=SMO8B30:00
> >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> >       waiting_for_supplier=0
> > firmware_node:
> >       hid=SMO8B30
> >       modalias=acpi:SMO8B30:SMO8B30:
> >       path=\_SB_.PCI0.I2C5.DEV_
> >       status=15
> >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> >       uid=0
> >
> > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> loaded on boot.
> > Modprobing it does not associate it with the device, as I would expect as
> > the module does not provide an alias for the above acpi/pnp id.  
> 
> Can you report this issue upstream? Gues to reach out are according to
> get_maintainers.pl script:
> 
> Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> linux-kernel@vger.kernel.org (open list)
> 
> Please keep us in the loop.
> 
> Regards,
> Salvatore


^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Fwd: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
       [not found]       ` <CAMxBKG0tyLSpaDPGBXsJbqgHSG9rH6owtSJsLw_ekmTA3Kyvdw@mail.gmail.com>
@ 2023-01-30  3:37         ` Darrell Kavanagh
  2023-01-30 12:31           ` Jonathan Cameron
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-01-30  3:37 UTC (permalink / raw)
  To: linux-iio, linux-kernel

Forwarding because original html messages were rejected by the server...

---------- Forwarded message ---------
From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
Date: Mon, 30 Jan 2023 at 02:52
Subject: Re: Bug#1029850: linux: Driver not loaded for ST
Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
To: Jonathan Cameron <jic23@kernel.org>
Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
<linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<carnil@debian.org>


Hi Jonathan,

Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
that 6.2 includes some i2c enhancements), but I adapted your changes
to fit my Debian 6.1 kernel and it works. Two IIO devices are created
in sysfs, iio-sensor-proxy.service starts up and automatic screen
rotation in Gnome just works.

To get the modules to load on boot, I made a small change to your code
in st_lsm6dsx_i2c to add the acpi alias to modules.alias:

adding a null element to st_lsm6dsx_i2c_acpi_match:
    static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
         { "SMO8B30", ST_LSM6DS3TRC_ID, },
         { },
    };
then:
   MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);


dmesg shows:

[ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
using dummy regulator
[ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
using dummy regulator
[ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
found: using identity...

Is this a problem?

Thanks again.

Darrell


On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Sun, 29 Jan 2023 17:03:51 +0000
> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>
> > Hi,
> >
> > I raised this bug in Debian, and have been asked to raise it upstream and
> > was given your addresses to do so. Will this email be OK, or should I raise
> > it in a bug tracking system somewhere?
>
> Email is the right option.
>
> >
> > Many thanks,
> > Darrell
> >
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: Salvatore Bonaccorso <carnil@debian.org>
> > Date: Sat, 28 Jan 2023 at 20:33
> > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> >
> >
> > Hi Darrell,
> >
> > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > Package: src:linux
> > > Version: 6.1.4-1
> > > Severity: normal
> > > File: linux
> > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > >
> > > Dear Maintainer,
> > >
> > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > device
> > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > and the
> > > sysfs trees are created at
> > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > but
> > > no driver is loaded.
>
> At least this is using the ST PNP ID which is better than average
> (long story!)
>
> The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> does not currently have an ACPI support.  It should be straight forwards
> to add though the driver first needs converting to use
> device_get_match_data() with appropriate fallback so that it will match on
> ACPI, OF or original spi_device_id tables
>
> Completely untested but something like the following
> (the offset in the enum is needed to allow us to tell if we got a result when
> calling device_get_match_data() as it returns NULL on failure IIRC)
>
> I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> it may get you basic functionality.
>
> Good luck and others more familiar with the driver may well tell me what I forgot
> when hacking the below ;)
>
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> index 499fcf8875b4..2617ce236ddc 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> @@ -39,7 +39,7 @@
>  #define ST_ISM330IS_DEV_NAME   "ism330is"
>
>  enum st_lsm6dsx_hw_id {
> -       ST_LSM6DS3_ID,
> +       ST_LSM6DS3_ID = 1,
>         ST_LSM6DS3H_ID,
>         ST_LSM6DSL_ID,
>         ST_LSM6DSM_ID,
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> index df5f60925260..ecfceb2fb3db 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
>
>  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
>  {
> -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> -       int hw_id = id->driver_data;
> +       int hw_id;
>         struct regmap *regmap;
>
> +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> +       if (!hw_id)
> +               hw_id = i2c_client_get_device_id(client)->driver_data;
> +       if (!hw_id)
> +               return -EINVAL;
> +
>         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
>         if (IS_ERR(regmap)) {
>                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
>
> +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> +};
> +
>  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
>         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
>         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
>                 .name = "st_lsm6dsx_i2c",
>                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
>                 .of_match_table = st_lsm6dsx_i2c_of_match,
> +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
>         },
>         .probe_new = st_lsm6dsx_i2c_probe,
>         .id_table = st_lsm6dsx_i2c_id_table,
>
>
> > >
> > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > physical_node:
> > >       modalias=acpi:SMO8B30:SMO8B30:
> > >       name=SMO8B30:00
> > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > >       waiting_for_supplier=0
> > > firmware_node:
> > >       hid=SMO8B30
> > >       modalias=acpi:SMO8B30:SMO8B30:
> > >       path=\_SB_.PCI0.I2C5.DEV_
> > >       status=15
> > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > >       uid=0
> > >
> > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > loaded on boot.
> > > Modprobing it does not associate it with the device, as I would expect as
> > > the module does not provide an alias for the above acpi/pnp id.
> >
> > Can you report this issue upstream? Gues to reach out are according to
> > get_maintainers.pl script:
> >
> > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > linux-kernel@vger.kernel.org (open list)
> >
> > Please keep us in the loop.
> >
> > Regards,
> > Salvatore
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30  3:37         ` Fwd: " Darrell Kavanagh
@ 2023-01-30 12:31           ` Jonathan Cameron
  2023-01-30 13:08             ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-01-30 12:31 UTC (permalink / raw)
  To: Darrell Kavanagh; +Cc: linux-iio, linux-kernel

On Mon, 30 Jan 2023 03:37:23 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> Forwarding because original html messages were rejected by the server...
> 
> ---------- Forwarded message ---------
> From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> Date: Mon, 30 Jan 2023 at 02:52
> Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> To: Jonathan Cameron <jic23@kernel.org>
> Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> <carnil@debian.org>
> 
> 
> Hi Jonathan,
> 
> Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> that 6.2 includes some i2c enhancements), but I adapted your changes
> to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> in sysfs, iio-sensor-proxy.service starts up and automatic screen
> rotation in Gnome just works.
> 
> To get the modules to load on boot, I made a small change to your code
> in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> 
> adding a null element to st_lsm6dsx_i2c_acpi_match:
>     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>          { "SMO8B30", ST_LSM6DS3TRC_ID, },
>          { },
>     };
> then:
>    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);

doh! That was indeed sloppy of me to miss even for an untested hack.



> 
> 
> dmesg shows:
> 
> [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> using dummy regulator
> [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> using dummy regulator
> [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> found: using identity...
> 
> Is this a problem?

Those are all fine. For regulators that's expected on ACPI and should
be harmless as it's up to the firmware to manage power (in DT it may
be up to the kernel).
For the mounting matrix, there is often something in ACPI DSDT
(non standard though).  Could you
cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
then run through iasl from acpitools
iasl -d ~/dsdt
and find the bit related to this device.

If you can then share that there may be a _DSM or similar in there that
is effectively the mounting matrix.  If we are lucky it will look like
some existing versions we have code to handle and can add that support
as well.

Either way - I'll spin a formal patch with your fixes above and we can
get this upstream for future kernels.  Mounting matrix can follow
later if needed.

Thanks,

Jonathan


> 
> Thanks again.
> 
> Darrell
> 
> 
> On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sun, 29 Jan 2023 17:03:51 +0000
> > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >  
> > > Hi,
> > >
> > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > was given your addresses to do so. Will this email be OK, or should I raise
> > > it in a bug tracking system somewhere?  
> >
> > Email is the right option.
> >  
> > >
> > > Many thanks,
> > > Darrell
> > >
> > >
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > Date: Sat, 28 Jan 2023 at 20:33
> > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > >
> > >
> > > Hi Darrell,
> > >
> > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
> > > > Package: src:linux
> > > > Version: 6.1.4-1
> > > > Severity: normal
> > > > File: linux
> > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > >
> > > > Dear Maintainer,
> > > >
> > > > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> > > device  
> > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> > > and the  
> > > > sysfs trees are created at  
> > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
> > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> > > but  
> > > > no driver is loaded.  
> >
> > At least this is using the ST PNP ID which is better than average
> > (long story!)
> >
> > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > does not currently have an ACPI support.  It should be straight forwards
> > to add though the driver first needs converting to use
> > device_get_match_data() with appropriate fallback so that it will match on
> > ACPI, OF or original spi_device_id tables
> >
> > Completely untested but something like the following
> > (the offset in the enum is needed to allow us to tell if we got a result when
> > calling device_get_match_data() as it returns NULL on failure IIRC)
> >
> > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > it may get you basic functionality.
> >
> > Good luck and others more familiar with the driver may well tell me what I forgot
> > when hacking the below ;)
> >
> > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > index 499fcf8875b4..2617ce236ddc 100644
> > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > @@ -39,7 +39,7 @@
> >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> >
> >  enum st_lsm6dsx_hw_id {
> > -       ST_LSM6DS3_ID,
> > +       ST_LSM6DS3_ID = 1,
> >         ST_LSM6DS3H_ID,
> >         ST_LSM6DSL_ID,
> >         ST_LSM6DSM_ID,
> > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > index df5f60925260..ecfceb2fb3db 100644
> > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> >
> >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> >  {
> > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > -       int hw_id = id->driver_data;
> > +       int hw_id;
> >         struct regmap *regmap;
> >
> > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > +       if (!hw_id)
> > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > +       if (!hw_id)
> > +               return -EINVAL;
> > +
> >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> >         if (IS_ERR(regmap)) {
> >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> >  };
> >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> >
> > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > +};
> > +
> >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> >                 .name = "st_lsm6dsx_i2c",
> >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> >         },
> >         .probe_new = st_lsm6dsx_i2c_probe,
> >         .id_table = st_lsm6dsx_i2c_id_table,
> >
> >  
> > > >
> > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > physical_node:
> > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > >       name=SMO8B30:00
> > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > >       waiting_for_supplier=0
> > > > firmware_node:
> > > >       hid=SMO8B30
> > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > >       status=15
> > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > >       uid=0
> > > >
> > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> > > loaded on boot.  
> > > > Modprobing it does not associate it with the device, as I would expect as
> > > > the module does not provide an alias for the above acpi/pnp id.  
> > >
> > > Can you report this issue upstream? Gues to reach out are according to
> > > get_maintainers.pl script:
> > >
> > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > linux-kernel@vger.kernel.org (open list)
> > >
> > > Please keep us in the loop.
> > >
> > > Regards,
> > > Salvatore  
> >  


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 12:31           ` Jonathan Cameron
@ 2023-01-30 13:08             ` Darrell Kavanagh
  2023-01-30 17:35               ` Jonathan Cameron
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-01-30 13:08 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: linux-iio, linux-kernel

Here is what I hope is the relevant section from the DSDT:

    Scope (_SB.PCI0.I2C5)
    {
        Device (DEV)
        {
            Name (_HID, EisaId ("SMO8B30"))  // _HID: Hardware ID
            Name (_CID, EisaId ("SMO8B30"))  // _CID: Compatible ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x006A, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PCI0.I2C5",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_._CRS.RBUF */
            }

            Method (ROTM, 0, NotSerialized)
            {
                Name (RBUF, Package (0x03)
                {
                    "0 -1 0",
                    "1 0 0",
                    "0 0 1"
                })
                Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.ROTM.RBUF */
            }

            Method (PRIM, 0, NotSerialized)
            {
                Name (RBUF, Buffer (One)
                {
                     0x01                                             // .
                })
                Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((GAVT == 0x6A))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }

            Method (CALS, 1, NotSerialized)
            {
                Local0 = Arg0
                If (((Local0 == Zero) || (Local0 == Ones)))
                {
                    Local0 = BAC1 /* \BAC1 */
                    Return (Local0)
                }
                Else
                {
                    BAC1 = Local0
                    BACS = Local0
                    BSCA (0xB0)
                }
            }
        }
    }


Thanks,
Darrell

On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Mon, 30 Jan 2023 03:37:23 +0000
> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>
> > Forwarding because original html messages were rejected by the server...
> >
> > ---------- Forwarded message ---------
> > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > Date: Mon, 30 Jan 2023 at 02:52
> > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > To: Jonathan Cameron <jic23@kernel.org>
> > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > <carnil@debian.org>
> >
> >
> > Hi Jonathan,
> >
> > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > that 6.2 includes some i2c enhancements), but I adapted your changes
> > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > rotation in Gnome just works.
> >
> > To get the modules to load on boot, I made a small change to your code
> > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> >
> > adding a null element to st_lsm6dsx_i2c_acpi_match:
> >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> >          { },
> >     };
> > then:
> >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
>
> doh! That was indeed sloppy of me to miss even for an untested hack.
>
>
>
> >
> >
> > dmesg shows:
> >
> > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > using dummy regulator
> > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > using dummy regulator
> > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > found: using identity...
> >
> > Is this a problem?
>
> Those are all fine. For regulators that's expected on ACPI and should
> be harmless as it's up to the firmware to manage power (in DT it may
> be up to the kernel).
> For the mounting matrix, there is often something in ACPI DSDT
> (non standard though).  Could you
> cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> then run through iasl from acpitools
> iasl -d ~/dsdt
> and find the bit related to this device.
>
> If you can then share that there may be a _DSM or similar in there that
> is effectively the mounting matrix.  If we are lucky it will look like
> some existing versions we have code to handle and can add that support
> as well.
>
> Either way - I'll spin a formal patch with your fixes above and we can
> get this upstream for future kernels.  Mounting matrix can follow
> later if needed.
>
> Thanks,
>
> Jonathan
>
>
> >
> > Thanks again.
> >
> > Darrell
> >
> >
> > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> > >
> > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > it in a bug tracking system somewhere?
> > >
> > > Email is the right option.
> > >
> > > >
> > > > Many thanks,
> > > > Darrell
> > > >
> > > >
> > > >
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > >
> > > >
> > > > Hi Darrell,
> > > >
> > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > > > Package: src:linux
> > > > > Version: 6.1.4-1
> > > > > Severity: normal
> > > > > File: linux
> > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > >
> > > > > Dear Maintainer,
> > > > >
> > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > > > device
> > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > > > and the
> > > > > sysfs trees are created at
> > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > > > but
> > > > > no driver is loaded.
> > >
> > > At least this is using the ST PNP ID which is better than average
> > > (long story!)
> > >
> > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > does not currently have an ACPI support.  It should be straight forwards
> > > to add though the driver first needs converting to use
> > > device_get_match_data() with appropriate fallback so that it will match on
> > > ACPI, OF or original spi_device_id tables
> > >
> > > Completely untested but something like the following
> > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > >
> > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > it may get you basic functionality.
> > >
> > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > when hacking the below ;)
> > >
> > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > index 499fcf8875b4..2617ce236ddc 100644
> > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > @@ -39,7 +39,7 @@
> > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > >
> > >  enum st_lsm6dsx_hw_id {
> > > -       ST_LSM6DS3_ID,
> > > +       ST_LSM6DS3_ID = 1,
> > >         ST_LSM6DS3H_ID,
> > >         ST_LSM6DSL_ID,
> > >         ST_LSM6DSM_ID,
> > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > index df5f60925260..ecfceb2fb3db 100644
> > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > >
> > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > >  {
> > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > -       int hw_id = id->driver_data;
> > > +       int hw_id;
> > >         struct regmap *regmap;
> > >
> > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > +       if (!hw_id)
> > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > +       if (!hw_id)
> > > +               return -EINVAL;
> > > +
> > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > >         if (IS_ERR(regmap)) {
> > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > >  };
> > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > >
> > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > +};
> > > +
> > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > >                 .name = "st_lsm6dsx_i2c",
> > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > >         },
> > >         .probe_new = st_lsm6dsx_i2c_probe,
> > >         .id_table = st_lsm6dsx_i2c_id_table,
> > >
> > >
> > > > >
> > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > physical_node:
> > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > >       name=SMO8B30:00
> > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > >       waiting_for_supplier=0
> > > > > firmware_node:
> > > > >       hid=SMO8B30
> > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > >       status=15
> > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > >       uid=0
> > > > >
> > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > > > loaded on boot.
> > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > the module does not provide an alias for the above acpi/pnp id.
> > > >
> > > > Can you report this issue upstream? Gues to reach out are according to
> > > > get_maintainers.pl script:
> > > >
> > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > linux-kernel@vger.kernel.org (open list)
> > > >
> > > > Please keep us in the loop.
> > > >
> > > > Regards,
> > > > Salvatore
> > >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 13:08             ` Darrell Kavanagh
@ 2023-01-30 17:35               ` Jonathan Cameron
  2023-01-30 18:32                 ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-01-30 17:35 UTC (permalink / raw)
  To: Darrell Kavanagh; +Cc: linux-iio, linux-kernel

On Mon, 30 Jan 2023 13:08:47 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> Here is what I hope is the relevant section from the DSDT:
> 
>     Scope (_SB.PCI0.I2C5)
>     {
>         Device (DEV)
>         {
>             Name (_HID, EisaId ("SMO8B30"))  // _HID: Hardware ID
>             Name (_CID, EisaId ("SMO8B30"))  // _CID: Compatible ID
>             Name (_UID, Zero)  // _UID: Unique ID
>             Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>             {
>                 Name (RBUF, ResourceTemplate ()
>                 {
>                     I2cSerialBusV2 (0x006A, ControllerInitiated, 0x00061A80,
>                         AddressingMode7Bit, "\\_SB.PCI0.I2C5",
>                         0x00, ResourceConsumer, , Exclusive,
>                         )
>                 })
>                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_._CRS.RBUF */
>             }
> 
>             Method (ROTM, 0, NotSerialized)
>             {
>                 Name (RBUF, Package (0x03)
>                 {
>                     "0 -1 0",
>                     "1 0 0",
>                     "0 0 1"
>                 })
>                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.ROTM.RBUF */

That certainly looks like suitable matrix.

If we are lucky it matches the handling in bmc150-accel-core.c for an identically
named method.  That is going to swap the x and y axis which is I'd have thought would
be rather bad if what you have is currently working well.

>             }
> 
>             Method (PRIM, 0, NotSerialized)
>             {
>                 Name (RBUF, Buffer (One)
>                 {
>                      0x01                                             // .
>                 })
>                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
>             }
> 
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 If ((GAVT == 0x6A))
>                 {
>                     Return (0x0F)
>                 }
>                 Else
>                 {
>                     Return (Zero)
>                 }
>             }
> 
>             Method (CALS, 1, NotSerialized)
>             {
>                 Local0 = Arg0
>                 If (((Local0 == Zero) || (Local0 == Ones)))
>                 {
>                     Local0 = BAC1 /* \BAC1 */
>                     Return (Local0)
>                 }
>                 Else
>                 {
>                     BAC1 = Local0
>                     BACS = Local0
>                     BSCA (0xB0)
>                 }
>             }
>         }
>     }
> 
> 
> Thanks,
> Darrell
> 
> On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Mon, 30 Jan 2023 03:37:23 +0000
> > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >  
> > > Forwarding because original html messages were rejected by the server...
> > >
> > > ---------- Forwarded message ---------
> > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > Date: Mon, 30 Jan 2023 at 02:52
> > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > To: Jonathan Cameron <jic23@kernel.org>
> > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > <carnil@debian.org>
> > >
> > >
> > > Hi Jonathan,
> > >
> > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > rotation in Gnome just works.
> > >
> > > To get the modules to load on boot, I made a small change to your code
> > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > >
> > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > >          { },
> > >     };
> > > then:
> > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);  
> >
> > doh! That was indeed sloppy of me to miss even for an untested hack.
> >
> >
> >  
> > >
> > >
> > > dmesg shows:
> > >
> > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > using dummy regulator
> > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > using dummy regulator
> > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > found: using identity...
> > >
> > > Is this a problem?  
> >
> > Those are all fine. For regulators that's expected on ACPI and should
> > be harmless as it's up to the firmware to manage power (in DT it may
> > be up to the kernel).
> > For the mounting matrix, there is often something in ACPI DSDT
> > (non standard though).  Could you
> > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > then run through iasl from acpitools
> > iasl -d ~/dsdt
> > and find the bit related to this device.
> >
> > If you can then share that there may be a _DSM or similar in there that
> > is effectively the mounting matrix.  If we are lucky it will look like
> > some existing versions we have code to handle and can add that support
> > as well.
> >
> > Either way - I'll spin a formal patch with your fixes above and we can
> > get this upstream for future kernels.  Mounting matrix can follow
> > later if needed.
> >
> > Thanks,
> >
> > Jonathan
> >
> >  
> > >
> > > Thanks again.
> > >
> > > Darrell
> > >
> > >
> > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > >
> > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > >  
> > > > > Hi,
> > > > >
> > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > it in a bug tracking system somewhere?  
> > > >
> > > > Email is the right option.
> > > >  
> > > > >
> > > > > Many thanks,
> > > > > Darrell
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------- Forwarded message ---------
> > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > >
> > > > >
> > > > > Hi Darrell,
> > > > >
> > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
> > > > > > Package: src:linux
> > > > > > Version: 6.1.4-1
> > > > > > Severity: normal
> > > > > > File: linux
> > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > >
> > > > > > Dear Maintainer,
> > > > > >
> > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> > > > > device  
> > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> > > > > and the  
> > > > > > sysfs trees are created at  
> > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
> > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> > > > > but  
> > > > > > no driver is loaded.  
> > > >
> > > > At least this is using the ST PNP ID which is better than average
> > > > (long story!)
> > > >
> > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > does not currently have an ACPI support.  It should be straight forwards
> > > > to add though the driver first needs converting to use
> > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > ACPI, OF or original spi_device_id tables
> > > >
> > > > Completely untested but something like the following
> > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > >
> > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > it may get you basic functionality.
> > > >
> > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > when hacking the below ;)
> > > >
> > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > @@ -39,7 +39,7 @@
> > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > >
> > > >  enum st_lsm6dsx_hw_id {
> > > > -       ST_LSM6DS3_ID,
> > > > +       ST_LSM6DS3_ID = 1,
> > > >         ST_LSM6DS3H_ID,
> > > >         ST_LSM6DSL_ID,
> > > >         ST_LSM6DSM_ID,
> > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > index df5f60925260..ecfceb2fb3db 100644
> > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > >
> > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > >  {
> > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > -       int hw_id = id->driver_data;
> > > > +       int hw_id;
> > > >         struct regmap *regmap;
> > > >
> > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > +       if (!hw_id)
> > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > +       if (!hw_id)
> > > > +               return -EINVAL;
> > > > +
> > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > >         if (IS_ERR(regmap)) {
> > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > >  };
> > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > >
> > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > +};
> > > > +
> > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > >                 .name = "st_lsm6dsx_i2c",
> > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > >         },
> > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > >
> > > >  
> > > > > >
> > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > physical_node:
> > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > >       name=SMO8B30:00
> > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > >       waiting_for_supplier=0
> > > > > > firmware_node:
> > > > > >       hid=SMO8B30
> > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > >       status=15
> > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > >       uid=0
> > > > > >
> > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> > > > > loaded on boot.  
> > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > the module does not provide an alias for the above acpi/pnp id.  
> > > > >
> > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > get_maintainers.pl script:
> > > > >
> > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > linux-kernel@vger.kernel.org (open list)
> > > > >
> > > > > Please keep us in the loop.
> > > > >
> > > > > Regards,
> > > > > Salvatore  
> > > >  
> >  


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 17:35               ` Jonathan Cameron
@ 2023-01-30 18:32                 ` Darrell Kavanagh
  2023-01-30 19:41                   ` Jonathan Cameron
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-01-30 18:32 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: linux-iio, linux-kernel

On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:

> That certainly looks like suitable matrix.
>
> If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> named method.  That is going to swap the x and y axis which is I'd have thought would
> be rather bad if what you have is currently working well.
>

Actually, that would be good, because at present I have to rotate 90
degrees in my grub command line.

Darrell

> >             }
> >
> >             Method (PRIM, 0, NotSerialized)
> >             {
> >                 Name (RBUF, Buffer (One)
> >                 {
> >                      0x01                                             // .
> >                 })
> >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> >             }
> >
> >             Method (_STA, 0, NotSerialized)  // _STA: Status
> >             {
> >                 If ((GAVT == 0x6A))
> >                 {
> >                     Return (0x0F)
> >                 }
> >                 Else
> >                 {
> >                     Return (Zero)
> >                 }
> >             }
> >
> >             Method (CALS, 1, NotSerialized)
> >             {
> >                 Local0 = Arg0
> >                 If (((Local0 == Zero) || (Local0 == Ones)))
> >                 {
> >                     Local0 = BAC1 /* \BAC1 */
> >                     Return (Local0)
> >                 }
> >                 Else
> >                 {
> >                     BAC1 = Local0
> >                     BACS = Local0
> >                     BSCA (0xB0)
> >                 }
> >             }
> >         }
> >     }
> >
> >
> > Thanks,
> > Darrell
> >
> > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >
> > > > Forwarding because original html messages were rejected by the server...
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > <carnil@debian.org>
> > > >
> > > >
> > > > Hi Jonathan,
> > > >
> > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > rotation in Gnome just works.
> > > >
> > > > To get the modules to load on boot, I made a small change to your code
> > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > >
> > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > >          { },
> > > >     };
> > > > then:
> > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
> > >
> > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > >
> > >
> > >
> > > >
> > > >
> > > > dmesg shows:
> > > >
> > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > using dummy regulator
> > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > using dummy regulator
> > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > found: using identity...
> > > >
> > > > Is this a problem?
> > >
> > > Those are all fine. For regulators that's expected on ACPI and should
> > > be harmless as it's up to the firmware to manage power (in DT it may
> > > be up to the kernel).
> > > For the mounting matrix, there is often something in ACPI DSDT
> > > (non standard though).  Could you
> > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > then run through iasl from acpitools
> > > iasl -d ~/dsdt
> > > and find the bit related to this device.
> > >
> > > If you can then share that there may be a _DSM or similar in there that
> > > is effectively the mounting matrix.  If we are lucky it will look like
> > > some existing versions we have code to handle and can add that support
> > > as well.
> > >
> > > Either way - I'll spin a formal patch with your fixes above and we can
> > > get this upstream for future kernels.  Mounting matrix can follow
> > > later if needed.
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > >
> > > >
> > > > Thanks again.
> > > >
> > > > Darrell
> > > >
> > > >
> > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> > > > >
> > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > it in a bug tracking system somewhere?
> > > > >
> > > > > Email is the right option.
> > > > >
> > > > > >
> > > > > > Many thanks,
> > > > > > Darrell
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ---------- Forwarded message ---------
> > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > >
> > > > > >
> > > > > > Hi Darrell,
> > > > > >
> > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > > > > > Package: src:linux
> > > > > > > Version: 6.1.4-1
> > > > > > > Severity: normal
> > > > > > > File: linux
> > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > >
> > > > > > > Dear Maintainer,
> > > > > > >
> > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > > > > > device
> > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > > > > > and the
> > > > > > > sysfs trees are created at
> > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > > > > > but
> > > > > > > no driver is loaded.
> > > > >
> > > > > At least this is using the ST PNP ID which is better than average
> > > > > (long story!)
> > > > >
> > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > to add though the driver first needs converting to use
> > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > ACPI, OF or original spi_device_id tables
> > > > >
> > > > > Completely untested but something like the following
> > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > >
> > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > it may get you basic functionality.
> > > > >
> > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > when hacking the below ;)
> > > > >
> > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > @@ -39,7 +39,7 @@
> > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > >
> > > > >  enum st_lsm6dsx_hw_id {
> > > > > -       ST_LSM6DS3_ID,
> > > > > +       ST_LSM6DS3_ID = 1,
> > > > >         ST_LSM6DS3H_ID,
> > > > >         ST_LSM6DSL_ID,
> > > > >         ST_LSM6DSM_ID,
> > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > >
> > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > >  {
> > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > -       int hw_id = id->driver_data;
> > > > > +       int hw_id;
> > > > >         struct regmap *regmap;
> > > > >
> > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > +       if (!hw_id)
> > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > +       if (!hw_id)
> > > > > +               return -EINVAL;
> > > > > +
> > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > >         if (IS_ERR(regmap)) {
> > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > >  };
> > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > >
> > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > +};
> > > > > +
> > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > >                 .name = "st_lsm6dsx_i2c",
> > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > >         },
> > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > >
> > > > >
> > > > > > >
> > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > physical_node:
> > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > >       name=SMO8B30:00
> > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > >       waiting_for_supplier=0
> > > > > > > firmware_node:
> > > > > > >       hid=SMO8B30
> > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > >       status=15
> > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > >       uid=0
> > > > > > >
> > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > > > > > loaded on boot.
> > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > the module does not provide an alias for the above acpi/pnp id.
> > > > > >
> > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > get_maintainers.pl script:
> > > > > >
> > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > >
> > > > > > Please keep us in the loop.
> > > > > >
> > > > > > Regards,
> > > > > > Salvatore
> > > > >
> > >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 18:32                 ` Darrell Kavanagh
@ 2023-01-30 19:41                   ` Jonathan Cameron
  2023-01-30 20:02                     ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-01-30 19:41 UTC (permalink / raw)
  To: Darrell Kavanagh; +Cc: Jonathan Cameron, linux-iio, linux-kernel

On Mon, 30 Jan 2023 18:32:02 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> 
> > That certainly looks like suitable matrix.
> >
> > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > named method.  That is going to swap the x and y axis which is I'd have thought would
> > be rather bad if what you have is currently working well.
> >  
> 
> Actually, that would be good, because at present I have to rotate 90
> degrees in my grub command line.
:)

I'll see if I can roll a suitable patch.

Jonathan

> 
> Darrell
> 
> > >             }
> > >
> > >             Method (PRIM, 0, NotSerialized)
> > >             {
> > >                 Name (RBUF, Buffer (One)
> > >                 {
> > >                      0x01                                             // .
> > >                 })
> > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > >             }
> > >
> > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > >             {
> > >                 If ((GAVT == 0x6A))
> > >                 {
> > >                     Return (0x0F)
> > >                 }
> > >                 Else
> > >                 {
> > >                     Return (Zero)
> > >                 }
> > >             }
> > >
> > >             Method (CALS, 1, NotSerialized)
> > >             {
> > >                 Local0 = Arg0
> > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > >                 {
> > >                     Local0 = BAC1 /* \BAC1 */
> > >                     Return (Local0)
> > >                 }
> > >                 Else
> > >                 {
> > >                     BAC1 = Local0
> > >                     BACS = Local0
> > >                     BSCA (0xB0)
> > >                 }
> > >             }
> > >         }
> > >     }
> > >
> > >
> > > Thanks,
> > > Darrell
> > >
> > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:  
> > > >
> > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > >  
> > > > > Forwarding because original html messages were rejected by the server...
> > > > >
> > > > > ---------- Forwarded message ---------
> > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > <carnil@debian.org>
> > > > >
> > > > >
> > > > > Hi Jonathan,
> > > > >
> > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > rotation in Gnome just works.
> > > > >
> > > > > To get the modules to load on boot, I made a small change to your code
> > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > >
> > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > >          { },
> > > > >     };
> > > > > then:
> > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);  
> > > >
> > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > >
> > > >
> > > >  
> > > > >
> > > > >
> > > > > dmesg shows:
> > > > >
> > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > using dummy regulator
> > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > using dummy regulator
> > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > found: using identity...
> > > > >
> > > > > Is this a problem?  
> > > >
> > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > be up to the kernel).
> > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > (non standard though).  Could you
> > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > then run through iasl from acpitools
> > > > iasl -d ~/dsdt
> > > > and find the bit related to this device.
> > > >
> > > > If you can then share that there may be a _DSM or similar in there that
> > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > some existing versions we have code to handle and can add that support
> > > > as well.
> > > >
> > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > later if needed.
> > > >
> > > > Thanks,
> > > >
> > > > Jonathan
> > > >
> > > >  
> > > > >
> > > > > Thanks again.
> > > > >
> > > > > Darrell
> > > > >
> > > > >
> > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > > >
> > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > >  
> > > > > > > Hi,
> > > > > > >
> > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > it in a bug tracking system somewhere?  
> > > > > >
> > > > > > Email is the right option.
> > > > > >  
> > > > > > >
> > > > > > > Many thanks,
> > > > > > > Darrell
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ---------- Forwarded message ---------
> > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > >
> > > > > > >
> > > > > > > Hi Darrell,
> > > > > > >
> > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
> > > > > > > > Package: src:linux
> > > > > > > > Version: 6.1.4-1
> > > > > > > > Severity: normal
> > > > > > > > File: linux
> > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > >
> > > > > > > > Dear Maintainer,
> > > > > > > >
> > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> > > > > > > device  
> > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> > > > > > > and the  
> > > > > > > > sysfs trees are created at  
> > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
> > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> > > > > > > but  
> > > > > > > > no driver is loaded.  
> > > > > >
> > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > (long story!)
> > > > > >
> > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > to add though the driver first needs converting to use
> > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > ACPI, OF or original spi_device_id tables
> > > > > >
> > > > > > Completely untested but something like the following
> > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > >
> > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > it may get you basic functionality.
> > > > > >
> > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > when hacking the below ;)
> > > > > >
> > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > @@ -39,7 +39,7 @@
> > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > >
> > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > -       ST_LSM6DS3_ID,
> > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > >         ST_LSM6DS3H_ID,
> > > > > >         ST_LSM6DSL_ID,
> > > > > >         ST_LSM6DSM_ID,
> > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > >
> > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > >  {
> > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > -       int hw_id = id->driver_data;
> > > > > > +       int hw_id;
> > > > > >         struct regmap *regmap;
> > > > > >
> > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > +       if (!hw_id)
> > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > +       if (!hw_id)
> > > > > > +               return -EINVAL;
> > > > > > +
> > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > >         if (IS_ERR(regmap)) {
> > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > >  };
> > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > >
> > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > +};
> > > > > > +
> > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > >         },
> > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > >
> > > > > >  
> > > > > > > >
> > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > physical_node:
> > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > >       name=SMO8B30:00
> > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > >       waiting_for_supplier=0
> > > > > > > > firmware_node:
> > > > > > > >       hid=SMO8B30
> > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > >       status=15
> > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > >       uid=0
> > > > > > > >
> > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> > > > > > > loaded on boot.  
> > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > the module does not provide an alias for the above acpi/pnp id.  
> > > > > > >
> > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > get_maintainers.pl script:
> > > > > > >
> > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > >
> > > > > > > Please keep us in the loop.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Salvatore  
> > > > > >  
> > > >  
> >  


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 19:41                   ` Jonathan Cameron
@ 2023-01-30 20:02                     ` Darrell Kavanagh
  2023-01-30 20:31                       ` Jonathan Cameron
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-01-30 20:02 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio, linux-kernel

Thanks. To be clear, before I changed the grub command line, the
system always booted up "sideways", even when the sensor was not being
detected. This was true for everything, not just Gnome, except grub
itself.

I added:

GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
video=DSI-1:panel_orientation=right_side_up quiet splash"

This fixed the orientation for pre-splash boot messages, the splash
screen and the desktop environment. But not, for example (as I saw
after adding my own module signing key for testing your fixes), the
MOK validation screens.

Does this make sense?

Does what you are proposing act at a lower level than changing the
systemd hwdb orientation matrix?

Thanks,
Darrell

On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Mon, 30 Jan 2023 18:32:02 +0000
> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>
> > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> >
> > > That certainly looks like suitable matrix.
> > >
> > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > be rather bad if what you have is currently working well.
> > >
> >
> > Actually, that would be good, because at present I have to rotate 90
> > degrees in my grub command line.
> :)
>
> I'll see if I can roll a suitable patch.
>
> Jonathan
>
> >
> > Darrell
> >
> > > >             }
> > > >
> > > >             Method (PRIM, 0, NotSerialized)
> > > >             {
> > > >                 Name (RBUF, Buffer (One)
> > > >                 {
> > > >                      0x01                                             // .
> > > >                 })
> > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > >             }
> > > >
> > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > >             {
> > > >                 If ((GAVT == 0x6A))
> > > >                 {
> > > >                     Return (0x0F)
> > > >                 }
> > > >                 Else
> > > >                 {
> > > >                     Return (Zero)
> > > >                 }
> > > >             }
> > > >
> > > >             Method (CALS, 1, NotSerialized)
> > > >             {
> > > >                 Local0 = Arg0
> > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > >                 {
> > > >                     Local0 = BAC1 /* \BAC1 */
> > > >                     Return (Local0)
> > > >                 }
> > > >                 Else
> > > >                 {
> > > >                     BAC1 = Local0
> > > >                     BACS = Local0
> > > >                     BSCA (0xB0)
> > > >                 }
> > > >             }
> > > >         }
> > > >     }
> > > >
> > > >
> > > > Thanks,
> > > > Darrell
> > > >
> > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > >
> > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > >
> > > > > > Forwarding because original html messages were rejected by the server...
> > > > > >
> > > > > > ---------- Forwarded message ---------
> > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > <carnil@debian.org>
> > > > > >
> > > > > >
> > > > > > Hi Jonathan,
> > > > > >
> > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > rotation in Gnome just works.
> > > > > >
> > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > >
> > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > >          { },
> > > > > >     };
> > > > > > then:
> > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
> > > > >
> > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > dmesg shows:
> > > > > >
> > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > using dummy regulator
> > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > using dummy regulator
> > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > found: using identity...
> > > > > >
> > > > > > Is this a problem?
> > > > >
> > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > be up to the kernel).
> > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > (non standard though).  Could you
> > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > then run through iasl from acpitools
> > > > > iasl -d ~/dsdt
> > > > > and find the bit related to this device.
> > > > >
> > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > some existing versions we have code to handle and can add that support
> > > > > as well.
> > > > >
> > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > later if needed.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jonathan
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks again.
> > > > > >
> > > > > > Darrell
> > > > > >
> > > > > >
> > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> > > > > > >
> > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > it in a bug tracking system somewhere?
> > > > > > >
> > > > > > > Email is the right option.
> > > > > > >
> > > > > > > >
> > > > > > > > Many thanks,
> > > > > > > > Darrell
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------- Forwarded message ---------
> > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Darrell,
> > > > > > > >
> > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > > > > > > > Package: src:linux
> > > > > > > > > Version: 6.1.4-1
> > > > > > > > > Severity: normal
> > > > > > > > > File: linux
> > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > >
> > > > > > > > > Dear Maintainer,
> > > > > > > > >
> > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > > > > > > > device
> > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > > > > > > > and the
> > > > > > > > > sysfs trees are created at
> > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > > > > > > > but
> > > > > > > > > no driver is loaded.
> > > > > > >
> > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > (long story!)
> > > > > > >
> > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > to add though the driver first needs converting to use
> > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > >
> > > > > > > Completely untested but something like the following
> > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > >
> > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > it may get you basic functionality.
> > > > > > >
> > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > when hacking the below ;)
> > > > > > >
> > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > @@ -39,7 +39,7 @@
> > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > >
> > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > >         ST_LSM6DS3H_ID,
> > > > > > >         ST_LSM6DSL_ID,
> > > > > > >         ST_LSM6DSM_ID,
> > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > >
> > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > >  {
> > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > -       int hw_id = id->driver_data;
> > > > > > > +       int hw_id;
> > > > > > >         struct regmap *regmap;
> > > > > > >
> > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > +       if (!hw_id)
> > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > +       if (!hw_id)
> > > > > > > +               return -EINVAL;
> > > > > > > +
> > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > >         if (IS_ERR(regmap)) {
> > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > >  };
> > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > >
> > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > +};
> > > > > > > +
> > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > >         },
> > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > physical_node:
> > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > >       name=SMO8B30:00
> > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > firmware_node:
> > > > > > > > >       hid=SMO8B30
> > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > >       status=15
> > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > >       uid=0
> > > > > > > > >
> > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > > > > > > > loaded on boot.
> > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > the module does not provide an alias for the above acpi/pnp id.
> > > > > > > >
> > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > get_maintainers.pl script:
> > > > > > > >
> > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > >
> > > > > > > > Please keep us in the loop.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Salvatore
> > > > > > >
> > > > >
> > >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 20:02                     ` Darrell Kavanagh
@ 2023-01-30 20:31                       ` Jonathan Cameron
  2023-01-31 13:34                         ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-01-30 20:31 UTC (permalink / raw)
  To: Darrell Kavanagh
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera

On Mon, 30 Jan 2023 20:02:31 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> Thanks. To be clear, before I changed the grub command line, the
> system always booted up "sideways", even when the sensor was not being
> detected. This was true for everything, not just Gnome, except grub
> itself.
> 
> I added:
> 
> GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> video=DSI-1:panel_orientation=right_side_up quiet splash"
> 
> This fixed the orientation for pre-splash boot messages, the splash
> screen and the desktop environment. But not, for example (as I saw
> after adding my own module signing key for testing your fixes), the
> MOK validation screens.
> 
> Does this make sense?
> 
> Does what you are proposing act at a lower level than changing the
> systemd hwdb orientation matrix?

I'm not sure on the userspace side of things, but intent is that
it will provide the orientation data to any users - though only after
the kernel boots and software needs to be aware of it.  Give it a go,
and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.

For Bastien - patches for kernel side are: 
https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t

Darrell is going to test them after back porting to 6.1.
With the first patch he gets the right result in gnome but we weren't
picking up the rotation matrix at that point (ROTM in ACPI).

Thanks,

Jonathan

> 
> Thanks,
> Darrell
> 
> On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Mon, 30 Jan 2023 18:32:02 +0000
> > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >  
> > > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > > <Jonathan.Cameron@huawei.com> wrote:
> > >  
> > > > That certainly looks like suitable matrix.
> > > >
> > > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > > be rather bad if what you have is currently working well.
> > > >  
> > >
> > > Actually, that would be good, because at present I have to rotate 90
> > > degrees in my grub command line.  
> > :)
> >
> > I'll see if I can roll a suitable patch.
> >
> > Jonathan
> >  
> > >
> > > Darrell
> > >  
> > > > >             }
> > > > >
> > > > >             Method (PRIM, 0, NotSerialized)
> > > > >             {
> > > > >                 Name (RBUF, Buffer (One)
> > > > >                 {
> > > > >                      0x01                                             // .
> > > > >                 })
> > > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > > >             }
> > > > >
> > > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > >             {
> > > > >                 If ((GAVT == 0x6A))
> > > > >                 {
> > > > >                     Return (0x0F)
> > > > >                 }
> > > > >                 Else
> > > > >                 {
> > > > >                     Return (Zero)
> > > > >                 }
> > > > >             }
> > > > >
> > > > >             Method (CALS, 1, NotSerialized)
> > > > >             {
> > > > >                 Local0 = Arg0
> > > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > > >                 {
> > > > >                     Local0 = BAC1 /* \BAC1 */
> > > > >                     Return (Local0)
> > > > >                 }
> > > > >                 Else
> > > > >                 {
> > > > >                     BAC1 = Local0
> > > > >                     BACS = Local0
> > > > >                     BSCA (0xB0)
> > > > >                 }
> > > > >             }
> > > > >         }
> > > > >     }
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Darrell
> > > > >
> > > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > > >
> > > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > >  
> > > > > > > Forwarding because original html messages were rejected by the server...
> > > > > > >
> > > > > > > ---------- Forwarded message ---------
> > > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > > <carnil@debian.org>
> > > > > > >
> > > > > > >
> > > > > > > Hi Jonathan,
> > > > > > >
> > > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > > rotation in Gnome just works.
> > > > > > >
> > > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > > >
> > > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > >          { },
> > > > > > >     };
> > > > > > > then:
> > > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);  
> > > > > >
> > > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > > >
> > > > > >
> > > > > >  
> > > > > > >
> > > > > > >
> > > > > > > dmesg shows:
> > > > > > >
> > > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > > using dummy regulator
> > > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > > using dummy regulator
> > > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > > found: using identity...
> > > > > > >
> > > > > > > Is this a problem?  
> > > > > >
> > > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > > be up to the kernel).
> > > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > > (non standard though).  Could you
> > > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > > then run through iasl from acpitools
> > > > > > iasl -d ~/dsdt
> > > > > > and find the bit related to this device.
> > > > > >
> > > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > > some existing versions we have code to handle and can add that support
> > > > > > as well.
> > > > > >
> > > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > > later if needed.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jonathan
> > > > > >
> > > > > >  
> > > > > > >
> > > > > > > Thanks again.
> > > > > > >
> > > > > > > Darrell
> > > > > > >
> > > > > > >
> > > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > > > > >
> > > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > >  
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > > it in a bug tracking system somewhere?  
> > > > > > > >
> > > > > > > > Email is the right option.
> > > > > > > >  
> > > > > > > > >
> > > > > > > > > Many thanks,
> > > > > > > > > Darrell
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Darrell,
> > > > > > > > >
> > > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
> > > > > > > > > > Package: src:linux
> > > > > > > > > > Version: 6.1.4-1
> > > > > > > > > > Severity: normal
> > > > > > > > > > File: linux
> > > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > > >
> > > > > > > > > > Dear Maintainer,
> > > > > > > > > >
> > > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> > > > > > > > > device  
> > > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> > > > > > > > > and the  
> > > > > > > > > > sysfs trees are created at  
> > > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
> > > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> > > > > > > > > but  
> > > > > > > > > > no driver is loaded.  
> > > > > > > >
> > > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > > (long story!)
> > > > > > > >
> > > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > > to add though the driver first needs converting to use
> > > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > > >
> > > > > > > > Completely untested but something like the following
> > > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > > >
> > > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > > it may get you basic functionality.
> > > > > > > >
> > > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > > when hacking the below ;)
> > > > > > > >
> > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > @@ -39,7 +39,7 @@
> > > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > > >
> > > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > > >         ST_LSM6DS3H_ID,
> > > > > > > >         ST_LSM6DSL_ID,
> > > > > > > >         ST_LSM6DSM_ID,
> > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > > >
> > > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > > >  {
> > > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > > -       int hw_id = id->driver_data;
> > > > > > > > +       int hw_id;
> > > > > > > >         struct regmap *regmap;
> > > > > > > >
> > > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > > +       if (!hw_id)
> > > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > > +       if (!hw_id)
> > > > > > > > +               return -EINVAL;
> > > > > > > > +
> > > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > > >         if (IS_ERR(regmap)) {
> > > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > > >  };
> > > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > > >
> > > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > +};
> > > > > > > > +
> > > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > > >         },
> > > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > > >
> > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > > physical_node:
> > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > >       name=SMO8B30:00
> > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > > firmware_node:
> > > > > > > > > >       hid=SMO8B30
> > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > > >       status=15
> > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > >       uid=0
> > > > > > > > > >
> > > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> > > > > > > > > loaded on boot.  
> > > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > > the module does not provide an alias for the above acpi/pnp id.  
> > > > > > > > >
> > > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > > get_maintainers.pl script:
> > > > > > > > >
> > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > > >
> > > > > > > > > Please keep us in the loop.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Salvatore  
> > > > > > > >  
> > > > > >  
> > > >  
> >  


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-30 20:31                       ` Jonathan Cameron
@ 2023-01-31 13:34                         ` Darrell Kavanagh
  2023-02-01  1:40                           ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-01-31 13:34 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera

Just a quick update on testing: I'm finding what look like
interactions between the kernel parm
video=DSI-1:panel_orientation=right_side_up and the sensor, which also
seem to differ depending on whether I'm in an X or Wayland session.
I'm documenting the effects of the various combinations and will post
my results when complete.

Thanks,
Darrell





On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Mon, 30 Jan 2023 20:02:31 +0000
> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>
> > Thanks. To be clear, before I changed the grub command line, the
> > system always booted up "sideways", even when the sensor was not being
> > detected. This was true for everything, not just Gnome, except grub
> > itself.
> >
> > I added:
> >
> > GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> > video=DSI-1:panel_orientation=right_side_up quiet splash"
> >
> > This fixed the orientation for pre-splash boot messages, the splash
> > screen and the desktop environment. But not, for example (as I saw
> > after adding my own module signing key for testing your fixes), the
> > MOK validation screens.
> >
> > Does this make sense?
> >
> > Does what you are proposing act at a lower level than changing the
> > systemd hwdb orientation matrix?
>
> I'm not sure on the userspace side of things, but intent is that
> it will provide the orientation data to any users - though only after
> the kernel boots and software needs to be aware of it.  Give it a go,
> and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
>
> For Bastien - patches for kernel side are:
> https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
>
> Darrell is going to test them after back porting to 6.1.
> With the first patch he gets the right result in gnome but we weren't
> picking up the rotation matrix at that point (ROTM in ACPI).
>
> Thanks,
>
> Jonathan
>
> >
> > Thanks,
> > Darrell
> >
> > On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
> > >
> > > On Mon, 30 Jan 2023 18:32:02 +0000
> > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >
> > > > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > > > <Jonathan.Cameron@huawei.com> wrote:
> > > >
> > > > > That certainly looks like suitable matrix.
> > > > >
> > > > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > > > be rather bad if what you have is currently working well.
> > > > >
> > > >
> > > > Actually, that would be good, because at present I have to rotate 90
> > > > degrees in my grub command line.
> > > :)
> > >
> > > I'll see if I can roll a suitable patch.
> > >
> > > Jonathan
> > >
> > > >
> > > > Darrell
> > > >
> > > > > >             }
> > > > > >
> > > > > >             Method (PRIM, 0, NotSerialized)
> > > > > >             {
> > > > > >                 Name (RBUF, Buffer (One)
> > > > > >                 {
> > > > > >                      0x01                                             // .
> > > > > >                 })
> > > > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > > > >             }
> > > > > >
> > > > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > > >             {
> > > > > >                 If ((GAVT == 0x6A))
> > > > > >                 {
> > > > > >                     Return (0x0F)
> > > > > >                 }
> > > > > >                 Else
> > > > > >                 {
> > > > > >                     Return (Zero)
> > > > > >                 }
> > > > > >             }
> > > > > >
> > > > > >             Method (CALS, 1, NotSerialized)
> > > > > >             {
> > > > > >                 Local0 = Arg0
> > > > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > > > >                 {
> > > > > >                     Local0 = BAC1 /* \BAC1 */
> > > > > >                     Return (Local0)
> > > > > >                 }
> > > > > >                 Else
> > > > > >                 {
> > > > > >                     BAC1 = Local0
> > > > > >                     BACS = Local0
> > > > > >                     BSCA (0xB0)
> > > > > >                 }
> > > > > >             }
> > > > > >         }
> > > > > >     }
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Darrell
> > > > > >
> > > > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > >
> > > > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > >
> > > > > > > > Forwarding because original html messages were rejected by the server...
> > > > > > > >
> > > > > > > > ---------- Forwarded message ---------
> > > > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > > > <carnil@debian.org>
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Jonathan,
> > > > > > > >
> > > > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > > > rotation in Gnome just works.
> > > > > > > >
> > > > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > > > >
> > > > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > >          { },
> > > > > > > >     };
> > > > > > > > then:
> > > > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
> > > > > > >
> > > > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > dmesg shows:
> > > > > > > >
> > > > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > > > using dummy regulator
> > > > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > > > using dummy regulator
> > > > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > > > found: using identity...
> > > > > > > >
> > > > > > > > Is this a problem?
> > > > > > >
> > > > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > > > be up to the kernel).
> > > > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > > > (non standard though).  Could you
> > > > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > > > then run through iasl from acpitools
> > > > > > > iasl -d ~/dsdt
> > > > > > > and find the bit related to this device.
> > > > > > >
> > > > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > > > some existing versions we have code to handle and can add that support
> > > > > > > as well.
> > > > > > >
> > > > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > > > later if needed.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Jonathan
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again.
> > > > > > > >
> > > > > > > > Darrell
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > > > it in a bug tracking system somewhere?
> > > > > > > > >
> > > > > > > > > Email is the right option.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Many thanks,
> > > > > > > > > > Darrell
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Darrell,
> > > > > > > > > >
> > > > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > > > > > > > > > Package: src:linux
> > > > > > > > > > > Version: 6.1.4-1
> > > > > > > > > > > Severity: normal
> > > > > > > > > > > File: linux
> > > > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > Dear Maintainer,
> > > > > > > > > > >
> > > > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > > > > > > > > > device
> > > > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > > > > > > > > > and the
> > > > > > > > > > > sysfs trees are created at
> > > > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > > > > > > > > > but
> > > > > > > > > > > no driver is loaded.
> > > > > > > > >
> > > > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > > > (long story!)
> > > > > > > > >
> > > > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > > > to add though the driver first needs converting to use
> > > > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > > > >
> > > > > > > > > Completely untested but something like the following
> > > > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > > > >
> > > > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > > > it may get you basic functionality.
> > > > > > > > >
> > > > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > > > when hacking the below ;)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > @@ -39,7 +39,7 @@
> > > > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > > > >
> > > > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > > > >         ST_LSM6DS3H_ID,
> > > > > > > > >         ST_LSM6DSL_ID,
> > > > > > > > >         ST_LSM6DSM_ID,
> > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > > > >
> > > > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > > > >  {
> > > > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > > > -       int hw_id = id->driver_data;
> > > > > > > > > +       int hw_id;
> > > > > > > > >         struct regmap *regmap;
> > > > > > > > >
> > > > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > > > +       if (!hw_id)
> > > > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > > > +       if (!hw_id)
> > > > > > > > > +               return -EINVAL;
> > > > > > > > > +
> > > > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > > > >         if (IS_ERR(regmap)) {
> > > > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > > > >  };
> > > > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > > > >
> > > > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > > > >         },
> > > > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > > > physical_node:
> > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > >       name=SMO8B30:00
> > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > > > firmware_node:
> > > > > > > > > > >       hid=SMO8B30
> > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > > > >       status=15
> > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > >       uid=0
> > > > > > > > > > >
> > > > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > > > > > > > > > loaded on boot.
> > > > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > > > the module does not provide an alias for the above acpi/pnp id.
> > > > > > > > > >
> > > > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > > > get_maintainers.pl script:
> > > > > > > > > >
> > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > > > >
> > > > > > > > > > Please keep us in the loop.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Salvatore
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-01-31 13:34                         ` Darrell Kavanagh
@ 2023-02-01  1:40                           ` Darrell Kavanagh
  2023-02-01  1:46                             ` Darrell Kavanagh
  2023-02-01 10:28                             ` Jonathan Cameron
  0 siblings, 2 replies; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-01  1:40 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera

Hello, all.

I've finally reached a conclusion on this, after testing all the
combinations of the patches (with and without reading the acpi
mounting matrix), window managers (wayland, xorg) and the presence or
not of my custom kernel parms.

What works well is the full set of patches with the custom kernel
parms and a new hwdb entry for the sensor:

sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
 ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1

The autorotate then works correctly in wayland and xorg, but for xorg,
the settings say the screen is "portrait left" when in actual fact it
is in standard laptop landscape orientation. Wayland does not have
this problem (I guess because wayland's view of the screen is straight
from the kernel).

Without the hwdb entry, the orientation is 90 degrees out without
using the acpi matrix and 180 degrees out when using it. I could have
gone either way here with appropriate hwdb entries, but my view is
that we *should* be using the matrix.

BTW, when I reported before that it was working correctly in Gnome, I
was using a third party shell extension to force auto-rotation rather
than actually detaching the keyboard. I take the view that if an
extension works differently to the built-in tablet mode, it's the
extension's problem!

The only thing that concerns me is the need for custom kernel parms.
It would be better if there was a way to avoid this, so that the user
didn't have to mess around with their grub config. Though having said
that, the sensors fix as we have it doesn't make things worse - under
currently released kernels the screen always starts up sideways unless
custom parms are added in grub.

Without the custom parms,  the patches and the new hwdb entry do
ensure that things end up the right way around, but it's a bit clunky.
The boot messages/splash is sideways and you can see the sensors
kicking in on the gdm screen: it shows momentarily sideways before
righting itself. This can also cause the scaling to be set to 200%,
which can carry through to the user's session.

So thanks for your work on this - I now have a fully functioning
device. I hope the changes are robust enough to be pushed into a
future kernel so that others can benefit.

Regards,
Darrell


On Tue, 31 Jan 2023 at 13:34, Darrell Kavanagh
<darrell.kavanagh@gmail.com> wrote:
>
> Just a quick update on testing: I'm finding what look like
> interactions between the kernel parm
> video=DSI-1:panel_orientation=right_side_up and the sensor, which also
> seem to differ depending on whether I'm in an X or Wayland session.
> I'm documenting the effects of the various combinations and will post
> my results when complete.
>
> Thanks,
> Darrell
>
>
>
>
>
> On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Mon, 30 Jan 2023 20:02:31 +0000
> > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >
> > > Thanks. To be clear, before I changed the grub command line, the
> > > system always booted up "sideways", even when the sensor was not being
> > > detected. This was true for everything, not just Gnome, except grub
> > > itself.
> > >
> > > I added:
> > >
> > > GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> > > video=DSI-1:panel_orientation=right_side_up quiet splash"
> > >
> > > This fixed the orientation for pre-splash boot messages, the splash
> > > screen and the desktop environment. But not, for example (as I saw
> > > after adding my own module signing key for testing your fixes), the
> > > MOK validation screens.
> > >
> > > Does this make sense?
> > >
> > > Does what you are proposing act at a lower level than changing the
> > > systemd hwdb orientation matrix?
> >
> > I'm not sure on the userspace side of things, but intent is that
> > it will provide the orientation data to any users - though only after
> > the kernel boots and software needs to be aware of it.  Give it a go,
> > and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
> >
> > For Bastien - patches for kernel side are:
> > https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
> >
> > Darrell is going to test them after back porting to 6.1.
> > With the first patch he gets the right result in gnome but we weren't
> > picking up the rotation matrix at that point (ROTM in ACPI).
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > Thanks,
> > > Darrell
> > >
> > > On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
> > > >
> > > > On Mon, 30 Jan 2023 18:32:02 +0000
> > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > >
> > > > > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > >
> > > > > > That certainly looks like suitable matrix.
> > > > > >
> > > > > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > > > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > > > > be rather bad if what you have is currently working well.
> > > > > >
> > > > >
> > > > > Actually, that would be good, because at present I have to rotate 90
> > > > > degrees in my grub command line.
> > > > :)
> > > >
> > > > I'll see if I can roll a suitable patch.
> > > >
> > > > Jonathan
> > > >
> > > > >
> > > > > Darrell
> > > > >
> > > > > > >             }
> > > > > > >
> > > > > > >             Method (PRIM, 0, NotSerialized)
> > > > > > >             {
> > > > > > >                 Name (RBUF, Buffer (One)
> > > > > > >                 {
> > > > > > >                      0x01                                             // .
> > > > > > >                 })
> > > > > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > > > > >             }
> > > > > > >
> > > > > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > > > >             {
> > > > > > >                 If ((GAVT == 0x6A))
> > > > > > >                 {
> > > > > > >                     Return (0x0F)
> > > > > > >                 }
> > > > > > >                 Else
> > > > > > >                 {
> > > > > > >                     Return (Zero)
> > > > > > >                 }
> > > > > > >             }
> > > > > > >
> > > > > > >             Method (CALS, 1, NotSerialized)
> > > > > > >             {
> > > > > > >                 Local0 = Arg0
> > > > > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > > > > >                 {
> > > > > > >                     Local0 = BAC1 /* \BAC1 */
> > > > > > >                     Return (Local0)
> > > > > > >                 }
> > > > > > >                 Else
> > > > > > >                 {
> > > > > > >                     BAC1 = Local0
> > > > > > >                     BACS = Local0
> > > > > > >                     BSCA (0xB0)
> > > > > > >                 }
> > > > > > >             }
> > > > > > >         }
> > > > > > >     }
> > > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Darrell
> > > > > > >
> > > > > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Forwarding because original html messages were rejected by the server...
> > > > > > > > >
> > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > > > > <carnil@debian.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Jonathan,
> > > > > > > > >
> > > > > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > > > > rotation in Gnome just works.
> > > > > > > > >
> > > > > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > > > > >
> > > > > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > >          { },
> > > > > > > > >     };
> > > > > > > > > then:
> > > > > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
> > > > > > > >
> > > > > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > dmesg shows:
> > > > > > > > >
> > > > > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > > > > using dummy regulator
> > > > > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > > > > using dummy regulator
> > > > > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > > > > found: using identity...
> > > > > > > > >
> > > > > > > > > Is this a problem?
> > > > > > > >
> > > > > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > > > > be up to the kernel).
> > > > > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > > > > (non standard though).  Could you
> > > > > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > > > > then run through iasl from acpitools
> > > > > > > > iasl -d ~/dsdt
> > > > > > > > and find the bit related to this device.
> > > > > > > >
> > > > > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > > > > some existing versions we have code to handle and can add that support
> > > > > > > > as well.
> > > > > > > >
> > > > > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > > > > later if needed.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Jonathan
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks again.
> > > > > > > > >
> > > > > > > > > Darrell
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > > > > it in a bug tracking system somewhere?
> > > > > > > > > >
> > > > > > > > > > Email is the right option.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Many thanks,
> > > > > > > > > > > Darrell
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Darrell,
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > > > > > > > > > > Package: src:linux
> > > > > > > > > > > > Version: 6.1.4-1
> > > > > > > > > > > > Severity: normal
> > > > > > > > > > > > File: linux
> > > > > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > Dear Maintainer,
> > > > > > > > > > > >
> > > > > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > > > > > > > > > > device
> > > > > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > > > > > > > > > > and the
> > > > > > > > > > > > sysfs trees are created at
> > > > > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > > > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > > > > > > > > > > but
> > > > > > > > > > > > no driver is loaded.
> > > > > > > > > >
> > > > > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > > > > (long story!)
> > > > > > > > > >
> > > > > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > > > > to add though the driver first needs converting to use
> > > > > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > > > > >
> > > > > > > > > > Completely untested but something like the following
> > > > > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > > > > >
> > > > > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > > > > it may get you basic functionality.
> > > > > > > > > >
> > > > > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > > > > when hacking the below ;)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > @@ -39,7 +39,7 @@
> > > > > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > > > > >
> > > > > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > > > > >         ST_LSM6DS3H_ID,
> > > > > > > > > >         ST_LSM6DSL_ID,
> > > > > > > > > >         ST_LSM6DSM_ID,
> > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > > > > >
> > > > > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > > > > >  {
> > > > > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > > > > -       int hw_id = id->driver_data;
> > > > > > > > > > +       int hw_id;
> > > > > > > > > >         struct regmap *regmap;
> > > > > > > > > >
> > > > > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > +               return -EINVAL;
> > > > > > > > > > +
> > > > > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > > > > >         if (IS_ERR(regmap)) {
> > > > > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > > > > >  };
> > > > > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > > > > >
> > > > > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > > > > >         },
> > > > > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > > > > physical_node:
> > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > >       name=SMO8B30:00
> > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > > > > firmware_node:
> > > > > > > > > > > >       hid=SMO8B30
> > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > > > > >       status=15
> > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > >       uid=0
> > > > > > > > > > > >
> > > > > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > > > > > > > > > > loaded on boot.
> > > > > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > > > > the module does not provide an alias for the above acpi/pnp id.
> > > > > > > > > > >
> > > > > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > > > > get_maintainers.pl script:
> > > > > > > > > > >
> > > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > > > > >
> > > > > > > > > > > Please keep us in the loop.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Salvatore
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01  1:40                           ` Darrell Kavanagh
@ 2023-02-01  1:46                             ` Darrell Kavanagh
  2023-02-01 10:29                               ` Jonathan Cameron
  2023-02-01 10:28                             ` Jonathan Cameron
  1 sibling, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-01  1:46 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera

I should also add that I'm more than willing to help in testing any
further changes for you, whether for this bug or future ones.

Darrell

On Wed, 1 Feb 2023 at 01:40, Darrell Kavanagh
<darrell.kavanagh@gmail.com> wrote:
>
> Hello, all.
>
> I've finally reached a conclusion on this, after testing all the
> combinations of the patches (with and without reading the acpi
> mounting matrix), window managers (wayland, xorg) and the presence or
> not of my custom kernel parms.
>
> What works well is the full set of patches with the custom kernel
> parms and a new hwdb entry for the sensor:
>
> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>
> The autorotate then works correctly in wayland and xorg, but for xorg,
> the settings say the screen is "portrait left" when in actual fact it
> is in standard laptop landscape orientation. Wayland does not have
> this problem (I guess because wayland's view of the screen is straight
> from the kernel).
>
> Without the hwdb entry, the orientation is 90 degrees out without
> using the acpi matrix and 180 degrees out when using it. I could have
> gone either way here with appropriate hwdb entries, but my view is
> that we *should* be using the matrix.
>
> BTW, when I reported before that it was working correctly in Gnome, I
> was using a third party shell extension to force auto-rotation rather
> than actually detaching the keyboard. I take the view that if an
> extension works differently to the built-in tablet mode, it's the
> extension's problem!
>
> The only thing that concerns me is the need for custom kernel parms.
> It would be better if there was a way to avoid this, so that the user
> didn't have to mess around with their grub config. Though having said
> that, the sensors fix as we have it doesn't make things worse - under
> currently released kernels the screen always starts up sideways unless
> custom parms are added in grub.
>
> Without the custom parms,  the patches and the new hwdb entry do
> ensure that things end up the right way around, but it's a bit clunky.
> The boot messages/splash is sideways and you can see the sensors
> kicking in on the gdm screen: it shows momentarily sideways before
> righting itself. This can also cause the scaling to be set to 200%,
> which can carry through to the user's session.
>
> So thanks for your work on this - I now have a fully functioning
> device. I hope the changes are robust enough to be pushed into a
> future kernel so that others can benefit.
>
> Regards,
> Darrell
>
>
> On Tue, 31 Jan 2023 at 13:34, Darrell Kavanagh
> <darrell.kavanagh@gmail.com> wrote:
> >
> > Just a quick update on testing: I'm finding what look like
> > interactions between the kernel parm
> > video=DSI-1:panel_orientation=right_side_up and the sensor, which also
> > seem to differ depending on whether I'm in an X or Wayland session.
> > I'm documenting the effects of the various combinations and will post
> > my results when complete.
> >
> > Thanks,
> > Darrell
> >
> >
> >
> >
> >
> > On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:
> > >
> > > On Mon, 30 Jan 2023 20:02:31 +0000
> > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >
> > > > Thanks. To be clear, before I changed the grub command line, the
> > > > system always booted up "sideways", even when the sensor was not being
> > > > detected. This was true for everything, not just Gnome, except grub
> > > > itself.
> > > >
> > > > I added:
> > > >
> > > > GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> > > > video=DSI-1:panel_orientation=right_side_up quiet splash"
> > > >
> > > > This fixed the orientation for pre-splash boot messages, the splash
> > > > screen and the desktop environment. But not, for example (as I saw
> > > > after adding my own module signing key for testing your fixes), the
> > > > MOK validation screens.
> > > >
> > > > Does this make sense?
> > > >
> > > > Does what you are proposing act at a lower level than changing the
> > > > systemd hwdb orientation matrix?
> > >
> > > I'm not sure on the userspace side of things, but intent is that
> > > it will provide the orientation data to any users - though only after
> > > the kernel boots and software needs to be aware of it.  Give it a go,
> > > and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
> > >
> > > For Bastien - patches for kernel side are:
> > > https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
> > >
> > > Darrell is going to test them after back porting to 6.1.
> > > With the first patch he gets the right result in gnome but we weren't
> > > picking up the rotation matrix at that point (ROTM in ACPI).
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > > >
> > > > Thanks,
> > > > Darrell
> > > >
> > > > On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
> > > > >
> > > > > On Mon, 30 Jan 2023 18:32:02 +0000
> > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > >
> > > > > > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > >
> > > > > > > That certainly looks like suitable matrix.
> > > > > > >
> > > > > > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > > > > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > > > > > be rather bad if what you have is currently working well.
> > > > > > >
> > > > > >
> > > > > > Actually, that would be good, because at present I have to rotate 90
> > > > > > degrees in my grub command line.
> > > > > :)
> > > > >
> > > > > I'll see if I can roll a suitable patch.
> > > > >
> > > > > Jonathan
> > > > >
> > > > > >
> > > > > > Darrell
> > > > > >
> > > > > > > >             }
> > > > > > > >
> > > > > > > >             Method (PRIM, 0, NotSerialized)
> > > > > > > >             {
> > > > > > > >                 Name (RBUF, Buffer (One)
> > > > > > > >                 {
> > > > > > > >                      0x01                                             // .
> > > > > > > >                 })
> > > > > > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > > > > > >             }
> > > > > > > >
> > > > > > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > > > > >             {
> > > > > > > >                 If ((GAVT == 0x6A))
> > > > > > > >                 {
> > > > > > > >                     Return (0x0F)
> > > > > > > >                 }
> > > > > > > >                 Else
> > > > > > > >                 {
> > > > > > > >                     Return (Zero)
> > > > > > > >                 }
> > > > > > > >             }
> > > > > > > >
> > > > > > > >             Method (CALS, 1, NotSerialized)
> > > > > > > >             {
> > > > > > > >                 Local0 = Arg0
> > > > > > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > > > > > >                 {
> > > > > > > >                     Local0 = BAC1 /* \BAC1 */
> > > > > > > >                     Return (Local0)
> > > > > > > >                 }
> > > > > > > >                 Else
> > > > > > > >                 {
> > > > > > > >                     BAC1 = Local0
> > > > > > > >                     BACS = Local0
> > > > > > > >                     BSCA (0xB0)
> > > > > > > >                 }
> > > > > > > >             }
> > > > > > > >         }
> > > > > > > >     }
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Darrell
> > > > > > > >
> > > > > > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > Forwarding because original html messages were rejected by the server...
> > > > > > > > > >
> > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > > > > > <carnil@debian.org>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Jonathan,
> > > > > > > > > >
> > > > > > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > > > > > rotation in Gnome just works.
> > > > > > > > > >
> > > > > > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > > > > > >
> > > > > > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > >          { },
> > > > > > > > > >     };
> > > > > > > > > > then:
> > > > > > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
> > > > > > > > >
> > > > > > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > dmesg shows:
> > > > > > > > > >
> > > > > > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > > > > > using dummy regulator
> > > > > > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > > > > > using dummy regulator
> > > > > > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > > > > > found: using identity...
> > > > > > > > > >
> > > > > > > > > > Is this a problem?
> > > > > > > > >
> > > > > > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > > > > > be up to the kernel).
> > > > > > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > > > > > (non standard though).  Could you
> > > > > > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > > > > > then run through iasl from acpitools
> > > > > > > > > iasl -d ~/dsdt
> > > > > > > > > and find the bit related to this device.
> > > > > > > > >
> > > > > > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > > > > > some existing versions we have code to handle and can add that support
> > > > > > > > > as well.
> > > > > > > > >
> > > > > > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > > > > > later if needed.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Jonathan
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Thanks again.
> > > > > > > > > >
> > > > > > > > > > Darrell
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > > > > > it in a bug tracking system somewhere?
> > > > > > > > > > >
> > > > > > > > > > > Email is the right option.
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Many thanks,
> > > > > > > > > > > > Darrell
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Darrell,
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> > > > > > > > > > > > > Package: src:linux
> > > > > > > > > > > > > Version: 6.1.4-1
> > > > > > > > > > > > > Severity: normal
> > > > > > > > > > > > > File: linux
> > > > > > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > Dear Maintainer,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor
> > > > > > > > > > > > device
> > > > > > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> > > > > > > > > > > > and the
> > > > > > > > > > > > > sysfs trees are created at
> > > > > > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> > > > > > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> > > > > > > > > > > > but
> > > > > > > > > > > > > no driver is loaded.
> > > > > > > > > > >
> > > > > > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > > > > > (long story!)
> > > > > > > > > > >
> > > > > > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > > > > > to add though the driver first needs converting to use
> > > > > > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > > > > > >
> > > > > > > > > > > Completely untested but something like the following
> > > > > > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > > > > > >
> > > > > > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > > > > > it may get you basic functionality.
> > > > > > > > > > >
> > > > > > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > > > > > when hacking the below ;)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > @@ -39,7 +39,7 @@
> > > > > > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > > > > > >
> > > > > > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > > > > > >         ST_LSM6DS3H_ID,
> > > > > > > > > > >         ST_LSM6DSL_ID,
> > > > > > > > > > >         ST_LSM6DSM_ID,
> > > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > > > > > >
> > > > > > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > > > > > >  {
> > > > > > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > > > > > -       int hw_id = id->driver_data;
> > > > > > > > > > > +       int hw_id;
> > > > > > > > > > >         struct regmap *regmap;
> > > > > > > > > > >
> > > > > > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > > +               return -EINVAL;
> > > > > > > > > > > +
> > > > > > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > > > > > >         if (IS_ERR(regmap)) {
> > > > > > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > > > > > >  };
> > > > > > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > > > > > >
> > > > > > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > > > > > >         },
> > > > > > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > > > > > physical_node:
> > > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       name=SMO8B30:00
> > > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > > > > > firmware_node:
> > > > > > > > > > > > >       hid=SMO8B30
> > > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > > > > > >       status=15
> > > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       uid=0
> > > > > > > > > > > > >
> > > > > > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> > > > > > > > > > > > loaded on boot.
> > > > > > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > > > > > the module does not provide an alias for the above acpi/pnp id.
> > > > > > > > > > > >
> > > > > > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > > > > > get_maintainers.pl script:
> > > > > > > > > > > >
> > > > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > > > > > >
> > > > > > > > > > > > Please keep us in the loop.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Salvatore
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01  1:40                           ` Darrell Kavanagh
  2023-02-01  1:46                             ` Darrell Kavanagh
@ 2023-02-01 10:28                             ` Jonathan Cameron
  2023-02-01 11:00                               ` Hans de Goede
  1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-02-01 10:28 UTC (permalink / raw)
  To: Darrell Kavanagh
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera, Hans de Goede

On Wed, 1 Feb 2023 01:40:49 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> Hello, all.
> 
> I've finally reached a conclusion on this, after testing all the
> combinations of the patches (with and without reading the acpi
> mounting matrix), window managers (wayland, xorg) and the presence or
> not of my custom kernel parms.
> 
> What works well is the full set of patches with the custom kernel
> parms and a new hwdb entry for the sensor:
> 
> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> 
> The autorotate then works correctly in wayland and xorg, but for xorg,
> the settings say the screen is "portrait left" when in actual fact it
> is in standard laptop landscape orientation. Wayland does not have
> this problem (I guess because wayland's view of the screen is straight
> from the kernel).
> 
> Without the hwdb entry, the orientation is 90 degrees out without
> using the acpi matrix and 180 degrees out when using it. I could have
> gone either way here with appropriate hwdb entries, but my view is
> that we *should* be using the matrix.

Added Hans de Goede as he has probably run into more of this mess
than anyone else.  Hans, any thoughts on if we are doing something
wrong on kernel side?  Or is the matrix just wrong *sigh*
I think 'ROTM' is defined by MS. 
https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries



> 
> BTW, when I reported before that it was working correctly in Gnome, I
> was using a third party shell extension to force auto-rotation rather
> than actually detaching the keyboard. I take the view that if an
> extension works differently to the built-in tablet mode, it's the
> extension's problem!
> 
> The only thing that concerns me is the need for custom kernel parms.
> It would be better if there was a way to avoid this, so that the user
> didn't have to mess around with their grub config. Though having said
> that, the sensors fix as we have it doesn't make things worse - under
> currently released kernels the screen always starts up sideways unless
> custom parms are added in grub.
> 
> Without the custom parms,  the patches and the new hwdb entry do
> ensure that things end up the right way around, but it's a bit clunky.
> The boot messages/splash is sideways and you can see the sensors
> kicking in on the gdm screen: it shows momentarily sideways before
> righting itself. This can also cause the scaling to be set to 200%,
> which can carry through to the user's session.
> 
> So thanks for your work on this - I now have a fully functioning
> device. I hope the changes are robust enough to be pushed into a
> future kernel so that others can benefit.

I'll certainly pick up the ID patch, but I'm dubious about the mount
matrix unless we manage to establish why it isn't directly giving us
the right answer (and what the solution should be).


Jonathan

> 
> Regards,
> Darrell
> 
> 
> On Tue, 31 Jan 2023 at 13:34, Darrell Kavanagh
> <darrell.kavanagh@gmail.com> wrote:
> >
> > Just a quick update on testing: I'm finding what look like
> > interactions between the kernel parm
> > video=DSI-1:panel_orientation=right_side_up and the sensor, which also
> > seem to differ depending on whether I'm in an X or Wayland session.
> > I'm documenting the effects of the various combinations and will post
> > my results when complete.
> >
> > Thanks,
> > Darrell
> >
> >
> >
> >
> >
> > On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:  
> > >
> > > On Mon, 30 Jan 2023 20:02:31 +0000
> > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >  
> > > > Thanks. To be clear, before I changed the grub command line, the
> > > > system always booted up "sideways", even when the sensor was not being
> > > > detected. This was true for everything, not just Gnome, except grub
> > > > itself.
> > > >
> > > > I added:
> > > >
> > > > GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> > > > video=DSI-1:panel_orientation=right_side_up quiet splash"
> > > >
> > > > This fixed the orientation for pre-splash boot messages, the splash
> > > > screen and the desktop environment. But not, for example (as I saw
> > > > after adding my own module signing key for testing your fixes), the
> > > > MOK validation screens.
> > > >
> > > > Does this make sense?
> > > >
> > > > Does what you are proposing act at a lower level than changing the
> > > > systemd hwdb orientation matrix?  
> > >
> > > I'm not sure on the userspace side of things, but intent is that
> > > it will provide the orientation data to any users - though only after
> > > the kernel boots and software needs to be aware of it.  Give it a go,
> > > and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
> > >
> > > For Bastien - patches for kernel side are:
> > > https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
> > >
> > > Darrell is going to test them after back porting to 6.1.
> > > With the first patch he gets the right result in gnome but we weren't
> > > picking up the rotation matrix at that point (ROTM in ACPI).
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >  
> > > >
> > > > Thanks,
> > > > Darrell
> > > >
> > > > On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > >
> > > > > On Mon, 30 Jan 2023 18:32:02 +0000
> > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > >  
> > > > > > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > >  
> > > > > > > That certainly looks like suitable matrix.
> > > > > > >
> > > > > > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > > > > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > > > > > be rather bad if what you have is currently working well.
> > > > > > >  
> > > > > >
> > > > > > Actually, that would be good, because at present I have to rotate 90
> > > > > > degrees in my grub command line.  
> > > > > :)
> > > > >
> > > > > I'll see if I can roll a suitable patch.
> > > > >
> > > > > Jonathan
> > > > >  
> > > > > >
> > > > > > Darrell
> > > > > >  
> > > > > > > >             }
> > > > > > > >
> > > > > > > >             Method (PRIM, 0, NotSerialized)
> > > > > > > >             {
> > > > > > > >                 Name (RBUF, Buffer (One)
> > > > > > > >                 {
> > > > > > > >                      0x01                                             // .
> > > > > > > >                 })
> > > > > > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > > > > > >             }
> > > > > > > >
> > > > > > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > > > > >             {
> > > > > > > >                 If ((GAVT == 0x6A))
> > > > > > > >                 {
> > > > > > > >                     Return (0x0F)
> > > > > > > >                 }
> > > > > > > >                 Else
> > > > > > > >                 {
> > > > > > > >                     Return (Zero)
> > > > > > > >                 }
> > > > > > > >             }
> > > > > > > >
> > > > > > > >             Method (CALS, 1, NotSerialized)
> > > > > > > >             {
> > > > > > > >                 Local0 = Arg0
> > > > > > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > > > > > >                 {
> > > > > > > >                     Local0 = BAC1 /* \BAC1 */
> > > > > > > >                     Return (Local0)
> > > > > > > >                 }
> > > > > > > >                 Else
> > > > > > > >                 {
> > > > > > > >                     BAC1 = Local0
> > > > > > > >                     BACS = Local0
> > > > > > > >                     BSCA (0xB0)
> > > > > > > >                 }
> > > > > > > >             }
> > > > > > > >         }
> > > > > > > >     }
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Darrell
> > > > > > > >
> > > > > > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > > > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > > > > > >
> > > > > > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > >  
> > > > > > > > > > Forwarding because original html messages were rejected by the server...
> > > > > > > > > >
> > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > > > > > <carnil@debian.org>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Jonathan,
> > > > > > > > > >
> > > > > > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > > > > > rotation in Gnome just works.
> > > > > > > > > >
> > > > > > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > > > > > >
> > > > > > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > >          { },
> > > > > > > > > >     };
> > > > > > > > > > then:
> > > > > > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);  
> > > > > > > > >
> > > > > > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > dmesg shows:
> > > > > > > > > >
> > > > > > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > > > > > using dummy regulator
> > > > > > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > > > > > using dummy regulator
> > > > > > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > > > > > found: using identity...
> > > > > > > > > >
> > > > > > > > > > Is this a problem?  
> > > > > > > > >
> > > > > > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > > > > > be up to the kernel).
> > > > > > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > > > > > (non standard though).  Could you
> > > > > > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > > > > > then run through iasl from acpitools
> > > > > > > > > iasl -d ~/dsdt
> > > > > > > > > and find the bit related to this device.
> > > > > > > > >
> > > > > > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > > > > > some existing versions we have code to handle and can add that support
> > > > > > > > > as well.
> > > > > > > > >
> > > > > > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > > > > > later if needed.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Jonathan
> > > > > > > > >
> > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > Thanks again.
> > > > > > > > > >
> > > > > > > > > > Darrell
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > > > > > > > >
> > > > > > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > > > >  
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > > > > > it in a bug tracking system somewhere?  
> > > > > > > > > > >
> > > > > > > > > > > Email is the right option.
> > > > > > > > > > >  
> > > > > > > > > > > >
> > > > > > > > > > > > Many thanks,
> > > > > > > > > > > > Darrell
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Darrell,
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
> > > > > > > > > > > > > Package: src:linux
> > > > > > > > > > > > > Version: 6.1.4-1
> > > > > > > > > > > > > Severity: normal
> > > > > > > > > > > > > File: linux
> > > > > > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > Dear Maintainer,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> > > > > > > > > > > > device  
> > > > > > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> > > > > > > > > > > > and the  
> > > > > > > > > > > > > sysfs trees are created at  
> > > > > > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
> > > > > > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> > > > > > > > > > > > but  
> > > > > > > > > > > > > no driver is loaded.  
> > > > > > > > > > >
> > > > > > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > > > > > (long story!)
> > > > > > > > > > >
> > > > > > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > > > > > to add though the driver first needs converting to use
> > > > > > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > > > > > >
> > > > > > > > > > > Completely untested but something like the following
> > > > > > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > > > > > >
> > > > > > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > > > > > it may get you basic functionality.
> > > > > > > > > > >
> > > > > > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > > > > > when hacking the below ;)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > @@ -39,7 +39,7 @@
> > > > > > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > > > > > >
> > > > > > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > > > > > >         ST_LSM6DS3H_ID,
> > > > > > > > > > >         ST_LSM6DSL_ID,
> > > > > > > > > > >         ST_LSM6DSM_ID,
> > > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > > > > > >
> > > > > > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > > > > > >  {
> > > > > > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > > > > > -       int hw_id = id->driver_data;
> > > > > > > > > > > +       int hw_id;
> > > > > > > > > > >         struct regmap *regmap;
> > > > > > > > > > >
> > > > > > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > > +               return -EINVAL;
> > > > > > > > > > > +
> > > > > > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > > > > > >         if (IS_ERR(regmap)) {
> > > > > > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > > > > > >  };
> > > > > > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > > > > > >
> > > > > > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > > > > > >         },
> > > > > > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > > > > > >
> > > > > > > > > > >  
> > > > > > > > > > > > >
> > > > > > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > > > > > physical_node:
> > > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       name=SMO8B30:00
> > > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > > > > > firmware_node:
> > > > > > > > > > > > >       hid=SMO8B30
> > > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > > > > > >       status=15
> > > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > >       uid=0
> > > > > > > > > > > > >
> > > > > > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> > > > > > > > > > > > loaded on boot.  
> > > > > > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > > > > > the module does not provide an alias for the above acpi/pnp id.  
> > > > > > > > > > > >
> > > > > > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > > > > > get_maintainers.pl script:
> > > > > > > > > > > >
> > > > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > > > > > >
> > > > > > > > > > > > Please keep us in the loop.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Salvatore  
> > > > > > > > > > >  
> > > > > > > > >  
> > > > > > >  
> > > > >  
> > >  


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01  1:46                             ` Darrell Kavanagh
@ 2023-02-01 10:29                               ` Jonathan Cameron
  0 siblings, 0 replies; 29+ messages in thread
From: Jonathan Cameron @ 2023-02-01 10:29 UTC (permalink / raw)
  To: Darrell Kavanagh
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera

On Wed, 1 Feb 2023 01:46:11 +0000
Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:

> I should also add that I'm more than willing to help in testing any
> further changes for you, whether for this bug or future ones.
> 

Thanks for the excellent reporting and testing!  I'll definitely
keep you in mind for this driver and in particular ACPI side
of things.

Jonathan

> Darrell
> 
> On Wed, 1 Feb 2023 at 01:40, Darrell Kavanagh
> <darrell.kavanagh@gmail.com> wrote:
> >
> > Hello, all.
> >
> > I've finally reached a conclusion on this, after testing all the
> > combinations of the patches (with and without reading the acpi
> > mounting matrix), window managers (wayland, xorg) and the presence or
> > not of my custom kernel parms.
> >
> > What works well is the full set of patches with the custom kernel
> > parms and a new hwdb entry for the sensor:
> >
> > sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> >  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> >
> > The autorotate then works correctly in wayland and xorg, but for xorg,
> > the settings say the screen is "portrait left" when in actual fact it
> > is in standard laptop landscape orientation. Wayland does not have
> > this problem (I guess because wayland's view of the screen is straight
> > from the kernel).
> >
> > Without the hwdb entry, the orientation is 90 degrees out without
> > using the acpi matrix and 180 degrees out when using it. I could have
> > gone either way here with appropriate hwdb entries, but my view is
> > that we *should* be using the matrix.
> >
> > BTW, when I reported before that it was working correctly in Gnome, I
> > was using a third party shell extension to force auto-rotation rather
> > than actually detaching the keyboard. I take the view that if an
> > extension works differently to the built-in tablet mode, it's the
> > extension's problem!
> >
> > The only thing that concerns me is the need for custom kernel parms.
> > It would be better if there was a way to avoid this, so that the user
> > didn't have to mess around with their grub config. Though having said
> > that, the sensors fix as we have it doesn't make things worse - under
> > currently released kernels the screen always starts up sideways unless
> > custom parms are added in grub.
> >
> > Without the custom parms,  the patches and the new hwdb entry do
> > ensure that things end up the right way around, but it's a bit clunky.
> > The boot messages/splash is sideways and you can see the sensors
> > kicking in on the gdm screen: it shows momentarily sideways before
> > righting itself. This can also cause the scaling to be set to 200%,
> > which can carry through to the user's session.
> >
> > So thanks for your work on this - I now have a fully functioning
> > device. I hope the changes are robust enough to be pushed into a
> > future kernel so that others can benefit.
> >
> > Regards,
> > Darrell
> >
> >
> > On Tue, 31 Jan 2023 at 13:34, Darrell Kavanagh
> > <darrell.kavanagh@gmail.com> wrote:  
> > >
> > > Just a quick update on testing: I'm finding what look like
> > > interactions between the kernel parm
> > > video=DSI-1:panel_orientation=right_side_up and the sensor, which also
> > > seem to differ depending on whether I'm in an X or Wayland session.
> > > I'm documenting the effects of the various combinations and will post
> > > my results when complete.
> > >
> > > Thanks,
> > > Darrell
> > >
> > >
> > >
> > >
> > >
> > > On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > >
> > > > On Mon, 30 Jan 2023 20:02:31 +0000
> > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > >  
> > > > > Thanks. To be clear, before I changed the grub command line, the
> > > > > system always booted up "sideways", even when the sensor was not being
> > > > > detected. This was true for everything, not just Gnome, except grub
> > > > > itself.
> > > > >
> > > > > I added:
> > > > >
> > > > > GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> > > > > video=DSI-1:panel_orientation=right_side_up quiet splash"
> > > > >
> > > > > This fixed the orientation for pre-splash boot messages, the splash
> > > > > screen and the desktop environment. But not, for example (as I saw
> > > > > after adding my own module signing key for testing your fixes), the
> > > > > MOK validation screens.
> > > > >
> > > > > Does this make sense?
> > > > >
> > > > > Does what you are proposing act at a lower level than changing the
> > > > > systemd hwdb orientation matrix?  
> > > >
> > > > I'm not sure on the userspace side of things, but intent is that
> > > > it will provide the orientation data to any users - though only after
> > > > the kernel boots and software needs to be aware of it.  Give it a go,
> > > > and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
> > > >
> > > > For Bastien - patches for kernel side are:
> > > > https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
> > > >
> > > > Darrell is going to test them after back porting to 6.1.
> > > > With the first patch he gets the right result in gnome but we weren't
> > > > picking up the rotation matrix at that point (ROTM in ACPI).
> > > >
> > > > Thanks,
> > > >
> > > > Jonathan
> > > >  
> > > > >
> > > > > Thanks,
> > > > > Darrell
> > > > >
> > > > > On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > > >
> > > > > > On Mon, 30 Jan 2023 18:32:02 +0000
> > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > >  
> > > > > > > On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> > > > > > > <Jonathan.Cameron@huawei.com> wrote:
> > > > > > >  
> > > > > > > > That certainly looks like suitable matrix.
> > > > > > > >
> > > > > > > > If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> > > > > > > > named method.  That is going to swap the x and y axis which is I'd have thought would
> > > > > > > > be rather bad if what you have is currently working well.
> > > > > > > >  
> > > > > > >
> > > > > > > Actually, that would be good, because at present I have to rotate 90
> > > > > > > degrees in my grub command line.  
> > > > > > :)
> > > > > >
> > > > > > I'll see if I can roll a suitable patch.
> > > > > >
> > > > > > Jonathan
> > > > > >  
> > > > > > >
> > > > > > > Darrell
> > > > > > >  
> > > > > > > > >             }
> > > > > > > > >
> > > > > > > > >             Method (PRIM, 0, NotSerialized)
> > > > > > > > >             {
> > > > > > > > >                 Name (RBUF, Buffer (One)
> > > > > > > > >                 {
> > > > > > > > >                      0x01                                             // .
> > > > > > > > >                 })
> > > > > > > > >                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> > > > > > > > >             }
> > > > > > > > >
> > > > > > > > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > > > > > > > >             {
> > > > > > > > >                 If ((GAVT == 0x6A))
> > > > > > > > >                 {
> > > > > > > > >                     Return (0x0F)
> > > > > > > > >                 }
> > > > > > > > >                 Else
> > > > > > > > >                 {
> > > > > > > > >                     Return (Zero)
> > > > > > > > >                 }
> > > > > > > > >             }
> > > > > > > > >
> > > > > > > > >             Method (CALS, 1, NotSerialized)
> > > > > > > > >             {
> > > > > > > > >                 Local0 = Arg0
> > > > > > > > >                 If (((Local0 == Zero) || (Local0 == Ones)))
> > > > > > > > >                 {
> > > > > > > > >                     Local0 = BAC1 /* \BAC1 */
> > > > > > > > >                     Return (Local0)
> > > > > > > > >                 }
> > > > > > > > >                 Else
> > > > > > > > >                 {
> > > > > > > > >                     BAC1 = Local0
> > > > > > > > >                     BACS = Local0
> > > > > > > > >                     BSCA (0xB0)
> > > > > > > > >                 }
> > > > > > > > >             }
> > > > > > > > >         }
> > > > > > > > >     }
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Darrell
> > > > > > > > >
> > > > > > > > > On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> > > > > > > > > <Jonathan.Cameron@huawei.com> wrote:  
> > > > > > > > > >
> > > > > > > > > > On Mon, 30 Jan 2023 03:37:23 +0000
> > > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > > >  
> > > > > > > > > > > Forwarding because original html messages were rejected by the server...
> > > > > > > > > > >
> > > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > > From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> > > > > > > > > > > Date: Mon, 30 Jan 2023 at 02:52
> > > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> > > > > > > > > > > Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > > To: Jonathan Cameron <jic23@kernel.org>
> > > > > > > > > > > Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> > > > > > > > > > > <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> > > > > > > > > > > <carnil@debian.org>
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Jonathan,
> > > > > > > > > > >
> > > > > > > > > > > Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> > > > > > > > > > > that 6.2 includes some i2c enhancements), but I adapted your changes
> > > > > > > > > > > to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> > > > > > > > > > > in sysfs, iio-sensor-proxy.service starts up and automatic screen
> > > > > > > > > > > rotation in Gnome just works.
> > > > > > > > > > >
> > > > > > > > > > > To get the modules to load on boot, I made a small change to your code
> > > > > > > > > > > in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> > > > > > > > > > >
> > > > > > > > > > > adding a null element to st_lsm6dsx_i2c_acpi_match:
> > > > > > > > > > >     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > > >          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > > >          { },
> > > > > > > > > > >     };
> > > > > > > > > > > then:
> > > > > > > > > > >    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);  
> > > > > > > > > >
> > > > > > > > > > doh! That was indeed sloppy of me to miss even for an untested hack.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >  
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > dmesg shows:
> > > > > > > > > > >
> > > > > > > > > > > [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> > > > > > > > > > > using dummy regulator
> > > > > > > > > > > [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> > > > > > > > > > > using dummy regulator
> > > > > > > > > > > [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> > > > > > > > > > > found: using identity...
> > > > > > > > > > >
> > > > > > > > > > > Is this a problem?  
> > > > > > > > > >
> > > > > > > > > > Those are all fine. For regulators that's expected on ACPI and should
> > > > > > > > > > be harmless as it's up to the firmware to manage power (in DT it may
> > > > > > > > > > be up to the kernel).
> > > > > > > > > > For the mounting matrix, there is often something in ACPI DSDT
> > > > > > > > > > (non standard though).  Could you
> > > > > > > > > > cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> > > > > > > > > > then run through iasl from acpitools
> > > > > > > > > > iasl -d ~/dsdt
> > > > > > > > > > and find the bit related to this device.
> > > > > > > > > >
> > > > > > > > > > If you can then share that there may be a _DSM or similar in there that
> > > > > > > > > > is effectively the mounting matrix.  If we are lucky it will look like
> > > > > > > > > > some existing versions we have code to handle and can add that support
> > > > > > > > > > as well.
> > > > > > > > > >
> > > > > > > > > > Either way - I'll spin a formal patch with your fixes above and we can
> > > > > > > > > > get this upstream for future kernels.  Mounting matrix can follow
> > > > > > > > > > later if needed.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > Jonathan
> > > > > > > > > >
> > > > > > > > > >  
> > > > > > > > > > >
> > > > > > > > > > > Thanks again.
> > > > > > > > > > >
> > > > > > > > > > > Darrell
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, 29 Jan 2023 17:03:51 +0000
> > > > > > > > > > > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > > > > > > > > > > >  
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I raised this bug in Debian, and have been asked to raise it upstream and
> > > > > > > > > > > > > was given your addresses to do so. Will this email be OK, or should I raise
> > > > > > > > > > > > > it in a bug tracking system somewhere?  
> > > > > > > > > > > >
> > > > > > > > > > > > Email is the right option.
> > > > > > > > > > > >  
> > > > > > > > > > > > >
> > > > > > > > > > > > > Many thanks,
> > > > > > > > > > > > > Darrell
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > ---------- Forwarded message ---------
> > > > > > > > > > > > > From: Salvatore Bonaccorso <carnil@debian.org>
> > > > > > > > > > > > > Date: Sat, 28 Jan 2023 at 20:33
> > > > > > > > > > > > > Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> > > > > > > > > > > > > LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> > > > > > > > > > > > > To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Darrell,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
> > > > > > > > > > > > > > Package: src:linux
> > > > > > > > > > > > > > Version: 6.1.4-1
> > > > > > > > > > > > > > Severity: normal
> > > > > > > > > > > > > > File: linux
> > > > > > > > > > > > > > X-Debbugs-Cc: darrell.kavanagh@gmail.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Dear Maintainer,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is a convertable touchscreen tablet/laptop. The rotation sensor  
> > > > > > > > > > > > > device  
> > > > > > > > > > > > > > ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
> > > > > > > > > > > > > and the  
> > > > > > > > > > > > > > sysfs trees are created at  
> > > > > > > > > > > > > devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
> > > > > > > > > > > > > > and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> > > > > > > > > > > > > > symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
> > > > > > > > > > > > > but  
> > > > > > > > > > > > > > no driver is loaded.  
> > > > > > > > > > > >
> > > > > > > > > > > > At least this is using the ST PNP ID which is better than average
> > > > > > > > > > > > (long story!)
> > > > > > > > > > > >
> > > > > > > > > > > > The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > > does not currently have an ACPI support.  It should be straight forwards
> > > > > > > > > > > > to add though the driver first needs converting to use
> > > > > > > > > > > > device_get_match_data() with appropriate fallback so that it will match on
> > > > > > > > > > > > ACPI, OF or original spi_device_id tables
> > > > > > > > > > > >
> > > > > > > > > > > > Completely untested but something like the following
> > > > > > > > > > > > (the offset in the enum is needed to allow us to tell if we got a result when
> > > > > > > > > > > > calling device_get_match_data() as it returns NULL on failure IIRC)
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> > > > > > > > > > > > it may get you basic functionality.
> > > > > > > > > > > >
> > > > > > > > > > > > Good luck and others more familiar with the driver may well tell me what I forgot
> > > > > > > > > > > > when hacking the below ;)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > > index 499fcf8875b4..2617ce236ddc 100644
> > > > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> > > > > > > > > > > > @@ -39,7 +39,7 @@
> > > > > > > > > > > >  #define ST_ISM330IS_DEV_NAME   "ism330is"
> > > > > > > > > > > >
> > > > > > > > > > > >  enum st_lsm6dsx_hw_id {
> > > > > > > > > > > > -       ST_LSM6DS3_ID,
> > > > > > > > > > > > +       ST_LSM6DS3_ID = 1,
> > > > > > > > > > > >         ST_LSM6DS3H_ID,
> > > > > > > > > > > >         ST_LSM6DSL_ID,
> > > > > > > > > > > >         ST_LSM6DSM_ID,
> > > > > > > > > > > > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > > index df5f60925260..ecfceb2fb3db 100644
> > > > > > > > > > > > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> > > > > > > > > > > > @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> > > > > > > > > > > >
> > > > > > > > > > > >  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> > > > > > > > > > > >  {
> > > > > > > > > > > > -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> > > > > > > > > > > > -       int hw_id = id->driver_data;
> > > > > > > > > > > > +       int hw_id;
> > > > > > > > > > > >         struct regmap *regmap;
> > > > > > > > > > > >
> > > > > > > > > > > > +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> > > > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > > > +               hw_id = i2c_client_get_device_id(client)->driver_data;
> > > > > > > > > > > > +       if (!hw_id)
> > > > > > > > > > > > +               return -EINVAL;
> > > > > > > > > > > > +
> > > > > > > > > > > >         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> > > > > > > > > > > >         if (IS_ERR(regmap)) {
> > > > > > > > > > > >                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> > > > > > > > > > > > @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> > > > > > > > > > > >  };
> > > > > > > > > > > >  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> > > > > > > > > > > >
> > > > > > > > > > > > +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> > > > > > > > > > > > +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> > > > > > > > > > > > +};
> > > > > > > > > > > > +
> > > > > > > > > > > >  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> > > > > > > > > > > >         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> > > > > > > > > > > >         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> > > > > > > > > > > > @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> > > > > > > > > > > >                 .name = "st_lsm6dsx_i2c",
> > > > > > > > > > > >                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> > > > > > > > > > > >                 .of_match_table = st_lsm6dsx_i2c_of_match,
> > > > > > > > > > > > +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> > > > > > > > > > > >         },
> > > > > > > > > > > >         .probe_new = st_lsm6dsx_i2c_probe,
> > > > > > > > > > > >         .id_table = st_lsm6dsx_i2c_id_table,
> > > > > > > > > > > >
> > > > > > > > > > > >  
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The device is identifying itself to the kernel with PNP id SMO8B30:
> > > > > > > > > > > > > > physical_node:
> > > > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > > >       name=SMO8B30:00
> > > > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > > >       waiting_for_supplier=0
> > > > > > > > > > > > > > firmware_node:
> > > > > > > > > > > > > >       hid=SMO8B30
> > > > > > > > > > > > > >       modalias=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > > >       path=\_SB_.PCI0.I2C5.DEV_
> > > > > > > > > > > > > >       status=15
> > > > > > > > > > > > > >       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> > > > > > > > > > > > > >       uid=0
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
> > > > > > > > > > > > > loaded on boot.  
> > > > > > > > > > > > > > Modprobing it does not associate it with the device, as I would expect as
> > > > > > > > > > > > > > the module does not provide an alias for the above acpi/pnp id.  
> > > > > > > > > > > > >
> > > > > > > > > > > > > Can you report this issue upstream? Gues to reach out are according to
> > > > > > > > > > > > > get_maintainers.pl script:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > > > Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > > > Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> > > > > > > > > > > > > linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> > > > > > > > > > > > > linux-kernel@vger.kernel.org (open list)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please keep us in the loop.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > Salvatore  
> > > > > > > > > > > >  
> > > > > > > > > >  
> > > > > > > >  
> > > > > >  
> > > >  


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 10:28                             ` Jonathan Cameron
@ 2023-02-01 11:00                               ` Hans de Goede
  2023-02-01 15:03                                 ` Darrell Kavanagh
  2023-02-01 16:12                                 ` Bastien Nocera
  0 siblings, 2 replies; 29+ messages in thread
From: Hans de Goede @ 2023-02-01 11:00 UTC (permalink / raw)
  To: Jonathan Cameron, Darrell Kavanagh
  Cc: Jonathan Cameron, linux-iio, linux-kernel, Bastien Nocera

Hi,

On 2/1/23 11:28, Jonathan Cameron wrote:
> On Wed, 1 Feb 2023 01:40:49 +0000
> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> 
>> Hello, all.
>>
>> I've finally reached a conclusion on this, after testing all the
>> combinations of the patches (with and without reading the acpi
>> mounting matrix), window managers (wayland, xorg) and the presence or
>> not of my custom kernel parms.
>>
>> What works well is the full set of patches with the custom kernel
>> parms and a new hwdb entry for the sensor:
>>
>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>
>> The autorotate then works correctly in wayland and xorg, but for xorg,
>> the settings say the screen is "portrait left" when in actual fact it
>> is in standard laptop landscape orientation. Wayland does not have
>> this problem (I guess because wayland's view of the screen is straight
>> from the kernel).
>>
>> Without the hwdb entry, the orientation is 90 degrees out without
>> using the acpi matrix and 180 degrees out when using it. I could have
>> gone either way here with appropriate hwdb entries, but my view is
>> that we *should* be using the matrix.
> 
> Added Hans de Goede as he has probably run into more of this mess
> than anyone else.  Hans, any thoughts on if we are doing something
> wrong on kernel side?  Or is the matrix just wrong *sigh*

I see below that this laptop has a panel which is mounted 90 degrees
rotated, that likely explains why the ACPI matrix does not work.
So the best thing to do here is to just override it with a hwdb entries.

IIRC there are already 1 or 2 other hwdb entries which actually
override the ACPI provided matrix because of similar issues.

Linux userspace expects the matrix in this case to be set so that
it causes e.g. gnome's auto-rotation to put the image upright
even with older gnome versions / mate / xfce which don't know about
the panel being mounted 90 degrees.

So e.g. "monitor-sensor" will report left-side-up or right-side-up
while the device is actually in normal clamshell mode with the
display up-right.

This reporting of left-side-up or right-side-up is actually "correct"
looking from the native LCD panel orientation and as mentioned is
done for backward compatibility. This is documented here:

https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54

The way we are handling this is likely incompatible with how Windows
handles this special case of 90° rotated screen + ROTM. Or the
matrix in the ACPI tables could be just wrong...

> I think 'ROTM' is defined by MS. 
> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries

Right and as such it would be good if we can still add support to
it to the sensor driver in question. Because the ROTM info usually
is correct and avoids the need for adding more and more hwdb entries.

Note there already is existing support in some other sensor drivers.

So we probably need to factor out some helper code for this and share
that between sensor drivers.


>> The only thing that concerns me is the need for custom kernel parms.
>> It would be better if there was a way to avoid this, so that the user
>> didn't have to mess around with their grub config. Though having said
>> that, the sensors fix as we have it doesn't make things worse - under
>> currently released kernels the screen always starts up sideways unless
>> custom parms are added in grub.

We actually have a quirk mechanism in the kernel for specifying
the need for: video=DSI-1:panel_orientation=right_side_up  and this
will also automatically fix the fbcon orientation, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c

If you submit a patch for this upstream please Cc me.

Regards,

Hans






>>> On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:  
>>>>
>>>> On Mon, 30 Jan 2023 20:02:31 +0000
>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>  
>>>>> Thanks. To be clear, before I changed the grub command line, the
>>>>> system always booted up "sideways", even when the sensor was not being
>>>>> detected. This was true for everything, not just Gnome, except grub
>>>>> itself.
>>>>>
>>>>> I added:
>>>>>
>>>>> GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
>>>>> video=DSI-1:panel_orientation=right_side_up quiet splash"
>>>>>
>>>>> This fixed the orientation for pre-splash boot messages, the splash
>>>>> screen and the desktop environment. But not, for example (as I saw
>>>>> after adding my own module signing key for testing your fixes), the
>>>>> MOK validation screens.
>>>>>
>>>>> Does this make sense?
>>>>>
>>>>> Does what you are proposing act at a lower level than changing the
>>>>> systemd hwdb orientation matrix?  
>>>>
>>>> I'm not sure on the userspace side of things, but intent is that
>>>> it will provide the orientation data to any users - though only after
>>>> the kernel boots and software needs to be aware of it.  Give it a go,
>>>> and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
>>>>
>>>> For Bastien - patches for kernel side are:
>>>> https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
>>>>
>>>> Darrell is going to test them after back porting to 6.1.
>>>> With the first patch he gets the right result in gnome but we weren't
>>>> picking up the rotation matrix at that point (ROTM in ACPI).
>>>>
>>>> Thanks,
>>>>
>>>> Jonathan
>>>>  
>>>>>
>>>>> Thanks,
>>>>> Darrell
>>>>>
>>>>> On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:  
>>>>>>
>>>>>> On Mon, 30 Jan 2023 18:32:02 +0000
>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>  
>>>>>>> On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
>>>>>>> <Jonathan.Cameron@huawei.com> wrote:
>>>>>>>  
>>>>>>>> That certainly looks like suitable matrix.
>>>>>>>>
>>>>>>>> If we are lucky it matches the handling in bmc150-accel-core.c for an identically
>>>>>>>> named method.  That is going to swap the x and y axis which is I'd have thought would
>>>>>>>> be rather bad if what you have is currently working well.
>>>>>>>>  
>>>>>>>
>>>>>>> Actually, that would be good, because at present I have to rotate 90
>>>>>>> degrees in my grub command line.  
>>>>>> :)
>>>>>>
>>>>>> I'll see if I can roll a suitable patch.
>>>>>>
>>>>>> Jonathan
>>>>>>  
>>>>>>>
>>>>>>> Darrell
>>>>>>>  
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             Method (PRIM, 0, NotSerialized)
>>>>>>>>>             {
>>>>>>>>>                 Name (RBUF, Buffer (One)
>>>>>>>>>                 {
>>>>>>>>>                      0x01                                             // .
>>>>>>>>>                 })
>>>>>>>>>                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             Method (_STA, 0, NotSerialized)  // _STA: Status
>>>>>>>>>             {
>>>>>>>>>                 If ((GAVT == 0x6A))
>>>>>>>>>                 {
>>>>>>>>>                     Return (0x0F)
>>>>>>>>>                 }
>>>>>>>>>                 Else
>>>>>>>>>                 {
>>>>>>>>>                     Return (Zero)
>>>>>>>>>                 }
>>>>>>>>>             }
>>>>>>>>>
>>>>>>>>>             Method (CALS, 1, NotSerialized)
>>>>>>>>>             {
>>>>>>>>>                 Local0 = Arg0
>>>>>>>>>                 If (((Local0 == Zero) || (Local0 == Ones)))
>>>>>>>>>                 {
>>>>>>>>>                     Local0 = BAC1 /* \BAC1 */
>>>>>>>>>                     Return (Local0)
>>>>>>>>>                 }
>>>>>>>>>                 Else
>>>>>>>>>                 {
>>>>>>>>>                     BAC1 = Local0
>>>>>>>>>                     BACS = Local0
>>>>>>>>>                     BSCA (0xB0)
>>>>>>>>>                 }
>>>>>>>>>             }
>>>>>>>>>         }
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Darrell
>>>>>>>>>
>>>>>>>>> On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
>>>>>>>>> <Jonathan.Cameron@huawei.com> wrote:  
>>>>>>>>>>
>>>>>>>>>> On Mon, 30 Jan 2023 03:37:23 +0000
>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>>>  
>>>>>>>>>>> Forwarding because original html messages were rejected by the server...
>>>>>>>>>>>
>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>> From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
>>>>>>>>>>> Date: Mon, 30 Jan 2023 at 02:52
>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST
>>>>>>>>>>> Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
>>>>>>>>>>> To: Jonathan Cameron <jic23@kernel.org>
>>>>>>>>>>> Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
>>>>>>>>>>> <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
>>>>>>>>>>> <carnil@debian.org>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>>
>>>>>>>>>>> Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
>>>>>>>>>>> that 6.2 includes some i2c enhancements), but I adapted your changes
>>>>>>>>>>> to fit my Debian 6.1 kernel and it works. Two IIO devices are created
>>>>>>>>>>> in sysfs, iio-sensor-proxy.service starts up and automatic screen
>>>>>>>>>>> rotation in Gnome just works.
>>>>>>>>>>>
>>>>>>>>>>> To get the modules to load on boot, I made a small change to your code
>>>>>>>>>>> in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
>>>>>>>>>>>
>>>>>>>>>>> adding a null element to st_lsm6dsx_i2c_acpi_match:
>>>>>>>>>>>     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>>>>>>>>>>>          { "SMO8B30", ST_LSM6DS3TRC_ID, },
>>>>>>>>>>>          { },
>>>>>>>>>>>     };
>>>>>>>>>>> then:
>>>>>>>>>>>    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);  
>>>>>>>>>>
>>>>>>>>>> doh! That was indeed sloppy of me to miss even for an untested hack.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> dmesg shows:
>>>>>>>>>>>
>>>>>>>>>>> [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
>>>>>>>>>>> using dummy regulator
>>>>>>>>>>> [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
>>>>>>>>>>> using dummy regulator
>>>>>>>>>>> [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
>>>>>>>>>>> found: using identity...
>>>>>>>>>>>
>>>>>>>>>>> Is this a problem?  
>>>>>>>>>>
>>>>>>>>>> Those are all fine. For regulators that's expected on ACPI and should
>>>>>>>>>> be harmless as it's up to the firmware to manage power (in DT it may
>>>>>>>>>> be up to the kernel).
>>>>>>>>>> For the mounting matrix, there is often something in ACPI DSDT
>>>>>>>>>> (non standard though).  Could you
>>>>>>>>>> cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
>>>>>>>>>> then run through iasl from acpitools
>>>>>>>>>> iasl -d ~/dsdt
>>>>>>>>>> and find the bit related to this device.
>>>>>>>>>>
>>>>>>>>>> If you can then share that there may be a _DSM or similar in there that
>>>>>>>>>> is effectively the mounting matrix.  If we are lucky it will look like
>>>>>>>>>> some existing versions we have code to handle and can add that support
>>>>>>>>>> as well.
>>>>>>>>>>
>>>>>>>>>> Either way - I'll spin a formal patch with your fixes above and we can
>>>>>>>>>> get this upstream for future kernels.  Mounting matrix can follow
>>>>>>>>>> later if needed.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>  
>>>>>>>>>>>
>>>>>>>>>>> Thanks again.
>>>>>>>>>>>
>>>>>>>>>>> Darrell
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:  
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, 29 Jan 2023 17:03:51 +0000
>>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>>>>>  
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I raised this bug in Debian, and have been asked to raise it upstream and
>>>>>>>>>>>>> was given your addresses to do so. Will this email be OK, or should I raise
>>>>>>>>>>>>> it in a bug tracking system somewhere?  
>>>>>>>>>>>>
>>>>>>>>>>>> Email is the right option.
>>>>>>>>>>>>  
>>>>>>>>>>>>>
>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>> Darrell
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>>>> From: Salvatore Bonaccorso <carnil@debian.org>
>>>>>>>>>>>>> Date: Sat, 28 Jan 2023 at 20:33
>>>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
>>>>>>>>>>>>> LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
>>>>>>>>>>>>> To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Darrell,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:  
>>>>>>>>>>>>>> Package: src:linux
>>>>>>>>>>>>>> Version: 6.1.4-1
>>>>>>>>>>>>>> Severity: normal
>>>>>>>>>>>>>> File: linux
>>>>>>>>>>>>>> X-Debbugs-Cc: darrell.kavanagh@gmail.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dear Maintainer,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a convertable touchscreen tablet/laptop. The rotation sensor  
>>>>>>>>>>>>> device  
>>>>>>>>>>>>>> ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI  
>>>>>>>>>>>>> and the  
>>>>>>>>>>>>>> sysfs trees are created at  
>>>>>>>>>>>>> devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00  
>>>>>>>>>>>>>> and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
>>>>>>>>>>>>>> symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,  
>>>>>>>>>>>>> but  
>>>>>>>>>>>>>> no driver is loaded.  
>>>>>>>>>>>>
>>>>>>>>>>>> At least this is using the ST PNP ID which is better than average
>>>>>>>>>>>> (long story!)
>>>>>>>>>>>>
>>>>>>>>>>>> The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>> does not currently have an ACPI support.  It should be straight forwards
>>>>>>>>>>>> to add though the driver first needs converting to use
>>>>>>>>>>>> device_get_match_data() with appropriate fallback so that it will match on
>>>>>>>>>>>> ACPI, OF or original spi_device_id tables
>>>>>>>>>>>>
>>>>>>>>>>>> Completely untested but something like the following
>>>>>>>>>>>> (the offset in the enum is needed to allow us to tell if we got a result when
>>>>>>>>>>>> calling device_get_match_data() as it returns NULL on failure IIRC)
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure how sucessful the driver will be at finding any interrupts etc, but
>>>>>>>>>>>> it may get you basic functionality.
>>>>>>>>>>>>
>>>>>>>>>>>> Good luck and others more familiar with the driver may well tell me what I forgot
>>>>>>>>>>>> when hacking the below ;)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>> index 499fcf8875b4..2617ce236ddc 100644
>>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>> @@ -39,7 +39,7 @@
>>>>>>>>>>>>  #define ST_ISM330IS_DEV_NAME   "ism330is"
>>>>>>>>>>>>
>>>>>>>>>>>>  enum st_lsm6dsx_hw_id {
>>>>>>>>>>>> -       ST_LSM6DS3_ID,
>>>>>>>>>>>> +       ST_LSM6DS3_ID = 1,
>>>>>>>>>>>>         ST_LSM6DS3H_ID,
>>>>>>>>>>>>         ST_LSM6DSL_ID,
>>>>>>>>>>>>         ST_LSM6DSM_ID,
>>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>> index df5f60925260..ecfceb2fb3db 100644
>>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>> @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
>>>>>>>>>>>>
>>>>>>>>>>>>  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
>>>>>>>>>>>>  {
>>>>>>>>>>>> -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
>>>>>>>>>>>> -       int hw_id = id->driver_data;
>>>>>>>>>>>> +       int hw_id;
>>>>>>>>>>>>         struct regmap *regmap;
>>>>>>>>>>>>
>>>>>>>>>>>> +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
>>>>>>>>>>>> +       if (!hw_id)
>>>>>>>>>>>> +               hw_id = i2c_client_get_device_id(client)->driver_data;
>>>>>>>>>>>> +       if (!hw_id)
>>>>>>>>>>>> +               return -EINVAL;
>>>>>>>>>>>> +
>>>>>>>>>>>>         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
>>>>>>>>>>>>         if (IS_ERR(regmap)) {
>>>>>>>>>>>>                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
>>>>>>>>>>>> @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
>>>>>>>>>>>>  };
>>>>>>>>>>>>  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
>>>>>>>>>>>>
>>>>>>>>>>>> +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>>>>>>>>>>>> +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
>>>>>>>>>>>> +};
>>>>>>>>>>>> +
>>>>>>>>>>>>  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
>>>>>>>>>>>>         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
>>>>>>>>>>>>         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
>>>>>>>>>>>> @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
>>>>>>>>>>>>                 .name = "st_lsm6dsx_i2c",
>>>>>>>>>>>>                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
>>>>>>>>>>>>                 .of_match_table = st_lsm6dsx_i2c_of_match,
>>>>>>>>>>>> +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
>>>>>>>>>>>>         },
>>>>>>>>>>>>         .probe_new = st_lsm6dsx_i2c_probe,
>>>>>>>>>>>>         .id_table = st_lsm6dsx_i2c_id_table,
>>>>>>>>>>>>
>>>>>>>>>>>>  
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The device is identifying itself to the kernel with PNP id SMO8B30:
>>>>>>>>>>>>>> physical_node:
>>>>>>>>>>>>>>       modalias=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>       name=SMO8B30:00
>>>>>>>>>>>>>>       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>       waiting_for_supplier=0
>>>>>>>>>>>>>> firmware_node:
>>>>>>>>>>>>>>       hid=SMO8B30
>>>>>>>>>>>>>>       modalias=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>       path=\_SB_.PCI0.I2C5.DEV_
>>>>>>>>>>>>>>       status=15
>>>>>>>>>>>>>>       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>       uid=0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not  
>>>>>>>>>>>>> loaded on boot.  
>>>>>>>>>>>>>> Modprobing it does not associate it with the device, as I would expect as
>>>>>>>>>>>>>> the module does not provide an alias for the above acpi/pnp id.  
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you report this issue upstream? Gues to reach out are according to
>>>>>>>>>>>>> get_maintainers.pl script:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
>>>>>>>>>>>>> Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
>>>>>>>>>>>>> Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
>>>>>>>>>>>>> linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
>>>>>>>>>>>>> linux-kernel@vger.kernel.org (open list)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please keep us in the loop.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Salvatore  
>>>>>>>>>>>>  
>>>>>>>>>>  
>>>>>>>>  
>>>>>>  
>>>>  
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 11:00                               ` Hans de Goede
@ 2023-02-01 15:03                                 ` Darrell Kavanagh
  2023-02-01 15:46                                   ` Hans de Goede
  2023-02-01 16:12                                 ` Bastien Nocera
  1 sibling, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-01 15:03 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, linux-kernel,
	Bastien Nocera

Thanks for the info, Hans. I was hoping there'd be something like
that. Compiling the whole kernel on this little machine will be
interesting, though...

On Wed, 1 Feb 2023 at 11:01, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 2/1/23 11:28, Jonathan Cameron wrote:
> > On Wed, 1 Feb 2023 01:40:49 +0000
> > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >
> >> Hello, all.
> >>
> >> I've finally reached a conclusion on this, after testing all the
> >> combinations of the patches (with and without reading the acpi
> >> mounting matrix), window managers (wayland, xorg) and the presence or
> >> not of my custom kernel parms.
> >>
> >> What works well is the full set of patches with the custom kernel
> >> parms and a new hwdb entry for the sensor:
> >>
> >> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> >>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> >>
> >> The autorotate then works correctly in wayland and xorg, but for xorg,
> >> the settings say the screen is "portrait left" when in actual fact it
> >> is in standard laptop landscape orientation. Wayland does not have
> >> this problem (I guess because wayland's view of the screen is straight
> >> from the kernel).
> >>
> >> Without the hwdb entry, the orientation is 90 degrees out without
> >> using the acpi matrix and 180 degrees out when using it. I could have
> >> gone either way here with appropriate hwdb entries, but my view is
> >> that we *should* be using the matrix.
> >
> > Added Hans de Goede as he has probably run into more of this mess
> > than anyone else.  Hans, any thoughts on if we are doing something
> > wrong on kernel side?  Or is the matrix just wrong *sigh*
>
> I see below that this laptop has a panel which is mounted 90 degrees
> rotated, that likely explains why the ACPI matrix does not work.
> So the best thing to do here is to just override it with a hwdb entries.
>
> IIRC there are already 1 or 2 other hwdb entries which actually
> override the ACPI provided matrix because of similar issues.
>
> Linux userspace expects the matrix in this case to be set so that
> it causes e.g. gnome's auto-rotation to put the image upright
> even with older gnome versions / mate / xfce which don't know about
> the panel being mounted 90 degrees.
>
> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> while the device is actually in normal clamshell mode with the
> display up-right.
>
> This reporting of left-side-up or right-side-up is actually "correct"
> looking from the native LCD panel orientation and as mentioned is
> done for backward compatibility. This is documented here:
>
> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>
> The way we are handling this is likely incompatible with how Windows
> handles this special case of 90° rotated screen + ROTM. Or the
> matrix in the ACPI tables could be just wrong...
>
> > I think 'ROTM' is defined by MS.
> > https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>
> Right and as such it would be good if we can still add support to
> it to the sensor driver in question. Because the ROTM info usually
> is correct and avoids the need for adding more and more hwdb entries.
>
> Note there already is existing support in some other sensor drivers.
>
> So we probably need to factor out some helper code for this and share
> that between sensor drivers.
>
>
> >> The only thing that concerns me is the need for custom kernel parms.
> >> It would be better if there was a way to avoid this, so that the user
> >> didn't have to mess around with their grub config. Though having said
> >> that, the sensors fix as we have it doesn't make things worse - under
> >> currently released kernels the screen always starts up sideways unless
> >> custom parms are added in grub.
>
> We actually have a quirk mechanism in the kernel for specifying
> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> will also automatically fix the fbcon orientation, see:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>
> If you submit a patch for this upstream please Cc me.
>
> Regards,
>
> Hans
>
>
>
>
>
>
> >>> On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:
> >>>>
> >>>> On Mon, 30 Jan 2023 20:02:31 +0000
> >>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>
> >>>>> Thanks. To be clear, before I changed the grub command line, the
> >>>>> system always booted up "sideways", even when the sensor was not being
> >>>>> detected. This was true for everything, not just Gnome, except grub
> >>>>> itself.
> >>>>>
> >>>>> I added:
> >>>>>
> >>>>> GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
> >>>>> video=DSI-1:panel_orientation=right_side_up quiet splash"
> >>>>>
> >>>>> This fixed the orientation for pre-splash boot messages, the splash
> >>>>> screen and the desktop environment. But not, for example (as I saw
> >>>>> after adding my own module signing key for testing your fixes), the
> >>>>> MOK validation screens.
> >>>>>
> >>>>> Does this make sense?
> >>>>>
> >>>>> Does what you are proposing act at a lower level than changing the
> >>>>> systemd hwdb orientation matrix?
> >>>>
> >>>> I'm not sure on the userspace side of things, but intent is that
> >>>> it will provide the orientation data to any users - though only after
> >>>> the kernel boots and software needs to be aware of it.  Give it a go,
> >>>> and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
> >>>>
> >>>> For Bastien - patches for kernel side are:
> >>>> https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
> >>>>
> >>>> Darrell is going to test them after back porting to 6.1.
> >>>> With the first patch he gets the right result in gnome but we weren't
> >>>> picking up the rotation matrix at that point (ROTM in ACPI).
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jonathan
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Darrell
> >>>>>
> >>>>> On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
> >>>>>>
> >>>>>> On Mon, 30 Jan 2023 18:32:02 +0000
> >>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>>>
> >>>>>>> On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
> >>>>>>> <Jonathan.Cameron@huawei.com> wrote:
> >>>>>>>
> >>>>>>>> That certainly looks like suitable matrix.
> >>>>>>>>
> >>>>>>>> If we are lucky it matches the handling in bmc150-accel-core.c for an identically
> >>>>>>>> named method.  That is going to swap the x and y axis which is I'd have thought would
> >>>>>>>> be rather bad if what you have is currently working well.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Actually, that would be good, because at present I have to rotate 90
> >>>>>>> degrees in my grub command line.
> >>>>>> :)
> >>>>>>
> >>>>>> I'll see if I can roll a suitable patch.
> >>>>>>
> >>>>>> Jonathan
> >>>>>>
> >>>>>>>
> >>>>>>> Darrell
> >>>>>>>
> >>>>>>>>>             }
> >>>>>>>>>
> >>>>>>>>>             Method (PRIM, 0, NotSerialized)
> >>>>>>>>>             {
> >>>>>>>>>                 Name (RBUF, Buffer (One)
> >>>>>>>>>                 {
> >>>>>>>>>                      0x01                                             // .
> >>>>>>>>>                 })
> >>>>>>>>>                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
> >>>>>>>>>             }
> >>>>>>>>>
> >>>>>>>>>             Method (_STA, 0, NotSerialized)  // _STA: Status
> >>>>>>>>>             {
> >>>>>>>>>                 If ((GAVT == 0x6A))
> >>>>>>>>>                 {
> >>>>>>>>>                     Return (0x0F)
> >>>>>>>>>                 }
> >>>>>>>>>                 Else
> >>>>>>>>>                 {
> >>>>>>>>>                     Return (Zero)
> >>>>>>>>>                 }
> >>>>>>>>>             }
> >>>>>>>>>
> >>>>>>>>>             Method (CALS, 1, NotSerialized)
> >>>>>>>>>             {
> >>>>>>>>>                 Local0 = Arg0
> >>>>>>>>>                 If (((Local0 == Zero) || (Local0 == Ones)))
> >>>>>>>>>                 {
> >>>>>>>>>                     Local0 = BAC1 /* \BAC1 */
> >>>>>>>>>                     Return (Local0)
> >>>>>>>>>                 }
> >>>>>>>>>                 Else
> >>>>>>>>>                 {
> >>>>>>>>>                     BAC1 = Local0
> >>>>>>>>>                     BACS = Local0
> >>>>>>>>>                     BSCA (0xB0)
> >>>>>>>>>                 }
> >>>>>>>>>             }
> >>>>>>>>>         }
> >>>>>>>>>     }
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Darrell
> >>>>>>>>>
> >>>>>>>>> On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
> >>>>>>>>> <Jonathan.Cameron@huawei.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 30 Jan 2023 03:37:23 +0000
> >>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Forwarding because original html messages were rejected by the server...
> >>>>>>>>>>>
> >>>>>>>>>>> ---------- Forwarded message ---------
> >>>>>>>>>>> From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
> >>>>>>>>>>> Date: Mon, 30 Jan 2023 at 02:52
> >>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST
> >>>>>>>>>>> Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> >>>>>>>>>>> To: Jonathan Cameron <jic23@kernel.org>
> >>>>>>>>>>> Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
> >>>>>>>>>>> <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
> >>>>>>>>>>> <carnil@debian.org>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Jonathan,
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
> >>>>>>>>>>> that 6.2 includes some i2c enhancements), but I adapted your changes
> >>>>>>>>>>> to fit my Debian 6.1 kernel and it works. Two IIO devices are created
> >>>>>>>>>>> in sysfs, iio-sensor-proxy.service starts up and automatic screen
> >>>>>>>>>>> rotation in Gnome just works.
> >>>>>>>>>>>
> >>>>>>>>>>> To get the modules to load on boot, I made a small change to your code
> >>>>>>>>>>> in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
> >>>>>>>>>>>
> >>>>>>>>>>> adding a null element to st_lsm6dsx_i2c_acpi_match:
> >>>>>>>>>>>     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> >>>>>>>>>>>          { "SMO8B30", ST_LSM6DS3TRC_ID, },
> >>>>>>>>>>>          { },
> >>>>>>>>>>>     };
> >>>>>>>>>>> then:
> >>>>>>>>>>>    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
> >>>>>>>>>>
> >>>>>>>>>> doh! That was indeed sloppy of me to miss even for an untested hack.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> dmesg shows:
> >>>>>>>>>>>
> >>>>>>>>>>> [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
> >>>>>>>>>>> using dummy regulator
> >>>>>>>>>>> [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
> >>>>>>>>>>> using dummy regulator
> >>>>>>>>>>> [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
> >>>>>>>>>>> found: using identity...
> >>>>>>>>>>>
> >>>>>>>>>>> Is this a problem?
> >>>>>>>>>>
> >>>>>>>>>> Those are all fine. For regulators that's expected on ACPI and should
> >>>>>>>>>> be harmless as it's up to the firmware to manage power (in DT it may
> >>>>>>>>>> be up to the kernel).
> >>>>>>>>>> For the mounting matrix, there is often something in ACPI DSDT
> >>>>>>>>>> (non standard though).  Could you
> >>>>>>>>>> cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
> >>>>>>>>>> then run through iasl from acpitools
> >>>>>>>>>> iasl -d ~/dsdt
> >>>>>>>>>> and find the bit related to this device.
> >>>>>>>>>>
> >>>>>>>>>> If you can then share that there may be a _DSM or similar in there that
> >>>>>>>>>> is effectively the mounting matrix.  If we are lucky it will look like
> >>>>>>>>>> some existing versions we have code to handle and can add that support
> >>>>>>>>>> as well.
> >>>>>>>>>>
> >>>>>>>>>> Either way - I'll spin a formal patch with your fixes above and we can
> >>>>>>>>>> get this upstream for future kernels.  Mounting matrix can follow
> >>>>>>>>>> later if needed.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Jonathan
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks again.
> >>>>>>>>>>>
> >>>>>>>>>>> Darrell
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sun, 29 Jan 2023 17:03:51 +0000
> >>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I raised this bug in Debian, and have been asked to raise it upstream and
> >>>>>>>>>>>>> was given your addresses to do so. Will this email be OK, or should I raise
> >>>>>>>>>>>>> it in a bug tracking system somewhere?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Email is the right option.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Many thanks,
> >>>>>>>>>>>>> Darrell
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ---------- Forwarded message ---------
> >>>>>>>>>>>>> From: Salvatore Bonaccorso <carnil@debian.org>
> >>>>>>>>>>>>> Date: Sat, 28 Jan 2023 at 20:33
> >>>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
> >>>>>>>>>>>>> LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
> >>>>>>>>>>>>> To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Darrell,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
> >>>>>>>>>>>>>> Package: src:linux
> >>>>>>>>>>>>>> Version: 6.1.4-1
> >>>>>>>>>>>>>> Severity: normal
> >>>>>>>>>>>>>> File: linux
> >>>>>>>>>>>>>> X-Debbugs-Cc: darrell.kavanagh@gmail.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Dear Maintainer,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This is a convertable touchscreen tablet/laptop. The rotation sensor
> >>>>>>>>>>>>> device
> >>>>>>>>>>>>>> ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
> >>>>>>>>>>>>> and the
> >>>>>>>>>>>>>> sysfs trees are created at
> >>>>>>>>>>>>> devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> >>>>>>>>>>>>>> and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> >>>>>>>>>>>>>> symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
> >>>>>>>>>>>>> but
> >>>>>>>>>>>>>> no driver is loaded.
> >>>>>>>>>>>>
> >>>>>>>>>>>> At least this is using the ST PNP ID which is better than average
> >>>>>>>>>>>> (long story!)
> >>>>>>>>>>>>
> >>>>>>>>>>>> The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> >>>>>>>>>>>> does not currently have an ACPI support.  It should be straight forwards
> >>>>>>>>>>>> to add though the driver first needs converting to use
> >>>>>>>>>>>> device_get_match_data() with appropriate fallback so that it will match on
> >>>>>>>>>>>> ACPI, OF or original spi_device_id tables
> >>>>>>>>>>>>
> >>>>>>>>>>>> Completely untested but something like the following
> >>>>>>>>>>>> (the offset in the enum is needed to allow us to tell if we got a result when
> >>>>>>>>>>>> calling device_get_match_data() as it returns NULL on failure IIRC)
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm not sure how sucessful the driver will be at finding any interrupts etc, but
> >>>>>>>>>>>> it may get you basic functionality.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Good luck and others more familiar with the driver may well tell me what I forgot
> >>>>>>>>>>>> when hacking the below ;)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> >>>>>>>>>>>> index 499fcf8875b4..2617ce236ddc 100644
> >>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> >>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> >>>>>>>>>>>> @@ -39,7 +39,7 @@
> >>>>>>>>>>>>  #define ST_ISM330IS_DEV_NAME   "ism330is"
> >>>>>>>>>>>>
> >>>>>>>>>>>>  enum st_lsm6dsx_hw_id {
> >>>>>>>>>>>> -       ST_LSM6DS3_ID,
> >>>>>>>>>>>> +       ST_LSM6DS3_ID = 1,
> >>>>>>>>>>>>         ST_LSM6DS3H_ID,
> >>>>>>>>>>>>         ST_LSM6DSL_ID,
> >>>>>>>>>>>>         ST_LSM6DSM_ID,
> >>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> >>>>>>>>>>>> index df5f60925260..ecfceb2fb3db 100644
> >>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> >>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> >>>>>>>>>>>> @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
> >>>>>>>>>>>>
> >>>>>>>>>>>>  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
> >>>>>>>>>>>>  {
> >>>>>>>>>>>> -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
> >>>>>>>>>>>> -       int hw_id = id->driver_data;
> >>>>>>>>>>>> +       int hw_id;
> >>>>>>>>>>>>         struct regmap *regmap;
> >>>>>>>>>>>>
> >>>>>>>>>>>> +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
> >>>>>>>>>>>> +       if (!hw_id)
> >>>>>>>>>>>> +               hw_id = i2c_client_get_device_id(client)->driver_data;
> >>>>>>>>>>>> +       if (!hw_id)
> >>>>>>>>>>>> +               return -EINVAL;
> >>>>>>>>>>>> +
> >>>>>>>>>>>>         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
> >>>>>>>>>>>>         if (IS_ERR(regmap)) {
> >>>>>>>>>>>>                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
> >>>>>>>>>>>> @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> >>>>>>>>>>>>  };
> >>>>>>>>>>>>  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> >>>>>>>>>>>>
> >>>>>>>>>>>> +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
> >>>>>>>>>>>> +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
> >>>>>>>>>>>> +};
> >>>>>>>>>>>> +
> >>>>>>>>>>>>  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> >>>>>>>>>>>>         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
> >>>>>>>>>>>>         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
> >>>>>>>>>>>> @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
> >>>>>>>>>>>>                 .name = "st_lsm6dsx_i2c",
> >>>>>>>>>>>>                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
> >>>>>>>>>>>>                 .of_match_table = st_lsm6dsx_i2c_of_match,
> >>>>>>>>>>>> +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
> >>>>>>>>>>>>         },
> >>>>>>>>>>>>         .probe_new = st_lsm6dsx_i2c_probe,
> >>>>>>>>>>>>         .id_table = st_lsm6dsx_i2c_id_table,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The device is identifying itself to the kernel with PNP id SMO8B30:
> >>>>>>>>>>>>>> physical_node:
> >>>>>>>>>>>>>>       modalias=acpi:SMO8B30:SMO8B30:
> >>>>>>>>>>>>>>       name=SMO8B30:00
> >>>>>>>>>>>>>>       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> >>>>>>>>>>>>>>       waiting_for_supplier=0
> >>>>>>>>>>>>>> firmware_node:
> >>>>>>>>>>>>>>       hid=SMO8B30
> >>>>>>>>>>>>>>       modalias=acpi:SMO8B30:SMO8B30:
> >>>>>>>>>>>>>>       path=\_SB_.PCI0.I2C5.DEV_
> >>>>>>>>>>>>>>       status=15
> >>>>>>>>>>>>>>       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
> >>>>>>>>>>>>>>       uid=0
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
> >>>>>>>>>>>>> loaded on boot.
> >>>>>>>>>>>>>> Modprobing it does not associate it with the device, as I would expect as
> >>>>>>>>>>>>>> the module does not provide an alias for the above acpi/pnp id.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Can you report this issue upstream? Gues to reach out are according to
> >>>>>>>>>>>>> get_maintainers.pl script:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
> >>>>>>>>>>>>> Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
> >>>>>>>>>>>>> Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
> >>>>>>>>>>>>> linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
> >>>>>>>>>>>>> linux-kernel@vger.kernel.org (open list)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please keep us in the loop.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Salvatore
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 15:03                                 ` Darrell Kavanagh
@ 2023-02-01 15:46                                   ` Hans de Goede
  0 siblings, 0 replies; 29+ messages in thread
From: Hans de Goede @ 2023-02-01 15:46 UTC (permalink / raw)
  To: Darrell Kavanagh
  Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, linux-kernel,
	Bastien Nocera

Hi,

On 2/1/23 16:03, Darrell Kavanagh wrote:
> Thanks for the info, Hans. I was hoping there'd be something like
> that. Compiling the whole kernel on this little machine will be
> interesting, though...

I usually build on a big machine and then also run "sudo make modules_install"
on the big machine (which normally will not conflict with distor kernels
since they have extra info in their version number) and then I do e.g.:

# on big machine:
make -j15 bzImage && make -j15 modules && sudo make modules_install

# on target, as root:
mkdir /lib/modules/6.2.0-rc6+

# on big machine
cd /lib/modules/6.2.0-rc6+/
scp -pr kernel modules.* root@192.168.1.97:/lib/modules/6.2.0-rc6+/
cd ~/projects/linux
cp arch/x86/boot/bzImage root@192.168.1.97:/boot/vmlinuz-6.2.0-rc6+

# on target, as root:
kernel-install add 6.2.0-rc6+ /boot/vmlinuz-6.2.0-rc6+

I believe you can also pass an alternate install location for the
modules, then you also don't need the sudo for the make modules_install,
but I tend to dogfood my own kernel tree on my $big-desktop-machine,
so I actually want the modules in /lib/modules/$version/ ...

Regards,

Hans



> On Wed, 1 Feb 2023 at 11:01, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 2/1/23 11:28, Jonathan Cameron wrote:
>>> On Wed, 1 Feb 2023 01:40:49 +0000
>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>
>>>> Hello, all.
>>>>
>>>> I've finally reached a conclusion on this, after testing all the
>>>> combinations of the patches (with and without reading the acpi
>>>> mounting matrix), window managers (wayland, xorg) and the presence or
>>>> not of my custom kernel parms.
>>>>
>>>> What works well is the full set of patches with the custom kernel
>>>> parms and a new hwdb entry for the sensor:
>>>>
>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>>>
>>>> The autorotate then works correctly in wayland and xorg, but for xorg,
>>>> the settings say the screen is "portrait left" when in actual fact it
>>>> is in standard laptop landscape orientation. Wayland does not have
>>>> this problem (I guess because wayland's view of the screen is straight
>>>> from the kernel).
>>>>
>>>> Without the hwdb entry, the orientation is 90 degrees out without
>>>> using the acpi matrix and 180 degrees out when using it. I could have
>>>> gone either way here with appropriate hwdb entries, but my view is
>>>> that we *should* be using the matrix.
>>>
>>> Added Hans de Goede as he has probably run into more of this mess
>>> than anyone else.  Hans, any thoughts on if we are doing something
>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
>>
>> I see below that this laptop has a panel which is mounted 90 degrees
>> rotated, that likely explains why the ACPI matrix does not work.
>> So the best thing to do here is to just override it with a hwdb entries.
>>
>> IIRC there are already 1 or 2 other hwdb entries which actually
>> override the ACPI provided matrix because of similar issues.
>>
>> Linux userspace expects the matrix in this case to be set so that
>> it causes e.g. gnome's auto-rotation to put the image upright
>> even with older gnome versions / mate / xfce which don't know about
>> the panel being mounted 90 degrees.
>>
>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
>> while the device is actually in normal clamshell mode with the
>> display up-right.
>>
>> This reporting of left-side-up or right-side-up is actually "correct"
>> looking from the native LCD panel orientation and as mentioned is
>> done for backward compatibility. This is documented here:
>>
>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>>
>> The way we are handling this is likely incompatible with how Windows
>> handles this special case of 90° rotated screen + ROTM. Or the
>> matrix in the ACPI tables could be just wrong...
>>
>>> I think 'ROTM' is defined by MS.
>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>>
>> Right and as such it would be good if we can still add support to
>> it to the sensor driver in question. Because the ROTM info usually
>> is correct and avoids the need for adding more and more hwdb entries.
>>
>> Note there already is existing support in some other sensor drivers.
>>
>> So we probably need to factor out some helper code for this and share
>> that between sensor drivers.
>>
>>
>>>> The only thing that concerns me is the need for custom kernel parms.
>>>> It would be better if there was a way to avoid this, so that the user
>>>> didn't have to mess around with their grub config. Though having said
>>>> that, the sensors fix as we have it doesn't make things worse - under
>>>> currently released kernels the screen always starts up sideways unless
>>>> custom parms are added in grub.
>>
>> We actually have a quirk mechanism in the kernel for specifying
>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
>> will also automatically fix the fbcon orientation, see:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>
>> If you submit a patch for this upstream please Cc me.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>
>>
>>>>> On Mon, 30 Jan 2023 at 20:17, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>>>
>>>>>> On Mon, 30 Jan 2023 20:02:31 +0000
>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks. To be clear, before I changed the grub command line, the
>>>>>>> system always booted up "sideways", even when the sensor was not being
>>>>>>> detected. This was true for everything, not just Gnome, except grub
>>>>>>> itself.
>>>>>>>
>>>>>>> I added:
>>>>>>>
>>>>>>> GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1
>>>>>>> video=DSI-1:panel_orientation=right_side_up quiet splash"
>>>>>>>
>>>>>>> This fixed the orientation for pre-splash boot messages, the splash
>>>>>>> screen and the desktop environment. But not, for example (as I saw
>>>>>>> after adding my own module signing key for testing your fixes), the
>>>>>>> MOK validation screens.
>>>>>>>
>>>>>>> Does this make sense?
>>>>>>>
>>>>>>> Does what you are proposing act at a lower level than changing the
>>>>>>> systemd hwdb orientation matrix?
>>>>>>
>>>>>> I'm not sure on the userspace side of things, but intent is that
>>>>>> it will provide the orientation data to any users - though only after
>>>>>> the kernel boots and software needs to be aware of it.  Give it a go,
>>>>>> and if not Bastien (IIRC wrote iio-sensor-proxy) may be able to advise.
>>>>>>
>>>>>> For Bastien - patches for kernel side are:
>>>>>> https://lore.kernel.org/linux-iio/20230130201018.981024-1-jic23@kernel.org/T/#t
>>>>>>
>>>>>> Darrell is going to test them after back porting to 6.1.
>>>>>> With the first patch he gets the right result in gnome but we weren't
>>>>>> picking up the rotation matrix at that point (ROTM in ACPI).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jonathan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Darrell
>>>>>>>
>>>>>>> On Mon, 30 Jan 2023 at 19:27, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Mon, 30 Jan 2023 18:32:02 +0000
>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Mon, 30 Jan 2023 at 17:35, Jonathan Cameron
>>>>>>>>> <Jonathan.Cameron@huawei.com> wrote:
>>>>>>>>>
>>>>>>>>>> That certainly looks like suitable matrix.
>>>>>>>>>>
>>>>>>>>>> If we are lucky it matches the handling in bmc150-accel-core.c for an identically
>>>>>>>>>> named method.  That is going to swap the x and y axis which is I'd have thought would
>>>>>>>>>> be rather bad if what you have is currently working well.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Actually, that would be good, because at present I have to rotate 90
>>>>>>>>> degrees in my grub command line.
>>>>>>>> :)
>>>>>>>>
>>>>>>>> I'll see if I can roll a suitable patch.
>>>>>>>>
>>>>>>>> Jonathan
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Darrell
>>>>>>>>>
>>>>>>>>>>>             }
>>>>>>>>>>>
>>>>>>>>>>>             Method (PRIM, 0, NotSerialized)
>>>>>>>>>>>             {
>>>>>>>>>>>                 Name (RBUF, Buffer (One)
>>>>>>>>>>>                 {
>>>>>>>>>>>                      0x01                                             // .
>>>>>>>>>>>                 })
>>>>>>>>>>>                 Return (RBUF) /* \_SB_.PCI0.I2C5.DEV_.PRIM.RBUF */
>>>>>>>>>>>             }
>>>>>>>>>>>
>>>>>>>>>>>             Method (_STA, 0, NotSerialized)  // _STA: Status
>>>>>>>>>>>             {
>>>>>>>>>>>                 If ((GAVT == 0x6A))
>>>>>>>>>>>                 {
>>>>>>>>>>>                     Return (0x0F)
>>>>>>>>>>>                 }
>>>>>>>>>>>                 Else
>>>>>>>>>>>                 {
>>>>>>>>>>>                     Return (Zero)
>>>>>>>>>>>                 }
>>>>>>>>>>>             }
>>>>>>>>>>>
>>>>>>>>>>>             Method (CALS, 1, NotSerialized)
>>>>>>>>>>>             {
>>>>>>>>>>>                 Local0 = Arg0
>>>>>>>>>>>                 If (((Local0 == Zero) || (Local0 == Ones)))
>>>>>>>>>>>                 {
>>>>>>>>>>>                     Local0 = BAC1 /* \BAC1 */
>>>>>>>>>>>                     Return (Local0)
>>>>>>>>>>>                 }
>>>>>>>>>>>                 Else
>>>>>>>>>>>                 {
>>>>>>>>>>>                     BAC1 = Local0
>>>>>>>>>>>                     BACS = Local0
>>>>>>>>>>>                     BSCA (0xB0)
>>>>>>>>>>>                 }
>>>>>>>>>>>             }
>>>>>>>>>>>         }
>>>>>>>>>>>     }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Darrell
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 30 Jan 2023 at 12:31, Jonathan Cameron
>>>>>>>>>>> <Jonathan.Cameron@huawei.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 30 Jan 2023 03:37:23 +0000
>>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Forwarding because original html messages were rejected by the server...
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>>>> From: Darrell Kavanagh <darrell.kavanagh@gmail.com>
>>>>>>>>>>>>> Date: Mon, 30 Jan 2023 at 02:52
>>>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST
>>>>>>>>>>>>> Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
>>>>>>>>>>>>> To: Jonathan Cameron <jic23@kernel.org>
>>>>>>>>>>>>> Cc: <lorenzo@kernel.org>, <lars@metafoo.de>,
>>>>>>>>>>>>> <linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
>>>>>>>>>>>>> <carnil@debian.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Jonathan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you. The driver has evolved quite a bit in 6.2 (I read somewhere
>>>>>>>>>>>>> that 6.2 includes some i2c enhancements), but I adapted your changes
>>>>>>>>>>>>> to fit my Debian 6.1 kernel and it works. Two IIO devices are created
>>>>>>>>>>>>> in sysfs, iio-sensor-proxy.service starts up and automatic screen
>>>>>>>>>>>>> rotation in Gnome just works.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To get the modules to load on boot, I made a small change to your code
>>>>>>>>>>>>> in st_lsm6dsx_i2c to add the acpi alias to modules.alias:
>>>>>>>>>>>>>
>>>>>>>>>>>>> adding a null element to st_lsm6dsx_i2c_acpi_match:
>>>>>>>>>>>>>     static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>>>>>>>>>>>>>          { "SMO8B30", ST_LSM6DS3TRC_ID, },
>>>>>>>>>>>>>          { },
>>>>>>>>>>>>>     };
>>>>>>>>>>>>> then:
>>>>>>>>>>>>>    MODULE_DEVICE_TABLE(acpi, st_lsm6dsx_i2c_acpi_match);
>>>>>>>>>>>>
>>>>>>>>>>>> doh! That was indeed sloppy of me to miss even for an untested hack.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> dmesg shows:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ 7366.120208] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vdd not found,
>>>>>>>>>>>>> using dummy regulator
>>>>>>>>>>>>> [ 7366.120260] st_lsm6dsx_i2c i2c-SMO8B30:00: supply vddio not found,
>>>>>>>>>>>>> using dummy regulator
>>>>>>>>>>>>> [ 7366.650839] st_lsm6dsx_i2c i2c-SMO8B30:00: mounting matrix not
>>>>>>>>>>>>> found: using identity...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is this a problem?
>>>>>>>>>>>>
>>>>>>>>>>>> Those are all fine. For regulators that's expected on ACPI and should
>>>>>>>>>>>> be harmless as it's up to the firmware to manage power (in DT it may
>>>>>>>>>>>> be up to the kernel).
>>>>>>>>>>>> For the mounting matrix, there is often something in ACPI DSDT
>>>>>>>>>>>> (non standard though).  Could you
>>>>>>>>>>>> cat /sys/firmware/acpi/tables/DSDT > ~/dsdt
>>>>>>>>>>>> then run through iasl from acpitools
>>>>>>>>>>>> iasl -d ~/dsdt
>>>>>>>>>>>> and find the bit related to this device.
>>>>>>>>>>>>
>>>>>>>>>>>> If you can then share that there may be a _DSM or similar in there that
>>>>>>>>>>>> is effectively the mounting matrix.  If we are lucky it will look like
>>>>>>>>>>>> some existing versions we have code to handle and can add that support
>>>>>>>>>>>> as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Either way - I'll spin a formal patch with your fixes above and we can
>>>>>>>>>>>> get this upstream for future kernels.  Mounting matrix can follow
>>>>>>>>>>>> later if needed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Darrell
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, 29 Jan 2023 at 18:10, Jonathan Cameron <jic23@kernel.org> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, 29 Jan 2023 17:03:51 +0000
>>>>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I raised this bug in Debian, and have been asked to raise it upstream and
>>>>>>>>>>>>>>> was given your addresses to do so. Will this email be OK, or should I raise
>>>>>>>>>>>>>>> it in a bug tracking system somewhere?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Email is the right option.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks,
>>>>>>>>>>>>>>> Darrell
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>>>>>> From: Salvatore Bonaccorso <carnil@debian.org>
>>>>>>>>>>>>>>> Date: Sat, 28 Jan 2023 at 20:33
>>>>>>>>>>>>>>> Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
>>>>>>>>>>>>>>> LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
>>>>>>>>>>>>>>> To: Darrell Kavanagh <darrell.kavanagh@gmail.com>, <1029850@bugs.debian.org>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Darrell,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sat, Jan 28, 2023 at 08:13:16PM +0000, Darrell Kavanagh wrote:
>>>>>>>>>>>>>>>> Package: src:linux
>>>>>>>>>>>>>>>> Version: 6.1.4-1
>>>>>>>>>>>>>>>> Severity: normal
>>>>>>>>>>>>>>>> File: linux
>>>>>>>>>>>>>>>> X-Debbugs-Cc: darrell.kavanagh@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dear Maintainer,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is a convertable touchscreen tablet/laptop. The rotation sensor
>>>>>>>>>>>>>>> device
>>>>>>>>>>>>>>>> ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI
>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>> sysfs trees are created at
>>>>>>>>>>>>>>> devices/pci0000:00/0000:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
>>>>>>>>>>>>>>>> and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
>>>>>>>>>>>>>>>> symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00,
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> no driver is loaded.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At least this is using the ST PNP ID which is better than average
>>>>>>>>>>>>>> (long story!)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The driver in question (ultimately drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> does not currently have an ACPI support.  It should be straight forwards
>>>>>>>>>>>>>> to add though the driver first needs converting to use
>>>>>>>>>>>>>> device_get_match_data() with appropriate fallback so that it will match on
>>>>>>>>>>>>>> ACPI, OF or original spi_device_id tables
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Completely untested but something like the following
>>>>>>>>>>>>>> (the offset in the enum is needed to allow us to tell if we got a result when
>>>>>>>>>>>>>> calling device_get_match_data() as it returns NULL on failure IIRC)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not sure how sucessful the driver will be at finding any interrupts etc, but
>>>>>>>>>>>>>> it may get you basic functionality.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Good luck and others more familiar with the driver may well tell me what I forgot
>>>>>>>>>>>>>> when hacking the below ;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>>>> index 499fcf8875b4..2617ce236ddc 100644
>>>>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
>>>>>>>>>>>>>> @@ -39,7 +39,7 @@
>>>>>>>>>>>>>>  #define ST_ISM330IS_DEV_NAME   "ism330is"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  enum st_lsm6dsx_hw_id {
>>>>>>>>>>>>>> -       ST_LSM6DS3_ID,
>>>>>>>>>>>>>> +       ST_LSM6DS3_ID = 1,
>>>>>>>>>>>>>>         ST_LSM6DS3H_ID,
>>>>>>>>>>>>>>         ST_LSM6DSL_ID,
>>>>>>>>>>>>>>         ST_LSM6DSM_ID,
>>>>>>>>>>>>>> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> index df5f60925260..ecfceb2fb3db 100644
>>>>>>>>>>>>>> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
>>>>>>>>>>>>>> @@ -23,10 +23,15 @@ static const struct regmap_config st_lsm6dsx_i2c_regmap_config = {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  static int st_lsm6dsx_i2c_probe(struct i2c_client *client)
>>>>>>>>>>>>>>  {
>>>>>>>>>>>>>> -       const struct i2c_device_id *id = i2c_client_get_device_id(client);
>>>>>>>>>>>>>> -       int hw_id = id->driver_data;
>>>>>>>>>>>>>> +       int hw_id;
>>>>>>>>>>>>>>         struct regmap *regmap;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +       hw_id = (kernel_ulong_t)device_get_match_data(&client->dev);
>>>>>>>>>>>>>> +       if (!hw_id)
>>>>>>>>>>>>>> +               hw_id = i2c_client_get_device_id(client)->driver_data;
>>>>>>>>>>>>>> +       if (!hw_id)
>>>>>>>>>>>>>> +               return -EINVAL;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>         regmap = devm_regmap_init_i2c(client, &st_lsm6dsx_i2c_regmap_config);
>>>>>>>>>>>>>>         if (IS_ERR(regmap)) {
>>>>>>>>>>>>>>                 dev_err(&client->dev, "Failed to register i2c regmap %ld\n", PTR_ERR(regmap));
>>>>>>>>>>>>>> @@ -129,6 +134,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>  MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +static const struct acpi_device_id st_lsm6dsx_i2c_acpi_match[] = {
>>>>>>>>>>>>>> +       { "SMO8B30", ST_LSM6DS3TRC_ID, },
>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>  static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
>>>>>>>>>>>>>>         { ST_LSM6DS3_DEV_NAME, ST_LSM6DS3_ID },
>>>>>>>>>>>>>>         { ST_LSM6DS3H_DEV_NAME, ST_LSM6DS3H_ID },
>>>>>>>>>>>>>> @@ -161,6 +170,7 @@ static struct i2c_driver st_lsm6dsx_driver = {
>>>>>>>>>>>>>>                 .name = "st_lsm6dsx_i2c",
>>>>>>>>>>>>>>                 .pm = pm_sleep_ptr(&st_lsm6dsx_pm_ops),
>>>>>>>>>>>>>>                 .of_match_table = st_lsm6dsx_i2c_of_match,
>>>>>>>>>>>>>> +               .acpi_match_table = st_lsm6dsx_i2c_acpi_match,
>>>>>>>>>>>>>>         },
>>>>>>>>>>>>>>         .probe_new = st_lsm6dsx_i2c_probe,
>>>>>>>>>>>>>>         .id_table = st_lsm6dsx_i2c_id_table,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The device is identifying itself to the kernel with PNP id SMO8B30:
>>>>>>>>>>>>>>>> physical_node:
>>>>>>>>>>>>>>>>       modalias=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>>       name=SMO8B30:00
>>>>>>>>>>>>>>>>       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>>       waiting_for_supplier=0
>>>>>>>>>>>>>>>> firmware_node:
>>>>>>>>>>>>>>>>       hid=SMO8B30
>>>>>>>>>>>>>>>>       modalias=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>>       path=\_SB_.PCI0.I2C5.DEV_
>>>>>>>>>>>>>>>>       status=15
>>>>>>>>>>>>>>>>       uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>>>>>>>>>>>>>>>>       uid=0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not
>>>>>>>>>>>>>>> loaded on boot.
>>>>>>>>>>>>>>>> Modprobing it does not associate it with the device, as I would expect as
>>>>>>>>>>>>>>>> the module does not provide an alias for the above acpi/pnp id.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you report this issue upstream? Gues to reach out are according to
>>>>>>>>>>>>>>> get_maintainers.pl script:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lorenzo Bianconi <lorenzo@kernel.org> (maintainer:ST LSM6DSx IMU IIO DRIVER)
>>>>>>>>>>>>>>> Jonathan Cameron <jic23@kernel.org> (maintainer:IIO SUBSYSTEM AND DRIVERS)
>>>>>>>>>>>>>>> Lars-Peter Clausen <lars@metafoo.de> (reviewer:IIO SUBSYSTEM AND DRIVERS)
>>>>>>>>>>>>>>> linux-iio@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
>>>>>>>>>>>>>>> linux-kernel@vger.kernel.org (open list)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please keep us in the loop.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Salvatore
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 11:00                               ` Hans de Goede
  2023-02-01 15:03                                 ` Darrell Kavanagh
@ 2023-02-01 16:12                                 ` Bastien Nocera
  2023-02-01 17:50                                   ` Darrell Kavanagh
  1 sibling, 1 reply; 29+ messages in thread
From: Bastien Nocera @ 2023-02-01 16:12 UTC (permalink / raw)
  To: Hans de Goede, Jonathan Cameron, Darrell Kavanagh
  Cc: Jonathan Cameron, linux-iio, linux-kernel

On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> Hi,
> 
> On 2/1/23 11:28, Jonathan Cameron wrote:
> > On Wed, 1 Feb 2023 01:40:49 +0000
> > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > 
> > > Hello, all.
> > > 
> > > I've finally reached a conclusion on this, after testing all the
> > > combinations of the patches (with and without reading the acpi
> > > mounting matrix), window managers (wayland, xorg) and the
> > > presence or
> > > not of my custom kernel parms.
> > > 
> > > What works well is the full set of patches with the custom kernel
> > > parms and a new hwdb entry for the sensor:
> > > 
> > > sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> > >  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> > > 
> > > The autorotate then works correctly in wayland and xorg, but for
> > > xorg,
> > > the settings say the screen is "portrait left" when in actual
> > > fact it
> > > is in standard laptop landscape orientation. Wayland does not
> > > have
> > > this problem (I guess because wayland's view of the screen is
> > > straight
> > > from the kernel).
> > > 
> > > Without the hwdb entry, the orientation is 90 degrees out without
> > > using the acpi matrix and 180 degrees out when using it. I could
> > > have
> > > gone either way here with appropriate hwdb entries, but my view
> > > is
> > > that we *should* be using the matrix.
> > 
> > Added Hans de Goede as he has probably run into more of this mess
> > than anyone else.  Hans, any thoughts on if we are doing something
> > wrong on kernel side?  Or is the matrix just wrong *sigh*
> 
> I see below that this laptop has a panel which is mounted 90 degrees
> rotated, that likely explains why the ACPI matrix does not work.
> So the best thing to do here is to just override it with a hwdb
> entries.
> 
> IIRC there are already 1 or 2 other hwdb entries which actually
> override the ACPI provided matrix because of similar issues.
> 
> Linux userspace expects the matrix in this case to be set so that
> it causes e.g. gnome's auto-rotation to put the image upright
> even with older gnome versions / mate / xfce which don't know about
> the panel being mounted 90 degrees.
> 
> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> while the device is actually in normal clamshell mode with the
> display up-right.
> 
> This reporting of left-side-up or right-side-up is actually "correct"
> looking from the native LCD panel orientation and as mentioned is
> done for backward compatibility. This is documented here:
> 
> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> 
> The way we are handling this is likely incompatible with how Windows
> handles this special case of 90° rotated screen + ROTM. Or the
> matrix in the ACPI tables could be just wrong...
> 
> > I think 'ROTM' is defined by MS. 
> > https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> 
> Right and as such it would be good if we can still add support to
> it to the sensor driver in question. Because the ROTM info usually
> is correct and avoids the need for adding more and more hwdb entries.
> 
> Note there already is existing support in some other sensor drivers.
> 
> So we probably need to factor out some helper code for this and share
> that between sensor drivers.
> 
> 
> > > The only thing that concerns me is the need for custom kernel
> > > parms.
> > > It would be better if there was a way to avoid this, so that the
> > > user
> > > didn't have to mess around with their grub config. Though having
> > > said
> > > that, the sensors fix as we have it doesn't make things worse -
> > > under
> > > currently released kernels the screen always starts up sideways
> > > unless
> > > custom parms are added in grub.
> 
> We actually have a quirk mechanism in the kernel for specifying
> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> will also automatically fix the fbcon orientation, see:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> 
> If you submit a patch for this upstream please Cc me.

And if after that change, and copy/pasting the orientation from the
DSDT into hwdb the sensor and screen move in the expected ways, then
maybe stealing the BMC150 driver's
bmc150_apply_bosc0200_acpi_orientation() might be a good idea.

Once exported through "mount_matrix", iio-sensor-proxy should see it
and read it without the need for a hwdb entry.

Cheers

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 16:12                                 ` Bastien Nocera
@ 2023-02-01 17:50                                   ` Darrell Kavanagh
  2023-02-01 17:55                                     ` Hans de Goede
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-01 17:50 UTC (permalink / raw)
  To: Bastien Nocera
  Cc: Hans de Goede, Jonathan Cameron, Jonathan Cameron, linux-iio,
	linux-kernel

Thank you. I don't have anything that could be called a big machine.
The fastest processor I have access to is a Core m3-8100Y - that's in
a Chromebook with 4GB memory - it can run Linux in a chroot or
officially in Google's VM. I also have an ancient gen 2 core i5-2410M
machine which is slower than the m3 in theory, but that has 6GB of
memory.

Is the kernel build more processor or memory bound?

Thanks,
Darrell

On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
>
> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 2/1/23 11:28, Jonathan Cameron wrote:
> > > On Wed, 1 Feb 2023 01:40:49 +0000
> > > Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >
> > > > Hello, all.
> > > >
> > > > I've finally reached a conclusion on this, after testing all the
> > > > combinations of the patches (with and without reading the acpi
> > > > mounting matrix), window managers (wayland, xorg) and the
> > > > presence or
> > > > not of my custom kernel parms.
> > > >
> > > > What works well is the full set of patches with the custom kernel
> > > > parms and a new hwdb entry for the sensor:
> > > >
> > > > sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> > > >  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> > > >
> > > > The autorotate then works correctly in wayland and xorg, but for
> > > > xorg,
> > > > the settings say the screen is "portrait left" when in actual
> > > > fact it
> > > > is in standard laptop landscape orientation. Wayland does not
> > > > have
> > > > this problem (I guess because wayland's view of the screen is
> > > > straight
> > > > from the kernel).
> > > >
> > > > Without the hwdb entry, the orientation is 90 degrees out without
> > > > using the acpi matrix and 180 degrees out when using it. I could
> > > > have
> > > > gone either way here with appropriate hwdb entries, but my view
> > > > is
> > > > that we *should* be using the matrix.
> > >
> > > Added Hans de Goede as he has probably run into more of this mess
> > > than anyone else.  Hans, any thoughts on if we are doing something
> > > wrong on kernel side?  Or is the matrix just wrong *sigh*
> >
> > I see below that this laptop has a panel which is mounted 90 degrees
> > rotated, that likely explains why the ACPI matrix does not work.
> > So the best thing to do here is to just override it with a hwdb
> > entries.
> >
> > IIRC there are already 1 or 2 other hwdb entries which actually
> > override the ACPI provided matrix because of similar issues.
> >
> > Linux userspace expects the matrix in this case to be set so that
> > it causes e.g. gnome's auto-rotation to put the image upright
> > even with older gnome versions / mate / xfce which don't know about
> > the panel being mounted 90 degrees.
> >
> > So e.g. "monitor-sensor" will report left-side-up or right-side-up
> > while the device is actually in normal clamshell mode with the
> > display up-right.
> >
> > This reporting of left-side-up or right-side-up is actually "correct"
> > looking from the native LCD panel orientation and as mentioned is
> > done for backward compatibility. This is documented here:
> >
> > https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> >
> > The way we are handling this is likely incompatible with how Windows
> > handles this special case of 90° rotated screen + ROTM. Or the
> > matrix in the ACPI tables could be just wrong...
> >
> > > I think 'ROTM' is defined by MS.
> > > https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> >
> > Right and as such it would be good if we can still add support to
> > it to the sensor driver in question. Because the ROTM info usually
> > is correct and avoids the need for adding more and more hwdb entries.
> >
> > Note there already is existing support in some other sensor drivers.
> >
> > So we probably need to factor out some helper code for this and share
> > that between sensor drivers.
> >
> >
> > > > The only thing that concerns me is the need for custom kernel
> > > > parms.
> > > > It would be better if there was a way to avoid this, so that the
> > > > user
> > > > didn't have to mess around with their grub config. Though having
> > > > said
> > > > that, the sensors fix as we have it doesn't make things worse -
> > > > under
> > > > currently released kernels the screen always starts up sideways
> > > > unless
> > > > custom parms are added in grub.
> >
> > We actually have a quirk mechanism in the kernel for specifying
> > the need for: video=DSI-1:panel_orientation=right_side_up  and this
> > will also automatically fix the fbcon orientation, see:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >
> > If you submit a patch for this upstream please Cc me.
>
> And if after that change, and copy/pasting the orientation from the
> DSDT into hwdb the sensor and screen move in the expected ways, then
> maybe stealing the BMC150 driver's
> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
>
> Once exported through "mount_matrix", iio-sensor-proxy should see it
> and read it without the need for a hwdb entry.
>
> Cheers

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 17:50                                   ` Darrell Kavanagh
@ 2023-02-01 17:55                                     ` Hans de Goede
  2023-02-03 18:23                                       ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Hans de Goede @ 2023-02-01 17:55 UTC (permalink / raw)
  To: Darrell Kavanagh, Bastien Nocera
  Cc: Jonathan Cameron, Jonathan Cameron, linux-iio, linux-kernel

Hi,

On 2/1/23 18:50, Darrell Kavanagh wrote:
> Thank you. I don't have anything that could be called a big machine.
> The fastest processor I have access to is a Core m3-8100Y - that's in
> a Chromebook with 4GB memory - it can run Linux in a chroot or
> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> machine which is slower than the m3 in theory, but that has 6GB of
> memory.
> 
> Is the kernel build more processor or memory bound?

It is mostly processor bound, esp. wtih something like make -j4,
make -j16 will start taking some RAM, but with make -j4 I expect you
to be fully CPU bound.

Regards,

Hans










> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
>>
>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 2/1/23 11:28, Jonathan Cameron wrote:
>>>> On Wed, 1 Feb 2023 01:40:49 +0000
>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>
>>>>> Hello, all.
>>>>>
>>>>> I've finally reached a conclusion on this, after testing all the
>>>>> combinations of the patches (with and without reading the acpi
>>>>> mounting matrix), window managers (wayland, xorg) and the
>>>>> presence or
>>>>> not of my custom kernel parms.
>>>>>
>>>>> What works well is the full set of patches with the custom kernel
>>>>> parms and a new hwdb entry for the sensor:
>>>>>
>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>>>>
>>>>> The autorotate then works correctly in wayland and xorg, but for
>>>>> xorg,
>>>>> the settings say the screen is "portrait left" when in actual
>>>>> fact it
>>>>> is in standard laptop landscape orientation. Wayland does not
>>>>> have
>>>>> this problem (I guess because wayland's view of the screen is
>>>>> straight
>>>>> from the kernel).
>>>>>
>>>>> Without the hwdb entry, the orientation is 90 degrees out without
>>>>> using the acpi matrix and 180 degrees out when using it. I could
>>>>> have
>>>>> gone either way here with appropriate hwdb entries, but my view
>>>>> is
>>>>> that we *should* be using the matrix.
>>>>
>>>> Added Hans de Goede as he has probably run into more of this mess
>>>> than anyone else.  Hans, any thoughts on if we are doing something
>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
>>>
>>> I see below that this laptop has a panel which is mounted 90 degrees
>>> rotated, that likely explains why the ACPI matrix does not work.
>>> So the best thing to do here is to just override it with a hwdb
>>> entries.
>>>
>>> IIRC there are already 1 or 2 other hwdb entries which actually
>>> override the ACPI provided matrix because of similar issues.
>>>
>>> Linux userspace expects the matrix in this case to be set so that
>>> it causes e.g. gnome's auto-rotation to put the image upright
>>> even with older gnome versions / mate / xfce which don't know about
>>> the panel being mounted 90 degrees.
>>>
>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
>>> while the device is actually in normal clamshell mode with the
>>> display up-right.
>>>
>>> This reporting of left-side-up or right-side-up is actually "correct"
>>> looking from the native LCD panel orientation and as mentioned is
>>> done for backward compatibility. This is documented here:
>>>
>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>>>
>>> The way we are handling this is likely incompatible with how Windows
>>> handles this special case of 90° rotated screen + ROTM. Or the
>>> matrix in the ACPI tables could be just wrong...
>>>
>>>> I think 'ROTM' is defined by MS.
>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>>>
>>> Right and as such it would be good if we can still add support to
>>> it to the sensor driver in question. Because the ROTM info usually
>>> is correct and avoids the need for adding more and more hwdb entries.
>>>
>>> Note there already is existing support in some other sensor drivers.
>>>
>>> So we probably need to factor out some helper code for this and share
>>> that between sensor drivers.
>>>
>>>
>>>>> The only thing that concerns me is the need for custom kernel
>>>>> parms.
>>>>> It would be better if there was a way to avoid this, so that the
>>>>> user
>>>>> didn't have to mess around with their grub config. Though having
>>>>> said
>>>>> that, the sensors fix as we have it doesn't make things worse -
>>>>> under
>>>>> currently released kernels the screen always starts up sideways
>>>>> unless
>>>>> custom parms are added in grub.
>>>
>>> We actually have a quirk mechanism in the kernel for specifying
>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
>>> will also automatically fix the fbcon orientation, see:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>
>>> If you submit a patch for this upstream please Cc me.
>>
>> And if after that change, and copy/pasting the orientation from the
>> DSDT into hwdb the sensor and screen move in the expected ways, then
>> maybe stealing the BMC150 driver's
>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
>>
>> Once exported through "mount_matrix", iio-sensor-proxy should see it
>> and read it without the need for a hwdb entry.
>>
>> Cheers
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-01 17:55                                     ` Hans de Goede
@ 2023-02-03 18:23                                       ` Darrell Kavanagh
  2023-02-04 17:09                                         ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-03 18:23 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Bastien Nocera, Jonathan Cameron, Jonathan Cameron, linux-iio,
	linux-kernel

Finally got a 6.2.0-rc6 kernel built and installed, with the following
patch, and everything is working as expected.

Moving on now to look at Bastien's suggestion.

Thanks,
Darrell

diff --git a/kernel/drm_panel_orientation_quirks.c
b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3659f04..590bb7b 100644
--- a/kernel/drm_panel_orientation_quirks.c
+++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
                  DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
                },
                .driver_data = (void *)&lcd1200x1920_rightside_up,
+       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
+               .matches = {
+                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
+               },
+               .driver_data = (void *)&lcd1200x1920_rightside_up,
        }, {    /* Lenovo Ideapad D330-10IGL (HD) */
                .matches = {
                  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),

On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 2/1/23 18:50, Darrell Kavanagh wrote:
> > Thank you. I don't have anything that could be called a big machine.
> > The fastest processor I have access to is a Core m3-8100Y - that's in
> > a Chromebook with 4GB memory - it can run Linux in a chroot or
> > officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> > machine which is slower than the m3 in theory, but that has 6GB of
> > memory.
> >
> > Is the kernel build more processor or memory bound?
>
> It is mostly processor bound, esp. wtih something like make -j4,
> make -j16 will start taking some RAM, but with make -j4 I expect you
> to be fully CPU bound.
>
> Regards,
>
> Hans
>
>
>
>
>
>
>
>
>
>
> > On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
> >>
> >> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 2/1/23 11:28, Jonathan Cameron wrote:
> >>>> On Wed, 1 Feb 2023 01:40:49 +0000
> >>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>
> >>>>> Hello, all.
> >>>>>
> >>>>> I've finally reached a conclusion on this, after testing all the
> >>>>> combinations of the patches (with and without reading the acpi
> >>>>> mounting matrix), window managers (wayland, xorg) and the
> >>>>> presence or
> >>>>> not of my custom kernel parms.
> >>>>>
> >>>>> What works well is the full set of patches with the custom kernel
> >>>>> parms and a new hwdb entry for the sensor:
> >>>>>
> >>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> >>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> >>>>>
> >>>>> The autorotate then works correctly in wayland and xorg, but for
> >>>>> xorg,
> >>>>> the settings say the screen is "portrait left" when in actual
> >>>>> fact it
> >>>>> is in standard laptop landscape orientation. Wayland does not
> >>>>> have
> >>>>> this problem (I guess because wayland's view of the screen is
> >>>>> straight
> >>>>> from the kernel).
> >>>>>
> >>>>> Without the hwdb entry, the orientation is 90 degrees out without
> >>>>> using the acpi matrix and 180 degrees out when using it. I could
> >>>>> have
> >>>>> gone either way here with appropriate hwdb entries, but my view
> >>>>> is
> >>>>> that we *should* be using the matrix.
> >>>>
> >>>> Added Hans de Goede as he has probably run into more of this mess
> >>>> than anyone else.  Hans, any thoughts on if we are doing something
> >>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
> >>>
> >>> I see below that this laptop has a panel which is mounted 90 degrees
> >>> rotated, that likely explains why the ACPI matrix does not work.
> >>> So the best thing to do here is to just override it with a hwdb
> >>> entries.
> >>>
> >>> IIRC there are already 1 or 2 other hwdb entries which actually
> >>> override the ACPI provided matrix because of similar issues.
> >>>
> >>> Linux userspace expects the matrix in this case to be set so that
> >>> it causes e.g. gnome's auto-rotation to put the image upright
> >>> even with older gnome versions / mate / xfce which don't know about
> >>> the panel being mounted 90 degrees.
> >>>
> >>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> >>> while the device is actually in normal clamshell mode with the
> >>> display up-right.
> >>>
> >>> This reporting of left-side-up or right-side-up is actually "correct"
> >>> looking from the native LCD panel orientation and as mentioned is
> >>> done for backward compatibility. This is documented here:
> >>>
> >>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> >>>
> >>> The way we are handling this is likely incompatible with how Windows
> >>> handles this special case of 90° rotated screen + ROTM. Or the
> >>> matrix in the ACPI tables could be just wrong...
> >>>
> >>>> I think 'ROTM' is defined by MS.
> >>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> >>>
> >>> Right and as such it would be good if we can still add support to
> >>> it to the sensor driver in question. Because the ROTM info usually
> >>> is correct and avoids the need for adding more and more hwdb entries.
> >>>
> >>> Note there already is existing support in some other sensor drivers.
> >>>
> >>> So we probably need to factor out some helper code for this and share
> >>> that between sensor drivers.
> >>>
> >>>
> >>>>> The only thing that concerns me is the need for custom kernel
> >>>>> parms.
> >>>>> It would be better if there was a way to avoid this, so that the
> >>>>> user
> >>>>> didn't have to mess around with their grub config. Though having
> >>>>> said
> >>>>> that, the sensors fix as we have it doesn't make things worse -
> >>>>> under
> >>>>> currently released kernels the screen always starts up sideways
> >>>>> unless
> >>>>> custom parms are added in grub.
> >>>
> >>> We actually have a quirk mechanism in the kernel for specifying
> >>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> >>> will also automatically fix the fbcon orientation, see:
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>
> >>> If you submit a patch for this upstream please Cc me.
> >>
> >> And if after that change, and copy/pasting the orientation from the
> >> DSDT into hwdb the sensor and screen move in the expected ways, then
> >> maybe stealing the BMC150 driver's
> >> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
> >>
> >> Once exported through "mount_matrix", iio-sensor-proxy should see it
> >> and read it without the need for a hwdb entry.
> >>
> >> Cheers
> >
>

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-03 18:23                                       ` Darrell Kavanagh
@ 2023-02-04 17:09                                         ` Darrell Kavanagh
  2023-02-04 21:31                                           ` Hans de Goede
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-04 17:09 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Bastien Nocera, Jonathan Cameron, Jonathan Cameron, linux-iio,
	linux-kernel

I've just noticed that the working mount matrix that I added to my
hwdb is the matrix retrieved from the ACPI ROTM call in the amended
driver, transposed.

Useful information or coincidence?

Darrell

On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
<darrell.kavanagh@gmail.com> wrote:
>
> Finally got a 6.2.0-rc6 kernel built and installed, with the following
> patch, and everything is working as expected.
>
> Moving on now to look at Bastien's suggestion.
>
> Thanks,
> Darrell
>
> diff --git a/kernel/drm_panel_orientation_quirks.c
> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> index 3659f04..590bb7b 100644
> --- a/kernel/drm_panel_orientation_quirks.c
> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> D330-10IGM"),
>                 },
>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
> +               .matches = {
> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> +               },
> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
>                 .matches = {
>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>
> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > Hi,
> >
> > On 2/1/23 18:50, Darrell Kavanagh wrote:
> > > Thank you. I don't have anything that could be called a big machine.
> > > The fastest processor I have access to is a Core m3-8100Y - that's in
> > > a Chromebook with 4GB memory - it can run Linux in a chroot or
> > > officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> > > machine which is slower than the m3 in theory, but that has 6GB of
> > > memory.
> > >
> > > Is the kernel build more processor or memory bound?
> >
> > It is mostly processor bound, esp. wtih something like make -j4,
> > make -j16 will start taking some RAM, but with make -j4 I expect you
> > to be fully CPU bound.
> >
> > Regards,
> >
> > Hans
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
> > >>
> > >> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> > >>> Hi,
> > >>>
> > >>> On 2/1/23 11:28, Jonathan Cameron wrote:
> > >>>> On Wed, 1 Feb 2023 01:40:49 +0000
> > >>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >>>>
> > >>>>> Hello, all.
> > >>>>>
> > >>>>> I've finally reached a conclusion on this, after testing all the
> > >>>>> combinations of the patches (with and without reading the acpi
> > >>>>> mounting matrix), window managers (wayland, xorg) and the
> > >>>>> presence or
> > >>>>> not of my custom kernel parms.
> > >>>>>
> > >>>>> What works well is the full set of patches with the custom kernel
> > >>>>> parms and a new hwdb entry for the sensor:
> > >>>>>
> > >>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> > >>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> > >>>>>
> > >>>>> The autorotate then works correctly in wayland and xorg, but for
> > >>>>> xorg,
> > >>>>> the settings say the screen is "portrait left" when in actual
> > >>>>> fact it
> > >>>>> is in standard laptop landscape orientation. Wayland does not
> > >>>>> have
> > >>>>> this problem (I guess because wayland's view of the screen is
> > >>>>> straight
> > >>>>> from the kernel).
> > >>>>>
> > >>>>> Without the hwdb entry, the orientation is 90 degrees out without
> > >>>>> using the acpi matrix and 180 degrees out when using it. I could
> > >>>>> have
> > >>>>> gone either way here with appropriate hwdb entries, but my view
> > >>>>> is
> > >>>>> that we *should* be using the matrix.
> > >>>>
> > >>>> Added Hans de Goede as he has probably run into more of this mess
> > >>>> than anyone else.  Hans, any thoughts on if we are doing something
> > >>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
> > >>>
> > >>> I see below that this laptop has a panel which is mounted 90 degrees
> > >>> rotated, that likely explains why the ACPI matrix does not work.
> > >>> So the best thing to do here is to just override it with a hwdb
> > >>> entries.
> > >>>
> > >>> IIRC there are already 1 or 2 other hwdb entries which actually
> > >>> override the ACPI provided matrix because of similar issues.
> > >>>
> > >>> Linux userspace expects the matrix in this case to be set so that
> > >>> it causes e.g. gnome's auto-rotation to put the image upright
> > >>> even with older gnome versions / mate / xfce which don't know about
> > >>> the panel being mounted 90 degrees.
> > >>>
> > >>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> > >>> while the device is actually in normal clamshell mode with the
> > >>> display up-right.
> > >>>
> > >>> This reporting of left-side-up or right-side-up is actually "correct"
> > >>> looking from the native LCD panel orientation and as mentioned is
> > >>> done for backward compatibility. This is documented here:
> > >>>
> > >>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> > >>>
> > >>> The way we are handling this is likely incompatible with how Windows
> > >>> handles this special case of 90° rotated screen + ROTM. Or the
> > >>> matrix in the ACPI tables could be just wrong...
> > >>>
> > >>>> I think 'ROTM' is defined by MS.
> > >>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> > >>>
> > >>> Right and as such it would be good if we can still add support to
> > >>> it to the sensor driver in question. Because the ROTM info usually
> > >>> is correct and avoids the need for adding more and more hwdb entries.
> > >>>
> > >>> Note there already is existing support in some other sensor drivers.
> > >>>
> > >>> So we probably need to factor out some helper code for this and share
> > >>> that between sensor drivers.
> > >>>
> > >>>
> > >>>>> The only thing that concerns me is the need for custom kernel
> > >>>>> parms.
> > >>>>> It would be better if there was a way to avoid this, so that the
> > >>>>> user
> > >>>>> didn't have to mess around with their grub config. Though having
> > >>>>> said
> > >>>>> that, the sensors fix as we have it doesn't make things worse -
> > >>>>> under
> > >>>>> currently released kernels the screen always starts up sideways
> > >>>>> unless
> > >>>>> custom parms are added in grub.
> > >>>
> > >>> We actually have a quirk mechanism in the kernel for specifying
> > >>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> > >>> will also automatically fix the fbcon orientation, see:
> > >>>
> > >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > >>>
> > >>> If you submit a patch for this upstream please Cc me.
> > >>
> > >> And if after that change, and copy/pasting the orientation from the
> > >> DSDT into hwdb the sensor and screen move in the expected ways, then
> > >> maybe stealing the BMC150 driver's
> > >> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
> > >>
> > >> Once exported through "mount_matrix", iio-sensor-proxy should see it
> > >> and read it without the need for a hwdb entry.
> > >>
> > >> Cheers
> > >
> >

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-04 17:09                                         ` Darrell Kavanagh
@ 2023-02-04 21:31                                           ` Hans de Goede
  2023-02-04 22:15                                             ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Hans de Goede @ 2023-02-04 21:31 UTC (permalink / raw)
  To: Darrell Kavanagh
  Cc: Bastien Nocera, Jonathan Cameron, Jonathan Cameron, linux-iio,
	linux-kernel

Hi,

On 2/4/23 18:09, Darrell Kavanagh wrote:
> I've just noticed that the working mount matrix that I added to my
> hwdb is the matrix retrieved from the ACPI ROTM call in the amended
> driver, transposed.

An other word for the mount matrix would be a rotation matrix,
since it defines how the physical sensor is mounted on the PCB
in a rotated fashion compared to its standard orientation.

The x, y, z axis relationship underling of course does
not change by the rotation, so yes all mount matrices
are a transposition of the standard:

1, 0, 0 : 0, 1, 0 : 0, 0, 1

matrix, that is expected. Where that to not be the case
then there would be a bug in the accelerometer driver itself
where the driver itself is swapping or inverting axis.

Regards,

Hans




> On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
> <darrell.kavanagh@gmail.com> wrote:
>>
>> Finally got a 6.2.0-rc6 kernel built and installed, with the following
>> patch, and everything is working as expected.
>>
>> Moving on now to look at Bastien's suggestion.
>>
>> Thanks,
>> Darrell
>>
>> diff --git a/kernel/drm_panel_orientation_quirks.c
>> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> index 3659f04..590bb7b 100644
>> --- a/kernel/drm_panel_orientation_quirks.c
>> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
>> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
>>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
>> D330-10IGM"),
>>                 },
>>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
>> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
>> +               .matches = {
>> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
>> +               },
>> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
>>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
>>                 .matches = {
>>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>
>> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> On 2/1/23 18:50, Darrell Kavanagh wrote:
>>>> Thank you. I don't have anything that could be called a big machine.
>>>> The fastest processor I have access to is a Core m3-8100Y - that's in
>>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
>>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
>>>> machine which is slower than the m3 in theory, but that has 6GB of
>>>> memory.
>>>>
>>>> Is the kernel build more processor or memory bound?
>>>
>>> It is mostly processor bound, esp. wtih something like make -j4,
>>> make -j16 will start taking some RAM, but with make -j4 I expect you
>>> to be fully CPU bound.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
>>>>>
>>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:
>>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello, all.
>>>>>>>>
>>>>>>>> I've finally reached a conclusion on this, after testing all the
>>>>>>>> combinations of the patches (with and without reading the acpi
>>>>>>>> mounting matrix), window managers (wayland, xorg) and the
>>>>>>>> presence or
>>>>>>>> not of my custom kernel parms.
>>>>>>>>
>>>>>>>> What works well is the full set of patches with the custom kernel
>>>>>>>> parms and a new hwdb entry for the sensor:
>>>>>>>>
>>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>>>>>>>
>>>>>>>> The autorotate then works correctly in wayland and xorg, but for
>>>>>>>> xorg,
>>>>>>>> the settings say the screen is "portrait left" when in actual
>>>>>>>> fact it
>>>>>>>> is in standard laptop landscape orientation. Wayland does not
>>>>>>>> have
>>>>>>>> this problem (I guess because wayland's view of the screen is
>>>>>>>> straight
>>>>>>>> from the kernel).
>>>>>>>>
>>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
>>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
>>>>>>>> have
>>>>>>>> gone either way here with appropriate hwdb entries, but my view
>>>>>>>> is
>>>>>>>> that we *should* be using the matrix.
>>>>>>>
>>>>>>> Added Hans de Goede as he has probably run into more of this mess
>>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
>>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
>>>>>>
>>>>>> I see below that this laptop has a panel which is mounted 90 degrees
>>>>>> rotated, that likely explains why the ACPI matrix does not work.
>>>>>> So the best thing to do here is to just override it with a hwdb
>>>>>> entries.
>>>>>>
>>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
>>>>>> override the ACPI provided matrix because of similar issues.
>>>>>>
>>>>>> Linux userspace expects the matrix in this case to be set so that
>>>>>> it causes e.g. gnome's auto-rotation to put the image upright
>>>>>> even with older gnome versions / mate / xfce which don't know about
>>>>>> the panel being mounted 90 degrees.
>>>>>>
>>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
>>>>>> while the device is actually in normal clamshell mode with the
>>>>>> display up-right.
>>>>>>
>>>>>> This reporting of left-side-up or right-side-up is actually "correct"
>>>>>> looking from the native LCD panel orientation and as mentioned is
>>>>>> done for backward compatibility. This is documented here:
>>>>>>
>>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>>>>>>
>>>>>> The way we are handling this is likely incompatible with how Windows
>>>>>> handles this special case of 90° rotated screen + ROTM. Or the
>>>>>> matrix in the ACPI tables could be just wrong...
>>>>>>
>>>>>>> I think 'ROTM' is defined by MS.
>>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>>>>>>
>>>>>> Right and as such it would be good if we can still add support to
>>>>>> it to the sensor driver in question. Because the ROTM info usually
>>>>>> is correct and avoids the need for adding more and more hwdb entries.
>>>>>>
>>>>>> Note there already is existing support in some other sensor drivers.
>>>>>>
>>>>>> So we probably need to factor out some helper code for this and share
>>>>>> that between sensor drivers.
>>>>>>
>>>>>>
>>>>>>>> The only thing that concerns me is the need for custom kernel
>>>>>>>> parms.
>>>>>>>> It would be better if there was a way to avoid this, so that the
>>>>>>>> user
>>>>>>>> didn't have to mess around with their grub config. Though having
>>>>>>>> said
>>>>>>>> that, the sensors fix as we have it doesn't make things worse -
>>>>>>>> under
>>>>>>>> currently released kernels the screen always starts up sideways
>>>>>>>> unless
>>>>>>>> custom parms are added in grub.
>>>>>>
>>>>>> We actually have a quirk mechanism in the kernel for specifying
>>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
>>>>>> will also automatically fix the fbcon orientation, see:
>>>>>>
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>>>>
>>>>>> If you submit a patch for this upstream please Cc me.
>>>>>
>>>>> And if after that change, and copy/pasting the orientation from the
>>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
>>>>> maybe stealing the BMC150 driver's
>>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
>>>>>
>>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
>>>>> and read it without the need for a hwdb entry.
>>>>>
>>>>> Cheers
>>>>
>>>
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-04 21:31                                           ` Hans de Goede
@ 2023-02-04 22:15                                             ` Darrell Kavanagh
  2023-02-05  8:50                                               ` Hans de Goede
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-04 22:15 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Bastien Nocera, Jonathan Cameron, Jonathan Cameron, linux-iio,
	linux-kernel

Yes, I understand that.

What I mean is that the matrix read from the DSDT by Jonathan's
amended driver is

 0 -1  0
 1  0  0
 0  0  1

and the (correct) matrix created with my new hwdb entry is

 0  1  0
-1  0  0
 0  0  1

which is the algebraic transposition (ie reflection in the diagonal)
of the DSDT one.

In other words, though the DST matrix is wrong, it is wrong in a
specific way - the rows should be the columns, and vv. I was just
wondering if this was a DSDT bug that might have been seen elsewhere
before.

BTW, there is another matrix in the DSTD, but I can't find the
associated HID (10EC5280) anywhere (Linux sysfs or Windows Powershell
system data extract). It's not a correct matrix, though - could it be
just a bit of redundant code in the DST?

Darrell

On Sat, 4 Feb 2023 at 21:31, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 2/4/23 18:09, Darrell Kavanagh wrote:
> > I've just noticed that the working mount matrix that I added to my
> > hwdb is the matrix retrieved from the ACPI ROTM call in the amended
> > driver, transposed.
>
> An other word for the mount matrix would be a rotation matrix,
> since it defines how the physical sensor is mounted on the PCB
> in a rotated fashion compared to its standard orientation.
>
> The x, y, z axis relationship underling of course does
> not change by the rotation, so yes all mount matrices
> are a transposition of the standard:
>
> 1, 0, 0 : 0, 1, 0 : 0, 0, 1
>
> matrix, that is expected. Where that to not be the case
> then there would be a bug in the accelerometer driver itself
> where the driver itself is swapping or inverting axis.
>
> Regards,
>
> Hans
>
>
>
>
> > On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
> > <darrell.kavanagh@gmail.com> wrote:
> >>
> >> Finally got a 6.2.0-rc6 kernel built and installed, with the following
> >> patch, and everything is working as expected.
> >>
> >> Moving on now to look at Bastien's suggestion.
> >>
> >> Thanks,
> >> Darrell
> >>
> >> diff --git a/kernel/drm_panel_orientation_quirks.c
> >> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >> index 3659f04..590bb7b 100644
> >> --- a/kernel/drm_panel_orientation_quirks.c
> >> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
> >>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> >> D330-10IGM"),
> >>                 },
> >>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
> >> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
> >> +               .matches = {
> >> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> >> +               },
> >> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
> >>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
> >>                 .matches = {
> >>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >>
> >> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 2/1/23 18:50, Darrell Kavanagh wrote:
> >>>> Thank you. I don't have anything that could be called a big machine.
> >>>> The fastest processor I have access to is a Core m3-8100Y - that's in
> >>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
> >>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> >>>> machine which is slower than the m3 in theory, but that has 6GB of
> >>>> memory.
> >>>>
> >>>> Is the kernel build more processor or memory bound?
> >>>
> >>> It is mostly processor bound, esp. wtih something like make -j4,
> >>> make -j16 will start taking some RAM, but with make -j4 I expect you
> >>> to be fully CPU bound.
> >>>
> >>> Regards,
> >>>
> >>> Hans
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
> >>>>>
> >>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:
> >>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
> >>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Hello, all.
> >>>>>>>>
> >>>>>>>> I've finally reached a conclusion on this, after testing all the
> >>>>>>>> combinations of the patches (with and without reading the acpi
> >>>>>>>> mounting matrix), window managers (wayland, xorg) and the
> >>>>>>>> presence or
> >>>>>>>> not of my custom kernel parms.
> >>>>>>>>
> >>>>>>>> What works well is the full set of patches with the custom kernel
> >>>>>>>> parms and a new hwdb entry for the sensor:
> >>>>>>>>
> >>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> >>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> >>>>>>>>
> >>>>>>>> The autorotate then works correctly in wayland and xorg, but for
> >>>>>>>> xorg,
> >>>>>>>> the settings say the screen is "portrait left" when in actual
> >>>>>>>> fact it
> >>>>>>>> is in standard laptop landscape orientation. Wayland does not
> >>>>>>>> have
> >>>>>>>> this problem (I guess because wayland's view of the screen is
> >>>>>>>> straight
> >>>>>>>> from the kernel).
> >>>>>>>>
> >>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
> >>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
> >>>>>>>> have
> >>>>>>>> gone either way here with appropriate hwdb entries, but my view
> >>>>>>>> is
> >>>>>>>> that we *should* be using the matrix.
> >>>>>>>
> >>>>>>> Added Hans de Goede as he has probably run into more of this mess
> >>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
> >>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
> >>>>>>
> >>>>>> I see below that this laptop has a panel which is mounted 90 degrees
> >>>>>> rotated, that likely explains why the ACPI matrix does not work.
> >>>>>> So the best thing to do here is to just override it with a hwdb
> >>>>>> entries.
> >>>>>>
> >>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
> >>>>>> override the ACPI provided matrix because of similar issues.
> >>>>>>
> >>>>>> Linux userspace expects the matrix in this case to be set so that
> >>>>>> it causes e.g. gnome's auto-rotation to put the image upright
> >>>>>> even with older gnome versions / mate / xfce which don't know about
> >>>>>> the panel being mounted 90 degrees.
> >>>>>>
> >>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> >>>>>> while the device is actually in normal clamshell mode with the
> >>>>>> display up-right.
> >>>>>>
> >>>>>> This reporting of left-side-up or right-side-up is actually "correct"
> >>>>>> looking from the native LCD panel orientation and as mentioned is
> >>>>>> done for backward compatibility. This is documented here:
> >>>>>>
> >>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> >>>>>>
> >>>>>> The way we are handling this is likely incompatible with how Windows
> >>>>>> handles this special case of 90° rotated screen + ROTM. Or the
> >>>>>> matrix in the ACPI tables could be just wrong...
> >>>>>>
> >>>>>>> I think 'ROTM' is defined by MS.
> >>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> >>>>>>
> >>>>>> Right and as such it would be good if we can still add support to
> >>>>>> it to the sensor driver in question. Because the ROTM info usually
> >>>>>> is correct and avoids the need for adding more and more hwdb entries.
> >>>>>>
> >>>>>> Note there already is existing support in some other sensor drivers.
> >>>>>>
> >>>>>> So we probably need to factor out some helper code for this and share
> >>>>>> that between sensor drivers.
> >>>>>>
> >>>>>>
> >>>>>>>> The only thing that concerns me is the need for custom kernel
> >>>>>>>> parms.
> >>>>>>>> It would be better if there was a way to avoid this, so that the
> >>>>>>>> user
> >>>>>>>> didn't have to mess around with their grub config. Though having
> >>>>>>>> said
> >>>>>>>> that, the sensors fix as we have it doesn't make things worse -
> >>>>>>>> under
> >>>>>>>> currently released kernels the screen always starts up sideways
> >>>>>>>> unless
> >>>>>>>> custom parms are added in grub.
> >>>>>>
> >>>>>> We actually have a quirk mechanism in the kernel for specifying
> >>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> >>>>>> will also automatically fix the fbcon orientation, see:
> >>>>>>
> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>>>>
> >>>>>> If you submit a patch for this upstream please Cc me.
> >>>>>
> >>>>> And if after that change, and copy/pasting the orientation from the
> >>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
> >>>>> maybe stealing the BMC150 driver's
> >>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
> >>>>>
> >>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
> >>>>> and read it without the need for a hwdb entry.
> >>>>>
> >>>>> Cheers
> >>>>
> >>>
> >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-04 22:15                                             ` Darrell Kavanagh
@ 2023-02-05  8:50                                               ` Hans de Goede
  2023-02-05 14:36                                                 ` Jonathan Cameron
  0 siblings, 1 reply; 29+ messages in thread
From: Hans de Goede @ 2023-02-05  8:50 UTC (permalink / raw)
  To: Darrell Kavanagh
  Cc: Bastien Nocera, Jonathan Cameron, Jonathan Cameron, linux-iio,
	linux-kernel

Hi,

On 2/4/23 23:15, Darrell Kavanagh wrote:
> Yes, I understand that.
> 
> What I mean is that the matrix read from the DSDT by Jonathan's
> amended driver is
> 
>  0 -1  0
>  1  0  0
>  0  0  1
> 
> and the (correct) matrix created with my new hwdb entry is
> 
>  0  1  0
> -1  0  0
>  0  0  1
> 
> which is the algebraic transposition (ie reflection in the diagonal)
> of the DSDT one.
> 
> In other words, though the DST matrix is wrong, it is wrong in a
> specific way - the rows should be the columns, and vv. I was just
> wondering if this was a DSDT bug that might have been seen elsewhere
> before.

No this does not ring a bell, but the x and y axis being swapped
does seem related to the LCD panel being 90° rotated.

> BTW, there is another matrix in the DSTD, but I can't find the
> associated HID (10EC5280) anywhere (Linux sysfs or Windows Powershell
> system data extract). It's not a correct matrix, though - could it be
> just a bit of redundant code in the DST?

Yes that is likely there often is a bunch of dead stuff DSDT leftover
from other device models.

Regards,

Hans





> 
> Darrell
> 
> On Sat, 4 Feb 2023 at 21:31, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 2/4/23 18:09, Darrell Kavanagh wrote:
>>> I've just noticed that the working mount matrix that I added to my
>>> hwdb is the matrix retrieved from the ACPI ROTM call in the amended
>>> driver, transposed.
>>
>> An other word for the mount matrix would be a rotation matrix,
>> since it defines how the physical sensor is mounted on the PCB
>> in a rotated fashion compared to its standard orientation.
>>
>> The x, y, z axis relationship underling of course does
>> not change by the rotation, so yes all mount matrices
>> are a transposition of the standard:
>>
>> 1, 0, 0 : 0, 1, 0 : 0, 0, 1
>>
>> matrix, that is expected. Where that to not be the case
>> then there would be a bug in the accelerometer driver itself
>> where the driver itself is swapping or inverting axis.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>
>>> On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
>>> <darrell.kavanagh@gmail.com> wrote:
>>>>
>>>> Finally got a 6.2.0-rc6 kernel built and installed, with the following
>>>> patch, and everything is working as expected.
>>>>
>>>> Moving on now to look at Bastien's suggestion.
>>>>
>>>> Thanks,
>>>> Darrell
>>>>
>>>> diff --git a/kernel/drm_panel_orientation_quirks.c
>>>> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>> index 3659f04..590bb7b 100644
>>>> --- a/kernel/drm_panel_orientation_quirks.c
>>>> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
>>>>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
>>>> D330-10IGM"),
>>>>                 },
>>>>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
>>>> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
>>>> +               .matches = {
>>>> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>>> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
>>>> +               },
>>>> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
>>>>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
>>>>                 .matches = {
>>>>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>>>
>>>> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 2/1/23 18:50, Darrell Kavanagh wrote:
>>>>>> Thank you. I don't have anything that could be called a big machine.
>>>>>> The fastest processor I have access to is a Core m3-8100Y - that's in
>>>>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
>>>>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
>>>>>> machine which is slower than the m3 in theory, but that has 6GB of
>>>>>> memory.
>>>>>>
>>>>>> Is the kernel build more processor or memory bound?
>>>>>
>>>>> It is mostly processor bound, esp. wtih something like make -j4,
>>>>> make -j16 will start taking some RAM, but with make -j4 I expect you
>>>>> to be fully CPU bound.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
>>>>>>>
>>>>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:
>>>>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello, all.
>>>>>>>>>>
>>>>>>>>>> I've finally reached a conclusion on this, after testing all the
>>>>>>>>>> combinations of the patches (with and without reading the acpi
>>>>>>>>>> mounting matrix), window managers (wayland, xorg) and the
>>>>>>>>>> presence or
>>>>>>>>>> not of my custom kernel parms.
>>>>>>>>>>
>>>>>>>>>> What works well is the full set of patches with the custom kernel
>>>>>>>>>> parms and a new hwdb entry for the sensor:
>>>>>>>>>>
>>>>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>>>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>>>>>>>>>
>>>>>>>>>> The autorotate then works correctly in wayland and xorg, but for
>>>>>>>>>> xorg,
>>>>>>>>>> the settings say the screen is "portrait left" when in actual
>>>>>>>>>> fact it
>>>>>>>>>> is in standard laptop landscape orientation. Wayland does not
>>>>>>>>>> have
>>>>>>>>>> this problem (I guess because wayland's view of the screen is
>>>>>>>>>> straight
>>>>>>>>>> from the kernel).
>>>>>>>>>>
>>>>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
>>>>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
>>>>>>>>>> have
>>>>>>>>>> gone either way here with appropriate hwdb entries, but my view
>>>>>>>>>> is
>>>>>>>>>> that we *should* be using the matrix.
>>>>>>>>>
>>>>>>>>> Added Hans de Goede as he has probably run into more of this mess
>>>>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
>>>>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
>>>>>>>>
>>>>>>>> I see below that this laptop has a panel which is mounted 90 degrees
>>>>>>>> rotated, that likely explains why the ACPI matrix does not work.
>>>>>>>> So the best thing to do here is to just override it with a hwdb
>>>>>>>> entries.
>>>>>>>>
>>>>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
>>>>>>>> override the ACPI provided matrix because of similar issues.
>>>>>>>>
>>>>>>>> Linux userspace expects the matrix in this case to be set so that
>>>>>>>> it causes e.g. gnome's auto-rotation to put the image upright
>>>>>>>> even with older gnome versions / mate / xfce which don't know about
>>>>>>>> the panel being mounted 90 degrees.
>>>>>>>>
>>>>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
>>>>>>>> while the device is actually in normal clamshell mode with the
>>>>>>>> display up-right.
>>>>>>>>
>>>>>>>> This reporting of left-side-up or right-side-up is actually "correct"
>>>>>>>> looking from the native LCD panel orientation and as mentioned is
>>>>>>>> done for backward compatibility. This is documented here:
>>>>>>>>
>>>>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>>>>>>>>
>>>>>>>> The way we are handling this is likely incompatible with how Windows
>>>>>>>> handles this special case of 90° rotated screen + ROTM. Or the
>>>>>>>> matrix in the ACPI tables could be just wrong...
>>>>>>>>
>>>>>>>>> I think 'ROTM' is defined by MS.
>>>>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>>>>>>>>
>>>>>>>> Right and as such it would be good if we can still add support to
>>>>>>>> it to the sensor driver in question. Because the ROTM info usually
>>>>>>>> is correct and avoids the need for adding more and more hwdb entries.
>>>>>>>>
>>>>>>>> Note there already is existing support in some other sensor drivers.
>>>>>>>>
>>>>>>>> So we probably need to factor out some helper code for this and share
>>>>>>>> that between sensor drivers.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> The only thing that concerns me is the need for custom kernel
>>>>>>>>>> parms.
>>>>>>>>>> It would be better if there was a way to avoid this, so that the
>>>>>>>>>> user
>>>>>>>>>> didn't have to mess around with their grub config. Though having
>>>>>>>>>> said
>>>>>>>>>> that, the sensors fix as we have it doesn't make things worse -
>>>>>>>>>> under
>>>>>>>>>> currently released kernels the screen always starts up sideways
>>>>>>>>>> unless
>>>>>>>>>> custom parms are added in grub.
>>>>>>>>
>>>>>>>> We actually have a quirk mechanism in the kernel for specifying
>>>>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
>>>>>>>> will also automatically fix the fbcon orientation, see:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>>>>>>
>>>>>>>> If you submit a patch for this upstream please Cc me.
>>>>>>>
>>>>>>> And if after that change, and copy/pasting the orientation from the
>>>>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
>>>>>>> maybe stealing the BMC150 driver's
>>>>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
>>>>>>>
>>>>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
>>>>>>> and read it without the need for a hwdb entry.
>>>>>>>
>>>>>>> Cheers
>>>>>>
>>>>>
>>>
>>
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-05  8:50                                               ` Hans de Goede
@ 2023-02-05 14:36                                                 ` Jonathan Cameron
  2023-02-05 16:06                                                   ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Cameron @ 2023-02-05 14:36 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Darrell Kavanagh, Bastien Nocera, Jonathan Cameron, linux-iio,
	linux-kernel

On Sun, 5 Feb 2023 09:50:51 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 2/4/23 23:15, Darrell Kavanagh wrote:
> > Yes, I understand that.
> > 
> > What I mean is that the matrix read from the DSDT by Jonathan's
> > amended driver is
> > 
> >  0 -1  0
> >  1  0  0
> >  0  0  1
> > 
> > and the (correct) matrix created with my new hwdb entry is
> > 
> >  0  1  0
> > -1  0  0
> >  0  0  1

May be concidence, but I think that's the inverse of the one we are reading
from ROTM - so represents the transform in the other direction.

The way ROTM is defined is that first row represents the direction of
the x axis in device coordinates - so it's the transform from sensor
to device space.

I wonder if the hwdb matrix is defined from world space to sensor?  Seems
unlikely. 

The IIO ABI docs describe mount matrix as being what you apply to data to
tranform into device space (oh for a diagram in the docs).  Anyhow my reading
is that matches with ROTM definition but maybe I'm reading that wrong...

For extra annoyance, the ROTM matrix on this device isn't a rotation matrix.
It's flipping the handedness of the sensor.  Determinant isn't -1 which it
should be.  I guess the sensor itself might have an axis backwards from
windows convention though *sigh*  I think windows uses left handed convention
and looks like sensor is using right handed (which I think is what Android and
similar use).

> > 
> > which is the algebraic transposition (ie reflection in the diagonal)
> > of the DSDT one.
> > 
> > In other words, though the DST matrix is wrong, it is wrong in a
> > specific way - the rows should be the columns, and vv. I was just
> > wondering if this was a DSDT bug that might have been seen elsewhere
> > before.  
> 
> No this does not ring a bell, but the x and y axis being swapped
> does seem related to the LCD panel being 90° rotated.
> 
> > BTW, there is another matrix in the DSTD, but I can't find the
> > associated HID (10EC5280) anywhere (Linux sysfs or Windows Powershell
> > system data extract). It's not a correct matrix, though - could it be
> > just a bit of redundant code in the DST?  
> 
> Yes that is likely there often is a bunch of dead stuff DSDT leftover
> from other device models.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> > 
> > Darrell
> > 
> > On Sat, 4 Feb 2023 at 21:31, Hans de Goede <hdegoede@redhat.com> wrote:  
> >>
> >> Hi,
> >>
> >> On 2/4/23 18:09, Darrell Kavanagh wrote:  
> >>> I've just noticed that the working mount matrix that I added to my
> >>> hwdb is the matrix retrieved from the ACPI ROTM call in the amended
> >>> driver, transposed.  
> >>
> >> An other word for the mount matrix would be a rotation matrix,
> >> since it defines how the physical sensor is mounted on the PCB
> >> in a rotated fashion compared to its standard orientation.
> >>
> >> The x, y, z axis relationship underling of course does
> >> not change by the rotation, so yes all mount matrices
> >> are a transposition of the standard:
> >>
> >> 1, 0, 0 : 0, 1, 0 : 0, 0, 1
> >>
> >> matrix, that is expected. Where that to not be the case
> >> then there would be a bug in the accelerometer driver itself
> >> where the driver itself is swapping or inverting axis.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >>  
> >>> On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
> >>> <darrell.kavanagh@gmail.com> wrote:  
> >>>>
> >>>> Finally got a 6.2.0-rc6 kernel built and installed, with the following
> >>>> patch, and everything is working as expected.
> >>>>
> >>>> Moving on now to look at Bastien's suggestion.
> >>>>
> >>>> Thanks,
> >>>> Darrell
> >>>>
> >>>> diff --git a/kernel/drm_panel_orientation_quirks.c
> >>>> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>> index 3659f04..590bb7b 100644
> >>>> --- a/kernel/drm_panel_orientation_quirks.c
> >>>> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
> >>>>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> >>>> D330-10IGM"),
> >>>>                 },
> >>>>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
> >>>> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
> >>>> +               .matches = {
> >>>> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >>>> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> >>>> +               },
> >>>> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
> >>>>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
> >>>>                 .matches = {
> >>>>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >>>>
> >>>> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:  
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 2/1/23 18:50, Darrell Kavanagh wrote:  
> >>>>>> Thank you. I don't have anything that could be called a big machine.
> >>>>>> The fastest processor I have access to is a Core m3-8100Y - that's in
> >>>>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
> >>>>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> >>>>>> machine which is slower than the m3 in theory, but that has 6GB of
> >>>>>> memory.
> >>>>>>
> >>>>>> Is the kernel build more processor or memory bound?  
> >>>>>
> >>>>> It is mostly processor bound, esp. wtih something like make -j4,
> >>>>> make -j16 will start taking some RAM, but with make -j4 I expect you
> >>>>> to be fully CPU bound.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hans
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>  
> >>>>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:  
> >>>>>>>
> >>>>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:  
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:  
> >>>>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
> >>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>>>>>>  
> >>>>>>>>>> Hello, all.
> >>>>>>>>>>
> >>>>>>>>>> I've finally reached a conclusion on this, after testing all the
> >>>>>>>>>> combinations of the patches (with and without reading the acpi
> >>>>>>>>>> mounting matrix), window managers (wayland, xorg) and the
> >>>>>>>>>> presence or
> >>>>>>>>>> not of my custom kernel parms.
> >>>>>>>>>>
> >>>>>>>>>> What works well is the full set of patches with the custom kernel
> >>>>>>>>>> parms and a new hwdb entry for the sensor:
> >>>>>>>>>>
> >>>>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> >>>>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> >>>>>>>>>>
> >>>>>>>>>> The autorotate then works correctly in wayland and xorg, but for
> >>>>>>>>>> xorg,
> >>>>>>>>>> the settings say the screen is "portrait left" when in actual
> >>>>>>>>>> fact it
> >>>>>>>>>> is in standard laptop landscape orientation. Wayland does not
> >>>>>>>>>> have
> >>>>>>>>>> this problem (I guess because wayland's view of the screen is
> >>>>>>>>>> straight
> >>>>>>>>>> from the kernel).
> >>>>>>>>>>
> >>>>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
> >>>>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
> >>>>>>>>>> have
> >>>>>>>>>> gone either way here with appropriate hwdb entries, but my view
> >>>>>>>>>> is
> >>>>>>>>>> that we *should* be using the matrix.  
> >>>>>>>>>
> >>>>>>>>> Added Hans de Goede as he has probably run into more of this mess
> >>>>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
> >>>>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*  
> >>>>>>>>
> >>>>>>>> I see below that this laptop has a panel which is mounted 90 degrees
> >>>>>>>> rotated, that likely explains why the ACPI matrix does not work.
> >>>>>>>> So the best thing to do here is to just override it with a hwdb
> >>>>>>>> entries.
> >>>>>>>>
> >>>>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
> >>>>>>>> override the ACPI provided matrix because of similar issues.
> >>>>>>>>
> >>>>>>>> Linux userspace expects the matrix in this case to be set so that
> >>>>>>>> it causes e.g. gnome's auto-rotation to put the image upright
> >>>>>>>> even with older gnome versions / mate / xfce which don't know about
> >>>>>>>> the panel being mounted 90 degrees.
> >>>>>>>>
> >>>>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> >>>>>>>> while the device is actually in normal clamshell mode with the
> >>>>>>>> display up-right.
> >>>>>>>>
> >>>>>>>> This reporting of left-side-up or right-side-up is actually "correct"
> >>>>>>>> looking from the native LCD panel orientation and as mentioned is
> >>>>>>>> done for backward compatibility. This is documented here:
> >>>>>>>>
> >>>>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> >>>>>>>>
> >>>>>>>> The way we are handling this is likely incompatible with how Windows
> >>>>>>>> handles this special case of 90° rotated screen + ROTM. Or the
> >>>>>>>> matrix in the ACPI tables could be just wrong...
> >>>>>>>>  
> >>>>>>>>> I think 'ROTM' is defined by MS.
> >>>>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries  
> >>>>>>>>
> >>>>>>>> Right and as such it would be good if we can still add support to
> >>>>>>>> it to the sensor driver in question. Because the ROTM info usually
> >>>>>>>> is correct and avoids the need for adding more and more hwdb entries.
> >>>>>>>>
> >>>>>>>> Note there already is existing support in some other sensor drivers.
> >>>>>>>>
> >>>>>>>> So we probably need to factor out some helper code for this and share
> >>>>>>>> that between sensor drivers.
> >>>>>>>>
> >>>>>>>>  
> >>>>>>>>>> The only thing that concerns me is the need for custom kernel
> >>>>>>>>>> parms.
> >>>>>>>>>> It would be better if there was a way to avoid this, so that the
> >>>>>>>>>> user
> >>>>>>>>>> didn't have to mess around with their grub config. Though having
> >>>>>>>>>> said
> >>>>>>>>>> that, the sensors fix as we have it doesn't make things worse -
> >>>>>>>>>> under
> >>>>>>>>>> currently released kernels the screen always starts up sideways
> >>>>>>>>>> unless
> >>>>>>>>>> custom parms are added in grub.  
> >>>>>>>>
> >>>>>>>> We actually have a quirk mechanism in the kernel for specifying
> >>>>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> >>>>>>>> will also automatically fix the fbcon orientation, see:
> >>>>>>>>
> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>>>>>>
> >>>>>>>> If you submit a patch for this upstream please Cc me.  
> >>>>>>>
> >>>>>>> And if after that change, and copy/pasting the orientation from the
> >>>>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
> >>>>>>> maybe stealing the BMC150 driver's
> >>>>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
> >>>>>>>
> >>>>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
> >>>>>>> and read it without the need for a hwdb entry.
> >>>>>>>
> >>>>>>> Cheers  
> >>>>>>  
> >>>>>  
> >>>  
> >>  
> >   
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-05 14:36                                                 ` Jonathan Cameron
@ 2023-02-05 16:06                                                   ` Darrell Kavanagh
  2023-02-05 18:06                                                     ` Hans de Goede
  0 siblings, 1 reply; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-05 16:06 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Hans de Goede, Bastien Nocera, Jonathan Cameron, linux-iio, linux-kernel

So does this mean that the least worst (only?) option is to get my
hwdb mount matrix entry added to systemd? I can raise a bug as
suggested in hwdb.d/60-sensor.hwdb if so.

Darrell

On Sun, 5 Feb 2023 at 14:22, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Sun, 5 Feb 2023 09:50:51 +0100
> Hans de Goede <hdegoede@redhat.com> wrote:
>
> > Hi,
> >
> > On 2/4/23 23:15, Darrell Kavanagh wrote:
> > > Yes, I understand that.
> > >
> > > What I mean is that the matrix read from the DSDT by Jonathan's
> > > amended driver is
> > >
> > >  0 -1  0
> > >  1  0  0
> > >  0  0  1
> > >
> > > and the (correct) matrix created with my new hwdb entry is
> > >
> > >  0  1  0
> > > -1  0  0
> > >  0  0  1
>
> May be concidence, but I think that's the inverse of the one we are reading
> from ROTM - so represents the transform in the other direction.
>
> The way ROTM is defined is that first row represents the direction of
> the x axis in device coordinates - so it's the transform from sensor
> to device space.
>
> I wonder if the hwdb matrix is defined from world space to sensor?  Seems
> unlikely.
>
> The IIO ABI docs describe mount matrix as being what you apply to data to
> tranform into device space (oh for a diagram in the docs).  Anyhow my reading
> is that matches with ROTM definition but maybe I'm reading that wrong...
>
> For extra annoyance, the ROTM matrix on this device isn't a rotation matrix.
> It's flipping the handedness of the sensor.  Determinant isn't -1 which it
> should be.  I guess the sensor itself might have an axis backwards from
> windows convention though *sigh*  I think windows uses left handed convention
> and looks like sensor is using right handed (which I think is what Android and
> similar use).
>
> > >
> > > which is the algebraic transposition (ie reflection in the diagonal)
> > > of the DSDT one.
> > >
> > > In other words, though the DST matrix is wrong, it is wrong in a
> > > specific way - the rows should be the columns, and vv. I was just
> > > wondering if this was a DSDT bug that might have been seen elsewhere
> > > before.
> >
> > No this does not ring a bell, but the x and y axis being swapped
> > does seem related to the LCD panel being 90° rotated.
> >
> > > BTW, there is another matrix in the DSTD, but I can't find the
> > > associated HID (10EC5280) anywhere (Linux sysfs or Windows Powershell
> > > system data extract). It's not a correct matrix, though - could it be
> > > just a bit of redundant code in the DST?
> >
> > Yes that is likely there often is a bunch of dead stuff DSDT leftover
> > from other device models.
> >
> > Regards,
> >
> > Hans
> >
> >
> >
> >
> >
> > >
> > > Darrell
> > >
> > > On Sat, 4 Feb 2023 at 21:31, Hans de Goede <hdegoede@redhat.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 2/4/23 18:09, Darrell Kavanagh wrote:
> > >>> I've just noticed that the working mount matrix that I added to my
> > >>> hwdb is the matrix retrieved from the ACPI ROTM call in the amended
> > >>> driver, transposed.
> > >>
> > >> An other word for the mount matrix would be a rotation matrix,
> > >> since it defines how the physical sensor is mounted on the PCB
> > >> in a rotated fashion compared to its standard orientation.
> > >>
> > >> The x, y, z axis relationship underling of course does
> > >> not change by the rotation, so yes all mount matrices
> > >> are a transposition of the standard:
> > >>
> > >> 1, 0, 0 : 0, 1, 0 : 0, 0, 1
> > >>
> > >> matrix, that is expected. Where that to not be the case
> > >> then there would be a bug in the accelerometer driver itself
> > >> where the driver itself is swapping or inverting axis.
> > >>
> > >> Regards,
> > >>
> > >> Hans
> > >>
> > >>
> > >>
> > >>
> > >>> On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
> > >>> <darrell.kavanagh@gmail.com> wrote:
> > >>>>
> > >>>> Finally got a 6.2.0-rc6 kernel built and installed, with the following
> > >>>> patch, and everything is working as expected.
> > >>>>
> > >>>> Moving on now to look at Bastien's suggestion.
> > >>>>
> > >>>> Thanks,
> > >>>> Darrell
> > >>>>
> > >>>> diff --git a/kernel/drm_panel_orientation_quirks.c
> > >>>> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > >>>> index 3659f04..590bb7b 100644
> > >>>> --- a/kernel/drm_panel_orientation_quirks.c
> > >>>> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > >>>> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
> > >>>>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> > >>>> D330-10IGM"),
> > >>>>                 },
> > >>>>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
> > >>>> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
> > >>>> +               .matches = {
> > >>>> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > >>>> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> > >>>> +               },
> > >>>> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
> > >>>>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
> > >>>>                 .matches = {
> > >>>>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> > >>>>
> > >>>> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> On 2/1/23 18:50, Darrell Kavanagh wrote:
> > >>>>>> Thank you. I don't have anything that could be called a big machine.
> > >>>>>> The fastest processor I have access to is a Core m3-8100Y - that's in
> > >>>>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
> > >>>>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> > >>>>>> machine which is slower than the m3 in theory, but that has 6GB of
> > >>>>>> memory.
> > >>>>>>
> > >>>>>> Is the kernel build more processor or memory bound?
> > >>>>>
> > >>>>> It is mostly processor bound, esp. wtih something like make -j4,
> > >>>>> make -j16 will start taking some RAM, but with make -j4 I expect you
> > >>>>> to be fully CPU bound.
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> Hans
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
> > >>>>>>>
> > >>>>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:
> > >>>>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
> > >>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Hello, all.
> > >>>>>>>>>>
> > >>>>>>>>>> I've finally reached a conclusion on this, after testing all the
> > >>>>>>>>>> combinations of the patches (with and without reading the acpi
> > >>>>>>>>>> mounting matrix), window managers (wayland, xorg) and the
> > >>>>>>>>>> presence or
> > >>>>>>>>>> not of my custom kernel parms.
> > >>>>>>>>>>
> > >>>>>>>>>> What works well is the full set of patches with the custom kernel
> > >>>>>>>>>> parms and a new hwdb entry for the sensor:
> > >>>>>>>>>>
> > >>>>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> > >>>>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> > >>>>>>>>>>
> > >>>>>>>>>> The autorotate then works correctly in wayland and xorg, but for
> > >>>>>>>>>> xorg,
> > >>>>>>>>>> the settings say the screen is "portrait left" when in actual
> > >>>>>>>>>> fact it
> > >>>>>>>>>> is in standard laptop landscape orientation. Wayland does not
> > >>>>>>>>>> have
> > >>>>>>>>>> this problem (I guess because wayland's view of the screen is
> > >>>>>>>>>> straight
> > >>>>>>>>>> from the kernel).
> > >>>>>>>>>>
> > >>>>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
> > >>>>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
> > >>>>>>>>>> have
> > >>>>>>>>>> gone either way here with appropriate hwdb entries, but my view
> > >>>>>>>>>> is
> > >>>>>>>>>> that we *should* be using the matrix.
> > >>>>>>>>>
> > >>>>>>>>> Added Hans de Goede as he has probably run into more of this mess
> > >>>>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
> > >>>>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
> > >>>>>>>>
> > >>>>>>>> I see below that this laptop has a panel which is mounted 90 degrees
> > >>>>>>>> rotated, that likely explains why the ACPI matrix does not work.
> > >>>>>>>> So the best thing to do here is to just override it with a hwdb
> > >>>>>>>> entries.
> > >>>>>>>>
> > >>>>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
> > >>>>>>>> override the ACPI provided matrix because of similar issues.
> > >>>>>>>>
> > >>>>>>>> Linux userspace expects the matrix in this case to be set so that
> > >>>>>>>> it causes e.g. gnome's auto-rotation to put the image upright
> > >>>>>>>> even with older gnome versions / mate / xfce which don't know about
> > >>>>>>>> the panel being mounted 90 degrees.
> > >>>>>>>>
> > >>>>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> > >>>>>>>> while the device is actually in normal clamshell mode with the
> > >>>>>>>> display up-right.
> > >>>>>>>>
> > >>>>>>>> This reporting of left-side-up or right-side-up is actually "correct"
> > >>>>>>>> looking from the native LCD panel orientation and as mentioned is
> > >>>>>>>> done for backward compatibility. This is documented here:
> > >>>>>>>>
> > >>>>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> > >>>>>>>>
> > >>>>>>>> The way we are handling this is likely incompatible with how Windows
> > >>>>>>>> handles this special case of 90° rotated screen + ROTM. Or the
> > >>>>>>>> matrix in the ACPI tables could be just wrong...
> > >>>>>>>>
> > >>>>>>>>> I think 'ROTM' is defined by MS.
> > >>>>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> > >>>>>>>>
> > >>>>>>>> Right and as such it would be good if we can still add support to
> > >>>>>>>> it to the sensor driver in question. Because the ROTM info usually
> > >>>>>>>> is correct and avoids the need for adding more and more hwdb entries.
> > >>>>>>>>
> > >>>>>>>> Note there already is existing support in some other sensor drivers.
> > >>>>>>>>
> > >>>>>>>> So we probably need to factor out some helper code for this and share
> > >>>>>>>> that between sensor drivers.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>> The only thing that concerns me is the need for custom kernel
> > >>>>>>>>>> parms.
> > >>>>>>>>>> It would be better if there was a way to avoid this, so that the
> > >>>>>>>>>> user
> > >>>>>>>>>> didn't have to mess around with their grub config. Though having
> > >>>>>>>>>> said
> > >>>>>>>>>> that, the sensors fix as we have it doesn't make things worse -
> > >>>>>>>>>> under
> > >>>>>>>>>> currently released kernels the screen always starts up sideways
> > >>>>>>>>>> unless
> > >>>>>>>>>> custom parms are added in grub.
> > >>>>>>>>
> > >>>>>>>> We actually have a quirk mechanism in the kernel for specifying
> > >>>>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> > >>>>>>>> will also automatically fix the fbcon orientation, see:
> > >>>>>>>>
> > >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > >>>>>>>>
> > >>>>>>>> If you submit a patch for this upstream please Cc me.
> > >>>>>>>
> > >>>>>>> And if after that change, and copy/pasting the orientation from the
> > >>>>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
> > >>>>>>> maybe stealing the BMC150 driver's
> > >>>>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
> > >>>>>>>
> > >>>>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
> > >>>>>>> and read it without the need for a hwdb entry.
> > >>>>>>>
> > >>>>>>> Cheers
> > >>>>>>
> > >>>>>
> > >>>
> > >>
> > >
> >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-05 16:06                                                   ` Darrell Kavanagh
@ 2023-02-05 18:06                                                     ` Hans de Goede
  2023-02-05 22:05                                                       ` Darrell Kavanagh
  0 siblings, 1 reply; 29+ messages in thread
From: Hans de Goede @ 2023-02-05 18:06 UTC (permalink / raw)
  To: Darrell Kavanagh, Jonathan Cameron
  Cc: Bastien Nocera, Jonathan Cameron, linux-iio, linux-kernel

Hi,

On 2/5/23 17:06, Darrell Kavanagh wrote:
> So does this mean that the least worst (only?) option is to get my
> hwdb mount matrix entry added to systemd? I can raise a bug as
> suggested in hwdb.d/60-sensor.hwdb if so.

Yes you should add a hwdb entry for this, note just submitting
a pull-req with the fix is better then filing an issue for this.

Regards,

Hans



> On Sun, 5 Feb 2023 at 14:22, Jonathan Cameron <jic23@kernel.org> wrote:
>>
>> On Sun, 5 Feb 2023 09:50:51 +0100
>> Hans de Goede <hdegoede@redhat.com> wrote:
>>
>>> Hi,
>>>
>>> On 2/4/23 23:15, Darrell Kavanagh wrote:
>>>> Yes, I understand that.
>>>>
>>>> What I mean is that the matrix read from the DSDT by Jonathan's
>>>> amended driver is
>>>>
>>>>  0 -1  0
>>>>  1  0  0
>>>>  0  0  1
>>>>
>>>> and the (correct) matrix created with my new hwdb entry is
>>>>
>>>>  0  1  0
>>>> -1  0  0
>>>>  0  0  1
>>
>> May be concidence, but I think that's the inverse of the one we are reading
>> from ROTM - so represents the transform in the other direction.
>>
>> The way ROTM is defined is that first row represents the direction of
>> the x axis in device coordinates - so it's the transform from sensor
>> to device space.
>>
>> I wonder if the hwdb matrix is defined from world space to sensor?  Seems
>> unlikely.
>>
>> The IIO ABI docs describe mount matrix as being what you apply to data to
>> tranform into device space (oh for a diagram in the docs).  Anyhow my reading
>> is that matches with ROTM definition but maybe I'm reading that wrong...
>>
>> For extra annoyance, the ROTM matrix on this device isn't a rotation matrix.
>> It's flipping the handedness of the sensor.  Determinant isn't -1 which it
>> should be.  I guess the sensor itself might have an axis backwards from
>> windows convention though *sigh*  I think windows uses left handed convention
>> and looks like sensor is using right handed (which I think is what Android and
>> similar use).
>>
>>>>
>>>> which is the algebraic transposition (ie reflection in the diagonal)
>>>> of the DSDT one.
>>>>
>>>> In other words, though the DST matrix is wrong, it is wrong in a
>>>> specific way - the rows should be the columns, and vv. I was just
>>>> wondering if this was a DSDT bug that might have been seen elsewhere
>>>> before.
>>>
>>> No this does not ring a bell, but the x and y axis being swapped
>>> does seem related to the LCD panel being 90° rotated.
>>>
>>>> BTW, there is another matrix in the DSTD, but I can't find the
>>>> associated HID (10EC5280) anywhere (Linux sysfs or Windows Powershell
>>>> system data extract). It's not a correct matrix, though - could it be
>>>> just a bit of redundant code in the DST?
>>>
>>> Yes that is likely there often is a bunch of dead stuff DSDT leftover
>>> from other device models.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Darrell
>>>>
>>>> On Sat, 4 Feb 2023 at 21:31, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 2/4/23 18:09, Darrell Kavanagh wrote:
>>>>>> I've just noticed that the working mount matrix that I added to my
>>>>>> hwdb is the matrix retrieved from the ACPI ROTM call in the amended
>>>>>> driver, transposed.
>>>>>
>>>>> An other word for the mount matrix would be a rotation matrix,
>>>>> since it defines how the physical sensor is mounted on the PCB
>>>>> in a rotated fashion compared to its standard orientation.
>>>>>
>>>>> The x, y, z axis relationship underling of course does
>>>>> not change by the rotation, so yes all mount matrices
>>>>> are a transposition of the standard:
>>>>>
>>>>> 1, 0, 0 : 0, 1, 0 : 0, 0, 1
>>>>>
>>>>> matrix, that is expected. Where that to not be the case
>>>>> then there would be a bug in the accelerometer driver itself
>>>>> where the driver itself is swapping or inverting axis.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
>>>>>> <darrell.kavanagh@gmail.com> wrote:
>>>>>>>
>>>>>>> Finally got a 6.2.0-rc6 kernel built and installed, with the following
>>>>>>> patch, and everything is working as expected.
>>>>>>>
>>>>>>> Moving on now to look at Bastien's suggestion.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Darrell
>>>>>>>
>>>>>>> diff --git a/kernel/drm_panel_orientation_quirks.c
>>>>>>> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>>>>> index 3659f04..590bb7b 100644
>>>>>>> --- a/kernel/drm_panel_orientation_quirks.c
>>>>>>> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>>>>> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
>>>>>>>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
>>>>>>> D330-10IGM"),
>>>>>>>                 },
>>>>>>>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
>>>>>>> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
>>>>>>> +               .matches = {
>>>>>>> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>>>>>> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
>>>>>>> +               },
>>>>>>> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
>>>>>>>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
>>>>>>>                 .matches = {
>>>>>>>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>>>>>>>
>>>>>>> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 2/1/23 18:50, Darrell Kavanagh wrote:
>>>>>>>>> Thank you. I don't have anything that could be called a big machine.
>>>>>>>>> The fastest processor I have access to is a Core m3-8100Y - that's in
>>>>>>>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
>>>>>>>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
>>>>>>>>> machine which is slower than the m3 in theory, but that has 6GB of
>>>>>>>>> memory.
>>>>>>>>>
>>>>>>>>> Is the kernel build more processor or memory bound?
>>>>>>>>
>>>>>>>> It is mostly processor bound, esp. wtih something like make -j4,
>>>>>>>> make -j16 will start taking some RAM, but with make -j4 I expect you
>>>>>>>> to be fully CPU bound.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:
>>>>>>>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
>>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello, all.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've finally reached a conclusion on this, after testing all the
>>>>>>>>>>>>> combinations of the patches (with and without reading the acpi
>>>>>>>>>>>>> mounting matrix), window managers (wayland, xorg) and the
>>>>>>>>>>>>> presence or
>>>>>>>>>>>>> not of my custom kernel parms.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What works well is the full set of patches with the custom kernel
>>>>>>>>>>>>> parms and a new hwdb entry for the sensor:
>>>>>>>>>>>>>
>>>>>>>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
>>>>>>>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
>>>>>>>>>>>>>
>>>>>>>>>>>>> The autorotate then works correctly in wayland and xorg, but for
>>>>>>>>>>>>> xorg,
>>>>>>>>>>>>> the settings say the screen is "portrait left" when in actual
>>>>>>>>>>>>> fact it
>>>>>>>>>>>>> is in standard laptop landscape orientation. Wayland does not
>>>>>>>>>>>>> have
>>>>>>>>>>>>> this problem (I guess because wayland's view of the screen is
>>>>>>>>>>>>> straight
>>>>>>>>>>>>> from the kernel).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
>>>>>>>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
>>>>>>>>>>>>> have
>>>>>>>>>>>>> gone either way here with appropriate hwdb entries, but my view
>>>>>>>>>>>>> is
>>>>>>>>>>>>> that we *should* be using the matrix.
>>>>>>>>>>>>
>>>>>>>>>>>> Added Hans de Goede as he has probably run into more of this mess
>>>>>>>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
>>>>>>>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
>>>>>>>>>>>
>>>>>>>>>>> I see below that this laptop has a panel which is mounted 90 degrees
>>>>>>>>>>> rotated, that likely explains why the ACPI matrix does not work.
>>>>>>>>>>> So the best thing to do here is to just override it with a hwdb
>>>>>>>>>>> entries.
>>>>>>>>>>>
>>>>>>>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
>>>>>>>>>>> override the ACPI provided matrix because of similar issues.
>>>>>>>>>>>
>>>>>>>>>>> Linux userspace expects the matrix in this case to be set so that
>>>>>>>>>>> it causes e.g. gnome's auto-rotation to put the image upright
>>>>>>>>>>> even with older gnome versions / mate / xfce which don't know about
>>>>>>>>>>> the panel being mounted 90 degrees.
>>>>>>>>>>>
>>>>>>>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
>>>>>>>>>>> while the device is actually in normal clamshell mode with the
>>>>>>>>>>> display up-right.
>>>>>>>>>>>
>>>>>>>>>>> This reporting of left-side-up or right-side-up is actually "correct"
>>>>>>>>>>> looking from the native LCD panel orientation and as mentioned is
>>>>>>>>>>> done for backward compatibility. This is documented here:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
>>>>>>>>>>>
>>>>>>>>>>> The way we are handling this is likely incompatible with how Windows
>>>>>>>>>>> handles this special case of 90° rotated screen + ROTM. Or the
>>>>>>>>>>> matrix in the ACPI tables could be just wrong...
>>>>>>>>>>>
>>>>>>>>>>>> I think 'ROTM' is defined by MS.
>>>>>>>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
>>>>>>>>>>>
>>>>>>>>>>> Right and as such it would be good if we can still add support to
>>>>>>>>>>> it to the sensor driver in question. Because the ROTM info usually
>>>>>>>>>>> is correct and avoids the need for adding more and more hwdb entries.
>>>>>>>>>>>
>>>>>>>>>>> Note there already is existing support in some other sensor drivers.
>>>>>>>>>>>
>>>>>>>>>>> So we probably need to factor out some helper code for this and share
>>>>>>>>>>> that between sensor drivers.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> The only thing that concerns me is the need for custom kernel
>>>>>>>>>>>>> parms.
>>>>>>>>>>>>> It would be better if there was a way to avoid this, so that the
>>>>>>>>>>>>> user
>>>>>>>>>>>>> didn't have to mess around with their grub config. Though having
>>>>>>>>>>>>> said
>>>>>>>>>>>>> that, the sensors fix as we have it doesn't make things worse -
>>>>>>>>>>>>> under
>>>>>>>>>>>>> currently released kernels the screen always starts up sideways
>>>>>>>>>>>>> unless
>>>>>>>>>>>>> custom parms are added in grub.
>>>>>>>>>>>
>>>>>>>>>>> We actually have a quirk mechanism in the kernel for specifying
>>>>>>>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
>>>>>>>>>>> will also automatically fix the fbcon orientation, see:
>>>>>>>>>>>
>>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
>>>>>>>>>>>
>>>>>>>>>>> If you submit a patch for this upstream please Cc me.
>>>>>>>>>>
>>>>>>>>>> And if after that change, and copy/pasting the orientation from the
>>>>>>>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
>>>>>>>>>> maybe stealing the BMC150 driver's
>>>>>>>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
>>>>>>>>>>
>>>>>>>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
>>>>>>>>>> and read it without the need for a hwdb entry.
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)
  2023-02-05 18:06                                                     ` Hans de Goede
@ 2023-02-05 22:05                                                       ` Darrell Kavanagh
  0 siblings, 0 replies; 29+ messages in thread
From: Darrell Kavanagh @ 2023-02-05 22:05 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Jonathan Cameron, Bastien Nocera, Jonathan Cameron, linux-iio,
	linux-kernel

OK, pull request has been submitted.
https://github.com/systemd/systemd/pull/26317

On Sun, 5 Feb 2023 at 18:06, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 2/5/23 17:06, Darrell Kavanagh wrote:
> > So does this mean that the least worst (only?) option is to get my
> > hwdb mount matrix entry added to systemd? I can raise a bug as
> > suggested in hwdb.d/60-sensor.hwdb if so.
>
> Yes you should add a hwdb entry for this, note just submitting
> a pull-req with the fix is better then filing an issue for this.
>
> Regards,
>
> Hans
>
>
>
> > On Sun, 5 Feb 2023 at 14:22, Jonathan Cameron <jic23@kernel.org> wrote:
> >>
> >> On Sun, 5 Feb 2023 09:50:51 +0100
> >> Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> On 2/4/23 23:15, Darrell Kavanagh wrote:
> >>>> Yes, I understand that.
> >>>>
> >>>> What I mean is that the matrix read from the DSDT by Jonathan's
> >>>> amended driver is
> >>>>
> >>>>  0 -1  0
> >>>>  1  0  0
> >>>>  0  0  1
> >>>>
> >>>> and the (correct) matrix created with my new hwdb entry is
> >>>>
> >>>>  0  1  0
> >>>> -1  0  0
> >>>>  0  0  1
> >>
> >> May be concidence, but I think that's the inverse of the one we are reading
> >> from ROTM - so represents the transform in the other direction.
> >>
> >> The way ROTM is defined is that first row represents the direction of
> >> the x axis in device coordinates - so it's the transform from sensor
> >> to device space.
> >>
> >> I wonder if the hwdb matrix is defined from world space to sensor?  Seems
> >> unlikely.
> >>
> >> The IIO ABI docs describe mount matrix as being what you apply to data to
> >> tranform into device space (oh for a diagram in the docs).  Anyhow my reading
> >> is that matches with ROTM definition but maybe I'm reading that wrong...
> >>
> >> For extra annoyance, the ROTM matrix on this device isn't a rotation matrix.
> >> It's flipping the handedness of the sensor.  Determinant isn't -1 which it
> >> should be.  I guess the sensor itself might have an axis backwards from
> >> windows convention though *sigh*  I think windows uses left handed convention
> >> and looks like sensor is using right handed (which I think is what Android and
> >> similar use).
> >>
> >>>>
> >>>> which is the algebraic transposition (ie reflection in the diagonal)
> >>>> of the DSDT one.
> >>>>
> >>>> In other words, though the DST matrix is wrong, it is wrong in a
> >>>> specific way - the rows should be the columns, and vv. I was just
> >>>> wondering if this was a DSDT bug that might have been seen elsewhere
> >>>> before.
> >>>
> >>> No this does not ring a bell, but the x and y axis being swapped
> >>> does seem related to the LCD panel being 90° rotated.
> >>>
> >>>> BTW, there is another matrix in the DSTD, but I can't find the
> >>>> associated HID (10EC5280) anywhere (Linux sysfs or Windows Powershell
> >>>> system data extract). It's not a correct matrix, though - could it be
> >>>> just a bit of redundant code in the DST?
> >>>
> >>> Yes that is likely there often is a bunch of dead stuff DSDT leftover
> >>> from other device models.
> >>>
> >>> Regards,
> >>>
> >>> Hans
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> Darrell
> >>>>
> >>>> On Sat, 4 Feb 2023 at 21:31, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 2/4/23 18:09, Darrell Kavanagh wrote:
> >>>>>> I've just noticed that the working mount matrix that I added to my
> >>>>>> hwdb is the matrix retrieved from the ACPI ROTM call in the amended
> >>>>>> driver, transposed.
> >>>>>
> >>>>> An other word for the mount matrix would be a rotation matrix,
> >>>>> since it defines how the physical sensor is mounted on the PCB
> >>>>> in a rotated fashion compared to its standard orientation.
> >>>>>
> >>>>> The x, y, z axis relationship underling of course does
> >>>>> not change by the rotation, so yes all mount matrices
> >>>>> are a transposition of the standard:
> >>>>>
> >>>>> 1, 0, 0 : 0, 1, 0 : 0, 0, 1
> >>>>>
> >>>>> matrix, that is expected. Where that to not be the case
> >>>>> then there would be a bug in the accelerometer driver itself
> >>>>> where the driver itself is swapping or inverting axis.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hans
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Fri, 3 Feb 2023 at 18:23, Darrell Kavanagh
> >>>>>> <darrell.kavanagh@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Finally got a 6.2.0-rc6 kernel built and installed, with the following
> >>>>>>> patch, and everything is working as expected.
> >>>>>>>
> >>>>>>> Moving on now to look at Bastien's suggestion.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Darrell
> >>>>>>>
> >>>>>>> diff --git a/kernel/drm_panel_orientation_quirks.c
> >>>>>>> b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>>>>> index 3659f04..590bb7b 100644
> >>>>>>> --- a/kernel/drm_panel_orientation_quirks.c
> >>>>>>> +++ b/kernel/linux-6.2-rc6/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>>>>> @@ -304,6 +304,12 @@ static const struct dmi_system_id orientation_data[] = {
> >>>>>>>                   DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
> >>>>>>> D330-10IGM"),
> >>>>>>>                 },
> >>>>>>>                 .driver_data = (void *)&lcd1200x1920_rightside_up,
> >>>>>>> +       }, {    /* Lenovo IdeaPad Duet 3 10IGL5 */
> >>>>>>> +               .matches = {
> >>>>>>> +                 DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >>>>>>> +                 DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Duet 3 10IGL5"),
> >>>>>>> +               },
> >>>>>>> +               .driver_data = (void *)&lcd1200x1920_rightside_up,
> >>>>>>>         }, {    /* Lenovo Ideapad D330-10IGL (HD) */
> >>>>>>>                 .matches = {
> >>>>>>>                   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> >>>>>>>
> >>>>>>> On Wed, 1 Feb 2023 at 17:55, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On 2/1/23 18:50, Darrell Kavanagh wrote:
> >>>>>>>>> Thank you. I don't have anything that could be called a big machine.
> >>>>>>>>> The fastest processor I have access to is a Core m3-8100Y - that's in
> >>>>>>>>> a Chromebook with 4GB memory - it can run Linux in a chroot or
> >>>>>>>>> officially in Google's VM. I also have an ancient gen 2 core i5-2410M
> >>>>>>>>> machine which is slower than the m3 in theory, but that has 6GB of
> >>>>>>>>> memory.
> >>>>>>>>>
> >>>>>>>>> Is the kernel build more processor or memory bound?
> >>>>>>>>
> >>>>>>>> It is mostly processor bound, esp. wtih something like make -j4,
> >>>>>>>> make -j16 will start taking some RAM, but with make -j4 I expect you
> >>>>>>>> to be fully CPU bound.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>>
> >>>>>>>> Hans
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@hadess.net> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote:
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> On 2/1/23 11:28, Jonathan Cameron wrote:
> >>>>>>>>>>>> On Wed, 1 Feb 2023 01:40:49 +0000
> >>>>>>>>>>>> Darrell Kavanagh <darrell.kavanagh@gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hello, all.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I've finally reached a conclusion on this, after testing all the
> >>>>>>>>>>>>> combinations of the patches (with and without reading the acpi
> >>>>>>>>>>>>> mounting matrix), window managers (wayland, xorg) and the
> >>>>>>>>>>>>> presence or
> >>>>>>>>>>>>> not of my custom kernel parms.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> What works well is the full set of patches with the custom kernel
> >>>>>>>>>>>>> parms and a new hwdb entry for the sensor:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:*
> >>>>>>>>>>>>>  ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The autorotate then works correctly in wayland and xorg, but for
> >>>>>>>>>>>>> xorg,
> >>>>>>>>>>>>> the settings say the screen is "portrait left" when in actual
> >>>>>>>>>>>>> fact it
> >>>>>>>>>>>>> is in standard laptop landscape orientation. Wayland does not
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>> this problem (I guess because wayland's view of the screen is
> >>>>>>>>>>>>> straight
> >>>>>>>>>>>>> from the kernel).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Without the hwdb entry, the orientation is 90 degrees out without
> >>>>>>>>>>>>> using the acpi matrix and 180 degrees out when using it. I could
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>> gone either way here with appropriate hwdb entries, but my view
> >>>>>>>>>>>>> is
> >>>>>>>>>>>>> that we *should* be using the matrix.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Added Hans de Goede as he has probably run into more of this mess
> >>>>>>>>>>>> than anyone else.  Hans, any thoughts on if we are doing something
> >>>>>>>>>>>> wrong on kernel side?  Or is the matrix just wrong *sigh*
> >>>>>>>>>>>
> >>>>>>>>>>> I see below that this laptop has a panel which is mounted 90 degrees
> >>>>>>>>>>> rotated, that likely explains why the ACPI matrix does not work.
> >>>>>>>>>>> So the best thing to do here is to just override it with a hwdb
> >>>>>>>>>>> entries.
> >>>>>>>>>>>
> >>>>>>>>>>> IIRC there are already 1 or 2 other hwdb entries which actually
> >>>>>>>>>>> override the ACPI provided matrix because of similar issues.
> >>>>>>>>>>>
> >>>>>>>>>>> Linux userspace expects the matrix in this case to be set so that
> >>>>>>>>>>> it causes e.g. gnome's auto-rotation to put the image upright
> >>>>>>>>>>> even with older gnome versions / mate / xfce which don't know about
> >>>>>>>>>>> the panel being mounted 90 degrees.
> >>>>>>>>>>>
> >>>>>>>>>>> So e.g. "monitor-sensor" will report left-side-up or right-side-up
> >>>>>>>>>>> while the device is actually in normal clamshell mode with the
> >>>>>>>>>>> display up-right.
> >>>>>>>>>>>
> >>>>>>>>>>> This reporting of left-side-up or right-side-up is actually "correct"
> >>>>>>>>>>> looking from the native LCD panel orientation and as mentioned is
> >>>>>>>>>>> done for backward compatibility. This is documented here:
> >>>>>>>>>>>
> >>>>>>>>>>> https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54
> >>>>>>>>>>>
> >>>>>>>>>>> The way we are handling this is likely incompatible with how Windows
> >>>>>>>>>>> handles this special case of 90° rotated screen + ROTM. Or the
> >>>>>>>>>>> matrix in the ACPI tables could be just wrong...
> >>>>>>>>>>>
> >>>>>>>>>>>> I think 'ROTM' is defined by MS.
> >>>>>>>>>>>> https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries
> >>>>>>>>>>>
> >>>>>>>>>>> Right and as such it would be good if we can still add support to
> >>>>>>>>>>> it to the sensor driver in question. Because the ROTM info usually
> >>>>>>>>>>> is correct and avoids the need for adding more and more hwdb entries.
> >>>>>>>>>>>
> >>>>>>>>>>> Note there already is existing support in some other sensor drivers.
> >>>>>>>>>>>
> >>>>>>>>>>> So we probably need to factor out some helper code for this and share
> >>>>>>>>>>> that between sensor drivers.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> The only thing that concerns me is the need for custom kernel
> >>>>>>>>>>>>> parms.
> >>>>>>>>>>>>> It would be better if there was a way to avoid this, so that the
> >>>>>>>>>>>>> user
> >>>>>>>>>>>>> didn't have to mess around with their grub config. Though having
> >>>>>>>>>>>>> said
> >>>>>>>>>>>>> that, the sensors fix as we have it doesn't make things worse -
> >>>>>>>>>>>>> under
> >>>>>>>>>>>>> currently released kernels the screen always starts up sideways
> >>>>>>>>>>>>> unless
> >>>>>>>>>>>>> custom parms are added in grub.
> >>>>>>>>>>>
> >>>>>>>>>>> We actually have a quirk mechanism in the kernel for specifying
> >>>>>>>>>>> the need for: video=DSI-1:panel_orientation=right_side_up  and this
> >>>>>>>>>>> will also automatically fix the fbcon orientation, see:
> >>>>>>>>>>>
> >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c
> >>>>>>>>>>>
> >>>>>>>>>>> If you submit a patch for this upstream please Cc me.
> >>>>>>>>>>
> >>>>>>>>>> And if after that change, and copy/pasting the orientation from the
> >>>>>>>>>> DSDT into hwdb the sensor and screen move in the expected ways, then
> >>>>>>>>>> maybe stealing the BMC150 driver's
> >>>>>>>>>> bmc150_apply_bosc0200_acpi_orientation() might be a good idea.
> >>>>>>>>>>
> >>>>>>>>>> Once exported through "mount_matrix", iio-sensor-proxy should see it
> >>>>>>>>>> and read it without the need for a hwdb entry.
> >>>>>>>>>>
> >>>>>>>>>> Cheers
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2023-02-05 22:06 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <167493679618.4533.12181720504943588640.reportbug@debian-duet>
     [not found] ` <Y9WGmBc9HG4Tx9gf@eldamar.lan>
     [not found]   ` <CAMxBKG1670TFuV3nHP7Yk8s6H+oBF7iiyiB-b=PvKv9hcH22xQ@mail.gmail.com>
2023-01-29 18:24     ` Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:) Jonathan Cameron
     [not found]       ` <CAMxBKG0tyLSpaDPGBXsJbqgHSG9rH6owtSJsLw_ekmTA3Kyvdw@mail.gmail.com>
2023-01-30  3:37         ` Fwd: " Darrell Kavanagh
2023-01-30 12:31           ` Jonathan Cameron
2023-01-30 13:08             ` Darrell Kavanagh
2023-01-30 17:35               ` Jonathan Cameron
2023-01-30 18:32                 ` Darrell Kavanagh
2023-01-30 19:41                   ` Jonathan Cameron
2023-01-30 20:02                     ` Darrell Kavanagh
2023-01-30 20:31                       ` Jonathan Cameron
2023-01-31 13:34                         ` Darrell Kavanagh
2023-02-01  1:40                           ` Darrell Kavanagh
2023-02-01  1:46                             ` Darrell Kavanagh
2023-02-01 10:29                               ` Jonathan Cameron
2023-02-01 10:28                             ` Jonathan Cameron
2023-02-01 11:00                               ` Hans de Goede
2023-02-01 15:03                                 ` Darrell Kavanagh
2023-02-01 15:46                                   ` Hans de Goede
2023-02-01 16:12                                 ` Bastien Nocera
2023-02-01 17:50                                   ` Darrell Kavanagh
2023-02-01 17:55                                     ` Hans de Goede
2023-02-03 18:23                                       ` Darrell Kavanagh
2023-02-04 17:09                                         ` Darrell Kavanagh
2023-02-04 21:31                                           ` Hans de Goede
2023-02-04 22:15                                             ` Darrell Kavanagh
2023-02-05  8:50                                               ` Hans de Goede
2023-02-05 14:36                                                 ` Jonathan Cameron
2023-02-05 16:06                                                   ` Darrell Kavanagh
2023-02-05 18:06                                                     ` Hans de Goede
2023-02-05 22:05                                                       ` Darrell Kavanagh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).