Support for Ambiq Apollo chips #bluetooth #ambiq


Keith Short
 

Hi Michał -

You want the devicetree organization to match the hardware description.  So in the case of the Ambiq GPIO controller, I think your best bet is to create only GPIOA and GPIOB controllers.  This matches the register layout for the common runtime operations: read GPIO input (via RDA abd RDB), write GPIO output (via WTA/WTB, WTSA/WTSB, WTCA/WTCB).

GPIOA will set ngpios = <32> and GPIOB will set ngpios = <18>.

As for the registers, you would map the PADREGA-H, and CFGA-D to the GPIOA controller, PADREGI-M and CFGE-G to the GPIOB controller.

My approach would probably look something like this:

gpioa: gpio@40010000 {
compatible = "ambiq,apollo3-gpio";
gpio-controller;
reg = <0x40010000 0x20   /* PADREGA-H */
      0x40010040 0x10   /* CFGA-D */
      0x40010080 4   /* RDA (input read) */
      0x40010088 4   /* WTA (output write) */
      0x40010090 4   /* WTSA (output set) */
      0x40010098 4   /* WTCA (clear) */
      0x400100a0 4   /* ENA (enable) */
      0x400100a8 4   /* ENSA (set) */
      0x400100b4 4   /* ENCA (clear) */
      >;
ngpios = <32>;
label = "GPIOA";
#gpio-cells = <2>;
};

The actual driver code can define macros to convert the GPIO pin number (0-31) to the correct PADREGx register offset, and subfield within the register.

Keith



On Wed, Apr 28, 2021 at 7:03 AM Michał Ciesielski <ciesielskimm@...> wrote:
Hey Keith,

Thanks for the lead. This certainly helps. I still have some
questions, hope that's ok.

Lets say I'm describing the bytes that relate to gpio controller A:

```
gpioa: gpio@40010000 {
compatible = "ambiq,apollo3-gpio";
gpio-controller;
reg = <0x40010000 4   /* PADREG */
      0x40010040 2   /* CFGA */
      0x400100e0 4   /* ALTPADCFGA */
      0x40010080 1   /* RDA (input read) */
      0x40010088 1   /* WTA (output write) */
      0x40010090 1   /* WTSA (output set) */
      0x40010098 1   /* WTCA (clear) */
      0x400100a0 1   /* ENA (enable) */
      0x400100a8 1   /* ENSA (set) */
      0x400100b4 1   /* ENCA (clear) */
      >;
ngpios = <4>;
label = "GPIOA";
#gpio-cells = <2>;
};
```

RDA register is an input register to read the input state of the first
32 pins. RDB register holds the input state of the next 18 pins.
How would I describe that in this gpio controller? Do I describe
specific pins at this stage or is that the register I specify,
combined
with its size, should include all the bytes that refer to the
controlled pins? Meaning that this memory description can include more
than just bits referring to the pins connected to the gpio controller
A and more specific pin description happens in another node.
So the aforementioned RDA register is described here with its address
and size of 32bits. That memory range 0x40010080 - 0x40010081
describes a register that is used by 32 pins.

Another example is the ALTPADCFGA. It describes 32 pins using 4 32bits
registers. Should I specify its size as 4 (entire register) or
only 1 as the first byte of that register is the only one that
references gpio controller A.

I guess my problems come from the lack of understanding what exactly
am I describing here.

Thanks again,
Michal



On Mon, Apr 26, 2021 at 10:29 PM Keith Short <keithshort@...> wrote:
>
> The GPIO driver for the ITE IT8xxx2 family also interleaves the register space.
>
> You could follow the model used for that driver - create multiple reg phandles for the individual registers.
>
> https://github.com/zephyrproject-rtos/zephyr/blob/a3469a04978540b1d1cf0173bc557aeb9c0453be/dts/riscv/it8xxx2.dtsi#L93
>
> Keith
>
> On Sun, Apr 25, 2021 at 4:19 PM <ciesielskimm@...> wrote:
>>
>> Hello,
>>
>> I'm trying to add support for the Ambiq Apollo series chips. I'm new to the Zephyr and not very experienced with Device Tree format.
>> Currently I'm working on the zephyr/dts/arm/ambiq/apollo.dtsi. I'm trying to add the GPIO control registers. I'm modyfing
>> the STM32 dtsi file. STM32's define the GPIO control in a different way. All the Pad A registers are defined in a continous memory block.
>> In Ambiq SOCs those they are interleaved. The image below shows the memory map.
>>
>>
>>
>> First its the Pad configuration registers. Then its GPIO configuration register. I'm wondering how should I implement this
>> memory layout in the dtsi.


