[PATCH v13 00/11] Convert PWM period and duty cycle to u64

[PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in
this series to be accepted and applied to the tree? I lost an Acked-by (in
intel-panel.c) because it had a merge conflict with a new change that came in
after I rebased to tip. I wasn't sure earlier about accepting single patches as
opposed to the entire series en masse, but this event has got me thinking.

[COVER LETTER]

Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like, for instance,
causing an LED to blink at an interval of 5 seconds.

Redefining the period and duty cycle struct members in the core PWM framework
structs as u64 values will enable larger time durations to be set and solve
this problem. Such a change to the framework mandates that drivers using these
struct members (and corresponding helper functions) also be modified correctly
in order to prevent compilation errors.

This patch series introduces the changes to all the drivers first, followed by
the framework change at the very end so that when the latter is applied, all
the drivers are in good shape and there are no compilation errors.

Changes from v12:
  - Rebased to tip of for-next
  - Collected Acked-by for sun4i
  - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
    a result

Changes from v11:
  - Rebased to tip of for-next.
  - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
  - Squished stm32-lp.c change with final patch in series
  - sun4i: Used nsecs_to_jiffies()
  - imx27: Added overflow handling logic
  - clps711x: Corrected the if condition for skipping the division
  - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero

Changes from v10:
  - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
    so far that had gotten missed in v9. No other changes.

Changes from v9:
  - Gathered the received "Reviewed-by: " tag
  - Added back the clk-pwm.c patch because kbuild test robot complained [3]
    and addressed received review comments.
  - clps711x: Addressed review comments.

Changes from v8:
  - Gathered all received "Acked-by: " and "Reviewed-by: " tags
  - Dropped patch to clk-pwm.c for reasons mentiond in [2]
  - Expanded audience of unreviewed patches

Changes from v7:
  - Changed commit messages of all patches to be brief and to the point.
  - Added explanation of change in cover letter.
  - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
    pwm_capture is not being modified in the PWM core.

Changes from v6:
  - Split out the driver changes out into separate patches, one patch per file
    for ease of reviewing.

Changes from v5:
  - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
    in https://www.spinics.net/lists/linux-pwm/msg11541.html

Changes from v4:
  - Split the patch into two: one for changes to the drivers, and the actual
    switch to u64 for ease of reverting should the need arise.
  - Re-examined the patch and made the following corrections:
      * intel_panel.c:
	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
	64-bit in this case).
      * pwm-sti.c:
	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
	div_u64's comment block suggests to use this as much as possible).

Changes from v3:
  - Rebased to current tip of for-next.

Changes from v2:
  - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
  - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c

Changes from v1:
  - Fixed compilation errors seen when compiling for different archs.

v1:
  - Reworked the change pushed upstream earlier [1] so as to not add an
    extension to an obsolete API. With this change, pwm_ops->apply() can be
    used to set pwm_state parameters as usual.

[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html

To: Arnd Bergmann <arnd@arndb.de>
To: David Laight <David.Laight@ACULAB.COM>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: David Collins <collinsd@codeaurora.org>
Cc: dri-devel@lists.freedesktop.org
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Kamil Debski <kamil@wypas.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: Mark Brown <broonie@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Yash Shah <yash.shah@sifive.com>

Guru Das Srinagesh (11):
  drm/i915: Use 64-bit division macro
  hwmon: pwm-fan: Use 64-bit division macro
  ir-rx51: Use 64-bit division macro
  pwm: clps711x: Cast period to u32 before use as divisor
  pwm: pwm-imx-tpm: Use 64-bit division macro
  pwm: imx27: Use 64-bit division macro and function
  pwm: sifive: Use 64-bit division macro
  pwm: sun4i: Use nsecs_to_jiffies to avoid a division
  backlight: pwm_bl: Use 64-bit division function
  clk: pwm: Use 64-bit division function
  pwm: core: Convert period and duty cycle to u64

 drivers/clk/clk-pwm.c                      |  7 +++-
 drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
 drivers/hwmon/pwm-fan.c                    |  2 +-
 drivers/media/rc/ir-rx51.c                 |  3 +-
 drivers/pwm/core.c                         | 14 ++++----
 drivers/pwm/pwm-clps711x.c                 |  5 ++-
 drivers/pwm/pwm-imx-tpm.c                  |  2 +-
 drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
 drivers/pwm/pwm-sifive.c                   |  2 +-
 drivers/pwm/pwm-stm32-lp.c                 |  2 +-
 drivers/pwm/pwm-sun4i.c                    |  2 +-
 drivers/pwm/sysfs.c                        |  8 ++---
 drivers/video/backlight/pwm_bl.c           |  3 +-
 include/linux/pwm.h                        | 12 +++----
 14 files changed, 82 insertions(+), 35 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in
this series to be accepted and applied to the tree? I lost an Acked-by (in
intel-panel.c) because it had a merge conflict with a new change that came in
after I rebased to tip. I wasn't sure earlier about accepting single patches as
opposed to the entire series en masse, but this event has got me thinking.

[COVER LETTER]

Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like, for instance,
causing an LED to blink at an interval of 5 seconds.

Redefining the period and duty cycle struct members in the core PWM framework
structs as u64 values will enable larger time durations to be set and solve
this problem. Such a change to the framework mandates that drivers using these
struct members (and corresponding helper functions) also be modified correctly
in order to prevent compilation errors.

This patch series introduces the changes to all the drivers first, followed by
the framework change at the very end so that when the latter is applied, all
the drivers are in good shape and there are no compilation errors.

Changes from v12:
  - Rebased to tip of for-next
  - Collected Acked-by for sun4i
  - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
    a result

Changes from v11:
  - Rebased to tip of for-next.
  - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
  - Squished stm32-lp.c change with final patch in series
  - sun4i: Used nsecs_to_jiffies()
  - imx27: Added overflow handling logic
  - clps711x: Corrected the if condition for skipping the division
  - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero

Changes from v10:
  - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
    so far that had gotten missed in v9. No other changes.

Changes from v9:
  - Gathered the received "Reviewed-by: " tag
  - Added back the clk-pwm.c patch because kbuild test robot complained [3]
    and addressed received review comments.
  - clps711x: Addressed review comments.

Changes from v8:
  - Gathered all received "Acked-by: " and "Reviewed-by: " tags
  - Dropped patch to clk-pwm.c for reasons mentiond in [2]
  - Expanded audience of unreviewed patches

Changes from v7:
  - Changed commit messages of all patches to be brief and to the point.
  - Added explanation of change in cover letter.
  - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
    pwm_capture is not being modified in the PWM core.

Changes from v6:
  - Split out the driver changes out into separate patches, one patch per file
    for ease of reviewing.

Changes from v5:
  - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
    in https://www.spinics.net/lists/linux-pwm/msg11541.html

Changes from v4:
  - Split the patch into two: one for changes to the drivers, and the actual
    switch to u64 for ease of reverting should the need arise.
  - Re-examined the patch and made the following corrections:
      * intel_panel.c:
	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
	64-bit in this case).
      * pwm-sti.c:
	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
	div_u64's comment block suggests to use this as much as possible).

Changes from v3:
  - Rebased to current tip of for-next.

Changes from v2:
  - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
  - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c

Changes from v1:
  - Fixed compilation errors seen when compiling for different archs.

v1:
  - Reworked the change pushed upstream earlier [1] so as to not add an
    extension to an obsolete API. With this change, pwm_ops->apply() can be
    used to set pwm_state parameters as usual.

[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html

To: Arnd Bergmann <arnd@arndb.de>
To: David Laight <David.Laight@ACULAB.COM>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: David Collins <collinsd@codeaurora.org>
Cc: dri-devel@lists.freedesktop.org
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Kamil Debski <kamil@wypas.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: Mark Brown <broonie@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Yash Shah <yash.shah@sifive.com>

Guru Das Srinagesh (11):
  drm/i915: Use 64-bit division macro
  hwmon: pwm-fan: Use 64-bit division macro
  ir-rx51: Use 64-bit division macro
  pwm: clps711x: Cast period to u32 before use as divisor
  pwm: pwm-imx-tpm: Use 64-bit division macro
  pwm: imx27: Use 64-bit division macro and function
  pwm: sifive: Use 64-bit division macro
  pwm: sun4i: Use nsecs_to_jiffies to avoid a division
  backlight: pwm_bl: Use 64-bit division function
  clk: pwm: Use 64-bit division function
  pwm: core: Convert period and duty cycle to u64

 drivers/clk/clk-pwm.c                      |  7 +++-
 drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
 drivers/hwmon/pwm-fan.c                    |  2 +-
 drivers/media/rc/ir-rx51.c                 |  3 +-
 drivers/pwm/core.c                         | 14 ++++----
 drivers/pwm/pwm-clps711x.c                 |  5 ++-
 drivers/pwm/pwm-imx-tpm.c                  |  2 +-
 drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
 drivers/pwm/pwm-sifive.c                   |  2 +-
 drivers/pwm/pwm-stm32-lp.c                 |  2 +-
 drivers/pwm/pwm-sun4i.c                    |  2 +-
 drivers/pwm/sysfs.c                        |  8 ++---
 drivers/video/backlight/pwm_bl.c           |  3 +-
 include/linux/pwm.h                        | 12 +++----
 14 files changed, 82 insertions(+), 35 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in
this series to be accepted and applied to the tree? I lost an Acked-by (in
intel-panel.c) because it had a merge conflict with a new change that came in
after I rebased to tip. I wasn't sure earlier about accepting single patches as
opposed to the entire series en masse, but this event has got me thinking.

[COVER LETTER]

Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like, for instance,
causing an LED to blink at an interval of 5 seconds.

Redefining the period and duty cycle struct members in the core PWM framework
structs as u64 values will enable larger time durations to be set and solve
this problem. Such a change to the framework mandates that drivers using these
struct members (and corresponding helper functions) also be modified correctly
in order to prevent compilation errors.

This patch series introduces the changes to all the drivers first, followed by
the framework change at the very end so that when the latter is applied, all
the drivers are in good shape and there are no compilation errors.

Changes from v12:
  - Rebased to tip of for-next
  - Collected Acked-by for sun4i
  - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
    a result

Changes from v11:
  - Rebased to tip of for-next.
  - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
  - Squished stm32-lp.c change with final patch in series
  - sun4i: Used nsecs_to_jiffies()
  - imx27: Added overflow handling logic
  - clps711x: Corrected the if condition for skipping the division
  - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero

Changes from v10:
  - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
    so far that had gotten missed in v9. No other changes.

Changes from v9:
  - Gathered the received "Reviewed-by: " tag
  - Added back the clk-pwm.c patch because kbuild test robot complained [3]
    and addressed received review comments.
  - clps711x: Addressed review comments.

Changes from v8:
  - Gathered all received "Acked-by: " and "Reviewed-by: " tags
  - Dropped patch to clk-pwm.c for reasons mentiond in [2]
  - Expanded audience of unreviewed patches

Changes from v7:
  - Changed commit messages of all patches to be brief and to the point.
  - Added explanation of change in cover letter.
  - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
    pwm_capture is not being modified in the PWM core.

Changes from v6:
  - Split out the driver changes out into separate patches, one patch per file
    for ease of reviewing.

Changes from v5:
  - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
    in https://www.spinics.net/lists/linux-pwm/msg11541.html

Changes from v4:
  - Split the patch into two: one for changes to the drivers, and the actual
    switch to u64 for ease of reverting should the need arise.
  - Re-examined the patch and made the following corrections:
      * intel_panel.c:
	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
	64-bit in this case).
      * pwm-sti.c:
	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
	div_u64's comment block suggests to use this as much as possible).

Changes from v3:
  - Rebased to current tip of for-next.

Changes from v2:
  - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
  - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c

Changes from v1:
  - Fixed compilation errors seen when compiling for different archs.

v1:
  - Reworked the change pushed upstream earlier [1] so as to not add an
    extension to an obsolete API. With this change, pwm_ops->apply() can be
    used to set pwm_state parameters as usual.

[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html

To: Arnd Bergmann <arnd@arndb.de>
To: David Laight <David.Laight@ACULAB.COM>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: David Collins <collinsd@codeaurora.org>
Cc: dri-devel@lists.freedesktop.org
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Kamil Debski <kamil@wypas.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: Mark Brown <broonie@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Yash Shah <yash.shah@sifive.com>

Guru Das Srinagesh (11):
  drm/i915: Use 64-bit division macro
  hwmon: pwm-fan: Use 64-bit division macro
  ir-rx51: Use 64-bit division macro
  pwm: clps711x: Cast period to u32 before use as divisor
  pwm: pwm-imx-tpm: Use 64-bit division macro
  pwm: imx27: Use 64-bit division macro and function
  pwm: sifive: Use 64-bit division macro
  pwm: sun4i: Use nsecs_to_jiffies to avoid a division
  backlight: pwm_bl: Use 64-bit division function
  clk: pwm: Use 64-bit division function
  pwm: core: Convert period and duty cycle to u64

 drivers/clk/clk-pwm.c                      |  7 +++-
 drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
 drivers/hwmon/pwm-fan.c                    |  2 +-
 drivers/media/rc/ir-rx51.c                 |  3 +-
 drivers/pwm/core.c                         | 14 ++++----
 drivers/pwm/pwm-clps711x.c                 |  5 ++-
 drivers/pwm/pwm-imx-tpm.c                  |  2 +-
 drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
 drivers/pwm/pwm-sifive.c                   |  2 +-
 drivers/pwm/pwm-stm32-lp.c                 |  2 +-
 drivers/pwm/pwm-sun4i.c                    |  2 +-
 drivers/pwm/sysfs.c                        |  8 ++---
 drivers/video/backlight/pwm_bl.c           |  3 +-
 include/linux/pwm.h                        | 12 +++----
 14 files changed, 82 insertions(+), 35 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

[REQUEST]

Would it be possible for the patches that have already received Acked-by's in
this series to be accepted and applied to the tree? I lost an Acked-by (in
intel-panel.c) because it had a merge conflict with a new change that came in
after I rebased to tip. I wasn't sure earlier about accepting single patches as
opposed to the entire series en masse, but this event has got me thinking.

[COVER LETTER]

Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like, for instance,
causing an LED to blink at an interval of 5 seconds.

Redefining the period and duty cycle struct members in the core PWM framework
structs as u64 values will enable larger time durations to be set and solve
this problem. Such a change to the framework mandates that drivers using these
struct members (and corresponding helper functions) also be modified correctly
in order to prevent compilation errors.

This patch series introduces the changes to all the drivers first, followed by
the framework change at the very end so that when the latter is applied, all
the drivers are in good shape and there are no compilation errors.

Changes from v12:
  - Rebased to tip of for-next
  - Collected Acked-by for sun4i
  - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
    a result

Changes from v11:
  - Rebased to tip of for-next.
  - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
  - Squished stm32-lp.c change with final patch in series
  - sun4i: Used nsecs_to_jiffies()
  - imx27: Added overflow handling logic
  - clps711x: Corrected the if condition for skipping the division
  - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero

Changes from v10:
  - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
    so far that had gotten missed in v9. No other changes.

Changes from v9:
  - Gathered the received "Reviewed-by: " tag
  - Added back the clk-pwm.c patch because kbuild test robot complained [3]
    and addressed received review comments.
  - clps711x: Addressed review comments.

Changes from v8:
  - Gathered all received "Acked-by: " and "Reviewed-by: " tags
  - Dropped patch to clk-pwm.c for reasons mentiond in [2]
  - Expanded audience of unreviewed patches

Changes from v7:
  - Changed commit messages of all patches to be brief and to the point.
  - Added explanation of change in cover letter.
  - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
    pwm_capture is not being modified in the PWM core.

Changes from v6:
  - Split out the driver changes out into separate patches, one patch per file
    for ease of reviewing.

Changes from v5:
  - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
    in https://www.spinics.net/lists/linux-pwm/msg11541.html

Changes from v4:
  - Split the patch into two: one for changes to the drivers, and the actual
    switch to u64 for ease of reverting should the need arise.
  - Re-examined the patch and made the following corrections:
      * intel_panel.c:
	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
	64-bit in this case).
      * pwm-sti.c:
	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
	div_u64's comment block suggests to use this as much as possible).

