Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[Alex Elder]

On 8/10/21 12: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.

I realize this was posted a long time ago but I spent a little
time on it today, and I have some comments for you to consider.
You'll need to post another version of this series if you're
going to address some of my comments.

Most of the comments are in patch 2, which contains all the code
and the sysfs documentation.  I have no comments on patches 3
(MAINTAINERS update) or 4 through 7 (DTS updates for specific
platforms).

First, a few comments on this cover page.  The most trivial
comment is:  Please make your lines narrower than 80 columns,
like the rest of the patches.

I appreciate that this goes into some detail about how this
feature has been used.  But I think it could benefit from
a little better high-level overview of what it *does*.
Your first paragraph is a concise summary, but I find it
doesn't evoke a model in my mind of what exactly is going
on, or what the hardware is doing.  In fact, if you can
provide a good high-level overview it might belong at the
top of "dcc.c" in comments.

Looking at the code (but not in any great depth), I see
that there are "linked lists" of what appear to be things
for the hardware to do with memory when this hardware is
"triggered."  If I understand it right, there can be up
to 8 of these lists (though some versions of hardware
might advertise the number supported via a register).

If the following is wrong, I hope you'll offer a comparable
explanation and will correct my misunderstanding.

Each list consists of a set of actions to take.  The actions
available include: reading a register (possibly <count> times
in succession); writing a register; and read/modify/writing
a register (affecting only bits in a given mask).  Actually,
the way looping works is a little confusing to me.

Each list can be enabled and disabled separately.  When
triggered, all lists are executed, and (somehow) the result
is saved into a buffer that can be read via /dev/dcc_sram.

So you use these sysfs files to configure the actions you'd
like to take when a "trigger" is signaled.  The content of
/dev/dcc_sram can then be read to see what output your
lists produced.

Is that close to correct?  If it is, great; I want to be
sure I understand what the hardware is supposed to do
before I comment much more on the way you represent it
in the driver and in sysfs.

> 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.
> 
> The options mentioned above are exposed to the user by sysfs files once the driver is probed.The
> details and usage of this sysfs files are documented in Documentation/ABI/testing/sysfs-driver-dcc.

Once you've confirmed I understand what's supposed to happen
when the trigger fires, I think I'll have some comments on
the way you represent the actions in these lists.  But
for now, maybe keep things as you have them, but address
some of the comments I'm giving you today.  Copy me on
future revisions and I'll plan to review again.

OK, that's enough on this file for now.  Onto the binding and
the code...

					-Alex

> As an example let us consider a couple of debug scenarios where DCC has been proved to be effective
> for debugging purposes:-
> 
> i)TimeStamp Related Issue
> 
> On SC7180, there was a coresight timestamp issue where it would occasionally be all 0 instead of proper
> timestamp values.
> 
> Proper timestamp:
> Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x13004d8f5b7aa; CC=0x9e
> 
> Zero timestamp:
> Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2
> 
> Now this is a non-fatal issue and doesn't need a system reset, but still needs
> to be rootcaused and fixed for those who do care about coresight etm traces.
> Since this is a timestamp issue, we would be looking for any timestamp related
> clocks and such.
> 
> o we get all the clk register details from IP documentation and configure it
> via DCC config syfs node. Before that we set the current linked list.
> 
> /* Set the current linked list */
> echo 3 > /sys/bus/platform/devices/10a2000.dcc/curr_list
> 
> /* Program the linked list with the addresses */
> echo 0x10c004 > /sys/bus/platform/devices/10a2000.dcc/config
> echo 0x10c008 > /sys/bus/platform/devices/10a2000.dcc/config
> echo 0x10c00c > /sys/bus/platform/devices/10a2000.dcc/config
> echo 0x10c010 > /sys/bus/platform/devices/10a2000.dcc/config
> ..... and so on for other timestamp related clk registers
> 
> /* Other way of specifying is in "addr len" pair, in below case it
> specifies to capture 4 words starting 0x10C004 */
> 
> echo 0x10C004 4 > /sys/bus/platform/devices/10a2000.dcc/config
> 
> /* Enable DCC */
> echo 1 > /sys/bus/platform/devices/10a2000.dcc/enable
> 
> /* Run the timestamp test for working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram1.bin
> 
> /* Run the timestamp test for non-working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram2.bin
> 
> Get the parser from [1] and checkout the latest branch.
> 
> /* Parse the SRAM bin */
> python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
> python dcc_parser.py -s dcc_sram2.bin --v2 -o output/
> 
> Sample parsed output of dcc_sram1.bin:
> 
> <hwioDump version="1">
>          <timestamp>03/14/21</timestamp>
>              <generator>Linux DCC Parser</generator>
>                  <chip name="None" version="None">
>                  <register address="0x0010c004" value="0x80000000" />
>                  <register address="0x0010c008" value="0x00000008" />
>                  <register address="0x0010c00c" value="0x80004220" />
>                  <register address="0x0010c010" value="0x80000000" />
>              </chip>
>      <next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
> </hwioDump>
> 
> ii)NOC register errors
> 
> A particular class of registers called NOC which are functional registers was reporting
> errors while logging the values.To trace these errors the DCC has been used effectively.
> The steps followed were similar to the ones mentioned above.
> In addition to NOC registers a few other dependent registers were configured in DCC to
> monitor it's values during a crash. A look at the dependent register values revealed that
> the crash was happening due to a secured access to one of these dependent registers.
> All these debugging activity and finding the root cause was achieved using DCC.
> 
> DCC parser is available at the following open source location
> 
> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser
> 
> Changes in v6:
> 
> *Added support in the dcc driver to handle multiple Qualcomm SoCs including SC7180,SC7280,SDM845
>   along with existing SM8150.
>   
> *Added the support node in the respective device tree files for SC7180,SC7280,SDM845.
> 
> Souradeep Chowdhury (7):
>    dt-bindings: Added the yaml bindings for DCC
>    soc: qcom: dcc:Add driver support for Data Capture and Compare
>      unit(DCC)
>    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>      support
>    arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support
>      node
>    arm64: dts: qcom: sc7280: Add Data Capture and Compare(DCC) support
>      node
>    arm64: dts: qcom: sc7180: Add Data Capture and Compare(DCC) support
>      node
>    arm64: dts: qcom: sdm845: Add Data Capture and Compare(DCC) support
>      node
> 
>   Documentation/ABI/testing/sysfs-driver-dcc         |  114 ++
>   .../devicetree/bindings/arm/msm/qcom,dcc.yaml      |   43 +
>   MAINTAINERS                                        |    8 +
>   arch/arm64/boot/dts/qcom/sc7180.dtsi               |    6 +
>   arch/arm64/boot/dts/qcom/sc7280.dtsi               |    6 +
>   arch/arm64/boot/dts/qcom/sdm845.dtsi               |    6 +
>   arch/arm64/boot/dts/qcom/sm8150.dtsi               |    6 +
>   drivers/soc/qcom/Kconfig                           |    8 +
>   drivers/soc/qcom/Makefile                          |    1 +
>   drivers/soc/qcom/dcc.c                             | 1549 ++++++++++++++++++++
>   10 files changed, 1747 insertions(+)
>   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>   create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
>   create mode 100644 drivers/soc/qcom/dcc.c
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[Souradeep Chowdhury]

On 12/14/2021 4:05 AM, Alex Elder wrote:
> On 8/10/21 12: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.
>
> I realize this was posted a long time ago but I spent a little
> time on it today, and I have some comments for you to consider.
> You'll need to post another version of this series if you're
> going to address some of my comments.
>
> Most of the comments are in patch 2, which contains all the code
> and the sysfs documentation.  I have no comments on patches 3
> (MAINTAINERS update) or 4 through 7 (DTS updates for specific
> platforms).
>
> First, a few comments on this cover page.  The most trivial
> comment is:  Please make your lines narrower than 80 columns,
> like the rest of the patches.
>
> I appreciate that this goes into some detail about how this
> feature has been used.  But I think it could benefit from
> a little better high-level overview of what it *does*.
> Your first paragraph is a concise summary, but I find it
> doesn't evoke a model in my mind of what exactly is going
> on, or what the hardware is doing.  In fact, if you can
> provide a good high-level overview it might belong at the
> top of "dcc.c" in comments.
>
> Looking at the code (but not in any great depth), I see
> that there are "linked lists" of what appear to be things
> for the hardware to do with memory when this hardware is
> "triggered."  If I understand it right, there can be up
> to 8 of these lists (though some versions of hardware
> might advertise the number supported via a register).
>
> If the following is wrong, I hope you'll offer a comparable
> explanation and will correct my misunderstanding.
>
> Each list consists of a set of actions to take.  The actions
> available include: reading a register (possibly <count> times
> in succession); writing a register; and read/modify/writing
> a register (affecting only bits in a given mask).  Actually,
> the way looping works is a little confusing to me.
>
> Each list can be enabled and disabled separately.  When
> triggered, all lists are executed, and (somehow) the result
> is saved into a buffer that can be read via /dev/dcc_sram.
>
> So you use these sysfs files to configure the actions you'd
> like to take when a "trigger" is signaled.  The content of
> /dev/dcc_sram can then be read to see what output your
> lists produced.
>
> Is that close to correct?  If it is, great; I want to be
> sure I understand what the hardware is supposed to do
> before I comment much more on the way you represent it
> in the driver and in sysfs.
>
>> 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.
>>
>> The options mentioned above are exposed to the user by sysfs files 
>> once the driver is probed.The
>> details and usage of this sysfs files are documented in 
>> Documentation/ABI/testing/sysfs-driver-dcc.
>
> Once you've confirmed I understand what's supposed to happen
> when the trigger fires, I think I'll have some comments on
> the way you represent the actions in these lists.  But
> for now, maybe keep things as you have them, but address
> some of the comments I'm giving you today.  Copy me on
> future revisions and I'll plan to review again.
>
> OK, that's enough on this file for now.  Onto the binding and
> the code...
>
>                     -Alex
>
Hi Alex.

Thanks for your feedback. The understanding is correct regarding DCC 
hardware.

Will address all the comments and post the next version copying you.

Thanks,

Souradeep

>> As an example let us consider a couple of debug scenarios where DCC 
>> has been proved to be effective
>> for debugging purposes:-
>>
>> i)TimeStamp Related Issue
>>
>> On SC7180, there was a coresight timestamp issue where it would 
>> occasionally be all 0 instead of proper
>> timestamp values.
>>
>> Proper timestamp:
>> Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 
>> 0x13004d8f5b7aa; CC=0x9e
>>
>> Zero timestamp:
>> Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2
>>
>> Now this is a non-fatal issue and doesn't need a system reset, but 
>> still needs
>> to be rootcaused and fixed for those who do care about coresight etm 
>> traces.
>> Since this is a timestamp issue, we would be looking for any 
>> timestamp related
>> clocks and such.
>>
>> o we get all the clk register details from IP documentation and 
>> configure it
>> via DCC config syfs node. Before that we set the current linked list.
>>
>> /* Set the current linked list */
>> echo 3 > /sys/bus/platform/devices/10a2000.dcc/curr_list
>>
>> /* Program the linked list with the addresses */
>> echo 0x10c004 > /sys/bus/platform/devices/10a2000.dcc/config
>> echo 0x10c008 > /sys/bus/platform/devices/10a2000.dcc/config
>> echo 0x10c00c > /sys/bus/platform/devices/10a2000.dcc/config
>> echo 0x10c010 > /sys/bus/platform/devices/10a2000.dcc/config
>> ..... and so on for other timestamp related clk registers
>>
>> /* Other way of specifying is in "addr len" pair, in below case it
>> specifies to capture 4 words starting 0x10C004 */
>>
>> echo 0x10C004 4 > /sys/bus/platform/devices/10a2000.dcc/config
>>
>> /* Enable DCC */
>> echo 1 > /sys/bus/platform/devices/10a2000.dcc/enable
>>
>> /* Run the timestamp test for working case */
>>
>> /* Send SW trigger */
>> echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
>>
>> /* Read SRAM */
>> cat /dev/dcc_sram > dcc_sram1.bin
>>
>> /* Run the timestamp test for non-working case */
>>
>> /* Send SW trigger */
>> echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
>>
>> /* Read SRAM */
>> cat /dev/dcc_sram > dcc_sram2.bin
>>
>> Get the parser from [1] and checkout the latest branch.
>>
>> /* Parse the SRAM bin */
>> python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
>> python dcc_parser.py -s dcc_sram2.bin --v2 -o output/
>>
>> Sample parsed output of dcc_sram1.bin:
>>
>> <hwioDump version="1">
>>          <timestamp>03/14/21</timestamp>
>>              <generator>Linux DCC Parser</generator>
>>                  <chip name="None" version="None">
>>                  <register address="0x0010c004" value="0x80000000" />
>>                  <register address="0x0010c008" value="0x00000008" />
>>                  <register address="0x0010c00c" value="0x80004220" />
>>                  <register address="0x0010c010" value="0x80000000" />
>>              </chip>
>>      <next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
>> </hwioDump>
>>
>> ii)NOC register errors
>>
>> A particular class of registers called NOC which are functional 
>> registers was reporting
>> errors while logging the values.To trace these errors the DCC has 
>> been used effectively.
>> The steps followed were similar to the ones mentioned above.
>> In addition to NOC registers a few other dependent registers were 
>> configured in DCC to
>> monitor it's values during a crash. A look at the dependent register 
>> values revealed that
>> the crash was happening due to a secured access to one of these 
>> dependent registers.
>> All these debugging activity and finding the root cause was achieved 
>> using DCC.
>>
>> DCC parser is available at the following open source location
>>
>> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser 
>>
>>
>> Changes in v6:
>>
>> *Added support in the dcc driver to handle multiple Qualcomm SoCs 
>> including SC7180,SC7280,SDM845
>>   along with existing SM8150.
>>   *Added the support node in the respective device tree files for 
>> SC7180,SC7280,SDM845.
>>
>> Souradeep Chowdhury (7):
>>    dt-bindings: Added the yaml bindings for DCC
>>    soc: qcom: dcc:Add driver support for Data Capture and Compare
>>      unit(DCC)
>>    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>>      support
>>    arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support
>>      node
>>    arm64: dts: qcom: sc7280: Add Data Capture and Compare(DCC) support
>>      node
>>    arm64: dts: qcom: sc7180: Add Data Capture and Compare(DCC) support
>>      node
>>    arm64: dts: qcom: sdm845: Add Data Capture and Compare(DCC) support
>>      node
>>
>>   Documentation/ABI/testing/sysfs-driver-dcc         |  114 ++
>>   .../devicetree/bindings/arm/msm/qcom,dcc.yaml      |   43 +
>>   MAINTAINERS                                        |    8 +
>>   arch/arm64/boot/dts/qcom/sc7180.dtsi               |    6 +
>>   arch/arm64/boot/dts/qcom/sc7280.dtsi               |    6 +
>>   arch/arm64/boot/dts/qcom/sdm845.dtsi               |    6 +
>>   arch/arm64/boot/dts/qcom/sm8150.dtsi               |    6 +
>>   drivers/soc/qcom/Kconfig                           |    8 +
>>   drivers/soc/qcom/Makefile                          |    1 +
>>   drivers/soc/qcom/dcc.c                             | 1549 
>> ++++++++++++++++++++
>>   10 files changed, 1747 insertions(+)
>>   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>>   create mode 100644 
>> Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
>>   create mode 100644 drivers/soc/qcom/dcc.c
>>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 1/7] dt-bindings: Added the yaml bindings for DCC

[Alex Elder]

On 8/10/21 12:54 PM, Souradeep Chowdhury wrote:
> Documentation for Data Capture and Compare(DCC) device tree bindings
> in yaml format.

Even though Rob has already reviewed this...  I think it
would be nice if you gave these memory regions names, such
as "config" for the first one and "sram" or something for
the second one.  It's a little more descriptive than just
looking them up using their positions.

					-Alex

> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org>
> ---
>   .../devicetree/bindings/arm/msm/qcom,dcc.yaml      | 43 ++++++++++++++++++++++
>   1 file changed, 43 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
> new file mode 100644
> index 0000000..b7a6619
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/msm/qcom,dcc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Data Capture and Compare
> +
> +maintainers:
> +  - Souradeep Chowdhury <schowdhu@codeaurora.org>
> +
> +description: |
> +    DCC (Data Capture and Compare) is a DMA engine which is used to save
> +    configuration data or system memory contents during catastrophic failure
> +    or SW trigger. DCC is used to capture and store data for debugging purpose
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - qcom,sm8150-dcc
> +          - qcom,sc7280-dcc
> +          - qcom,sc7180-dcc
> +          - qcom,sdm845-dcc
> +      - const: qcom,dcc
> +
> +  reg:
> +    items:
> +      - description: DCC base register region
> +      - description: DCC RAM base register region
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    dma@10a2000{
> +                compatible = "qcom,sm8150-dcc","qcom,dcc";
> +                reg = <0x010a2000  0x1000>,
> +                      <0x010ad000  0x2000>;
> +    };
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[Thara Gopinath]

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.

-- 
Warm Regards
Thara (She/Her/Hers)
> 
> The options mentioned above are exposed to the user by sysfs files once the driver is probed.The
> details and usage of this sysfs files are documented in Documentation/ABI/testing/sysfs-driver-dcc.
> 
> As an example let us consider a couple of debug scenarios where DCC has been proved to be effective
> for debugging purposes:-
> 
> i)TimeStamp Related Issue
> 
> On SC7180, there was a coresight timestamp issue where it would occasionally be all 0 instead of proper
> timestamp values.
> 
> Proper timestamp:
> Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x13004d8f5b7aa; CC=0x9e
> 
> Zero timestamp:
> Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2
> 
> Now this is a non-fatal issue and doesn't need a system reset, but still needs
> to be rootcaused and fixed for those who do care about coresight etm traces.
> Since this is a timestamp issue, we would be looking for any timestamp related
> clocks and such.
> 
> o we get all the clk register details from IP documentation and configure it
> via DCC config syfs node. Before that we set the current linked list.
> 
> /* Set the current linked list */
> echo 3 > /sys/bus/platform/devices/10a2000.dcc/	
> 
> /* Program the linked list with the addresses */
> echo 0x10c004 > /sys/bus/platform/devices/10a2000.dcc/config
> echo 0x10c008 > /sys/bus/platform/devices/10a2000.dcc/config
> echo 0x10c00c > /sys/bus/platform/devices/10a2000.dcc/config
> echo 0x10c010 > /sys/bus/platform/devices/10a2000.dcc/config
> ..... and so on for other timestamp related clk registers
> 
> /* Other way of specifying is in "addr len" pair, in below case it
> specifies to capture 4 words starting 0x10C004 */
> 
> echo 0x10C004 4 > /sys/bus/platform/devices/10a2000.dcc/config
> 
> /* Enable DCC */
> echo 1 > /sys/bus/platform/devices/10a2000.dcc/enable
> 
> /* Run the timestamp test for working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram1.bin
> 
> /* Run the timestamp test for non-working case */
> 
> /* Send SW trigger */
> echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
> 
> /* Read SRAM */
> cat /dev/dcc_sram > dcc_sram2.bin
> 
> Get the parser from [1] and checkout the latest branch.
> 
> /* Parse the SRAM bin */
> python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
> python dcc_parser.py -s dcc_sram2.bin --v2 -o output/
> 
> Sample parsed output of dcc_sram1.bin:
> 
> <hwioDump version="1">
>          <timestamp>03/14/21</timestamp>
>              <generator>Linux DCC Parser</generator>
>                  <chip name="None" version="None">
>                  <register address="0x0010c004" value="0x80000000" />
>                  <register address="0x0010c008" value="0x00000008" />
>                  <register address="0x0010c00c" value="0x80004220" />
>                  <register address="0x0010c010" value="0x80000000" />
>              </chip>
>      <next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
> </hwioDump>
> 
> ii)NOC register errors
> 
> A particular class of registers called NOC which are functional registers was reporting
> errors while logging the values.To trace these errors the DCC has been used effectively.
> The steps followed were similar to the ones mentioned above.
> In addition to NOC registers a few other dependent registers were configured in DCC to
> monitor it's values during a crash. A look at the dependent register values revealed that
> the crash was happening due to a secured access to one of these dependent registers.
> All these debugging activity and finding the root cause was achieved using DCC.
> 
> DCC parser is available at the following open source location
> 
> https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser
> 
> Changes in v6:
> 
> *Added support in the dcc driver to handle multiple Qualcomm SoCs including SC7180,SC7280,SDM845
>   along with existing SM8150.
>   
> *Added the support node in the respective device tree files for SC7180,SC7280,SDM845.
> 
> Souradeep Chowdhury (7):
>    dt-bindings: Added the yaml bindings for DCC
>    soc: qcom: dcc:Add driver support for Data Capture and Compare
>      unit(DCC)
>    MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
>      support
>    arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support
>      node
>    arm64: dts: qcom: sc7280: Add Data Capture and Compare(DCC) support
>      node
>    arm64: dts: qcom: sc7180: Add Data Capture and Compare(DCC) support
>      node
>    arm64: dts: qcom: sdm845: Add Data Capture and Compare(DCC) support
>      node
> 
>   Documentation/ABI/testing/sysfs-driver-dcc         |  114 ++
>   .../devicetree/bindings/arm/msm/qcom,dcc.yaml      |   43 +
>   MAINTAINERS                                        |    8 +
>   arch/arm64/boot/dts/qcom/sc7180.dtsi               |    6 +
>   arch/arm64/boot/dts/qcom/sc7280.dtsi               |    6 +
>   arch/arm64/boot/dts/qcom/sdm845.dtsi               |    6 +
>   arch/arm64/boot/dts/qcom/sm8150.dtsi               |    6 +
>   drivers/soc/qcom/Kconfig                           |    8 +
>   drivers/soc/qcom/Makefile                          |    1 +
>   drivers/soc/qcom/dcc.c                             | 1549 ++++++++++++++++++++
>   10 files changed, 1747 insertions(+)
>   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>   create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
>   create mode 100644 drivers/soc/qcom/dcc.c
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[Souradeep Chowdhury]

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.


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






