Hi Mathieu,
On 28/11/2019 17:20, Mathieu Poirier wrote:
On Thu, 28 Nov 2019 at 03:54, Suzuki Kuruppassery Poulose suzuki.poulose@arm.com wrote:
On 19/11/2019 23:19, Mike Leach wrote:
Adds in sysfs programming support for the CTI function register sets. Allows direct manipulation of channel / trigger association registers.
Reviewed-by: Mathieu Poirier mathieu.poirier@linaro.org Signed-off-by: Mike Leach mike.leach@linaro.org
+/*
- #define CTI_DEBUG_INTEGRATION_CTRL to enable the access to the integration
- control registers. Normally only used to investigate connection data.
- */
On a second thought, I have some comments on this symbol.
Given that the integration control registers may be useful for people to find the device connections, I strongly feel that this is provided via a CONFIG symbol rather than a debug symbol within the code.
Device connections can be discovered with the dynamic sysfs connection entries added as part of patch 09. In cases where that is not
Yes, that correct. That happens only if the DT/ACPI describes the connections.
sufficient and people really need to use the integration control registers they are probably instrumenting the code anyway.
In this case given the CTI number of triggers and connections, this step is to identify the connections in the first place, so that they can be described in the DT/ACPI. Of course this is not a common activity, but more of a board bring up activity. Thus, we can't expect the board bringup engineer to necessarily know how to modify the driver to get this exposed. Having a Kconfig entry, with a help text makes this easier for them to avoid fiddling with the code. Hope this is clearer now.
Cheers Suzuki
i.e, CONFIG_CTI_DEBUG_INTEGRATION_CTRL, to help the people better. Codewise this doesn't make much difference, but it certainly makes it more easier for people to use it.
I agree that code-wise it doesn't make much difference but I'm really not convinced it makes the driver easier to use, and one needs to recompile their kernel for production systems anyway.
Thanks, Mathieu
We have used debug symbols elsewhere in the drivers for pure functional debugging purposes. However I feel this is case is superior.
Cheers Suzuki