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 4089DEB64DD for ; Mon, 14 Aug 2023 19:33:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231258AbjHNTd1 (ORCPT ); Mon, 14 Aug 2023 15:33:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232165AbjHNTdA (ORCPT ); Mon, 14 Aug 2023 15:33:00 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14BC7BB for ; Mon, 14 Aug 2023 12:32:59 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5254f9eda36so2756245a12.1 for ; Mon, 14 Aug 2023 12:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692041577; x=1692646377; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+PPyRkE8QNcnw8n4URXIBMydlUyue4gEnUO37VgDlOA=; b=uZ42I4tK6dm+P+AF/H5MI2p0bu0VHhQ7yPZs/u6FYyCso2ccRZgNK6eZBMNd3rmvFo sLXx4suRvyn6HQYLfroPz4RL43N7kgktorfctw5SfYFMrhK3qCBbcWgm0rh1R0eSDX6s kZ6dHLa3Hes0qOybeWm0EAXeb+7QMheSjTumDW4XQJPTpXMINE5Lv0ogrgL7ssFYqUbY 90BM7ESD8Y3MuQBzRaiUrDFp4xKx44Coo4evx2Y9K8KK614ipaXzIkPxvQQvKL1HY/kt /N1bdIYgFb5wyqnMDqdCf44YbHhHkHUGlT48j5CZlGww6W2fDaceH9UP8GCDz46y01ci RXhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692041577; x=1692646377; 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=+PPyRkE8QNcnw8n4URXIBMydlUyue4gEnUO37VgDlOA=; b=PLowD1zDLI6nrfYca9ndpfhglcJa7asipn4MqD/MeRqZGSdRkai9cumh+ydVD9XHWw ZrAcXOFWAC8hSdwDuducIJVPW1Tu2IiMKQTSCxQAO7aR1rKeF5PRUPc2WHjGFpJpbCxC mTiD73xll3yKp9aXtTrHT2/W7xeQs9/1Njo2JyqaaHVWF1SkQ07JnPlSX7/K12qa+Tyd Yi4OQPhJAizDqkICdUbbFXlvL5IGh2vXFslX5/y/QT3AXpuw6+AVmI9rYq4s7zem50ti qoIjK8El07+rYE8U3wDo0uO8NWsMhXDPnp9MYPab418gBT24hhLf8H3oA0jMxrmvpFTY 9SEQ== X-Gm-Message-State: AOJu0YzK770eT9dzHb1AzMTsvfEG+g3lxcVlBby+7lmJlKg71teMU1yJ k2p7o9mjrjSuAWs84QHhksWnfegyV8xXm+VG7f0= X-Google-Smtp-Source: AGHT+IHCJObag9Dyk19qMlfSCfz6Iy2moD47tbSnD7NtULAtaT+peJh+ZdxunQCt9JIIgTgjSOmhoQ== X-Received: by 2002:aa7:d8d8:0:b0:525:46b7:40f2 with SMTP id k24-20020aa7d8d8000000b0052546b740f2mr5057909eds.21.1692041577535; Mon, 14 Aug 2023 12:32:57 -0700 (PDT) Received: from [192.168.1.20] ([178.197.214.188]) by smtp.gmail.com with ESMTPSA id a25-20020aa7cf19000000b0051e1660a34esm5930702edy.51.2023.08.14.12.32.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Aug 2023 12:32:57 -0700 (PDT) Message-ID: Date: Mon, 14 Aug 2023 21:32:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH v3 1/3] dt-bindings: hwmon: Add Infineon TDA38640 Content-Language: en-US To: Naresh Solanki , Conor Dooley Cc: Guenter Roeck , Jean Delvare , krzysztof.kozlowski+dt@linaro.org, Rob Herring , Conor Dooley , linux-hwmon@vger.kernel.org, Patrick Rudolph , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230802193155.2170935-1-Naresh.Solanki@9elements.com> <20230808-stand-cheddar-b76b0b7509a0@spud> <20230808-esquire-epidemic-f9bd74ffde25@spud> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 11/08/2023 18:00, Naresh Solanki wrote: > Hi, > > On Tue, 8 Aug 2023 at 19:58, Conor Dooley wrote: >> >> On Tue, Aug 08, 2023 at 07:10:08AM -0700, Guenter Roeck wrote: >>> On 8/8/23 04:46, Conor Dooley wrote: >>>> On Wed, Aug 02, 2023 at 09:31:51PM +0200, Naresh Solanki wrote: >>>>> From: Patrick Rudolph >>>>> >>>>> The TDA38640 chip has different output control mechanisms depending on >>>>> its mode of operation. When the chip is in SVID mode, only >>>>> hardware-based output control is supported via ENABLE pin. However, when >>>>> it operates in PMBus mode, software control works perfectly. >>>>> >>>>> To enable software control as a workaround in SVID mode, add the DT >>>>> property 'infineon,en-svid-control'. This property will enable the >>>>> workaround, which utilizes ENABLE pin polarity flipping for output when >>>>> the chip is in SVID mode. >>>> >>>> Why do you need a custom property for this? How come it is not possible >>>> to determine what bus you are on? >>>> >>> >>> That is not the point. Yes, it can be detected if the control method is >>> PMBus or SVID. However, in SVID mode, SVID is supposed to control the >>> output, not PMBUs. This is bypassed by controlling the polarity of the >>> (physical) output enable signal. We do _not_ want this enabled automatically >>> in SVID mode. Its side effects on random boards using this chip are unknown. >>> Thus, this needs a property which specifically enables this functionality >>> for users who _really_ need to use it and (hopefully) know what they are >>> doing. >> >> Hmm, reading this it makes a lot more sense why this is a property - I >> guess I just struggled to understand the commit message here, >> particularly what the benefit of using the workaround is. I'm still >> having difficulty parsing the commit & property text though - its >> unclear to me when you would need to use it - so I will stay out >> of the way & let Rob or Krzysztof handle things. > > To provide context, my system employs a unique power sequence > strategy utilizing a BMC (Baseboard Management Controller), > rendering the reliance on the ENABLE pin unnecessary. > In this configuration, the ENABLE pin is grounded in the hardware. > While most regulators facilitate PMBus Operation for output control, > the TDA38640 chip, when in SVID mode, is constrained by the > ENABLE pin to align with Intel specifications. > My communication with Infineon confirmed that the recommended > approach is to invert the Enable Pin for my use case. > > Since this is not typically the use case for most setup & hence DT property > is must for enabling the special case. > > For further insight into my setup's power sequence strategy, you can > refer to the following link: https://github.com/9elements/pwrseqd > This justifies to me the property, but still you described desired driver behavior, not the hardware characteristic. Don't describe what you want to control, but describe the entire system. Best regards, Krzysztof