_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[Bjorn Andersson]

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.

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
> 
> 
> 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[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
>>
>>
>>
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845

[Bjorn Andersson]

On Fri 07 Jan 07:43 PST 2022, Souradeep Chowdhury wrote:

> 
> 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.
> 

Makes sense. But I think you should use "list" (or "sequence") and not
"linked list" in the API/documentation then.

>               /* 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.
> 

But as the DCC supports reading, writing, looping and rmw I don't think
it's correct to say that a list is a "group of register values". It's a
"sequence (or list) of operations".

Regards,
Bjorn

> > 
> > 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
> > > 
> > > 
> > > 
> > > 
> > > 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Alex Elder]

On 8/10/21 12:54 PM, Souradeep Chowdhury wrote:
> The DCC is a DMA Engine designed to capture and store data
> during system crash or software triggers.The DCC operates
> based on user inputs via the sysfs interface.The user gives
> addresses as inputs and these addresses are stored in the
> form of linkedlists.In case of a system crash or a manual
> software trigger by the user through the sysfs interface,
> the dcc captures and stores the values at these addresses.
> This patch contains the driver which has all the methods
> pertaining to the sysfs interface, auxiliary functions to
> support all the four fundamental operations of dcc namely
> read, write, first read then write and loop.The probe method
> here instantiates all the resources necessary for dcc to
> operate mainly the dedicated dcc sram where it stores the
> values.The DCC driver can be used for debugging purposes
> without going for a reboot since it can perform manual
> triggers.

I don't understand what you're trying to say with the last
sentence above.

> Also added the documentation for sysfs entries
> and explained the functionalities of each sysfs file that
> has been created for dcc.

Could these files all land in debugfs, at least initially?
I guess if you get it right it's fine in sysfs, but unlike
sysfs, debugfs is not considered a stable user space API.

> The following is the justification of using sysfs interface
> over the other alternatives like ioctls
> 
> i) As can be seen from the sysfs attribute descriptions,
> most of it does basic hardware manipulations like dcc_enable,
> dcc_disable, config reset etc. As a result sysfs is preferred
> over ioctl as we just need to enter a 0 or 1.
> 
> ii) Existing similar debug hardwares are there for which drivers
> have been written using sysfs interface.One such example is the
> coresight-etm-trace driver.A closer analog can also be the watchdog
> subsystems though it is ioctls based.

Even if it eventually becomes a sysfs interface, it might
be better to initially land it in debugfs.  (Maybe others
disagree.)

Generally, it looks to me like this always reads memory in
32-bit units.  I might have missed it, but if that is not
documented it should be.  Also, is it OK to provide an
address that is not aligned on a 32-bit boundary?  I
presume memory is interpreted as CPU endian; does that
produce the most meaningful results if the offset isn't
aligned?

More comments, below.

					-Alex

> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org>
> ---
>   Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
>   drivers/soc/qcom/Kconfig                   |    8 +
>   drivers/soc/qcom/Makefile                  |    1 +
>   drivers/soc/qcom/dcc.c                     | 1549 ++++++++++++++++++++++++++++
>   4 files changed, 1672 insertions(+)
>   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>   create mode 100644 drivers/soc/qcom/dcc.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc
> new file mode 100644
> index 0000000..05d24f0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-dcc

Throughout this file, add a space or two after each period.

> @@ -0,0 +1,114 @@
> +What:           /sys/bus/platform/devices/.../trigger
> +Date:           March 2021

Probably update these dates when the code is close to
getting accepted.

> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This is the sysfs interface for manual software

Try to reword each of the descriptions so they don't
talk about "this sysfs interface."  Each one of these
*is* describing a sysfs interface file, so that can be
omitted from the description.  For example:

     This file is used to perform a manual trigger
     operation, causing all lists of memory operations
     to be executed.

Or something along those lines.

> +		triggers.The user can simply enter a 1 against
> +		the sysfs file and enable a manual trigger.
> +		Example:
> +		echo  1 > /sys/bus/platform/devices/.../trigger
> +
> +What:           /sys/bus/platform/devices/.../enable
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This sysfs interface is used for enabling the
> +		the dcc hardware.Without this being set to 1,
> +		the dcc hardware ceases to function.

This could/should use a standard Boolean interface.  That is,
parse the input in your code using kstrtobool() on the buffer
passed to your store function.


> +		Example:
> +		echo  0 > /sys/bus/platform/devices/.../enable
> +		(disable interface)
> +		echo  1 > /sys/bus/platform/devices/.../enable
> +		(enable interface)
> +
> +What:           /sys/bus/platform/devices/.../config
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This is the most commonly used sysfs interface
> +		file and this basically stores the addresses of

It doesn't matter if this is the "most commonly used" file.
Just describe what it does.

If I understand it right, you write a memory offset and
an (optional) number of consecutive memory addresses to
be read.

> +		the registers which needs to be read in case of
> +		a hardware crash or manual software triggers.
> +		Example:
> +		echo  0x80000010 10 > /sys/bus/platform/devices/../config
> +		This specifies that 10 words starting from address
> +		0x80000010 is to be read.In case there are no words to be
> +		specified we can simply enter the address.

I don't know what "in case there are no words to be specified"
means.  Does that just mean memory at exactly one offset is
read is implied if a count is not specified?

> +
> +What:           /sys/bus/platform/devices/.../config_write
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file allows user to write a value to the register
> +		address given as argument.The values are entered in the
> +		form of <register_address> <value>.The reason for this
> +		feature of dcc is that for accessing certain registers
> +		it is necessary to set some bits of soe other register.
> +		That is achievable by giving DCC this privelege.
> +		Example:
> +		echo 0x80000000 0xFF > /sys/bus/platform/devices/.../config_write
> +
> +What:           /sys/bus/platform/devices/.../config_reset
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to reset the configuration of
> +		a dcc driver to the default configuration.

What does it mean to "reset the driver to the default"?
Does that mean all lists of operations supplied previously
are forgotten, and the lists become empty and disabled?

> +		Example:
> +		echo  1 > /sys/bus/platform/devices/.../config_reset
> +
> +What:           /sys/bus/platform/devices/.../loop
> +Date:		March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:

Can looping be done for a write or read/modify/write operation,
or is it only used for reads?

Now skipping ahead to the code.

> +		This file is used to enter the loop count as dcc
> +		driver gives the option to loop multiple times on
> +		the same register and store the values for each

. . .

> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> new file mode 100644
> index 0000000..daf4388
> --- /dev/null
> +++ b/drivers/soc/qcom/dcc.c
> @@ -0,0 +1,1549 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/cdev.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +#define TIMEOUT_US		5000

This timeout is only used when polling the STATUS register to
determine when the DCC hardware is "ready".  Maybe the name
could reflect that (STATUS_READY_TIMEOUT?).

I think the next two might be better implemented as functions.
It would allow the compiler to do some additional type checking.

> +#define dcc_writel(drvdata, val, off)					\
> +	writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
> +#define dcc_readl(drvdata, off)						\
> +	readl(drvdata->base + dcc_offset_conv(drvdata, off))
> +
> +#define DCC_SRAM_NODE "dcc_sram"
> +
> +/* DCC registers */
> +#define DCC_HW_INFO			0x04
> +#define DCC_LL_NUM_INFO			0x10
> +#define DCC_STATUS			0x1C
> +#define DCC_LL_LOCK(m)			(0x34 + 0x80 * m)
> +#define DCC_LL_CFG(m)			(0x38 + 0x80 * m)
> +#define DCC_LL_BASE(m)			(0x3c + 0x80 * m)
> +#define DCC_FD_BASE(m)			(0x40 + 0x80 * m)
> +#define DCC_LL_TIMEOUT(m)		(0x44 + 0x80 * m)
> +#define DCC_LL_INT_ENABLE(m)		(0x4C + 0x80 * m)
> +#define DCC_LL_INT_STATUS(m)		(0x50 + 0x80 * m)
> +#define DCC_LL_SW_TRIGGER(m)		(0x60 + 0x80 * m)
> +#define DCC_LL_BUS_ACCESS_STATUS(m)	(0x64 + 0x80 * m)

The MAP_LEVEL and MAP_OFFSET definitions below, together
with the function dcc_offset_conv(), are a clever way to
have the above set of offsets "work" by mapping them to
(at least) three distinct "actual" addresses.  That is:

     if (map_ver == 1)

         if (0 <= offset < MAP_LEVEL_1)

             actual_offset = offset

         else if (MAP_LEVEL_1 <= offset < MAP_LEVEL_2)

             actual_offset = offset - MAP_OFFSET_1

         else if (MAP_LEVEL_2 <= offset < MAP_LEVEL_3)

             actual_offset = offset - MAP_OFFSET_2

         else

             actual_offset = offset - MAP_OFFSET_3

     else
  if (map_ver == 2)
         if (0 <= offset < MAP_LEVEL_1)

             actual_offset = offset

         else

             actual_offset = offset - MAP_OFFSET_4

     else
             actual_offset = offset

This is a bit messy, but other ways of doing it aren't
likely to be any cleaner.  Regardless, this whole mapping
process should be explained in comments.

> +#define DCC_MAP_LEVEL1			0x18
> +#define DCC_MAP_LEVEL2			0x34
> +#define DCC_MAP_LEVEL3			0x4C
> +
> +#define DCC_MAP_OFFSET1			0x10
> +#define DCC_MAP_OFFSET2			0x18
> +#define DCC_MAP_OFFSET3			0x1C
> +#define DCC_MAP_OFFSET4			0x8
> +
> +#define DCC_FIX_LOOP_OFFSET		16
> +#define DCC_VER_INFO_BIT		9
> +
> +#define DCC_READ			0
> +#define DCC_WRITE			1
> +#define DCC_LOOP			2
> +#define DCC_READ_WRITE			3
> +
> +#define MAX_DCC_OFFSET			GENMASK(9, 2)
> +#define MAX_DCC_LEN			GENMASK(6, 0)
> +#define MAX_LOOP_CNT			GENMASK(7, 0)
> +
> +#define DCC_ADDR_DESCRIPTOR		0x00
> +#define DCC_ADDR_LIMIT			27
> +#define DCC_ADDR_OFF_RANGE		8
> +#define DCC_ADDR_RANGE			GENMASK(31, 4)
> +#define DCC_LOOP_DESCRIPTOR		BIT(30)
> +#define DCC_RD_MOD_WR_DESCRIPTOR	BIT(31)
> +#define DCC_LINK_DESCRIPTOR		GENMASK(31, 30)
> +
> +#define DCC_READ_IND			0x00
> +#define DCC_WRITE_IND			(BIT(28))
> +
> +#define DCC_AHB_IND			0x00
> +#define DCC_APB_IND			BIT(29)
> +
> +#define DCC_MAX_LINK_LIST		8
> +#define DCC_INVALID_LINK_LIST		GENMASK(7, 0)
> +
> +#define DCC_VER_MASK1			GENMASK(6, 0)
> +#define DCC_VER_MASK2			GENMASK(5, 0)
> +
> +#define DCC_RD_MOD_WR_ADDR              0xC105E
> +
> +struct qcom_dcc_config {

No need for "qcom_" in the type name here.

> +	int dcc_ram_offset;
> +};
> +
> +enum dcc_descriptor_type {
> +	DCC_ADDR_TYPE,
> +	DCC_LOOP_TYPE,
> +	DCC_READ_WRITE_TYPE,
> +	DCC_WRITE_TYPE
> +};
> +
> +enum dcc_mem_map_ver {
> +	DCC_MEM_MAP_VER1 = 1,
> +	DCC_MEM_MAP_VER2 = 2,
> +	DCC_MEM_MAP_VER3 = 3

This enumerated type doesn't really add any value.  Just use 1, 2, and 3
for your version numbers in the few places this is used in code.  If it
gets more complicated than this one-to-one mapping in the future, add
a type like this.

> +};
> +
> +struct dcc_config_entry {

. . .

> +static bool dcc_ready(struct dcc_drvdata *drvdata)
> +{
> +	u32 val;
> +
> +	return !readl_poll_timeout((drvdata->base + dcc_offset_conv(drvdata, DCC_STATUS)),

Use dcc_readl(drvdata, offset) here.

> +				val, (FIELD_GET(GENMASK(1, 0), val) == 0), 1, TIMEOUT_US);

Use !FIELD_GET(...) here.

Is the 1 microsecond delay required?

> +
> +}
> +
> +static int dcc_read_status(struct dcc_drvdata *drvdata)
> +{
> +	int curr_list;
> +	u32 bus_status;
> +	u32 ll_cfg;
> +	u32 tmp_ll_cfg;
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> +		if (!drvdata->enable[curr_list])
> +			continue;
> +
> +		bus_status = dcc_readl(drvdata, DCC_LL_BUS_ACCESS_STATUS(curr_list));
> +
> +		if (bus_status) {
> +			dev_err(drvdata->dev,
> +				"Read access error for list %d err: 0x%x.\n",
> +				curr_list, bus_status);
> +
> +			ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
> +			tmp_ll_cfg = ll_cfg & ~BIT(9);
> +			dcc_writel(drvdata, tmp_ll_cfg, DCC_LL_CFG(curr_list));
> +			dcc_writel(drvdata, 0x3,
> +				DCC_LL_BUS_ACCESS_STATUS(curr_list));

What does writing 1 to the bottom two bits of the STATUS
register do?  Can you represent that with a mask, which
defines the register field?

> +			dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
> +			return -ENODATA;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int dcc_sw_trigger(struct dcc_drvdata *drvdata)
> +{
> +	int ret;
> +	int curr_list;
> +	u32 ll_cfg;
> +	u32 tmp_ll_cfg;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> +		if (!drvdata->enable[curr_list])
> +			continue;
> +		ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
> +		tmp_ll_cfg = ll_cfg & ~BIT(9);

What does bit 9 of this register represent?  Why is it turned
off here?

> +		dcc_writel(drvdata, tmp_ll_cfg, DCC_LL_CFG(curr_list));
> +		dcc_writel(drvdata, 1, DCC_LL_SW_TRIGGER(curr_list));
> +		dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));

Does this assume that bit 9 of the register was originally set?

> +	}
> +
> +	if (!dcc_ready(drvdata)) {
> +		dev_err(drvdata->dev,
> +			"DCC is busy after receiving sw tigger.\n");
> +		ret = -EBUSY;
> +		goto err;
> +	}
> +
> +	ret = dcc_read_status(drvdata);
> +
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +

. . .

> +static int __dcc_ll_cfg(struct dcc_drvdata *drvdata, int curr_list)
> +{
> +	int ret = 0;
> +	u32 total_len, pos;
> +	struct dcc_config_entry *entry;
> +	struct dcc_cfg_attr cfg;
> +	struct dcc_cfg_loop_attr cfg_loop;
> +
> +	memset(&cfg, 0, sizeof(cfg));
> +	memset(&cfg_loop, 0, sizeof(cfg_loop));
> +	cfg.sram_offset = drvdata->ram_cfg * 4;
> +	total_len = 0;
> +
> +	list_for_each_entry(entry, &drvdata->cfg_head[curr_list], list) {
> +		switch (entry->desc_type) {
> +		case DCC_READ_WRITE_TYPE:
> +			ret = _dcc_ll_cfg_read_write(drvdata, entry, &cfg);
> +			if (ret)
> +				goto overstep;
> +			break;
> +
> +		case DCC_LOOP_TYPE:
> +			ret = _dcc_ll_cfg_loop(drvdata, entry, &cfg, &cfg_loop, &total_len);
> +			if (ret)
> +				goto overstep;
> +			break;
> +
> +		case DCC_WRITE_TYPE:
> +			ret = _dcc_ll_cfg_write(drvdata, entry, &cfg, &total_len);
> +			if (ret)
> +				goto overstep;
> +			break;
> +
> +		default:

Use this instead of "default":
		case DCC_ADDR_TYPE:

> +			ret = _dcc_ll_cfg_default(drvdata, entry, &cfg, &pos, &total_len);
> +			if (ret)
> +				goto overstep;
> +			break;
> +		}
> +	}
> +
> +	if (cfg.link) {
> +		ret = dcc_sram_writel(drvdata, cfg.link, cfg.sram_offset);
> +		if (ret)
> +			goto overstep;
> +		cfg.sram_offset += 4;
> +	}

. . .

> +static ssize_t enable_show(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	int ret;
> +	bool dcc_enable = false;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");

Can this actually happen?  Isn't curr_list initially 0?
And can't you constrain the store function for curr_list
so it never exceeds nr_link_list?

> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	dcc_enable = is_dcc_enabled(drvdata);
> +
> +	ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> +				(unsigned int)dcc_enable > +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static ssize_t enable_store(struct device *dev,
> +				struct device_attribute *attr,
> +				const char *buf, size_t size)
> +{
> +	int ret = 0;
> +	unsigned long val;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (kstrtoul(buf, 16, &val))
> +		return -EINVAL;

I recommend using kstrtobool() here.

> +
> +	if (val)
> +		ret = dcc_enable(drvdata);
> +	else
> +		dcc_disable(drvdata);
> +
> +	if (!ret)
> +		ret = size;
> +
> +	return ret;
> +
> +}

. . .

> +static ssize_t config_write_store(struct device *dev,
> +						struct device_attribute *attr,
> +						const char *buf, size_t size)
> +{
> +	int ret;
> +	int nval;
> +	unsigned int addr, write_val;
> +	int apb_bus = 0;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	nval = sscanf(buf, "%x %x %d", &addr, &write_val, &apb_bus);

You didn't document in the sysfs documentation the optional
third argument here, which specify APB rather than AHB bus.

> +	if (nval <= 1 || nval > 3) {
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");

Here again (and everywhere else), avoid this possible error
condition by guaranteeing it will never be assigned a value
that's larger than nr_link_list.

> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (nval == 3 && apb_bus != 0)
> +		apb_bus = 1;
> +
> +	ret = dcc_add_write(drvdata, addr, write_val, apb_bus);
> +	if (ret)
> +		goto err;
> +
> +	mutex_unlock(&drvdata->mutex);
> +	return size;
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static DEVICE_ATTR_WO(config_write);
> +
> +static const struct device_attribute *dcc_attrs[] = {
> +	&dev_attr_trigger,
> +	&dev_attr_enable,
> +	&dev_attr_config,
> +	&dev_attr_config_reset,
> +	&dev_attr_ready,
> +	&dev_attr_interrupt_disable,
> +	&dev_attr_loop,
> +	&dev_attr_rd_mod_wr,
> +	&dev_attr_curr_list,
> +	&dev_attr_config_write,
> +	NULL,
> +};
> +
> +static int dcc_create_files(struct device *dev,
> +					const struct device_attribute **attrs)
> +{
> +	int ret = 0, i;

Cant these be initialized automatically as an attribute group
or something?  Maybe I'm getting confused.

> +	for (i = 0; attrs[i] != NULL; i++) {
> +		ret = device_create_file(dev, attrs[i]);
> +		if (ret) {
> +			dev_err(dev, "DCC: Couldn't create sysfs attribute: %s\n",
> +				attrs[i]->attr.name);
> +			break;
> +		}
> +	}
> +	return ret;
> +}
> +
> +static int dcc_sram_open(struct inode *inode, struct file *file)
> +{
> +	struct dcc_drvdata *drvdata = container_of(inode->i_cdev,
> +		struct dcc_drvdata,
> +		sram_dev);
> +	file->private_data = drvdata;
> +
> +	return	0;
> +}
> +
> +static ssize_t dcc_sram_read(struct file *file, char __user *data,
> +						size_t len, loff_t *ppos)
> +{
> +	unsigned char *buf;
> +	struct dcc_drvdata *drvdata = file->private_data;
> +
> +	/* EOF check */
> +	if (drvdata->ram_size <= *ppos)
> +		return 0;
> +
> +	if ((*ppos + len) > drvdata->ram_size)
> +		len = (drvdata->ram_size - *ppos);
> +
> +	buf = kzalloc(len, GFP_KERNEL);
> +	if (!buf)
> +		return -ENOMEM;
> +
> +	memcpy_fromio(buf, drvdata->ram_base + *ppos, len);
> +
> +	if (copy_to_user(data, buf, len)) {
> +		dev_err(drvdata->dev, "DCC: Couldn't copy all data to user\n");

Don't allow user input (i.e., providing a bad buffer pointer
in this case) lead to spamming the log.  The EFAULT error is
enough to explain what the problem is.  In generaly, I don't
think you should call dev_err() in these sysfs functions.

> +		kfree(buf);
> +		return -EFAULT;
> +	}
> +
> +	*ppos += len;
> +
> +	kfree(buf);
> +
> +	return len;
> +}
> +
> +static const struct file_operations dcc_sram_fops = {
> +	.owner		= THIS_MODULE,
> +	.open		= dcc_sram_open,
> +	.read		= dcc_sram_read,
> +	.llseek		= no_llseek,
> +};


Since dcc_sram_dev_init() does nothing but call this function,
why not just incorporate one into the other?  Same thing goes
for dcc_sram_dev_exit() and dcc_sram_dev_deregister().

> +static int dcc_sram_dev_register(struct dcc_drvdata *drvdata)
> +{
> +	int ret;
> +	struct device *device;
> +	dev_t dev;
> +
> +	ret = alloc_chrdev_region(&dev, 0, 1, DCC_SRAM_NODE);
> +	if (ret)
> +		goto err_alloc;
> +
> +	cdev_init(&drvdata->sram_dev, &dcc_sram_fops);
> +
> +	drvdata->sram_dev.owner = THIS_MODULE;
> +	ret = cdev_add(&drvdata->sram_dev, dev, 1);
> +	if (ret)
> +		goto err_cdev_add;
> +
> +	drvdata->sram_class = class_create(THIS_MODULE, DCC_SRAM_NODE);
> +	if (IS_ERR(drvdata->sram_class)) {
> +		ret = PTR_ERR(drvdata->sram_class);
> +		goto err_class_create;
> +	}
> +
> +	device = device_create(drvdata->sram_class, NULL,
> +						drvdata->sram_dev.dev, drvdata,
> +						DCC_SRAM_NODE);
> +	if (IS_ERR(device)) {
> +		ret = PTR_ERR(device);
> +		goto err_dev_create;
> +	}
> +
> +	return 0;
> +err_dev_create:
> +	class_destroy(drvdata->sram_class);
> +err_class_create:
> +	cdev_del(&drvdata->sram_dev);
> +err_cdev_add:
> +	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
> +err_alloc:
> +	return ret;
> +}
> +
> +static void dcc_sram_dev_deregister(struct dcc_drvdata *drvdata)
> +{
> +	device_destroy(drvdata->sram_class, drvdata->sram_dev.dev);
> +	class_destroy(drvdata->sram_class);
> +	cdev_del(&drvdata->sram_dev);
> +	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
> +}
> +
> +static int dcc_sram_dev_init(struct dcc_drvdata *drvdata)
> +{
> +	int ret = 0;
> +
> +	ret = dcc_sram_dev_register(drvdata);
> +	if (ret)
> +		dev_err(drvdata->dev, "DCC: sram node not registered.\n");
> +
> +	return ret;
> +}
> +
> +static void dcc_sram_dev_exit(struct dcc_drvdata *drvdata)
> +{
> +	dcc_sram_dev_deregister(drvdata);
> +}
> +
> +static int dcc_probe(struct platform_device *pdev)
> +{
> +	u32 val;
> +	int ret = 0, i, enable_size, nr_config_size, cfg_head_size;
> +	struct device *dev = &pdev->dev;
> +	struct dcc_drvdata *dcc;
> +	struct resource *res;
> +	const struct qcom_dcc_config *cfg;
> +
> +	dcc = devm_kzalloc(dev, sizeof(*dcc), GFP_KERNEL);
> +	if (!dcc)
> +		return -ENOMEM;
> +
> +	dcc->dev = &pdev->dev;
> +	platform_set_drvdata(pdev, dcc);
> +
> +	dcc->base = devm_platform_ioremap_resource(pdev, 0);

I mentioned earlier, it might be nice to give these memory
ranges a name more meaningful than 0 and 1.

> +	if (IS_ERR(dcc->base))
> +		return PTR_ERR(dcc->base);
> +
> +	dcc->ram_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
> +	if (IS_ERR(dcc->ram_base))
> +		return PTR_ERR(dcc->ram_base);
> +
> +	dcc->ram_size = resource_size(res);

Did you already take care of remapping with the call just above?

> +	dcc->ram_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (!dcc->ram_base)
> +		return -ENOMEM;

In any case, I think this second memory region is more like
memory space than I/O space.  If so, memremapping it might
be the right thing to do.

> +	cfg = of_device_get_match_data(&pdev->dev);
> +	dcc->ram_offset = cfg->dcc_ram_offset;
> +
> +	val = dcc_readl(dcc, DCC_HW_INFO);

Can you provide a short block of code that explains in English
what the next set of if statements are doing, and why?

> +	if (FIELD_GET(BIT(DCC_VER_INFO_BIT), val)) {
> +		dcc->mem_map_ver = DCC_MEM_MAP_VER3;
> +		dcc->nr_link_list = dcc_readl(dcc, DCC_LL_NUM_INFO);
> +		if (dcc->nr_link_list == 0)
> +			return	-EINVAL;
> +	} else if ((val & DCC_VER_MASK2) == DCC_VER_MASK2) {
> +		dcc->mem_map_ver = DCC_MEM_MAP_VER2;
> +		dcc->nr_link_list = dcc_readl(dcc, DCC_LL_NUM_INFO);
> +		if (dcc->nr_link_list == 0)
> +			return	-EINVAL;
> +	} else {
> +		dcc->mem_map_ver = DCC_MEM_MAP_VER1;
> +		dcc->nr_link_list = DCC_MAX_LINK_LIST;
> +	}

What does bit 6 in the HW_INFO register represent?

> +	if ((val & BIT(6)) == BIT(6))

	if (val & BIT(6))

> +		dcc->loopoff = DCC_FIX_LOOP_OFFSET;
> +	else
> +		dcc->loopoff = get_bitmask_order((dcc->ram_size +
> +				dcc->ram_offset) / 4 - 1);
> +
> +	mutex_init(&dcc->mutex);
> +	/* Allocate space for all entries at once */
> +	enable_size = dcc->nr_link_list * sizeof(bool);
> +	nr_config_size = dcc->nr_link_list * sizeof(size_t);
> +	cfg_head_size = dcc->nr_link_list * sizeof(struct list_head);
> +
> +	dcc->enable = devm_kzalloc(dev, enable_size + nr_config_size + cfg_head_size, GFP_KERNEL);
> +	if (!dcc->enable)
> +		return -ENOMEM;
> +
> +	dcc->nr_config  = (size_t *)(dcc->enable + dcc->nr_link_list);
> +	dcc->cfg_head = (struct list_head *)(dcc->nr_config + dcc->nr_link_list);
> +
> +	for (i = 0; i < dcc->nr_link_list; i++)
> +		INIT_LIST_HEAD(&dcc->cfg_head[i]);
> +
> +	dcc->curr_list = DCC_INVALID_LINK_LIST;
> +	ret = dcc_sram_dev_init(dcc);
> +	if (ret)
> +		return ret;
> +
> +	return dcc_create_files(dev, dcc_attrs);

If dcc_create_files() returns an error, you are not calling
dcc_sram_dev_exit() to clean things up.

> +}
> +
> +static int dcc_remove(struct platform_device *pdev)
> +{
> +	struct dcc_drvdata *drvdata = platform_get_drvdata(pdev);
> +
> +	dcc_sram_dev_exit(drvdata);
> +
> +	dcc_config_reset(drvdata);
> +
> +	return 0;
> +}
> +
> +static const struct qcom_dcc_config sm8150_cfg = {
> +	.dcc_ram_offset	= 0x5000,

If you know you'll be adding more fields there's nothing
wrong with this, but if the only thing you're storing is
the RAM offset, there's no need to define that within a
structure.  Just do something like:

	{ .compatible = "qcom,sm8150-dcc", .data = (void *)0x5000 },

> +};
> +
> +static const struct qcom_dcc_config sc7280_cfg = {
> +	.dcc_ram_offset = 0x12000,
> +};
> +
> +static const struct qcom_dcc_config sc7180_cfg = {
> +	.dcc_ram_offset = 0x6000,
> +};
> +
> +static const struct qcom_dcc_config sdm845_cfg = {
> +	.dcc_ram_offset = 0x6000,
> +};
> +
> +static const struct of_device_id dcc_match_table[] = {
> +	{ .compatible = "qcom,sm8150-dcc", .data = &sm8150_cfg },
> +	{ .compatible = "qcom,sc7280-dcc", .data = &sc7280_cfg },
> +	{ .compatible = "qcom,sc7180-dcc", .data = &sc7180_cfg },
> +	{ .compatible = "qcom,sdm845-dcc", .data = &sdm845_cfg },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, dcc_match_table);
> +
> +static struct platform_driver dcc_driver = {
> +	.probe = dcc_probe,
> +	.remove	= dcc_remove,
> +	.driver	= {
> +		.name = "qcom-dcc",
> +		.of_match_table	= dcc_match_table,
> +	},
> +};
> +
> +module_platform_driver(dcc_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Qualcomm Technologies Inc. DCC driver");
> +
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Souradeep Chowdhury]

On 12/14/2021 4:06 AM, Alex Elder wrote:
> On 8/10/21 12:54 PM, Souradeep Chowdhury wrote:
>> The DCC is a DMA Engine designed to capture and store data
>> during system crash or software triggers.The DCC operates
>> based on user inputs via the sysfs interface.The user gives
>> addresses as inputs and these addresses are stored in the
>> form of linkedlists.In case of a system crash or a manual
>> software trigger by the user through the sysfs interface,
>> the dcc captures and stores the values at these addresses.
>> This patch contains the driver which has all the methods
>> pertaining to the sysfs interface, auxiliary functions to
>> support all the four fundamental operations of dcc namely
>> read, write, first read then write and loop.The probe method
>> here instantiates all the resources necessary for dcc to
>> operate mainly the dedicated dcc sram where it stores the
>> values.The DCC driver can be used for debugging purposes
>> without going for a reboot since it can perform manual
>> triggers.
>
> I don't understand what you're trying to say with the last
> sentence above.
>
So DCC has both software and hardware triggers. The former can be 
triggered by the user by doing a

echo 1 > trigger from user space while the later happens during a crash.

>> Also added the documentation for sysfs entries
>> and explained the functionalities of each sysfs file that
>> has been created for dcc.
>
> Could these files all land in debugfs, at least initially?
> I guess if you get it right it's fine in sysfs, but unlike
> sysfs, debugfs is not considered a stable user space API.
>
Ack.Will move this to debugfs
>> The following is the justification of using sysfs interface
>> over the other alternatives like ioctls
>>
>> i) As can be seen from the sysfs attribute descriptions,
>> most of it does basic hardware manipulations like dcc_enable,
>> dcc_disable, config reset etc. As a result sysfs is preferred
>> over ioctl as we just need to enter a 0 or 1.
>>
>> ii) Existing similar debug hardwares are there for which drivers
>> have been written using sysfs interface.One such example is the
>> coresight-etm-trace driver.A closer analog can also be the watchdog
>> subsystems though it is ioctls based.
>
> Even if it eventually becomes a sysfs interface, it might
> be better to initially land it in debugfs.  (Maybe others
> disagree.)

Ack

>
> Generally, it looks to me like this always reads memory in
> 32-bit units.  I might have missed it, but if that is not
> documented it should be.  Also, is it OK to provide an
> address that is not aligned on a 32-bit boundary?  I
> presume memory is interpreted as CPU endian; does that
> produce the most meaningful results if the offset isn't
> aligned?
>
Address along with offset has to be valid to capture the results.


> More comments, below.
>
>                     -Alex
>
>> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org>
>> ---
>>   Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
>>   drivers/soc/qcom/Kconfig                   |    8 +
>>   drivers/soc/qcom/Makefile                  |    1 +
>>   drivers/soc/qcom/dcc.c                     | 1549 
>> ++++++++++++++++++++++++++++
>>   4 files changed, 1672 insertions(+)
>>   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>>   create mode 100644 drivers/soc/qcom/dcc.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-dcc 
>> b/Documentation/ABI/testing/sysfs-driver-dcc
>> new file mode 100644
>> index 0000000..05d24f0
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-driver-dcc
>
> Throughout this file, add a space or two after each period.
>
>> @@ -0,0 +1,114 @@
>> +What:           /sys/bus/platform/devices/.../trigger
>> +Date:           March 2021
>
> Probably update these dates when the code is close to
> getting accepted.

Ack

>
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +        This is the sysfs interface for manual software
>
> Try to reword each of the descriptions so they don't
> talk about "this sysfs interface."  Each one of these
> *is* describing a sysfs interface file, so that can be
> omitted from the description.  For example:
>
>     This file is used to perform a manual trigger
>     operation, causing all lists of memory operations
>     to be executed.
>
> Or something along those lines.
Ack
>
>> +        triggers.The user can simply enter a 1 against
>> +        the sysfs file and enable a manual trigger.
>> +        Example:
>> +        echo  1 > /sys/bus/platform/devices/.../trigger
>> +
>> +What:           /sys/bus/platform/devices/.../enable
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +        This sysfs interface is used for enabling the
>> +        the dcc hardware.Without this being set to 1,
>> +        the dcc hardware ceases to function.
>
> This could/should use a standard Boolean interface.  That is,
> parse the input in your code using kstrtobool() on the buffer
> passed to your store function.

Ack

>
>
>
>> +        Example:
>> +        echo  0 > /sys/bus/platform/devices/.../enable
>> +        (disable interface)
>> +        echo  1 > /sys/bus/platform/devices/.../enable
>> +        (enable interface)
>> +
>> +What:           /sys/bus/platform/devices/.../config
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +        This is the most commonly used sysfs interface
>> +        file and this basically stores the addresses of
>
> It doesn't matter if this is the "most commonly used" file.
> Just describe what it does.
>
> If I understand it right, you write a memory offset and
> an (optional) number of consecutive memory addresses to
> be read.

That's right.  Ack.

>
>> +        the registers which needs to be read in case of
>> +        a hardware crash or manual software triggers.
>> +        Example:
>> +        echo  0x80000010 10 > /sys/bus/platform/devices/../config
>> +        This specifies that 10 words starting from address
>> +        0x80000010 is to be read.In case there are no words to be
>> +        specified we can simply enter the address.
>
> I don't know what "in case there are no words to be specified"
> means.  Does that just mean memory at exactly one offset is
> read is implied if a count is not specified?

That's correct.Will update accordingly

>
>
>> +
>> +What:           /sys/bus/platform/devices/.../config_write
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +        This file allows user to write a value to the register
>> +        address given as argument.The values are entered in the
>> +        form of <register_address> <value>.The reason for this
>> +        feature of dcc is that for accessing certain registers
>> +        it is necessary to set some bits of soe other register.
>> +        That is achievable by giving DCC this privelege.
>> +        Example:
>> +        echo 0x80000000 0xFF > 
>> /sys/bus/platform/devices/.../config_write
>> +
>> +What:           /sys/bus/platform/devices/.../config_reset
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +        This file is used to reset the configuration of
>> +        a dcc driver to the default configuration.
>
> What does it mean to "reset the driver to the default"?
> Does that mean all lists of operations supplied previously
> are forgotten, and the lists become empty and disabled?

That's correct. Will update accordingly.

>
>> +        Example:
>> +        echo  1 > /sys/bus/platform/devices/.../config_reset
>> +
>> +What:           /sys/bus/platform/devices/.../loop
>> +Date:        March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>
> Can looping be done for a write or read/modify/write operation,
> or is it only used for reads?

Looping is only for read operations.

>
> Now skipping ahead to the code.
>
>> +        This file is used to enter the loop count as dcc
>> +        driver gives the option to loop multiple times on
>> +        the same register and store the values for each
>
> . . .
>
>> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
>> new file mode 100644
>> index 0000000..daf4388
>> --- /dev/null
>> +++ b/drivers/soc/qcom/dcc.c
>> @@ -0,0 +1,1549 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/bitops.h>
>> +#include <linux/cdev.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/io.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/uaccess.h>
>> +
>> +#define TIMEOUT_US        5000
>
> This timeout is only used when polling the STATUS register to
> determine when the DCC hardware is "ready".  Maybe the name
> could reflect that (STATUS_READY_TIMEOUT?).
>
Ack
> I think the next two might be better implemented as functions.
> It would allow the compiler to do some additional type checking.

Ack

>
>
>> +#define dcc_writel(drvdata, val, off)                    \
>> +    writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
>> +#define dcc_readl(drvdata, off)                        \
>> +    readl(drvdata->base + dcc_offset_conv(drvdata, off))
>> +
>> +#define DCC_SRAM_NODE "dcc_sram"
>> +
>> +/* DCC registers */
>> +#define DCC_HW_INFO            0x04
>> +#define DCC_LL_NUM_INFO            0x10
>> +#define DCC_STATUS            0x1C
>> +#define DCC_LL_LOCK(m)            (0x34 + 0x80 * m)
>> +#define DCC_LL_CFG(m)            (0x38 + 0x80 * m)
>> +#define DCC_LL_BASE(m)            (0x3c + 0x80 * m)
>> +#define DCC_FD_BASE(m)            (0x40 + 0x80 * m)
>> +#define DCC_LL_TIMEOUT(m)        (0x44 + 0x80 * m)
>> +#define DCC_LL_INT_ENABLE(m)        (0x4C + 0x80 * m)
>> +#define DCC_LL_INT_STATUS(m)        (0x50 + 0x80 * m)
>> +#define DCC_LL_SW_TRIGGER(m)        (0x60 + 0x80 * m)
>> +#define DCC_LL_BUS_ACCESS_STATUS(m)    (0x64 + 0x80 * m)
>
> The MAP_LEVEL and MAP_OFFSET definitions below, together
> with the function dcc_offset_conv(), are a clever way to
> have the above set of offsets "work" by mapping them to
> (at least) three distinct "actual" addresses.  That is:
>
>     if (map_ver == 1)
>
>         if (0 <= offset < MAP_LEVEL_1)
>
>             actual_offset = offset
>
>         else if (MAP_LEVEL_1 <= offset < MAP_LEVEL_2)
>
>             actual_offset = offset - MAP_OFFSET_1
>
>         else if (MAP_LEVEL_2 <= offset < MAP_LEVEL_3)
>
>             actual_offset = offset - MAP_OFFSET_2
>
>         else
>
>             actual_offset = offset - MAP_OFFSET_3
>
>     else
>  if (map_ver == 2)
>         if (0 <= offset < MAP_LEVEL_1)
>
>             actual_offset = offset
>
>         else
>
>             actual_offset = offset - MAP_OFFSET_4
>
>     else
>             actual_offset = offset
>
> This is a bit messy, but other ways of doing it aren't
> likely to be any cleaner.  Regardless, this whole mapping
> process should be explained in comments.

Ack

>
>> +#define DCC_MAP_LEVEL1            0x18
>> +#define DCC_MAP_LEVEL2            0x34
>> +#define DCC_MAP_LEVEL3            0x4C
>> +
>> +#define DCC_MAP_OFFSET1            0x10
>> +#define DCC_MAP_OFFSET2            0x18
>> +#define DCC_MAP_OFFSET3            0x1C
>> +#define DCC_MAP_OFFSET4            0x8
>> +
>> +#define DCC_FIX_LOOP_OFFSET        16
>> +#define DCC_VER_INFO_BIT        9
>> +
>> +#define DCC_READ            0
>> +#define DCC_WRITE            1
>> +#define DCC_LOOP            2
>> +#define DCC_READ_WRITE            3
>> +
>> +#define MAX_DCC_OFFSET            GENMASK(9, 2)
>> +#define MAX_DCC_LEN            GENMASK(6, 0)
>> +#define MAX_LOOP_CNT            GENMASK(7, 0)
>> +
>> +#define DCC_ADDR_DESCRIPTOR        0x00
>> +#define DCC_ADDR_LIMIT            27
>> +#define DCC_ADDR_OFF_RANGE        8
>> +#define DCC_ADDR_RANGE            GENMASK(31, 4)
>> +#define DCC_LOOP_DESCRIPTOR        BIT(30)
>> +#define DCC_RD_MOD_WR_DESCRIPTOR    BIT(31)
>> +#define DCC_LINK_DESCRIPTOR        GENMASK(31, 30)
>> +
>> +#define DCC_READ_IND            0x00
>> +#define DCC_WRITE_IND            (BIT(28))
>> +
>> +#define DCC_AHB_IND            0x00
>> +#define DCC_APB_IND            BIT(29)
>> +
>> +#define DCC_MAX_LINK_LIST        8
>> +#define DCC_INVALID_LINK_LIST        GENMASK(7, 0)
>> +
>> +#define DCC_VER_MASK1            GENMASK(6, 0)
>> +#define DCC_VER_MASK2            GENMASK(5, 0)
>> +
>> +#define DCC_RD_MOD_WR_ADDR              0xC105E
>> +
>> +struct qcom_dcc_config {
>
> No need for "qcom_" in the type name here.

Ack

>
>
>> +    int dcc_ram_offset;
>> +};
>> +
>> +enum dcc_descriptor_type {
>> +    DCC_ADDR_TYPE,
>> +    DCC_LOOP_TYPE,
>> +    DCC_READ_WRITE_TYPE,
>> +    DCC_WRITE_TYPE
>> +};
>> +
>> +enum dcc_mem_map_ver {
>> +    DCC_MEM_MAP_VER1 = 1,
>> +    DCC_MEM_MAP_VER2 = 2,
>> +    DCC_MEM_MAP_VER3 = 3
>
> This enumerated type doesn't really add any value.  Just use 1, 2, and 3
> for your version numbers in the few places this is used in code. If it
> gets more complicated than this one-to-one mapping in the future, add
> a type like this.
  Ack
>
>> +};
>> +
>> +struct dcc_config_entry {
>
> . . .
>
>> +static bool dcc_ready(struct dcc_drvdata *drvdata)
>> +{
>> +    u32 val;
>> +
>> +    return !readl_poll_timeout((drvdata->base + 
>> dcc_offset_conv(drvdata, DCC_STATUS)),
>
> Use dcc_readl(drvdata, offset) here.
Ack
>
>> +                val, (FIELD_GET(GENMASK(1, 0), val) == 0), 1, 
>> TIMEOUT_US);
>
> Use !FIELD_GET(...) here.
Ack
>
>
> Is the 1 microsecond delay required?

Ack

>
>
>> +
>> +}
>> +
>> +static int dcc_read_status(struct dcc_drvdata *drvdata)
>> +{
>> +    int curr_list;
>> +    u32 bus_status;
>> +    u32 ll_cfg;
>> +    u32 tmp_ll_cfg;
>> +
>> +    for (curr_list = 0; curr_list < drvdata->nr_link_list; 
>> curr_list++) {
>> +        if (!drvdata->enable[curr_list])
>> +            continue;
>> +
>> +        bus_status = dcc_readl(drvdata, 
>> DCC_LL_BUS_ACCESS_STATUS(curr_list));
>> +
>> +        if (bus_status) {
>> +            dev_err(drvdata->dev,
>> +                "Read access error for list %d err: 0x%x.\n",
>> +                curr_list, bus_status);
>> +
>> +            ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
>> +            tmp_ll_cfg = ll_cfg & ~BIT(9);
>> +            dcc_writel(drvdata, tmp_ll_cfg, DCC_LL_CFG(curr_list));
>> +            dcc_writel(drvdata, 0x3,
>> +                DCC_LL_BUS_ACCESS_STATUS(curr_list));
>
> What does writing 1 to the bottom two bits of the STATUS
> register do?  Can you represent that with a mask, which
> defines the register field?

Ack. This is used to set the status bits for DCC to configure the 
linkedlist.

>
>> +            dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
>> +            return -ENODATA;
>> +        }
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +static int dcc_sw_trigger(struct dcc_drvdata *drvdata)
>> +{
>> +    int ret;
>> +    int curr_list;
>> +    u32 ll_cfg;
>> +    u32 tmp_ll_cfg;
>> +
>> +    mutex_lock(&drvdata->mutex);
>> +
>> +    for (curr_list = 0; curr_list < drvdata->nr_link_list; 
>> curr_list++) {
>> +        if (!drvdata->enable[curr_list])
>> +            continue;
>> +        ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
>> +        tmp_ll_cfg = ll_cfg & ~BIT(9);
>
> What does bit 9 of this register represent?  Why is it turned
> off here?
>
This bit needs to be set for the software trigger to happen as per the

DCC hardware configuration.

>> +        dcc_writel(drvdata, tmp_ll_cfg, DCC_LL_CFG(curr_list));
>> +        dcc_writel(drvdata, 1, DCC_LL_SW_TRIGGER(curr_list));
>> +        dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
>
> Does this assume that bit 9 of the register was originally set?

Yes. This is the predefined sequence of operation for the DCC software 
trigger

to take place.

>
>
>> +    }
>> +
>> +    if (!dcc_ready(drvdata)) {
>> +        dev_err(drvdata->dev,
>> +            "DCC is busy after receiving sw tigger.\n");
>> +        ret = -EBUSY;
>> +        goto err;
>> +    }
>> +
>> +    ret = dcc_read_status(drvdata);
>> +
>> +err:
>> +    mutex_unlock(&drvdata->mutex);
>> +    return ret;
>> +}
>> +
>
> . . .
>
>> +static int __dcc_ll_cfg(struct dcc_drvdata *drvdata, int curr_list)
>> +{
>> +    int ret = 0;
>> +    u32 total_len, pos;
>> +    struct dcc_config_entry *entry;
>> +    struct dcc_cfg_attr cfg;
>> +    struct dcc_cfg_loop_attr cfg_loop;
>> +
>> +    memset(&cfg, 0, sizeof(cfg));
>> +    memset(&cfg_loop, 0, sizeof(cfg_loop));
>> +    cfg.sram_offset = drvdata->ram_cfg * 4;
>> +    total_len = 0;
>> +
>> +    list_for_each_entry(entry, &drvdata->cfg_head[curr_list], list) {
>> +        switch (entry->desc_type) {
>> +        case DCC_READ_WRITE_TYPE:
>> +            ret = _dcc_ll_cfg_read_write(drvdata, entry, &cfg);
>> +            if (ret)
>> +                goto overstep;
>> +            break;
>> +
>> +        case DCC_LOOP_TYPE:
>> +            ret = _dcc_ll_cfg_loop(drvdata, entry, &cfg, &cfg_loop, 
>> &total_len);
>> +            if (ret)
>> +                goto overstep;
>> +            break;
>> +
>> +        case DCC_WRITE_TYPE:
>> +            ret = _dcc_ll_cfg_write(drvdata, entry, &cfg, &total_len);
>> +            if (ret)
>> +                goto overstep;
>> +            break;
>> +
>> +        default:
>
> Use this instead of "default":
>         case DCC_ADDR_TYPE:

Ack

>
>> +            ret = _dcc_ll_cfg_default(drvdata, entry, &cfg, &pos, 
>> &total_len);
>> +            if (ret)
>> +                goto overstep;
>> +            break;
>> +        }
>> +    }
>> +
>> +    if (cfg.link) {
>> +        ret = dcc_sram_writel(drvdata, cfg.link, cfg.sram_offset);
>> +        if (ret)
>> +            goto overstep;
>> +        cfg.sram_offset += 4;
>> +    }
>
> . . .
>
>> +static ssize_t enable_show(struct device *dev,
>> +    struct device_attribute *attr, char *buf)
>> +{
>> +    int ret;
>> +    bool dcc_enable = false;
>> +    struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +    mutex_lock(&drvdata->mutex);
>> +    if (drvdata->curr_list >= drvdata->nr_link_list) {
>> +        dev_err(dev, "Select link list to program using curr_list\n");
>
> Can this actually happen?  Isn't curr_list initially 0?
> And can't you constrain the store function for curr_list
> so it never exceeds nr_link_list?

Ack

>
>> +        ret = -EINVAL;
>> +        goto err;
>> +    }
>> +
>> +    dcc_enable = is_dcc_enabled(drvdata);
>> +
>> +    ret = scnprintf(buf, PAGE_SIZE, "%u\n",
>> +                (unsigned int)dcc_enable > +err:
>> +    mutex_unlock(&drvdata->mutex);
>> +    return ret;
>> +}
>> +
>> +static ssize_t enable_store(struct device *dev,
>> +                struct device_attribute *attr,
>> +                const char *buf, size_t size)
>> +{
>> +    int ret = 0;
>> +    unsigned long val;
>> +    struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +    if (kstrtoul(buf, 16, &val))
>> +        return -EINVAL;
>
> I recommend using kstrtobool() here.

Ack

>
>
>> +
>> +    if (val)
>> +        ret = dcc_enable(drvdata);
>> +    else
>> +        dcc_disable(drvdata);
>> +
>> +    if (!ret)
>> +        ret = size;
>> +
>> +    return ret;
>> +
>> +}
>
> . . .
>
>> +static ssize_t config_write_store(struct device *dev,
>> +                        struct device_attribute *attr,
>> +                        const char *buf, size_t size)
>> +{
>> +    int ret;
>> +    int nval;
>> +    unsigned int addr, write_val;
>> +    int apb_bus = 0;
>> +    struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +    mutex_lock(&drvdata->mutex);
>> +
>> +    nval = sscanf(buf, "%x %x %d", &addr, &write_val, &apb_bus);
>
> You didn't document in the sysfs documentation the optional
> third argument here, which specify APB rather than AHB bus.
Ack
>
>
>> +    if (nval <= 1 || nval > 3) {
>> +        ret = -EINVAL;
>> +        goto err;
>> +    }
>> +
>> +    if (drvdata->curr_list >= drvdata->nr_link_list) {
>> +        dev_err(dev, "Select link list to program using curr_list\n");
>
> Here again (and everywhere else), avoid this possible error
> condition by guaranteeing it will never be assigned a value
> that's larger than nr_link_list.
Ack
>
>
>> +        ret = -EINVAL;
>> +        goto err;
>> +    }
>> +
>> +    if (nval == 3 && apb_bus != 0)
>> +        apb_bus = 1;
>> +
>> +    ret = dcc_add_write(drvdata, addr, write_val, apb_bus);
>> +    if (ret)
>> +        goto err;
>> +
>> +    mutex_unlock(&drvdata->mutex);
>> +    return size;
>> +err:
>> +    mutex_unlock(&drvdata->mutex);
>> +    return ret;
>> +}
>> +
>> +static DEVICE_ATTR_WO(config_write);
>> +
>> +static const struct device_attribute *dcc_attrs[] = {
>> +    &dev_attr_trigger,
>> +    &dev_attr_enable,
>> +    &dev_attr_config,
>> +    &dev_attr_config_reset,
>> +    &dev_attr_ready,
>> +    &dev_attr_interrupt_disable,
>> +    &dev_attr_loop,
>> +    &dev_attr_rd_mod_wr,
>> +    &dev_attr_curr_list,
>> +    &dev_attr_config_write,
>> +    NULL,
>> +};
>> +
>> +static int dcc_create_files(struct device *dev,
>> +                    const struct device_attribute **attrs)
>> +{
>> +    int ret = 0, i;
>
> Cant these be initialized automatically as an attribute group
> or something?  Maybe I'm getting confused.
Ack. Attr group can be used in this case.
>
>
>> +    for (i = 0; attrs[i] != NULL; i++) {
>> +        ret = device_create_file(dev, attrs[i]);
>> +        if (ret) {
>> +            dev_err(dev, "DCC: Couldn't create sysfs attribute: %s\n",
>> +                attrs[i]->attr.name);
>> +            break;
>> +        }
>> +    }
>> +    return ret;
>> +}
>> +
>> +static int dcc_sram_open(struct inode *inode, struct file *file)
>> +{
>> +    struct dcc_drvdata *drvdata = container_of(inode->i_cdev,
>> +        struct dcc_drvdata,
>> +        sram_dev);
>> +    file->private_data = drvdata;
>> +
>> +    return    0;
>> +}
>> +
>> +static ssize_t dcc_sram_read(struct file *file, char __user *data,
>> +                        size_t len, loff_t *ppos)
>> +{
>> +    unsigned char *buf;
>> +    struct dcc_drvdata *drvdata = file->private_data;
>> +
>> +    /* EOF check */
>> +    if (drvdata->ram_size <= *ppos)
>> +        return 0;
>> +
>> +    if ((*ppos + len) > drvdata->ram_size)
>> +        len = (drvdata->ram_size - *ppos);
>> +
>> +    buf = kzalloc(len, GFP_KERNEL);
>> +    if (!buf)
>> +        return -ENOMEM;
>> +
>> +    memcpy_fromio(buf, drvdata->ram_base + *ppos, len);
>> +
>> +    if (copy_to_user(data, buf, len)) {
>> +        dev_err(drvdata->dev, "DCC: Couldn't copy all data to user\n");
>
> Don't allow user input (i.e., providing a bad buffer pointer
> in this case) lead to spamming the log.  The EFAULT error is
> enough to explain what the problem is.  In generaly, I don't
> think you should call dev_err() in these sysfs functions.

Ack

>
>
>> +        kfree(buf);
>> +        return -EFAULT;
>> +    }
>> +
>> +    *ppos += len;
>> +
>> +    kfree(buf);
>> +
>> +    return len;
>> +}
>> +
>> +static const struct file_operations dcc_sram_fops = {
>> +    .owner        = THIS_MODULE,
>> +    .open        = dcc_sram_open,
>> +    .read        = dcc_sram_read,
>> +    .llseek        = no_llseek,
>> +};
>
>
> Since dcc_sram_dev_init() does nothing but call this function,
> why not just incorporate one into the other?  Same thing goes
> for dcc_sram_dev_exit() and dcc_sram_dev_deregister().
Ack
>
>
>> +static int dcc_sram_dev_register(struct dcc_drvdata *drvdata)
>> +{
>> +    int ret;
>> +    struct device *device;
>> +    dev_t dev;
>> +
>> +    ret = alloc_chrdev_region(&dev, 0, 1, DCC_SRAM_NODE);
>> +    if (ret)
>> +        goto err_alloc;
>> +
>> +    cdev_init(&drvdata->sram_dev, &dcc_sram_fops);
>> +
>> +    drvdata->sram_dev.owner = THIS_MODULE;
>> +    ret = cdev_add(&drvdata->sram_dev, dev, 1);
>> +    if (ret)
>> +        goto err_cdev_add;
>> +
>> +    drvdata->sram_class = class_create(THIS_MODULE, DCC_SRAM_NODE);
>> +    if (IS_ERR(drvdata->sram_class)) {
>> +        ret = PTR_ERR(drvdata->sram_class);
>> +        goto err_class_create;
>> +    }
>> +
>> +    device = device_create(drvdata->sram_class, NULL,
>> +                        drvdata->sram_dev.dev, drvdata,
>> +                        DCC_SRAM_NODE);
>> +    if (IS_ERR(device)) {
>> +        ret = PTR_ERR(device);
>> +        goto err_dev_create;
>> +    }
>> +
>> +    return 0;
>> +err_dev_create:
>> +    class_destroy(drvdata->sram_class);
>> +err_class_create:
>> +    cdev_del(&drvdata->sram_dev);
>> +err_cdev_add:
>> +    unregister_chrdev_region(drvdata->sram_dev.dev, 1);
>> +err_alloc:
>> +    return ret;
>> +}
>> +
>> +static void dcc_sram_dev_deregister(struct dcc_drvdata *drvdata)
>> +{
>> +    device_destroy(drvdata->sram_class, drvdata->sram_dev.dev);
>> +    class_destroy(drvdata->sram_class);
>> +    cdev_del(&drvdata->sram_dev);
>> +    unregister_chrdev_region(drvdata->sram_dev.dev, 1);
>> +}
>> +
>> +static int dcc_sram_dev_init(struct dcc_drvdata *drvdata)
>> +{
>> +    int ret = 0;
>> +
>> +    ret = dcc_sram_dev_register(drvdata);
>> +    if (ret)
>> +        dev_err(drvdata->dev, "DCC: sram node not registered.\n");
>> +
>> +    return ret;
>> +}
>> +
>> +static void dcc_sram_dev_exit(struct dcc_drvdata *drvdata)
>> +{
>> +    dcc_sram_dev_deregister(drvdata);
>> +}
>> +
>> +static int dcc_probe(struct platform_device *pdev)
>> +{
>> +    u32 val;
>> +    int ret = 0, i, enable_size, nr_config_size, cfg_head_size;
>> +    struct device *dev = &pdev->dev;
>> +    struct dcc_drvdata *dcc;
>> +    struct resource *res;
>> +    const struct qcom_dcc_config *cfg;
>> +
>> +    dcc = devm_kzalloc(dev, sizeof(*dcc), GFP_KERNEL);
>> +    if (!dcc)
>> +        return -ENOMEM;
>> +
>> +    dcc->dev = &pdev->dev;
>> +    platform_set_drvdata(pdev, dcc);
>> +
>> +    dcc->base = devm_platform_ioremap_resource(pdev, 0);
>
> I mentioned earlier, it might be nice to give these memory
> ranges a name more meaningful than 0 and 1.
Reason explained in the reply on the previous patch.
>
>
>> +    if (IS_ERR(dcc->base))
>> +        return PTR_ERR(dcc->base);
>> +
>> +    dcc->ram_base = devm_platform_get_and_ioremap_resource(pdev, 1, 
>> &res);
>> +    if (IS_ERR(dcc->ram_base))
>> +        return PTR_ERR(dcc->ram_base);
>> +
>> +    dcc->ram_size = resource_size(res);
>
> Did you already take care of remapping with the call just above?
Ack
>
>
>> +    dcc->ram_base = devm_ioremap(dev, res->start, resource_size(res));
>> +    if (!dcc->ram_base)
>> +        return -ENOMEM;
>
> In any case, I think this second memory region is more like
> memory space than I/O space.  If so, memremapping it might
> be the right thing to do.

  Ack

>
>
>> +    cfg = of_device_get_match_data(&pdev->dev);
>> +    dcc->ram_offset = cfg->dcc_ram_offset;
>> +
>> +    val = dcc_readl(dcc, DCC_HW_INFO);
>
> Can you provide a short block of code that explains in English
> what the next set of if statements are doing, and why?

So here I am finding out the memory map version of DCC by reading 
DCC_HW_INFO register.

If DCC_VER_INFO_BIT(9) of DCC_HW_INFO is set then

memory map version is 3 and max supported link list is the value at 
register DCC_LL_NUM_INFO.

If  all the first 7 bits(0x7F) of DCC_HW_INFO is set, then

memory map version is 2 and  max supported link list is the value at 
register DCC_LL_NUM_INFO.

If none of the above is true then

Memory map version is 1 and max supported link list is 
DCC_MAX_LINK_LIST(predefined) which is 8.

>
>> +    if (FIELD_GET(BIT(DCC_VER_INFO_BIT), val)) {
>> +        dcc->mem_map_ver = DCC_MEM_MAP_VER3;
>> +        dcc->nr_link_list = dcc_readl(dcc, DCC_LL_NUM_INFO);
>> +        if (dcc->nr_link_list == 0)
>> +            return    -EINVAL;
>> +    } else if ((val & DCC_VER_MASK2) == DCC_VER_MASK2) {
>> +        dcc->mem_map_ver = DCC_MEM_MAP_VER2;
>> +        dcc->nr_link_list = dcc_readl(dcc, DCC_LL_NUM_INFO);
>> +        if (dcc->nr_link_list == 0)
>> +            return    -EINVAL;
>> +    } else {
>> +        dcc->mem_map_ver = DCC_MEM_MAP_VER1;
>> +        dcc->nr_link_list = DCC_MAX_LINK_LIST;
>> +    }
>
> What does bit 6 in the HW_INFO register represent?

This gives the loop_offset value type for the dcc version which is used in

case of loop addresses.

>
>
>> +    if ((val & BIT(6)) == BIT(6))
>
>     if (val & BIT(6))
>
>> +        dcc->loopoff = DCC_FIX_LOOP_OFFSET;
>> +    else
>> +        dcc->loopoff = get_bitmask_order((dcc->ram_size +
>> +                dcc->ram_offset) / 4 - 1);
>> +
>> +    mutex_init(&dcc->mutex);
>> +    /* Allocate space for all entries at once */
>> +    enable_size = dcc->nr_link_list * sizeof(bool);
>> +    nr_config_size = dcc->nr_link_list * sizeof(size_t);
>> +    cfg_head_size = dcc->nr_link_list * sizeof(struct list_head);
>> +
>> +    dcc->enable = devm_kzalloc(dev, enable_size + nr_config_size + 
>> cfg_head_size, GFP_KERNEL);
>> +    if (!dcc->enable)
>> +        return -ENOMEM;
>> +
>> +    dcc->nr_config  = (size_t *)(dcc->enable + dcc->nr_link_list);
>> +    dcc->cfg_head = (struct list_head *)(dcc->nr_config + 
>> dcc->nr_link_list);
>> +
>> +    for (i = 0; i < dcc->nr_link_list; i++)
>> +        INIT_LIST_HEAD(&dcc->cfg_head[i]);
>> +
>> +    dcc->curr_list = DCC_INVALID_LINK_LIST;
>> +    ret = dcc_sram_dev_init(dcc);
>> +    if (ret)
>> +        return ret;
>> +
>> +    return dcc_create_files(dev, dcc_attrs);
>
> If dcc_create_files() returns an error, you are not calling
> dcc_sram_dev_exit() to clean things up.

Ack

>
>
>> +}
>> +
>> +static int dcc_remove(struct platform_device *pdev)
>> +{
>> +    struct dcc_drvdata *drvdata = platform_get_drvdata(pdev);
>> +
>> +    dcc_sram_dev_exit(drvdata);
>> +
>> +    dcc_config_reset(drvdata);
>> +
>> +    return 0;
>> +}
>> +
>> +static const struct qcom_dcc_config sm8150_cfg = {
>> +    .dcc_ram_offset    = 0x5000,
>
> If you know you'll be adding more fields there's nothing
> wrong with this, but if the only thing you're storing is
> the RAM offset, there's no need to define that within a
> structure.  Just do something like:
>
>     { .compatible = "qcom,sm8150-dcc", .data = (void *)0x5000 },
>
Ack
>> +};
>> +
>> +static const struct qcom_dcc_config sc7280_cfg = {
>> +    .dcc_ram_offset = 0x12000,
>> +};
>> +
>> +static const struct qcom_dcc_config sc7180_cfg = {
>> +    .dcc_ram_offset = 0x6000,
>> +};
>> +
>> +static const struct qcom_dcc_config sdm845_cfg = {
>> +    .dcc_ram_offset = 0x6000,
>> +};
>> +
>> +static const struct of_device_id dcc_match_table[] = {
>> +    { .compatible = "qcom,sm8150-dcc", .data = &sm8150_cfg },
>> +    { .compatible = "qcom,sc7280-dcc", .data = &sc7280_cfg },
>> +    { .compatible = "qcom,sc7180-dcc", .data = &sc7180_cfg },
>> +    { .compatible = "qcom,sdm845-dcc", .data = &sdm845_cfg },
>> +    { }
>> +};
>> +MODULE_DEVICE_TABLE(of, dcc_match_table);
>> +
>> +static struct platform_driver dcc_driver = {
>> +    .probe = dcc_probe,
>> +    .remove    = dcc_remove,
>> +    .driver    = {
>> +        .name = "qcom-dcc",
>> +        .of_match_table    = dcc_match_table,
>> +    },
>> +};
>> +
>> +module_platform_driver(dcc_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("Qualcomm Technologies Inc. DCC driver");
>> +
>>
>
>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Manivannan Sadhasivam]

On Tue, Aug 10, 2021 at 11:24:38PM +0530, Souradeep Chowdhury wrote:
> The DCC is a DMA Engine designed to capture and store data
> during system crash or software triggers.The DCC operates
> based on user inputs via the sysfs interface.The user gives
> addresses as inputs and these addresses are stored in the
> form of linkedlists.

The linked lists are present in the hardware, right? You should state it
explicitly.

> In case of a system crash or a manual

So what does a crash here means? How does DCC detect it?

> software trigger by the user through the sysfs interface,
> the dcc captures and stores the values at these addresses.

This could be reworded a bit:

"DCC captures and stores the current values of the provided addresses in SRAM"

> This patch contains the driver which has all the methods
> pertaining to the sysfs interface, auxiliary functions to
> support all the four fundamental operations of dcc namely
> read, write, first read then write and loop.The probe method
> here instantiates all the resources necessary for dcc to
> operate mainly the dedicated dcc sram where it stores the

Please use "DCC" everywhere.

> values.The DCC driver can be used for debugging purposes
> without going for a reboot since it can perform manual
> triggers.
> 

It allows users to perform software triggers for capturing values manually. 

> Also added the documentation for sysfs entries
> and explained the functionalities of each sysfs file that
> has been created for dcc.
> 
> The following is the justification of using sysfs interface
> over the other alternatives like ioctls
> 
> i) As can be seen from the sysfs attribute descriptions,
> most of it does basic hardware manipulations like dcc_enable,
> dcc_disable, config reset etc. As a result sysfs is preferred
> over ioctl as we just need to enter a 0 or 1.
> 

This is not an apt reason to use sysfs. The one-value-per-file is a rule of
sysfs not a criteria to use it.

> ii) Existing similar debug hardwares are there for which drivers
> have been written using sysfs interface.One such example is the
> coresight-etm-trace driver.A closer analog can also be the watchdog
> subsystems though it is ioctls based.
> 

Initially I thought that this driver could use debugfs interface, but going
through it I feel that sysfs is more suited. Reason is, debugfs interface is
used by drivers to expose debugging information additional to the function they
do. But the sole usage of this driver depends on the configuration exported
through the attributes and they looks to be an ABI to me.

> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org>
> ---
>  Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
>  drivers/soc/qcom/Kconfig                   |    8 +
>  drivers/soc/qcom/Makefile                  |    1 +
>  drivers/soc/qcom/dcc.c                     | 1549 ++++++++++++++++++++++++++++
>  4 files changed, 1672 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>  create mode 100644 drivers/soc/qcom/dcc.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc
> new file mode 100644
> index 0000000..05d24f0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-dcc
> @@ -0,0 +1,114 @@
> +What:           /sys/bus/platform/devices/.../trigger
> +Date:           March 2021

Please fix the dates of all attributes.

> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This is the sysfs interface for manual software

All entries should be aligned properly.

> +		triggers.The user can simply enter a 1 against
> +		the sysfs file and enable a manual trigger.
> +		Example:
> +		echo  1 > /sys/bus/platform/devices/.../trigger

Why 2 spaces after echo?

> +
> +What:           /sys/bus/platform/devices/.../enable
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This sysfs interface is used for enabling the
> +		the dcc hardware.Without this being set to 1,

DCC here also. And a space after "." everywhere.

> +		the dcc hardware ceases to function.
> +		Example:
> +		echo  0 > /sys/bus/platform/devices/.../enable
> +		(disable interface)
> +		echo  1 > /sys/bus/platform/devices/.../enable
> +		(enable interface)
> +
> +What:           /sys/bus/platform/devices/.../config
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This is the most commonly used sysfs interface
> +		file and this basically stores the addresses of
> +		the registers which needs to be read in case of
> +		a hardware crash or manual software triggers.
> +		Example:
> +		echo  0x80000010 10 > /sys/bus/platform/devices/../config
> +		This specifies that 10 words starting from address

words are of width?

> +		0x80000010 is to be read.In case there are no words to be
> +		specified we can simply enter the address.

No word to be read? So what's the purpose then?

> +
> +What:           /sys/bus/platform/devices/.../config_write
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file allows user to write a value to the register
> +		address given as argument.The values are entered in the
> +		form of <register_address> <value>.The reason for this
> +		feature of dcc is that for accessing certain registers
> +		it is necessary to set some bits of soe other register.

soe?

> +		That is achievable by giving DCC this privelege.

privilege

> +		Example:
> +		echo 0x80000000 0xFF > /sys/bus/platform/devices/.../config_write
> +
> +What:           /sys/bus/platform/devices/.../config_reset
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to reset the configuration of
> +		a dcc driver to the default configuration.

s/"a dcc driver"/"the DCC driver"/g

> +		Example:
> +		echo  1 > /sys/bus/platform/devices/.../config_reset
> +
> +What:           /sys/bus/platform/devices/.../loop
> +Date:		March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to enter the loop count as dcc
> +		driver gives the option to loop multiple times on
> +		the same register and store the values for each
> +		loop.This is done to capture the changing values
> +		of a register with time which comes handy for
> +		debugging purposes.
> +		Example:
> +		echo 10 > /sys/bus/platform/devices/10a2000.dcc/loop
> +		(Setting the loop count to 10)
> +		echo  0x80000010 10 > /sys/bus/platform/devices/.../config
> +                (Read 10 words starting from address 0x80000010O)
> +		echo 1 > /sys/bus/platform/devices/.../loop
> +		(Terminate the loop by writing a count of 1 to the loop sysfs node)
> +
> +What:           /sys/bus/platform/devices/.../rd_mod_wr

Can you come up with a better name? Like config_read_write?

> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to read the value of the register
> +		and then write the value given as an argument to the
> +		register address in config.The address argument should
> +		be given of the form <mask> <value>.For debugging
> +		purposes sometimes we need to first read from a register
> +		and then set some values to the register.

Reading this description gives an impression that this file is used to read the
value of a register. But it is write only and the value will be read only during
the trigger or crash. So this should be stated explicitly.

> +		Example:
> +		echo 0x80000000 > /sys/bus/platform/devices/.../config
> +		(Set the address in config file)
> +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
> +		(Provide the mask and the value to write)
> +
> +What:           /sys/bus/platform/devices/.../ready
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to check the status of the dcc
> +		hardware if it's ready to take the inputs.
> +		Example:
> +		cat /sys/bus/platform/devices/.../ready

Document the value read also.

> +
> +What:		/sys/bus/platform/devices/.../curr_list
> +Date:		February 2021
> +Contact:	Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This attribute is used to enter the linklist to be
> +		used while appending addresses.The range of values
> +		for this can be from 0 to 3.This feature is given in
> +		order to use certain linkedlist for certain debugging
> +		purposes.
> +		Example:
> +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
> +

How does a user will know the contents of the linked list? Basis on what
criteria, user will know what value to write?

> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 79b568f..5101912 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -69,6 +69,14 @@ config QCOM_LLCC
>  	  SDM845. This provides interfaces to clients that use the LLCC.
>  	  Say yes here to enable LLCC slice driver.
>  
> +config QCOM_DCC
> +	tristate "Qualcomm Technologies, Inc. Data Capture and Compare(DCC) engine driver"
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	help
> +	  This option enables driver for Data Capture and Compare engine. DCC
> +	  driver provides interface to configure DCC block and read back
> +	  captured data from DCC's internal SRAM.
> +
>  config QCOM_KRYO_L2_ACCESSORS
>  	bool
>  	depends on ARCH_QCOM && ARM64 || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ad675a6..0aaf82b 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
>  obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>  obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>  obj-$(CONFIG_QCOM_CPR)		+= cpr.o
> +obj-$(CONFIG_QCOM_DCC) += dcc.o
>  obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
>  obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> new file mode 100644
> index 0000000..daf4388
> --- /dev/null
> +++ b/drivers/soc/qcom/dcc.c
> @@ -0,0 +1,1549 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/cdev.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +#define TIMEOUT_US		5000
> +
> +#define dcc_writel(drvdata, val, off)					\
> +	writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
> +#define dcc_readl(drvdata, off)						\
> +	readl(drvdata->base + dcc_offset_conv(drvdata, off))
> +
> +#define DCC_SRAM_NODE "dcc_sram"
> +
> +/* DCC registers */
> +#define DCC_HW_INFO			0x04
> +#define DCC_LL_NUM_INFO			0x10
> +#define DCC_STATUS			0x1C

Please use lower case for register offsets. Also, align the defines properly.

> +#define DCC_LL_LOCK(m)			(0x34 + 0x80 * m)
> +#define DCC_LL_CFG(m)			(0x38 + 0x80 * m)
> +#define DCC_LL_BASE(m)			(0x3c + 0x80 * m)
> +#define DCC_FD_BASE(m)			(0x40 + 0x80 * m)
> +#define DCC_LL_TIMEOUT(m)		(0x44 + 0x80 * m)
> +#define DCC_LL_INT_ENABLE(m)		(0x4C + 0x80 * m)
> +#define DCC_LL_INT_STATUS(m)		(0x50 + 0x80 * m)
> +#define DCC_LL_SW_TRIGGER(m)		(0x60 + 0x80 * m)
> +#define DCC_LL_BUS_ACCESS_STATUS(m)	(0x64 + 0x80 * m)
> +
> +#define DCC_MAP_LEVEL1			0x18
> +#define DCC_MAP_LEVEL2			0x34
> +#define DCC_MAP_LEVEL3			0x4C
> +
> +#define DCC_MAP_OFFSET1			0x10
> +#define DCC_MAP_OFFSET2			0x18
> +#define DCC_MAP_OFFSET3			0x1C
> +#define DCC_MAP_OFFSET4			0x8
> +
> +#define DCC_FIX_LOOP_OFFSET		16
> +#define DCC_VER_INFO_BIT		9
> +
> +#define DCC_READ			0
> +#define DCC_WRITE			1
> +#define DCC_LOOP			2
> +#define DCC_READ_WRITE			3
> +
> +#define MAX_DCC_OFFSET			GENMASK(9, 2)
> +#define MAX_DCC_LEN			GENMASK(6, 0)
> +#define MAX_LOOP_CNT			GENMASK(7, 0)
> +
> +#define DCC_ADDR_DESCRIPTOR		0x00
> +#define DCC_ADDR_LIMIT			27
> +#define DCC_ADDR_OFF_RANGE		8
> +#define DCC_ADDR_RANGE			GENMASK(31, 4)
> +#define DCC_LOOP_DESCRIPTOR		BIT(30)
> +#define DCC_RD_MOD_WR_DESCRIPTOR	BIT(31)
> +#define DCC_LINK_DESCRIPTOR		GENMASK(31, 30)
> +
> +#define DCC_READ_IND			0x00
> +#define DCC_WRITE_IND			(BIT(28))
> +
> +#define DCC_AHB_IND			0x00
> +#define DCC_APB_IND			BIT(29)
> +
> +#define DCC_MAX_LINK_LIST		8
> +#define DCC_INVALID_LINK_LIST		GENMASK(7, 0)
> +
> +#define DCC_VER_MASK1			GENMASK(6, 0)
> +#define DCC_VER_MASK2			GENMASK(5, 0)
> +
> +#define DCC_RD_MOD_WR_ADDR              0xC105E
> +
> +struct qcom_dcc_config {
> +	int dcc_ram_offset;

Are you planning to expand this structure? If not, please use "dcc_ram_offset"
directly.

> +};
> +
> +enum dcc_descriptor_type {
> +	DCC_ADDR_TYPE,
> +	DCC_LOOP_TYPE,
> +	DCC_READ_WRITE_TYPE,
> +	DCC_WRITE_TYPE
> +};
> +
> +enum dcc_mem_map_ver {
> +	DCC_MEM_MAP_VER1 = 1,
> +	DCC_MEM_MAP_VER2 = 2,
> +	DCC_MEM_MAP_VER3 = 3
> +};
> +
> +struct dcc_config_entry {
> +	u32				base;
> +	u32				offset;
> +	u32				len;
> +	u32				index;
> +	u32				loop_cnt;
> +	u32				write_val;
> +	u32				mask;
> +	bool				apb_bus;
> +	enum dcc_descriptor_type	desc_type;
> +	struct list_head		list;
> +};
> +
> +/**
> + * struct dcc_drvdata - configuration information related to a dcc device
> + * @base:	      Base Address of the dcc device
> + * @dev:	      The device attached to the driver data
> + * @mutex:	      Lock to protect access and manipulation of dcc_drvdata

What? Are you trying to protect the whole structure or some fields?

> + * @ram_base:         Base address for the SRAM dedicated for the dcc device
> + * @ram_offset:       Offset to the SRAM dedicated for dcc device
> + * @mem_map_ver:      Memory map version of DCC hardware
> + * @ram_cfg:          Used for address limit calculation for dcc
> + * @ram_start:        Starting address of DCC SRAM
> + * @enable:	      Flag to check if DCC linked list is enabled

This contains an array of linked list enable flags.

> + * @interrupt_disable:Flag to enable/disable interrupts

For simplicity, just use a space after colon.

> + * @sram_dev:	      Character device equivalent of dcc SRAM
> + * @sram_class:	      Class equivalent of the DCC SRAM device
> + * @cfg_head:	      Points to the head of the linked list of addresses
> + * @nr_config:        Stores the number of addresses currently configured for a linkedlist
> + * @nr_link_list:     Total number of linkedlists supported by the DCC configuration
> + * @curr_list:        The index of the current linklist with which the driver is working
> + * @loopoff:          Loop offset bits range for the addresses
> + */
> +struct dcc_drvdata {
> +	void __iomem		*base;
> +	struct device		*dev;
> +	struct mutex		mutex;
> +	void __iomem		*ram_base;
> +	phys_addr_t		ram_size;
> +	phys_addr_t		ram_offset;
> +	enum dcc_mem_map_ver	mem_map_ver;
> +	phys_addr_t		ram_cfg;
> +	phys_addr_t		ram_start;
> +	bool			*enable;
> +	bool			interrupt_disable;

Move this to end to avoid holes.

> +	struct cdev		sram_dev;
> +	struct class		*sram_class;
> +	struct list_head	*cfg_head;
> +	size_t			*nr_config;
> +	size_t			nr_link_list;
> +	u8			curr_list;
> +	u8			loopoff;
> +};

Is it possible to move the linked list specific members to a different struct?

> +
> +struct dcc_cfg_attr {
> +	u32	addr;
> +	u32	prev_addr;
> +	u32	prev_off;
> +	u32	link;
> +	u32	sram_offset;
> +};
> +
> +struct dcc_cfg_loop_attr {
> +	u32	loop;
> +	bool	loop_start;

Move this to the end

> +	u32	loop_cnt;
> +	u32	loop_len;
> +	u32	loop_off;
> +};
> +
> +static size_t dcc_offset_conv(struct dcc_drvdata *drvdata, size_t off)

Add comment on what this function does.

> +{
> +	if (drvdata->mem_map_ver == DCC_MEM_MAP_VER1) {
> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL3)

Use FIELD_* macros where applicable.

> +			return off - DCC_MAP_OFFSET3;

Use brackets ():

return (off - DCC_MAP_OFFSET3);

> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
> +			return off - DCC_MAP_OFFSET2;
> +		else if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL1)
> +			return off - DCC_MAP_OFFSET1;
> +	} else if (drvdata->mem_map_ver == DCC_MEM_MAP_VER2) {
> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
> +			return off - DCC_MAP_OFFSET4;
> +	}
> +
> +	return off;
> +}
> +
> +static int dcc_sram_writel(struct dcc_drvdata *drvdata,
> +					u32 val, u32 off)
> +{
> +	if (unlikely(off > (drvdata->ram_size - 4)))

A comment here would be good too.

> +		return -EINVAL;
> +
> +	writel(val, drvdata->ram_base + off);
> +
> +	return 0;
> +}
> +
> +static bool dcc_ready(struct dcc_drvdata *drvdata)
> +{
> +	u32 val;
> +
> +	return !readl_poll_timeout((drvdata->base + dcc_offset_conv(drvdata, DCC_STATUS)),
> +				val, (FIELD_GET(GENMASK(1, 0), val) == 0), 1, TIMEOUT_US);

"FIELD_GET(GENMASK(1, 0)" could be wrapped in a define.

> +
> +}
> +
> +static int dcc_read_status(struct dcc_drvdata *drvdata)
> +{
> +	int curr_list;
> +	u32 bus_status;
> +	u32 ll_cfg;
> +	u32 tmp_ll_cfg;
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> +		if (!drvdata->enable[curr_list])

This looks wrong to me. Why can't you simply allocate N number of linked list
structures based on the value read from hardware and do all list manipulations
with it? Like,

struct dcc_list {
	struct list_head cfg_head;
	bool enable;
	...
};

struct dcc_drvdata {
	...
	struct dcc_list *lists;
	...
};

/* List allocation */
dcc->lists = devm_kzalloc();

...

/* List initialization */
for (i = 0; i < dcc->nr_link_list; i++) {
	list = dcc->lists[i];
	INIT_LIST_HEAD(&list->cfg_head);
}

...

/* List manipulation */
list = dcc->lists[i];
list->enable = true;

> +			continue;
> +
> +		bus_status = dcc_readl(drvdata, DCC_LL_BUS_ACCESS_STATUS(curr_list));
> +

No new line needed here.

I'm stopping here. For the next revision, please split this patch into multiple
ones based on the functionality added. It is hard to review 1.3k LOC in a single
patch.

Thanks,
Mani

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Souradeep Chowdhury]

On 12/14/2021 10:55 PM, Manivannan Sadhasivam wrote:
> On Tue, Aug 10, 2021 at 11:24:38PM +0530, Souradeep Chowdhury wrote:
>> The DCC is a DMA Engine designed to capture and store data
>> during system crash or software triggers.The DCC operates
>> based on user inputs via the sysfs interface.The user gives
>> addresses as inputs and these addresses are stored in the
>> form of linkedlists.
> The linked lists are present in the hardware, right? You should state it
> explicitly.
Ack
>
>> In case of a system crash or a manual
> So what does a crash here means? How does DCC detect it?

In case of a system crashes like kernel panic , the dcc hardware gets 
activated

automatically and dumps the register values.Nothing needs to be done from

software side for that.

>
>> software trigger by the user through the sysfs interface,
>> the dcc captures and stores the values at these addresses.
> This could be reworded a bit:
>
> "DCC captures and stores the current values of the provided addresses in SRAM"
Ack
>
>> This patch contains the driver which has all the methods
>> pertaining to the sysfs interface, auxiliary functions to
>> support all the four fundamental operations of dcc namely
>> read, write, first read then write and loop.The probe method
>> here instantiates all the resources necessary for dcc to
>> operate mainly the dedicated dcc sram where it stores the
> Please use "DCC" everywhere.

Ack

>
>> values.The DCC driver can be used for debugging purposes
>> without going for a reboot since it can perform manual
>> triggers.
>>
> It allows users to perform software triggers for capturing values manually.
Ack
>
>> Also added the documentation for sysfs entries
>> and explained the functionalities of each sysfs file that
>> has been created for dcc.
>>
>> The following is the justification of using sysfs interface
>> over the other alternatives like ioctls
>>
>> i) As can be seen from the sysfs attribute descriptions,
>> most of it does basic hardware manipulations like dcc_enable,
>> dcc_disable, config reset etc. As a result sysfs is preferred
>> over ioctl as we just need to enter a 0 or 1.
>>
> This is not an apt reason to use sysfs. The one-value-per-file is a rule of
> sysfs not a criteria to use it.
Ack. Will be updating the justifications accordingly.
>
>> ii) Existing similar debug hardwares are there for which drivers
>> have been written using sysfs interface.One such example is the
>> coresight-etm-trace driver.A closer analog can also be the watchdog
>> subsystems though it is ioctls based.
>>
> Initially I thought that this driver could use debugfs interface, but going
> through it I feel that sysfs is more suited. Reason is, debugfs interface is
> used by drivers to expose debugging information additional to the function they
> do. But the sole usage of this driver depends on the configuration exported
> through the attributes and they looks to be an ABI to me.
Ack
>
>> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org>
>> ---
>>   Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
>>   drivers/soc/qcom/Kconfig                   |    8 +
>>   drivers/soc/qcom/Makefile                  |    1 +
>>   drivers/soc/qcom/dcc.c                     | 1549 ++++++++++++++++++++++++++++
>>   4 files changed, 1672 insertions(+)
>>   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>>   create mode 100644 drivers/soc/qcom/dcc.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc
>> new file mode 100644
>> index 0000000..05d24f0
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-driver-dcc
>> @@ -0,0 +1,114 @@
>> +What:           /sys/bus/platform/devices/.../trigger
>> +Date:           March 2021
> Please fix the dates of all attributes.
Ack
>
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This is the sysfs interface for manual software
> All entries should be aligned properly.
Ack
>
>> +		triggers.The user can simply enter a 1 against
>> +		the sysfs file and enable a manual trigger.
>> +		Example:
>> +		echo  1 > /sys/bus/platform/devices/.../trigger
> Why 2 spaces after echo?
Ack
>
>> +
>> +What:           /sys/bus/platform/devices/.../enable
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This sysfs interface is used for enabling the
>> +		the dcc hardware.Without this being set to 1,
> DCC here also. And a space after "." everywhere.
Ack
>
>> +		the dcc hardware ceases to function.
>> +		Example:
>> +		echo  0 > /sys/bus/platform/devices/.../enable
>> +		(disable interface)
>> +		echo  1 > /sys/bus/platform/devices/.../enable
>> +		(enable interface)
>> +
>> +What:           /sys/bus/platform/devices/.../config
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This is the most commonly used sysfs interface
>> +		file and this basically stores the addresses of
>> +		the registers which needs to be read in case of
>> +		a hardware crash or manual software triggers.
>> +		Example:
>> +		echo  0x80000010 10 > /sys/bus/platform/devices/../config
>> +		This specifies that 10 words starting from address
> words are of width?
32 bits, will update accordingly.
>
>> +		0x80000010 is to be read.In case there are no words to be
>> +		specified we can simply enter the address.
> No word to be read? So what's the purpose then?

This will only read the value at the address. By specifying the words , 
it will read the value of the

subsequent addresses as well. For example :-

echo  0x80000010 10 > /sys/bus/platform/devices/../config

This will also read and store the value at the next 9 addresses after 0x80000010.
  

>
>> +
>> +What:           /sys/bus/platform/devices/.../config_write
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This file allows user to write a value to the register
>> +		address given as argument.The values are entered in the
>> +		form of <register_address> <value>.The reason for this
>> +		feature of dcc is that for accessing certain registers
>> +		it is necessary to set some bits of soe other register.
> soe?
Ack
>
>> +		That is achievable by giving DCC this privelege.
> privilege
Ack
>
>> +		Example:
>> +		echo 0x80000000 0xFF > /sys/bus/platform/devices/.../config_write
>> +
>> +What:           /sys/bus/platform/devices/.../config_reset
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This file is used to reset the configuration of
>> +		a dcc driver to the default configuration.
> s/"a dcc driver"/"the DCC driver"/g
Ack
>
>> +		Example:
>> +		echo  1 > /sys/bus/platform/devices/.../config_reset
>> +
>> +What:           /sys/bus/platform/devices/.../loop
>> +Date:		March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This file is used to enter the loop count as dcc
>> +		driver gives the option to loop multiple times on
>> +		the same register and store the values for each
>> +		loop.This is done to capture the changing values
>> +		of a register with time which comes handy for
>> +		debugging purposes.
>> +		Example:
>> +		echo 10 > /sys/bus/platform/devices/10a2000.dcc/loop
>> +		(Setting the loop count to 10)
>> +		echo  0x80000010 10 > /sys/bus/platform/devices/.../config
>> +                (Read 10 words starting from address 0x80000010O)
>> +		echo 1 > /sys/bus/platform/devices/.../loop
>> +		(Terminate the loop by writing a count of 1 to the loop sysfs node)
>> +
>> +What:           /sys/bus/platform/devices/.../rd_mod_wr
> Can you come up with a better name? Like config_read_write?
Ack
>
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This file is used to read the value of the register
>> +		and then write the value given as an argument to the
>> +		register address in config.The address argument should
>> +		be given of the form <mask> <value>.For debugging
>> +		purposes sometimes we need to first read from a register
>> +		and then set some values to the register.
> Reading this description gives an impression that this file is used to read the
> value of a register. But it is write only and the value will be read only during
> the trigger or crash. So this should be stated explicitly.
Ack
>
>> +		Example:
>> +		echo 0x80000000 > /sys/bus/platform/devices/.../config
>> +		(Set the address in config file)
>> +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
>> +		(Provide the mask and the value to write)
>> +
>> +What:           /sys/bus/platform/devices/.../ready
>> +Date:           March 2021
>> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This file is used to check the status of the dcc
>> +		hardware if it's ready to take the inputs.
>> +		Example:
>> +		cat /sys/bus/platform/devices/.../ready
> Document the value read also.
Ack
>
>> +
>> +What:		/sys/bus/platform/devices/.../curr_list
>> +Date:		February 2021
>> +Contact:	Souradeep Chowdhury <schowdhu@codeaurora.org>
>> +Description:
>> +		This attribute is used to enter the linklist to be
>> +		used while appending addresses.The range of values
>> +		for this can be from 0 to 3.This feature is given in
>> +		order to use certain linkedlist for certain debugging
>> +		purposes.
>> +		Example:
>> +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
>> +
> How does a user will know the contents of the linked list? Basis on what
> criteria, user will know what value to write?

The purpose of creating separate linked list for the user was to provide 
them with a guidelines of

which linked list to use for which debugging purposes. There is no 
stringent rule as such for which

linked list to use but while debugging multiple components , this gives 
an advantage to the user.

>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 79b568f..5101912 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -69,6 +69,14 @@ config QCOM_LLCC
>>   	  SDM845. This provides interfaces to clients that use the LLCC.
>>   	  Say yes here to enable LLCC slice driver.
>>   
>> +config QCOM_DCC
>> +	tristate "Qualcomm Technologies, Inc. Data Capture and Compare(DCC) engine driver"
>> +	depends on ARCH_QCOM || COMPILE_TEST
>> +	help
>> +	  This option enables driver for Data Capture and Compare engine. DCC
>> +	  driver provides interface to configure DCC block and read back
>> +	  captured data from DCC's internal SRAM.
>> +
>>   config QCOM_KRYO_L2_ACCESSORS
>>   	bool
>>   	depends on ARCH_QCOM && ARM64 || COMPILE_TEST
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index ad675a6..0aaf82b 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -4,6 +4,7 @@ obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
>>   obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>>   obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>>   obj-$(CONFIG_QCOM_CPR)		+= cpr.o
>> +obj-$(CONFIG_QCOM_DCC) += dcc.o
>>   obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
>>   obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
>>   obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
>> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
>> new file mode 100644
>> index 0000000..daf4388
>> --- /dev/null
>> +++ b/drivers/soc/qcom/dcc.c
>> @@ -0,0 +1,1549 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/bitops.h>
>> +#include <linux/cdev.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/io.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/uaccess.h>
>> +
>> +#define TIMEOUT_US		5000
>> +
>> +#define dcc_writel(drvdata, val, off)					\
>> +	writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
>> +#define dcc_readl(drvdata, off)						\
>> +	readl(drvdata->base + dcc_offset_conv(drvdata, off))
>> +
>> +#define DCC_SRAM_NODE "dcc_sram"
>> +
>> +/* DCC registers */
>> +#define DCC_HW_INFO			0x04
>> +#define DCC_LL_NUM_INFO			0x10
>> +#define DCC_STATUS			0x1C
> Please use lower case for register offsets. Also, align the defines properly.
Ack
>
>> +#define DCC_LL_LOCK(m)			(0x34 + 0x80 * m)
>> +#define DCC_LL_CFG(m)			(0x38 + 0x80 * m)
>> +#define DCC_LL_BASE(m)			(0x3c + 0x80 * m)
>> +#define DCC_FD_BASE(m)			(0x40 + 0x80 * m)
>> +#define DCC_LL_TIMEOUT(m)		(0x44 + 0x80 * m)
>> +#define DCC_LL_INT_ENABLE(m)		(0x4C + 0x80 * m)
>> +#define DCC_LL_INT_STATUS(m)		(0x50 + 0x80 * m)
>> +#define DCC_LL_SW_TRIGGER(m)		(0x60 + 0x80 * m)
>> +#define DCC_LL_BUS_ACCESS_STATUS(m)	(0x64 + 0x80 * m)
>> +
>> +#define DCC_MAP_LEVEL1			0x18
>> +#define DCC_MAP_LEVEL2			0x34
>> +#define DCC_MAP_LEVEL3			0x4C
>> +
>> +#define DCC_MAP_OFFSET1			0x10
>> +#define DCC_MAP_OFFSET2			0x18
>> +#define DCC_MAP_OFFSET3			0x1C
>> +#define DCC_MAP_OFFSET4			0x8
>> +
>> +#define DCC_FIX_LOOP_OFFSET		16
>> +#define DCC_VER_INFO_BIT		9
>> +
>> +#define DCC_READ			0
>> +#define DCC_WRITE			1
>> +#define DCC_LOOP			2
>> +#define DCC_READ_WRITE			3
>> +
>> +#define MAX_DCC_OFFSET			GENMASK(9, 2)
>> +#define MAX_DCC_LEN			GENMASK(6, 0)
>> +#define MAX_LOOP_CNT			GENMASK(7, 0)
>> +
>> +#define DCC_ADDR_DESCRIPTOR		0x00
>> +#define DCC_ADDR_LIMIT			27
>> +#define DCC_ADDR_OFF_RANGE		8
>> +#define DCC_ADDR_RANGE			GENMASK(31, 4)
>> +#define DCC_LOOP_DESCRIPTOR		BIT(30)
>> +#define DCC_RD_MOD_WR_DESCRIPTOR	BIT(31)
>> +#define DCC_LINK_DESCRIPTOR		GENMASK(31, 30)
>> +
>> +#define DCC_READ_IND			0x00
>> +#define DCC_WRITE_IND			(BIT(28))
>> +
>> +#define DCC_AHB_IND			0x00
>> +#define DCC_APB_IND			BIT(29)
>> +
>> +#define DCC_MAX_LINK_LIST		8
>> +#define DCC_INVALID_LINK_LIST		GENMASK(7, 0)
>> +
>> +#define DCC_VER_MASK1			GENMASK(6, 0)
>> +#define DCC_VER_MASK2			GENMASK(5, 0)
>> +
>> +#define DCC_RD_MOD_WR_ADDR              0xC105E
>> +
>> +struct qcom_dcc_config {
>> +	int dcc_ram_offset;
> Are you planning to expand this structure? If not, please use "dcc_ram_offset"
> directly.
Ack
>
>> +};
>> +
>> +enum dcc_descriptor_type {
>> +	DCC_ADDR_TYPE,
>> +	DCC_LOOP_TYPE,
>> +	DCC_READ_WRITE_TYPE,
>> +	DCC_WRITE_TYPE
>> +};
>> +
>> +enum dcc_mem_map_ver {
>> +	DCC_MEM_MAP_VER1 = 1,
>> +	DCC_MEM_MAP_VER2 = 2,
>> +	DCC_MEM_MAP_VER3 = 3
>> +};
>> +
>> +struct dcc_config_entry {
>> +	u32				base;
>> +	u32				offset;
>> +	u32				len;
>> +	u32				index;
>> +	u32				loop_cnt;
>> +	u32				write_val;
>> +	u32				mask;
>> +	bool				apb_bus;
>> +	enum dcc_descriptor_type	desc_type;
>> +	struct list_head		list;
>> +};
>> +
>> +/**
>> + * struct dcc_drvdata - configuration information related to a dcc device
>> + * @base:	      Base Address of the dcc device
>> + * @dev:	      The device attached to the driver data
>> + * @mutex:	      Lock to protect access and manipulation of dcc_drvdata
> What? Are you trying to protect the whole structure or some fields?
whole structure in this case
>
>> + * @ram_base:         Base address for the SRAM dedicated for the dcc device
>> + * @ram_offset:       Offset to the SRAM dedicated for dcc device
>> + * @mem_map_ver:      Memory map version of DCC hardware
>> + * @ram_cfg:          Used for address limit calculation for dcc
>> + * @ram_start:        Starting address of DCC SRAM
>> + * @enable:	      Flag to check if DCC linked list is enabled
> This contains an array of linked list enable flags.
Ack
>
>> + * @interrupt_disable:Flag to enable/disable interrupts
> For simplicity, just use a space after colon.
Ack
>
>> + * @sram_dev:	      Character device equivalent of dcc SRAM
>> + * @sram_class:	      Class equivalent of the DCC SRAM device
>> + * @cfg_head:	      Points to the head of the linked list of addresses
>> + * @nr_config:        Stores the number of addresses currently configured for a linkedlist
>> + * @nr_link_list:     Total number of linkedlists supported by the DCC configuration
>> + * @curr_list:        The index of the current linklist with which the driver is working
>> + * @loopoff:          Loop offset bits range for the addresses
>> + */
>> +struct dcc_drvdata {
>> +	void __iomem		*base;
>> +	struct device		*dev;
>> +	struct mutex		mutex;
>> +	void __iomem		*ram_base;
>> +	phys_addr_t		ram_size;
>> +	phys_addr_t		ram_offset;
>> +	enum dcc_mem_map_ver	mem_map_ver;
>> +	phys_addr_t		ram_cfg;
>> +	phys_addr_t		ram_start;
>> +	bool			*enable;
>> +	bool			interrupt_disable;
> Move this to end to avoid holes.
Ack
>
>> +	struct cdev		sram_dev;
>> +	struct class		*sram_class;
>> +	struct list_head	*cfg_head;
>> +	size_t			*nr_config;
>> +	size_t			nr_link_list;
>> +	u8			curr_list;
>> +	u8			loopoff;
>> +};
> Is it possible to move the linked list specific members to a different struct?
Ack
>
>> +
>> +struct dcc_cfg_attr {
>> +	u32	addr;
>> +	u32	prev_addr;
>> +	u32	prev_off;
>> +	u32	link;
>> +	u32	sram_offset;
>> +};
>> +
>> +struct dcc_cfg_loop_attr {
>> +	u32	loop;
>> +	bool	loop_start;
> Move this to the end
Ack
>
>> +	u32	loop_cnt;
>> +	u32	loop_len;
>> +	u32	loop_off;
>> +};
>> +
>> +static size_t dcc_offset_conv(struct dcc_drvdata *drvdata, size_t off)
> Add comment on what this function does.
Ack
>
>> +{
>> +	if (drvdata->mem_map_ver == DCC_MEM_MAP_VER1) {
>> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL3)
> Use FIELD_* macros where applicable.
Ack
>
>> +			return off - DCC_MAP_OFFSET3;
> Use brackets ():
>
> return (off - DCC_MAP_OFFSET3);
Ack
>
>> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
>> +			return off - DCC_MAP_OFFSET2;
>> +		else if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL1)
>> +			return off - DCC_MAP_OFFSET1;
>> +	} else if (drvdata->mem_map_ver == DCC_MEM_MAP_VER2) {
>> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
>> +			return off - DCC_MAP_OFFSET4;
>> +	}
>> +
>> +	return off;
>> +}
>> +
>> +static int dcc_sram_writel(struct dcc_drvdata *drvdata,
>> +					u32 val, u32 off)
>> +{
>> +	if (unlikely(off > (drvdata->ram_size - 4)))
> A comment here would be good too.
Ack
>
>> +		return -EINVAL;
>> +
>> +	writel(val, drvdata->ram_base + off);
>> +
>> +	return 0;
>> +}
>> +
>> +static bool dcc_ready(struct dcc_drvdata *drvdata)
>> +{
>> +	u32 val;
>> +
>> +	return !readl_poll_timeout((drvdata->base + dcc_offset_conv(drvdata, DCC_STATUS)),
>> +				val, (FIELD_GET(GENMASK(1, 0), val) == 0), 1, TIMEOUT_US);
> "FIELD_GET(GENMASK(1, 0)" could be wrapped in a define.
Ack
>
>> +
>> +}
>> +
>> +static int dcc_read_status(struct dcc_drvdata *drvdata)
>> +{
>> +	int curr_list;
>> +	u32 bus_status;
>> +	u32 ll_cfg;
>> +	u32 tmp_ll_cfg;
>> +
>> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
>> +		if (!drvdata->enable[curr_list])
> This looks wrong to me. Why can't you simply allocate N number of linked list
> structures based on the value read from hardware and do all list manipulations
> with it? Like,
>
> struct dcc_list {
> 	struct list_head cfg_head;
> 	bool enable;
> 	...
> };
>
> struct dcc_drvdata {
> 	...
> 	struct dcc_list *lists;
> 	...
> };
>
> /* List allocation */
> dcc->lists = devm_kzalloc();
>
> ...
>
> /* List initialization */
> for (i = 0; i < dcc->nr_link_list; i++) {
> 	list = dcc->lists[i];
> 	INIT_LIST_HEAD(&list->cfg_head);
> }
>
> ...
>
> /* List manipulation */
> list = dcc->lists[i];
> list->enable = true;
Ack
>
>> +			continue;
>> +
>> +		bus_status = dcc_readl(drvdata, DCC_LL_BUS_ACCESS_STATUS(curr_list));
>> +
> No new line needed here.
Ack
>
> I'm stopping here. For the next revision, please split this patch into multiple
> ones based on the functionality added. It is hard to review 1.3k LOC in a single
> patch.

So in version 1 of this series, separate patches were posted for the 
driver but as per Bjorn's

suggestion this was merged as it was becoming difficult to review in 
that case as well.

>
> Thanks,
> Mani

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Bjorn Andersson]

