This patchset aims to:
* Fix the incorrect bindings for the s4 type of pwm that was introduced
while converting the documentation from txt to yaml format.
* Introduce a new compatible for the existing PWMs to better describe the
HW in DT, instead of describing driver settings.
* Make the introduction of a new pwm variant (s4) slightly easier.
Changes since v4 [4]:
* Rebased on Uwe's pwm rework in pwm-next
* Drop change to carry device data in drvdata
* Make the length of parent name array fixed
* Single allocation instead 3 for the internal clock elements
* meson8-pwm-v2 and meson-pwm-s4 compatibles under an enum instead of
2 const
Changes since v3 [3]:
* Split first rework patch into 3 changes
* Use dev_warn_once() to notify use of obsolete bindings
* Rebased on Uwe dev_err_probe() change.
Changes since v2 [2]:
* Drop DTS changes. These will be re-submitted later on. Possibly after
u-boot gets support for the new compatible to minimise conversion
problems.
* Position deprecated property correctly in dt-bindings for the old
meson8 type pwm bindings
* Reword commit description of patch #2 to make more obvious it does not
introduce a new HW support but fixes a bad bindings.
* Dropped Rob's Reviewed-by on patch #2. It seemed appropriate considering
the discussion on this change.
Changes since v1 [1]:
* Fix typo in the new binding compatible documentation
* Disallow clock-names for the new compatibles in the schema documenation
[1]: https://lore.kernel.org/linux-amlogic/[email protected]
[2]: https://lore.kernel.org/linux-amlogic/[email protected]
[3]: https://lore.kernel.org/linux-amlogic/[email protected]
[4]: https://lore.kernel.org/linux-amlogic/[email protected]
Jerome Brunet (5):
dt-bindings: pwm: amlogic: fix s4 bindings
dt-bindings: pwm: amlogic: Add a new binding for meson8 pwm types
pwm: meson: generalize 4 inputs clock on meson8 pwm type
pwm: meson: don't carry internal clock elements around
pwm: meson: add generic compatible for meson8 to sm1
.../devicetree/bindings/pwm/pwm-amlogic.yaml | 115 ++++++-
drivers/pwm/pwm-meson.c | 289 ++++++++++--------
2 files changed, 260 insertions(+), 144 deletions(-)
--
2.43.0
Introduce a new compatible support in the Amlogic PWM driver.
The PWM HW is actually the same for all SoCs supported so far. A specific
compatible is needed only because the clock sources of the PWMs are
hard-coded in the driver.
It is better to have the clock source described in DT but this changes the
bindings so a new compatible must be introduced.
When all supported platform have migrated to the new compatible, support
for the legacy ones may be removed from the driver.
The addition of this new compatible makes the old ones obsolete, as
described in the DT documentation.
Adding a callback to setup the clock will also make it easier to add
support for the new PWM HW found in a1, s4, c3 and t7 SoC families.
Signed-off-by: Jerome Brunet <[email protected]>
---
drivers/pwm/pwm-meson.c | 195 +++++++++++++++++++++++++---------------
1 file changed, 121 insertions(+), 74 deletions(-)
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index fe61335d87d0..90fc7b349723 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -101,6 +101,7 @@ struct meson_pwm_channel {
struct meson_pwm_data {
const char *const parent_names[MESON_NUM_MUX_PARENTS];
+ int (*channels_init)(struct pwm_chip *chip);
};
struct meson_pwm {
@@ -341,86 +342,16 @@ static const struct pwm_ops meson_pwm_ops = {
.get_state = meson_pwm_get_state,
};
-static const struct meson_pwm_data pwm_meson8b_data = {
- .parent_names = { "xtal", NULL, "fclk_div4", "fclk_div3" },
-};
-
-/*
- * Only the 2 first inputs of the GXBB AO PWMs are valid
- * The last 2 are grounded
- */
-static const struct meson_pwm_data pwm_gxbb_ao_data = {
- .parent_names = { "xtal", "clk81", NULL, NULL },
-};
-
-static const struct meson_pwm_data pwm_axg_ee_data = {
- .parent_names = { "xtal", "fclk_div5", "fclk_div4", "fclk_div3" },
-};
-
-static const struct meson_pwm_data pwm_axg_ao_data = {
- .parent_names = { "xtal", "axg_ao_clk81", "fclk_div4", "fclk_div5" },
-};
-
-static const struct meson_pwm_data pwm_g12a_ao_ab_data = {
- .parent_names = { "xtal", "g12a_ao_clk81", "fclk_div4", "fclk_div5" },
-};
-
-static const struct meson_pwm_data pwm_g12a_ao_cd_data = {
- .parent_names = { "xtal", "g12a_ao_clk81", NULL, NULL },
-};
-
-static const struct of_device_id meson_pwm_matches[] = {
- {
- .compatible = "amlogic,meson8b-pwm",
- .data = &pwm_meson8b_data
- },
- {
- .compatible = "amlogic,meson-gxbb-pwm",
- .data = &pwm_meson8b_data
- },
- {
- .compatible = "amlogic,meson-gxbb-ao-pwm",
- .data = &pwm_gxbb_ao_data
- },
- {
- .compatible = "amlogic,meson-axg-ee-pwm",
- .data = &pwm_axg_ee_data
- },
- {
- .compatible = "amlogic,meson-axg-ao-pwm",
- .data = &pwm_axg_ao_data
- },
- {
- .compatible = "amlogic,meson-g12a-ee-pwm",
- .data = &pwm_meson8b_data
- },
- {
- .compatible = "amlogic,meson-g12a-ao-pwm-ab",
- .data = &pwm_g12a_ao_ab_data
- },
- {
- .compatible = "amlogic,meson-g12a-ao-pwm-cd",
- .data = &pwm_g12a_ao_cd_data
- },
- {},
-};
-MODULE_DEVICE_TABLE(of, meson_pwm_matches);
-
-static int meson_pwm_init_channels(struct pwm_chip *chip)
+static int meson_pwm_init_clocks_meson8b(struct pwm_chip *chip,
+ struct clk_parent_data *mux_parent_data)
{
struct meson_pwm *meson = to_meson_pwm(chip);
- struct clk_parent_data mux_parent_data[MESON_NUM_MUX_PARENTS] = {};
struct device *dev = pwmchip_parent(chip);
unsigned int i;
char name[255];
int err;
- for (i = 0; i < MESON_NUM_MUX_PARENTS; i++) {
- mux_parent_data[i].index = -1;
- mux_parent_data[i].name = meson->data->parent_names[i];
- }
-
- for (i = 0; i < chip->npwm; i++) {
+ for (i = 0; i < MESON_NUM_PWMS; i++) {
struct meson_pwm_channel *channel = &meson->channels[i];
struct clk_parent_data pdata = {};
struct meson8b_pwm_clocks *clks;
@@ -502,6 +433,122 @@ static int meson_pwm_init_channels(struct pwm_chip *chip)
return 0;
}
+static int meson_pwm_init_channels_meson8b_legacy(struct pwm_chip *chip)
+{
+ struct clk_parent_data mux_parent_data[MESON_NUM_MUX_PARENTS] = {};
+ struct meson_pwm *meson = to_meson_pwm(chip);
+ int i;
+
+ dev_warn_once(pwmchip_parent(chip),
+ "using obsolete compatible, please consider updating dt\n");
+
+ for (i = 0; i < MESON_NUM_MUX_PARENTS; i++) {
+ mux_parent_data[i].index = -1;
+ mux_parent_data[i].name = meson->data->parent_names[i];
+ }
+
+ return meson_pwm_init_clocks_meson8b(chip, mux_parent_data);
+}
+
+static int meson_pwm_init_channels_meson8b_v2(struct pwm_chip *chip)
+{
+ struct clk_parent_data mux_parent_data[MESON_NUM_MUX_PARENTS] = {};
+ int i;
+
+ /*
+ * NOTE: Instead of relying on the hard coded names in the driver
+ * as the legacy version, this relies on DT to provide the list of
+ * clocks.
+ * For once, using input numbers actually makes more sense than names.
+ * Also DT requires clock-names to be explicitly ordered, so there is
+ * no point bothering with clock names in this case.
+ */
+ for (i = 0; i < MESON_NUM_MUX_PARENTS; i++)
+ mux_parent_data[i].index = i;
+
+ return meson_pwm_init_clocks_meson8b(chip, mux_parent_data);
+}
+
+static const struct meson_pwm_data pwm_meson8b_data = {
+ .parent_names = { "xtal", NULL, "fclk_div4", "fclk_div3" },
+ .channels_init = meson_pwm_init_channels_meson8b_legacy,
+};
+
+/*
+ * Only the 2 first inputs of the GXBB AO PWMs are valid
+ * The last 2 are grounded
+ */
+static const struct meson_pwm_data pwm_gxbb_ao_data = {
+ .parent_names = { "xtal", "clk81", NULL, NULL },
+ .channels_init = meson_pwm_init_channels_meson8b_legacy,
+};
+
+static const struct meson_pwm_data pwm_axg_ee_data = {
+ .parent_names = { "xtal", "fclk_div5", "fclk_div4", "fclk_div3" },
+ .channels_init = meson_pwm_init_channels_meson8b_legacy,
+};
+
+static const struct meson_pwm_data pwm_axg_ao_data = {
+ .parent_names = { "xtal", "axg_ao_clk81", "fclk_div4", "fclk_div5" },
+ .channels_init = meson_pwm_init_channels_meson8b_legacy,
+};
+
+static const struct meson_pwm_data pwm_g12a_ao_ab_data = {
+ .parent_names = { "xtal", "g12a_ao_clk81", "fclk_div4", "fclk_div5" },
+ .channels_init = meson_pwm_init_channels_meson8b_legacy,
+};
+
+static const struct meson_pwm_data pwm_g12a_ao_cd_data = {
+ .parent_names = { "xtal", "g12a_ao_clk81", NULL, NULL },
+ .channels_init = meson_pwm_init_channels_meson8b_legacy,
+};
+
+static const struct meson_pwm_data pwm_meson8_v2_data = {
+ .channels_init = meson_pwm_init_channels_meson8b_v2,
+};
+
+static const struct of_device_id meson_pwm_matches[] = {
+ {
+ .compatible = "amlogic,meson8-pwm-v2",
+ .data = &pwm_meson8_v2_data
+ },
+ /* The following compatibles are obsolete */
+ {
+ .compatible = "amlogic,meson8b-pwm",
+ .data = &pwm_meson8b_data
+ },
+ {
+ .compatible = "amlogic,meson-gxbb-pwm",
+ .data = &pwm_meson8b_data
+ },
+ {
+ .compatible = "amlogic,meson-gxbb-ao-pwm",
+ .data = &pwm_gxbb_ao_data
+ },
+ {
+ .compatible = "amlogic,meson-axg-ee-pwm",
+ .data = &pwm_axg_ee_data
+ },
+ {
+ .compatible = "amlogic,meson-axg-ao-pwm",
+ .data = &pwm_axg_ao_data
+ },
+ {
+ .compatible = "amlogic,meson-g12a-ee-pwm",
+ .data = &pwm_meson8b_data
+ },
+ {
+ .compatible = "amlogic,meson-g12a-ao-pwm-ab",
+ .data = &pwm_g12a_ao_ab_data
+ },
+ {
+ .compatible = "amlogic,meson-g12a-ao-pwm-cd",
+ .data = &pwm_g12a_ao_cd_data
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, meson_pwm_matches);
+
static int meson_pwm_probe(struct platform_device *pdev)
{
struct pwm_chip *chip;
@@ -522,7 +569,7 @@ static int meson_pwm_probe(struct platform_device *pdev)
meson->data = of_device_get_match_data(&pdev->dev);
- err = meson_pwm_init_channels(chip);
+ err = meson->data->channels_init(chip);
if (err < 0)
return err;
--
2.43.0
Hello Jerome,
On Wed, Feb 21, 2024 at 04:11:46PM +0100, Jerome Brunet wrote:
> Jerome Brunet (5):
> dt-bindings: pwm: amlogic: fix s4 bindings
> dt-bindings: pwm: amlogic: Add a new binding for meson8 pwm types
> pwm: meson: generalize 4 inputs clock on meson8 pwm type
> pwm: meson: don't carry internal clock elements around
> pwm: meson: add generic compatible for meson8 to sm1
I applied patches #1 to #3. This doesn't mean #4 and #5 are bad, just
that I need some more time for review.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Sat 02 Mar 2024 at 11:04, Uwe Kleine-König <[email protected]> wrote:
> [[PGP Signed Part:Undecided]]
> Hello Jerome,
>
> On Wed, Feb 21, 2024 at 04:11:46PM +0100, Jerome Brunet wrote:
>> Jerome Brunet (5):
>> dt-bindings: pwm: amlogic: fix s4 bindings
>> dt-bindings: pwm: amlogic: Add a new binding for meson8 pwm types
>> pwm: meson: generalize 4 inputs clock on meson8 pwm type
>> pwm: meson: don't carry internal clock elements around
>> pwm: meson: add generic compatible for meson8 to sm1
>
> I applied patches #1 to #3. This doesn't mean #4 and #5 are bad, just
> that I need some more time for review.
No worries. The change in those, especially #5, are pretty simple but
the diff are indeed hard to read :/
>
> Best regards
> Uwe
--
Jerome
On Sat 02 Mar 2024 at 16:50, Jerome Brunet <[email protected]> wrote:
> On Sat 02 Mar 2024 at 11:04, Uwe Kleine-König <[email protected]> wrote:
>
>> [[PGP Signed Part:Undecided]]
>> Hello Jerome,
>>
>> On Wed, Feb 21, 2024 at 04:11:46PM +0100, Jerome Brunet wrote:
>>> Jerome Brunet (5):
>>> dt-bindings: pwm: amlogic: fix s4 bindings
>>> dt-bindings: pwm: amlogic: Add a new binding for meson8 pwm types
>>> pwm: meson: generalize 4 inputs clock on meson8 pwm type
>>> pwm: meson: don't carry internal clock elements around
>>> pwm: meson: add generic compatible for meson8 to sm1
>>
>> I applied patches #1 to #3. This doesn't mean #4 and #5 are bad, just
>> that I need some more time for review.
>
> No worries. The change in those, especially #5, are pretty simple but
> the diff are indeed hard to read :/
Hello Uwe,
Introducing the s4 support depends on this series.
Is there any news ?
Thanks
Regards
>
>>
>> Best regards
>> Uwe
--
Jerome
Hello Jerome, Uwe
On 4/12/24 11:04, Jerome Brunet wrote:
>
> On Sat 02 Mar 2024 at 16:50, Jerome Brunet <[email protected]> wrote:
>
>> On Sat 02 Mar 2024 at 11:04, Uwe Kleine-König <[email protected]> wrote:
>>
>>> [[PGP Signed Part:Undecided]]
>>> Hello Jerome,
>>>
>>> On Wed, Feb 21, 2024 at 04:11:46PM +0100, Jerome Brunet wrote:
>>>> Jerome Brunet (5):
>>>> dt-bindings: pwm: amlogic: fix s4 bindings
>>>> dt-bindings: pwm: amlogic: Add a new binding for meson8 pwm types
>>>> pwm: meson: generalize 4 inputs clock on meson8 pwm type
>>>> pwm: meson: don't carry internal clock elements around
>>>> pwm: meson: add generic compatible for meson8 to sm1
>>>
>>> I applied patches #1 to #3. This doesn't mean #4 and #5 are bad, just
>>> that I need some more time for review.
>>
>> No worries. The change in those, especially #5, are pretty simple but
>> the diff are indeed hard to read :/
>
> Hello Uwe,
>
> Introducing the s4 support depends on this series.
> Is there any news ?
Actually we're waiting for the opportunity to introduce a1 support too.
>
> Thanks
> Regards
>
>>
>>>
>>> Best regards
>>> Uwe
>
>
--
Best regards
George
On Wed, Feb 21, 2024 at 04:11:51PM +0100, Jerome Brunet wrote:
> Introduce a new compatible support in the Amlogic PWM driver.
>
> The PWM HW is actually the same for all SoCs supported so far. A specific
> compatible is needed only because the clock sources of the PWMs are
> hard-coded in the driver.
>
> It is better to have the clock source described in DT but this changes the
> bindings so a new compatible must be introduced.
>
> When all supported platform have migrated to the new compatible, support
> for the legacy ones may be removed from the driver.
>
> The addition of this new compatible makes the old ones obsolete, as
> described in the DT documentation.
>
> Adding a callback to setup the clock will also make it easier to add
> support for the new PWM HW found in a1, s4, c3 and t7 SoC families.
>
> Signed-off-by: Jerome Brunet <[email protected]>
After spending some brain cycles on this one I think I understood it.
Looks fine to me, I only considered questioning if the dev_warn_once is
too offensive.
b4 + git applied the patch just fine even without patch #4 of this
series. Would you be so kind to double check it works as intended?
BTW, b4 diagnosed:
Checking attestation on all messages, may take a moment...
---
✗ [PATCH v5 5/5] pwm: meson: add generic compatible for meson8 to sm1
+ Link: https://lore.kernel.org/r/[email protected]
+ Signed-off-by: Uwe Kleine-König <[email protected]>
---
✗ BADSIG: DKIM/baylibre-com.20230601.gappssmtp.com
Is this only because it took me so long to reply, or is there a
configuration issue with the baylibre MTA?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Fri 12 Apr 2024 at 14:08, Uwe Kleine-König <[email protected]> wrote:
> [[PGP Signed Part:Undecided]]
> On Wed, Feb 21, 2024 at 04:11:51PM +0100, Jerome Brunet wrote:
>> Introduce a new compatible support in the Amlogic PWM driver.
>>
>> The PWM HW is actually the same for all SoCs supported so far. A specific
>> compatible is needed only because the clock sources of the PWMs are
>> hard-coded in the driver.
>>
>> It is better to have the clock source described in DT but this changes the
>> bindings so a new compatible must be introduced.
>>
>> When all supported platform have migrated to the new compatible, support
>> for the legacy ones may be removed from the driver.
>>
>> The addition of this new compatible makes the old ones obsolete, as
>> described in the DT documentation.
>>
>> Adding a callback to setup the clock will also make it easier to add
>> support for the new PWM HW found in a1, s4, c3 and t7 SoC families.
>>
>> Signed-off-by: Jerome Brunet <[email protected]>
>
> After spending some brain cycles on this one I think I understood it.
> Looks fine to me, I only considered questioning if the dev_warn_once is
> too offensive.
>
> b4 + git applied the patch just fine even without patch #4 of this
> series. Would you be so kind to double check it works as intended?
It does, Thx.
>
> BTW, b4 diagnosed:
>
> Checking attestation on all messages, may take a moment...
> ---
> ✗ [PATCH v5 5/5] pwm: meson: add generic compatible for meson8 to sm1
> + Link: https://lore.kernel.org/r/[email protected]
> + Signed-off-by: Uwe Kleine-König <[email protected]>
> ---
> ✗ BADSIG: DKIM/baylibre-com.20230601.gappssmtp.com
>
> Is this only because it took me so long to reply, or is there a
> configuration issue with the baylibre MTA?
I have no idea. This is the first time this is reported
>
> Best regards
> Uwe
--
Jerome
On Thu, Apr 18, 2024 at 01:57:03PM +0200, Jerome Brunet wrote:
> On Fri 12 Apr 2024 at 14:08, Uwe Kleine-König <[email protected]> wrote:
> > b4 + git applied the patch just fine even without patch #4 of this
> > series. Would you be so kind to double check it works as intended?
>
> It does, Thx.
Thank you.
> > BTW, b4 diagnosed:
> >
> > Checking attestation on all messages, may take a moment...
> > ---
> > ✗ [PATCH v5 5/5] pwm: meson: add generic compatible for meson8 to sm1
> > + Link: https://lore.kernel.org/r/[email protected]
> > + Signed-off-by: Uwe Kleine-König <[email protected]>
> > ---
> > ✗ BADSIG: DKIM/baylibre-com.20230601.gappssmtp.com
> >
> > Is this only because it took me so long to reply, or is there a
> > configuration issue with the baylibre MTA?
>
> I have no idea. This is the first time this is reported
I just picked up a patch by one of your colleagues and there the DKIM
stuff was fine. I didn't debug that further.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On 18/04/2024 18:08, Uwe Kleine-König wrote:
> On Thu, Apr 18, 2024 at 01:57:03PM +0200, Jerome Brunet wrote:
>> On Fri 12 Apr 2024 at 14:08, Uwe Kleine-König <[email protected]> wrote:
>>> b4 + git applied the patch just fine even without patch #4 of this
>>> series. Would you be so kind to double check it works as intended?
>>
>> It does, Thx.
>
> Thank you.
>
>>> BTW, b4 diagnosed:
>>>
>>> Checking attestation on all messages, may take a moment...
>>> ---
>>> ✗ [PATCH v5 5/5] pwm: meson: add generic compatible for meson8 to sm1
>>> + Link: https://lore.kernel.org/r/[email protected]
>>> + Signed-off-by: Uwe Kleine-König <[email protected]>
>>> ---
>>> ✗ BADSIG: DKIM/baylibre-com.20230601.gappssmtp.com
>>>
>>> Is this only because it took me so long to reply, or is there a
>>> configuration issue with the baylibre MTA?
>>
>> I have no idea. This is the first time this is reported
>
> I just picked up a patch by one of your colleagues and there the DKIM
> stuff was fine. I didn't debug that further.
Google's DKIM key gets rotated, after while the DKIM signature gets invalid.
The best is to add a GPG signature on top of DKIM, like with B4.
Neil
>
> Best regards
> Uwe
>