Changes from v3:
  - Rebased to current tip of for-next.

Changes from v2:
  - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
  - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c

Changes from v1:
  - Fixed compilation errors seen when compiling for different archs.

v1:
  - Reworked the change pushed upstream earlier [1] so as to not add an
    extension to an obsolete API. With this change, pwm_ops->apply() can be
    used to set pwm_state parameters as usual.

[1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
[2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
[3] https://www.spinics.net/lists/linux-pwm/msg11906.html
[4] https://www.spinics.net/lists/linux-pwm/msg11986.html

To: Arnd Bergmann <arnd@arndb.de>
To: David Laight <David.Laight@ACULAB.COM>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Allison Randal <allison@lohutok.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: David Collins <collinsd@codeaurora.org>
Cc: dri-devel@lists.freedesktop.org
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: intel-gfx@lists.freedesktop.org
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Kamil Debski <kamil@wypas.org>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Cc: Mark Brown <broonie@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Yash Shah <yash.shah@sifive.com>

Guru Das Srinagesh (11):
  drm/i915: Use 64-bit division macro
  hwmon: pwm-fan: Use 64-bit division macro
  ir-rx51: Use 64-bit division macro
  pwm: clps711x: Cast period to u32 before use as divisor
  pwm: pwm-imx-tpm: Use 64-bit division macro
  pwm: imx27: Use 64-bit division macro and function
  pwm: sifive: Use 64-bit division macro
  pwm: sun4i: Use nsecs_to_jiffies to avoid a division
  backlight: pwm_bl: Use 64-bit division function
  clk: pwm: Use 64-bit division function
  pwm: core: Convert period and duty cycle to u64

 drivers/clk/clk-pwm.c                      |  7 +++-
 drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
 drivers/hwmon/pwm-fan.c                    |  2 +-
 drivers/media/rc/ir-rx51.c                 |  3 +-
 drivers/pwm/core.c                         | 14 ++++----
 drivers/pwm/pwm-clps711x.c                 |  5 ++-
 drivers/pwm/pwm-imx-tpm.c                  |  2 +-
 drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
 drivers/pwm/pwm-sifive.c                   |  2 +-
 drivers/pwm/pwm-stm32-lp.c                 |  2 +-
 drivers/pwm/pwm-sun4i.c                    |  2 +-
 drivers/pwm/sysfs.c                        |  8 ++---
 drivers/video/backlight/pwm_bl.c           |  3 +-
 include/linux/pwm.h                        | 12 +++----
 14 files changed, 82 insertions(+), 35 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.

To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index 276f438..81547a0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
 		return retval;
 	}
 
-	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 			     CRC_PMIC_PWM_PERIOD_NS);
 	panel->backlight.level =
 		intel_panel_compute_brightness(connector, level);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Intel-gfx] [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.

To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index 276f438..81547a0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
 		return retval;
 	}
 
-	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 			     CRC_PMIC_PWM_PERIOD_NS);
 	panel->backlight.level =
 		intel_panel_compute_brightness(connector, level);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.

To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index 276f438..81547a0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
 		return retval;
 	}
 
-	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
+	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 			     CRC_PMIC_PWM_PERIOD_NS);
 	panel->backlight.level =
 		intel_panel_compute_brightness(connector, level);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> Since the PWM framework is switching struct pwm_state.duty_cycle's
> datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> to handle a 64-bit dividend.
>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
>

Superfluous blank line.

Anyway, please preserve the existing acks and reviews [1] so people
don't have to do it again.

BR,
Jani.

[1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
> index 276f438..81547a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
>  		return retval;
>  	}
>  
> -	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
> +	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
>  			     CRC_PMIC_PWM_PERIOD_NS);
>  	panel->backlight.level =
>  		intel_panel_compute_brightness(connector, level);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> Since the PWM framework is switching struct pwm_state.duty_cycle's
> datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> to handle a 64-bit dividend.
>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
>

Superfluous blank line.

Anyway, please preserve the existing acks and reviews [1] so people
don't have to do it again.

BR,
Jani.

[1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
> index 276f438..81547a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
>  		return retval;
>  	}
>  
> -	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
> +	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
>  			     CRC_PMIC_PWM_PERIOD_NS);
>  	panel->backlight.level =
>  		intel_panel_compute_brightness(connector, level);

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> Since the PWM framework is switching struct pwm_state.duty_cycle's
> datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> to handle a 64-bit dividend.
>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
>

Superfluous blank line.

Anyway, please preserve the existing acks and reviews [1] so people
don't have to do it again.

BR,
Jani.

[1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
> index 276f438..81547a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
>  		return retval;
>  	}
>  
> -	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
> +	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
>  			     CRC_PMIC_PWM_PERIOD_NS);
>  	panel->backlight.level =
>  		intel_panel_compute_brightness(connector, level);

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> Since the PWM framework is switching struct pwm_state.duty_cycle's
> datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> to handle a 64-bit dividend.
>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
>

Superfluous blank line.

Anyway, please preserve the existing acks and reviews [1] so people
don't have to do it again.

BR,
Jani.

[1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
> index 276f438..81547a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1920,7 +1920,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
>  		return retval;
>  	}
>  
> -	level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
> +	level = DIV_ROUND_UP_ULL(pwm_get_duty_cycle(panel->backlight.pwm) * 100,
>  			     CRC_PMIC_PWM_PERIOD_NS);
>  	panel->backlight.level =
>  		intel_panel_compute_brightness(connector, level);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
> On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > Since the PWM framework is switching struct pwm_state.duty_cycle's
> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> > to handle a 64-bit dividend.
> >
> > To: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: David Airlie <airlied@linux.ie>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> >
> 
> Superfluous blank line.

Will remove.

> 
> Anyway, please preserve the existing acks and reviews [1] so people
> don't have to do it again.
> 
> BR,
> Jani.
> 
> [1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

I dropped your Acked-by as the patch had to changed to resolve a merge
conflict when I rebased to tip. Could you please re-review this patch?

Thank you.

Guru Das.

Re: [Intel-gfx] [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
> On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > Since the PWM framework is switching struct pwm_state.duty_cycle's
> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> > to handle a 64-bit dividend.
> >
> > To: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: David Airlie <airlied@linux.ie>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> >
> 
> Superfluous blank line.

Will remove.

> 
> Anyway, please preserve the existing acks and reviews [1] so people
> don't have to do it again.
> 
> BR,
> Jani.
> 
> [1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

I dropped your Acked-by as the patch had to changed to resolve a merge
conflict when I rebased to tip. Could you please re-review this patch?

Thank you.

Guru Das.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
> On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > Since the PWM framework is switching struct pwm_state.duty_cycle's
> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
> > to handle a 64-bit dividend.
> >
> > To: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > Cc: David Airlie <airlied@linux.ie>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> >
> 
> Superfluous blank line.

Will remove.

> 
> Anyway, please preserve the existing acks and reviews [1] so people
> don't have to do it again.
> 
> BR,
> Jani.
> 
> [1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com

I dropped your Acked-by as the patch had to changed to resolve a merge
conflict when I rebased to tip. Could you please re-review this patch?

Thank you.

Guru Das.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Fri, 24 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
>> On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>> > Since the PWM framework is switching struct pwm_state.duty_cycle's
>> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
>> > to handle a 64-bit dividend.
>> >
>> > To: Jani Nikula <jani.nikula@linux.intel.com>
>> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> > Cc: David Airlie <airlied@linux.ie>
>> > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
>> > Cc: intel-gfx@lists.freedesktop.org
>> > Cc: dri-devel@lists.freedesktop.org
>> >
>> 
>> Superfluous blank line.
>
> Will remove.
>
>> 
>> Anyway, please preserve the existing acks and reviews [1] so people
>> don't have to do it again.
>> 
>> BR,
>> Jani.
>> 
>> [1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com
>
> I dropped your Acked-by as the patch had to changed to resolve a merge
> conflict when I rebased to tip. Could you please re-review this patch?

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Fri, 24 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
>> On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>> > Since the PWM framework is switching struct pwm_state.duty_cycle's
>> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
>> > to handle a 64-bit dividend.
>> >
>> > To: Jani Nikula <jani.nikula@linux.intel.com>
>> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> > Cc: David Airlie <airlied@linux.ie>
>> > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
>> > Cc: intel-gfx@lists.freedesktop.org
>> > Cc: dri-devel@lists.freedesktop.org
>> >
>> 
>> Superfluous blank line.
>
> Will remove.
>
>> 
>> Anyway, please preserve the existing acks and reviews [1] so people
>> don't have to do it again.
>> 
>> BR,
>> Jani.
>> 
>> [1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com
>
> I dropped your Acked-by as the patch had to changed to resolve a merge
> conflict when I rebased to tip. Could you please re-review this patch?

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 01/11] drm/i915: Use 64-bit division macro

[Jani Nikula]

On Fri, 24 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> On Fri, Apr 24, 2020 at 09:17:58AM +0300, Jani Nikula wrote:
>> On Tue, 21 Apr 2020, Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>> > Since the PWM framework is switching struct pwm_state.duty_cycle's
>> > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
>> > to handle a 64-bit dividend.
>> >
>> > To: Jani Nikula <jani.nikula@linux.intel.com>
>> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> > Cc: David Airlie <airlied@linux.ie>
>> > Cc: Daniel Vetter <daniel@ffwll.ch>
>> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
>> > Cc: intel-gfx@lists.freedesktop.org
>> > Cc: dri-devel@lists.freedesktop.org
>> >
>> 
>> Superfluous blank line.
>
> Will remove.
>
>> 
>> Anyway, please preserve the existing acks and reviews [1] so people
>> don't have to do it again.
>> 
>> BR,
>> Jani.
>> 
>> [1] http://lore.kernel.org/r/87h7yleb0i.fsf@intel.com
>
> I dropped your Acked-by as the patch had to changed to resolve a merge
> conflict when I rebased to tip. Could you please re-review this patch?

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v13 02/11] hwmon: pwm-fan: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle
a 64-bit dividend.

Cc: Kamil Debski <kamil@wypas.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-hwmon@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
 drivers/hwmon/pwm-fan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 30b7b3e..17bb642 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -447,7 +447,7 @@ static int pwm_fan_resume(struct device *dev)
 		return 0;
 
 	pwm_get_args(ctx->pwm, &pargs);
-	duty = DIV_ROUND_UP(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
+	duty = DIV_ROUND_UP_ULL(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
 	ret = pwm_config(ctx->pwm, duty, pargs.period);
 	if (ret)
 		return ret;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 03/11] ir-rx51: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV_ROUND_CLOSEST_ULL to
handle a 64-bit dividend.

Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Allison Randal <allison@lohutok.net>
Cc: linux-media@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Sean Young <sean@mess.org>
---
 drivers/media/rc/ir-rx51.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8574eda..9a5dfd7 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -241,7 +241,8 @@ static int ir_rx51_probe(struct platform_device *dev)
 	}
 
 	/* Use default, in case userspace does not set the carrier */
-	ir_rx51.freq = DIV_ROUND_CLOSEST(pwm_get_period(pwm), NSEC_PER_SEC);
+	ir_rx51.freq = DIV_ROUND_CLOSEST_ULL(pwm_get_period(pwm),
+			NSEC_PER_SEC);
 	pwm_put(pwm);
 
 	hrtimer_init(&ir_rx51.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 04/11] pwm: clps711x: Cast period to u32 before use as divisor

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by typecasting it to u32.

Also, since the dividend is still a 32-bit number, any divisor greater
than the numerator will cause the quotient to be zero, so return 0 in
that case to efficiently skip the division.

Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Arnd Bergmann <arnd@arndb.de>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-clps711x.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index 924d39a..0d368ac 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
 static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
 {
 	/* Duty cycle 0..15 max */
-	return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+	if ((u32)pwm->args.period > (v * 0xf))
+		return 0;
+
+	return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
 }
 
 static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v13 04/11] pwm: clps711x: Cast period to u32 before use as divisor

[Geert Uytterhoeven]

On Wed, Apr 22, 2020 at 5:00 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by typecasting it to u32.
>
> Also, since the dividend is still a 32-bit number, any divisor greater
> than the numerator will cause the quotient to be zero, so return 0 in
> that case to efficiently skip the division.
>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Arnd Bergmann <arnd@arndb.de>
>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/pwm/pwm-clps711x.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> index 924d39a..0d368ac 100644
> --- a/drivers/pwm/pwm-clps711x.c
> +++ b/drivers/pwm/pwm-clps711x.c
> @@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
>  static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
>  {
>         /* Duty cycle 0..15 max */
> -       return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> +       if ((u32)pwm->args.period > (v * 0xf))

Shouldn't the cast be removed from the expression above?
Else a period larger than or equal to 2^32 may be accepted, but truncated
silently.  And even cause a division by zero error.


> +               return 0;
> +
> +       return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
>  }
>
>  static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v13 04/11] pwm: clps711x: Cast period to u32 before use as divisor

[Geert Uytterhoeven]

On Wed, Apr 22, 2020 at 5:00 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by typecasting it to u32.
>
> Also, since the dividend is still a 32-bit number, any divisor greater
> than the numerator will cause the quotient to be zero, so return 0 in
> that case to efficiently skip the division.
>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Arnd Bergmann <arnd@arndb.de>
>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/pwm/pwm-clps711x.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> index 924d39a..0d368ac 100644
> --- a/drivers/pwm/pwm-clps711x.c
> +++ b/drivers/pwm/pwm-clps711x.c
> @@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
>  static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
>  {
>         /* Duty cycle 0..15 max */
> -       return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> +       if ((u32)pwm->args.period > (v * 0xf))

Shouldn't the cast be removed from the expression above?
Else a period larger than or equal to 2^32 may be accepted, but truncated
silently.  And even cause a division by zero error.


> +               return 0;
> +
> +       return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
>  }
>
>  static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)

Gr{oetje,eeting}s,

                        Geert

Re: [PATCH v13 04/11] pwm: clps711x: Cast period to u32 before use as divisor

[Guru Das Srinagesh]

On Thu, Apr 23, 2020 at 11:30:19AM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 22, 2020 at 5:00 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > Since the PWM framework is switching struct pwm_args.period's datatype
> > to u64, prepare for this transition by typecasting it to u32.
> >
> > Also, since the dividend is still a 32-bit number, any divisor greater
> > than the numerator will cause the quotient to be zero, so return 0 in
> > that case to efficiently skip the division.
> >
> > Cc: Alexander Shiyan <shc_work@mail.ru>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> >
> > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > ---
> >  drivers/pwm/pwm-clps711x.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> > index 924d39a..0d368ac 100644
> > --- a/drivers/pwm/pwm-clps711x.c
> > +++ b/drivers/pwm/pwm-clps711x.c
> > @@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
> >  static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
> >  {
> >         /* Duty cycle 0..15 max */
> > -       return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> > +       if ((u32)pwm->args.period > (v * 0xf))
> 
> Shouldn't the cast be removed from the expression above?
> Else a period larger than or equal to 2^32 may be accepted, but truncated
> silently.  And even cause a division by zero error.

I agree. Will remove the cast in the next patchset.

Thank you.

Guru Das.

[PATCH v13 05/11] pwm: pwm-imx-tpm: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-imx-tpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index 5f3d7f7..fcdf6be 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -124,7 +124,7 @@ static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
 		real_state->duty_cycle = state->duty_cycle;
 
 	tmp = (u64)p->mod * real_state->duty_cycle;
-	p->val = DIV_ROUND_CLOSEST_ULL(tmp, real_state->period);
+	p->val = DIV64_U64_ROUND_CLOSEST(tmp, real_state->period);
 
 	real_state->polarity = state->polarity;
 	real_state->enabled = state->enabled;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 06/11] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's
datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULL to handle a 64-bit dividend, and div64_u64 to handle a
64-bit divisor.

Also handle a possible overflow in the calculation of period_cycles when
both clk_rate and period are large numbers. This logic was unit-tested
out by calculating period_cycles using both the existing logic and the
proposed one, and the results are as below.

----------------------------------------------------------------------------
 clk_rate            period           existing            proposed
----------------------------------------------------------------------------
1000000000   18446744073709551615    18446744072    18446744073000000000
                   (U64_MAX)
----------------------------------------------------------------------------
1000000000        4294967291         4294967291         4294967291
----------------------------------------------------------------------------

Overflow occurs in the first case with the existing logic, whereas the
proposed logic handles it better, sacrificing some precision in a best-effort
attempt to handle overflow. As for the second case where there are
more typical values of period, the proposed logic handles that correctly
too.

To: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: David Collins <collinsd@codeaurora.org>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-imx27.c | 53 +++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 45 insertions(+), 8 deletions(-)

diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index a6e40d4..164cb65 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -203,7 +203,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
 	sr = readl(imx->mmio_base + MX3_PWMSR);
 	fifoav = FIELD_GET(MX3_PWMSR_FIFOAV, sr);
 	if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
-		period_ms = DIV_ROUND_UP(pwm_get_period(pwm),
+		period_ms = DIV_ROUND_UP_ULL(pwm_get_period(pwm),
 					 NSEC_PER_MSEC);
 		msleep(period_ms);
 
@@ -213,6 +213,45 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
 	}
 }
 