On Tue 10 Aug 12:54 CDT 2021, Souradeep Chowdhury wrote:

> The DCC is a DMA Engine designed to capture and store data
> during system crash or software triggers.The DCC operates

Please include a space after '.'

> based on user inputs via the sysfs interface.The user gives
> addresses as inputs and these addresses are stored in the
> form of linkedlists.In case of a system crash or a manual

I think the user configures the DCC hardware with "a sequence of
operations to be performed as DCC is triggered".

Afaict the sequence is stored just as a sequence of operations in SRAM,
there's no linked list involved - except in your intermediate
implementation.

> software trigger by the user through the sysfs interface,
> the dcc captures and stores the values at these addresses.
> This patch contains the driver which has all the methods
> pertaining to the sysfs interface, auxiliary functions to
> support all the four fundamental operations of dcc namely
> read, write, first read then write and loop.The probe method

"first read then write" is called "read/modify/write"

> here instantiates all the resources necessary for dcc to
> operate mainly the dedicated dcc sram where it stores the
> values.The DCC driver can be used for debugging purposes
> without going for a reboot since it can perform manual
> triggers.
> 
> Also added the documentation for sysfs entries
> and explained the functionalities of each sysfs file that
> has been created for dcc.
> 
> The following is the justification of using sysfs interface
> over the other alternatives like ioctls
> 
> i) As can be seen from the sysfs attribute descriptions,
> most of it does basic hardware manipulations like dcc_enable,
> dcc_disable, config reset etc. As a result sysfs is preferred
> over ioctl as we just need to enter a 0 or 1.
> 