Michał Ciesielski
 

Hey Keith,

Thanks for the lead. This certainly helps. I still have some
questions, hope that's ok.

Lets say I'm describing the bytes that relate to gpio controller A:

```
gpioa: gpio@40010000 {
compatible = "ambiq,apollo3-gpio";
gpio-controller;
reg = <0x40010000 4 /* PADREG */
0x40010040 2 /* CFGA */
0x400100e0 4 /* ALTPADCFGA */
0x40010080 1 /* RDA (input read) */
0x40010088 1 /* WTA (output write) */
0x40010090 1 /* WTSA (output set) */
0x40010098 1 /* WTCA (clear) */
0x400100a0 1 /* ENA (enable) */
0x400100a8 1 /* ENSA (set) */
0x400100b4 1 /* ENCA (clear) */
>;
ngpios = <4>;
label = "GPIOA";
#gpio-cells = <2>;
};
```

RDA register is an input register to read the input state of the first
32 pins. RDB register holds the input state of the next 18 pins.
How would I describe that in this gpio controller? Do I describe
specific pins at this stage or is that the register I specify,
combined
with its size, should include all the bytes that refer to the
controlled pins? Meaning that this memory description can include more
than just bits referring to the pins connected to the gpio controller
A and more specific pin description happens in another node.
So the aforementioned RDA register is described here with its address
and size of 32bits. That memory range 0x40010080 - 0x40010081
describes a register that is used by 32 pins.

Another example is the ALTPADCFGA. It describes 32 pins using 4 32bits
registers. Should I specify its size as 4 (entire register) or
only 1 as the first byte of that register is the only one that
references gpio controller A.

I guess my problems come from the lack of understanding what exactly
am I describing here.

Thanks again,
Michal



On Mon, Apr 26, 2021 at 10:29 PM Keith Short <keithshort@google.com> wrote:

The GPIO driver for the ITE IT8xxx2 family also interleaves the register space.

You could follow the model used for that driver - create multiple reg phandles for the individual registers.

https://github.com/zephyrproject-rtos/zephyr/blob/a3469a04978540b1d1cf0173bc557aeb9c0453be/dts/riscv/it8xxx2.dtsi#L93

Keith

On Sun, Apr 25, 2021 at 4:19 PM <ciesielskimm@gmail.com> wrote:

Hello,

I'm trying to add support for the Ambiq Apollo series chips. I'm new to the Zephyr and not very experienced with Device Tree format.
Currently I'm working on the zephyr/dts/arm/ambiq/apollo.dtsi. I'm trying to add the GPIO control registers. I'm modyfing
the STM32 dtsi file. STM32's define the GPIO control in a different way. All the Pad A registers are defined in a continous memory block.
In Ambiq SOCs those they are interleaved. The image below shows the memory map.



First its the Pad configuration registers. Then its GPIO configuration register. I'm wondering how should I implement this
memory layout in the dtsi.


Keith Short
 

The GPIO driver for the ITE IT8xxx2 family also interleaves the register space.

You could follow the model used for that driver - create multiple reg phandles for the individual registers.


Keith

On Sun, Apr 25, 2021 at 4:19 PM <ciesielskimm@...> wrote:
Hello,

I'm trying to add support for the Ambiq Apollo series chips. I'm new to the Zephyr and not very experienced with Device Tree format.
Currently I'm working on the zephyr/dts/arm/ambiq/apollo.dtsi. I'm trying to add the GPIO control registers. I'm modyfing
the STM32 dtsi file. STM32's define the GPIO control in a different way. All the Pad A registers are defined in a continous memory block.
In Ambiq SOCs those they are interleaved. The image below shows the memory map.



First its the Pad configuration registers. Then its GPIO configuration register. I'm wondering how should I implement this
memory layout in the dtsi.


Michał Ciesielski
 

Hello,

I'm trying to add support for the Ambiq Apollo series chips. I'm new to the Zephyr and not very experienced with Device Tree format.
Currently I'm working on the zephyr/dts/arm/ambiq/apollo.dtsi. I'm trying to add the GPIO control registers. I'm modyfing
the STM32 dtsi file. STM32's define the GPIO control in a different way. All the Pad A registers are defined in a continous memory block.
In Ambiq SOCs those they are interleaved. The image below shows the memory map.



First its the Pad configuration registers. Then its GPIO configuration register. I'm wondering how should I implement this
memory layout in the dtsi.