On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
The following is the justification of using debugfs interface over the
other alternatives like sysfs/ioctls
i) As can be seen from the debugfs attribute descriptions, some of the
debugfs attribute files here contains multiple arguments which needs to
be accepted from the user. This goes against the design style of sysfs.
ii) The user input patterns have been made simple and convenient in this
case with the use of debugfs interface as user doesn't need to shuffle
between different files to execute one instruction as was the case on
using other alternatives.
Why do you have debugfs and also a misc device? How are they related?
Why both? Why not just one? What userspace tools are going to use
either of these interfaces and where are they published to show how this
all was tested?
DCC has two fundamental steps of usage:-
1.Configuring the register addresses on the dcc_sram which is done by
user through the debugfs interface. For example:-
echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
Here we are configuring the register addresses for list 3, the 'R'
indicates a read operation, so this register value will be read
in case of a software trigger or kernel panic/watchdog bite and
dumped into the dcc_sram.
Can you describe why the register location needs to be
runtime configurable? I would have expected this type of setting
to be part of the devicetree, which already describes other
parts that interact with sram devices.
Register addresses are made runtime configurable to give the user the
option of going for a software trigger. So the user can debug issues
during run-time as well. These register locations are arbitrary
and is configured by the user for debugging purposes and is not related
to the DCC hardware itself.
How does a user ensure that the address they configure does
not overlap with some other use of the sram?
The dcc_sram is a dedicated io-memory for exclusive usage by dcc.
The register addresses are programmed in the dcc_sram corresponding
to a particular list and the start and end location on dcc_sram for
a particular list is updated in dcc hardware registers. So no two
lists can overlap. This is ensured by the driver code as follows:-
/* 3. Program DCC_RAM_CFG reg */
dcc_list_writel(drvdata, ram_cfg_base +
drvdata->ram_offset / 4, curr_list, DCC_LL_BASE);
dcc_list_writel(drvdata, drvdata->ram_start +
drvdata->ram_offset / 4, curr_list, DCC_FD_BASE);
Arnd