+static int pwm_imx27_calc_period_cycles(const struct pwm_state *state,
+					unsigned long clk_rate,
+					unsigned long *period_cycles)
+{
+	u64 c = 0, c1, c2;
+
+	c1 = clk_rate;
+	c2 = state->period;
+	if (c2 > c1) {
+		c2 = c1;
+		c1 = state->period;
+	}
+
+	if (!c1 || !c2) {
+		pr_err("clk rate and period should be nonzero\n");
+		return -EINVAL;
+	}
+
+	if (c2 <= div64_u64(U64_MAX, c1)) {
+		c = c1 * c2;
+		do_div(c, 1000000000);
+	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) {
+		do_div(c1, 1000);
+		c = c1 * c2;
+		do_div(c, 1000000);
+	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) {
+		do_div(c1, 1000000);
+		c = c1 * c2;
+		do_div(c, 1000);
+	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) {
+		do_div(c1, 1000000000);
+		c = c1 * c2;
+	}
+
+	*period_cycles = c;
+
+	return 0;
+}
+
 static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			   const struct pwm_state *state)
 {
@@ -225,18 +264,16 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	pwm_get_state(pwm, &cstate);
 
-	c = clk_get_rate(imx->clk_per);
-	c *= state->period;
-
-	do_div(c, 1000000000);
-	period_cycles = c;
+	ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
+					   &period_cycles);
+	if (ret)
+		return ret;
 
 	prescale = period_cycles / 0x10000 + 1;
 
 	period_cycles /= prescale;
 	c = (unsigned long long)period_cycles * state->duty_cycle;
-	do_div(c, state->period);
-	duty_cycles = c;
+	duty_cycles = div64_u64(c, state->period);
 
 	/*
 	 * according to imx pwm RM, the real period value should be PERIOD
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 07/11] pwm: sifive: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.

Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org
Cc: Yash Shah <yash.shah@sifive.com>
Cc: Atish Patra <atish.patra@wdc.com>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
 drivers/pwm/pwm-sifive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index cc63f9b..62de0bb 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -181,7 +181,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * consecutively
 	 */
 	num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
-	frac = DIV_ROUND_CLOSEST_ULL(num, state->period);
+	frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
 	/* The hardware cannot generate a 100% duty cycle */
 	frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 07/11] pwm: sifive: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.

Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org
Cc: Yash Shah <yash.shah@sifive.com>
Cc: Atish Patra <atish.patra@wdc.com>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
 drivers/pwm/pwm-sifive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index cc63f9b..62de0bb 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -181,7 +181,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * consecutively
 	 */
 	num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
-	frac = DIV_ROUND_CLOSEST_ULL(num, state->period);
+	frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
 	/* The hardware cannot generate a 100% duty cycle */
 	frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 08/11] pwm: sun4i: Use nsecs_to_jiffies to avoid a division

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using nsecs_to_jiffies() which
does away with the need for a division operation.

Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/pwm/pwm-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 5c677c5..1694e69 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -285,7 +285,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	val = (duty & PWM_DTY_MASK) | PWM_PRD(period);
 	sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
 	sun4i_pwm->next_period[pwm->hwpwm] = jiffies +
-		usecs_to_jiffies(cstate.period / 1000 + 1);
+		nsecs_to_jiffies(cstate.period + 1000);
 
 	if (state->polarity != PWM_POLARITY_NORMAL)
 		ctrl &= ~BIT_CH(PWM_ACT_STATE, pwm->hwpwm);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-pwm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 drivers/video/backlight/pwm_bl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 82b8d75..464baad 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -606,7 +606,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 		pb->scale = data->max_brightness;
 	}
 
-	pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
+	pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
+				pb->scale));
 
 	props.type = BACKLIGHT_RAW;
 	props.max_brightness = data->max_brightness;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-pwm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 drivers/video/backlight/pwm_bl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 82b8d75..464baad 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -606,7 +606,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 		pb->scale = data->max_brightness;
 	}
 
-	pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
+	pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
+				pb->scale));
 
 	props.type = BACKLIGHT_RAW;
 	props.max_brightness = data->max_brightness;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-pwm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 drivers/video/backlight/pwm_bl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 82b8d75..464baad 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -606,7 +606,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 		pb->scale = data->max_brightness;
 	}
 
-	pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
+	pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
+				pb->scale));
 
 	props.type = BACKLIGHT_RAW;
 	props.max_brightness = data->max_brightness;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> Since the PWM framework is switching struct pwm_state.period's datatype
> to u64, prepare for this transition by using div_u64 to handle a 64-bit
> dividend instead of a straight division operation.
> 
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: linux-pwm@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> 
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> Since the PWM framework is switching struct pwm_state.period's datatype
> to u64, prepare for this transition by using div_u64 to handle a 64-bit
> dividend instead of a straight division operation.
> 
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: linux-pwm@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> 
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> Since the PWM framework is switching struct pwm_state.period's datatype
> to u64, prepare for this transition by using div_u64 to handle a 64-bit
> dividend instead of a straight division operation.
> 
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: linux-pwm@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> 
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>

Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v13 10/11] clk: pwm: Use 64-bit division function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using div64_u64 to handle a
64-bit divisor.

Also ensure that divide-by-zero (with fixed_rate as denominator) does
not happen with an explicit check with probe failure as a consequence.

To: David Laight <David.Laight@ACULAB.COM>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/clk/clk-pwm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 87fe0b0e..86f2e2d 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -89,7 +89,12 @@ static int clk_pwm_probe(struct platform_device *pdev)
 	}
 
 	if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
-		clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
+		clk_pwm->fixed_rate = div64_u64(NSEC_PER_SEC, pargs.period);
+
+	if (!clk_pwm->fixed_rate) {
+		dev_err(&pdev->dev, "fixed_rate cannot be zero\n");
+		return -EINVAL;
+	}
 
 	if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
 	    pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v13 10/11] clk: pwm: Use 64-bit division function

[Stephen Boyd]

Quoting Guru Das Srinagesh (2020-04-21 19:57:22)
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by using div64_u64 to handle a

Write div64_u64() please

> 64-bit divisor.
> 
> Also ensure that divide-by-zero (with fixed_rate as denominator) does
> not happen with an explicit check with probe failure as a consequence.
> 
> To: David Laight <David.Laight@ACULAB.COM>
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> 

Nitpick: Remove the extra newline.

> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---

Acked-by: Stephen Boyd <sboyd@kernel.org>

[PATCH v13 11/11] pwm: core: Convert period and duty cycle to u64

[Guru Das Srinagesh]

Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.

Also use the right format specifiers in debug prints in both core.c as
well as pwm-stm32-lp.c.

Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Joe Perches <joe@perches.com>

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/core.c         | 14 +++++++-------
 drivers/pwm/pwm-stm32-lp.c |  2 +-
 drivers/pwm/sysfs.c        |  8 ++++----
 include/linux/pwm.h        | 12 ++++++------
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index bca0496..a2ff6dd 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -510,12 +510,12 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 	    last->period > s2.period &&
 	    last->period <= state->period)
 		dev_warn(chip->dev,
-			 ".apply didn't pick the best available period (requested: %u, applied: %u, possible: %u)\n",
+			 ".apply didn't pick the best available period (requested: %llu, applied: %llu, possible: %llu)\n",
 			 state->period, s2.period, last->period);
 
 	if (state->enabled && state->period < s2.period)
 		dev_warn(chip->dev,
-			 ".apply is supposed to round down period (requested: %u, applied: %u)\n",
+			 ".apply is supposed to round down period (requested: %llu, applied: %llu)\n",
 			 state->period, s2.period);
 
 	if (state->enabled &&
@@ -524,14 +524,14 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 	    last->duty_cycle > s2.duty_cycle &&
 	    last->duty_cycle <= state->duty_cycle)
 		dev_warn(chip->dev,
-			 ".apply didn't pick the best available duty cycle (requested: %u/%u, applied: %u/%u, possible: %u/%u)\n",
+			 ".apply didn't pick the best available duty cycle (requested: %llu/%llu, applied: %llu/%llu, possible: %llu/%llu)\n",
 			 state->duty_cycle, state->period,
 			 s2.duty_cycle, s2.period,
 			 last->duty_cycle, last->period);
 
 	if (state->enabled && state->duty_cycle < s2.duty_cycle)
 		dev_warn(chip->dev,
-			 ".apply is supposed to round down duty_cycle (requested: %u/%u, applied: %u/%u)\n",
+			 ".apply is supposed to round down duty_cycle (requested: %llu/%llu, applied: %llu/%llu)\n",
 			 state->duty_cycle, state->period,
 			 s2.duty_cycle, s2.period);
 
@@ -558,7 +558,7 @@ static void pwm_apply_state_debug(struct pwm_device *pwm,
 	    (s1.enabled && s1.period != last->period) ||
 	    (s1.enabled && s1.duty_cycle != last->duty_cycle)) {
 		dev_err(chip->dev,
-			".apply is not idempotent (ena=%d pol=%d %u/%u) -> (ena=%d pol=%d %u/%u)\n",
+			".apply is not idempotent (ena=%d pol=%d %llu/%llu) -> (ena=%d pol=%d %llu/%llu)\n",
 			s1.enabled, s1.polarity, s1.duty_cycle, s1.period,
 			last->enabled, last->polarity, last->duty_cycle,
 			last->period);
@@ -1284,8 +1284,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
 		if (state.enabled)
 			seq_puts(s, " enabled");
 
-		seq_printf(s, " period: %u ns", state.period);
-		seq_printf(s, " duty: %u ns", state.duty_cycle);
+		seq_printf(s, " period: %llu ns", state.period);
+		seq_printf(s, " duty: %llu ns", state.duty_cycle);
 		seq_printf(s, " polarity: %s",
 			   state.polarity ? "inverse" : "normal");
 
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 67fca62..134c146 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	do_div(div, NSEC_PER_SEC);
 	if (!div) {
 		/* Clock is too slow to achieve requested period. */
-		dev_dbg(priv->chip.dev, "Can't reach %u ns\n",	state->period);
+		dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
 		return -EINVAL;
 	}
 
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 2389b86..449dbc0 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,
 
 	pwm_get_state(pwm, &state);
 
-	return sprintf(buf, "%u\n", state.period);
+	return sprintf(buf, "%llu\n", state.period);
 }
 
 static ssize_t period_store(struct device *child,
@@ -52,10 +52,10 @@ static ssize_t period_store(struct device *child,
 	struct pwm_export *export = child_to_pwm_export(child);
 	struct pwm_device *pwm = export->pwm;
 	struct pwm_state state;
-	unsigned int val;
+	u64 val;
 	int ret;
 
-	ret = kstrtouint(buf, 0, &val);
+	ret = kstrtou64(buf, 0, &val);
 	if (ret)
 		return ret;
 
@@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,
 
 	pwm_get_state(pwm, &state);
 
-	return sprintf(buf, "%u\n", state.duty_cycle);
+	return sprintf(buf, "%llu\n", state.duty_cycle);
 }
 
 static ssize_t duty_cycle_store(struct device *child,
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 2635b2a..a13ff38 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -39,7 +39,7 @@ enum pwm_polarity {
  * current PWM hardware state.
  */
 struct pwm_args {
-	unsigned int period;
+	u64 period;
 	enum pwm_polarity polarity;
 };
 
@@ -56,8 +56,8 @@ enum {
  * @enabled: PWM enabled status
  */
 struct pwm_state {
-	unsigned int period;
-	unsigned int duty_cycle;
+	u64 period;
+	u64 duty_cycle;
 	enum pwm_polarity polarity;
 	bool enabled;
 };
@@ -107,13 +107,13 @@ static inline bool pwm_is_enabled(const struct pwm_device *pwm)
 	return state.enabled;
 }
 
-static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
+static inline void pwm_set_period(struct pwm_device *pwm, u64 period)
 {
 	if (pwm)
 		pwm->state.period = period;
 }
 
-static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
+static inline u64 pwm_get_period(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
@@ -128,7 +128,7 @@ static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int duty)
 		pwm->state.duty_cycle = duty;
 }
 
-static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
+static inline u64 pwm_get_duty_cycle(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v13 11/11] pwm: core: Convert period and duty cycle to u64

[Uwe Kleine-König]

On Tue, Apr 21, 2020 at 07:57:23PM -0700, Guru Das Srinagesh wrote:
> Because period and duty cycle are defined as ints with units of
> nanoseconds, the maximum time duration that can be set is limited to
> ~2.147 seconds. Change their definitions to u64 in the structs of the
> PWM framework so that higher durations may be set.
> 
> Also use the right format specifiers in debug prints in both core.c as
> well as pwm-stm32-lp.c.
> 
> Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Joe Perches <joe@perches.com>
> 
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>

I like this change in general. I didn't check all the prepatory patches
in detail but the few I glanced over looked ok.

I think we have to prepare for having to fix a few fallouts but consider
it ok to expose this in next (but wouldn't send it for 5.8-rc1 yet).

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.

Has there been a positive maintainer review of patch 11 at any point in
the thread (most of the people you are asking to commit patches have
not been able to see the discussion about the actual feature these
patches are preparing for)?


Daniel.

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.

Has there been a positive maintainer review of patch 11 at any point in
the thread (most of the people you are asking to commit patches have
not been able to see the discussion about the actual feature these
patches are preparing for)?


Daniel.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.

Has there been a positive maintainer review of patch 11 at any point in
the thread (most of the people you are asking to commit patches have
not been able to see the discussion about the actual feature these
patches are preparing for)?


Daniel.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.

Has there been a positive maintainer review of patch 11 at any point in
the thread (most of the people you are asking to commit patches have
not been able to see the discussion about the actual feature these
patches are preparing for)?


Daniel.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > [REQUEST]
> > 
> > Would it be possible for the patches that have already received Acked-by's in
> > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > intel-panel.c) because it had a merge conflict with a new change that came in
> > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > opposed to the entire series en masse, but this event has got me thinking.
> 
> Has there been a positive maintainer review of patch 11 at any point in
> the thread (most of the people you are asking to commit patches have
> not been able to see the discussion about the actual feature these
> patches are preparing for)?

Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
which is essentially unchanged in this patchset save the dropping of the
pwm_capture change.

[1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Thank you.

Guru Das.

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > [REQUEST]
> > 
> > Would it be possible for the patches that have already received Acked-by's in
> > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > intel-panel.c) because it had a merge conflict with a new change that came in
> > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > opposed to the entire series en masse, but this event has got me thinking.
> 
> Has there been a positive maintainer review of patch 11 at any point in
> the thread (most of the people you are asking to commit patches have
> not been able to see the discussion about the actual feature these
> patches are preparing for)?

Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
which is essentially unchanged in this patchset save the dropping of the
pwm_capture change.

[1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Thank you.

Guru Das.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > [REQUEST]
> > 
> > Would it be possible for the patches that have already received Acked-by's in
> > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > intel-panel.c) because it had a merge conflict with a new change that came in
> > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > opposed to the entire series en masse, but this event has got me thinking.
> 
> Has there been a positive maintainer review of patch 11 at any point in
> the thread (most of the people you are asking to commit patches have
> not been able to see the discussion about the actual feature these
> patches are preparing for)?

Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
which is essentially unchanged in this patchset save the dropping of the
pwm_capture change.

[1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Thank you.

Guru Das.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > [REQUEST]
> > 
> > Would it be possible for the patches that have already received Acked-by's in
> > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > intel-panel.c) because it had a merge conflict with a new change that came in
> > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > opposed to the entire series en masse, but this event has got me thinking.
> 
> Has there been a positive maintainer review of patch 11 at any point in
> the thread (most of the people you are asking to commit patches have
> not been able to see the discussion about the actual feature these
> patches are preparing for)?

Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
which is essentially unchanged in this patchset save the dropping of the
pwm_capture change.

[1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Thank you.

Guru Das.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Wed, Apr 22, 2020 at 04:37:55PM -0700, Guru Das Srinagesh wrote:
> On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> > On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > > [REQUEST]
> > > 
> > > Would it be possible for the patches that have already received Acked-by's in
> > > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > > intel-panel.c) because it had a merge conflict with a new change that came in
> > > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > > opposed to the entire series en masse, but this event has got me thinking.
> > 
> > Has there been a positive maintainer review of patch 11 at any point in
> > the thread (most of the people you are asking to commit patches have
> > not been able to see the discussion about the actual feature these
> > patches are preparing for)?
> 
> Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
> which is essentially unchanged in this patchset save the dropping of the
> pwm_capture change.
> 
> [1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Excellent. Thanks!


Daniel.

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Wed, Apr 22, 2020 at 04:37:55PM -0700, Guru Das Srinagesh wrote:
> On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> > On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > > [REQUEST]
> > > 
> > > Would it be possible for the patches that have already received Acked-by's in
> > > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > > intel-panel.c) because it had a merge conflict with a new change that came in
> > > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > > opposed to the entire series en masse, but this event has got me thinking.
> > 
> > Has there been a positive maintainer review of patch 11 at any point in
> > the thread (most of the people you are asking to commit patches have
> > not been able to see the discussion about the actual feature these
> > patches are preparing for)?
> 
> Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
> which is essentially unchanged in this patchset save the dropping of the
> pwm_capture change.
> 
> [1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Excellent. Thanks!


Daniel.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Wed, Apr 22, 2020 at 04:37:55PM -0700, Guru Das Srinagesh wrote:
> On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> > On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > > [REQUEST]
> > > 
> > > Would it be possible for the patches that have already received Acked-by's in
> > > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > > intel-panel.c) because it had a merge conflict with a new change that came in
> > > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > > opposed to the entire series en masse, but this event has got me thinking.
> > 
> > Has there been a positive maintainer review of patch 11 at any point in
> > the thread (most of the people you are asking to commit patches have
> > not been able to see the discussion about the actual feature these
> > patches are preparing for)?
> 
> Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
> which is essentially unchanged in this patchset save the dropping of the
> pwm_capture change.
> 
> [1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Excellent. Thanks!


Daniel.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Daniel Thompson]

On Wed, Apr 22, 2020 at 04:37:55PM -0700, Guru Das Srinagesh wrote:
> On Wed, Apr 22, 2020 at 09:49:34AM +0100, Daniel Thompson wrote:
> > On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> > > [REQUEST]
> > > 
> > > Would it be possible for the patches that have already received Acked-by's in
> > > this series to be accepted and applied to the tree? I lost an Acked-by (in
> > > intel-panel.c) because it had a merge conflict with a new change that came in
> > > after I rebased to tip. I wasn't sure earlier about accepting single patches as
> > > opposed to the entire series en masse, but this event has got me thinking.
> > 
> > Has there been a positive maintainer review of patch 11 at any point in
> > the thread (most of the people you are asking to commit patches have
> > not been able to see the discussion about the actual feature these
> > patches are preparing for)?
> 
> Yes. Uwe had this to say [1] about a previous patchset (v5) of patch 11
> which is essentially unchanged in this patchset save the dropping of the
> pwm_capture change.
> 
> [1] https://www.spinics.net/lists/linux-pwm/msg11536.html

Excellent. Thanks!


Daniel.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.

What's the merge plan for this set?

FYI, it's better to send all patches to all parties.  That way
maintainers and interested persons can follow the discussion and
progress, or lack there of.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.

What's the merge plan for this set?

FYI, it's better to send all patches to all parties.  That way
maintainers and interested persons can follow the discussion and
progress, or lack there of.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.

What's the merge plan for this set?

FYI, it's better to send all patches to all parties.  That way
maintainers and interested persons can follow the discussion and
progress, or lack there of.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.

What's the merge plan for this set?

FYI, it's better to send all patches to all parties.  That way
maintainers and interested persons can follow the discussion and
progress, or lack there of.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> What's the merge plan for this set?

I'm not sure what you mean. My assumption is that first all the patches
need to get an Acked-by and only then will the series get applied by
Thierry... Could Thierry or Uwe weigh in on this point please?

> FYI, it's better to send all patches to all parties.  That way
> maintainers and interested persons can follow the discussion and
> progress, or lack there of.

Something I noticed with adding all the various mailing lists to the CC
list for this cover letter is that it is causing this cover letter email
and all its replies to not be archived properly on spinics or lore -
it's probably getting rejected by email filters somehow. Compare with
v12 [1] where I'd pruned the list considerably as an experiment - that
got archived correctly.

Any ideas on what might be going wrong? Once I fix this I can add all
parties to all patches knowing that there would be no issues in mail
archival.

[1] https://www.spinics.net/lists/linux-pwm/msg12131.html

Thank you.

Guru Das.

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> What's the merge plan for this set?

I'm not sure what you mean. My assumption is that first all the patches
need to get an Acked-by and only then will the series get applied by
Thierry... Could Thierry or Uwe weigh in on this point please?

> FYI, it's better to send all patches to all parties.  That way
> maintainers and interested persons can follow the discussion and
> progress, or lack there of.

Something I noticed with adding all the various mailing lists to the CC
list for this cover letter is that it is causing this cover letter email
and all its replies to not be archived properly on spinics or lore -
it's probably getting rejected by email filters somehow. Compare with
v12 [1] where I'd pruned the list considerably as an experiment - that
got archived correctly.

Any ideas on what might be going wrong? Once I fix this I can add all
parties to all patches knowing that there would be no issues in mail
archival.

[1] https://www.spinics.net/lists/linux-pwm/msg12131.html

Thank you.

Guru Das.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> What's the merge plan for this set?

I'm not sure what you mean. My assumption is that first all the patches
need to get an Acked-by and only then will the series get applied by
Thierry... Could Thierry or Uwe weigh in on this point please?

> FYI, it's better to send all patches to all parties.  That way
> maintainers and interested persons can follow the discussion and
> progress, or lack there of.

Something I noticed with adding all the various mailing lists to the CC
list for this cover letter is that it is causing this cover letter email
and all its replies to not be archived properly on spinics or lore -
it's probably getting rejected by email filters somehow. Compare with
v12 [1] where I'd pruned the list considerably as an experiment - that
got archived correctly.

Any ideas on what might be going wrong? Once I fix this I can add all
parties to all patches knowing that there would be no issues in mail
archival.

[1] https://www.spinics.net/lists/linux-pwm/msg12131.html

Thank you.

Guru Das.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> What's the merge plan for this set?

I'm not sure what you mean. My assumption is that first all the patches
need to get an Acked-by and only then will the series get applied by
Thierry... Could Thierry or Uwe weigh in on this point please?

> FYI, it's better to send all patches to all parties.  That way
> maintainers and interested persons can follow the discussion and
> progress, or lack there of.

Something I noticed with adding all the various mailing lists to the CC
list for this cover letter is that it is causing this cover letter email
and all its replies to not be archived properly on spinics or lore -
it's probably getting rejected by email filters somehow. Compare with
v12 [1] where I'd pruned the list considerably as an experiment - that
got archived correctly.

Any ideas on what might be going wrong? Once I fix this I can add all
parties to all patches knowing that there would be no issues in mail
archival.

[1] https://www.spinics.net/lists/linux-pwm/msg12131.html

Thank you.

Guru Das.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?
> 
> > FYI, it's better to send all patches to all parties.  That way
> > maintainers and interested persons can follow the discussion and
> > progress, or lack there of.
> 
> Something I noticed with adding all the various mailing lists to the CC
> list for this cover letter is that it is causing this cover letter email
> and all its replies to not be archived properly on spinics or lore -
> it's probably getting rejected by email filters somehow. Compare with
> v12 [1] where I'd pruned the list considerably as an experiment - that
> got archived correctly.
> 
> Any ideas on what might be going wrong? Once I fix this I can add all
> parties to all patches knowing that there would be no issues in mail
> archival.

A great deal of mailing lists contain numerous protections against
things like flooding and spamming.  One of those protections is a
check for "Too many recipients to the message".  Most of the time this
simply requires moderator intervention by way of review and approval,
but this ultimately depends on the ML's configuration.

The first thing to ascertain is why your recipients list is so large.
Have you added every reviewer, subsystem-maintainer, maintainer and
contributor suggested by get-maintainer.pl?  If so, consider pruning
that a little.  Contributors do not tend to care about subsequent
changes to a file.  As someone who receives a lot of patches, I tend
to get fed-up when receiving patches simply because I made a change X
years ago.  Stick to listed maintainers/reviewers in the first
instance and see how far that takes you.

If your recipients list is as succinct as reasonably possible, maybe
just accept that every version isn't going to be archived by every
ML.  It's still much more useful for the correct people to have
visibility into the set than for it to be archived multiple times.

> [1] https://www.spinics.net/lists/linux-pwm/msg12131.html
> 
> Thank you.
> 
> Guru Das.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?
> 
> > FYI, it's better to send all patches to all parties.  That way
> > maintainers and interested persons can follow the discussion and
> > progress, or lack there of.
> 
> Something I noticed with adding all the various mailing lists to the CC
> list for this cover letter is that it is causing this cover letter email
> and all its replies to not be archived properly on spinics or lore -
> it's probably getting rejected by email filters somehow. Compare with
> v12 [1] where I'd pruned the list considerably as an experiment - that
> got archived correctly.
> 
> Any ideas on what might be going wrong? Once I fix this I can add all
> parties to all patches knowing that there would be no issues in mail
> archival.

A great deal of mailing lists contain numerous protections against
things like flooding and spamming.  One of those protections is a
check for "Too many recipients to the message".  Most of the time this
simply requires moderator intervention by way of review and approval,
but this ultimately depends on the ML's configuration.

The first thing to ascertain is why your recipients list is so large.
Have you added every reviewer, subsystem-maintainer, maintainer and
contributor suggested by get-maintainer.pl?  If so, consider pruning
that a little.  Contributors do not tend to care about subsequent
changes to a file.  As someone who receives a lot of patches, I tend
to get fed-up when receiving patches simply because I made a change X
years ago.  Stick to listed maintainers/reviewers in the first
instance and see how far that takes you.

If your recipients list is as succinct as reasonably possible, maybe
just accept that every version isn't going to be archived by every
ML.  It's still much more useful for the correct people to have
visibility into the set than for it to be archived multiple times.

> [1] https://www.spinics.net/lists/linux-pwm/msg12131.html
> 
> Thank you.
> 
> Guru Das.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?
> 
> > FYI, it's better to send all patches to all parties.  That way
> > maintainers and interested persons can follow the discussion and
> > progress, or lack there of.
> 
> Something I noticed with adding all the various mailing lists to the CC
> list for this cover letter is that it is causing this cover letter email
> and all its replies to not be archived properly on spinics or lore -
> it's probably getting rejected by email filters somehow. Compare with
> v12 [1] where I'd pruned the list considerably as an experiment - that
> got archived correctly.
> 
> Any ideas on what might be going wrong? Once I fix this I can add all
> parties to all patches knowing that there would be no issues in mail
> archival.

A great deal of mailing lists contain numerous protections against
things like flooding and spamming.  One of those protections is a
check for "Too many recipients to the message".  Most of the time this
simply requires moderator intervention by way of review and approval,
but this ultimately depends on the ML's configuration.

The first thing to ascertain is why your recipients list is so large.
Have you added every reviewer, subsystem-maintainer, maintainer and
contributor suggested by get-maintainer.pl?  If so, consider pruning
that a little.  Contributors do not tend to care about subsequent
changes to a file.  As someone who receives a lot of patches, I tend
to get fed-up when receiving patches simply because I made a change X
years ago.  Stick to listed maintainers/reviewers in the first
instance and see how far that takes you.

If your recipients list is as succinct as reasonably possible, maybe
just accept that every version isn't going to be archived by every
ML.  It's still much more useful for the correct people to have
visibility into the set than for it to be archived multiple times.

> [1] https://www.spinics.net/lists/linux-pwm/msg12131.html
> 
> Thank you.
> 
> Guru Das.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?
> 
> > FYI, it's better to send all patches to all parties.  That way
> > maintainers and interested persons can follow the discussion and
> > progress, or lack there of.
> 
> Something I noticed with adding all the various mailing lists to the CC
> list for this cover letter is that it is causing this cover letter email
> and all its replies to not be archived properly on spinics or lore -
> it's probably getting rejected by email filters somehow. Compare with
> v12 [1] where I'd pruned the list considerably as an experiment - that
> got archived correctly.
> 
> Any ideas on what might be going wrong? Once I fix this I can add all
> parties to all patches knowing that there would be no issues in mail
> archival.

A great deal of mailing lists contain numerous protections against
things like flooding and spamming.  One of those protections is a
check for "Too many recipients to the message".  Most of the time this
simply requires moderator intervention by way of review and approval,
but this ultimately depends on the ML's configuration.

The first thing to ascertain is why your recipients list is so large.
Have you added every reviewer, subsystem-maintainer, maintainer and
contributor suggested by get-maintainer.pl?  If so, consider pruning
that a little.  Contributors do not tend to care about subsequent
changes to a file.  As someone who receives a lot of patches, I tend
to get fed-up when receiving patches simply because I made a change X
years ago.  Stick to listed maintainers/reviewers in the first
instance and see how far that takes you.

If your recipients list is as succinct as reasonably possible, maybe
just accept that every version isn't going to be archived by every
ML.  It's still much more useful for the correct people to have
visibility into the set than for it to be archived multiple times.

> [1] https://www.spinics.net/lists/linux-pwm/msg12131.html
> 
> Thank you.
> 
> Guru Das.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> A great deal of mailing lists contain numerous protections against
> things like flooding and spamming.  One of those protections is a
> check for "Too many recipients to the message".  Most of the time this
> simply requires moderator intervention by way of review and approval,
> but this ultimately depends on the ML's configuration.
> 
> The first thing to ascertain is why your recipients list is so large.
> Have you added every reviewer, subsystem-maintainer, maintainer and
> contributor suggested by get-maintainer.pl?  If so, consider pruning
> that a little.  Contributors do not tend to care about subsequent
> changes to a file.  As someone who receives a lot of patches, I tend
> to get fed-up when receiving patches simply because I made a change X
> years ago.  Stick to listed maintainers/reviewers in the first
> instance and see how far that takes you.

Thank you for the detailed reply. I did this in the first few patchsets
and then when a few patches didn't get any attention, expanded the
audience thus. Still, around 50% of the patches in this series remain
unreviewed by anyone.

> If your recipients list is as succinct as reasonably possible, maybe
> just accept that every version isn't going to be archived by every
> ML.  It's still much more useful for the correct people to have
> visibility into the set than for it to be archived multiple times.

Thank you, will prune the list and remove past contributors from the
Cc-list and add all parties to all patches.

Thank you.

Guru Das.

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> A great deal of mailing lists contain numerous protections against
> things like flooding and spamming.  One of those protections is a
> check for "Too many recipients to the message".  Most of the time this
> simply requires moderator intervention by way of review and approval,
> but this ultimately depends on the ML's configuration.
> 
> The first thing to ascertain is why your recipients list is so large.
> Have you added every reviewer, subsystem-maintainer, maintainer and
> contributor suggested by get-maintainer.pl?  If so, consider pruning
> that a little.  Contributors do not tend to care about subsequent
> changes to a file.  As someone who receives a lot of patches, I tend
> to get fed-up when receiving patches simply because I made a change X
> years ago.  Stick to listed maintainers/reviewers in the first
> instance and see how far that takes you.

Thank you for the detailed reply. I did this in the first few patchsets
and then when a few patches didn't get any attention, expanded the
audience thus. Still, around 50% of the patches in this series remain
unreviewed by anyone.

> If your recipients list is as succinct as reasonably possible, maybe
> just accept that every version isn't going to be archived by every
> ML.  It's still much more useful for the correct people to have
> visibility into the set than for it to be archived multiple times.

Thank you, will prune the list and remove past contributors from the
Cc-list and add all parties to all patches.

Thank you.

Guru Das.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> A great deal of mailing lists contain numerous protections against
> things like flooding and spamming.  One of those protections is a
> check for "Too many recipients to the message".  Most of the time this
> simply requires moderator intervention by way of review and approval,
> but this ultimately depends on the ML's configuration.
> 
> The first thing to ascertain is why your recipients list is so large.
> Have you added every reviewer, subsystem-maintainer, maintainer and
> contributor suggested by get-maintainer.pl?  If so, consider pruning
> that a little.  Contributors do not tend to care about subsequent
> changes to a file.  As someone who receives a lot of patches, I tend
> to get fed-up when receiving patches simply because I made a change X
> years ago.  Stick to listed maintainers/reviewers in the first
> instance and see how far that takes you.

Thank you for the detailed reply. I did this in the first few patchsets
and then when a few patches didn't get any attention, expanded the
audience thus. Still, around 50% of the patches in this series remain
unreviewed by anyone.

> If your recipients list is as succinct as reasonably possible, maybe
> just accept that every version isn't going to be archived by every
> ML.  It's still much more useful for the correct people to have
> visibility into the set than for it to be archived multiple times.

Thank you, will prune the list and remove past contributors from the
Cc-list and add all parties to all patches.

Thank you.

Guru Das.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> A great deal of mailing lists contain numerous protections against
> things like flooding and spamming.  One of those protections is a
> check for "Too many recipients to the message".  Most of the time this
> simply requires moderator intervention by way of review and approval,
> but this ultimately depends on the ML's configuration.
> 
> The first thing to ascertain is why your recipients list is so large.
> Have you added every reviewer, subsystem-maintainer, maintainer and
> contributor suggested by get-maintainer.pl?  If so, consider pruning
> that a little.  Contributors do not tend to care about subsequent
> changes to a file.  As someone who receives a lot of patches, I tend
> to get fed-up when receiving patches simply because I made a change X
> years ago.  Stick to listed maintainers/reviewers in the first
> instance and see how far that takes you.

Thank you for the detailed reply. I did this in the first few patchsets
and then when a few patches didn't get any attention, expanded the
audience thus. Still, around 50% of the patches in this series remain
unreviewed by anyone.

> If your recipients list is as succinct as reasonably possible, maybe
> just accept that every version isn't going to be archived by every
> ML.  It's still much more useful for the correct people to have
> visibility into the set than for it to be archived multiple times.

Thank you, will prune the list and remove past contributors from the
Cc-list and add all parties to all patches.

Thank you.

Guru Das.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:

> On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > A great deal of mailing lists contain numerous protections against
> > things like flooding and spamming.  One of those protections is a
> > check for "Too many recipients to the message".  Most of the time this
> > simply requires moderator intervention by way of review and approval,
> > but this ultimately depends on the ML's configuration.
> > 
> > The first thing to ascertain is why your recipients list is so large.
> > Have you added every reviewer, subsystem-maintainer, maintainer and
> > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > that a little.  Contributors do not tend to care about subsequent
> > changes to a file.  As someone who receives a lot of patches, I tend
> > to get fed-up when receiving patches simply because I made a change X
> > years ago.  Stick to listed maintainers/reviewers in the first
> > instance and see how far that takes you.
> 
> Thank you for the detailed reply. I did this in the first few patchsets
> and then when a few patches didn't get any attention, expanded the
> audience thus. Still, around 50% of the patches in this series remain
> unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care
even less than your original group).  However it *is* a good argument
for including all of the specified maintainers/reviewers in on all of
the patches.

> > If your recipients list is as succinct as reasonably possible, maybe
> > just accept that every version isn't going to be archived by every
> > ML.  It's still much more useful for the correct people to have
> > visibility into the set than for it to be archived multiple times.
> 
> Thank you, will prune the list and remove past contributors from the
> Cc-list and add all parties to all patches.

Great.  Once you've done that, we can start to help you acquire the
Acks you need on your remaining patches.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:

> On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > A great deal of mailing lists contain numerous protections against
> > things like flooding and spamming.  One of those protections is a
> > check for "Too many recipients to the message".  Most of the time this
> > simply requires moderator intervention by way of review and approval,
> > but this ultimately depends on the ML's configuration.
> > 
> > The first thing to ascertain is why your recipients list is so large.
> > Have you added every reviewer, subsystem-maintainer, maintainer and
> > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > that a little.  Contributors do not tend to care about subsequent
> > changes to a file.  As someone who receives a lot of patches, I tend
> > to get fed-up when receiving patches simply because I made a change X
> > years ago.  Stick to listed maintainers/reviewers in the first
> > instance and see how far that takes you.
> 
> Thank you for the detailed reply. I did this in the first few patchsets
> and then when a few patches didn't get any attention, expanded the
> audience thus. Still, around 50% of the patches in this series remain
> unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care
even less than your original group).  However it *is* a good argument
for including all of the specified maintainers/reviewers in on all of
the patches.

