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 1858BC433EF for ; Fri, 26 Nov 2021 11:48:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376775AbhKZLvT (ORCPT ); Fri, 26 Nov 2021 06:51:19 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:48994 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347866AbhKZLtQ (ORCPT ); Fri, 26 Nov 2021 06:49:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637927163; 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=c1ya2zAC+GLUoT5O0PKB3gUVIZyk51duRXmMGKOgUc4=; b=UWEUWbfolEyBTP5kP/4FHgZktfqhwzZUH3emD8oALL2xAH7OHW8MHxUmrYS9xMk/P1meK8 /6NxtyJrVRuimFJjq4hC9f5fWZuJS/RWjv7cIeNAnjXuhrd30l1J9CBIf9mtPfO8iRSY8K hLVkio6dUvFFouvqqfMZR03CleIWCv0= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-299-OSiIHmAkPX2yJrwsLduRQw-1; Fri, 26 Nov 2021 06:46:02 -0500 X-MC-Unique: OSiIHmAkPX2yJrwsLduRQw-1 Received: by mail-ed1-f71.google.com with SMTP id p4-20020aa7d304000000b003e7ef120a37so7806522edq.16 for ; Fri, 26 Nov 2021 03:46:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=c1ya2zAC+GLUoT5O0PKB3gUVIZyk51duRXmMGKOgUc4=; b=CHYkY6xyC3ecIq7yymTtxwmJDfwDV4OIw6LgG8DimAU+WqU51LWw5HydjZgW00e/MC mEs854ZnaPc2VQbHZR3Goh+D3odX0HY7rbulyG/lskF8fGUCNDRX+6oX6jt5QxDFfrCc sRaQuyjnnNsym9SRbCU6EiDb66IrlBMPI7XW1esBzTJHvxm+IBcHGxCLSd1YNtgFJ4Qr TBhocCjnKIo/BF9phIf4j7JRi02+8oVj2VZxLFIRgGvxAAP+9KnvdrakJITuMDkHu5ni qjGqGdoAm27rjkGQyutVx7Nr746jMKxlmLovvPBYVTPk/EeHL6uqo7ola5RHd7rwUW3U UHKg== X-Gm-Message-State: AOAM531YBSWX5WNdSNf8yJs+SZlEiLI03ZGRGLDjhwp3UV+06nO84icc RMIp02fV21PRLZwAcOn2H4Mfw35sis3hd5+YbeLg004xPPePx3DCST5cvtbbWDpRJiU+a+v7ACV +hLOxPhAw2et2GCpAx2kmTEra X-Received: by 2002:a17:906:8c3:: with SMTP id o3mr38686186eje.10.1637927161126; Fri, 26 Nov 2021 03:46:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQ7am4Ala1kqDx7YmdB+rbbqSZypeAXzclZOGZ1kAkUizNdbpr5ikUpVseAcA4iSm5SH/CwA== X-Received: by 2002:a17:906:8c3:: with SMTP id o3mr38686160eje.10.1637927160921; Fri, 26 Nov 2021 03:46:00 -0800 (PST) Received: from ?IPV6:2001:1c00:c1e:bf00:1054:9d19:e0f0:8214? (2001-1c00-0c1e-bf00-1054-9d19-e0f0-8214.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:1054:9d19:e0f0:8214]) by smtp.gmail.com with ESMTPSA id f7sm3747090edl.33.2021.11.26.03.46.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Nov 2021 03:46:00 -0800 (PST) Message-ID: <2fd5400e-e587-54d2-1071-ad8df49a8a68@redhat.com> Date: Fri, 26 Nov 2021 12:45:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH v6 07/15] platform/x86: int3472: Enable I2c daisy chain Content-Language: en-US To: Daniel Scally , Laurent Pinchart Cc: "Rafael J . Wysocki" , Mark Gross , Andy Shevchenko , Wolfram Sang , Mika Westerberg , Mauro Carvalho Chehab , Liam Girdwood , Mark Brown , Michael Turquette , Stephen Boyd , Len Brown , linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, Sakari Ailus , Kate Hsuan , linux-media@vger.kernel.org, linux-clk@vger.kernel.org, Andy Shevchenko References: <20211125165412.535063-1-hdegoede@redhat.com> <20211125165412.535063-8-hdegoede@redhat.com> <03306e12-40ec-39ab-3b40-42b0395e1b65@redhat.com> <4ab5efa7-65b0-009c-293a-d7a49776e78d@gmail.com> From: Hans de Goede In-Reply-To: <4ab5efa7-65b0-009c-293a-d7a49776e78d@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11/26/21 12:39, Daniel Scally wrote: > Hello > > On 26/11/2021 11:30, Hans de Goede wrote: >> Hi, >> >> On 11/26/21 00:39, Laurent Pinchart wrote: >>> Hi Hans, >>> >>> Thank you for the patch. >>> >>> On Thu, Nov 25, 2021 at 05:54:04PM +0100, Hans de Goede wrote: >>>> From: Daniel Scally >>>> >>>> The TPS68470 PMIC has an I2C passthrough mode through which I2C traffic >>>> can be forwarded to a device connected to the PMIC as though it were >>>> connected directly to the system bus. Enable this mode when the chip >>>> is initialised. >>> Is there any drawback doing this unconditionally, if nothing is >>> connected to the bus on the other side (including no pull-ups) ? >> I actually never took a really close look at this patch, I just >> sorta inherited it from Daniel. >> >> Now that I have taken a close look, I see that it is setting the >> exact same bits as which get set when enabling the VSIO regulator. >> >> The idea here is that the I2C-passthrough only gets enabled when >> the VSIO regulator is turned on, because some sensors end up >> shorting the I2C pins to ground when the sensor is not powered. >> >> Since we set these bits when powering up the VSIO regulator >> and since we do that before trying to talk to the sensor >> I don't think that we need this (hack) anymore. >> >> I will give things a try without this change and if things >> still work I will drop this patch from the set. >> >> Daniel, what do you think? > > > Humm, we're only using the VSIO regulator with the VCM though right? Nope, there is a mapping from VSIO to dovdd for the ov8865 in the board_data; and I'm pretty sure I copied that from your earlier attempts at getting regulator lookups registered :) And even if the VSIO regulator was only used by the VCM, then it would get turned off after probing the VCM, clearing the 2 bits which this commit sets. Which would break things if we did not re-enable it when the ov8865 needs it. > Which might not be on when the ov8865 tries to probe. I haven't tried > without this patch to be honest; I set it because that was what Windows > does when powering on the PMIC. See above, I'm pretty sure we can do without this patch which means that the INT3472 code will no longer be poking at the PMIC directly itself, which is good :) Anyways I'll give this a try sometime next week and then drop the patch. Regards, Hans >>>> Reviewed-by: Andy Shevchenko >>>> Signed-off-by: Daniel Scally >>>> --- >>>> .../x86/intel/int3472/intel_skl_int3472_tps68470.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c b/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c >>>> index c05b4cf502fe..42e688f4cad4 100644 >>>> --- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c >>>> +++ b/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c >>>> @@ -45,6 +45,13 @@ static int tps68470_chip_init(struct device *dev, struct regmap *regmap) >>>> return ret; >>>> } >>>> >>>> + /* Enable I2C daisy chain */ >>>> + ret = regmap_write(regmap, TPS68470_REG_S_I2C_CTL, 0x03); >>>> + if (ret) { >>>> + dev_err(dev, "Failed to enable i2c daisy chain\n"); >>>> + return ret; >>>> + } >>>> + >>>> dev_info(dev, "TPS68470 REVID: 0x%02x\n", version); >>>> >>>> return 0; >