As I mentioned in our chat, using sysfs allows us to operate the
interface using the shell without additional tools.

But I don't think that it's easy to implement enable/disable/reset using
sysfs is a strong argument. The difficult part of this ABI is the
operations to manipulate the sequence of operations, so that's what you
need to have a solid plan for.

> ii) Existing similar debug hardwares are there for which drivers
> have been written using sysfs interface.One such example is the
> coresight-etm-trace driver.

Afaict the etm interface has operations to enable and disable, I don't
see anything that's similar to the interface for defining the sequence
of operations.

> A closer analog can also be the watchdog
> subsystems though it is ioctls based.
> 

I don't think this adds value to the argument for using a sysfs based
interface.

> Signed-off-by: Souradeep Chowdhury <schowdhu@codeaurora.org>
> ---
>  Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
>  drivers/soc/qcom/Kconfig                   |    8 +
>  drivers/soc/qcom/Makefile                  |    1 +
>  drivers/soc/qcom/dcc.c                     | 1549 ++++++++++++++++++++++++++++
>  4 files changed, 1672 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>  create mode 100644 drivers/soc/qcom/dcc.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc
> new file mode 100644
> index 0000000..05d24f0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-dcc
> @@ -0,0 +1,114 @@
> +What:           /sys/bus/platform/devices/.../trigger
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This is the sysfs interface for manual software
> +		triggers.The user can simply enter a 1 against
> +		the sysfs file and enable a manual trigger.
> +		Example:
> +		echo  1 > /sys/bus/platform/devices/.../trigger
> +
> +What:           /sys/bus/platform/devices/.../enable
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This sysfs interface is used for enabling the
> +		the dcc hardware.Without this being set to 1,
> +		the dcc hardware ceases to function.
> +		Example:
> +		echo  0 > /sys/bus/platform/devices/.../enable
> +		(disable interface)
> +		echo  1 > /sys/bus/platform/devices/.../enable
> +		(enable interface)
> +
> +What:           /sys/bus/platform/devices/.../config
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This is the most commonly used sysfs interface

No reason to mention that this is the most commonly used attribute, with
the right description that will be obvious.

> +		file and this basically stores the addresses of
> +		the registers which needs to be read in case of
> +		a hardware crash or manual software triggers.

This doesn't "basically store the..." it "appends a set of registers to
include in the snapshot to the currently selected list".

The description should cover the format at well, in particular there's
nothing in "the addresses" that indicates that it takes 1, 2 or 3
parameters.

> +		Example:
> +		echo  0x80000010 10 > /sys/bus/platform/devices/../config
> +		This specifies that 10 words starting from address
> +		0x80000010 is to be read.In case there are no words to be
> +		specified we can simply enter the address.
> +
> +What:           /sys/bus/platform/devices/.../config_write
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file allows user to write a value to the register
> +		address given as argument.The values are entered in the
> +		form of <register_address> <value>.The reason for this
> +		feature of dcc is that for accessing certain registers
> +		it is necessary to set some bits of soe other register.
> +		That is achievable by giving DCC this privelege.
> +		Example:
> +		echo 0x80000000 0xFF > /sys/bus/platform/devices/.../config_write
> +
> +What:           /sys/bus/platform/devices/.../config_reset
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to reset the configuration of
> +		a dcc driver to the default configuration.
> +		Example:
> +		echo  1 > /sys/bus/platform/devices/.../config_reset
> +
> +What:           /sys/bus/platform/devices/.../loop
> +Date:		March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to enter the loop count as dcc
> +		driver gives the option to loop multiple times on
> +		the same register and store the values for each
> +		loop.This is done to capture the changing values
> +		of a register with time which comes handy for
> +		debugging purposes.
> +		Example:
> +		echo 10 > /sys/bus/platform/devices/10a2000.dcc/loop
> +		(Setting the loop count to 10)
> +		echo  0x80000010 10 > /sys/bus/platform/devices/.../config
> +                (Read 10 words starting from address 0x80000010O)
> +		echo 1 > /sys/bus/platform/devices/.../loop
> +		(Terminate the loop by writing a count of 1 to the loop sysfs node)
> +
> +What:           /sys/bus/platform/devices/.../rd_mod_wr
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to read the value of the register
> +		and then write the value given as an argument to the
> +		register address in config.