> > If your recipients list is as succinct as reasonably possible, maybe
> > just accept that every version isn't going to be archived by every
> > ML.  It's still much more useful for the correct people to have
> > visibility into the set than for it to be archived multiple times.
> 
> Thank you, will prune the list and remove past contributors from the
> Cc-list and add all parties to all patches.

Great.  Once you've done that, we can start to help you acquire the
Acks you need on your remaining patches.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:

> On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > A great deal of mailing lists contain numerous protections against
> > things like flooding and spamming.  One of those protections is a
> > check for "Too many recipients to the message".  Most of the time this
> > simply requires moderator intervention by way of review and approval,
> > but this ultimately depends on the ML's configuration.
> > 
> > The first thing to ascertain is why your recipients list is so large.
> > Have you added every reviewer, subsystem-maintainer, maintainer and
> > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > that a little.  Contributors do not tend to care about subsequent
> > changes to a file.  As someone who receives a lot of patches, I tend
> > to get fed-up when receiving patches simply because I made a change X
> > years ago.  Stick to listed maintainers/reviewers in the first
> > instance and see how far that takes you.
> 
> Thank you for the detailed reply. I did this in the first few patchsets
> and then when a few patches didn't get any attention, expanded the
> audience thus. Still, around 50% of the patches in this series remain
> unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care
even less than your original group).  However it *is* a good argument
for including all of the specified maintainers/reviewers in on all of
the patches.

> > If your recipients list is as succinct as reasonably possible, maybe
> > just accept that every version isn't going to be archived by every
> > ML.  It's still much more useful for the correct people to have
> > visibility into the set than for it to be archived multiple times.
> 
> Thank you, will prune the list and remove past contributors from the
> Cc-list and add all parties to all patches.

Great.  Once you've done that, we can start to help you acquire the
Acks you need on your remaining patches.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:

> On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > A great deal of mailing lists contain numerous protections against
> > things like flooding and spamming.  One of those protections is a
> > check for "Too many recipients to the message".  Most of the time this
> > simply requires moderator intervention by way of review and approval,
> > but this ultimately depends on the ML's configuration.
> > 
> > The first thing to ascertain is why your recipients list is so large.
> > Have you added every reviewer, subsystem-maintainer, maintainer and
> > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > that a little.  Contributors do not tend to care about subsequent
> > changes to a file.  As someone who receives a lot of patches, I tend
> > to get fed-up when receiving patches simply because I made a change X
> > years ago.  Stick to listed maintainers/reviewers in the first
> > instance and see how far that takes you.
> 
> Thank you for the detailed reply. I did this in the first few patchsets
> and then when a few patches didn't get any attention, expanded the
> audience thus. Still, around 50% of the patches in this series remain
> unreviewed by anyone.

This isn't a reason to add more recipients (who are likely to care
even less than your original group).  However it *is* a good argument
for including all of the specified maintainers/reviewers in on all of
the patches.

> > If your recipients list is as succinct as reasonably possible, maybe
> > just accept that every version isn't going to be archived by every
> > ML.  It's still much more useful for the correct people to have
> > visibility into the set than for it to be archived multiple times.
> 
> Thank you, will prune the list and remove past contributors from the
> Cc-list and add all parties to all patches.

Great.  Once you've done that, we can start to help you acquire the
Acks you need on your remaining patches.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> 
> > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > A great deal of mailing lists contain numerous protections against
> > > things like flooding and spamming.  One of those protections is a
> > > check for "Too many recipients to the message".  Most of the time this
> > > simply requires moderator intervention by way of review and approval,
> > > but this ultimately depends on the ML's configuration.
> > > 
> > > The first thing to ascertain is why your recipients list is so large.
> > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > that a little.  Contributors do not tend to care about subsequent
> > > changes to a file.  As someone who receives a lot of patches, I tend
> > > to get fed-up when receiving patches simply because I made a change X
> > > years ago.  Stick to listed maintainers/reviewers in the first
> > > instance and see how far that takes you.
> > 
> > Thank you for the detailed reply. I did this in the first few patchsets
> > and then when a few patches didn't get any attention, expanded the
> > audience thus. Still, around 50% of the patches in this series remain
> > unreviewed by anyone.
> 
> This isn't a reason to add more recipients (who are likely to care
> even less than your original group).  However it *is* a good argument
> for including all of the specified maintainers/reviewers in on all of
> the patches.
> 
> > > If your recipients list is as succinct as reasonably possible, maybe
> > > just accept that every version isn't going to be archived by every
> > > ML.  It's still much more useful for the correct people to have
> > > visibility into the set than for it to be archived multiple times.
> > 
> > Thank you, will prune the list and remove past contributors from the
> > Cc-list and add all parties to all patches.
> 
> Great.  Once you've done that, we can start to help you acquire the
> Acks you need on your remaining patches.

Hi Lee, Thierry, Uwe,

In v14 of this patchset I've pruned the list of contributors, removed
past contributors from the cc-list, and added all parties to all patches
(except for the patches that are yet to reviewed, for which I've added
what get_maintainer.pl showed me). I've also resent v14 a couple of
times already, with around a week's time interval between resends, and
somehow it seems like this set has lost traction.

Could you please indicate what next steps I should take to have more
eyes on the unreviewed patches? Only 4 out of 11 patches remain
unreviewed.

Thank you.

Guru Das.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Wed, 20 May 2020, Guru Das Srinagesh wrote:

> On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > 
> > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > A great deal of mailing lists contain numerous protections against
> > > > things like flooding and spamming.  One of those protections is a
> > > > check for "Too many recipients to the message".  Most of the time this
> > > > simply requires moderator intervention by way of review and approval,
> > > > but this ultimately depends on the ML's configuration.
> > > > 
> > > > The first thing to ascertain is why your recipients list is so large.
> > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > that a little.  Contributors do not tend to care about subsequent
> > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > to get fed-up when receiving patches simply because I made a change X
> > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > instance and see how far that takes you.
> > > 
> > > Thank you for the detailed reply. I did this in the first few patchsets
> > > and then when a few patches didn't get any attention, expanded the
> > > audience thus. Still, around 50% of the patches in this series remain
> > > unreviewed by anyone.
> > 
> > This isn't a reason to add more recipients (who are likely to care
> > even less than your original group).  However it *is* a good argument
> > for including all of the specified maintainers/reviewers in on all of
> > the patches.
> > 
> > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > just accept that every version isn't going to be archived by every
> > > > ML.  It's still much more useful for the correct people to have
> > > > visibility into the set than for it to be archived multiple times.
> > > 
> > > Thank you, will prune the list and remove past contributors from the
> > > Cc-list and add all parties to all patches.
> > 
> > Great.  Once you've done that, we can start to help you acquire the
> > Acks you need on your remaining patches.
> 
> Hi Lee, Thierry, Uwe,
> 
> In v14 of this patchset I've pruned the list of contributors, removed
> past contributors from the cc-list, and added all parties to all patches
> (except for the patches that are yet to reviewed, for which I've added
> what get_maintainer.pl showed me). I've also resent v14 a couple of
> times already, with around a week's time interval between resends, and
> somehow it seems like this set has lost traction.
> 
> Could you please indicate what next steps I should take to have more
> eyes on the unreviewed patches? Only 4 out of 11 patches remain
> unreviewed.

Looks like we're waiting on Thierry (again).

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4189 bytes --]

On Thu, May 21, 2020 at 08:15:05AM +0100, Lee Jones wrote:
> On Wed, 20 May 2020, Guru Das Srinagesh wrote:
> 
> > On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > > 
> > > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > > A great deal of mailing lists contain numerous protections against
> > > > > things like flooding and spamming.  One of those protections is a
> > > > > check for "Too many recipients to the message".  Most of the time this
> > > > > simply requires moderator intervention by way of review and approval,
> > > > > but this ultimately depends on the ML's configuration.
> > > > > 
> > > > > The first thing to ascertain is why your recipients list is so large.
> > > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > > that a little.  Contributors do not tend to care about subsequent
> > > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > > to get fed-up when receiving patches simply because I made a change X
> > > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > > instance and see how far that takes you.
> > > > 
> > > > Thank you for the detailed reply. I did this in the first few patchsets
> > > > and then when a few patches didn't get any attention, expanded the
> > > > audience thus. Still, around 50% of the patches in this series remain
> > > > unreviewed by anyone.
> > > 
> > > This isn't a reason to add more recipients (who are likely to care
> > > even less than your original group).  However it *is* a good argument
> > > for including all of the specified maintainers/reviewers in on all of
> > > the patches.
> > > 
> > > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > > just accept that every version isn't going to be archived by every
> > > > > ML.  It's still much more useful for the correct people to have
> > > > > visibility into the set than for it to be archived multiple times.
> > > > 
> > > > Thank you, will prune the list and remove past contributors from the
> > > > Cc-list and add all parties to all patches.
> > > 
> > > Great.  Once you've done that, we can start to help you acquire the
> > > Acks you need on your remaining patches.
> > 
> > Hi Lee, Thierry, Uwe,
> > 
> > In v14 of this patchset I've pruned the list of contributors, removed
> > past contributors from the cc-list, and added all parties to all patches
> > (except for the patches that are yet to reviewed, for which I've added
> > what get_maintainer.pl showed me). I've also resent v14 a couple of
> > times already, with around a week's time interval between resends, and
> > somehow it seems like this set has lost traction.
> > 
> > Could you please indicate what next steps I should take to have more
> > eyes on the unreviewed patches? Only 4 out of 11 patches remain
> > unreviewed.
> 
> Looks like we're waiting on Thierry (again).
> 
> This has been a common theme over the past few months.
> 
> Perhaps he has changed employer/project?

My work on PWM is purely done in my spare time. I don't get paid for any
of it. I currently have two kids that need home-schooling, as many
others probably do, and I have a full time job doing non-PWM related
things. As a result my spare time is close to nil these days.

I very much appreciate all the effort that others have spent in getting
this reviewed. I haven't been able to keep a very close eye on this, but
even the latest versions have some comments, so I didn't consider this
ready yet. If that's changed and everybody's okay with the changes, then
I can apply this to for-next. We haven't got all that much time left
before the merge window and I had hoped this would be ready earlier so
that we'd have more time for this in linux-next. But I'd be willing to
at least give it a try. If it starts to look like there are going to be
issues with this I can always back them out and we can have another go
next release.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Fri, 22 May 2020, Thierry Reding wrote:

> On Thu, May 21, 2020 at 08:15:05AM +0100, Lee Jones wrote:
> > On Wed, 20 May 2020, Guru Das Srinagesh wrote:
> > 
> > > On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > > > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > > > 
> > > > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > > > A great deal of mailing lists contain numerous protections against
> > > > > > things like flooding and spamming.  One of those protections is a
> > > > > > check for "Too many recipients to the message".  Most of the time this
> > > > > > simply requires moderator intervention by way of review and approval,
> > > > > > but this ultimately depends on the ML's configuration.
> > > > > > 
> > > > > > The first thing to ascertain is why your recipients list is so large.
> > > > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > > > that a little.  Contributors do not tend to care about subsequent
> > > > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > > > to get fed-up when receiving patches simply because I made a change X
> > > > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > > > instance and see how far that takes you.
> > > > > 
> > > > > Thank you for the detailed reply. I did this in the first few patchsets
> > > > > and then when a few patches didn't get any attention, expanded the
> > > > > audience thus. Still, around 50% of the patches in this series remain
> > > > > unreviewed by anyone.
> > > > 
> > > > This isn't a reason to add more recipients (who are likely to care
> > > > even less than your original group).  However it *is* a good argument
> > > > for including all of the specified maintainers/reviewers in on all of
> > > > the patches.
> > > > 
> > > > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > > > just accept that every version isn't going to be archived by every
> > > > > > ML.  It's still much more useful for the correct people to have
> > > > > > visibility into the set than for it to be archived multiple times.
> > > > > 
> > > > > Thank you, will prune the list and remove past contributors from the
> > > > > Cc-list and add all parties to all patches.
> > > > 
> > > > Great.  Once you've done that, we can start to help you acquire the
> > > > Acks you need on your remaining patches.
> > > 
> > > Hi Lee, Thierry, Uwe,
> > > 
> > > In v14 of this patchset I've pruned the list of contributors, removed
> > > past contributors from the cc-list, and added all parties to all patches
> > > (except for the patches that are yet to reviewed, for which I've added
> > > what get_maintainer.pl showed me). I've also resent v14 a couple of
> > > times already, with around a week's time interval between resends, and
> > > somehow it seems like this set has lost traction.
> > > 
> > > Could you please indicate what next steps I should take to have more
> > > eyes on the unreviewed patches? Only 4 out of 11 patches remain
> > > unreviewed.
> > 
> > Looks like we're waiting on Thierry (again).
> > 
> > This has been a common theme over the past few months.
> > 
> > Perhaps he has changed employer/project?
> 
> My work on PWM is purely done in my spare time. I don't get paid for any
> of it. I currently have two kids that need home-schooling, as many
> others probably do, and I have a full time job doing non-PWM related
> things. As a result my spare time is close to nil these days.

This is no different to many others.  I too am not paid for this work,
but it's still my responsibly to ensure a reply within a reasonable
amount of time.

We can all appreciate that the latest situation has exacerbated issues,
but a reasonable level of PWM participation, blocking various
patch-sets has been lacking for months before we'd even heard of
Covid-19 [0].

If you need help, just ask for it.  I am willing to step up and review
patches if you're overloaded.  Uwe is already listed as a designated
reviewer.  Perhaps between the 3 of us we can work something out in
order to reduce the latency.

[0] https://patchwork.ozlabs.org/project/linux-pwm/list/

> I very much appreciate all the effort that others have spent in getting
> this reviewed. I haven't been able to keep a very close eye on this, but
> even the latest versions have some comments, so I didn't consider this
> ready yet. If that's changed and everybody's okay with the changes, then
> I can apply this to for-next. We haven't got all that much time left
> before the merge window and I had hoped this would be ready earlier so
> that we'd have more time for this in linux-next. But I'd be willing to
> at least give it a try. If it starts to look like there are going to be
> issues with this I can always back them out and we can have another go
> next release.

If you would be so kind as to review the PWM patches, I can take them
in but I can't do anything without your Ack.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6706 bytes --]

On Fri, May 22, 2020 at 12:31:47PM +0100, Lee Jones wrote:
> On Fri, 22 May 2020, Thierry Reding wrote:
> 
> > On Thu, May 21, 2020 at 08:15:05AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2020, Guru Das Srinagesh wrote:
> > > 
> > > > On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > > > > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > > > > 
> > > > > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > > > > A great deal of mailing lists contain numerous protections against
> > > > > > > things like flooding and spamming.  One of those protections is a
> > > > > > > check for "Too many recipients to the message".  Most of the time this
> > > > > > > simply requires moderator intervention by way of review and approval,
> > > > > > > but this ultimately depends on the ML's configuration.
> > > > > > > 
> > > > > > > The first thing to ascertain is why your recipients list is so large.
> > > > > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > > > > that a little.  Contributors do not tend to care about subsequent
> > > > > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > > > > to get fed-up when receiving patches simply because I made a change X
> > > > > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > > > > instance and see how far that takes you.
> > > > > > 
> > > > > > Thank you for the detailed reply. I did this in the first few patchsets
> > > > > > and then when a few patches didn't get any attention, expanded the
> > > > > > audience thus. Still, around 50% of the patches in this series remain
> > > > > > unreviewed by anyone.
> > > > > 
> > > > > This isn't a reason to add more recipients (who are likely to care
> > > > > even less than your original group).  However it *is* a good argument
> > > > > for including all of the specified maintainers/reviewers in on all of
> > > > > the patches.
> > > > > 
> > > > > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > > > > just accept that every version isn't going to be archived by every
> > > > > > > ML.  It's still much more useful for the correct people to have
> > > > > > > visibility into the set than for it to be archived multiple times.
> > > > > > 
> > > > > > Thank you, will prune the list and remove past contributors from the
> > > > > > Cc-list and add all parties to all patches.
> > > > > 
> > > > > Great.  Once you've done that, we can start to help you acquire the
> > > > > Acks you need on your remaining patches.
> > > > 
> > > > Hi Lee, Thierry, Uwe,
> > > > 
> > > > In v14 of this patchset I've pruned the list of contributors, removed
> > > > past contributors from the cc-list, and added all parties to all patches
> > > > (except for the patches that are yet to reviewed, for which I've added
> > > > what get_maintainer.pl showed me). I've also resent v14 a couple of
> > > > times already, with around a week's time interval between resends, and
> > > > somehow it seems like this set has lost traction.
> > > > 
> > > > Could you please indicate what next steps I should take to have more
> > > > eyes on the unreviewed patches? Only 4 out of 11 patches remain
> > > > unreviewed.
> > > 
> > > Looks like we're waiting on Thierry (again).
> > > 
> > > This has been a common theme over the past few months.
> > > 
> > > Perhaps he has changed employer/project?
> > 
> > My work on PWM is purely done in my spare time. I don't get paid for any
> > of it. I currently have two kids that need home-schooling, as many
> > others probably do, and I have a full time job doing non-PWM related
> > things. As a result my spare time is close to nil these days.
> 
> This is no different to many others.  I too am not paid for this work,
> but it's still my responsibly to ensure a reply within a reasonable
> amount of time.

I realize that this is the same for many others. Still, you seemed to
suggest that the lack of time that I was able to spend on PWM was
somehow related to me changing employers, so I wanted to clarify that
this isn't 

> We can all appreciate that the latest situation has exacerbated issues,
> but a reasonable level of PWM participation, blocking various
> patch-sets has been lacking for months before we'd even heard of
> Covid-19 [0].

