[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2bb661d-8ef5-43d4-aece-c7fec01ff9fe@gmail.com>
Date: Tue, 29 Oct 2024 09:53:33 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andreas Kemnade <andreas@...nade.info>, Conor Dooley
<conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
linux-kernel@...r.kernel.org, Fabio Estevam <festevam@...il.com>,
devicetree@...r.kernel.org, Pengutronix Kernel Team <kernel@...gutronix.de>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
linux-arm-kernel@...ts.infradead.org, Sascha Hauer <s.hauer@...gutronix.de>,
Alexander Stein <alexander.stein@...tq-group.com>, imx@...ts.linux.dev
Subject: Re: [PATCH v2 2/3] ARM: dts: imx: Add devicetree for Kobo Clara 2E
On 24/10/2024 17:22, Andreas Kemnade wrote:
> Adds a devicetree for the Kobo Clara 2E Ebook reader. It is based
> on boards marked with "37NB-E60K2M+4A2" or "37NB-E60K2M+4B0". It is
> equipped with an i.MX6SLL SoC.
>
> Expected to work:
> - Buttons
> - Wifi
> - Bluetooth
> (if Wifi is initialized first, driver does not handle regulators
> yet)
> - LED
> - uSD
> - USB
> - RTC
> - Touchscreen
>
> Add human-readable comments for devices without mainlined driver and
> binding. Such comments can e.g. be help to find testers if someone
> starts to work on the missing drivers.
>
> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
...
> +
> + pmic@4b {
> + compatible = "rohm,bd71879", "rohm,bd71828";
> + reg = <0x4b>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_bd71828>;
> +
> + interrupt-parent = <&gpio4>;
> + interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
> + system-power-controller;
> +
> + clocks = <&clks 0>;
> + #clock-cells = <0>;
> + clock-output-names = "bd71828-32k-out";
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-reserved-ranges = <0 1>, <2 1>;
> +
> + rohm,charger-sense-resistor-ohms = <30000000>;
I am afraid that this one is _my_ very much terrible brainfart. Yeah,
pile up the stones and start casting ;)
I am fairly sure the sense resistor is 30 mOhm (0,030 Ohm), not 30 MOhm
(30 000 000 Ohm). (And I am the one who misinterpreted the M in some
email/data-sheet in the past - and never questioned the sanity).
In short, AFAICS the sense resistor is added "in series" to the system
load. Eg:
--------
---| Rsense |-----
| -------- |
--------- -------
| VSupply | | Rload |
--------- -------
| |
------------------
Hence, by measuring the voltage drop on the Rsense gives us the current
flowing through the system ( good old U = RI ).
I believe having 30 Mohm (30 000 000 Ohm) resistor there would not make
much of sense... With a Fermi estimate that the system works with
voltage magnitude of 1V and current magnitude of 1A and then applying
good old P = UI and U = RI would give us wonderful results :) Quite a
battery on poor Kobo, right? You'd better to not touch the battery
termninals ;) Oh, and looking the driver code I've written for handling
this property... Sometimes I really don't like mirrors :)
Well, now that I got this out - I suppose this could be
rohm,charger-sense-resistor-milli-ohms = <30>;
or
rohm,charger-sense-resistor-micro-ohms = <30000>;
I further guess there is no upstreamn binding doc for this property. I
think there is also no upstream charger driver for the BD71828/BD71879 -
only an early RFC and some downstream mess - but stil it'd be nice to
have the property in place as the size of the sense resistor is needed
when converting coulomb counter register values to current.
Yours,
-- Matti
Powered by blists - more mailing lists