Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp664090ybc; Tue, 19 Nov 2019 07:19:59 -0800 (PST) X-Google-Smtp-Source: APXvYqx162STRkgk55W3toiCxTiAVonkpw/bqdSAqUHzg4dbIESZCcF1CA/THKQQJX8uQGLhOXXE X-Received: by 2002:a2e:8508:: with SMTP id j8mr4379311lji.136.1574176799181; Tue, 19 Nov 2019 07:19:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574176799; cv=none; d=google.com; s=arc-20160816; b=B1qSXxhtUNrgJZJxTq9736N/7KocR4h29l5/MVRMYY37+jEDUaaVDckJpGIrZJyHki 55mbmRmvJxB8H7pByTPlvUShEg1nte7tKwLrPfE5Ct4SQ4g6ZWFZpW2t2f4D7fDqudqQ 16wK3M//z+5UBMl/6Fpv8Jy/wnh5QJCCBPttUx4JIBGhKV3Ic+hEftvQB600SAjjZgZi gPcyDLSXjb7ghFfvgeHL7f6WNF3JSubNm4y2rM/2jEwoAkBJCuAxI+rsZ5K2/2NfUZPw VlBE6ChjtuUaTd+TRLEW6JaO93872hAD/moL5CbOGZToV5bdncrKPDL6LSA2IQV2B9Jx kGsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=W44n0jnAWgfO1rcmYb1hXUHI1Cvs6LKx+Od1R8CiNaI=; b=TRlAXp5EPkGiYepHOnwhfRxV0xKK08Vv/OmV/e8aHvVtTqGr5w5FC2qWXkRw1/Qln0 WrM1ib/m6ItXMXFWUBhPiFslYNGlWQA8vuQjbFz6MJgw8Rg+9BQ5F028eUw1IqFtSgD+ P3GxFLK0aPXI5IqGPToeYaVkaIGUsWYFkzaDMF6ve9DYvZhZ0w0Z08rVVGufGTJi6Kxi Q/KEbpwXr6Q7DMLLsgVoIUFZQTp22acp46VWfhx+POLGmNDcj5K2kuiLIOcqiTkOlhRo xAA2kwEheStzwnWMMu22fFMb2wHWWZ7om2ojLWVxEoRP0pt1oiS4kAgHveGljIX4yytP ANJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WJhPokso; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t22si14419902edy.116.2019.11.19.07.19.34; Tue, 19 Nov 2019 07:19:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WJhPokso; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727909AbfKSPS1 (ORCPT + 99 others); Tue, 19 Nov 2019 10:18:27 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:55615 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727509AbfKSPS0 (ORCPT ); Tue, 19 Nov 2019 10:18:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574176705; 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; bh=W44n0jnAWgfO1rcmYb1hXUHI1Cvs6LKx+Od1R8CiNaI=; b=WJhPoksoZr/4euaFUBfGc/1pQIxgjkeeEwiM2HBLdQmfVxVR4hMNPyKT/TlZPeMwJM7cT/ wc0THZPqIKxX/u5sx8TpMbyZxvuIOk7viP2pY+SCBIMG9PrpsFr7ZAM86GdjWs18Q0eoQ3 VGwD1ZkdlLcqtueUienq83kJnRFIp4A= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-220-gj-aswoLMX2E5TPcRjr9sg-1; Tue, 19 Nov 2019 10:18:24 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5F51C802520; Tue, 19 Nov 2019 15:18:22 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-117-49.ams2.redhat.com [10.36.117.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id C9F201001925; Tue, 19 Nov 2019 15:18:19 +0000 (UTC) From: Hans de Goede To: Maarten Lankhorst , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , "Rafael J . Wysocki" , Len Brown , Lee Jones Cc: Hans de Goede , Andy Shevchenko , linux-acpi@vger.kernel.org, intel-gfx , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/3] drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT Date: Tue, 19 Nov 2019 16:18:15 +0100 Message-Id: <20191119151818.67531-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: gj-aswoLMX2E5TPcRjr9sg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi All, This series needs to be merged through a single tree, to keep things bisectable. I have even considered just squashing all 3 patches into 1, but having separate commits seems better, but that does lead to an intermediate state where the backlight sysfs interface will be broken (and fixed 2 commits later). See below for some background info. The changes to drivers/acpi/acpi_lpss.c and drivers/mfd/intel_soc_pmic_core= .c are quite small and should not lead to any conflicts, so I believe that it would be best to merge this entire series through the drm-intel tree. Lee, may I have your Acked-by for merging the mfd change through the drm-intel tree? Rafael, may I have your Acked-by for merging the acpi_lpss change through t= he drm-intel tree? Regards, Hans p.s. The promised background info: We have this long standing issue where instead of looking in the i915 VBT (Video BIOS Table) to see if we should use the PWM block of the SoC or of the PMIC to control the backlight of a DSI panel, we rely on drivers/acpi/acpi_lpss.c and/or drivers/mfd/intel_soc_pmic_core.c registering a pwm with the generic name of "pwm_backlight" and then the i915 panel code does a pwm_get(dev, "pwm_backlight"). We have some heuristics in drivers/acpi/acpi_lpss.c to not register the lookup if a Crystal Cove PMIC is presend and the mfd/intel_soc_pmic_core.c code simply assumes that since there is a PMIC the PMIC PWM block will be used. Basically we are winging it. Recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. This series renams the PWM lookups registered by the LPSS / intel_soc_pmic_core.c code from "pwm_backlight" to "pwm_soc_backlight" resp= . "pwm_pmic_backlight" and in the LPSS case also dropping the heuristics when to register the lookup. This combined with teaching the i915 panel to call pwm_get for the right lookup-name depending on the VBT bits resolves this.