Covid-19 started to impact me around mid-March, and you'll see that
that's about the time that I stopped maintaining patchwork.

> If you need help, just ask for it.

Hm... who do you go and ask for help? Every maintainer I know is already
at least as busy as I am.

> I am willing to step up and review patches if you're overloaded. Uwe
> is already listed as a designated reviewer. Perhaps between the 3 of
> us we can work something out in order to reduce the latency.

That's very kind of you. Yes, I'd be willing to do this as a sort of
group maintenance, and perhaps even eventually step away from my role
as maintainer entirely if I think somebody else will do a better job.
I do still care about the PWM subsystem, having looked after it for a
couple of years, so I do want any hand-off to be somewhat orderly.

> [0] https://patchwork.ozlabs.org/project/linux-pwm/list/
> 
> > I very much appreciate all the effort that others have spent in getting
> > this reviewed. I haven't been able to keep a very close eye on this, but
> > even the latest versions have some comments, so I didn't consider this
> > ready yet. If that's changed and everybody's okay with the changes, then
> > I can apply this to for-next. We haven't got all that much time left
> > before the merge window and I had hoped this would be ready earlier so
> > that we'd have more time for this in linux-next. But I'd be willing to
> > at least give it a try. If it starts to look like there are going to be
> > issues with this I can always back them out and we can have another go
> > next release.
> 
> If you would be so kind as to review the PWM patches, I can take them
> in but I can't do anything without your Ack.

Looking at v14 I think there are no longer any discussions (looks like
the last comment I thought was from v14 was actually on v13 and it seems
to have been solved in v14 now) and there are Acked-bys for all the non-
PWM patches, so there's nothing in the way of me applying this to the
PWM tree. I can let it soak there for a few days and send out a stable
branch if anyone needs it if there aren't any huge issues.

Does that sound like a plan?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Fri, May 22, 2020 at 02:50:28PM +0200, Thierry Reding wrote:
> Looking at v14 I think there are no longer any discussions (looks like
> the last comment I thought was from v14 was actually on v13 and it seems
> to have been solved in v14 now) and there are Acked-bys for all the non-
> PWM patches, so there's nothing in the way of me applying this to the
> PWM tree. I can let it soak there for a few days and send out a stable
> branch if anyone needs it if there aren't any huge issues.
> 
> Does that sound like a plan?

There is one ongoing discussion on v14 [1]: Daniel just gave me some
comments on the clps711x.c patch that I will address in the next
patchset. The plan you outlined sounds good to me - just let me send out
v15 which you may then pick up.

[1] https://lore.kernel.org/lkml/20200521101934.j5ivjky4e6byveut@holly.lan/

Thank you.

Guru Das.

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Fri, 22 May 2020, Thierry Reding wrote:

> On Fri, May 22, 2020 at 12:31:47PM +0100, Lee Jones wrote:
> > On Fri, 22 May 2020, Thierry Reding wrote:
> > 
> > > On Thu, May 21, 2020 at 08:15:05AM +0100, Lee Jones wrote:
> > > > On Wed, 20 May 2020, Guru Das Srinagesh wrote:
> > > > 
> > > > > On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > > > > > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > > > > > 
> > > > > > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > > > > > A great deal of mailing lists contain numerous protections against
> > > > > > > > things like flooding and spamming.  One of those protections is a
> > > > > > > > check for "Too many recipients to the message".  Most of the time this
> > > > > > > > simply requires moderator intervention by way of review and approval,
> > > > > > > > but this ultimately depends on the ML's configuration.
> > > > > > > > 
> > > > > > > > The first thing to ascertain is why your recipients list is so large.
> > > > > > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > > > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > > > > > that a little.  Contributors do not tend to care about subsequent
> > > > > > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > > > > > to get fed-up when receiving patches simply because I made a change X
> > > > > > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > > > > > instance and see how far that takes you.
> > > > > > > 
> > > > > > > Thank you for the detailed reply. I did this in the first few patchsets
> > > > > > > and then when a few patches didn't get any attention, expanded the
> > > > > > > audience thus. Still, around 50% of the patches in this series remain
> > > > > > > unreviewed by anyone.
> > > > > > 
> > > > > > This isn't a reason to add more recipients (who are likely to care
> > > > > > even less than your original group).  However it *is* a good argument
> > > > > > for including all of the specified maintainers/reviewers in on all of
> > > > > > the patches.
> > > > > > 
> > > > > > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > > > > > just accept that every version isn't going to be archived by every
> > > > > > > > ML.  It's still much more useful for the correct people to have
> > > > > > > > visibility into the set than for it to be archived multiple times.
> > > > > > > 
> > > > > > > Thank you, will prune the list and remove past contributors from the
> > > > > > > Cc-list and add all parties to all patches.
> > > > > > 
> > > > > > Great.  Once you've done that, we can start to help you acquire the
> > > > > > Acks you need on your remaining patches.
> > > > > 
> > > > > Hi Lee, Thierry, Uwe,
> > > > > 
> > > > > In v14 of this patchset I've pruned the list of contributors, removed
> > > > > past contributors from the cc-list, and added all parties to all patches
> > > > > (except for the patches that are yet to reviewed, for which I've added
> > > > > what get_maintainer.pl showed me). I've also resent v14 a couple of
> > > > > times already, with around a week's time interval between resends, and
> > > > > somehow it seems like this set has lost traction.
> > > > > 
> > > > > Could you please indicate what next steps I should take to have more
> > > > > eyes on the unreviewed patches? Only 4 out of 11 patches remain
> > > > > unreviewed.
> > > > 
> > > > Looks like we're waiting on Thierry (again).
> > > > 
> > > > This has been a common theme over the past few months.
> > > > 
> > > > Perhaps he has changed employer/project?
> > > 
> > > My work on PWM is purely done in my spare time. I don't get paid for any
> > > of it. I currently have two kids that need home-schooling, as many
> > > others probably do, and I have a full time job doing non-PWM related
> > > things. As a result my spare time is close to nil these days.
> > 
> > This is no different to many others.  I too am not paid for this work,
> > but it's still my responsibly to ensure a reply within a reasonable
> > amount of time.
> 
> I realize that this is the same for many others. Still, you seemed to
> suggest that the lack of time that I was able to spend on PWM was
> somehow related to me changing employers, so I wanted to clarify that
> this isn't 
> 
> > We can all appreciate that the latest situation has exacerbated issues,
> > but a reasonable level of PWM participation, blocking various
> > patch-sets has been lacking for months before we'd even heard of
> > Covid-19 [0].
> 
> Covid-19 started to impact me around mid-March, and you'll see that
> that's about the time that I stopped maintaining patchwork.
> 
> > If you need help, just ask for it.
> 
> Hm... who do you go and ask for help? Every maintainer I know is already
> at least as busy as I am.
> 
> > I am willing to step up and review patches if you're overloaded. Uwe
> > is already listed as a designated reviewer. Perhaps between the 3 of
> > us we can work something out in order to reduce the latency.
> 
> That's very kind of you. Yes, I'd be willing to do this as a sort of
> group maintenance, and perhaps even eventually step away from my role
> as maintainer entirely if I think somebody else will do a better job.
> I do still care about the PWM subsystem, having looked after it for a
> couple of years, so I do want any hand-off to be somewhat orderly.
> 
> > [0] https://patchwork.ozlabs.org/project/linux-pwm/list/
> > 
> > > I very much appreciate all the effort that others have spent in getting
> > > this reviewed. I haven't been able to keep a very close eye on this, but
> > > even the latest versions have some comments, so I didn't consider this
> > > ready yet. If that's changed and everybody's okay with the changes, then
> > > I can apply this to for-next. We haven't got all that much time left
> > > before the merge window and I had hoped this would be ready earlier so
> > > that we'd have more time for this in linux-next. But I'd be willing to
> > > at least give it a try. If it starts to look like there are going to be
> > > issues with this I can always back them out and we can have another go
> > > next release.
> > 
> > If you would be so kind as to review the PWM patches, I can take them
> > in but I can't do anything without your Ack.
> 
> Looking at v14 I think there are no longer any discussions (looks like
> the last comment I thought was from v14 was actually on v13 and it seems
> to have been solved in v14 now) and there are Acked-bys for all the non-
> PWM patches, so there's nothing in the way of me applying this to the
> PWM tree. I can let it soak there for a few days and send out a stable
> branch if anyone needs it if there aren't any huge issues.
> 
> Does that sound like a plan?

I had it in my mind that I'd apply it, as MFD is usually the central
repo to a lot of these cross-subsystem type patchsets, and the fact
that I'm already set-up for it (I have scripts which make this easy).

However, as long as a pull-request is sent out for us to potentially
pull from, it really makes no difference to me.  Go for it! :)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?

Yes, that is the merge plan. :)

Whoever takes this will have to offer out an immutable PR.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?

Yes, that is the merge plan. :)

Whoever takes this will have to offer out an immutable PR.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?

Yes, that is the merge plan. :)

Whoever takes this will have to offer out an immutable PR.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Thu, 23 Apr 2020, Guru Das Srinagesh wrote:

> On Thu, Apr 23, 2020 at 12:48:57PM +0100, Lee Jones wrote:
> > What's the merge plan for this set?
> 
> I'm not sure what you mean. My assumption is that first all the patches
> need to get an Acked-by and only then will the series get applied by
> Thierry... Could Thierry or Uwe weigh in on this point please?

Yes, that is the merge plan. :)

