Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1370267pxb; Fri, 21 Jan 2022 16:46:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJzVRC0wHUqr18mwiKQYXPzjmRKf28AH38Lcb+i2y7igufd/v4XbY3Pm5Wi4SpC2BPJHuOqR X-Received: by 2002:a63:be49:: with SMTP id g9mr4550650pgo.375.1642812405660; Fri, 21 Jan 2022 16:46:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642812405; cv=none; d=google.com; s=arc-20160816; b=EfbLT/eC+yyzNCGRudRu/9Ckwy6Z/VHquUrYbKxwYuSHaZ2umuuGT7hzLQdLi5YOtE g/C/47zN8pk8eCm2fsFwHc0xzlmHl1z3rCXmwwQe1TxvmAZjX72/9n3Gebjlk7HlcB2x aXenxg8yg/pQr3f7zhur8GiJr68wUEpkphL67+F0Wr4Q6bRQFxtE4HN9n/82LDRMLE61 JgLxpNXkccN/bJ11rt7J1u0MTGews/Ul0VxqXtUmpJuJvY/S9fqgvU+c+U+OaZLUWcmB 2Xk8NMg2qkTXmCg1Ltkaa2/2vTOTzBR2wj7jAjR6NdqUG442ZxP3dEHMGwUfY3cxmMlR IheQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=KhlrB2SVGbtIKoVBNVPoy+9dR4p29EtqR1X9fQ4Ad8M=; b=NM218+n5eZKvJkxNgQf3zM7DiIgIn+P33CnK9P+DslsPVKNLiOpFn3jgMbDlobTzBH AugKLzUsTvhaxmuYaJOvR3WhwbVJ1zoxFvlRD3FbP5Fg8KSM2l6kX/Xhp5ohs/xvueh2 td0TzzdPRSd5H0X8BL6ID5QA0KSSTBc4c5+dOGR0dmPtgeQh+l4PRMXBTmUzwcljdgwp SBgYO6bf0jIJ3EjCQyN+91fzB7khuMvMEBqiaEMp/Inh8sCSk+gbmciCgaCecEcmizFe KBjOBS6jLwEQyzW2Q/G1NNO1ej3gfjfJIuzr46jva5hIAdNzchW4/zxn2wt0V7RDmIe4 r1ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=cq81Gfjb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z9si8491566pgr.712.2022.01.21.16.46.32; Fri, 21 Jan 2022 16:46:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=cq81Gfjb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379992AbiAUK1i (ORCPT + 99 others); Fri, 21 Jan 2022 05:27:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344593AbiAUK1g (ORCPT ); Fri, 21 Jan 2022 05:27:36 -0500 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C347C06173F for ; Fri, 21 Jan 2022 02:27:35 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id s61-20020a17090a69c300b001b4d0427ea2so13015245pjj.4 for ; Fri, 21 Jan 2022 02:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KhlrB2SVGbtIKoVBNVPoy+9dR4p29EtqR1X9fQ4Ad8M=; b=cq81Gfjb0rILYcu0ZNwDYDwgYbr4f/L5oKASBNnJPbsho/KZ8RE76KnQifYvytvN5W LSaOCPLE6chYKNnPiaoTZfg3cBjGijgPKSzB4SerKPypjbFOnE8w2G5djXUWmueG31Bw rdNf2j1rUgtQ4GBfjnc0ZyyXKhX5TpYKfYwbJ3QHcJoGz8/qx2IkavB45wJGIQkxlf5E HTZLfO8ktymEhaU/uV+dEoRpxYYczalL6rc1LaNoQyefFadKA6+HH6BVmDFdBYCXMO7C PE3LI80PBby1pA42dwXVxkFBKxmyMUiKLdwwUgKWk0WIrIfLMWl9VNU0I2TeXdDc95yv aIcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KhlrB2SVGbtIKoVBNVPoy+9dR4p29EtqR1X9fQ4Ad8M=; b=RGNuQMs9a4sOldy9J1kmBL8D8Ykm40Pqj/Gg9yww/+n47lT+CMj4dYu83tvTAImufR hLqzFZXkXwfJBTQOejo44IU1GOS3Hz3r2nyzXU9DJVUbaxKGcYO2OuPW6gTA0MRPDoy0 RXYRPGcR+kz6PDHSXDXke0Xf47SCKkMqMKGX39gSLWwrDdJS0eC+NwkKL4FkKJuXf3AR e4jSuHOlHz5BdM98DQCyNdX+BkZtlP0699tozaERcsGIjYyQzIvzS9jvYTkiyLYzBoRM NPkhFTyOYuYreDEBl4M3qlr6aPgJY0wtPcXwfpvERe4C4JXJ7e6Ip+g5ok5+D+llsMxa vOTw== X-Gm-Message-State: AOAM531zKCHJlkE2n3IOGg/oeQ4Cn4KyJABUUGwJWdIEMLxDAnpobURW F30hsptGM+oQkkmxuUUMwIWPEDfs/MUopqrXCw47rQ== X-Received: by 2002:a17:902:bb8e:b0:14a:496c:6f2b with SMTP id m14-20020a170902bb8e00b0014a496c6f2bmr3112204pls.57.1642760855372; Fri, 21 Jan 2022 02:27:35 -0800 (PST) MIME-Version: 1.0 References: <20220120001621.705352-1-jsd@semihalf.com> <2f7610dc-ab57-ddbf-277f-e84680da71bd@redhat.com> <7f165170-ed25-7804-b756-4944a4067b8a@redhat.com> In-Reply-To: <7f165170-ed25-7804-b756-4944a4067b8a@redhat.com> From: =?UTF-8?B?SmFuIETEhWJyb8Wb?= Date: Fri, 21 Jan 2022 11:27:24 +0100 Message-ID: Subject: Re: [PATCH 0/2] i2c-designware: Add support for AMD PSP semaphore To: Hans de Goede Cc: Linux Kernel Mailing List , linux-i2c , Jarkko Nikula , Andy Shevchenko , Mika Westerberg , Wolfram Sang , Raul E Rangel , Marcin Wojtas , Grzegorz Jaszczyk , upstream@semihalf.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org czw., 20 sty 2022 o 16:57 Hans de Goede napisa=C5=82(= a): > > Hi, > > On 1/20/22 13:29, Jan D=C4=85bro=C5=9B wrote: > > Hi Hans, > > > > > > czw., 20 sty 2022 o 12:15 Hans de Goede napisa=C5= =82(a): > >> > >> Hi Jan, > >> > >> On 1/20/22 01:16, Jan Dabros wrote: > >>> This patchset comprises support for new i2c-designware controller set= up on some > >>> AMD Cezanne SoCs, where x86 is sharing i2c bus with PSP. PSP uses the= same > >>> controller and acts as an i2c arbitrator there (x86 is leasing bus fr= om it). > >>> > >>> First commit aims to improve generic i2c-designware code by adding ex= tra locking > >>> on probe() and disable() paths. I would like to ask someone with acce= ss to > >>> boards which use Intel BayTrail(CONFIG_I2C_DESIGNWARE_BAYTRAIL) to ve= rify > >>> behavior of my changes on such setup. > >>> > >>> Second commit adds support for new PSP semaphore arbitration mechanis= m. > >>> Implementation is similar to the one from i2c-designware-baytrail.c h= owever > >>> there are two main differences: > >>> 1) Add new ACPI ID in order to protect against silent binding of the = old driver > >>> to the setup with PSP semaphore. Extra flag ARBITRATION_SEMAPHORE add= ed to this > >>> new _HID allows to recognize setup with PSP. > >>> 2) Beside acquire_lock() and release_lock() methods we are also apply= ing quirks > >>> to the lock_bus() and unlock_bus() global adapter methods. With this = in place > >>> all i2c clients drivers may lock i2c bus for a desired number of i2c > >>> transactions (e.g. write-wait-read) without being aware of that such = bus is > >>> shared with another entity. > >>> > >>> This patchset is a follow-up to the RFC sent earlier on LKML [1], wit= h review > >>> comments applied. > >>> > >>> Looking forward to some feedback. > >>> > >>> [1] https://lkml.org/lkml/2021/12/22/219 > >> > >> > >> Thank you for your patch series. > >> > >> As you may have seen I've done a lot of work on the Bay Trail semaphor= e > >> thing. I also own several Bay Trail and Cherry Trail based devices whi= ch > >> use this setup. > >> > >> I'll add your patches to my personal WIP tree which I regularly run > >> on these devices and I'll report back if I notice any issues. > > > > Thanks in advance, this will be really helpful! I don't have Bay > > Trail/Cherry Trail, so I've only tested that build of Bay Trail > > semaphore isn't broken. > > > > I would like to point to new locks in i2c_dw_disable() method as > > something to be the most fragile and error-prone, will be great if you > > can verify this thoroughly. This function is invoked on both > > dw_i2c_driver.remove() and dw_i2c_plat_suspend() paths. Considering > > that Bay Trail semaphore means that i2c bus is shared with PMIC, I'm > > not sure whether all corner cases are secured especially on platform > > suspend. > > You are right that the whole sharing of the bus to the PMIC between > the SoC's internal power-management microcontroller (P-Unit) and > the OS is a bit fragile (it really is a bit crazy design IMHO). > > You are also right that disabling the controller on suspend > is a problem, because once everything is suspended and we hit > deeper power-saving states then the P-Unit actually needs the > controller to tell the PMIC to disable certain regulators; and > the P-Unit is not prepared for us having turned the controller off, > therefor dw_i2c_plat_suspend() looks like this: > > static int dw_i2c_plat_suspend(struct device *dev) > { > struct dw_i2c_dev *i_dev =3D dev_get_drvdata(dev); > > i_dev->suspended =3D true; > > if (i_dev->shared_with_punit) > return 0; > > ... > > > Note the shared_with_punit flag, so on the Bay Trail case > i2c_dw_disable() never gets called on suspend, so that should > not be an issue. Thanks for pointing this! So actually the only path which is now (with my patch) altered on the Bay Trails is unbinding driver from the device which will call dw_i2c_driver.remove(). > > So all in all I don't really expect any problems, still thank > you for Cc-ing me. Thanks a lot for your help with testing and reviewing my code. > > Regards, > > Hans > > > > >> One remark, I notice that there are no AMD people in the Cc, it > >> would be good if you can find someone from AMD to look at this, > >> also see my remarks to the 2nd patch in my reply to that patch. > > > > This was partially discussed with AMD folks and you are right that I > > should include someone from AMD to take a look at this. Thanks for all > > your comments! > > > >> Regards, > >> > >> Hans > >> > >> > >> > >> > >>> > >>> Jan Dabros (2): > >>> i2c: designware: Add missing locks > >>> i2c: designware: Add AMD PSP I2C bus support > >>> > >>> MAINTAINERS | 1 + > >>> drivers/acpi/acpi_apd.c | 1 + > >>> drivers/i2c/busses/Kconfig | 10 + > >>> drivers/i2c/busses/Makefile | 1 + > >>> drivers/i2c/busses/i2c-designware-amdpsp.c | 357 +++++++++++++++++= ++ > >>> drivers/i2c/busses/i2c-designware-baytrail.c | 10 +- > >>> drivers/i2c/busses/i2c-designware-common.c | 12 + > >>> drivers/i2c/busses/i2c-designware-core.h | 18 +- > >>> drivers/i2c/busses/i2c-designware-master.c | 6 + > >>> drivers/i2c/busses/i2c-designware-platdrv.c | 61 ++++ > >>> 10 files changed, 469 insertions(+), 8 deletions(-) > >>> create mode 100644 drivers/i2c/busses/i2c-designware-amdpsp.c > >>> > >> > > >