[PATCH 1/2] dt-bindings: microchip-otpc: document Microchip OTPC
Claudiu.Beznea at microchip.com
Claudiu.Beznea at microchip.com
Thu May 12 00:17:45 PDT 2022
On 11.05.2022 18:27, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 10/05/2022 11:44, Claudiu Beznea wrote:
>> Document Microchip OTP controller.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> ---
>> .../bindings/nvmem/microchip-otpc.yaml | 55 +++++++++++++++++++
>> include/dt-bindings/nvmem/microchip,otpc.h | 18 ++++++
>> 2 files changed, 73 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>> create mode 040000 include/dt-bindings/nvmem
>> create mode 100644 include/dt-bindings/nvmem/microchip,otpc.h
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>> new file mode 100644
>> index 000000000000..a8df7fee5c2b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/microchip-otpc.yaml
>
> vendor,device.yaml
> device should not be a wildcard but first compatible, so
> microchip,sama7g5-otpc.yaml
OK
>
>
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/nvmem/microchip-otpc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip SAMA7G5 OTP Controller (OTPC) device tree bindings
>
> s/device tree bindings//
OK
>
>> +
>> +maintainers:
>> + - Claudiu Beznea <claudiu.beznea at microchip.com>
>> +
>> +description: |
>> + This binding represents the OTP controller found on SAMA7G5 SoC.
>
> Entire description is duplicating title. Please describe the hardware or
> skip it.
OK
>
> OTOH, you should mention the header, for example in description.
>
>> +
>> +allOf:
>> + - $ref: "nvmem.yaml#"
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - const: microchip,sama7g5-otpc
>> + - const: syscon
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 1
>
> These come from nvmem.yaml.
OK
>
>> +
>> +required:
>> + - compatible
>> + - reg
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/at91.h>
>
> How the clock is used here?
This is garbage. I forgot it here.
>
>> + #include <dt-bindings/nvmem/microchip,otpc.h>
>> +
>> + otpc: efuse at e8c00000 {
>> + compatible = "microchip,sama7g5-otpc", "syscon";
>> + reg = <0xe8c00000 0xec>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + temperature_calib: calib at 1 {
>> + reg = <OTP_PKT(1) OTP_PKT_SAMA7G5_TEMP_CALIB_LEN>;
>> + };
>> + };
>> +
>> +...
>> diff --git a/include/dt-bindings/nvmem/microchip,otpc.h b/include/dt-bindings/nvmem/microchip,otpc.h
>> new file mode 100644
>> index 000000000000..44b6ed3b8f18
>> --- /dev/null
>> +++ b/include/dt-bindings/nvmem/microchip,otpc.h
>> @@ -0,0 +1,18 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>
> Same license as bindings.
OK
>
>> +
>> +#ifndef _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>> +#define _DT_BINDINGS_NVMEM_MICROCHIP_OTPC_H
>> +
>> +/*
>> + * Need to have it as a multiple of 4 as NVMEM memory is registered with
>> + * stride = 4.
>> + */
>> +#define OTP_PKT(id) ((id) * 4)
>
> Do I get it correctly - the offset or register address is now part of a
> binding? You write here "id", however you use it as part of "reg", so
> it's confusing.
I agree that reg should describe the offset in OTP memory and its the
length for a cell.
However this OTP memory is organized into packets (this is how hardware is
designed), the 1st one being the boot configuration packet, the 2nd one
being temperature calibration data. At the moment Microchip provides only
these 2 packets in OTP memory. Boot configuration packet may vary in length
thus it may change the offset the temperature calibration packet resides
to. If this happen and we use offset based addressing in device trees then
the solution will not work all the time.
OTP hardware is designed to work with packets. For a packet being in memory
at offset 0x0E as follows:
offset OTP Memory layout
. .
. ... .
. .
0x0E +-----------+ <--- packet X
| header X |
0x12 +-----------+
| payload X |
0x16 | |
| |
0x1A | |
+-----------+
. .
. ... .
. .
requesting from software data at address 0x16 (through OTP control
registers) will return the whole packet starting at offset 0x0E. Same
things happens when requesting data at offset 0x0E, 0x12, 0x1A.
Thus, as underlying hardware returns to software chunks of 4 bytes though
data registers the driver has been registered with stride = 4. The
OTP_PKT() macro expects packet identifier (starting from 0), multiplies it
by 4 to be able to pass the NVMEM subsystem accordingly, then the driver
which manages a list of the available packets divides this value by 4 and
gets the packet ID and the proper offset in memory for the requested packet ID.
The intention was to have the OTP_PKT() macro here to be used in device
trees for simpler way of describing different cells in this OTP memory.
Also, using OTP_PKT() abstraction looked to me closer to the reality
(although the computed value is not reflecting this, it is only an
abstraction to be able to pass the NVMEM subsystem).
Would you prefer to have raw values instead of using this macro?
Adapting the subsystem for this kind of devices is also an option if
Srinivas thinks like this.
>
>> +
>> +/*
>> + * Temperature calibration packet length for SAMA7G5: 1 words header,
>> + * 18 words payload.
>> + */
>> +#define OTP_PKT_SAMA7G5_TEMP_CALIB_LEN (19 * 4)
>
> Length of some memory region also does not look like job for bindings.
I added it here to be able to have the same macro in DT and consumer
drivers taking as example iio drivers that uses this approach to describe
IIO channel identifiers. I can remove it and use necessary macros in the
consumer drivers, if it's better this way.
Thank you for your review,
Claudiu Beznea
>
> Best regards,
> Krzysztof
More information about the linux-arm-kernel
mailing list