It's not clear from this description how to use this operation. E.g. is
it appended to the same list of operations? When will this operation
happen?

Looking at the implementation I believe that "config", "config_write",
"loop" and "rd_mod_wr" all appends operations to the same list.

I think it would be much better to configure this with a single file
that can either be written to '>' or appended to '>>' and you would feed
it a sequence of the operations to be performed.

That said, I'm afraid that might no longer be a sysfs attribute.

Something like:
  # echo 'r 0x80000010 0x10' > config
  # echo 'w 0x80000000 0xff' >> config
  # echo 'rmw 0x80000000 0xf 0xa' >> config
  # echo 'l 0x80000010 10' >> config

and:
  # cat config
  r 0x80000010 0x10
  w 0x80000000 0xff
  rmw 0x80000000 0xf 0xa
  l 0x80000010 10

(Or read/write/modify/loop as keywords...)


reset could be done by just: echo '' > config

This would make it quite similar to several of the files in the tracing
framework.

> +		The address argument should
> +		be given of the form <mask> <value>.For debugging
> +		purposes sometimes we need to first read from a register
> +		and then set some values to the register.
> +		Example:
> +		echo 0x80000000 > /sys/bus/platform/devices/.../config
> +		(Set the address in config file)
> +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
> +		(Provide the mask and the value to write)
> +
> +What:           /sys/bus/platform/devices/.../ready
> +Date:           March 2021
> +Contact:        Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This file is used to check the status of the dcc
> +		hardware if it's ready to take the inputs.

When will this read "false"?

> +		Example:
> +		cat /sys/bus/platform/devices/.../ready
> +
> +What:		/sys/bus/platform/devices/.../curr_list
> +Date:		February 2021
> +Contact:	Souradeep Chowdhury <schowdhu@codeaurora.org>
> +Description:
> +		This attribute is used to enter the linklist to be

I think it would be more appropriate to use the verb "select" here and
afaict it's a "list" as the "linked" part only relates to your
implementation).

But that said, I don't like this ABI. I think it would be cleaner if you
had specific attributes for each of the lists. That way it would be
clear that you have N lists and they can be configured and enabled
independently, and there's no possible race conditions.

> +		used while appending addresses.The range of values
> +		for this can be from 0 to 3.This feature is given in
> +		order to use certain linkedlist for certain debugging
> +		purposes.
> +		Example:
> +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
> +
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 79b568f..5101912 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -69,6 +69,14 @@ config QCOM_LLCC
>  	  SDM845. This provides interfaces to clients that use the LLCC.
>  	  Say yes here to enable LLCC slice driver.
>  
> +config QCOM_DCC
> +	tristate "Qualcomm Technologies, Inc. Data Capture and Compare(DCC) engine driver"
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	help
> +	  This option enables driver for Data Capture and Compare engine. DCC
> +	  driver provides interface to configure DCC block and read back
> +	  captured data from DCC's internal SRAM.
> +
>  config QCOM_KRYO_L2_ACCESSORS
>  	bool
>  	depends on ARCH_QCOM && ARM64 || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ad675a6..0aaf82b 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
>  obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>  obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>  obj-$(CONFIG_QCOM_CPR)		+= cpr.o
> +obj-$(CONFIG_QCOM_DCC) += dcc.o
>  obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
>  obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> new file mode 100644
> index 0000000..daf4388
> --- /dev/null
> +++ b/drivers/soc/qcom/dcc.c
> @@ -0,0 +1,1549 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/cdev.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +#define TIMEOUT_US		5000
> +
> +#define dcc_writel(drvdata, val, off)					\
> +	writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
> +#define dcc_readl(drvdata, off)						\
> +	readl(drvdata->base + dcc_offset_conv(drvdata, off))
> +
> +#define DCC_SRAM_NODE "dcc_sram"
> +
> +/* DCC registers */
> +#define DCC_HW_INFO			0x04
> +#define DCC_LL_NUM_INFO			0x10
> +#define DCC_STATUS			0x1C
> +#define DCC_LL_LOCK(m)			(0x34 + 0x80 * m)
> +#define DCC_LL_CFG(m)			(0x38 + 0x80 * m)
> +#define DCC_LL_BASE(m)			(0x3c + 0x80 * m)
> +#define DCC_FD_BASE(m)			(0x40 + 0x80 * m)
> +#define DCC_LL_TIMEOUT(m)		(0x44 + 0x80 * m)
> +#define DCC_LL_INT_ENABLE(m)		(0x4C + 0x80 * m)
> +#define DCC_LL_INT_STATUS(m)		(0x50 + 0x80 * m)
> +#define DCC_LL_SW_TRIGGER(m)		(0x60 + 0x80 * m)
> +#define DCC_LL_BUS_ACCESS_STATUS(m)	(0x64 + 0x80 * m)
> +
> +#define DCC_MAP_LEVEL1			0x18
> +#define DCC_MAP_LEVEL2			0x34
> +#define DCC_MAP_LEVEL3			0x4C
> +
> +#define DCC_MAP_OFFSET1			0x10
> +#define DCC_MAP_OFFSET2			0x18
> +#define DCC_MAP_OFFSET3			0x1C
> +#define DCC_MAP_OFFSET4			0x8
> +
> +#define DCC_FIX_LOOP_OFFSET		16
> +#define DCC_VER_INFO_BIT		9
> +
> +#define DCC_READ			0
> +#define DCC_WRITE			1
> +#define DCC_LOOP			2
> +#define DCC_READ_WRITE			3
> +
> +#define MAX_DCC_OFFSET			GENMASK(9, 2)
> +#define MAX_DCC_LEN			GENMASK(6, 0)
> +#define MAX_LOOP_CNT			GENMASK(7, 0)
> +
> +#define DCC_ADDR_DESCRIPTOR		0x00
> +#define DCC_ADDR_LIMIT			27
> +#define DCC_ADDR_OFF_RANGE		8
> +#define DCC_ADDR_RANGE			GENMASK(31, 4)
> +#define DCC_LOOP_DESCRIPTOR		BIT(30)
> +#define DCC_RD_MOD_WR_DESCRIPTOR	BIT(31)
> +#define DCC_LINK_DESCRIPTOR		GENMASK(31, 30)
> +
> +#define DCC_READ_IND			0x00
> +#define DCC_WRITE_IND			(BIT(28))
> +
> +#define DCC_AHB_IND			0x00
> +#define DCC_APB_IND			BIT(29)
> +
> +#define DCC_MAX_LINK_LIST		8
> +#define DCC_INVALID_LINK_LIST		GENMASK(7, 0)
> +
> +#define DCC_VER_MASK1			GENMASK(6, 0)
> +#define DCC_VER_MASK2			GENMASK(5, 0)
> +
> +#define DCC_RD_MOD_WR_ADDR              0xC105E
> +
> +struct qcom_dcc_config {
> +	int dcc_ram_offset;
> +};
> +
> +enum dcc_descriptor_type {
> +	DCC_ADDR_TYPE,
> +	DCC_LOOP_TYPE,
> +	DCC_READ_WRITE_TYPE,
> +	DCC_WRITE_TYPE
> +};
> +
> +enum dcc_mem_map_ver {
> +	DCC_MEM_MAP_VER1 = 1,
> +	DCC_MEM_MAP_VER2 = 2,
> +	DCC_MEM_MAP_VER3 = 3
> +};
> +
> +struct dcc_config_entry {
> +	u32				base;
> +	u32				offset;
> +	u32				len;
> +	u32				index;
> +	u32				loop_cnt;
> +	u32				write_val;
> +	u32				mask;
> +	bool				apb_bus;
> +	enum dcc_descriptor_type	desc_type;
> +	struct list_head		list;
> +};
> +
> +/**
> + * struct dcc_drvdata - configuration information related to a dcc device
> + * @base:	      Base Address of the dcc device
> + * @dev:	      The device attached to the driver data
> + * @mutex:	      Lock to protect access and manipulation of dcc_drvdata
> + * @ram_base:         Base address for the SRAM dedicated for the dcc device
> + * @ram_offset:       Offset to the SRAM dedicated for dcc device
> + * @mem_map_ver:      Memory map version of DCC hardware
> + * @ram_cfg:          Used for address limit calculation for dcc
> + * @ram_start:        Starting address of DCC SRAM
> + * @enable:	      Flag to check if DCC linked list is enabled
> + * @interrupt_disable:Flag to enable/disable interrupts
> + * @sram_dev:	      Character device equivalent of dcc SRAM
> + * @sram_class:	      Class equivalent of the DCC SRAM device
> + * @cfg_head:	      Points to the head of the linked list of addresses

This isn't a list "of addresses" it's the list of operations that, when
written to sram, will be executed when the DCC trigger happens.

> + * @nr_config:        Stores the number of addresses currently configured for a linkedlist
> + * @nr_link_list:     Total number of linkedlists supported by the DCC configuration
> + * @curr_list:        The index of the current linklist with which the driver is working
> + * @loopoff:          Loop offset bits range for the addresses
> + */
> +struct dcc_drvdata {
> +	void __iomem		*base;
> +	struct device		*dev;
> +	struct mutex		mutex;
> +	void __iomem		*ram_base;
> +	phys_addr_t		ram_size;

ram_size sounds like a size_t

> +	phys_addr_t		ram_offset;

This can be size_t as well, or unsigned int.

> +	enum dcc_mem_map_ver	mem_map_ver;
> +	phys_addr_t		ram_cfg;
> +	phys_addr_t		ram_start;
> +	bool			*enable;
> +	bool			interrupt_disable;
> +	struct cdev		sram_dev;
> +	struct class		*sram_class;
> +	struct list_head	*cfg_head;
> +	size_t			*nr_config;
> +	size_t			nr_link_list;
> +	u8			curr_list;
> +	u8			loopoff;
> +};
> +
> +struct dcc_cfg_attr {
> +	u32	addr;
> +	u32	prev_addr;
> +	u32	prev_off;
> +	u32	link;
> +	u32	sram_offset;
> +};
> +
> +struct dcc_cfg_loop_attr {
> +	u32	loop;
> +	bool	loop_start;
> +	u32	loop_cnt;
> +	u32	loop_len;
> +	u32	loop_off;
> +};
> +
> +static size_t dcc_offset_conv(struct dcc_drvdata *drvdata, size_t off)
> +{
> +	if (drvdata->mem_map_ver == DCC_MEM_MAP_VER1) {
> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL3)
> +			return off - DCC_MAP_OFFSET3;
> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
> +			return off - DCC_MAP_OFFSET2;
> +		else if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL1)
> +			return off - DCC_MAP_OFFSET1;
> +	} else if (drvdata->mem_map_ver == DCC_MEM_MAP_VER2) {
> +		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
> +			return off - DCC_MAP_OFFSET4;
> +	}
> +
> +	return off;
> +}
> +
> +static int dcc_sram_writel(struct dcc_drvdata *drvdata,
> +					u32 val, u32 off)
> +{
> +	if (unlikely(off > (drvdata->ram_size - 4)))
> +		return -EINVAL;

ENOSPC seems better

> +
> +	writel(val, drvdata->ram_base + off);
> +
> +	return 0;
> +}
> +
> +static bool dcc_ready(struct dcc_drvdata *drvdata)

This name gives a feeling that it might relate to the "ready" sysfs
attribute, but it's actually "dcc_sw_trigger_done()", so I think it
would be better to just inline the readl_poll_timeout() directly in
dcc_sw_trigger().

> +{
> +	u32 val;
> +
> +	return !readl_poll_timeout((drvdata->base + dcc_offset_conv(drvdata, DCC_STATUS)),
> +				val, (FIELD_GET(GENMASK(1, 0), val) == 0), 1, TIMEOUT_US);

GENMASK(1,0) would be better represented by well named define.

> +
> +}
> +
> +static int dcc_read_status(struct dcc_drvdata *drvdata)

This function name gives an impression that you're just querying the
state, but it seems to be doing "read and clear".

