Messages in this thread | | | Date | Fri, 7 Jan 2022 21:13:16 +0530 | Subject | Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845 | From | Souradeep Chowdhury <> |
| |
On 1/7/2022 5:35 AM, Bjorn Andersson wrote: > On Thu 06 Jan 07:20 PST 2022, Souradeep Chowdhury wrote: > >> On 12/16/2021 9:18 PM, Thara Gopinath wrote: >>> >>> On 8/10/21 1:54 PM, Souradeep Chowdhury wrote: >>>> DCC(Data Capture and Compare) is a DMA engine designed for debugging >>>> purposes.In case of a system >>>> crash or manual software triggers by the user the DCC hardware >>>> stores the value at the register >>>> addresses which can be used for debugging purposes.The DCC driver >>>> provides the user with sysfs >>>> interface to configure the register addresses.The options that the >>>> DCC hardware provides include >>>> reading from registers,writing to registers,first reading and then >>>> writing to registers and looping >>>> through the values of the same register. >>>> >>>> In certain cases a register write needs to be executed for accessing >>>> the rest of the registers, >>>> also the user might want to record the changing values of a register >>>> with time for which he has the >>>> option to use the loop feature. >>> Hello Souradeep, >>> >>> First of all, I think this is very a useful feature to have. I have some >>> generic design related queries/comments on driver and the interface >>> exposed to the user space. Also, I do not understand the h/w well here, >>> so feel free to correct me if I am wrong. >>> >>> 1. Linked list looks like a very internal feature to the h/w. It really >>> is not an info that user should be aware of. I tried reading the code a >>> bit. IUC, every time a s/w trigger is issued the configs in all the >>> enabled linked lists are executed. The final ram dump that you get from >>> /dev/dcc_sram is a dump of contents from all the enabled list? Is this >>> understanding correct ? And we are talking of at-most 4 linked list? >>> If yes, I think it might be better to have a folder per linked list with >>> config, config_write etc. Also if possible it will be better to dump the >>> results to a file in the specific folder instead of reading from >>> /dev/dcc_sram. >>> If no, there is no real need for user to know the linked list, right? >>> Choosing of linked list can be done by kernel driver in this case with >>> no input needed from user. >>> >>> 2. Now to the sysfs interface itself, I know lot of thought has gone >>> into sysfs vs debugfs considerations. But, have you considered using >>> netlink interface instead of sysfs. Netlink interface is used for >>> asynchronous communication between kernel and user space. In case of >>> DCC, the communication appears to be asynchronous, where in user asks >>> the kernel to capture some info and kernel can indicate back to user >>> when the info is captured. Also the entire mess surrounding echoing addr >>> / value / offset repeatedly into a sysfs entry can be avoided using >>> netlink interface. >>> >> Hello Thara, >> >> Thanks for your review comments. Following are some points from my end >> >> >> 1) Each linked list represent a particular block of memory in DCC_SRAM which >> is preserved for that particular list. That is why offset calculation is >> done on the driver based on the linked list chosen by the user. >> >> This choice needs to be made by the user since the number for the linked >> list chosen is specific to the registers used to debug a particular >> component. Also we are giving the user flexibility to configure multiple >> >> linked lists at one go so that even if we don't have a separate folder >> for it , the dumps are collected as a separate list of registers. Also there >> are certain curr_list values which may be supported by the dcc >> >> hardware but may not be accessible to the user and so the choice cannot >> be made arbitrarily from the driver. >> > But in the end, as you write out the SRAM content, is there really any > linked lists? Afaict it's just a sequence of operations/commands. The > linked list part seems to be your data structure of choice to keep track > of these operations in the driver before flushing them out.
That is correct, the linked list defined in the driver is for storing the addresses sequentially in DCC_SRAM and is just an internal
data structure of the driver. However, there is also a "list" from DCC hardware perspective. The following driver code shows how
a list is initiated with the beginning and end sram offset so that DCC hardware can treat it as a separate list of addresses and dump
the values separately.
/* 1. Take ownership of the list */ dcc_writel(drvdata, BIT(0), DCC_LL_LOCK(list));
/* 2. Program linked-list in the SRAM */ ram_cfg_base = drvdata->ram_cfg; ret = __dcc_ll_cfg(drvdata, list); if (ret) { dcc_writel(drvdata, 0, DCC_LL_LOCK(list)); goto err; }
/* 3. program DCC_RAM_CFG reg */ dcc_writel(drvdata, ram_cfg_base + drvdata->ram_offset/4, DCC_LL_BASE(list)); dcc_writel(drvdata, drvdata->ram_start + drvdata->ram_offset/4, DCC_FD_BASE(list)); dcc_writel(drvdata, 0xFFF, DCC_LL_TIMEOUT(list));
/* 4. Clears interrupt status register */ dcc_writel(drvdata, 0, DCC_LL_INT_ENABLE(list)); dcc_writel(drvdata, (BIT(0) | BIT(1) | BIT(2)), DCC_LL_INT_STATUS(list));
drvdata->enable[list] = true;
So when user enters multiple lists, the DCC hardware will process it as separate group of register values.
> > Regards, > Bjorn > >> 2) From opensource, I can see that Netlink has been used in most of the >> cases where we need to notify stats to the user by taking the advantage of >> asynchronous communication. In this case, that requirement is not >> >> there since it is mostly one way communication from user to kernel. Also >> since this is used for debugging purposes perhaps sysfs adds more >> reliability than Netlink. In case of Netlink we have the additional >> >> overhead of dealing with socket calls. Let me know otherwise. >> >> >> Thanks, >> >> Souradeep >> >> >> >> >>
| |