Re: [PATCH 3/3] arm64: dts: qcom: msm8953: Add device tree for Billion Capture+

[Luca Weiss]

On 21-06-2025 9:07 a.m., cristian_ci wrote:
> On Saturday, June 21st, 2025 at 00:20, Luca Weiss <luca@xxxxxxxxxxxx> wrote:
>
> > > +
> > > + reserved-memory {
> > > + qseecom@0 {
> >
> >
> > qseecom@84a00000 ?
> >
> > > + reg = <0x00 0x84a00000 0x00 0x1900000>;
> > > + no-map;
> > > + };
>
> Looking at downstream devicetree, every reserved-memory nodes with "removed-dma-pool" compatible has unit address 0. OTOH, kernel documentation [1] says:
> "  Following the generic-names recommended practice, node names should
>    reflect the purpose of the node (ie. "framebuffer" or "dma-pool").
>    Unit address (@<address>) should be appended to the name if the node
>    is a static allocation."
>
> In my case, downstream devicetree shows:
>
> 		other_ext_region@0 {
> 			compatible = "removed-dma-pool";
> 			no-map;
> 			reg = <0x00 0x84a00000 0x00 0x1e00000>;
> 		};
>
> which will be 'qseecom' reserved-memory node in mainline devicetree.
>
> OTOH, 'qseecom' node in downstream devicetree also shows:
>
> 		qseecom@84a00000 {
> 			compatible = "qcom,qseecom";
> 			reg = <0x84a00000 0x1900000>;
>                          ...
>
> If you confirm what you suggest, 'qseecom' reserved-memory node will look like the following:
>
> 		qseecom_mem: qseecom@84a00000 {
> 			reg = <0x0 0x84a00000 0x0 0x1900000>;
> 			no-map;
> 		};
>
> [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml

The name (qseecom@84a00000) mostly does not matter at runtime, it's just 
a nice label we give it. The reg is the important bit that gets used in 
reserved-memory.

But actually re-checking, I don't think your reserved-memory works right 
now, msm8953.dtsi has

	soc: soc@0 {
		#address-cells = <1>;
		#size-cells = <1>;

which means that you should only have one value for address, and one for 
size, so "reg = <0x84a00000 0x1900000>;". This is different to most 
other Qualcomm arm64 SoCs.

Same for cont-splash below.

> > > + cont_splash_mem: cont-splash@90001000 {
> > > + reg = <0x0 0x90001000 0x0 (1080 * 1920 * 3)>;
> > > + no-map;
> > > + };
> > > + };
> > > +>>
> > Any ideas what's connected to these pins? If you do, good to document
> > this like in other devices.
> >
> > Regards
> > Luca
>
> Unfortunately, downstream devicetree's pinctrl (kernel sources not available) doesn't mention anywhere 'gpio0', 'gpio1', 'gpio2', 'gpio3', 'gpio135', 'gpio136', 'gpio137' and 'gpio138' (but, for example, 'gpio4' and 'gpio139' are shown, instead). So, I've no ideas what these reserved gpios are used for.
That's fine from my side then.

Regards
Luca