> +{
> +	int curr_list;
> +	u32 bus_status;
> +	u32 ll_cfg;
> +	u32 tmp_ll_cfg;
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {

I find it confusing that you're using curr_list as iterator in these
local functions as well as denoting the currently selected list.

If you just made the local variable "i" it would be obvious that it's a
local iterator/index.

> +		if (!drvdata->enable[curr_list])
> +			continue;
> +
> +		bus_status = dcc_readl(drvdata, DCC_LL_BUS_ACCESS_STATUS(curr_list));
> +
> +		if (bus_status) {
> +			dev_err(drvdata->dev,
> +				"Read access error for list %d err: 0x%x.\n",
> +				curr_list, bus_status);
> +
> +			ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
> +			tmp_ll_cfg = ll_cfg & ~BIT(9);

Can we have a define for BIT(9) in this register?

> +			dcc_writel(drvdata, tmp_ll_cfg, DCC_LL_CFG(curr_list));
> +			dcc_writel(drvdata, 0x3,

Same for 0x3?

> +				DCC_LL_BUS_ACCESS_STATUS(curr_list));
> +			dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
> +			return -ENODATA;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int dcc_sw_trigger(struct dcc_drvdata *drvdata)
> +{
> +	int ret;
> +	int curr_list;
> +	u32 ll_cfg;
> +	u32 tmp_ll_cfg;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> +		if (!drvdata->enable[curr_list])
> +			continue;
> +		ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
> +		tmp_ll_cfg = ll_cfg & ~BIT(9);
> +		dcc_writel(drvdata, tmp_ll_cfg, DCC_LL_CFG(curr_list));
> +		dcc_writel(drvdata, 1, DCC_LL_SW_TRIGGER(curr_list));
> +		dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
> +	}
> +
> +	if (!dcc_ready(drvdata)) {
> +		dev_err(drvdata->dev,
> +			"DCC is busy after receiving sw tigger.\n");
> +		ret = -EBUSY;
> +		goto err;
> +	}
> +
> +	ret = dcc_read_status(drvdata);
> +
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static void _dcc_ll_cfg_reset_link(struct dcc_cfg_attr *cfg)
> +{
> +	cfg->addr = 0x00;
> +	cfg->link = 0;
> +	cfg->prev_off = 0;
> +	cfg->prev_addr = cfg->addr;
> +}
> +
> +static int _dcc_ll_cfg_read_write(struct dcc_drvdata *drvdata,
> +				  struct dcc_config_entry *entry,
> +				  struct dcc_cfg_attr *cfg)
> +{
> +	int ret;
> +
> +	if (cfg->link) {
> +		/*
> +		 * write new offset = 1 to continue
> +		 * processing the list
> +		 */
> +
> +		ret = dcc_sram_writel(drvdata, cfg->link, cfg->sram_offset);

This api seems rather "raw" and every time you call it you need to check
the return value and increment sram_offset with 4.

I think it would be nicer if you passed &cfg->sram_offset and
incremented that inside the function. You could go further by not
providing a return value and just speculatively perform all the
dcc_sram_writel() operations and then finally check if it overflowed at
the end of __dcc_ll_cfg().

> +		if (ret)
> +			return ret;
> +		cfg->sram_offset += 4;
> +		/* Reset link and prev_off */
> +		_dcc_ll_cfg_reset_link(cfg);
> +	}
> +
> +	cfg->addr = DCC_RD_MOD_WR_DESCRIPTOR;
> +	ret = dcc_sram_writel(drvdata, cfg->addr, cfg->sram_offset);
> +	if (ret)
> +		return ret;
> +
> +	cfg->sram_offset += 4;
> +	ret = dcc_sram_writel(drvdata, entry->mask, cfg->sram_offset);
> +	if (ret)
> +		return ret;
> +
> +	cfg->sram_offset += 4;
> +	ret = dcc_sram_writel(drvdata, entry->write_val, cfg->sram_offset);
> +	if (ret)
> +		return ret;
> +
> +	cfg->sram_offset += 4;
> +	cfg->addr = 0;
> +	return ret;
> +}
> +
> +static int _dcc_ll_cfg_loop(struct dcc_drvdata *drvdata, struct dcc_config_entry *entry,
> +			    struct dcc_cfg_attr *cfg,
> +			    struct dcc_cfg_loop_attr *cfg_loop,
> +			    u32 *total_len)
> +{
> +
> +	int ret;
> +
> +	/* Check if we need to write link of prev entry */
> +	if (cfg->link) {
> +		ret = dcc_sram_writel(drvdata, cfg->link, cfg->sram_offset);
> +		if (ret)
> +			return ret;
> +		cfg->sram_offset += 4;
> +	}
> +
> +	if (cfg_loop->loop_start) {

So you simply add an even number of loop entries in your list and every
even one is supposed to jump to the previous odd one.

> +		cfg_loop->loop = (cfg->sram_offset - cfg_loop->loop_off) / 4;
> +		cfg_loop->loop |= (cfg_loop->loop_cnt << drvdata->loopoff) &
> +		GENMASK(DCC_ADDR_LIMIT, drvdata->loopoff);
> +		cfg_loop->loop |= DCC_LOOP_DESCRIPTOR;
> +		*total_len += (*total_len - cfg_loop->loop_len) * cfg_loop->loop_cnt;
> +
> +		ret = dcc_sram_writel(drvdata, cfg_loop->loop, cfg->sram_offset);
> +		if (ret)
> +			return ret;
> +		cfg->sram_offset += 4;
> +
> +		cfg_loop->loop_start = false;
> +		cfg_loop->loop_len = 0;
> +		cfg_loop->loop_off = 0;
> +	} else {
> +		cfg_loop->loop_start = true;
> +		cfg_loop->loop_cnt = entry->loop_cnt - 1;
> +		cfg_loop->loop_len = *total_len;
> +		cfg_loop->loop_off = cfg->sram_offset;
> +	}
> +
> +	/* Reset link and prev_off */
> +	_dcc_ll_cfg_reset_link(cfg);
> +
> +	return ret;
> +}
> +
> +static int _dcc_ll_cfg_write(struct dcc_drvdata *drvdata,
> +			     struct dcc_config_entry *entry,
> +			     struct dcc_cfg_attr *cfg,
> +			     u32 *total_len)
> +{
> +	u32 off;
> +	int ret;
> +
> +	if (cfg->link) {
> +		/*
> +		 * write new offset = 1 to continue
> +		 * processing the list
> +		 */
> +		ret = dcc_sram_writel(drvdata, cfg->link, cfg->sram_offset);
> +
> +		if (ret)
> +			return ret;
> +
> +		cfg->sram_offset += 4;
> +		/* Reset link and prev_off */
> +		cfg->addr = 0x00;
> +		cfg->prev_off = 0;
> +		cfg->prev_addr = cfg->addr;
> +	}
> +
> +	off = entry->offset/4;
> +	/* write new offset-length pair to correct position */
> +	cfg->link |= ((off & GENMASK(7, 0)) | BIT(15) | ((entry->len << 8) & GENMASK(14, 8)));
> +	cfg->link |= DCC_LINK_DESCRIPTOR;
> +
> +	/* Address type */
> +	cfg->addr = (entry->base >> 4) & GENMASK(DCC_ADDR_LIMIT, 0);
> +	if (entry->apb_bus)
> +		cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_WRITE_IND | DCC_APB_IND;
> +	else
> +		cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_WRITE_IND | DCC_AHB_IND;
> +	ret = dcc_sram_writel(drvdata, cfg->addr, cfg->sram_offset);
> +
> +	if (ret)
> +		return ret;
> +	cfg->sram_offset += 4;
> +
> +	ret = dcc_sram_writel(drvdata, cfg->link, cfg->sram_offset);
> +	if (ret)
> +		return ret;
> +	cfg->sram_offset += 4;
> +
> +	ret = dcc_sram_writel(drvdata, entry->write_val, cfg->sram_offset);
> +
> +	if (ret)
> +		return ret;
> +
> +	cfg->sram_offset += 4;
> +	cfg->addr = 0x00;
> +	cfg->link = 0;
> +	return ret;
> +}
> +
> +static int _dcc_ll_cfg_default(struct dcc_drvdata *drvdata,

Why is this called "default" and not "read"?

> +			       struct dcc_config_entry *entry,
> +			       struct dcc_cfg_attr *cfg,
> +			       u32 *pos, u32 *total_len)
> +{
> +	int ret;
> +	u32 off;
> +	u32 temp_off;
> +
> +	cfg->addr = (entry->base >> 4) & GENMASK(27, 0);
> +
> +	if (entry->apb_bus)
> +		cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_READ_IND | DCC_APB_IND;
> +	else
> +		cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_READ_IND | DCC_AHB_IND;
> +
> +	off = entry->offset/4;
> +
> +	*total_len += entry->len * 4;
> +
> +	if (!cfg->prev_addr || cfg->prev_addr != cfg->addr || cfg->prev_off > off) {
> +		/* Check if we need to write prev link entry */
> +		if (cfg->link) {
> +			ret = dcc_sram_writel(drvdata, cfg->link, cfg->sram_offset);
> +			if (ret)
> +				return ret;
> +			cfg->sram_offset += 4;
> +		}
> +		dev_dbg(drvdata->dev, "DCC: sram address 0x%x\n", cfg->sram_offset);
> +
> +		/* Write address */
> +		ret = dcc_sram_writel(drvdata, cfg->addr, cfg->sram_offset);
> +
> +		if (ret)
> +			return ret;
> +
> +		cfg->sram_offset += 4;
> +
> +		/* Reset link and prev_off */
> +		cfg->link = 0;
> +		cfg->prev_off = 0;
> +	}
> +
> +	if ((off - cfg->prev_off) > 0xFF || entry->len > MAX_DCC_LEN) {
> +		dev_err(drvdata->dev, "DCC: Programming error Base: 0x%x, offset 0x%x\n",
> +		entry->base, entry->offset);
> +		ret = -EINVAL;
> +		return ret;
> +	}
> +
> +	if (cfg->link) {
> +		/*
> +		 * link already has one offset-length so new
> +		 * offset-length needs to be placed at
> +		 * bits [29:15]
> +		 */
> +		*pos = 15;
> +
> +		/* Clear bits [31:16] */
> +		cfg->link &= GENMASK(14, 0);
> +	} else {
> +		/*
> +		 * link is empty, so new offset-length needs
> +		 * to be placed at bits [15:0]
> +		 */
> +		*pos = 0;
> +		cfg->link = 1 << 15;
> +	}
> +
> +	/* write new offset-length pair to correct position */
> +	temp_off = (off-cfg->prev_off) & GENMASK(7, 0);
> +	cfg->link |= temp_off |((entry->len << 8) & GENMASK(14, 8)) << *pos;
> +
> +	cfg->link |= DCC_LINK_DESCRIPTOR;
> +
> +	if (*pos) {
> +		ret = dcc_sram_writel(drvdata, cfg->link, cfg->sram_offset);
> +		if (ret)
> +			return ret;
> +		cfg->sram_offset += 4;
> +		cfg->link = 0;
> +	}
> +
> +	cfg->prev_off  = off + entry->len - 1;
> +	cfg->prev_addr = cfg->addr;
> +	return ret;
> +}
> +
> +static int __dcc_ll_cfg(struct dcc_drvdata *drvdata, int curr_list)

I guess this is an abbreviation of dcc_linked_list_config?

Why not something like dcc_emit_config() and then above might be
dcc_emit_read(), dcc_emit_write() etc?

> +{
> +	int ret = 0;

Afaict this the first access to this is an assignment in all code paths,
so please skip the initialization.

> +	u32 total_len, pos;
> +	struct dcc_config_entry *entry;
> +	struct dcc_cfg_attr cfg;
> +	struct dcc_cfg_loop_attr cfg_loop;
> +
> +	memset(&cfg, 0, sizeof(cfg));
> +	memset(&cfg_loop, 0, sizeof(cfg_loop));
> +	cfg.sram_offset = drvdata->ram_cfg * 4;
> +	total_len = 0;
> +
> +	list_for_each_entry(entry, &drvdata->cfg_head[curr_list], list) {
> +		switch (entry->desc_type) {
> +		case DCC_READ_WRITE_TYPE:
> +			ret = _dcc_ll_cfg_read_write(drvdata, entry, &cfg);
> +			if (ret)
> +				goto overstep;
> +			break;
> +
> +		case DCC_LOOP_TYPE:
> +			ret = _dcc_ll_cfg_loop(drvdata, entry, &cfg, &cfg_loop, &total_len);
> +			if (ret)
> +				goto overstep;
> +			break;
> +
> +		case DCC_WRITE_TYPE:
> +			ret = _dcc_ll_cfg_write(drvdata, entry, &cfg, &total_len);
> +			if (ret)
> +				goto overstep;
> +			break;
> +
> +		default:
> +			ret = _dcc_ll_cfg_default(drvdata, entry, &cfg, &pos, &total_len);
> +			if (ret)
> +				goto overstep;
> +			break;
> +		}
> +	}
> +
> +	if (cfg.link) {
> +		ret = dcc_sram_writel(drvdata, cfg.link, cfg.sram_offset);
> +		if (ret)
> +			goto overstep;
> +		cfg.sram_offset += 4;
> +	}
> +
> +	if (cfg_loop.loop_start) {
> +		dev_err(drvdata->dev, "DCC: Programming error: Loop unterminated\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	/* Handling special case of list ending with a rd_mod_wr */
> +	if (cfg.addr == DCC_RD_MOD_WR_DESCRIPTOR) {
> +		cfg.addr = (DCC_RD_MOD_WR_ADDR) & GENMASK(27, 0);
> +		cfg.addr |= DCC_ADDR_DESCRIPTOR;
> +		ret = dcc_sram_writel(drvdata, cfg.addr, cfg.sram_offset);
> +		if (ret)
> +			goto overstep;
> +		cfg.sram_offset += 4;
> +	}
> +
> +	/* Setting zero to indicate end of the list */
> +	cfg.link = DCC_LINK_DESCRIPTOR;
> +	ret = dcc_sram_writel(drvdata, cfg.link, cfg.sram_offset);
> +	if (ret)
> +		goto overstep;
> +	cfg.sram_offset += 4;
> +
> +	/* Update ram_cfg and check if the data will overstep */
> +
> +	drvdata->ram_cfg = (cfg.sram_offset + total_len) / 4;
> +
> +	if (cfg.sram_offset + total_len > drvdata->ram_size) {
> +		cfg.sram_offset += total_len;
> +		goto overstep;
> +	}
> +
> +	drvdata->ram_start = cfg.sram_offset/4;
> +	return 0;
> +overstep:
> +	ret = -EINVAL;
> +	memset_io(drvdata->ram_base, 0, drvdata->ram_size);
> +
> +err:
> +	return ret;
> +}
> +
> +static int dcc_valid_list(struct dcc_drvdata *drvdata, int curr_list)
> +{
> +	u32 lock_reg;
> +
> +	if (list_empty(&drvdata->cfg_head[curr_list]))
> +		return -EINVAL;
> +
> +	if (drvdata->enable[curr_list]) {
> +		dev_err(drvdata->dev, "List %d is already enabled\n",
> +				curr_list);
> +		return -EINVAL;
> +	}
> +
> +	lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(curr_list));

Under what circumstances would this differ from
drvdata->enable[curr_list}?

> +	if (lock_reg & 0x1) {
> +		dev_err(drvdata->dev, "List %d is already locked\n",
> +				curr_list);
> +		return -EINVAL;
> +	}
> +
> +	dev_err(drvdata->dev, "DCC list passed %d\n", curr_list);

This is noise, please drop it.

> +	return 0;
> +}
> +
> +static bool is_dcc_enabled(struct dcc_drvdata *drvdata)
> +{
> +	bool dcc_enable = false;
> +	int list;
> +
> +	for (list = 0; list < DCC_MAX_LINK_LIST; list++) {
> +		if (drvdata->enable[list]) {

			return true;

> +			dcc_enable = true;
> +			break;
> +		}
> +	}
> +

	return false;

> +	return dcc_enable;
> +}
> +
> +static int dcc_enable(struct dcc_drvdata *drvdata)
> +{
> +	int ret = 0;
> +	int list;
> +	u32 ram_cfg_base;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	if (!is_dcc_enabled(drvdata)) {
> +		memset_io(drvdata->ram_base,
> +			0xDE, drvdata->ram_size);

No need to wrap this line, and please use lowercase hex digits.

> +	}
> +
> +	for (list = 0; list < drvdata->nr_link_list; list++) {
> +

Please drop the empty line.

> +		if (dcc_valid_list(drvdata, list))
> +			continue;
> +
> +		/* 1. Take ownership of the list */
> +		dcc_writel(drvdata, BIT(0), DCC_LL_LOCK(list));

Can we have a define for BIT(0)? Is it really about ownership or just
that we "enable" it?

If ownership, who's the other contenders for the ownership?

> +
> +		/* 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;
> +
> +		/* 5. Configure trigger */
> +		dcc_writel(drvdata, BIT(9), DCC_LL_CFG(list));
> +	}
> +
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static void dcc_disable(struct dcc_drvdata *drvdata)
> +{
> +	int curr_list;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> +		if (!drvdata->enable[curr_list])
> +			continue;
> +		dcc_writel(drvdata, 0, DCC_LL_CFG(curr_list));
> +		dcc_writel(drvdata, 0, DCC_LL_BASE(curr_list));
> +		dcc_writel(drvdata, 0, DCC_FD_BASE(curr_list));
> +		dcc_writel(drvdata, 0, DCC_LL_LOCK(curr_list));
> +		drvdata->enable[curr_list] = false;
> +	}
> +	memset_io(drvdata->ram_base, 0, drvdata->ram_size);

Is there any reason why DCC is filled with 0xde during initialization
but 0 when disabled?

> +	drvdata->ram_cfg = 0;
> +	drvdata->ram_start = 0;
> +	mutex_unlock(&drvdata->mutex);
> +}
> +
> +static ssize_t curr_list_show(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	int ret;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +	if (drvdata->curr_list == DCC_INVALID_LINK_LIST) {
> +		dev_err(dev, "curr_list is not set.\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	ret = scnprintf(buf, PAGE_SIZE, "%d\n",	drvdata->curr_list);
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static ssize_t curr_list_store(struct device *dev,
> +						struct device_attribute *attr,
> +						const char *buf, size_t size)
> +{
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +	unsigned long val;
> +	u32 lock_reg;
> +	bool dcc_enable = false;
> +
> +	if (kstrtoul(buf, 16, &val))
> +		return -EINVAL;
> +
> +	if (val >= drvdata->nr_link_list)
> +		return -EINVAL;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	dcc_enable = is_dcc_enabled(drvdata);
> +	if (drvdata->curr_list != DCC_INVALID_LINK_LIST	&& dcc_enable) {
> +		dev_err(drvdata->dev, "DCC is enabled, please disable it first.\n");
> +		mutex_unlock(&drvdata->mutex);
> +		return -EINVAL;
> +	}
> +
> +	lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(val));
> +	if (lock_reg & 0x1) {
> +		dev_err(drvdata->dev, "DCC linked list is already configured\n");
> +		mutex_unlock(&drvdata->mutex);
> +		return -EINVAL;
> +	}
> +	drvdata->curr_list = val;
> +	mutex_unlock(&drvdata->mutex);
> +
> +	return size;
> +}
> +
> +static DEVICE_ATTR_RW(curr_list);
> +
> +
> +static ssize_t trigger_store(struct device *dev,
> +					struct device_attribute *attr,
> +					const char *buf, size_t size)
> +{
> +	int ret = 0;
> +	unsigned long val;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (kstrtoul(buf, 16, &val))
> +		return -EINVAL;
> +	if (val != 1)
> +		return -EINVAL;
> +
> +	ret = dcc_sw_trigger(drvdata);
> +	if (!ret)
> +		ret = size;
> +
> +	return ret;
> +}
> +static DEVICE_ATTR_WO(trigger);
> +
> +static ssize_t enable_show(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	int ret;
> +	bool dcc_enable = false;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	dcc_enable = is_dcc_enabled(drvdata);
> +
> +	ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> +				(unsigned int)dcc_enable);
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static ssize_t enable_store(struct device *dev,
> +				struct device_attribute *attr,
> +				const char *buf, size_t size)
> +{
> +	int ret = 0;
> +	unsigned long val;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (kstrtoul(buf, 16, &val))
> +		return -EINVAL;
> +
> +	if (val)
> +		ret = dcc_enable(drvdata);
> +	else
> +		dcc_disable(drvdata);
> +
> +	if (!ret)
> +		ret = size;
> +
> +	return ret;
> +
> +}
> +
> +static DEVICE_ATTR_RW(enable);
> +
> +static ssize_t config_show(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +	struct dcc_config_entry *entry;
> +	char local_buf[64];
> +	int len = 0, count = 0;
> +
> +	mutex_lock(&drvdata->mutex);
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");
> +		count = -EINVAL;
> +		goto err;
> +	}
> +
> +	list_for_each_entry(entry,
> +	&drvdata->cfg_head[drvdata->curr_list], list) {
> +		switch (entry->desc_type) {
> +		case DCC_READ_WRITE_TYPE:
> +			len = snprintf(local_buf, 64, "Index: 0x%x, mask: 0x%x, val: 0x%x\n",
> +				entry->index, entry->mask, entry->write_val);
> +			break;
> +		case DCC_LOOP_TYPE:
> +			len = snprintf(local_buf, 64, "Index: 0x%x, Loop: %d\n",
> +				entry->index, entry->loop_cnt);
> +			break;
> +		case DCC_WRITE_TYPE:
> +			len = snprintf(local_buf, 64,
> +				"Write Index: 0x%x, Base: 0x%x, Offset: 0x%x, len: 0x%x APB: %d\n",
> +				entry->index, entry->base, entry->offset, entry->len,
> +				entry->apb_bus);
> +			break;
> +		default:
> +			len = snprintf(local_buf, 64,
> +				"Read Index: 0x%x, Base: 0x%x, Offset: 0x%x, len: 0x%x APB: %d\n",
> +				entry->index, entry->base, entry->offset,
> +				entry->len, entry->apb_bus);
> +		}
> +
> +		if ((count + len) > PAGE_SIZE) {
> +			dev_err(dev, "DCC: Couldn't write complete config\n");
> +			break;
> +		}
> +		count += len;
> +	}
> +
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return count;
> +}
> +
> +static int dcc_config_add(struct dcc_drvdata *drvdata, unsigned int addr,
> +				unsigned int len, int apb_bus)
> +{
> +	int ret;
> +	struct dcc_config_entry *entry, *pentry;
> +	unsigned int base, offset;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(drvdata->dev, "Select link list to program using curr_list\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (!len || len > (drvdata->ram_size / DCC_ADDR_OFF_RANGE)) {
> +		dev_err(drvdata->dev, "DCC: Invalid length\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	base = addr & DCC_ADDR_RANGE;
> +
> +	if (!list_empty(&drvdata->cfg_head[drvdata->curr_list])) {
> +		pentry = list_last_entry(&drvdata->cfg_head[drvdata->curr_list],
> +			struct dcc_config_entry, list);
> +
> +		if (pentry->desc_type == DCC_ADDR_TYPE &&
> +				addr >= (pentry->base + pentry->offset) &&
> +				addr <= (pentry->base +
> +					pentry->offset + MAX_DCC_OFFSET)) {
> +
> +			/* Re-use base address from last entry */
> +			base = pentry->base;
> +
> +			if ((pentry->len * 4 + pentry->base + pentry->offset)
> +					== addr) {
> +				len += pentry->len;
> +
> +				if (len > MAX_DCC_LEN)
> +					pentry->len = MAX_DCC_LEN;
> +				else
> +					pentry->len = len;
> +
> +				addr = pentry->base + pentry->offset +
> +					pentry->len * 4;
> +				len -= pentry->len;
> +			}
> +		}
> +	}
> +
> +	offset = addr - base;
> +
> +	while (len) {
> +		entry = devm_kzalloc(drvdata->dev, sizeof(*entry), GFP_KERNEL);
> +		if (!entry) {
> +			ret = -ENOMEM;
> +			goto err;
> +		}
> +
> +		entry->base = base;
> +		entry->offset = offset;
> +		entry->len = min_t(u32, len, MAX_DCC_LEN);
> +		entry->index = drvdata->nr_config[drvdata->curr_list]++;

Every time you insert something in the list you calculate and store
"index", which I presume means that it will be the index'th entry in
sram. Why not just calculate this as you flush out the list to sram?

> +		entry->desc_type = DCC_ADDR_TYPE;
> +		entry->apb_bus = apb_bus;
> +		INIT_LIST_HEAD(&entry->list);
> +		list_add_tail(&entry->list,
> +			&drvdata->cfg_head[drvdata->curr_list]);
> +
> +		len -= entry->len;
> +		offset += MAX_DCC_LEN * 4;
> +	}
> +
> +	mutex_unlock(&drvdata->mutex);
> +	return 0;
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static ssize_t config_store(struct device *dev,
> +				struct device_attribute *attr,
> +				const char *buf, size_t size)
> +{
> +	int ret, len, apb_bus;
> +	unsigned int base;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +	int nval;
> +
> +	nval = sscanf(buf, "%x %i %d", &base, &len, &apb_bus);
> +	if (nval <= 0 || nval > 3)
> +		return -EINVAL;
> +
> +	if (nval == 1) {
> +		len = 1;
> +		apb_bus = 0;
> +	} else if (nval == 2) {
> +		apb_bus = 0;
> +	} else {
> +		apb_bus = 1;
> +	}
> +
> +	ret = dcc_config_add(drvdata, base, len, apb_bus);
> +	if (ret)
> +		return ret;
> +
> +	return size;
> +
> +}
> +
> +static DEVICE_ATTR_RW(config);
> +
> +static void dcc_config_reset(struct dcc_drvdata *drvdata)
> +{
> +	struct dcc_config_entry *entry, *temp;
> +	int curr_list;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> +		list_for_each_entry_safe(entry, temp,
> +			&drvdata->cfg_head[curr_list], list) {
> +			list_del(&entry->list);
> +			devm_kfree(drvdata->dev, entry);
> +			drvdata->nr_config[curr_list]--;
> +		}
> +	}
> +	drvdata->ram_start = 0;
> +	drvdata->ram_cfg = 0;
> +	mutex_unlock(&drvdata->mutex);
> +}
> +
> +
> +static ssize_t config_reset_store(struct device *dev,
> +	struct device_attribute *attr,
> +	const char *buf, size_t size)
> +{
> +	unsigned long val;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (kstrtoul(buf, 16, &val))
> +		return -EINVAL;
> +
> +	if (val)
> +		dcc_config_reset(drvdata);
> +
> +	return size;
> +}
> +
> +static DEVICE_ATTR_WO(config_reset);
> +
> +static ssize_t ready_show(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	int ret;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (!drvdata->enable[drvdata->curr_list]) {
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> +			(unsigned int)FIELD_GET(BIT(1), dcc_readl(drvdata, DCC_STATUS)));
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static DEVICE_ATTR_RO(ready);
> +
> +static ssize_t interrupt_disable_show(struct device *dev,
> +						struct device_attribute *attr,
> +						char *buf)
> +{
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	return scnprintf(buf, PAGE_SIZE, "%u\n",
> +				(unsigned int)drvdata->interrupt_disable);
> +}
> +
> +static ssize_t interrupt_disable_store(struct device *dev,
> +	struct device_attribute *attr,
> +	const char *buf, size_t size)
> +{
> +	unsigned long val;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	if (kstrtoul(buf, 16, &val))
> +		return -EINVAL;
> +
> +	mutex_lock(&drvdata->mutex);
> +	drvdata->interrupt_disable = (val ? 1:0);

This doesn't seem like it actually does something, and it's not
documented in the sysfs interface.

> +	mutex_unlock(&drvdata->mutex);
> +	return size;
> +}
> +
> +static DEVICE_ATTR_RW(interrupt_disable);
> +
> +static int dcc_add_loop(struct dcc_drvdata *drvdata, unsigned long loop_cnt)
> +{
> +	struct dcc_config_entry *entry;
> +
> +	entry = devm_kzalloc(drvdata->dev, sizeof(*entry), GFP_KERNEL);
> +	if (!entry)
> +		return -ENOMEM;
> +
> +	entry->loop_cnt = min_t(u32, loop_cnt, MAX_LOOP_CNT);
> +	entry->index = drvdata->nr_config[drvdata->curr_list]++;
> +	entry->desc_type = DCC_LOOP_TYPE;
> +	INIT_LIST_HEAD(&entry->list);
> +	list_add_tail(&entry->list, &drvdata->cfg_head[drvdata->curr_list]);
> +
> +	return 0;
> +}
> +
> +static ssize_t loop_store(struct device *dev,
> +	struct device_attribute *attr,
> +	const char *buf, size_t size)
> +{
> +	int ret;
> +	unsigned long loop_cnt;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	if (kstrtoul(buf, 16, &loop_cnt)) {
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	ret = dcc_add_loop(drvdata, loop_cnt);
> +	if (ret)
> +		goto err;
> +
> +	mutex_unlock(&drvdata->mutex);
> +	return size;
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static DEVICE_ATTR_WO(loop);
> +
> +static int dcc_rd_mod_wr_add(struct dcc_drvdata *drvdata, unsigned int mask,
> +				unsigned int val)
> +{
> +	int ret = 0;
> +	struct dcc_config_entry *entry;
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(drvdata->dev, "Select link list to program using curr_list\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (list_empty(&drvdata->cfg_head[drvdata->curr_list])) {
> +		dev_err(drvdata->dev, "DCC: No read address programmed\n");
> +		ret = -EPERM;
> +		goto err;
> +	}
> +
> +	entry = devm_kzalloc(drvdata->dev, sizeof(*entry), GFP_KERNEL);
> +	if (!entry) {
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +
> +	entry->desc_type = DCC_READ_WRITE_TYPE;
> +	entry->mask = mask;
> +	entry->write_val = val;
> +	entry->index = drvdata->nr_config[drvdata->curr_list]++;
> +	INIT_LIST_HEAD(&entry->list);
> +	list_add_tail(&entry->list, &drvdata->cfg_head[drvdata->curr_list]);
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;
> +}
> +
> +static ssize_t rd_mod_wr_store(struct device *dev,
> +	struct device_attribute *attr,
> +	const char *buf, size_t size)
> +{
> +	int ret;
> +	int nval;
> +	unsigned int mask, val;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	nval = sscanf(buf, "%x %x", &mask, &val);
> +
> +	if (nval <= 1 || nval > 2)
> +		return -EINVAL;
> +
> +	ret = dcc_rd_mod_wr_add(drvdata, mask, val);
> +	if (ret)
> +		return ret;
> +
> +	return size;
> +
> +}
> +
> +static DEVICE_ATTR_WO(rd_mod_wr);
> +
> +static int dcc_add_write(struct dcc_drvdata *drvdata, unsigned int addr,
> +				unsigned int write_val, int apb_bus)
> +{
> +	struct dcc_config_entry *entry;
> +
> +	entry = devm_kzalloc(drvdata->dev, sizeof(*entry), GFP_KERNEL);
> +	if (!entry)
> +		return -ENOMEM;
> +
> +	entry->desc_type = DCC_WRITE_TYPE;
> +	entry->base = addr & GENMASK(31, 4);
> +	entry->offset = addr - entry->base;
> +	entry->write_val = write_val;
> +	entry->index = drvdata->nr_config[drvdata->curr_list]++;
> +	entry->len = 1;
> +	entry->apb_bus = apb_bus;
> +	INIT_LIST_HEAD(&entry->list);
> +	list_add_tail(&entry->list, &drvdata->cfg_head[drvdata->curr_list]);
> +
> +	return 0;
> +}
> +
> +static ssize_t config_write_store(struct device *dev,
> +						struct device_attribute *attr,
> +						const char *buf, size_t size)
> +{
> +	int ret;
> +	int nval;
> +	unsigned int addr, write_val;
> +	int apb_bus = 0;
> +	struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +	mutex_lock(&drvdata->mutex);
> +
> +	nval = sscanf(buf, "%x %x %d", &addr, &write_val, &apb_bus);
> +
> +	if (nval <= 1 || nval > 3) {
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (drvdata->curr_list >= drvdata->nr_link_list) {
> +		dev_err(dev, "Select link list to program using curr_list\n");
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +
> +	if (nval == 3 && apb_bus != 0)
> +		apb_bus = 1;
> +
> +	ret = dcc_add_write(drvdata, addr, write_val, apb_bus);
> +	if (ret)
> +		goto err;
> +
> +	mutex_unlock(&drvdata->mutex);
> +	return size;
> +err:
> +	mutex_unlock(&drvdata->mutex);
> +	return ret;

The two tails are very similar, you should be able to combine the two.

> +}
> +
> +static DEVICE_ATTR_WO(config_write);
> +
> +static const struct device_attribute *dcc_attrs[] = {
> +	&dev_attr_trigger,
> +	&dev_attr_enable,
> +	&dev_attr_config,
> +	&dev_attr_config_reset,
> +	&dev_attr_ready,
> +	&dev_attr_interrupt_disable,
> +	&dev_attr_loop,
> +	&dev_attr_rd_mod_wr,
> +	&dev_attr_curr_list,
> +	&dev_attr_config_write,
> +	NULL,
> +};
> +
> +static int dcc_create_files(struct device *dev,
> +					const struct device_attribute **attrs)
> +{
> +	int ret = 0, i;
> +
> +	for (i = 0; attrs[i] != NULL; i++) {
> +		ret = device_create_file(dev, attrs[i]);
> +		if (ret) {
> +			dev_err(dev, "DCC: Couldn't create sysfs attribute: %s\n",
> +				attrs[i]->attr.name);
> +			break;
> +		}
> +	}
> +	return ret;
> +}
> +
> +static int dcc_sram_open(struct inode *inode, struct file *file)
> +{
> +	struct dcc_drvdata *drvdata = container_of(inode->i_cdev,
> +		struct dcc_drvdata,
> +		sram_dev);
> +	file->private_data = drvdata;
> +
> +	return	0;
> +}
> +
> +static ssize_t dcc_sram_read(struct file *file, char __user *data,
> +						size_t len, loff_t *ppos)
> +{
> +	unsigned char *buf;
> +	struct dcc_drvdata *drvdata = file->private_data;
> +
> +	/* EOF check */
> +	if (drvdata->ram_size <= *ppos)
> +		return 0;
> +
> +	if ((*ppos + len) > drvdata->ram_size)
> +		len = (drvdata->ram_size - *ppos);
> +
> +	buf = kzalloc(len, GFP_KERNEL);
> +	if (!buf)
> +		return -ENOMEM;
> +
> +	memcpy_fromio(buf, drvdata->ram_base + *ppos, len);
> +
> +	if (copy_to_user(data, buf, len)) {
> +		dev_err(drvdata->dev, "DCC: Couldn't copy all data to user\n");
> +		kfree(buf);
> +		return -EFAULT;
> +	}
> +
> +	*ppos += len;
> +
> +	kfree(buf);
> +
> +	return len;
> +}
> +
> +static const struct file_operations dcc_sram_fops = {
> +	.owner		= THIS_MODULE,
> +	.open		= dcc_sram_open,
> +	.read		= dcc_sram_read,
> +	.llseek		= no_llseek,
> +};
> +
> +static int dcc_sram_dev_register(struct dcc_drvdata *drvdata)
> +{
> +	int ret;
> +	struct device *device;
> +	dev_t dev;
> +
> +	ret = alloc_chrdev_region(&dev, 0, 1, DCC_SRAM_NODE);
> +	if (ret)
> +		goto err_alloc;
> +
> +	cdev_init(&drvdata->sram_dev, &dcc_sram_fops);
> +
> +	drvdata->sram_dev.owner = THIS_MODULE;
> +	ret = cdev_add(&drvdata->sram_dev, dev, 1);
> +	if (ret)
> +		goto err_cdev_add;
> +
> +	drvdata->sram_class = class_create(THIS_MODULE, DCC_SRAM_NODE);
> +	if (IS_ERR(drvdata->sram_class)) {
> +		ret = PTR_ERR(drvdata->sram_class);
> +		goto err_class_create;
> +	}
> +
> +	device = device_create(drvdata->sram_class, NULL,
> +						drvdata->sram_dev.dev, drvdata,
> +						DCC_SRAM_NODE);

Use misc_register() instead of rolling your own chrdev_region, cdev and
associated device.

> +	if (IS_ERR(device)) {
> +		ret = PTR_ERR(device);
> +		goto err_dev_create;
> +	}
> +
> +	return 0;
> +err_dev_create:
> +	class_destroy(drvdata->sram_class);
> +err_class_create:
> +	cdev_del(&drvdata->sram_dev);
> +err_cdev_add:
> +	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
> +err_alloc:
> +	return ret;
> +}
> +
> +static void dcc_sram_dev_deregister(struct dcc_drvdata *drvdata)
> +{
> +	device_destroy(drvdata->sram_class, drvdata->sram_dev.dev);
> +	class_destroy(drvdata->sram_class);
> +	cdev_del(&drvdata->sram_dev);
> +	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
> +}
> +
> +static int dcc_sram_dev_init(struct dcc_drvdata *drvdata)
> +{
> +	int ret = 0;
> +
> +	ret = dcc_sram_dev_register(drvdata);

Why don't you simply call dcc_sram_dev_register() from probe?

> +	if (ret)
> +		dev_err(drvdata->dev, "DCC: sram node not registered.\n");
> +
> +	return ret;
> +}
> +
> +static void dcc_sram_dev_exit(struct dcc_drvdata *drvdata)
> +{
> +	dcc_sram_dev_deregister(drvdata);
> +}
> +
> +static int dcc_probe(struct platform_device *pdev)
> +{
> +	u32 val;
> +	int ret = 0, i, enable_size, nr_config_size, cfg_head_size;
> +	struct device *dev = &pdev->dev;
> +	struct dcc_drvdata *dcc;
> +	struct resource *res;
> +	const struct qcom_dcc_config *cfg;
> +
> +	dcc = devm_kzalloc(dev, sizeof(*dcc), GFP_KERNEL);
> +	if (!dcc)
> +		return -ENOMEM;
> +
> +	dcc->dev = &pdev->dev;
> +	platform_set_drvdata(pdev, dcc);
> +
> +	dcc->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(dcc->base))
> +		return PTR_ERR(dcc->base);
> +
> +	dcc->ram_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
> +	if (IS_ERR(dcc->ram_base))
> +		return PTR_ERR(dcc->ram_base);
> +
> +	dcc->ram_size = resource_size(res);
> +
> +	dcc->ram_base = devm_ioremap(dev, res->start, resource_size(res));
> +	if (!dcc->ram_base)
> +		return -ENOMEM;
> +
> +	cfg = of_device_get_match_data(&pdev->dev);
> +	dcc->ram_offset = cfg->dcc_ram_offset;

ram_offset is always divided by 4 when read, so how about treating it as
"number of elements offset", rather than number of bytes?

> +
> +	val = dcc_readl(dcc, DCC_HW_INFO);
> +
> +	if (FIELD_GET(BIT(DCC_VER_INFO_BIT), val)) {
> +		dcc->mem_map_ver = DCC_MEM_MAP_VER3;
> +		dcc->nr_link_list = dcc_readl(dcc, DCC_LL_NUM_INFO);
> +		if (dcc->nr_link_list == 0)
> +			return	-EINVAL;
> +	} else if ((val & DCC_VER_MASK2) == DCC_VER_MASK2) {
> +		dcc->mem_map_ver = DCC_MEM_MAP_VER2;
> +		dcc->nr_link_list = dcc_readl(dcc, DCC_LL_NUM_INFO);
> +		if (dcc->nr_link_list == 0)
> +			return	-EINVAL;
> +	} else {
> +		dcc->mem_map_ver = DCC_MEM_MAP_VER1;
> +		dcc->nr_link_list = DCC_MAX_LINK_LIST;
> +	}
> +
> +	if ((val & BIT(6)) == BIT(6))

#define BIT(6) please

> +		dcc->loopoff = DCC_FIX_LOOP_OFFSET;
> +	else
> +		dcc->loopoff = get_bitmask_order((dcc->ram_size +
> +				dcc->ram_offset) / 4 - 1);
> +
> +	mutex_init(&dcc->mutex);
> +	/* Allocate space for all entries at once */
> +	enable_size = dcc->nr_link_list * sizeof(bool);
> +	nr_config_size = dcc->nr_link_list * sizeof(size_t);
> +	cfg_head_size = dcc->nr_link_list * sizeof(struct list_head);
> +
> +	dcc->enable = devm_kzalloc(dev, enable_size + nr_config_size + cfg_head_size, GFP_KERNEL);
> +	if (!dcc->enable)
> +		return -ENOMEM;
> +
> +	dcc->nr_config  = (size_t *)(dcc->enable + dcc->nr_link_list);
> +	dcc->cfg_head = (struct list_head *)(dcc->nr_config + dcc->nr_link_list);

I find this overly complicated if it's true, as you wrote above, that
nr_link_list will be <= 4. Just make enable a bitmap, and nr_config and
statically sized arrays of length 4.

> +
> +	for (i = 0; i < dcc->nr_link_list; i++)
> +		INIT_LIST_HEAD(&dcc->cfg_head[i]);
> +
> +	dcc->curr_list = DCC_INVALID_LINK_LIST;

Why don't you set this to 0, that way it's impossible for dcc->curr_list
to be an invalid number so you can remove all the checks of it being
invalid throughout the driver.

> +	ret = dcc_sram_dev_init(dcc);
> +	if (ret)
> +		return ret;
> +
> +	return dcc_create_files(dev, dcc_attrs);

If this fails you will leak the resources create in dcc_sram_dev_init()

> +}
> +
> +static int dcc_remove(struct platform_device *pdev)
> +{
> +	struct dcc_drvdata *drvdata = platform_get_drvdata(pdev);

drvdata is named "dcc" in probe, that seems like a nicer name.

> +
> +	dcc_sram_dev_exit(drvdata);
> +
> +	dcc_config_reset(drvdata);
> +
> +	return 0;
> +}
> +
> +static const struct qcom_dcc_config sm8150_cfg = {
> +	.dcc_ram_offset	= 0x5000,

Please just inline these into dcc_match_table[]

Regards,
Bjorn

> +};
> +
> +static const struct qcom_dcc_config sc7280_cfg = {
> +	.dcc_ram_offset = 0x12000,
> +};
> +
> +static const struct qcom_dcc_config sc7180_cfg = {
> +	.dcc_ram_offset = 0x6000,
> +};
> +
> +static const struct qcom_dcc_config sdm845_cfg = {
> +	.dcc_ram_offset = 0x6000,
> +};
> +
> +static const struct of_device_id dcc_match_table[] = {
> +	{ .compatible = "qcom,sm8150-dcc", .data = &sm8150_cfg },
> +	{ .compatible = "qcom,sc7280-dcc", .data = &sc7280_cfg },
> +	{ .compatible = "qcom,sc7180-dcc", .data = &sc7180_cfg },
> +	{ .compatible = "qcom,sdm845-dcc", .data = &sdm845_cfg },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, dcc_match_table);
> +
> +static struct platform_driver dcc_driver = {
> +	.probe = dcc_probe,
> +	.remove	= dcc_remove,
> +	.driver	= {
> +		.name = "qcom-dcc",
> +		.of_match_table	= dcc_match_table,
> +	},
> +};
> +
> +module_platform_driver(dcc_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Qualcomm Technologies Inc. DCC driver");
> +
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Bjorn Andersson]

On Wed 05 Jan 23:57 PST 2022, Souradeep Chowdhury wrote:

> 
> On 12/18/2021 1:41 AM, Bjorn Andersson wrote:
> > On Tue 10 Aug 12:54 CDT 2021, Souradeep Chowdhury wrote:
> > 
> > > The DCC is a DMA Engine designed to capture and store data
> > > during system crash or software triggers.The DCC operates
> > Please include a space after '.'
> Ack
> > > based on user inputs via the sysfs interface.The user gives
> > > addresses as inputs and these addresses are stored in the
> > > form of linkedlists.In case of a system crash or a manual
> > I think the user configures the DCC hardware with "a sequence of
> > operations to be performed as DCC is triggered".
> > 
> > Afaict the sequence is stored just as a sequence of operations in SRAM,
> > there's no linked list involved - except in your intermediate
> > implementation.
> 
> The user just enters the addresses as input whereas the sequence of
> operations takes
> 
> place as per configuration code inside the driver. The end result is storage
> of these
> 
> addresses inside the DCC SRAM. The DCC hardware will capture the value at
> these
> 
> addresses on a crash or manual trigger by the user.
> 
> > > software trigger by the user through the sysfs interface,
> > > the dcc captures and stores the values at these addresses.
> > > This patch contains the driver which has all the methods
> > > pertaining to the sysfs interface, auxiliary functions to
> > > support all the four fundamental operations of dcc namely
> > > read, write, first read then write and loop.The probe method
> > "first read then write" is called "read/modify/write"
> Ack
> > > here instantiates all the resources necessary for dcc to
> > > operate mainly the dedicated dcc sram where it stores the
> > > values.The DCC driver can be used for debugging purposes
> > > without going for a reboot since it can perform manual
> > > triggers.
> > > 
> > > Also added the documentation for sysfs entries
> > > and explained the functionalities of each sysfs file that
> > > has been created for dcc.
> > > 
> > > The following is the justification of using sysfs interface
> > > over the other alternatives like ioctls
> > > 
> > > i) As can be seen from the sysfs attribute descriptions,
> > > most of it does basic hardware manipulations like dcc_enable,
> > > dcc_disable, config reset etc. As a result sysfs is preferred
> > > over ioctl as we just need to enter a 0 or 1.
> > > 
> > As I mentioned in our chat, using sysfs allows us to operate the
> > interface using the shell without additional tools.
> > 
> > But I don't think that it's easy to implement enable/disable/reset using
> > sysfs is a strong argument. The difficult part of this ABI is the
> > operations to manipulate the sequence of operations, so that's what you
> > need to have a solid plan for.
> 
> The sysfs interface is being used to get the addresses values entered by the
> user
> 
> and to also go for manual triggers. The sequence of operations are kept as a
> part of
> 
> fixed driver code which is called when the user enters the data.
> 

But does the hardware really just operate on "addresses values entered
by the user". Given the various types of operations: read, write,
read-modify-write and loop I get the feeling that the hardware
"executes" a series of actions.

I'm don't think the proposed sysfs interface best exposes this to the
user and I don't think that "it's easy to implement enable/disable
attributes in sysfs" is reason enough to go with that approach.

> > > ii) Existing similar debug hardwares are there for which drivers
> > > have been written using sysfs interface.One such example is the
> > > coresight-etm-trace driver.
> > Afaict the etm interface has operations to enable and disable, I don't
> > see anything that's similar to the interface for defining the sequence
> > of operations.
> 
> Here I have just drawn analogy with an existing sysfs interface. The 
> argument for
> 
> using sysfs instead of other interfaces can be as folllows
> 
> 1)
> 
> Debugfs interface is used by drivers to expose debugging information additional to
> the function they do. But the sole usage of this driver depends on the configuration
> exported through the attributes and therefore it is an ABI as suggested by Mani.
> 
> 2)
> 
> Debugfs is disabled in production so this will not give the user facility to use DCC.
> 
> 3)
> 
> As you mentioned sysfs can be used with the shell without any additional tools.
> 
> 4)
> 
> Alternatives like NETLINK has also been suggested although in this case by using
> NETLINK we won't be able to exploit most it's features like duplex connection,
> asychrony and bulk data transfers. We are not showing any stats here to the user
> as such and also sysfs is considered to be a bit more reliable.
> 

I'm not sure why netlink would preferred for this; to me sysfs is much
preferred as it allows us to use DCC from scripts etc without having to
bundle additional binaries. If we can't express the configuration
appropriately in a sysfs (debugfs would be the same) interface, I think
an ioctl interface on /dev/dcc would be a reasonable alternative.

> Please let me your thoughts regarding this.
> 
> > > A closer analog can also be the watchdog
> > > subsystems though it is ioctls based.
> > > 
> > I don't think this adds value to the argument for using a sysfs based
> > interface.
> Ack
> > 
> > > Signed-off-by: Souradeep Chowdhury<schowdhu@codeaurora.org>
> > > ---
> > >   Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
> > >   drivers/soc/qcom/Kconfig                   |    8 +
> > >   drivers/soc/qcom/Makefile                  |    1 +
> > >   drivers/soc/qcom/dcc.c                     | 1549 ++++++++++++++++++++++++++++
> > >   4 files changed, 1672 insertions(+)
> > >   create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
> > >   create mode 100644 drivers/soc/qcom/dcc.c
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc
[..]
> > > +What:           /sys/bus/platform/devices/.../rd_mod_wr
> > > +Date:           March 2021
> > > +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
> > > +Description:
> > > +		This file is used to read the value of the register
> > > +		and then write the value given as an argument to the
> > > +		register address in config.
> > It's not clear from this description how to use this operation. E.g. is
> > it appended to the same list of operations? When will this operation
> > happen?
> > 
> > Looking at the implementation I believe that "config", "config_write",
> > "loop" and "rd_mod_wr" all appends operations to the same list.
> > 
> > I think it would be much better to configure this with a single file
> > that can either be written to '>' or appended to '>>' and you would feed
> > it a sequence of the operations to be performed.
> > 
> > That said, I'm afraid that might no longer be a sysfs attribute.
> > 
> > Something like:
> >    # echo 'r 0x80000010 0x10' > config
> >    # echo 'w 0x80000000 0xff' >> config
> >    # echo 'rmw 0x80000000 0xf 0xa' >> config
> >    # echo 'l 0x80000010 10' >> config
> > 
> > and:
> >    # cat config
> >    r 0x80000010 0x10
> >    w 0x80000000 0xff
> >    rmw 0x80000000 0xf 0xa
> >    l 0x80000010 10
> > 
> > (Or read/write/modify/loop as keywords...)
> > 
> > 
> > reset could be done by just: echo '' > config
> > 
> > This would make it quite similar to several of the files in the tracing
> > framework.
> 
> Currently this is being implemented as follows
> 
> Step 1
> 
> echo 0x80000000 > /sys/bus/platform/devices/../config
> 
> Step 2
> 
> echo 0xF 0xA > /sys/bus/platform/devices/../rd_mod_wr
> 
> So the particular address is tagged as rd_mod_wr type and therefore
> 
> while the value at the address 0x80000000 is captured, 0xA is also
> 
> written to it's last 4 bits. Will be updating this in the documentation
> 
> along with details for loop and config_write as well.
> 

But can you help me confirm what is actually written in SRAM when you
run these two steps?

> > 
> > > +		The address argument should
> > > +		be given of the form <mask> <value>.For debugging
> > > +		purposes sometimes we need to first read from a register
> > > +		and then set some values to the register.
> > > +		Example:
> > > +		echo 0x80000000 > /sys/bus/platform/devices/.../config
> > > +		(Set the address in config file)
> > > +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
> > > +		(Provide the mask and the value to write)
> > > +
> > > +What:           /sys/bus/platform/devices/.../ready
> > > +Date:           March 2021
> > > +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
> > > +Description:
> > > +		This file is used to check the status of the dcc
> > > +		hardware if it's ready to take the inputs.
> > When will this read "false"?
> 
> This will give false if the DCC hardware is not in an operational state.
> 
> Will update accordingly.
> 
> > 
> > > +		Example:
> > > +		cat /sys/bus/platform/devices/.../ready
> > > +
> > > +What:		/sys/bus/platform/devices/.../curr_list
> > > +Date:		February 2021
> > > +Contact:	Souradeep Chowdhury<schowdhu@codeaurora.org>
> > > +Description:
> > > +		This attribute is used to enter the linklist to be
> > I think it would be more appropriate to use the verb "select" here and
> > afaict it's a "list" as the "linked" part only relates to your
> > implementation).
> > 
> > But that said, I don't like this ABI. I think it would be cleaner if you
> > had specific attributes for each of the lists. That way it would be
> > clear that you have N lists and they can be configured and enabled
> > independently, and there's no possible race conditions.
> 
> So we do have attributes for independent lists in this case. The user is
> given the option
> 
> to configure multiple lists at one go. For example I can do
> 
> echo 1 > curr_list
> 
> echo 0x18000010 1 > config
> echo 0x18000024 1 > config
> 
> Then followed by
> 
> echo 2 > curr_list
> 
> echo 0x18010038 6 > config
> echo 0x18020010 1 > config
> 
> We will get the output in terms of two separate list of registers values.
> 

I understand that this will define two lists of operations and that we
will get 2 and 7 registers dumped, respectively. Perhaps unlikely, but
what happens if you try to do these two operations concurrently?


What I'm suggesting here is that if you have N contexts, you should have
N interfaces to modify each one independently - simply because that's
generally a very good thing.

> > 
> > > +		used while appending addresses.The range of values
> > > +		for this can be from 0 to 3.This feature is given in
> > > +		order to use certain linkedlist for certain debugging
> > > +		purposes.
> > > +		Example:
> > > +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
> > > +
[..]
> > > diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
[..]
> > > +static int dcc_valid_list(struct dcc_drvdata *drvdata, int curr_list)
> > > +{
> > > +	u32 lock_reg;
> > > +
> > > +	if (list_empty(&drvdata->cfg_head[curr_list]))
> > > +		return -EINVAL;
> > > +
> > > +	if (drvdata->enable[curr_list]) {
> > > +		dev_err(drvdata->dev, "List %d is already enabled\n",
> > > +				curr_list);
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(curr_list));
> > Under what circumstances would this differ from
> > drvdata->enable[curr_list}?
> 
> So locking the list is done on the register as soon as the user enters the
> curr_list entry whereas
> 
> the list is marked as enabled only on successfully programming the SRAM
> contents. So a list can
> 
> be locked and not marked enabled in certain cases. The first is used so that
> the user doesn't
> 
> mistakenly enter the same curr_list twice whereas the later is used to mark
> that the list has been
> 
> successfully configured.
> 

So this will mark the list as "actively in use, but disabled"? Why is
this kept in the hardware? When is this not the same as the list of
operations for that list being non-empty?

> > 
> > > +	if (lock_reg & 0x1) {
> > > +		dev_err(drvdata->dev, "List %d is already locked\n",
> > > +				curr_list);
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	dev_err(drvdata->dev, "DCC list passed %d\n", curr_list);
> > This is noise, please drop it.
> Ack
> > 
> > > +	return 0;
> > > +}
> > > +
> > > +static bool is_dcc_enabled(struct dcc_drvdata *drvdata)
> > > +{
> > > +	bool dcc_enable = false;
> > > +	int list;
> > > +
> > > +	for (list = 0; list < DCC_MAX_LINK_LIST; list++) {
> > > +		if (drvdata->enable[list]) {
> > 			return true;
> > 
> > > +			dcc_enable = true;
> > > +			break;
> > > +		}
> > > +	}
> > > +
> > 	return false;
> > 
> > > +	return dcc_enable;
> > > +}
> > > +
> > > +static int dcc_enable(struct dcc_drvdata *drvdata)
> > > +{
> > > +	int ret = 0;
> > > +	int list;
> > > +	u32 ram_cfg_base;
> > > +
> > > +	mutex_lock(&drvdata->mutex);
> > > +
> > > +	if (!is_dcc_enabled(drvdata)) {
> > > +		memset_io(drvdata->ram_base,
> > > +			0xDE, drvdata->ram_size);
> > No need to wrap this line, and please use lowercase hex digits.
> Ack
> > 
> > > +	}
> > > +
> > > +	for (list = 0; list < drvdata->nr_link_list; list++) {
> > > +
> > Please drop the empty line.
> Ack
> > 
> > > +		if (dcc_valid_list(drvdata, list))
> > > +			continue;
> > > +
> > > +		/* 1. Take ownership of the list */
> > > +		dcc_writel(drvdata, BIT(0), DCC_LL_LOCK(list));
> > Can we have a define for BIT(0)? Is it really about ownership or just
> > that we "enable" it?
> > 
> > If ownership, who's the other contenders for the ownership?
> 
> This is done to mark that the user has already entered the curr_list and
> therefore
> 
> cannot enter it again.
> 

What does "entered" mean here? Do you mean that the list of operations
that the driver kept track of has been flushed out to SRAM and we're not
not allowed to modify it?

What does this actually mean? Why is this done in the hardware and not
simply with a bool in the driver?

> > 
> > > +
> > > +		/* 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;
> > > +
> > > +		/* 5. Configure trigger */
> > > +		dcc_writel(drvdata, BIT(9), DCC_LL_CFG(list));
> > > +	}
> > > +
> > > +err:
> > > +	mutex_unlock(&drvdata->mutex);
> > > +	return ret;
> > > +}
> > > +
> > > +static void dcc_disable(struct dcc_drvdata *drvdata)
> > > +{
> > > +	int curr_list;
> > > +
> > > +	mutex_lock(&drvdata->mutex);
> > > +
> > > +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
> > > +		if (!drvdata->enable[curr_list])
> > > +			continue;
> > > +		dcc_writel(drvdata, 0, DCC_LL_CFG(curr_list));
> > > +		dcc_writel(drvdata, 0, DCC_LL_BASE(curr_list));
> > > +		dcc_writel(drvdata, 0, DCC_FD_BASE(curr_list));
> > > +		dcc_writel(drvdata, 0, DCC_LL_LOCK(curr_list));
> > > +		drvdata->enable[curr_list] = false;
> > > +	}
> > > +	memset_io(drvdata->ram_base, 0, drvdata->ram_size);
> > Is there any reason why DCC is filled with 0xde during initialization
> > but 0 when disabled?
> 
> Yes this poison value is required to distinguish between bus hang on
> register accesses
> 
> and a zero value for the registers. In case of the former dcc returns zero
> value on registers
> 
> which causes ambiguity.
> 

That explains why you poison ram_base with 0xde during dcc_enable(). But
why do you overwrite it with 0s in dcc_disable()?

You should be able to either just leave it as it will be poisoned again
next time dcc_enable() is called, or if you want to ensure things are
cleared you should be able to poison it with the same poison - to
distinguish it from a bunch of read 0s?

Regards,
Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Souradeep Chowdhury]

On 1/7/2022 5:31 AM, Bjorn Andersson wrote:
> On Wed 05 Jan 23:57 PST 2022, Souradeep Chowdhury wrote:
>
>> On 12/18/2021 1:41 AM, Bjorn Andersson wrote:
>>> On Tue 10 Aug 12:54 CDT 2021, Souradeep Chowdhury wrote:
>>>
>>>> The DCC is a DMA Engine designed to capture and store data
>>>> during system crash or software triggers.The DCC operates
>>> Please include a space after '.'
>> Ack
>>>> based on user inputs via the sysfs interface.The user gives
>>>> addresses as inputs and these addresses are stored in the
>>>> form of linkedlists.In case of a system crash or a manual
>>> I think the user configures the DCC hardware with "a sequence of
>>> operations to be performed as DCC is triggered".
>>>
>>> Afaict the sequence is stored just as a sequence of operations in SRAM,
>>> there's no linked list involved - except in your intermediate
>>> implementation.
>> The user just enters the addresses as input whereas the sequence of
>> operations takes
>>
>> place as per configuration code inside the driver. The end result is storage
>> of these
>>
>> addresses inside the DCC SRAM. The DCC hardware will capture the value at
>> these
>>
>> addresses on a crash or manual trigger by the user.
>>
>>>> software trigger by the user through the sysfs interface,
>>>> the dcc captures and stores the values at these addresses.
>>>> This patch contains the driver which has all the methods
>>>> pertaining to the sysfs interface, auxiliary functions to
>>>> support all the four fundamental operations of dcc namely
>>>> read, write, first read then write and loop.The probe method
>>> "first read then write" is called "read/modify/write"
>> Ack
>>>> here instantiates all the resources necessary for dcc to
>>>> operate mainly the dedicated dcc sram where it stores the
>>>> values.The DCC driver can be used for debugging purposes
>>>> without going for a reboot since it can perform manual
>>>> triggers.
>>>>
>>>> Also added the documentation for sysfs entries
>>>> and explained the functionalities of each sysfs file that
>>>> has been created for dcc.
>>>>
>>>> The following is the justification of using sysfs interface
>>>> over the other alternatives like ioctls
>>>>
>>>> i) As can be seen from the sysfs attribute descriptions,
>>>> most of it does basic hardware manipulations like dcc_enable,
>>>> dcc_disable, config reset etc. As a result sysfs is preferred
>>>> over ioctl as we just need to enter a 0 or 1.
>>>>
>>> As I mentioned in our chat, using sysfs allows us to operate the
>>> interface using the shell without additional tools.
>>>
>>> But I don't think that it's easy to implement enable/disable/reset using
>>> sysfs is a strong argument. The difficult part of this ABI is the
>>> operations to manipulate the sequence of operations, so that's what you
>>> need to have a solid plan for.
>> The sysfs interface is being used to get the addresses values entered by the
>> user
>>
>> and to also go for manual triggers. The sequence of operations are kept as a
>> part of
>>
>> fixed driver code which is called when the user enters the data.
>>
> But does the hardware really just operate on "addresses values entered
> by the user". Given the various types of operations: read, write,
> read-modify-write and loop I get the feeling that the hardware
> "executes" a series of actions.
>
> I'm don't think the proposed sysfs interface best exposes this to the
> user and I don't think that "it's easy to implement enable/disable
> attributes in sysfs" is reason enough to go with that approach.

So the sysfs interface here has been introduced keeping in mind how the 
DCC_SRAM needs to be

programmed for the dcc hardware to work. We are maintaining a list here 
based on the address

entry. The 4 cases for the type of addresses are as follows-:

i) READ ADDRESSES

user enters something like "echo <addr> <len> > config"

DCC driver stores the <addr> along with the length information in the 
DCC_SRAM.

ii) WRITE ADDRESSES

User enters something like "echo <addr> <write_val> 1  > config_write"

DCC stores the <addr> first in sram followed by <write_val>.

For the above 2 type of addresses there won't be much difference if we 
use IOCTL.

However, for the next 2 type of addresses

iii) LOOP ADDRESSES

user has to enter something like below

echo 9 > loop
echo 0x01741010 1 > config
echo 0x01741014 1 > config
echo 1 > loop

The DCC SRAM will be programmed precisely like the above entries where 
the loop count will be stored first

followed by loop addresses and then again a "echo 1 > loop " marks the 
end of loop addresses.

in DCC_SRAM.

iv) READ_WRITE ADDRESSES

User has to enter something like below

echo <addr> > /sys/bus/platform/devices/../config

echo <mask> <val> > /sys/bus/platform/devices/../rd_mod_wr

Here first the  <addr> is stored in DCC_SRAM followed by <mask> and then 
the <val>.

The above representation to the user space is consistent with the dcc 
hardware in terms of

the way the sequence of values are programmed in the DCC SRAM . Moving 
to IOCTL will

only change the way the READ_WRITE address is represented although user 
will have to enter

multiple parameters at once, let me know if we still need to go for the 
same.


>>>> ii) Existing similar debug hardwares are there for which drivers
>>>> have been written using sysfs interface.One such example is the
>>>> coresight-etm-trace driver.
>>> Afaict the etm interface has operations to enable and disable, I don't
>>> see anything that's similar to the interface for defining the sequence
>>> of operations.
>> Here I have just drawn analogy with an existing sysfs interface. The
>> argument for
>>
>> using sysfs instead of other interfaces can be as folllows
>>
>> 1)
>>
>> Debugfs interface is used by drivers to expose debugging information additional to
>> the function they do. But the sole usage of this driver depends on the configuration
>> exported through the attributes and therefore it is an ABI as suggested by Mani.
>>
>> 2)
>>
>> Debugfs is disabled in production so this will not give the user facility to use DCC.
>>
>> 3)
>>
>> As you mentioned sysfs can be used with the shell without any additional tools.
>>
>> 4)
>>
>> Alternatives like NETLINK has also been suggested although in this case by using
>> NETLINK we won't be able to exploit most it's features like duplex connection,
>> asychrony and bulk data transfers. We are not showing any stats here to the user
>> as such and also sysfs is considered to be a bit more reliable.
>>
> I'm not sure why netlink would preferred for this; to me sysfs is much
> preferred as it allows us to use DCC from scripts etc without having to
> bundle additional binaries. If we can't express the configuration
> appropriately in a sysfs (debugfs would be the same) interface, I think
> an ioctl interface on /dev/dcc would be a reasonable alternative.
>
>> Please let me your thoughts regarding this.
>>
>>>> A closer analog can also be the watchdog
>>>> subsystems though it is ioctls based.
>>>>
>>> I don't think this adds value to the argument for using a sysfs based
>>> interface.
>> Ack
>>>> Signed-off-by: Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>> ---
>>>>    Documentation/ABI/testing/sysfs-driver-dcc |  114 ++
>>>>    drivers/soc/qcom/Kconfig                   |    8 +
>>>>    drivers/soc/qcom/Makefile                  |    1 +
>>>>    drivers/soc/qcom/dcc.c                     | 1549 ++++++++++++++++++++++++++++
>>>>    4 files changed, 1672 insertions(+)
>>>>    create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
>>>>    create mode 100644 drivers/soc/qcom/dcc.c
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc
> [..]
>>>> +What:           /sys/bus/platform/devices/.../rd_mod_wr
>>>> +Date:           March 2021
>>>> +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>> +Description:
>>>> +		This file is used to read the value of the register
>>>> +		and then write the value given as an argument to the
>>>> +		register address in config.
>>> It's not clear from this description how to use this operation. E.g. is
>>> it appended to the same list of operations? When will this operation
>>> happen?
>>>
>>> Looking at the implementation I believe that "config", "config_write",
>>> "loop" and "rd_mod_wr" all appends operations to the same list.
>>>
>>> I think it would be much better to configure this with a single file
>>> that can either be written to '>' or appended to '>>' and you would feed
>>> it a sequence of the operations to be performed.
>>>
>>> That said, I'm afraid that might no longer be a sysfs attribute.
>>>
>>> Something like:
>>>     # echo 'r 0x80000010 0x10' > config
>>>     # echo 'w 0x80000000 0xff' >> config
>>>     # echo 'rmw 0x80000000 0xf 0xa' >> config
>>>     # echo 'l 0x80000010 10' >> config
>>>
>>> and:
>>>     # cat config
>>>     r 0x80000010 0x10
>>>     w 0x80000000 0xff
>>>     rmw 0x80000000 0xf 0xa
>>>     l 0x80000010 10
>>>
>>> (Or read/write/modify/loop as keywords...)
>>>
>>>
>>> reset could be done by just: echo '' > config
>>>
>>> This would make it quite similar to several of the files in the tracing
>>> framework.
>> Currently this is being implemented as follows
>>
>> Step 1
>>
>> echo 0x80000000 > /sys/bus/platform/devices/../config
>>
>> Step 2
>>
>> echo 0xF 0xA > /sys/bus/platform/devices/../rd_mod_wr
>>
>> So the particular address is tagged as rd_mod_wr type and therefore
>>
>> while the value at the address 0x80000000 is captured, 0xA is also
>>
>> written to it's last 4 bits. Will be updating this in the documentation
>>
>> along with details for loop and config_write as well.
>>
> But can you help me confirm what is actually written in SRAM when you
> run these two steps?
Explained as above.
>
>>>> +		The address argument should
>>>> +		be given of the form <mask> <value>.For debugging
>>>> +		purposes sometimes we need to first read from a register
>>>> +		and then set some values to the register.
>>>> +		Example:
>>>> +		echo 0x80000000 > /sys/bus/platform/devices/.../config
>>>> +		(Set the address in config file)
>>>> +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
>>>> +		(Provide the mask and the value to write)
>>>> +
>>>> +What:           /sys/bus/platform/devices/.../ready
>>>> +Date:           March 2021
>>>> +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>> +Description:
>>>> +		This file is used to check the status of the dcc
>>>> +		hardware if it's ready to take the inputs.
>>> When will this read "false"?
>> This will give false if the DCC hardware is not in an operational state.
>>
>> Will update accordingly.
>>
>>>> +		Example:
>>>> +		cat /sys/bus/platform/devices/.../ready
>>>> +
>>>> +What:		/sys/bus/platform/devices/.../curr_list
>>>> +Date:		February 2021
>>>> +Contact:	Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>> +Description:
>>>> +		This attribute is used to enter the linklist to be
>>> I think it would be more appropriate to use the verb "select" here and
>>> afaict it's a "list" as the "linked" part only relates to your
>>> implementation).
>>>
>>> But that said, I don't like this ABI. I think it would be cleaner if you
>>> had specific attributes for each of the lists. That way it would be
>>> clear that you have N lists and they can be configured and enabled
>>> independently, and there's no possible race conditions.
>> So we do have attributes for independent lists in this case. The user is
>> given the option
>>
>> to configure multiple lists at one go. For example I can do
>>
>> echo 1 > curr_list
>>
>> echo 0x18000010 1 > config
>> echo 0x18000024 1 > config
>>
>> Then followed by
>>
>> echo 2 > curr_list
>>
>> echo 0x18010038 6 > config
>> echo 0x18020010 1 > config
>>
>> We will get the output in terms of two separate list of registers values.
>>
> I understand that this will define two lists of operations and that we
> will get 2 and 7 registers dumped, respectively. Perhaps unlikely, but
> what happens if you try to do these two operations concurrently?
>
>
> What I'm suggesting here is that if you have N contexts, you should have
> N interfaces to modify each one independently - simply because that's
> generally a very good thing.

Not sure if there will ever be a concurrency issue in this case. This is 
just about programming the DCC SRAM

from the user entries sequentially. The curr_list number is nothing but 
some register writes done in the dcc

so that the dcc_hardware knows the beginning and end of a particular 
list and can dump the captured data

according. Even if an user chooses multiple curr_list entries, it will 
be programmed sequentially in DCC_SRAM.

>
>>>> +		used while appending addresses.The range of values
>>>> +		for this can be from 0 to 3.This feature is given in
>>>> +		order to use certain linkedlist for certain debugging
>>>> +		purposes.
>>>> +		Example:
>>>> +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
>>>> +
> [..]
>>>> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> [..]
>>>> +static int dcc_valid_list(struct dcc_drvdata *drvdata, int curr_list)
>>>> +{
>>>> +	u32 lock_reg;
>>>> +
>>>> +	if (list_empty(&drvdata->cfg_head[curr_list]))
>>>> +		return -EINVAL;
>>>> +
>>>> +	if (drvdata->enable[curr_list]) {
>>>> +		dev_err(drvdata->dev, "List %d is already enabled\n",
>>>> +				curr_list);
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(curr_list));
>>> Under what circumstances would this differ from
>>> drvdata->enable[curr_list}?
>> So locking the list is done on the register as soon as the user enters the
>> curr_list entry whereas
>>
>> the list is marked as enabled only on successfully programming the SRAM
>> contents. So a list can
>>
>> be locked and not marked enabled in certain cases. The first is used so that
>> the user doesn't
>>
>> mistakenly enter the same curr_list twice whereas the later is used to mark
>> that the list has been
>>
>> successfully configured.
>>
> So this will mark the list as "actively in use, but disabled"? Why is
> this kept in the hardware? When is this not the same as the list of
> operations for that list being non-empty?

So this is in accordance with the dcc hardware configuration 
requirement. We have to lock the list first and

after that proceed with the subsequent writes . As per the driver code below

                /* 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));

In case of any errors we again unlock the list before exiting.

>
>>>> +	if (lock_reg & 0x1) {
>>>> +		dev_err(drvdata->dev, "List %d is already locked\n",
>>>> +				curr_list);
>>>> +		return -EINVAL;
>>>> +	}
>>>> +
>>>> +	dev_err(drvdata->dev, "DCC list passed %d\n", curr_list);
>>> This is noise, please drop it.
>> Ack
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static bool is_dcc_enabled(struct dcc_drvdata *drvdata)
>>>> +{
>>>> +	bool dcc_enable = false;
>>>> +	int list;
>>>> +
>>>> +	for (list = 0; list < DCC_MAX_LINK_LIST; list++) {
>>>> +		if (drvdata->enable[list]) {
>>> 			return true;
>>>
>>>> +			dcc_enable = true;
>>>> +			break;
>>>> +		}
>>>> +	}
>>>> +
>>> 	return false;
>>>
>>>> +	return dcc_enable;
>>>> +}
>>>> +
>>>> +static int dcc_enable(struct dcc_drvdata *drvdata)
>>>> +{
>>>> +	int ret = 0;
>>>> +	int list;
>>>> +	u32 ram_cfg_base;
>>>> +
>>>> +	mutex_lock(&drvdata->mutex);
>>>> +
>>>> +	if (!is_dcc_enabled(drvdata)) {
>>>> +		memset_io(drvdata->ram_base,
>>>> +			0xDE, drvdata->ram_size);
>>> No need to wrap this line, and please use lowercase hex digits.
>> Ack
>>>> +	}
>>>> +
>>>> +	for (list = 0; list < drvdata->nr_link_list; list++) {
>>>> +
>>> Please drop the empty line.
>> Ack
>>>> +		if (dcc_valid_list(drvdata, list))
>>>> +			continue;
>>>> +
>>>> +		/* 1. Take ownership of the list */
>>>> +		dcc_writel(drvdata, BIT(0), DCC_LL_LOCK(list));
>>> Can we have a define for BIT(0)? Is it really about ownership or just
>>> that we "enable" it?
>>>
>>> If ownership, who's the other contenders for the ownership?
>> This is done to mark that the user has already entered the curr_list and
>> therefore
>>
>> cannot enter it again.
>>
> What does "entered" mean here? Do you mean that the list of operations
> that the driver kept track of has been flushed out to SRAM and we're not
> not allowed to modify it?
>
> What does this actually mean? Why is this done in the hardware and not
> simply with a bool in the driver?
That is correct. As explained above this is as per dcc hardware 
configuration requirement.
>
>>>> +
>>>> +		/* 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;
>>>> +
>>>> +		/* 5. Configure trigger */
>>>> +		dcc_writel(drvdata, BIT(9), DCC_LL_CFG(list));
>>>> +	}
>>>> +
>>>> +err:
>>>> +	mutex_unlock(&drvdata->mutex);
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +static void dcc_disable(struct dcc_drvdata *drvdata)
>>>> +{
>>>> +	int curr_list;
>>>> +
>>>> +	mutex_lock(&drvdata->mutex);
>>>> +
>>>> +	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
>>>> +		if (!drvdata->enable[curr_list])
>>>> +			continue;
>>>> +		dcc_writel(drvdata, 0, DCC_LL_CFG(curr_list));
>>>> +		dcc_writel(drvdata, 0, DCC_LL_BASE(curr_list));
>>>> +		dcc_writel(drvdata, 0, DCC_FD_BASE(curr_list));
>>>> +		dcc_writel(drvdata, 0, DCC_LL_LOCK(curr_list));
>>>> +		drvdata->enable[curr_list] = false;
>>>> +	}
>>>> +	memset_io(drvdata->ram_base, 0, drvdata->ram_size);
>>> Is there any reason why DCC is filled with 0xde during initialization
>>> but 0 when disabled?
>> Yes this poison value is required to distinguish between bus hang on
>> register accesses
>>
>> and a zero value for the registers. In case of the former dcc returns zero
>> value on registers
>>
>> which causes ambiguity.
>>
> That explains why you poison ram_base with 0xde during dcc_enable(). But
> why do you overwrite it with 0s in dcc_disable()?
>
> You should be able to either just leave it as it will be poisoned again
> next time dcc_enable() is called, or if you want to ensure things are
> cleared you should be able to poison it with the same poison - to
> distinguish it from a bunch of read 0s?
Ack
>
> Regards,
> Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Bjorn Andersson]

On Fri 07 Jan 07:27 PST 2022, Souradeep Chowdhury wrote:

> 
> On 1/7/2022 5:31 AM, Bjorn Andersson wrote:
> > On Wed 05 Jan 23:57 PST 2022, Souradeep Chowdhury wrote:
> > 
> > > On 12/18/2021 1:41 AM, Bjorn Andersson wrote:
> > > > On Tue 10 Aug 12:54 CDT 2021, Souradeep Chowdhury wrote:
> > > > 
> > > > > The DCC is a DMA Engine designed to capture and store data
> > > > > during system crash or software triggers.The DCC operates
> > > > Please include a space after '.'
> > > Ack
> > > > > based on user inputs via the sysfs interface.The user gives
> > > > > addresses as inputs and these addresses are stored in the
> > > > > form of linkedlists.In case of a system crash or a manual
> > > > I think the user configures the DCC hardware with "a sequence of
> > > > operations to be performed as DCC is triggered".
> > > > 
> > > > Afaict the sequence is stored just as a sequence of operations in SRAM,
> > > > there's no linked list involved - except in your intermediate
> > > > implementation.
> > > The user just enters the addresses as input whereas the sequence of
> > > operations takes
> > > 
> > > place as per configuration code inside the driver. The end result is storage
> > > of these
> > > 
> > > addresses inside the DCC SRAM. The DCC hardware will capture the value at
> > > these
> > > 
> > > addresses on a crash or manual trigger by the user.
> > > 
> > > > > software trigger by the user through the sysfs interface,
> > > > > the dcc captures and stores the values at these addresses.
> > > > > This patch contains the driver which has all the methods
> > > > > pertaining to the sysfs interface, auxiliary functions to
> > > > > support all the four fundamental operations of dcc namely
> > > > > read, write, first read then write and loop.The probe method
> > > > "first read then write" is called "read/modify/write"
> > > Ack
> > > > > here instantiates all the resources necessary for dcc to
> > > > > operate mainly the dedicated dcc sram where it stores the
> > > > > values.The DCC driver can be used for debugging purposes
> > > > > without going for a reboot since it can perform manual
> > > > > triggers.
> > > > > 
> > > > > Also added the documentation for sysfs entries
> > > > > and explained the functionalities of each sysfs file that
> > > > > has been created for dcc.
> > > > > 
> > > > > The following is the justification of using sysfs interface
> > > > > over the other alternatives like ioctls
> > > > > 
> > > > > i) As can be seen from the sysfs attribute descriptions,
> > > > > most of it does basic hardware manipulations like dcc_enable,
> > > > > dcc_disable, config reset etc. As a result sysfs is preferred
> > > > > over ioctl as we just need to enter a 0 or 1.
> > > > > 
> > > > As I mentioned in our chat, using sysfs allows us to operate the
> > > > interface using the shell without additional tools.
> > > > 
> > > > But I don't think that it's easy to implement enable/disable/reset using
> > > > sysfs is a strong argument. The difficult part of this ABI is the
> > > > operations to manipulate the sequence of operations, so that's what you
> > > > need to have a solid plan for.
> > > The sysfs interface is being used to get the addresses values entered by the
> > > user
> > > 
> > > and to also go for manual triggers. The sequence of operations are kept as a
> > > part of
> > > 
> > > fixed driver code which is called when the user enters the data.
> > > 
> > But does the hardware really just operate on "addresses values entered
> > by the user". Given the various types of operations: read, write,
> > read-modify-write and loop I get the feeling that the hardware
> > "executes" a series of actions.
> > 
> > I'm don't think the proposed sysfs interface best exposes this to the
> > user and I don't think that "it's easy to implement enable/disable
> > attributes in sysfs" is reason enough to go with that approach.
> 
> So the sysfs interface here has been introduced keeping in mind how the
> DCC_SRAM needs to be
> 
> programmed for the dcc hardware to work. We are maintaining a list here
> based on the address
> 
> entry. The 4 cases for the type of addresses are as follows-:
> 
> i) READ ADDRESSES
> 
> user enters something like "echo <addr> <len> > config"
> 
> DCC driver stores the <addr> along with the length information in the
> DCC_SRAM.
> 
> ii) WRITE ADDRESSES
> 
> User enters something like "echo <addr> <write_val> 1  > config_write"
> 
> DCC stores the <addr> first in sram followed by <write_val>.
> 
> For the above 2 type of addresses there won't be much difference if we use
> IOCTL.
> 
> However, for the next 2 type of addresses
> 
> iii) LOOP ADDRESSES
> 
> user has to enter something like below
> 
> echo 9 > loop
> echo 0x01741010 1 > config
> echo 0x01741014 1 > config
> echo 1 > loop
> 
> The DCC SRAM will be programmed precisely like the above entries where the
> loop count will be stored first
> 
> followed by loop addresses and then again a "echo 1 > loop " marks the end
> of loop addresses.
> 
> in DCC_SRAM.
> 
> iv) READ_WRITE ADDRESSES
> 
> User has to enter something like below
> 
> echo <addr> > /sys/bus/platform/devices/../config
> 
> echo <mask> <val> > /sys/bus/platform/devices/../rd_mod_wr
> 
> Here first the  <addr> is stored in DCC_SRAM followed by <mask> and then the
> <val>.
> 
> The above representation to the user space is consistent with the dcc
> hardware in terms of
> 
> the way the sequence of values are programmed in the DCC SRAM . Moving to
> IOCTL will
> 
> only change the way the READ_WRITE address is represented although user will
> have to enter
> 
> multiple parameters at once, let me know if we still need to go for the
> same.
> 

So if I understand correctly, my concern is that if I would like to
perform something like (in pseudo code):

readl(X)
write(1, Y)
readl(Z) 5 times

then I will do this as:

echo X > config
echo Y 1 > config_write
echo 5 > loop
echo Z > config
echo 1 > loop

And the DCC driver will then write this to SRAM as something like:

read X
write Y, 1
loop 5
read Z
loop


In other words, my mind and the DCC has the same representation of this
sequence of operations, but I have to shuffle the information into 4
different sysfs attributes to get there.

The design guideline for sysfs is that each attribute should hold one
value per attribute, but in your model the attributes are tangled and
writing things to them depends on what has been written in that or other
attributes previously.

I simply don't think that's a good ABI.

[..]
> > > > > +		The address argument should
> > > > > +		be given of the form <mask> <value>.For debugging
> > > > > +		purposes sometimes we need to first read from a register
> > > > > +		and then set some values to the register.
> > > > > +		Example:
> > > > > +		echo 0x80000000 > /sys/bus/platform/devices/.../config
> > > > > +		(Set the address in config file)
> > > > > +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
> > > > > +		(Provide the mask and the value to write)
> > > > > +
> > > > > +What:           /sys/bus/platform/devices/.../ready
> > > > > +Date:           March 2021
> > > > > +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
> > > > > +Description:
> > > > > +		This file is used to check the status of the dcc
> > > > > +		hardware if it's ready to take the inputs.
> > > > When will this read "false"?
> > > This will give false if the DCC hardware is not in an operational state.
> > > 
> > > Will update accordingly.
> > > 
> > > > > +		Example:
> > > > > +		cat /sys/bus/platform/devices/.../ready
> > > > > +
> > > > > +What:		/sys/bus/platform/devices/.../curr_list
> > > > > +Date:		February 2021
> > > > > +Contact:	Souradeep Chowdhury<schowdhu@codeaurora.org>
> > > > > +Description:
> > > > > +		This attribute is used to enter the linklist to be
> > > > I think it would be more appropriate to use the verb "select" here and
> > > > afaict it's a "list" as the "linked" part only relates to your
> > > > implementation).
> > > > 
> > > > But that said, I don't like this ABI. I think it would be cleaner if you
> > > > had specific attributes for each of the lists. That way it would be
> > > > clear that you have N lists and they can be configured and enabled
> > > > independently, and there's no possible race conditions.
> > > So we do have attributes for independent lists in this case. The user is
> > > given the option
> > > 
> > > to configure multiple lists at one go. For example I can do
> > > 
> > > echo 1 > curr_list
> > > 
> > > echo 0x18000010 1 > config
> > > echo 0x18000024 1 > config
> > > 
> > > Then followed by
> > > 
> > > echo 2 > curr_list
> > > 
> > > echo 0x18010038 6 > config
> > > echo 0x18020010 1 > config
> > > 
> > > We will get the output in terms of two separate list of registers values.
> > > 
> > I understand that this will define two lists of operations and that we
> > will get 2 and 7 registers dumped, respectively. Perhaps unlikely, but
> > what happens if you try to do these two operations concurrently?
> > 
> > 
> > What I'm suggesting here is that if you have N contexts, you should have
> > N interfaces to modify each one independently - simply because that's
> > generally a very good thing.
> 
> Not sure if there will ever be a concurrency issue in this case.
> This is just about programming the DCC SRAM from the user entries
> sequentially.

So you've decided that two such sequences must not happen at the same
time. (I know it's unlikely, but there's nothing preventing me from
running the two snippets of echos concurrently and the outcome will be
unexpected)

> The curr_list number is nothing but some register writes
> done in the dcc so that the dcc_hardware knows the beginning and end
> of a particular list and can dump the captured data according. Even if
> an user chooses multiple curr_list entries, it will be programmed
> sequentially in DCC_SRAM.
> 

So there's no separation between the lists in the hardware?

Looking at the driver I get a sense that we have N lists that can be
configured independently and will be run "independently" upon a trigger.

If this isn't the case, what's the purpose of the multiple lists?

> > 
> > > > > +		used while appending addresses.The range of values
> > > > > +		for this can be from 0 to 3.This feature is given in
> > > > > +		order to use certain linkedlist for certain debugging
> > > > > +		purposes.
> > > > > +		Example:
> > > > > +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
> > > > > +
> > [..]
> > > > > diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> > [..]
> > > > > +static int dcc_valid_list(struct dcc_drvdata *drvdata, int curr_list)
> > > > > +{
> > > > > +	u32 lock_reg;
> > > > > +
> > > > > +	if (list_empty(&drvdata->cfg_head[curr_list]))
> > > > > +		return -EINVAL;
> > > > > +
> > > > > +	if (drvdata->enable[curr_list]) {
> > > > > +		dev_err(drvdata->dev, "List %d is already enabled\n",
> > > > > +				curr_list);
> > > > > +		return -EINVAL;
> > > > > +	}
> > > > > +
> > > > > +	lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(curr_list));
> > > > Under what circumstances would this differ from
> > > > drvdata->enable[curr_list}?
> > > So locking the list is done on the register as soon as the user enters the
> > > curr_list entry whereas
> > > 
> > > the list is marked as enabled only on successfully programming the SRAM
> > > contents. So a list can
> > > 
> > > be locked and not marked enabled in certain cases. The first is used so that
> > > the user doesn't
> > > 
> > > mistakenly enter the same curr_list twice whereas the later is used to mark
> > > that the list has been
> > > 
> > > successfully configured.
> > > 
> > So this will mark the list as "actively in use, but disabled"? Why is
> > this kept in the hardware? When is this not the same as the list of
> > operations for that list being non-empty?
> 
> So this is in accordance with the dcc hardware configuration
> requirement. We have to lock the list first and after that proceed
> with the subsequent writes.

But what does this mean? What happens when I lock a list?

Afacit we have a "lock" bit and an "enable" bit. So in what circumstance
does the hardware care about a list being locked? Wouldn't it be
sufficient to just have the enable bit?

> As per the driver code below
> 
>                /* 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));
> 
> In case of any errors we again unlock the list before exiting.
> 

So it needs to be locked while SRAM contains a valid sequence of
operations?

Or does it need to be locked while we write to SRAM? If so, why is that?

Regards,
Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Souradeep Chowdhury]

On 1/7/2022 9:27 PM, Bjorn Andersson wrote:
> On Fri 07 Jan 07:27 PST 2022, Souradeep Chowdhury wrote:
>
>> On 1/7/2022 5:31 AM, Bjorn Andersson wrote:
>>> On Wed 05 Jan 23:57 PST 2022, Souradeep Chowdhury wrote:
>>>
>>>> On 12/18/2021 1:41 AM, Bjorn Andersson wrote:
>>>>> On Tue 10 Aug 12:54 CDT 2021, Souradeep Chowdhury wrote:
>>>>>
>>>>>> The DCC is a DMA Engine designed to capture and store data
>>>>>> during system crash or software triggers.The DCC operates
>>>>> Please include a space after '.'
>>>> Ack
>>>>>> based on user inputs via the sysfs interface.The user gives
>>>>>> addresses as inputs and these addresses are stored in the
>>>>>> form of linkedlists.In case of a system crash or a manual
>>>>> I think the user configures the DCC hardware with "a sequence of
>>>>> operations to be performed as DCC is triggered".
>>>>>
>>>>> Afaict the sequence is stored just as a sequence of operations in SRAM,
>>>>> there's no linked list involved - except in your intermediate
>>>>> implementation.
>>>> The user just enters the addresses as input whereas the sequence of
>>>> operations takes
>>>>
>>>> place as per configuration code inside the driver. The end result is storage
>>>> of these
>>>>
>>>> addresses inside the DCC SRAM. The DCC hardware will capture the value at
>>>> these
>>>>
>>>> addresses on a crash or manual trigger by the user.
>>>>
>>>>>> software trigger by the user through the sysfs interface,
>>>>>> the dcc captures and stores the values at these addresses.
>>>>>> This patch contains the driver which has all the methods
>>>>>> pertaining to the sysfs interface, auxiliary functions to
>>>>>> support all the four fundamental operations of dcc namely
>>>>>> read, write, first read then write and loop.The probe method
>>>>> "first read then write" is called "read/modify/write"
>>>> Ack
>>>>>> here instantiates all the resources necessary for dcc to
>>>>>> operate mainly the dedicated dcc sram where it stores the
>>>>>> values.The DCC driver can be used for debugging purposes
>>>>>> without going for a reboot since it can perform manual
>>>>>> triggers.
>>>>>>
>>>>>> Also added the documentation for sysfs entries
>>>>>> and explained the functionalities of each sysfs file that
>>>>>> has been created for dcc.
>>>>>>
>>>>>> The following is the justification of using sysfs interface
>>>>>> over the other alternatives like ioctls
>>>>>>
>>>>>> i) As can be seen from the sysfs attribute descriptions,
>>>>>> most of it does basic hardware manipulations like dcc_enable,
>>>>>> dcc_disable, config reset etc. As a result sysfs is preferred
>>>>>> over ioctl as we just need to enter a 0 or 1.
>>>>>>
>>>>> As I mentioned in our chat, using sysfs allows us to operate the
>>>>> interface using the shell without additional tools.
>>>>>
>>>>> But I don't think that it's easy to implement enable/disable/reset using
>>>>> sysfs is a strong argument. The difficult part of this ABI is the
>>>>> operations to manipulate the sequence of operations, so that's what you
>>>>> need to have a solid plan for.
>>>> The sysfs interface is being used to get the addresses values entered by the
>>>> user
>>>>
>>>> and to also go for manual triggers. The sequence of operations are kept as a
>>>> part of
>>>>
>>>> fixed driver code which is called when the user enters the data.
>>>>
>>> But does the hardware really just operate on "addresses values entered
>>> by the user". Given the various types of operations: read, write,
>>> read-modify-write and loop I get the feeling that the hardware
>>> "executes" a series of actions.
>>>
>>> I'm don't think the proposed sysfs interface best exposes this to the
>>> user and I don't think that "it's easy to implement enable/disable
>>> attributes in sysfs" is reason enough to go with that approach.
>> So the sysfs interface here has been introduced keeping in mind how the
>> DCC_SRAM needs to be
>>
>> programmed for the dcc hardware to work. We are maintaining a list here
>> based on the address
>>
>> entry. The 4 cases for the type of addresses are as follows-:
>>
>> i) READ ADDRESSES
>>
>> user enters something like "echo <addr> <len> > config"
>>
>> DCC driver stores the <addr> along with the length information in the
>> DCC_SRAM.
>>
>> ii) WRITE ADDRESSES
>>
>> User enters something like "echo <addr> <write_val> 1  > config_write"
>>
>> DCC stores the <addr> first in sram followed by <write_val>.
>>
>> For the above 2 type of addresses there won't be much difference if we use
>> IOCTL.
>>
>> However, for the next 2 type of addresses
>>
>> iii) LOOP ADDRESSES
>>
>> user has to enter something like below
>>
>> echo 9 > loop
>> echo 0x01741010 1 > config
>> echo 0x01741014 1 > config
>> echo 1 > loop
>>
>> The DCC SRAM will be programmed precisely like the above entries where the
>> loop count will be stored first
>>
>> followed by loop addresses and then again a "echo 1 > loop " marks the end
>> of loop addresses.
>>
>> in DCC_SRAM.
>>
>> iv) READ_WRITE ADDRESSES
>>
>> User has to enter something like below
>>
>> echo <addr> > /sys/bus/platform/devices/../config
>>
>> echo <mask> <val> > /sys/bus/platform/devices/../rd_mod_wr
>>
>> Here first the  <addr> is stored in DCC_SRAM followed by <mask> and then the
>> <val>.
>>
>> The above representation to the user space is consistent with the dcc
>> hardware in terms of
>>
>> the way the sequence of values are programmed in the DCC SRAM . Moving to
>> IOCTL will
>>
>> only change the way the READ_WRITE address is represented although user will
>> have to enter
>>
>> multiple parameters at once, let me know if we still need to go for the
>> same.
>>
> So if I understand correctly, my concern is that if I would like to
> perform something like (in pseudo code):
>
> readl(X)
> write(1, Y)
> readl(Z) 5 times
>
> then I will do this as:
>
> echo X > config
> echo Y 1 > config_write
> echo 5 > loop
> echo Z > config
> echo 1 > loop
>
> And the DCC driver will then write this to SRAM as something like:
>
> read X
> write Y, 1
> loop 5
> read Z
> loop
>
>
> In other words, my mind and the DCC has the same representation of this
> sequence of operations, but I have to shuffle the information into 4
> different sysfs attributes to get there.
>
> The design guideline for sysfs is that each attribute should hold one
> value per attribute, but in your model the attributes are tangled and
> writing things to them depends on what has been written in that or other
> attributes previously.
>
> I simply don't think that's a good ABI.

Ack.

Should I change this to have separate sysfs files dealing with separate 
type of instructions?

For example I can have separate files like config_read, 
config_write(already exists), config_loop

and config_read_write to handle 4 different type of instructions with 
inputs like

echo <loop_offset> <loop_address_numbers> <loop_address_1> 
<loop_address_2>.. > config_loop

echo <address> <mask> <val> > config_read_write

and so on

>
> [..]
>>>>>> +		The address argument should
>>>>>> +		be given of the form <mask> <value>.For debugging
>>>>>> +		purposes sometimes we need to first read from a register
>>>>>> +		and then set some values to the register.
>>>>>> +		Example:
>>>>>> +		echo 0x80000000 > /sys/bus/platform/devices/.../config
>>>>>> +		(Set the address in config file)
>>>>>> +		echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
>>>>>> +		(Provide the mask and the value to write)
>>>>>> +
>>>>>> +What:           /sys/bus/platform/devices/.../ready
>>>>>> +Date:           March 2021
>>>>>> +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>>>> +Description:
>>>>>> +		This file is used to check the status of the dcc
>>>>>> +		hardware if it's ready to take the inputs.
>>>>> When will this read "false"?
>>>> This will give false if the DCC hardware is not in an operational state.
>>>>
>>>> Will update accordingly.
>>>>
>>>>>> +		Example:
>>>>>> +		cat /sys/bus/platform/devices/.../ready
>>>>>> +
>>>>>> +What:		/sys/bus/platform/devices/.../curr_list
>>>>>> +Date:		February 2021
>>>>>> +Contact:	Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>>>> +Description:
>>>>>> +		This attribute is used to enter the linklist to be
>>>>> I think it would be more appropriate to use the verb "select" here and
>>>>> afaict it's a "list" as the "linked" part only relates to your
>>>>> implementation).
>>>>>
>>>>> But that said, I don't like this ABI. I think it would be cleaner if you
>>>>> had specific attributes for each of the lists. That way it would be
>>>>> clear that you have N lists and they can be configured and enabled
>>>>> independently, and there's no possible race conditions.
>>>> So we do have attributes for independent lists in this case. The user is
>>>> given the option
>>>>
>>>> to configure multiple lists at one go. For example I can do
>>>>
>>>> echo 1 > curr_list
>>>>
>>>> echo 0x18000010 1 > config
>>>> echo 0x18000024 1 > config
>>>>
>>>> Then followed by
>>>>
>>>> echo 2 > curr_list
>>>>
>>>> echo 0x18010038 6 > config
>>>> echo 0x18020010 1 > config
>>>>
>>>> We will get the output in terms of two separate list of registers values.
>>>>
>>> I understand that this will define two lists of operations and that we
>>> will get 2 and 7 registers dumped, respectively. Perhaps unlikely, but
>>> what happens if you try to do these two operations concurrently?
>>>
>>>
>>> What I'm suggesting here is that if you have N contexts, you should have
>>> N interfaces to modify each one independently - simply because that's
>>> generally a very good thing.
>> Not sure if there will ever be a concurrency issue in this case.
>> This is just about programming the DCC SRAM from the user entries
>> sequentially.
> So you've decided that two such sequences must not happen at the same
> time. (I know it's unlikely, but there's nothing preventing me from
> running the two snippets of echos concurrently and the outcome will be
> unexpected)

So as per the dcc hardware configuration document, parallel programming 
of lists are not

supported for dcc. We program the lists sequentially one after the other.

>
>> The curr_list number is nothing but some register writes
>> done in the dcc so that the dcc_hardware knows the beginning and end
>> of a particular list and can dump the captured data according. Even if
>> an user chooses multiple curr_list entries, it will be programmed
>> sequentially in DCC_SRAM.
>>
> So there's no separation between the lists in the hardware?
>
> Looking at the driver I get a sense that we have N lists that can be
> configured independently and will be run "independently" upon a trigger.
>
> If this isn't the case, what's the purpose of the multiple lists?

Lists are programmed sequentially from the driver perspective.

We have multiple lists in case of dcc because multiple software 
components may be using

dcc hardware at once in which case there are individual lists allotted 
for each individual components.

For example kernel might have a few lists to access whereas the rest 
maybe used by SDI which is a

separate component. Each list is of arbitrary length as entered by the 
user and one list can be updated

with it's base address after the previous list has been programmed in 
DCC_SRAM like below :-

                 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));
  

>
>>>>>> +		used while appending addresses.The range of values
>>>>>> +		for this can be from 0 to 3.This feature is given in
>>>>>> +		order to use certain linkedlist for certain debugging
>>>>>> +		purposes.
>>>>>> +		Example:
>>>>>> +		echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
>>>>>> +
>>> [..]
>>>>>> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
>>> [..]
>>>>>> +static int dcc_valid_list(struct dcc_drvdata *drvdata, int curr_list)
>>>>>> +{
>>>>>> +	u32 lock_reg;
>>>>>> +
>>>>>> +	if (list_empty(&drvdata->cfg_head[curr_list]))
>>>>>> +		return -EINVAL;
>>>>>> +
>>>>>> +	if (drvdata->enable[curr_list]) {
>>>>>> +		dev_err(drvdata->dev, "List %d is already enabled\n",
>>>>>> +				curr_list);
>>>>>> +		return -EINVAL;
>>>>>> +	}
>>>>>> +
>>>>>> +	lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(curr_list));
>>>>> Under what circumstances would this differ from
>>>>> drvdata->enable[curr_list}?
>>>> So locking the list is done on the register as soon as the user enters the
>>>> curr_list entry whereas
>>>>
>>>> the list is marked as enabled only on successfully programming the SRAM
>>>> contents. So a list can
>>>>
>>>> be locked and not marked enabled in certain cases. The first is used so that
>>>> the user doesn't
>>>>
>>>> mistakenly enter the same curr_list twice whereas the later is used to mark
>>>> that the list has been
>>>>
>>>> successfully configured.
>>>>
>>> So this will mark the list as "actively in use, but disabled"? Why is
>>> this kept in the hardware? When is this not the same as the list of
>>> operations for that list being non-empty?
>> So this is in accordance with the dcc hardware configuration
>> requirement. We have to lock the list first and after that proceed
>> with the subsequent writes.
> But what does this mean? What happens when I lock a list?
>
> Afacit we have a "lock" bit and an "enable" bit. So in what circumstance
> does the hardware care about a list being locked? Wouldn't it be
> sufficient to just have the enable bit?

As explained above multiple software components might be using DCC 
hardware for which lock bit is

necessary. From only kernel perspective enable bit alone suffices for 
the operation.

>
>> As per the driver code below
>>
>>                 /* 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));
>>
>> In case of any errors we again unlock the list before exiting.
>>
> So it needs to be locked while SRAM contains a valid sequence of
> operations?
>
> Or does it need to be locked while we write to SRAM? If so, why is that?

So it needs to be locked while SRAM contains a valid sequence of operations.

The reason has been explained as above.

> Regards,
> Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH V6 2/7] soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC)

[Souradeep Chowdhury]

On 1/17/2022 11:19 AM, Souradeep Chowdhury wrote:
>
> On 1/7/2022 9:27 PM, Bjorn Andersson wrote:
>> On Fri 07 Jan 07:27 PST 2022, Souradeep Chowdhury wrote:
>>
>>> On 1/7/2022 5:31 AM, Bjorn Andersson wrote:
>>>> On Wed 05 Jan 23:57 PST 2022, Souradeep Chowdhury wrote:
>>>>
>>>>> On 12/18/2021 1:41 AM, Bjorn Andersson wrote:
>>>>>> On Tue 10 Aug 12:54 CDT 2021, Souradeep Chowdhury wrote:
>>>>>>
>>>>>>> The DCC is a DMA Engine designed to capture and store data
>>>>>>> during system crash or software triggers.The DCC operates
>>>>>> Please include a space after '.'
>>>>> Ack
>>>>>>> based on user inputs via the sysfs interface.The user gives
>>>>>>> addresses as inputs and these addresses are stored in the
>>>>>>> form of linkedlists.In case of a system crash or a manual
>>>>>> I think the user configures the DCC hardware with "a sequence of
>>>>>> operations to be performed as DCC is triggered".
>>>>>>
>>>>>> Afaict the sequence is stored just as a sequence of operations in 
>>>>>> SRAM,
>>>>>> there's no linked list involved - except in your intermediate
>>>>>> implementation.
>>>>> The user just enters the addresses as input whereas the sequence of
>>>>> operations takes
>>>>>
>>>>> place as per configuration code inside the driver. The end result 
>>>>> is storage
>>>>> of these
>>>>>
>>>>> addresses inside the DCC SRAM. The DCC hardware will capture the 
>>>>> value at
>>>>> these
>>>>>
>>>>> addresses on a crash or manual trigger by the user.
>>>>>
>>>>>>> software trigger by the user through the sysfs interface,
>>>>>>> the dcc captures and stores the values at these addresses.
>>>>>>> This patch contains the driver which has all the methods
>>>>>>> pertaining to the sysfs interface, auxiliary functions to
>>>>>>> support all the four fundamental operations of dcc namely
>>>>>>> read, write, first read then write and loop.The probe method
>>>>>> "first read then write" is called "read/modify/write"
>>>>> Ack
>>>>>>> here instantiates all the resources necessary for dcc to
>>>>>>> operate mainly the dedicated dcc sram where it stores the
>>>>>>> values.The DCC driver can be used for debugging purposes
>>>>>>> without going for a reboot since it can perform manual
>>>>>>> triggers.
>>>>>>>
>>>>>>> Also added the documentation for sysfs entries
>>>>>>> and explained the functionalities of each sysfs file that
>>>>>>> has been created for dcc.
>>>>>>>
>>>>>>> The following is the justification of using sysfs interface
>>>>>>> over the other alternatives like ioctls
>>>>>>>
>>>>>>> i) As can be seen from the sysfs attribute descriptions,
>>>>>>> most of it does basic hardware manipulations like dcc_enable,
>>>>>>> dcc_disable, config reset etc. As a result sysfs is preferred
>>>>>>> over ioctl as we just need to enter a 0 or 1.
>>>>>>>
>>>>>> As I mentioned in our chat, using sysfs allows us to operate the
>>>>>> interface using the shell without additional tools.
>>>>>>
>>>>>> But I don't think that it's easy to implement 
>>>>>> enable/disable/reset using
>>>>>> sysfs is a strong argument. The difficult part of this ABI is the
>>>>>> operations to manipulate the sequence of operations, so that's 
>>>>>> what you
>>>>>> need to have a solid plan for.
>>>>> The sysfs interface is being used to get the addresses values 
>>>>> entered by the
>>>>> user
>>>>>
>>>>> and to also go for manual triggers. The sequence of operations are 
>>>>> kept as a
>>>>> part of
>>>>>
>>>>> fixed driver code which is called when the user enters the data.
>>>>>
>>>> But does the hardware really just operate on "addresses values entered
>>>> by the user". Given the various types of operations: read, write,
>>>> read-modify-write and loop I get the feeling that the hardware
>>>> "executes" a series of actions.
>>>>
>>>> I'm don't think the proposed sysfs interface best exposes this to the
>>>> user and I don't think that "it's easy to implement enable/disable
>>>> attributes in sysfs" is reason enough to go with that approach.
>>> So the sysfs interface here has been introduced keeping in mind how the
>>> DCC_SRAM needs to be
>>>
>>> programmed for the dcc hardware to work. We are maintaining a list here
>>> based on the address
>>>
>>> entry. The 4 cases for the type of addresses are as follows-:
>>>
>>> i) READ ADDRESSES
>>>
>>> user enters something like "echo <addr> <len> > config"
>>>
>>> DCC driver stores the <addr> along with the length information in the
>>> DCC_SRAM.
>>>
>>> ii) WRITE ADDRESSES
>>>
>>> User enters something like "echo <addr> <write_val> 1  > config_write"
>>>
>>> DCC stores the <addr> first in sram followed by <write_val>.
>>>
>>> For the above 2 type of addresses there won't be much difference if 
>>> we use
>>> IOCTL.
>>>
>>> However, for the next 2 type of addresses
>>>
>>> iii) LOOP ADDRESSES
>>>
>>> user has to enter something like below
>>>
>>> echo 9 > loop
>>> echo 0x01741010 1 > config
>>> echo 0x01741014 1 > config
>>> echo 1 > loop
>>>
>>> The DCC SRAM will be programmed precisely like the above entries 
>>> where the
>>> loop count will be stored first
>>>
>>> followed by loop addresses and then again a "echo 1 > loop " marks 
>>> the end
>>> of loop addresses.
>>>
>>> in DCC_SRAM.
>>>
>>> iv) READ_WRITE ADDRESSES
>>>
>>> User has to enter something like below
>>>
>>> echo <addr> > /sys/bus/platform/devices/../config
>>>
>>> echo <mask> <val> > /sys/bus/platform/devices/../rd_mod_wr
>>>
>>> Here first the  <addr> is stored in DCC_SRAM followed by <mask> and 
>>> then the
>>> <val>.
>>>
>>> The above representation to the user space is consistent with the dcc
>>> hardware in terms of
>>>
>>> the way the sequence of values are programmed in the DCC SRAM . 
>>> Moving to
>>> IOCTL will
>>>
>>> only change the way the READ_WRITE address is represented although 
>>> user will
>>> have to enter
>>>
>>> multiple parameters at once, let me know if we still need to go for the
>>> same.
>>>
>> So if I understand correctly, my concern is that if I would like to
>> perform something like (in pseudo code):
>>
>> readl(X)
>> write(1, Y)
>> readl(Z) 5 times
>>
>> then I will do this as:
>>
>> echo X > config
>> echo Y 1 > config_write
>> echo 5 > loop
>> echo Z > config
>> echo 1 > loop
>>
>> And the DCC driver will then write this to SRAM as something like:
>>
>> read X
>> write Y, 1
>> loop 5
>> read Z
>> loop
>>
>>
>> In other words, my mind and the DCC has the same representation of this
>> sequence of operations, but I have to shuffle the information into 4
>> different sysfs attributes to get there.
>>
>> The design guideline for sysfs is that each attribute should hold one
>> value per attribute, but in your model the attributes are tangled and
>> writing things to them depends on what has been written in that or other
>> attributes previously.
>>
>> I simply don't think that's a good ABI.
>
> Ack.
>
> Should I change this to have separate sysfs files dealing with 
> separate type of instructions?
>
> For example I can have separate files like config_read, 
> config_write(already exists), config_loop
>
> and config_read_write to handle 4 different type of instructions with 
> inputs like
>
> echo <loop_offset> <loop_address_numbers> <loop_address_1> 
> <loop_address_2>.. > config_loop
>
> echo <address> <mask> <val> > config_read_write
>
> and so on

Hi Bjorn,


Further to this, since in case of sysfs , we cannot have multiple values 
for a single sysfs file,

handling loop instructions become  difficult.

So can I go for debugfs for the above implementation?

I can have separate debugfs files to handle config_loop , config_read, 
config_write, config_read_write

with inputs as follows

->  echo <read_address>  >  config_read

->  echo <write_address> <write_val>  > config_write

->  echo <loop_counter> <loop_address_number> <loop_address1> 
<loop_address2>..  >  config_loop

->  echo <read_write_address> <write_mask> <write_val>  >  config_read_write

Let me know your thoughts regarding this.


Thanks,

Souradeep


>
>>
>> [..]
>>>>>>> +        The address argument should
>>>>>>> +        be given of the form <mask> <value>.For debugging
>>>>>>> +        purposes sometimes we need to first read from a register
>>>>>>> +        and then set some values to the register.
>>>>>>> +        Example:
>>>>>>> +        echo 0x80000000 > /sys/bus/platform/devices/.../config
>>>>>>> +        (Set the address in config file)
>>>>>>> +        echo 0xF 0xA > /sys/bus/platform/devices/.../rd_mod_wr
>>>>>>> +        (Provide the mask and the value to write)
>>>>>>> +
>>>>>>> +What:           /sys/bus/platform/devices/.../ready
>>>>>>> +Date:           March 2021
>>>>>>> +Contact:        Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>>>>> +Description:
>>>>>>> +        This file is used to check the status of the dcc
>>>>>>> +        hardware if it's ready to take the inputs.
>>>>>> When will this read "false"?
>>>>> This will give false if the DCC hardware is not in an operational 
>>>>> state.
>>>>>
>>>>> Will update accordingly.
>>>>>
>>>>>>> +        Example:
>>>>>>> +        cat /sys/bus/platform/devices/.../ready
>>>>>>> +
>>>>>>> +What:        /sys/bus/platform/devices/.../curr_list
>>>>>>> +Date:        February 2021
>>>>>>> +Contact:    Souradeep Chowdhury<schowdhu@codeaurora.org>
>>>>>>> +Description:
>>>>>>> +        This attribute is used to enter the linklist to be
>>>>>> I think it would be more appropriate to use the verb "select" 
>>>>>> here and
>>>>>> afaict it's a "list" as the "linked" part only relates to your
>>>>>> implementation).
>>>>>>
>>>>>> But that said, I don't like this ABI. I think it would be cleaner 
>>>>>> if you
>>>>>> had specific attributes for each of the lists. That way it would be
>>>>>> clear that you have N lists and they can be configured and enabled
>>>>>> independently, and there's no possible race conditions.
>>>>> So we do have attributes for independent lists in this case. The 
>>>>> user is
>>>>> given the option
>>>>>
>>>>> to configure multiple lists at one go. For example I can do
>>>>>
>>>>> echo 1 > curr_list
>>>>>
>>>>> echo 0x18000010 1 > config
>>>>> echo 0x18000024 1 > config
>>>>>
>>>>> Then followed by
>>>>>
>>>>> echo 2 > curr_list
>>>>>
>>>>> echo 0x18010038 6 > config
>>>>> echo 0x18020010 1 > config
>>>>>
>>>>> We will get the output in terms of two separate list of registers 
>>>>> values.
>>>>>
>>>> I understand that this will define two lists of operations and that we
>>>> will get 2 and 7 registers dumped, respectively. Perhaps unlikely, but
>>>> what happens if you try to do these two operations concurrently?
>>>>
>>>>
>>>> What I'm suggesting here is that if you have N contexts, you should 
>>>> have
>>>> N interfaces to modify each one independently - simply because that's
>>>> generally a very good thing.
>>> Not sure if there will ever be a concurrency issue in this case.
>>> This is just about programming the DCC SRAM from the user entries
>>> sequentially.
>> So you've decided that two such sequences must not happen at the same
>> time. (I know it's unlikely, but there's nothing preventing me from
>> running the two snippets of echos concurrently and the outcome will be
>> unexpected)
>
> So as per the dcc hardware configuration document, parallel 
> programming of lists are not
>
> supported for dcc. We program the lists sequentially one after the other.
>
>>
>>> The curr_list number is nothing but some register writes
>>> done in the dcc so that the dcc_hardware knows the beginning and end
>>> of a particular list and can dump the captured data according. Even if
>>> an user chooses multiple curr_list entries, it will be programmed
>>> sequentially in DCC_SRAM.
>>>
>> So there's no separation between the lists in the hardware?
>>
>> Looking at the driver I get a sense that we have N lists that can be
>> configured independently and will be run "independently" upon a trigger.
>>
>> If this isn't the case, what's the purpose of the multiple lists?
>
> Lists are programmed sequentially from the driver perspective.
>
> We have multiple lists in case of dcc because multiple software 
> components may be using
>
> dcc hardware at once in which case there are individual lists allotted 
> for each individual components.
>
> For example kernel might have a few lists to access whereas the rest 
> maybe used by SDI which is a
>
> separate component. Each list is of arbitrary length as entered by the 
> user and one list can be updated
>
> with it's base address after the previous list has been programmed in 
> DCC_SRAM like below :-
>
>                 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));
>
>
>>
>>>>>>> +        used while appending addresses.The range of values
>>>>>>> +        for this can be from 0 to 3.This feature is given in
>>>>>>> +        order to use certain linkedlist for certain debugging
>>>>>>> +        purposes.
>>>>>>> +        Example:
>>>>>>> +        echo 0 > /sys/bus/platform/devices/10a2000.dcc/curr_list
>>>>>>> +
>>>> [..]
>>>>>>> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
>>>> [..]
>>>>>>> +static int dcc_valid_list(struct dcc_drvdata *drvdata, int 
>>>>>>> curr_list)
>>>>>>> +{
>>>>>>> +    u32 lock_reg;
>>>>>>> +
>>>>>>> +    if (list_empty(&drvdata->cfg_head[curr_list]))
>>>>>>> +        return -EINVAL;
>>>>>>> +
>>>>>>> +    if (drvdata->enable[curr_list]) {
>>>>>>> +        dev_err(drvdata->dev, "List %d is already enabled\n",
>>>>>>> +                curr_list);
>>>>>>> +        return -EINVAL;
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(curr_list));
>>>>>> Under what circumstances would this differ from
>>>>>> drvdata->enable[curr_list}?
>>>>> So locking the list is done on the register as soon as the user 
>>>>> enters the
>>>>> curr_list entry whereas
>>>>>
>>>>> the list is marked as enabled only on successfully programming the 
>>>>> SRAM
>>>>> contents. So a list can
>>>>>
>>>>> be locked and not marked enabled in certain cases. The first is 
>>>>> used so that
>>>>> the user doesn't
>>>>>
>>>>> mistakenly enter the same curr_list twice whereas the later is 
>>>>> used to mark
>>>>> that the list has been
>>>>>
>>>>> successfully configured.
>>>>>
>>>> So this will mark the list as "actively in use, but disabled"? Why is
>>>> this kept in the hardware? When is this not the same as the list of
>>>> operations for that list being non-empty?
>>> So this is in accordance with the dcc hardware configuration
>>> requirement. We have to lock the list first and after that proceed
>>> with the subsequent writes.
>> But what does this mean? What happens when I lock a list?
>>
>> Afacit we have a "lock" bit and an "enable" bit. So in what circumstance
>> does the hardware care about a list being locked? Wouldn't it be
>> sufficient to just have the enable bit?
>
> As explained above multiple software components might be using DCC 
> hardware for which lock bit is
>
> necessary. From only kernel perspective enable bit alone suffices for 
> the operation.
>
>>
>>> As per the driver code below
>>>
>>>                 /* 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));
>>>
>>> In case of any errors we again unlock the list before exiting.
>>>
>> So it needs to be locked while SRAM contains a valid sequence of
>> operations?
>>
>> Or does it need to be locked while we write to SRAM? If so, why is that?
>
> So it needs to be locked while SRAM contains a valid sequence of 
> operations.
>
> The reason has been explained as above.
>
>> Regards,
>> Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel