From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4EE27C05027 for ; Wed, 1 Feb 2023 17:56:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229923AbjBAR4d (ORCPT ); Wed, 1 Feb 2023 12:56:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229612AbjBAR4c (ORCPT ); Wed, 1 Feb 2023 12:56:32 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3AB37D9AB for ; Wed, 1 Feb 2023 09:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675274146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vFAeXA1XdcMNLN0rSiKe5P8CKHTtok03BfRTmM0Pwgo=; b=Fs+MXS2fQBzP9qYNEzras+9QiUA8KLrLRfoIQqJvmKAk5LcPMdvsJVeNzu7RUBCe8iIkvT 5WeTcvz+mPgAgx6YAhUScyKjTg/ilCufHuUSeTCoQbifuMGc9o/1aFFoWifpaFF+lRN4sO gYV4BYGYtp0lssbbEnRTCYBmHkjxV/M= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-544-sHhcaTSFOJSQESXgN_Sl9Q-1; Wed, 01 Feb 2023 12:55:44 -0500 X-MC-Unique: sHhcaTSFOJSQESXgN_Sl9Q-1 Received: by mail-ed1-f72.google.com with SMTP id g19-20020a056402115300b004a26cc7f6cbso3924722edw.4 for ; Wed, 01 Feb 2023 09:55:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vFAeXA1XdcMNLN0rSiKe5P8CKHTtok03BfRTmM0Pwgo=; b=IwoIdUB/DxBRCg56BBSlVZgKMyIOv1qS9R+0OsIOzyeTwJCzFmErpQ+8O1T+88sCgr pFhbYcGdTuov7lpsaKuU/j+oZTrZEO0RISAh3os8Z8LOEA1XWyFlcSXm/PPtdjEpSJfH ykLXpDLYkg8amuedC1x/QgZgZNNZlBlk1d8esZDreXuQxkYXdwcqHxu21WfTO8vYs1KE ntT5NFZW31Jpmw2oOeCrefOf9o2ULhOn7fjfAnBLFDo699ykNbQbX1d5Ehprp21LnQho pqRycXoUTZ03qQFZdPBGqFQ0OV/NrnWHjjn4WKuIo7gojUFmEjKcoMVez8DA2r3VrWTZ XHlg== X-Gm-Message-State: AO0yUKWjHeImedePRuDF5XSdV3n8QYEh5Ynf7FwLptKDl5/CcfYV8q6R LSyE0NixVVWmAmZd0J80+6bYj8XNHeIBnS018lFkG63fFxrEDFn+xlVCFfnYHQrPWIV2G1reuZC tTMWrbiGUjaW4DMJHdskt X-Received: by 2002:a17:907:d38b:b0:878:7449:429f with SMTP id vh11-20020a170907d38b00b008787449429fmr3327468ejc.16.1675274143666; Wed, 01 Feb 2023 09:55:43 -0800 (PST) X-Google-Smtp-Source: AK7set+IQFJ+Dd/5eLlvpo4HyU3h1W+V9gisNjQIRkgJ0Gy8saNxMttk9mNAi8DgwLOJ1U70gnX7mA== X-Received: by 2002:a17:907:d38b:b0:878:7449:429f with SMTP id vh11-20020a170907d38b00b008787449429fmr3327458ejc.16.1675274143434; Wed, 01 Feb 2023 09:55:43 -0800 (PST) Received: from ?IPV6:2001:1c00:c32:7800:5bfa:a036:83f0:f9ec? (2001-1c00-0c32-7800-5bfa-a036-83f0-f9ec.cable.dynamic.v6.ziggo.nl. [2001:1c00:c32:7800:5bfa:a036:83f0:f9ec]) by smtp.gmail.com with ESMTPSA id q8-20020a056402032800b004a24b8b58cbsm4406633edw.16.2023.02.01.09.55.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 09:55:42 -0800 (PST) Message-ID: <7005e022-dd4c-835c-bdc2-11bbbd214071@redhat.com> Date: Wed, 1 Feb 2023 18:55:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:) Content-Language: en-US, nl To: Darrell Kavanagh , Bastien Nocera Cc: Jonathan Cameron , Jonathan Cameron , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org References: <167493679618.4533.12181720504943588640.reportbug@debian-duet> <20230129182441.082f29d0@jic23-huawei> <20230130123113.00002c3f@Huawei.com> <20230130173525.0000418d@huawei.com> <20230130194110.256144e7@jic23-huawei> <20230130203110.60c96f37@jic23-huawei> <20230201102824.00002044@Huawei.com> From: Hans de Goede In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org 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 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 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 >