Re: [PATCH 03/24] arm64: dts: qcom: Introduce Glymur base dtsi and CRD dts

Dmitry Baryshkov
2025-10-30T11:09:52Z

On Thu, 30 Oct 2025 at 12:44, Taniya Das <taniya.das@oss.qualcomm.com> wrote:
>
>
>
> On 10/29/2025 4:06 PM, Dmitry Baryshkov wrote:
> > On Wed, Oct 29, 2025 at 03:30:54PM +0530, Taniya Das wrote:
> >>
> >>
> >> On 9/25/2025 3:46 PM, Konrad Dybcio wrote:
> >>>> + tcsrcc: clock-controller@1fd5044 {
> >>>> + compatible = "qcom,glymur-tcsr";
> >>>> + reg = <0x0 0x1fd5044 0x0 0x48>;
> >>> We can map 0x1fd5000 - 0x1fd5094 inclusive, as that seems like a
> >>> logical subblock (this would require adjusting the driver)
> >>>
> >>
> >> Konrad, we encountered issues when trying to map regions beyond just the
> >> clock reference registers. Normally, we map the entire address range of
> >> a clock controller (CC) module in the device tree. However, for TCSRCC
> >> where CLKREF_EN registers are located within shared modules like TCSR or
> >> TLMM—we don't own the whole address space, and mapping the full range
> >> can overlap with other devices.
> >> To avoid this, we propose defining the base address as the first
> >> register actually used, and the size to only include up to the last
> >> register we use. This ensures we only map the relevant subblock,
> >> preventing conflicts with other device nodes.
> >
> > Then you need to behave slightly differently: map the full range at the
> > basic device (TLMM, TCSR, etc.) and then create TCSRCC as a child device
> > to that node (and use paren't regmap to access the registers).
> >
>
> Dmitry, I agree that this approach is ideal. However, the current
> hardware implementation isn’t consistent across multiple SoCs, which
> means the driver design also needs to adapt. Given these differences, we
> decided to strictly map only the range of hardware registers that are
> actually used for clocks, rather than the entire module.

You are writing a driver for the platform, not a generic driver for
all the platforms.

>
> >>
> >> So want to keep the mapping same from the start of clockref clocks.
> >>
> >>> There's also a laaaarge pool of various TCSR_ registers between
> >>> the previous node and this one.. but we can leave that in case we
> >>> need to describe it in a specific way some day
> >>>> + #clock-cells = <1>;
> >>>> + #reset-cells = <1>;
> >>>> + };
> >>>> +
> >>
> >> --
> >> Thanks,
> >> Taniya Das
> >>
> >
>
> --
> Thanks,
> Taniya Das
>

--
With best wishes
Dmitry