drivers: firmware: Clock control TISCI driver support

[Kronosblaster]

Support added for clock control using TISCI added for devices using the binding ti,k2g-sci-clk. This PR waits on #90053

Testing

Refer: ClockControllerTest

Output:

DMSC Firmware Version 11.0.7--v11.00.07 (Fancy Rat)                                                 
DMSC Firmware revision 0xb                                                                          
DMSC ABI revision 4.0                                                                               
                                                                                                    
INFO: Bootloader_runCpu:205: CPU r5f1-0  is initialized to 800000000 Hz !!!                         
INFO: Bootloader_runCpu:205: CPU r5f1-1 is initialized to 800000000 Hz !!!                          
INFO: Bootloader_runCpu:205: CPU m4f0-0 is initialized to 400000000 Hz !!!                          
INFO: Bootloader_runCpu:205: CPU a530-0 is initialized to 800000000 Hz !!!                          
INFO: Bootloader_runCpu:205: CPU a530-1 is initialized to 800000000 Hz !!!                          
INFO: Bootloader_loadSelfCpu:257: CPU r5f0-0 is initialized to 800000000 Hz !!!                     
INFO: Bootloader_loadSelfCpu:257: CPU r5f0-1 is initialized to 800000000 Hz !!!                     
INFO: Bootloader_runSelfCpu:267: All done, reseting self ...                                        
                                                                                                    
*** Booting Zephyr OS build v4.1.0-5562-g50269a5c5de1 ***                                           
Current clock rate: 48000000                                                                        
Clock rate set to 96000000                                                                          
Clock rate set to 48000000                                                                          
Current clock rate after set: 48000000                                                              
All clock controller tests passed! 

[JarmouniA]

Should be enabled on at least one board in-tree and be tested with an existing or a new testsuite.

[Kronosblaster]

Should be enabled on at least one board in-tree and be tested with an existing or a new testsuite.

This driver currently only wraps the merged #90053 (TISCI driver). Its use-case #91914 depends on multiple subsystems and is organized into another PR which will contain the required in-tree changes.

[vaishnavachath]

@Kronosblaster It looks

Should be enabled on at least one board in-tree and be tested with an existing or a new testsuite.

This driver currently only wraps the merged #90053 (TISCI driver). Its use-case #91914 depends on multiple subsystems and is organized into another PR which will contain the required in-tree changes.

@Kronosblaster , it looks like #91914 has build errors, how was this tested? and how do we ensure that this is not merged in a broken state?

[JarmouniA]

This driver currently only wraps the merged #90053 (TISCI driver). Its use-case #91914 depends on multiple subsystems and is organized into another PR which will contain the required in-tree changes.

When there is serial dependency between PRs, to ensure we are not merging stuff that doesn't even compile, you should do:

For PRs A, B, & C, where C depends on B, B depends on A, and assuming C contains the actual tests that will validate all the code in the 3 PRs,
Send the 3 PRs, but only put A as ready for review, and include A in B, and A&B in C,
And any changes to A, should be propagated to B, then B to C...
This way, when reviewing A, we can see if stuff works by testing C.
Then redo the process for B, once A is merged...

[Kronosblaster]

@Kronosblaster It looks

Should be enabled on at least one board in-tree and be tested with an existing or a new testsuite.

This driver currently only wraps the merged #90053 (TISCI driver). Its use-case #91914 depends on multiple subsystems and is organized into another PR which will contain the required in-tree changes.

@Kronosblaster , it looks like #91914 has build errors, how was this tested? and how do we ensure that this is not merged in a broken state?

As @JarmouniA mentioned the PR #91914 has be converted to a draft with this PR added so as to enable testing

[JarmouniA]

Adding DNM until testing is done

[Kronosblaster]

Adding DNM until testing is done

#91914 shows errors unrelated to the PR
Refer: #92170 (comment)

[JarmouniA]

@Kronosblaster I don't see #91914 enabling any tests that will cover the added code here & there. Are there already test scenarios in-tree that cover it?

[Kronosblaster]

@Kronosblaster I don't see #91914 enabling any tests that will cover the added code here & there. Are there already test scenarios in-tree that cover it?

The TISCI clock control framework only frames and wraps TISCI API calls which have in-tree tests. A similar implementation would be the SCMI clock controller framework which does not have specific tests for clock layer either.
Refer: #75102

[natto1784]

The failing twister test should be fixed by this #98388. Ergo, this patchset can be merged.

[Kronosblaster]

The failing twister test should be fixed by this #98388. Ergo, this patchset can be merged.

@JarmouniA Can this be merged?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud