[no subject]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As I understand, each clock definition corresponds to the clock CG
settings provided to different hardware, and each hardware driver can
control its own clock CG through the CCF to control their CG in clock
driver. So they can be an abstraction values between driver and DTS.

Similarly, the GCE subsys ID and GCE event ID correspond to symbols
used by GCE to control various hardware, and each hardware driver can
use these IDs to generate commands buffer for GCE through the API
provided by the GCE driver and achieve the desired control over their
hardware.

I guess the difference is that the clock driver has a platform-specific
clock table to store these binding headers, while the GCE driver does
not have a platform-specific thread priority table, subsys ID table,
and event ID table. Instead, the GCE client drivers can directly obtain
their respective hardware settings from the DTS.

On the other hand, definitions like CLK_TOP_MAINPLL_D3,
CLK_TOP_MAINPLL_D4, etc., correspond to different clock frequency
divider levels, and the CMDQ_THR_PRIO_X for GCE thread priority also
corresponds to different priority levels for GCE threads. Therefore, I
am not quite sure why GCE thread priority cannot be considered a
binding when it is also a symbol number for a hardware level setting.


If the condition for becoming a binding header is that it `must` be
used by a specific driver, such as a platform-specific table, then I
will remove the entire GCE dt-binding header. Because the current usage
of these definitions is that each GCE client drivers can directly store
these GCE definitions through the DTS, just like IRQ IDs, and without
the need for an additional table defined by the GCE driver.


I am not unwilling to change the code, but I hope to first understand
what qualifies as a binding header.
This way, I can confidently remove the MT8196 GCE binding header,
and other developers will also know that the GCE binding header for the
previous MTXXXX is not needed.

I sincerely hope you can guide me to meet your expectations and
standards.

Regards,
Jason-JH.Lin

> 
> >      ```
> 
> Best regards,
> Krzysztof
> 




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux