From: Alexandre Mergnat <amergnat@baylibre.com> To: Matti Vaittinen <mazziesaccount@gmail.com> Cc: Flora Fu <flora.fu@mediatek.com>, Matthias Brugger <matthias.bgg@gmail.com>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, Tianping Fang <tianping.fang@mediatek.com>, Fabien Parent <fabien.parent@linaro.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Liam Girdwood <lgirdwood@gmail.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Mark Brown <broonie@kernel.org>, Sean Wang <sean.wang@mediatek.com>, Chen Zhong <chen.zhong@mediatek.com>, Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>, Alessandro Zummo <a.zummo@towertech.it>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Rob Herring <robh@kernel.org>, Mattijs Korpershoek <mkorpershoek@baylibre.com>, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-leds@vger.kernel.org, Fabien Parent <fparent@baylibre.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, linux-rtc@vger.kernel.org, linux-input@vger.kernel.org Subject: Re: [PATCH v5 09/10] regulator: add mt6357 regulator Date: Tue, 22 Nov 2022 11:17:10 +0100 [thread overview] Message-ID: <CAFGrd9rcDyZxnL5W0PvGyYyq6s+=imqvxM05nOeAqL4trgCDXQ@mail.gmail.com> (raw) In-Reply-To: <d61d8c22-fce5-74d5-6d2b-0eda6f2ace9e@gmail.com> Le mer. 16 nov. 2022 à 15:17, Matti Vaittinen <mazziesaccount@gmail.com> a écrit : > > Hi Alexandre, All > > Please, treat my review more as initiation for discussion than 'hard > requirements' for this driver. I am in no point or no "confidence level" > to give you any requirements ;) Hi Matti, Understood, thanks for clarifying this. > > If I read this right, the device has separate register(s) for writing > and reading the voltage? I wonder if this is a completely unique setup? > > If this is not unique, then it might be worth adding another field for > 'vsel_get' register and a flag in regulator desc - and modify the > generic regmap helpers to handle this in common code if the special > register? Not sure if this HW design is common enough to warrant the > added confusion though. You and Mark may have more insight. > I didn't write this driver and when I handled it, I found this weird. In the datasheet, registers access are read and write. After some read/write tests in the registers, I understood that read vosel_reg always returns the wrong value. That's why the debug register is used to get the value. I'm not sure I understand your proposal, but it seems to add more custom stuff and modify generic regmap instead of using the generic regmap which already allows us to customize get and set functions properly. IMHO, modifying the generic regmap isn't a good solution because I think this HW design isn't common. > > + > > +static const struct linear_range buck_volt_range1[] = { > > + REGULATOR_LINEAR_RANGE(518750, 0, 0x7f, 6250), > > +}; > > + > > +static const struct linear_range buck_volt_range2[] = { > > + REGULATOR_LINEAR_RANGE(500000, 0, 0x7f, 6250), > > +}; > > + > > +static const struct linear_range buck_volt_range3[] = { > > + REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000), > > +}; > > + > > +static const struct linear_range buck_volt_range4[] = { > > + REGULATOR_LINEAR_RANGE(1200000, 0, 0x7f, 12500), > > +}; > > I am unsure if we should aim for dropping the REGULATOR_LINEAR_RANGE() > and using the LINEAR_RANGE(). If yes, then it might simplify things if > new drivers used LINEAR_RANGE() from the day 1. If we don't, then it > makes sense to keep consistently using REGULATOR_LINEAR_RANGE() for all > of the drivers. I am not sure which way is the right way. Good catch. LINEAR_RANGE() is defined in "linear_range.h" REGULATOR_LINEAR_RANGE() is defined in "regulator/driver.h" "linear_range.h" is included in "regulator/driver.h" Then, I would like to say that regulator drivers should use REGULATOR_LINEAR_RANGE(). But duplicating the definition is weird, this is probably something which needs to be fixed or clarified. Also, that means mt6357-regulator.c no longer needs "#include <linux/linear_range.h>". Then I will remove it. > > > +static int mt6357_regulator_probe(struct platform_device *pdev) > > +{ > > + struct mt6397_chip *mt6357 = dev_get_drvdata(pdev->dev.parent); > > I am unsure what data do you need from the parent. If it is just the > regmap / device-tree node / device, then it does not (in my opinion) > really warrant using parent's drvdata. One can often get away with the > dev_get_regmap(pdev->dev.parent, NULL). Ok thanks, I wasn't aware of that. I tried to apply this change but I've got a kernel panic at boot because "mt6357_get_buck_voltage_sel" needs to retrieve the regmap.
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Mergnat <amergnat@baylibre.com> To: Matti Vaittinen <mazziesaccount@gmail.com> Cc: Flora Fu <flora.fu@mediatek.com>, Matthias Brugger <matthias.bgg@gmail.com>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, Tianping Fang <tianping.fang@mediatek.com>, Fabien Parent <fabien.parent@linaro.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Liam Girdwood <lgirdwood@gmail.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Mark Brown <broonie@kernel.org>, Sean Wang <sean.wang@mediatek.com>, Chen Zhong <chen.zhong@mediatek.com>, Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>, Alessandro Zummo <a.zummo@towertech.it>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Rob Herring <robh@kernel.org>, Mattijs Korpershoek <mkorpershoek@baylibre.com>, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-leds@vger.kernel.org, Fabien Parent <fparent@baylibre.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, linux-rtc@vger.kernel.org, linux-input@vger.kernel.org Subject: Re: [PATCH v5 09/10] regulator: add mt6357 regulator Date: Tue, 22 Nov 2022 11:17:10 +0100 [thread overview] Message-ID: <CAFGrd9rcDyZxnL5W0PvGyYyq6s+=imqvxM05nOeAqL4trgCDXQ@mail.gmail.com> (raw) In-Reply-To: <d61d8c22-fce5-74d5-6d2b-0eda6f2ace9e@gmail.com> Le mer. 16 nov. 2022 à 15:17, Matti Vaittinen <mazziesaccount@gmail.com> a écrit : > > Hi Alexandre, All > > Please, treat my review more as initiation for discussion than 'hard > requirements' for this driver. I am in no point or no "confidence level" > to give you any requirements ;) Hi Matti, Understood, thanks for clarifying this. > > If I read this right, the device has separate register(s) for writing > and reading the voltage? I wonder if this is a completely unique setup? > > If this is not unique, then it might be worth adding another field for > 'vsel_get' register and a flag in regulator desc - and modify the > generic regmap helpers to handle this in common code if the special > register? Not sure if this HW design is common enough to warrant the > added confusion though. You and Mark may have more insight. > I didn't write this driver and when I handled it, I found this weird. In the datasheet, registers access are read and write. After some read/write tests in the registers, I understood that read vosel_reg always returns the wrong value. That's why the debug register is used to get the value. I'm not sure I understand your proposal, but it seems to add more custom stuff and modify generic regmap instead of using the generic regmap which already allows us to customize get and set functions properly. IMHO, modifying the generic regmap isn't a good solution because I think this HW design isn't common. > > + > > +static const struct linear_range buck_volt_range1[] = { > > + REGULATOR_LINEAR_RANGE(518750, 0, 0x7f, 6250), > > +}; > > + > > +static const struct linear_range buck_volt_range2[] = { > > + REGULATOR_LINEAR_RANGE(500000, 0, 0x7f, 6250), > > +}; > > + > > +static const struct linear_range buck_volt_range3[] = { > > + REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000), > > +}; > > + > > +static const struct linear_range buck_volt_range4[] = { > > + REGULATOR_LINEAR_RANGE(1200000, 0, 0x7f, 12500), > > +}; > > I am unsure if we should aim for dropping the REGULATOR_LINEAR_RANGE() > and using the LINEAR_RANGE(). If yes, then it might simplify things if > new drivers used LINEAR_RANGE() from the day 1. If we don't, then it > makes sense to keep consistently using REGULATOR_LINEAR_RANGE() for all > of the drivers. I am not sure which way is the right way. Good catch. LINEAR_RANGE() is defined in "linear_range.h" REGULATOR_LINEAR_RANGE() is defined in "regulator/driver.h" "linear_range.h" is included in "regulator/driver.h" Then, I would like to say that regulator drivers should use REGULATOR_LINEAR_RANGE(). But duplicating the definition is weird, this is probably something which needs to be fixed or clarified. Also, that means mt6357-regulator.c no longer needs "#include <linux/linear_range.h>". Then I will remove it. > > > +static int mt6357_regulator_probe(struct platform_device *pdev) > > +{ > > + struct mt6397_chip *mt6357 = dev_get_drvdata(pdev->dev.parent); > > I am unsure what data do you need from the parent. If it is just the > regmap / device-tree node / device, then it does not (in my opinion) > really warrant using parent's drvdata. One can often get away with the > dev_get_regmap(pdev->dev.parent, NULL). Ok thanks, I wasn't aware of that. I tried to apply this change but I've got a kernel panic at boot because "mt6357_get_buck_voltage_sel" needs to retrieve the regmap. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-11-22 10:18 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-16 12:32 [PATCH v5 00/10] Add MediaTek MT6357 PMIC support Alexandre Mergnat 2022-11-16 12:32 ` Alexandre Mergnat 2022-11-16 12:32 ` [PATCH v5 01/10] dt-bindings: input: mtk-pmic-keys: add binding for MT6357 PMIC Alexandre Mergnat 2022-11-16 12:32 ` Alexandre Mergnat 2022-11-16 12:32 ` [PATCH v5 02/10] dt-bindings: rtc: mediatek: convert MT6397 rtc documentation Alexandre Mergnat 2022-11-16 12:32 ` Alexandre Mergnat 2022-11-17 15:39 ` Rob Herring 2022-11-17 15:39 ` Rob Herring 2022-11-16 12:32 ` [PATCH v5 03/10] dt-bindings: rtc: mediatek: add MT6357 support Alexandre Mergnat 2022-11-16 12:32 ` Alexandre Mergnat 2022-11-20 16:44 ` Rob Herring 2022-11-20 16:44 ` Rob Herring 2022-11-16 12:32 ` [PATCH v5 04/10] regulator: dt-bindings: Add binding schema for mt6357 regulators Alexandre Mergnat 2022-11-16 12:32 ` Alexandre Mergnat 2022-11-16 12:32 ` [PATCH v5 05/10] dt-bindings: mfd: mediatek: Add bindings for MT6357 PMIC Alexandre Mergnat 2022-11-16 12:32 ` Alexandre Mergnat 2022-11-16 16:03 ` Rob Herring 2022-11-16 16:03 ` Rob Herring 2022-11-16 16:26 ` Alexandre Mergnat 2022-11-16 16:26 ` Alexandre Mergnat 2022-11-16 12:33 ` [PATCH v5 06/10] dt-bindings: soc: mediatek: convert pwrap documentation Alexandre Mergnat 2022-11-16 12:33 ` Alexandre Mergnat 2022-11-17 16:00 ` Rob Herring 2022-11-17 16:00 ` Rob Herring 2022-11-17 16:06 ` Matthias Brugger 2022-11-17 16:06 ` Matthias Brugger 2022-11-22 8:14 ` Alexandre Mergnat 2022-11-22 8:14 ` Alexandre Mergnat 2022-11-22 15:37 ` Alexandre Mergnat 2022-11-22 15:37 ` Alexandre Mergnat 2022-11-16 12:33 ` [PATCH v5 07/10] arm64: dts: mt6358: change node names Alexandre Mergnat 2022-11-16 12:33 ` Alexandre Mergnat 2022-11-17 16:02 ` Matthias Brugger 2022-11-17 16:02 ` Matthias Brugger 2022-11-16 12:33 ` [PATCH v5 08/10] arm64: dts: mt8173: change node name Alexandre Mergnat 2022-11-16 12:33 ` Alexandre Mergnat 2022-11-17 15:56 ` Matthias Brugger 2022-11-17 15:56 ` Matthias Brugger 2022-11-16 12:33 ` [PATCH v5 09/10] regulator: add mt6357 regulator Alexandre Mergnat 2022-11-16 12:33 ` Alexandre Mergnat 2022-11-16 14:17 ` Matti Vaittinen 2022-11-16 14:17 ` Matti Vaittinen 2022-11-22 10:17 ` Alexandre Mergnat [this message] 2022-11-22 10:17 ` Alexandre Mergnat 2022-11-16 12:33 ` [PATCH v5 10/10] Input: mtk-pmic-keys: add MT6357 support Alexandre Mergnat 2022-11-16 12:33 ` Alexandre Mergnat
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAFGrd9rcDyZxnL5W0PvGyYyq6s+=imqvxM05nOeAqL4trgCDXQ@mail.gmail.com' \ --to=amergnat@baylibre.com \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@bootlin.com \ --cc=angelogioacchino.delregno@collabora.com \ --cc=broonie@kernel.org \ --cc=chen.zhong@mediatek.com \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.torokhov@gmail.com \ --cc=fabien.parent@linaro.org \ --cc=flora.fu@mediatek.com \ --cc=fparent@baylibre.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=krzysztof.kozlowski@linaro.org \ --cc=lee@kernel.org \ --cc=lgirdwood@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-leds@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux-rtc@vger.kernel.org \ --cc=matthias.bgg@gmail.com \ --cc=mazziesaccount@gmail.com \ --cc=mkorpershoek@baylibre.com \ --cc=pavel@ucw.cz \ --cc=robh+dt@kernel.org \ --cc=robh@kernel.org \ --cc=sean.wang@mediatek.com \ --cc=tianping.fang@mediatek.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.