On Tue, Aug 20, 2024 at 11:12:45PM +0300, Cristian Ciocaltea wrote:
On 8/20/24 7:14 PM, Conor Dooley wrote:
quoted
On Tue, Aug 20, 2024 at 03:37:44PM +0300, Cristian Ciocaltea wrote:
quoted
On 8/19/24 7:53 PM, Conor Dooley wrote:
quoted
On Mon, Aug 19, 2024 at 01:29:30AM +0300, Cristian Ciocaltea wrote:
quoted
+ rockchip,grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Most HDMI QP related data is accessed through SYS GRF regs.
+
+ rockchip,vo1-grf:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Additional HDMI QP related data is accessed through VO1 GRF regs.
Why are these required? What prevents you looking up the syscons by
compatible?
That is for getting the proper instance:
Ah, that makes sense. I am, however, curious why these have the same
compatible when they have different sized regions allocated to them.
Good question, didn't notice. I've just checked the TRM and, in both
cases, the maximum register offset is within the 0x100 range. Presumably
this is nothing but an inconsistency, as the syscons have been added in
separate commits.
Is that TRM publicly available? I do find it curious that devices sound
like they have different contents have the same compatible. In my view,
that is incorrect and they should have unique compatibles if the
contents (and therefore the programming model) differs.
quoted
quoted
vo0_grf: syscon@fd5a6000 {
compatible = "rockchip,rk3588-vo-grf", "syscon";
reg = <0x0 0xfd5a6000 0x0 0x2000>;
clocks = <&cru PCLK_VO0GRF>;
};
vo1_grf: syscon@fd5a8000 {
compatible = "rockchip,rk3588-vo-grf", "syscon";
reg = <0x0 0xfd5a8000 0x0 0x100>;
clocks = <&cru PCLK_VO1GRF>;
};