Whoever takes this will have to offer out an immutable PR.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.
> 
> Changes from v12:
>   - Rebased to tip of for-next
>   - Collected Acked-by for sun4i
>   - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
>     a result
> 
> Changes from v11:
>   - Rebased to tip of for-next.
>   - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
>   - Squished stm32-lp.c change with final patch in series
>   - sun4i: Used nsecs_to_jiffies()
>   - imx27: Added overflow handling logic
>   - clps711x: Corrected the if condition for skipping the division
>   - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero
> 
> Changes from v10:
>   - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
>     so far that had gotten missed in v9. No other changes.
> 
> Changes from v9:
>   - Gathered the received "Reviewed-by: " tag
>   - Added back the clk-pwm.c patch because kbuild test robot complained [3]
>     and addressed received review comments.
>   - clps711x: Addressed review comments.
> 
> Changes from v8:
>   - Gathered all received "Acked-by: " and "Reviewed-by: " tags
>   - Dropped patch to clk-pwm.c for reasons mentiond in [2]
>   - Expanded audience of unreviewed patches
> 
> Changes from v7:
>   - Changed commit messages of all patches to be brief and to the point.
>   - Added explanation of change in cover letter.
>   - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
>     pwm_capture is not being modified in the PWM core.
> 
> Changes from v6:
>   - Split out the driver changes out into separate patches, one patch per file
>     for ease of reviewing.
> 
> Changes from v5:
>   - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
>     in https://www.spinics.net/lists/linux-pwm/msg11541.html
> 
> Changes from v4:
>   - Split the patch into two: one for changes to the drivers, and the actual
>     switch to u64 for ease of reverting should the need arise.
>   - Re-examined the patch and made the following corrections:
>       * intel_panel.c:
> 	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
> 	64-bit in this case).
>       * pwm-sti.c:
> 	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
> 	div_u64's comment block suggests to use this as much as possible).
> 
> Changes from v3:
>   - Rebased to current tip of for-next.
> 
> Changes from v2:
>   - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
>   - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
> 
> Changes from v1:
>   - Fixed compilation errors seen when compiling for different archs.
> 
> v1:
>   - Reworked the change pushed upstream earlier [1] so as to not add an
>     extension to an obsolete API. With this change, pwm_ops->apply() can be
>     used to set pwm_state parameters as usual.
> 
> [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
> [2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
> [3] https://www.spinics.net/lists/linux-pwm/msg11906.html
> [4] https://www.spinics.net/lists/linux-pwm/msg11986.html
> 
> To: Arnd Bergmann <arnd@arndb.de>
> To: David Laight <David.Laight@ACULAB.COM>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Allison Randal <allison@lohutok.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: David Airlie <airlied@linux.ie>
> Cc: David Collins <collinsd@codeaurora.org>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Kamil Debski <kamil@wypas.org>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: linux-clk@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-hwmon@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: linux-pwm@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Richard Fontana <rfontana@redhat.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: Yash Shah <yash.shah@sifive.com>
> 
> Guru Das Srinagesh (11):
>   drm/i915: Use 64-bit division macro
>   hwmon: pwm-fan: Use 64-bit division macro
>   ir-rx51: Use 64-bit division macro
>   pwm: clps711x: Cast period to u32 before use as divisor
>   pwm: pwm-imx-tpm: Use 64-bit division macro
>   pwm: imx27: Use 64-bit division macro and function
>   pwm: sifive: Use 64-bit division macro
>   pwm: sun4i: Use nsecs_to_jiffies to avoid a division
>   backlight: pwm_bl: Use 64-bit division function
>   clk: pwm: Use 64-bit division function
>   pwm: core: Convert period and duty cycle to u64
> 
>  drivers/clk/clk-pwm.c                      |  7 +++-
>  drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
>  drivers/hwmon/pwm-fan.c                    |  2 +-
>  drivers/media/rc/ir-rx51.c                 |  3 +-
>  drivers/pwm/core.c                         | 14 ++++----
>  drivers/pwm/pwm-clps711x.c                 |  5 ++-
>  drivers/pwm/pwm-imx-tpm.c                  |  2 +-
>  drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
>  drivers/pwm/pwm-sifive.c                   |  2 +-
>  drivers/pwm/pwm-stm32-lp.c                 |  2 +-
>  drivers/pwm/pwm-sun4i.c                    |  2 +-
>  drivers/pwm/sysfs.c                        |  8 ++---

>  drivers/video/backlight/pwm_bl.c           |  3 +-

Acked-by: Lee Jones <lee.jones@linaro.org>

>  include/linux/pwm.h                        | 12 +++----
>  14 files changed, 82 insertions(+), 35 deletions(-)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.
> 
> Changes from v12:
>   - Rebased to tip of for-next
>   - Collected Acked-by for sun4i
>   - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
>     a result
> 
> Changes from v11:
>   - Rebased to tip of for-next.
>   - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
>   - Squished stm32-lp.c change with final patch in series
>   - sun4i: Used nsecs_to_jiffies()
>   - imx27: Added overflow handling logic
>   - clps711x: Corrected the if condition for skipping the division
>   - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero
> 
> Changes from v10:
>   - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
>     so far that had gotten missed in v9. No other changes.
> 
> Changes from v9:
>   - Gathered the received "Reviewed-by: " tag
>   - Added back the clk-pwm.c patch because kbuild test robot complained [3]
>     and addressed received review comments.
>   - clps711x: Addressed review comments.
> 
> Changes from v8:
>   - Gathered all received "Acked-by: " and "Reviewed-by: " tags
>   - Dropped patch to clk-pwm.c for reasons mentiond in [2]
>   - Expanded audience of unreviewed patches
> 
> Changes from v7:
>   - Changed commit messages of all patches to be brief and to the point.
>   - Added explanation of change in cover letter.
>   - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
>     pwm_capture is not being modified in the PWM core.
> 
> Changes from v6:
>   - Split out the driver changes out into separate patches, one patch per file
>     for ease of reviewing.
> 
> Changes from v5:
>   - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
>     in https://www.spinics.net/lists/linux-pwm/msg11541.html
> 
> Changes from v4:
>   - Split the patch into two: one for changes to the drivers, and the actual
>     switch to u64 for ease of reverting should the need arise.
>   - Re-examined the patch and made the following corrections:
>       * intel_panel.c:
> 	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
> 	64-bit in this case).
>       * pwm-sti.c:
> 	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
> 	div_u64's comment block suggests to use this as much as possible).
> 
> Changes from v3:
>   - Rebased to current tip of for-next.
> 
> Changes from v2:
>   - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
>   - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
> 
> Changes from v1:
>   - Fixed compilation errors seen when compiling for different archs.
> 
> v1:
>   - Reworked the change pushed upstream earlier [1] so as to not add an
>     extension to an obsolete API. With this change, pwm_ops->apply() can be
>     used to set pwm_state parameters as usual.
> 
> [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
> [2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
> [3] https://www.spinics.net/lists/linux-pwm/msg11906.html
> [4] https://www.spinics.net/lists/linux-pwm/msg11986.html
> 
> To: Arnd Bergmann <arnd@arndb.de>
> To: David Laight <David.Laight@ACULAB.COM>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Allison Randal <allison@lohutok.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: David Airlie <airlied@linux.ie>
> Cc: David Collins <collinsd@codeaurora.org>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Kamil Debski <kamil@wypas.org>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: linux-clk@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-hwmon@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: linux-pwm@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Richard Fontana <rfontana@redhat.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: Yash Shah <yash.shah@sifive.com>
> 
> Guru Das Srinagesh (11):
>   drm/i915: Use 64-bit division macro
>   hwmon: pwm-fan: Use 64-bit division macro
>   ir-rx51: Use 64-bit division macro
>   pwm: clps711x: Cast period to u32 before use as divisor
>   pwm: pwm-imx-tpm: Use 64-bit division macro
>   pwm: imx27: Use 64-bit division macro and function
>   pwm: sifive: Use 64-bit division macro
>   pwm: sun4i: Use nsecs_to_jiffies to avoid a division
>   backlight: pwm_bl: Use 64-bit division function
>   clk: pwm: Use 64-bit division function
>   pwm: core: Convert period and duty cycle to u64
> 
>  drivers/clk/clk-pwm.c                      |  7 +++-
>  drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
>  drivers/hwmon/pwm-fan.c                    |  2 +-
>  drivers/media/rc/ir-rx51.c                 |  3 +-
>  drivers/pwm/core.c                         | 14 ++++----
>  drivers/pwm/pwm-clps711x.c                 |  5 ++-
>  drivers/pwm/pwm-imx-tpm.c                  |  2 +-
>  drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
>  drivers/pwm/pwm-sifive.c                   |  2 +-
>  drivers/pwm/pwm-stm32-lp.c                 |  2 +-
>  drivers/pwm/pwm-sun4i.c                    |  2 +-
>  drivers/pwm/sysfs.c                        |  8 ++---

>  drivers/video/backlight/pwm_bl.c           |  3 +-

Acked-by: Lee Jones <lee.jones@linaro.org>

>  include/linux/pwm.h                        | 12 +++----
>  14 files changed, 82 insertions(+), 35 deletions(-)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.
> 
> Changes from v12:
>   - Rebased to tip of for-next
>   - Collected Acked-by for sun4i
>   - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
>     a result
> 
> Changes from v11:
>   - Rebased to tip of for-next.
>   - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
>   - Squished stm32-lp.c change with final patch in series
>   - sun4i: Used nsecs_to_jiffies()
>   - imx27: Added overflow handling logic
>   - clps711x: Corrected the if condition for skipping the division
>   - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero
> 
> Changes from v10:
>   - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
>     so far that had gotten missed in v9. No other changes.
> 
> Changes from v9:
>   - Gathered the received "Reviewed-by: " tag
>   - Added back the clk-pwm.c patch because kbuild test robot complained [3]
>     and addressed received review comments.
>   - clps711x: Addressed review comments.
> 
> Changes from v8:
>   - Gathered all received "Acked-by: " and "Reviewed-by: " tags
>   - Dropped patch to clk-pwm.c for reasons mentiond in [2]
>   - Expanded audience of unreviewed patches
> 
> Changes from v7:
>   - Changed commit messages of all patches to be brief and to the point.
>   - Added explanation of change in cover letter.
>   - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
>     pwm_capture is not being modified in the PWM core.
> 
> Changes from v6:
>   - Split out the driver changes out into separate patches, one patch per file
>     for ease of reviewing.
> 
> Changes from v5:
>   - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
>     in https://www.spinics.net/lists/linux-pwm/msg11541.html
> 
> Changes from v4:
>   - Split the patch into two: one for changes to the drivers, and the actual
>     switch to u64 for ease of reverting should the need arise.
>   - Re-examined the patch and made the following corrections:
>       * intel_panel.c:
> 	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
> 	64-bit in this case).
>       * pwm-sti.c:
> 	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
> 	div_u64's comment block suggests to use this as much as possible).
> 
> Changes from v3:
>   - Rebased to current tip of for-next.
> 
> Changes from v2:
>   - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
>   - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
> 
> Changes from v1:
>   - Fixed compilation errors seen when compiling for different archs.
> 
> v1:
>   - Reworked the change pushed upstream earlier [1] so as to not add an
>     extension to an obsolete API. With this change, pwm_ops->apply() can be
>     used to set pwm_state parameters as usual.
> 
> [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
> [2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
> [3] https://www.spinics.net/lists/linux-pwm/msg11906.html
> [4] https://www.spinics.net/lists/linux-pwm/msg11986.html
> 
> To: Arnd Bergmann <arnd@arndb.de>
> To: David Laight <David.Laight@ACULAB.COM>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Allison Randal <allison@lohutok.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: David Airlie <airlied@linux.ie>
> Cc: David Collins <collinsd@codeaurora.org>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Kamil Debski <kamil@wypas.org>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: linux-clk@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-hwmon@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: linux-pwm@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Richard Fontana <rfontana@redhat.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: Yash Shah <yash.shah@sifive.com>
> 
> Guru Das Srinagesh (11):
>   drm/i915: Use 64-bit division macro
>   hwmon: pwm-fan: Use 64-bit division macro
>   ir-rx51: Use 64-bit division macro
>   pwm: clps711x: Cast period to u32 before use as divisor
>   pwm: pwm-imx-tpm: Use 64-bit division macro
>   pwm: imx27: Use 64-bit division macro and function
>   pwm: sifive: Use 64-bit division macro
>   pwm: sun4i: Use nsecs_to_jiffies to avoid a division
>   backlight: pwm_bl: Use 64-bit division function
>   clk: pwm: Use 64-bit division function
>   pwm: core: Convert period and duty cycle to u64
> 
>  drivers/clk/clk-pwm.c                      |  7 +++-
>  drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
>  drivers/hwmon/pwm-fan.c                    |  2 +-
>  drivers/media/rc/ir-rx51.c                 |  3 +-
>  drivers/pwm/core.c                         | 14 ++++----
>  drivers/pwm/pwm-clps711x.c                 |  5 ++-
>  drivers/pwm/pwm-imx-tpm.c                  |  2 +-
>  drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
>  drivers/pwm/pwm-sifive.c                   |  2 +-
>  drivers/pwm/pwm-stm32-lp.c                 |  2 +-
>  drivers/pwm/pwm-sun4i.c                    |  2 +-
>  drivers/pwm/sysfs.c                        |  8 ++---

>  drivers/video/backlight/pwm_bl.c           |  3 +-

Acked-by: Lee Jones <lee.jones@linaro.org>

>  include/linux/pwm.h                        | 12 +++----
>  14 files changed, 82 insertions(+), 35 deletions(-)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:

> [REQUEST]
> 
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a new change that came in
> after I rebased to tip. I wasn't sure earlier about accepting single patches as
> opposed to the entire series en masse, but this event has got me thinking.
> 
> [COVER LETTER]
> 
> Because period and duty cycle are defined in the PWM framework structs as ints
> with units of nanoseconds, the maximum time duration that can be set is limited
> to ~2.147 seconds. Consequently, applications desiring to set greater time
> periods via the PWM framework are not be able to do so - like, for instance,
> causing an LED to blink at an interval of 5 seconds.
> 
> Redefining the period and duty cycle struct members in the core PWM framework
> structs as u64 values will enable larger time durations to be set and solve
> this problem. Such a change to the framework mandates that drivers using these
> struct members (and corresponding helper functions) also be modified correctly
> in order to prevent compilation errors.
> 
> This patch series introduces the changes to all the drivers first, followed by
> the framework change at the very end so that when the latter is applied, all
> the drivers are in good shape and there are no compilation errors.
> 
> Changes from v12:
>   - Rebased to tip of for-next
>   - Collected Acked-by for sun4i
>   - Reworked patch for intel-panel.c due to rebase, dropped Jani's Acked-by as
>     a result
> 
> Changes from v11:
>   - Rebased to tip of for-next.
>   - Collected "Acked-by:" for v7 (unchanged) of pwm: sifive: [4]
>   - Squished stm32-lp.c change with final patch in series
>   - sun4i: Used nsecs_to_jiffies()
>   - imx27: Added overflow handling logic
>   - clps711x: Corrected the if condition for skipping the division
>   - clk: pwm: Reverted to v8 version, added check to prevent division-by-zero
> 
> Changes from v10:
>   - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received
>     so far that had gotten missed in v9. No other changes.
> 
> Changes from v9:
>   - Gathered the received "Reviewed-by: " tag
>   - Added back the clk-pwm.c patch because kbuild test robot complained [3]
>     and addressed received review comments.
>   - clps711x: Addressed review comments.
> 
> Changes from v8:
>   - Gathered all received "Acked-by: " and "Reviewed-by: " tags
>   - Dropped patch to clk-pwm.c for reasons mentiond in [2]
>   - Expanded audience of unreviewed patches
> 
> Changes from v7:
>   - Changed commit messages of all patches to be brief and to the point.
>   - Added explanation of change in cover letter.
>   - Dropped change to pwm-sti.c as upon review it was unnecessary as struct
>     pwm_capture is not being modified in the PWM core.
> 
> Changes from v6:
>   - Split out the driver changes out into separate patches, one patch per file
>     for ease of reviewing.
> 
> Changes from v5:
>   - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned
>     in https://www.spinics.net/lists/linux-pwm/msg11541.html
> 
> Changes from v4:
>   - Split the patch into two: one for changes to the drivers, and the actual
>     switch to u64 for ease of reverting should the need arise.
>   - Re-examined the patch and made the following corrections:
>       * intel_panel.c:
> 	DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be
> 	64-bit in this case).
>       * pwm-sti.c:
> 	do_div -> div_u64 (do_div is optimized only for x86 architectures, and
> 	div_u64's comment block suggests to use this as much as possible).
> 
> Changes from v3:
>   - Rebased to current tip of for-next.
> 
> Changes from v2:
>   - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot
>   - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c
> 
> Changes from v1:
>   - Fixed compilation errors seen when compiling for different archs.
> 
> v1:
>   - Reworked the change pushed upstream earlier [1] so as to not add an
>     extension to an obsolete API. With this change, pwm_ops->apply() can be
>     used to set pwm_state parameters as usual.
> 
> [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/
> [2] https://lore.kernel.org/lkml/20200312190859.GA19605@codeaurora.org/
> [3] https://www.spinics.net/lists/linux-pwm/msg11906.html
> [4] https://www.spinics.net/lists/linux-pwm/msg11986.html
> 
> To: Arnd Bergmann <arnd@arndb.de>
> To: David Laight <David.Laight@ACULAB.COM>
> To: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Allison Randal <allison@lohutok.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: David Airlie <airlied@linux.ie>
> Cc: David Collins <collinsd@codeaurora.org>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Kamil Debski <kamil@wypas.org>
> Cc: Kate Stewart <kstewart@linuxfoundation.org>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: linux-clk@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-hwmon@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: linux-pwm@vger.kernel.org
> Cc: linux-riscv@lists.infradead.org
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Richard Fontana <rfontana@redhat.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
> Cc: Yash Shah <yash.shah@sifive.com>
> 
> Guru Das Srinagesh (11):
>   drm/i915: Use 64-bit division macro
>   hwmon: pwm-fan: Use 64-bit division macro
>   ir-rx51: Use 64-bit division macro
>   pwm: clps711x: Cast period to u32 before use as divisor
>   pwm: pwm-imx-tpm: Use 64-bit division macro
>   pwm: imx27: Use 64-bit division macro and function
>   pwm: sifive: Use 64-bit division macro
>   pwm: sun4i: Use nsecs_to_jiffies to avoid a division
>   backlight: pwm_bl: Use 64-bit division function
>   clk: pwm: Use 64-bit division function
>   pwm: core: Convert period and duty cycle to u64
> 
>  drivers/clk/clk-pwm.c                      |  7 +++-
>  drivers/gpu/drm/i915/display/intel_panel.c |  2 +-
>  drivers/hwmon/pwm-fan.c                    |  2 +-
>  drivers/media/rc/ir-rx51.c                 |  3 +-
>  drivers/pwm/core.c                         | 14 ++++----
>  drivers/pwm/pwm-clps711x.c                 |  5 ++-
>  drivers/pwm/pwm-imx-tpm.c                  |  2 +-
>  drivers/pwm/pwm-imx27.c                    | 53 +++++++++++++++++++++++++-----
>  drivers/pwm/pwm-sifive.c                   |  2 +-
>  drivers/pwm/pwm-stm32-lp.c                 |  2 +-
>  drivers/pwm/pwm-sun4i.c                    |  2 +-
>  drivers/pwm/sysfs.c                        |  8 ++---

>  drivers/video/backlight/pwm_bl.c           |  3 +-

Acked-by: Lee Jones <lee.jones@linaro.org>

>  include/linux/pwm.h                        | 12 +++----
>  14 files changed, 82 insertions(+), 35 deletions(-)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog