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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2960FEB64DA for ; Wed, 19 Jul 2023 05:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=E9DAc5aVK0J2aHrRndtCTQv03hlpOyYPvzqdkGk7U0Q=; b=L4t79UmNypwHCK/q+bKqHh2b9E coKroS1+0U0H1zgHdmG2jnxxKdUoFRDkqnjOhB5CnlJkZzSUANwt1jx1HnJUcC4+N9TFUCSi4Jznv rXpIDb0uJ+zjw+iZ5YO6Q+rp+VowAPMmoVWKh70djM0qhEyMQh8xf7lwYZ9dpxT9uw5QutaGU1WLS RkCmtPnPDZ1cl6GzP2Fcv+7xPKZvPWN6/o6/TxeHGBcdKNiBTpVki9p70K0/afk3uGTzkEMlaaBWp GUCNW5iCm+fRSU3V4PgTDTGZLLjeNfvHkOAADNNd4jkyI3w6rBI9Bq50H4/4kfIc1QZF16gZ7eu20 0NFSmqVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qLzVn-005BlL-0N; Wed, 19 Jul 2023 05:14:07 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qLzVl-005Bkg-39 for linux-arm-kernel@bombadil.infradead.org; Wed, 19 Jul 2023 05:14:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=jnpKtK98eWniw+QQGcMqsflbYqKRBaBydeIwxyFDILE=; b=iZ4AgKn6znu5fIExeMASbfGDVN SPJ6GvNhg52Yi5kEKUVpCOz+1XpRok4sU0kHQaJwQW3YrO+ug9BQj3F6Lvsrh87/EjVrBhk2NwT44 BjWBofc7Nm5rY4Ajor9m2xIpALg02ct4XNq/t7afkdH4wMiJ0WxF+XcZTVLjUtc6/org5TrofrIp8 72G9F3uh/Y4lLlnRMtFg8155S3OwmBpMltaAqrYekfuqoFXByji/bHy4nC+rW1i+TpsgdpKw8+mm+ v25Hdux/Kvd/fVQtOVzw9ebGM1E9smEpgxV5R2kpez+/bHwGTP7quFv09hFdSouLEgw53QBLkaF4Z mAOju5/A==; Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by desiato.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qLewD-00BFmK-18 for linux-arm-kernel@lists.infradead.org; Tue, 18 Jul 2023 07:16:03 +0000 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-991da766865so742987166b.0 for ; Tue, 18 Jul 2023 00:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689664498; x=1692256498; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=jnpKtK98eWniw+QQGcMqsflbYqKRBaBydeIwxyFDILE=; b=m4pH/zT+DKmOFoZoscmxaV7Kdwy0B56Own15J7zC2TckUE3LwuJfmdhuJPnIslZbNk 7t9u4a0+d+6hrlL50FGYrB+0YveI0/c2V7NfwXI8KBlPcNdsDoZ+NqMaGH9hg6dtgGQ/ axztbKrCGM+exVVaE+gbeoNJArl4lLiFX61Zl+WknPL3hZg5itfKhBNH1i2PEP7Ziyrw zzrxg9drOottfyMomEOuStRyatZNhJzRC4lnHnGSV/qmSJON9eui2FUOhFjWtOVSqL8S Z+YuCVFt40nFwknNjlz134SJc/4UXWJe8R+fZk8uSvZ0rUUslPdhEnWIsOUp8ORGLTGd gPsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689664498; x=1692256498; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jnpKtK98eWniw+QQGcMqsflbYqKRBaBydeIwxyFDILE=; b=CzHX/bjC0vzIZNvcZZPFogDNjHFWONe5/C7w1gW+OeKXLOY4XzYX8VshGVS7ntW/hI L2+bvfMSoq7jHtMIJWux1pHi8/2X3FGrTiF5sua6T21/NFbqxS6EuSa+N3YT6wKky+wW rZUB4kdhoGUmvFAS5tfDB0qsM4/2rjGz1ei0fG8CQMSOjG3sueJe742Zk7mhLzaz1C9+ IjiVNq0KQAWeD8LClCUh+uenAxN2OSf0QmIghWaLdw99b6MFYc+Wbo+GCdj30L5egQfE IW+4Amzw8G6ylgR/t28MdCr0P7FaXRoB4rJmreTsqJssHlPQIvrOsejTllzoESFyoHj1 SdIg== X-Gm-Message-State: ABy/qLYW4h7WADSTN/GOC3uBulhQoHLjfOHogFLYIKjSy0X4ILNEOPDT 8+B6LqaOfdCSeHAJGTgmcwk= X-Google-Smtp-Source: APBJJlEFdG8t3DQ8rUQtaucSoGPQ0mmVmKRdvJBEzO82biA1GmtF1Tw0+jTZYmZ3o1WzDT+DMDILmA== X-Received: by 2002:a17:906:150:b0:979:dad9:4e9 with SMTP id 16-20020a170906015000b00979dad904e9mr13385553ejh.50.1689664497376; Tue, 18 Jul 2023 00:14:57 -0700 (PDT) Received: from orome (p200300e41f4b7100f22f74fffe1f3a53.dip0.t-ipconnect.de. [2003:e4:1f4b:7100:f22f:74ff:fe1f:3a53]) by smtp.gmail.com with ESMTPSA id p20-20020a170906141400b00992b2c55c67sm618032ejc.156.2023.07.18.00.14.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jul 2023 00:14:57 -0700 (PDT) Date: Tue, 18 Jul 2023 09:14:55 +0200 From: Thierry Reding To: Guenter Roeck Cc: =?utf-8?B?6JSh5om/6YGU?= , Krzysztof Kozlowski , "jdelvare@suse.com" , "robh+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "joel@jms.id.au" , "andrew@aj.id.au" , "u.kleine-koenig@pengutronix.de" , "corbet@lwn.net" , "p.zabel@pengutronix.de" , "linux-hwmon@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-doc@vger.kernel.org" , "patrick@stwcx.xyz" , Billy Tsai Subject: Re: [v6 2/4] dt-bindings: hwmon: Add ASPEED TACH Control documentation Message-ID: References: <7b198d57-ddec-3074-314a-3e5e5b8f48f9@roeck-us.net> <7a69bda1-5f4c-5b1f-8eb6-6fd58917a9b1@roeck-us.net> <3756dffd-1407-d656-485a-9cf1eefd9ae1@linaro.org> <709d738c-3bf3-d808-4172-468d7ad947d7@roeck-us.net> MIME-Version: 1.0 In-Reply-To: <709d738c-3bf3-d808-4172-468d7ad947d7@roeck-us.net> User-Agent: Mutt/2.2.10 (2023-03-25) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230718_081601_854681_C03459F0 X-CRM114-Status: GOOD ( 64.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7214988906143343517==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7214988906143343517== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qrzPy44n6zH1YQcM" Content-Disposition: inline --qrzPy44n6zH1YQcM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2023 at 11:54:26PM -0700, Guenter Roeck wrote: > On 7/17/23 23:39, Thierry Reding wrote: > > On Tue, Jul 18, 2023 at 08:04:24AM +0200, Krzysztof Kozlowski wrote: > > > On 18/07/2023 06:01, =E8=94=A1=E6=89=BF=E9=81=94 wrote: > > > > >=20 > > > > > On 17/07/2023 11:01, =E8=94=A1=E6=89=BF=E9=81=94 wrote: > > > > > > Guenter Roeck =E6=96=BC 2023=E5=B9=B47=E6= =9C=8817=E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8A=E5=8D=881:00=E5=AF=AB=E9=81= =93=EF=BC=9A > > > > > > >=20 > > > > > > > On 7/16/23 09:08, Krzysztof Kozlowski wrote: > > > > > > >=20 > > > > > > > [ ... ] > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > This patch serial doesn't use to binding the fan control = h/w. It is > > > > > > > > > used to binding the two independent h/w blocks. > > > > > > > > > One is used to provide pwm output and another is used to = monitor the > > > > > > > > > speed of the input. > > > > > > > > > My patch is used to point out that the pwm and the tach i= s the > > > > > > > > > different function and don't need to > > > > > > > > > bind together. You can not only combine them as the fan u= sage but also > > > > > > > > > treat them as the individual module for > > > > > > > > > use. For example: the pwm can use to be the beeper (pwm-b= eeper.c), the > > > > > > > > > tach can be used to monitor the heart beat signal. > > > > > > > >=20 > > > > > > > > Isn't this exactly the same as in every other SoC? PWMs can= be used in > > > > > > > > different ways? > > > > > > > >=20 > > > > > > >=20 > > > > > > > ... and in every fan controller. Not that it really makes sen= se because > > > > > > > normally the pwm controller part of such chips is tied to the= fan input, > > > > > > > to enable automatic fan control, but it is technically possib= le. > > > > > > > In many cases this is also the case in SoCs, for example, in = ast2500. > > > > > > > Apparently this was redesigned in ast2600 where they two bloc= ks are > > > > > > > only lightly coupled (there are two pwm status bits in the fa= n status > > > > > > > register, but I have no idea what those mean). If the blocks = are tightly > > > > > > > coupled, separate drivers don't really make sense. > > > > > > >=20 > > > > > > > There are multiple ways to separate the pwm controller part f= rom the > > > > > > > fan inputs if that is really necessary. One would be to provi= de a > > > > > > > sequence of address mappings, the other would be to pass the = memory > > > > > > > region from an mfd driver. It is not necessary to have N inst= ances > > > > > > > of the fan controller, even if the address space is not conti= nuous. > > > > > > >=20 > > > > > >=20 > > > > > > Hi Guenter, > > > > > >=20 > > > > > > May I ask about the meaning of the sequence of address mappings= ? It appears > > > > > > to consist of multiple tuples within the 'reg' property, indica= ting > > > > > > the usage of PWM/Tach > > > > > > registers within a single instance. After that I can use the dt= s like following: > > > > > >=20 > > > > > > pwm: pwm@1e610000 { > > > > > > ... > > > > > > reg =3D <0x1e610000 0x8 > > > > > > 0x1e610010 0x8 > > > > > > 0x1e610020 0x8 > > > > > > 0x1e610030 0x8 > > > > > > 0x1e610040 0x8 > > > > > > 0x1e610050 0x8 > > > > > > 0x1e610060 0x8 > > > > > > 0x1e610070 0x8 > > > > > > 0x1e610080 0x8 > > > > > > 0x1e610090 0x8 > > > > > > 0x1e6100A0 0x8 > > > > > > 0x1e6100B0 0x8 > > > > > > 0x1e6100C0 0x8 > > > > > > 0x1e6100D0 0x8 > > > > > > 0x1e6100E0 0x8 > > > > > > 0x1e6100F0 0x8>; > > > > >=20 > > > > >=20 > > > > > Uh, no... I mean, why? We keep pointing out that this should not = be done > > > > > differently than any other SoC. Open any other SoC PWM controller= and > > > > > tell me why this is different? Why this cannot be one address spa= ce? > > > >=20 > > > > Hi Krzysztof, > > > >=20 > > > > This is because the register layout for PWM and Tach is not continu= ous. > > > > Each PWM/Tach instance has its own set of controller registers, and= they > > > > are independent of each other. > > >=20 > > > Register layout is not continuous in many other devices, so again - w= hy > > > this must be different? > > >=20 > > > >=20 > > > > For example: > > > > PWM0 uses registers 0x0 and 0x4, while Tach0 uses registers 0x8 and= 0xc. > > > > PWM1 uses registers 0x10 and 0x14, while Tach1 uses registers 0x18 = and 0x1c. > > > > ... > > > >=20 > > > > To separate the PWM controller part from the fan inputs, Guenter has > > > > provided two methods. > > > > The first method involves passing the memory region from an MFD > > > > driver, which was the > > >=20 > > > I have no clue how can you pass memory region > > > (Documentation/devicetree/bindings/reserved-memory/) from MFD and why > > > does it make sense here. > > >=20 > > > > initial method I intended to use. However, it seems that this method > > > > does not make sense to you. > > > >=20 > > > > Therefore, I would like to explore the second method suggested by > > > > Guenter, which involves providing > > > > a sequence of address mappings. > >=20 > > At the risk of saying what others have said: given that there's a single > > reset line and a single clock line controlling all of these channels and > > given what I recall of how address demuxers work in chips, everything > > indicates that this is a single hardware block/device. > >=20 > > So the way that this should be described in DT is: > >=20 > > pwm@1e610000 { > > reg =3D <0x1e610000 0x100>; > > clocks =3D ...; > > resets =3D ... > > }; > >=20 > > That'd be the most accurate representation of this hardware in DT. It is > > then up to the driver to expose this in any way you see fit. For Linux > > it may make sense to expose this as 16 PWM channels and 16 hardware > > monitoring devices. Other operating systems using the same DT may choose >=20 > It is single chip. It should be a single hardware monitoring device with > 16 channels. I don't even want to think about the mess we'd get if people > start modeling a single chip as N hardware monitoring devices, one for > each monitoring channel supported by that chip. It would be even more mes= sy > if the driver supporting those N devices would be marked for asynchronous > probe, which would result in random hwmon device assignments. Sorry, I badly worded it. What I meant to say was: one hardware monitoring device with 16 channels. > > to expose this differently, depending on their frameworks, etc. A simple > > operating system may not expose this as separate resources at all but > > instead directly program individual registers from this block. > >=20 > > I'd also like to add that I think trying to split this up into multiple > > drivers in Linux is a bit overkill. In my opinion, though I know not > > everyone shares this view, it's perfectly fine for one driver to expose > > multiple types of resources. There's plenty of use-cases across the > > kernel where tightly coupled devices like this have a single driver that > > registers with multiple subsystems. Going through MFD only because this > > particular hardware doesn't split registers nicely along Linux subsystem > > boundaries. > >=20 > > So FWIW, I'm fine carrying hwmon code in a PWM driver and I'm equally > > fine if PWM code ends up in a hwmon driver (or any other subsystem > > really) if that makes sense for a given hardware. > >=20 >=20 > I am fine either way as well, as long as we are talking about a single > hwmon device and not 16 of them. Excellent. Should make it pretty clear in which direction this should go. Thierry --qrzPy44n6zH1YQcM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmS2O+8ACgkQ3SOs138+ s6EYWw/9HhCW64NMvU75PTpx/u+bWywB+D2iZNRyQKlXNPl1hO5Hx16z+74eOLN3 QUqscREyVwjIi2XciYXmgj7uGZMhTC6WxAbXAYlwtFyyxzrd+jbWlb55DV52EJZT SGhnxKBQx3WaFyEwPn2BhUXiGA3YFLpzTJ33DC+ErkSEA+JKl6q2bn6QPshKHq1R 1NtTOmj5HmuViALp7H1XZnhbig5CkVSIkqSQ3DQmqW9AXHqjEYY4jm0DO6Q6IXGs Yu5ipEZU7wGGEnHntx/02luCyXL41yPdQee4S8d7Qq1M2qA3DrGmT54nByS7xoFb yy76xt4JJJJS97js3d/e9paggU0wCdM+S+0KJvKaN4XU8RVxhEjtvAoLBZ3i1dPs uD+MKXb/ZULQCwtpRWdlAgaORwbVomz8X3pjFDMGpy41qky70KjudQKVfhsgqXKg bIdoN3whD0L5zIhsVmoX10utrhI9a/VTkHza/f/CTVuapxCdEZC9crk0/OZfsBQY ZCGzHvFyeyTwXtNJuajTDl4QufBvlXoHaTeY2xi93jxCGjiq9MN5+FRQYnfU5fhe P3vKLCBiRvJEFR1IDYWCT0K+4DNzP9hjElVUvwxfbocBCOyO02EQuaqXM8cfOFZz Qb++3fMiMRwFR2s56NOIi0189sAxvUwUCVVpEeHDBgAqX2QawRM= =nqHD -----END PGP SIGNATURE----- --qrzPy44n6zH1YQcM-- --===============7214988906143343517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7214988906143343517==--