Sometimes it's useful to have well-defined SI metric prefix to be used
to self-describe the formulas or equations.
List most popular ones in the units.h.
Signed-off-by: Andy Shevchenko <[email protected]>
---
include/linux/units.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/linux/units.h b/include/linux/units.h
index dcc30a53fa93..7366fcd45ec2 100644
--- a/include/linux/units.h
+++ b/include/linux/units.h
@@ -4,6 +4,22 @@
#include <linux/math.h>
+/* Metric prefixes in accordance with Système international (d'unités) */
+#define PETA 1000000000000000LL
+#define TERA 1000000000000LL
+#define GIGA 1000000000L
+#define MEGA 1000000L
+#define KILO 1000L
+#define HECTO 100L
+#define DECA 10L
+#define DECI 10L
+#define CENTI 100L
+#define MILLI 1000L
+#define MICRO 1000000L
+#define NANO 1000000000L
+#define PICO 1000000000000LL
+#define FEMTO 1000000000000000LL
+
#define MILLIWATT_PER_WATT 1000L
#define MICROWATT_PER_MILLIWATT 1000L
#define MICROWATT_PER_WATT 1000000L
--
2.30.2
Instead of open-coding DIV_ROUND_CLOSEST() and similar use the macros directly.
While at it, replace numbers with predefined SI metric prefixes.
No functional change intended.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/i2c/busses/i2c-designware-common.c | 8 ++++----
drivers/i2c/busses/i2c-designware-platdrv.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-common.c b/drivers/i2c/busses/i2c-designware-common.c
index fdc34d9e3702..9df101d1a34f 100644
--- a/drivers/i2c/busses/i2c-designware-common.c
+++ b/drivers/i2c/busses/i2c-designware-common.c
@@ -24,6 +24,7 @@
#include <linux/regmap.h>
#include <linux/swab.h>
#include <linux/types.h>
+#include <linux/units.h>
#include "i2c-designware-core.h"
@@ -350,7 +351,7 @@ u32 i2c_dw_scl_hcnt(u32 ic_clk, u32 tSYMBOL, u32 tf, int cond, int offset)
*
* If your hardware is free from tHD;STA issue, try this one.
*/
- return (ic_clk * tSYMBOL + 500000) / 1000000 - 8 + offset;
+ return DIV_ROUND_CLOSEST(ic_clk * tSYMBOL, MEGA) - 8 + offset;
else
/*
* Conditional expression:
@@ -366,8 +367,7 @@ u32 i2c_dw_scl_hcnt(u32 ic_clk, u32 tSYMBOL, u32 tf, int cond, int offset)
* The reason why we need to take into account "tf" here,
* is the same as described in i2c_dw_scl_lcnt().
*/
- return (ic_clk * (tSYMBOL + tf) + 500000) / 1000000
- - 3 + offset;
+ return DIV_ROUND_CLOSEST(ic_clk * (tSYMBOL + tf), MEGA) - 3 + offset;
}
u32 i2c_dw_scl_lcnt(u32 ic_clk, u32 tLOW, u32 tf, int offset)
@@ -383,7 +383,7 @@ u32 i2c_dw_scl_lcnt(u32 ic_clk, u32 tLOW, u32 tf, int offset)
* account the fall time of SCL signal (tf). Default tf value
* should be 0.3 us, for safety.
*/
- return ((ic_clk * (tLOW + tf) + 500000) / 1000000) - 1 + offset;
+ return DIV_ROUND_CLOSEST(ic_clk * (tLOW + tf), MEGA) - 1 + offset;
}
int i2c_dw_set_sda_hold(struct dw_i2c_dev *dev)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 4b37f28ec0c6..099e303d22bb 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -31,12 +31,13 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/suspend.h>
+#include <linux/units.h>
#include "i2c-designware-core.h"
static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
{
- return clk_get_rate(dev->clk)/1000;
+ return clk_get_rate(dev->clk) / KILO;
}
#ifdef CONFIG_ACPI
@@ -269,8 +270,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
clk_khz = dev->get_clk_rate_khz(dev);
if (!dev->sda_hold_time && t->sda_hold_ns)
- dev->sda_hold_time =
- div_u64(clk_khz * t->sda_hold_ns + 500000, 1000000);
+ dev->sda_hold_time = DIV_S64_ROUND_CLOSEST(clk_khz * t->sda_hold_ns, MEGA);
}
adap = &dev->adapter;
--
2.30.2
In couple of places the indentation makes harder to read the code.
Fix it to be sane.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/i2c/busses/i2c-designware-core.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 6a53f75abf7c..60a2e750cee9 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -117,7 +117,7 @@
#define DW_IC_ERR_TX_ABRT 0x1
-#define DW_IC_TAR_10BITADDR_MASTER BIT(12)
+#define DW_IC_TAR_10BITADDR_MASTER BIT(12)
#define DW_IC_COMP_PARAM_1_SPEED_MODE_HIGH (BIT(2) | BIT(3))
#define DW_IC_COMP_PARAM_1_SPEED_MODE_MASK GENMASK(3, 2)
@@ -245,7 +245,7 @@ struct dw_i2c_dev {
struct clk *clk;
struct clk *pclk;
struct reset_control *rst;
- struct i2c_client *slave;
+ struct i2c_client *slave;
u32 (*get_clk_rate_khz) (struct dw_i2c_dev *dev);
int cmd_err;
struct i2c_msg *msgs;
--
2.30.2
On 6/3/21 7:04 PM, Andy Shevchenko wrote:
> Sometimes it's useful to have well-defined SI metric prefix to be used
> to self-describe the formulas or equations.
>
> List most popular ones in the units.h.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
> ---
> include/linux/units.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/units.h b/include/linux/units.h
> index dcc30a53fa93..7366fcd45ec2 100644
> --- a/include/linux/units.h
> +++ b/include/linux/units.h
> @@ -4,6 +4,22 @@
>
> #include <linux/math.h>
>
> +/* Metric prefixes in accordance with Système international (d'unités) */
> +#define PETA 1000000000000000LL
> +#define TERA 1000000000000LL
> +#define GIGA 1000000000L
> +#define MEGA 1000000L
> +#define KILO 1000L
> +#define HECTO 100L
> +#define DECA 10L
> +#define DECI 10L
> +#define CENTI 100L
> +#define MILLI 1000L
> +#define MICRO 1000000L
> +#define NANO 1000000000L
> +#define PICO 1000000000000LL
> +#define FEMTO 1000000000000000LL
> +
For me milli is always 1/1000. Might lead to confusion with these
defines if idea is to multiply with KILO but divide with MILLI?
Jarkko
On Mon, Jun 07, 2021 at 03:33:31PM +0300, Jarkko Nikula wrote:
> On 6/3/21 7:04 PM, Andy Shevchenko wrote:
> > Sometimes it's useful to have well-defined SI metric prefix to be used
> > to self-describe the formulas or equations.
> >
> > List most popular ones in the units.h.
...
> > +/* Metric prefixes in accordance with Syst?me international (d'unit?s) */
> > +#define PETA 1000000000000000LL
> > +#define TERA 1000000000000LL
> > +#define GIGA 1000000000L
> > +#define MEGA 1000000L
> > +#define KILO 1000L
> > +#define HECTO 100L
> > +#define DECA 10L
> > +#define DECI 10L
> > +#define CENTI 100L
> > +#define MILLI 1000L
> > +#define MICRO 1000000L
> > +#define NANO 1000000000L
> > +#define PICO 1000000000000LL
> > +#define FEMTO 1000000000000000LL
>
> For me milli is always 1/1000.
For me as well. Kernel does not operate with float point numbers.
That's why it's ordered like this.
> Might lead to confusion with these defines if
> idea is to multiply with KILO but divide with MILLI?
If the author of the hypothetical driver doesn't understand this, maybe
they can ask first, but I am an optimist here and I assume that whoever
writes the driver for a sensor / etc has a minimum education to see
what's needed for the certain case.
--
With Best Regards,
Andy Shevchenko
On Mon, Jun 07, 2021 at 05:24:44PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 07, 2021 at 03:33:31PM +0300, Jarkko Nikula wrote:
> > On 6/3/21 7:04 PM, Andy Shevchenko wrote:
> > > Sometimes it's useful to have well-defined SI metric prefix to be used
> > > to self-describe the formulas or equations.
> > >
> > > List most popular ones in the units.h.
>
> ...
>
> > > +/* Metric prefixes in accordance with Syst?me international (d'unit?s) */
> > > +#define PETA 1000000000000000LL
> > > +#define TERA 1000000000000LL
> > > +#define GIGA 1000000000L
> > > +#define MEGA 1000000L
> > > +#define KILO 1000L
> > > +#define HECTO 100L
> > > +#define DECA 10L
> > > +#define DECI 10L
> > > +#define CENTI 100L
> > > +#define MILLI 1000L
> > > +#define MICRO 1000000L
> > > +#define NANO 1000000000L
> > > +#define PICO 1000000000000LL
> > > +#define FEMTO 1000000000000000LL
> >
> > For me milli is always 1/1000.
>
> For me as well. Kernel does not operate with float point numbers.
> That's why it's ordered like this.
>
> > Might lead to confusion with these defines if
> > idea is to multiply with KILO but divide with MILLI?
>
> If the author of the hypothetical driver doesn't understand this, maybe
> they can ask first, but I am an optimist here and I assume that whoever
> writes the driver for a sensor / etc has a minimum education to see
> what's needed for the certain case.
Writing this, I think that I'm not so educated :-)
What we have in I?C case is kHz * ns = 10^3 * 10^-9, so we need to divide by
10^-6 to normalize the numbers. Sounds like MICRO is the correct thing to use
there.
--
With Best Regards,
Andy Shevchenko