* Re: [PATCH 0/2] Add HwSpinlock nodes for TI K3 SoCs
From: Suman Anna @ 2019-08-27 22:34 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190722190539.27816-1-s-anna@ti.com>
Hi Tero,
On 7/22/19 2:05 PM, Suman Anna wrote:
> Hi Tero,
>
> The following series adds the HwSpinlock DT nodes for the
> TI K3 AM65x and J721E SoC families. Patches are based on
> v5.3-rc1.
I am not sure if you have already staged these, but if haven't,
can you please pick these and the mailbox nodes for 5.4 merge window?
Thanks,
Suman
>
> The bindings and driver support for the same have been
> merged in v5.3-rc1.
>
> regards
> Suman
>
> Suman Anna (2):
> arm64: dts: ti: k3-am65-main: Add hwspinlock node
> arm64: dts: ti: k3-j721e-main: Add hwspinlock node
>
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 6 ++++++
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 6 ++++++
> 2 files changed, 12 insertions(+)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 8/8] coresight: etm4x: docs: Additional documentation for ETM4x.
From: Mathieu Poirier @ 2019-08-27 22:32 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190819205720.24457-9-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:20PM +0100, Mike Leach wrote:
> Update existing docs for new sysfs API features.
> Add new ETMv4 reference document for sysfs programming.
> Move coresight documentation to common directory.
Please split in 3 different patches. When sending again make sure to add
Jonathan Corbet, Greg KH and the linux-doc mailing as recipients.
Thanks,
Mathieu
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../testing/sysfs-bus-coresight-devices-etm4x | 183 ++++---
> .../{ => coresight}/coresight-cpu-debug.txt | 0
> .../coresight/coresight-etm4x-reference.txt | 459 ++++++++++++++++++
> .../trace/{ => coresight}/coresight.txt | 0
> MAINTAINERS | 3 +-
> 5 files changed, 575 insertions(+), 70 deletions(-)
> rename Documentation/trace/{ => coresight}/coresight-cpu-debug.txt (100%)
> create mode 100644 Documentation/trace/coresight/coresight-etm4x-reference.txt
> rename Documentation/trace/{ => coresight}/coresight.txt (100%)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> index 36258bc1b473..112c50ae9986 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> @@ -1,4 +1,4 @@
> -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> +What: /sys/bus/coresight/devices/etm<N>/enable_source
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> @@ -8,82 +8,82 @@ Description: (RW) Enable/disable tracing on this specific trace entiry.
> of coresight components linking the source to the sink is
> configured and managed automatically by the coresight framework.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/cpu
> +What: /sys/bus/coresight/devices/etm<N>/cpu
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) The CPU this tracing entity is associated with.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
> +What: /sys/bus/coresight/devices/etm<N>/nr_pe_cmp
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of PE comparator inputs that are
> available for tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
> +What: /sys/bus/coresight/devices/etm<N>/nr_addr_cmp
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of address comparator pairs that are
> available for tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
> +What: /sys/bus/coresight/devices/etm<N>/nr_cntr
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of counters that are available for
> tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
> +What: /sys/bus/coresight/devices/etm<N>/nr_ext_inp
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates how many external inputs are implemented.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/numcidc
> +What: /sys/bus/coresight/devices/etm<N>/numcidc
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of Context ID comparators that are
> available for tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/numvmidc
> +What: /sys/bus/coresight/devices/etm<N>/numvmidc
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of VMID comparators that are available
> for tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
> +What: /sys/bus/coresight/devices/etm<N>/nrseqstate
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of sequencer states that are
> implemented.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_resource
> +What: /sys/bus/coresight/devices/etm<N>/nr_resource
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of resource selection pairs that are
> available for tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
> +What: /sys/bus/coresight/devices/etm<N>/nr_ss_cmp
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Indicates the number of single-shot comparator controls that
> are available for tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/reset
> +What: /sys/bus/coresight/devices/etm<N>/reset
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (W) Cancels all configuration on a trace unit and set it back
> to its boot configuration.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mode
> +What: /sys/bus/coresight/devices/etm<N>/mode
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> @@ -91,302 +91,349 @@ Description: (RW) Controls various modes supported by this ETM, for example
> P0 instruction tracing, branch broadcast, cycle counting and
> context ID tracing.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/pe
> +What: /sys/bus/coresight/devices/etm<N>/pe
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls which PE to trace.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/event
> +What: /sys/bus/coresight/devices/etm<N>/event
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls the tracing of arbitrary events from bank 0 to 3.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/event_instren
> +What: /sys/bus/coresight/devices/etm<N>/event_instren
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls the behavior of the events in bank 0 to 3.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/event_ts
> +What: /sys/bus/coresight/devices/etm<N>/event_ts
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls the insertion of global timestamps in the trace
> streams.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/syncfreq
> +What: /sys/bus/coresight/devices/etm<N>/syncfreq
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls how often trace synchronization requests occur.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
> +What: /sys/bus/coresight/devices/etm<N>/cyc_threshold
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Sets the threshold value for cycle counting.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
> +What: /sys/bus/coresight/devices/etm<N>/bb_ctrl
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls which regions in the memory map are enabled to
> use branch broadcasting.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/event_vinst
> +What: /sys/bus/coresight/devices/etm<N>/event_vinst
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls instruction trace filtering.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
> +What: /sys/bus/coresight/devices/etm<N>/s_exlevel_vinst
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) In Secure state, each bit controls whether instruction
> tracing is enabled for the corresponding exception level.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
> +What: /sys/bus/coresight/devices/etm<N>/ns_exlevel_vinst
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) In non-secure state, each bit controls whether instruction
> tracing is enabled for the corresponding exception level.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_idx
> +What: /sys/bus/coresight/devices/etm<N>/addr_idx
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Select which address comparator or pair (of comparators) to
> work with.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
> +What: /sys/bus/coresight/devices/etm<N>/addr_instdatatype
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls what type of comparison the trace unit performs.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_single
> +What: /sys/bus/coresight/devices/etm<N>/addr_single
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Used to setup single address comparator values.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/addr_range
> +What: /sys/bus/coresight/devices/etm<N>/addr_range
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Used to setup address range comparator values.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_idx
> +What: /sys/bus/coresight/devices/etm<N>/seq_idx
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Select which sequensor.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_state
> +What: /sys/bus/coresight/devices/etm<N>/seq_state
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Use this to set, or read, the sequencer state.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_event
> +What: /sys/bus/coresight/devices/etm<N>/seq_event
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Moves the sequencer state to a specific state.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
> +What: /sys/bus/coresight/devices/etm<N>/seq_reset_event
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Moves the sequencer to state 0 when a programmed event
> occurs.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
> +What: /sys/bus/coresight/devices/etm<N>/cntr_idx
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Select which counter unit to work with.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
> +What: /sys/bus/coresight/devices/etm<N>/cntrldvr
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) This sets or returns the reload count value of the
> specific counter.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_val
> +What: /sys/bus/coresight/devices/etm<N>/cntr_val
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) This sets or returns the current count value of the
> specific counter.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
> +What: /sys/bus/coresight/devices/etm<N>/cntr_ctrl
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls the operation of the selected counter.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/res_idx
> +What: /sys/bus/coresight/devices/etm<N>/res_idx
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Select which resource selection unit to work with.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
> +What: /sys/bus/coresight/devices/etm<N>/res_ctrl
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Controls the selection of the resources in the trace unit.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
> +What: /sys/bus/coresight/devices/etm<N>/ctxid_idx
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Select which context ID comparator to work with.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
> +What: /sys/bus/coresight/devices/etm<N>/ctxid_pid
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Get/Set the context ID comparator value to trigger on.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
> +What: /sys/bus/coresight/devices/etm<N>/ctxid_masks
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Mask for all 8 context ID comparator value
> registers (if implemented).
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
> +What: /sys/bus/coresight/devices/etm<N>/vmid_idx
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Select which virtual machine ID comparator to work with.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_val
> +What: /sys/bus/coresight/devices/etm<N>/vmid_val
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Get/Set the virtual machine ID comparator value to
> trigger on.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
> +What: /sys/bus/coresight/devices/etm<N>/vmid_masks
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (RW) Mask for all 8 virtual machine ID comparator value
> registers (if implemented).
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
> +What: /sys/bus/coresight/devices/etm<N>/addr_exlevel_s_ns
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (RW) Set the Exception Level matching bits for secure and
> + non-secure exception levels.
> +
> +What: /sys/bus/coresight/devices/etm<N>/vinst_pe_cmp_start_stop
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (RW) Access the start stop control register for PE input
> + comparators.
> +
> +What: /sys/bus/coresight/devices/etm<N>/addr_cmp_view
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (R) Print the current settings for the selected address
> + comparator.
> +
> +What: /sys/bus/coresight/devices/etm<N>/sshot_idx
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (RW) Select the single shot control register to access.
> +
> +What: /sys/bus/coresight/devices/etm<N>/sshot_ctrl
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (RW) Access the selected single shot control register.
> +
> +What: /sys/bus/coresight/devices/etm<N>/sshot_status
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (R) Print the current value of the selected single shot
> + status register.
> +
> +What: /sys/bus/coresight/devices/etm<N>/sshot_pe_ctrl
> +Date: August 2019
> +KernelVersion: 5.4
> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> +Description: (RW) Access the selected single show PE comparator control
> + register.
> +
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcoslsr
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the OS Lock Status Register (0x304).
> The value it taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdcr
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Power Down Control Register
> (0x310). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdsr
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Power Down Status Register
> (0x314). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trclsr
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the SW Lock Status Register
> (0xFB4). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcauthstatus
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Authentication Status Register
> (0xFB8). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevid
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Device ID Register
> (0xFC8). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevtype
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Device Type Register
> (0xFCC). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr0
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Peripheral ID0 Register
> (0xFE0). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr1
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Peripheral ID1 Register
> (0xFE4). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr2
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Peripheral ID2 Register
> (0xFE8). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr3
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the Peripheral ID3 Register
> (0xFEC). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcconfig
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trcconfig
> Date: February 2016
> KernelVersion: 4.07
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the trace configuration register
> (0x010) as currently set by SW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trctraceid
> +What: /sys/bus/coresight/devices/etm<N>/mgmt/trctraceid
> Date: February 2016
> KernelVersion: 4.07
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Print the content of the trace ID register (0x040).
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr0
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns the tracing capabilities of the trace unit (0x1E0).
> The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr1
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns the tracing capabilities of the trace unit (0x1E4).
> The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr2
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> @@ -394,7 +441,7 @@ Description: (R) Returns the maximum size of the data value, data address,
> VMID, context ID and instuction address in the trace unit
> (0x1E8). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> @@ -403,42 +450,42 @@ Description: (R) Returns the value associated with various resources
> architecture specification for more details (0x1E8).
> The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr4
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns how many resources the trace unit supports (0x1F0).
> The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr5
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns how many resources the trace unit supports (0x1F4).
> The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr8
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns the maximum speculation depth of the instruction
> trace stream. (0x180). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr9
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns the number of P0 right-hand keys that the trace unit
> can use (0x184). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr10
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> Description: (R) Returns the number of P1 right-hand keys that the trace unit
> can use (0x188). The value is taken directly from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr11
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> @@ -446,7 +493,7 @@ Description: (R) Returns the number of special P1 right-hand keys that the
> trace unit can use (0x18C). The value is taken directly from
> the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr12
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> @@ -454,7 +501,7 @@ Description: (R) Returns the number of conditional P1 right-hand keys that
> the trace unit can use (0x190). The value is taken directly
> from the HW.
>
> -What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
> +What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr13
> Date: April 2015
> KernelVersion: 4.01
> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight/coresight-cpu-debug.txt
> similarity index 100%
> rename from Documentation/trace/coresight-cpu-debug.txt
> rename to Documentation/trace/coresight/coresight-cpu-debug.txt
> diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.txt b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> new file mode 100644
> index 000000000000..72e81bbbef43
> --- /dev/null
> +++ b/Documentation/trace/coresight/coresight-etm4x-reference.txt
> @@ -0,0 +1,459 @@
> +ETMv4 sysfs linux driver programming reference - v2.
> +====================================================
> +
> +Supplement to existing ETMv4 driver documentation.
> +
> +Sysfs files and directories
> +---------------------------
> +
> +Root: /sys/bus/coresight/devices/etm<N>
> +
> +
> +The following paragraphs explain the association between sysfs files and the
> +ETMv4 registers that they effect. Note the register names are given without
> +the ‘TRC’ prefix.
> +
> +File : mode (rw)
> +Trace Registers : {CONFIGR + others}
> +Notes : Bit select trace features. See ‘mode’ section below. Bits
> + in this will cause equivalent programming of trace config and
> + other registers to enable the features requested.
> +Syntax & eg : 'echo bitfield > mode'
> + bitfield up to 32 bits setting trace features.
> +Example : $> echo 0x > mode
> +
> +File : reset (wo)
> +Trace Registers : All
> +Notes : Reset all programming to trace nothing / no logic programmed.
> +Syntax : 'echo 1 > reset'
> +
> +File : enable_source (wo)
> +Trace Registers : PRGCTLR, All hardware regs.
> +Notes : >0: Programs up the hardware with the current values held in
> + the driver and enables trace.
> + 0: disable trace hardware.
> +Syntax : 'echo 1 > enable_source'
> +
> +File : cpu (ro)
> +Trace Registers : None.
> +Notes : CPU ID that this ETM is attached to.
> +Example :$> cat cpu
> + $> 0
> +
> +File : addr_idx (rw)
> +Trace Registers : None.
> +Notes : Virtual register to index address comparator and range
> + features. Set index for first of the pair in a range.
> +Syntax : 'echo idx > addr_idx'
> + Where idx < nr_addr_cmp x 2
> +
> +File : addr_range (rw)
> +Trace Registers : ACVR[idx, idx+1], VIIECTLR
> +Notes : Pair of addresses for a range selected by addr_idx. Include
> + / exclude according to the optional parameter, or if omitted
> + uses the current ‘mode’ setting. Select comparator range in
> + control register. Error if index is odd value.
> +Depends : mode, addr_idx
> +Syntax : 'echo addr1 addr2 [exclude] > addr_range'
> + Where addr1 and addr2 define the range and addr1 < addr2.
> + Optional exclude value - 0 for include, 1 for exclude.
> +Example : $> echo 0x0000 0x2000 0 > addr_range
> +
> +File : addr_single (rw)
> +Trace Registers : ACVR[idx]
> +Notes : Set a single address comparator according to addr_idx. This
> + is used if the address comparator is used as part of event
> + generation logic etc.
> +Depends : addr_idx
> +Syntax : 'echo addr1 > addr_single'
> +
> +File : addr_start (rw)
> +Trace Registers : ACVR[idx], VISSCTLR
> +Notes : Set a trace start address comparator according to addr_idx.
> + Select comparator in control register.
> +Depends : addr_idx
> +Syntax : 'echo addr1 > addr_start'
> +
> +File : addr_stop (rw)
> +Trace Registers : ACVR[idx], VISSCTLR
> +Notes : Set a trace stop address comparator according to addr_idx.
> + Select comparator in control register.
> +Depends : addr_idx
> +Syntax : 'echo addr1 > addr_stop'
> +
> +File : addr_context (rw)
> +Trace Registers : ACATR[idx,{6:4}]
> +Notes : Link context ID comparator to address comparator addr_idx
> +Depends : addr_idx.
> +Syntax : 'echo ctxt_idx > addr_context'
> + Where ctxt_idx is the index of the linked context id / vmid
> + comparator.
> +
> +File : addr_ctxtype (rw)
> +Trace Registers : ACATR[idx,{3:2}]
> +Notes : Input value string. Set type for linked context ID comparator
> +Depends : addr_idx
> +Syntax : 'echo type > addr_ctxtype'
> + Type one of {all, vmid, ctxid, none}
> +Example : $> echo ctxid > addr_ctxtype
> +
> +File : addr_exlevel_s_ns (rw)
> +Trace Registers : ACATR[idx,{14:8}]
> +Notes : Set the ELx secure and non-secure matching bits for the
> + selected address comparator
> +Depends : addr_idx
> +Syntax : 'echo val > addr_exlevel_s_ns'
> + val is a 7 bit value for exception levels to exclude. Input
> + value shifted to correct bits in register.
> +Example : $> echo 0x4F > addr_exlevel_s_ns
> +
> +File : addr_instdatatype (rw)
> +Trace Registers : ACATR[idx,{1:0}]
> +Notes : Set the comparator address type for matching. Driver only
> + supports setting instruction address type.
> +Depends : addr_idx
> +
> +File : addr_cmp_view (ro)
> +Trace Registers : ACVR[idx, idx+1], ACATR[idx], VIIECTLR
> +Notes : Read the currently selected address comparator. If part of
> + address range then display both addresses.
> +Depends : addr_idx
> +Syntax : 'cat addr_cmp_view'
> +Example : $> cat addr_cmp_view
> + addr_cmp[0] range 0x0 0xffffffffffffffff include ctrl(0x4b00)
> +
> +File : nr_addr_cmp (ro)
> +Trace Registers : From IDR4
> +Notes : Number of address comparator pairs
> +
> +File : sshot_idx (rw)
> +Trace Registers : None
> +Notes : Select single shot register set.
> +
> +File : sshot_ctrl (rw)
> +Trace Registers : SSCCR[idx]
> +Notes : Access a single shot comparator control register.
> +Depends : sshot_idx
> +Syntax : 'echo val > sshot_ctrl'
> + Writes val into the selected control register.
> +
> +File : sshot_status (ro)
> +Trace Registers : SSCSR[idx]
> +Notes : Read a single shot comparator status register
> +Depends : sshot_idx
> +Syntax : 'cat sshot_status'
> + Read status.
> +Example : $> cat sshot_status
> + 0x1
> +
> +File : sshot_pe_ctrl (rw)
> +Trace Registers : SSPCICR[idx]
> +Notes : Access a single shot PE comparator input control register.
> +Depends : sshot_idx
> +Syntax : echo val > sshot_pe_ctrl
> + Writes val into the selected control register.
> +
> +File : ns_exlevel_vinst (rw)
> +Trace Registers : VICTLR{23:20}
> +Notes : Program non-secure exception level filters. Set / clear NS
> + exception filter bits. Setting ‘1’ excludes trace from the
> + exception level.
> +Syntax : 'echo bitfield > ns_exlevel_viinst'
> + Where bitfield contains bits to set clear for EL0 to EL2
> +Example : %> echo 0x4 > ns_exlevel_viinst
> + ; Exclude EL2 NS trace.
> +
> +File : vinst_pe_cmp_start_stop (rw)
> +Trace Registers : VIPCSSCTLR
> +Notes : Access PE start stop comparator input control registers
> +
> +File : bb_ctrl (rw)
> +Trace Registers : BBCTLR
> +Notes : Define ranges that Branch Broadcast will operate in.
> + Default (0x0) is all addresses.
> +Depends : BB enabled.
> +
> +File : cyc_threshold (rw)
> +Trace Registers : CCCTLR
> +Notes : Set the threshold for which cycle counts will be emitted.
> + Error if attempt to set below minimum defined in IDR3, masked
> + to width of valid bits.
> +Depends : CC enabled.
> +
> +File : syncfreq (rw)
> +Trace Registers : SYNCPR
> +Notes : Set trace synchronisation period. Power of 2 value, 0 (off)
> + or 8-20. Driver defaults to 12 (every 4096 bytes).
> +
> +File : cntr_idx (rw)
> +Trace Registers : none
> +Notes : Select the counter to access
> +Syntax : 'echo idx > cntr_idx'
> + Where idx < nr_cntr
> +
> +File : cntr_ctrl (rw)
> +Trace Registers : CNTCTLR[idx]
> +Notes : Set counter control value
> +Depends : cntr_idx
> +Syntax : 'echo val > cntr_ctrl'
> + Where val is per ETMv4 spec.
> +
> +File : cntrldvr (rw)
> +Trace Registers : CNTRLDVR[idx]
> +Notes : Set counter reload value
> +Depends : cntr_idx
> +Syntax : 'echo val > cntrldvr'
> + Where val is per ETMv4 spec.
> +
> +File : nr_cntr (ro)
> +Trace Registers : From IDR5
> +Notes : Number of counters implemented.
> +
> +File : ctxid_idx (rw)
> +Trace Registers : None
> +Notes : Select the context ID comparator to access
> +Syntax : 'echo idx > ctxid_idx'
> + Where idx < numcidc
> +
> +File : ctxid_pid (rw)
> +Trace Registers : CIDCVR[idx]
> +Notes : Set the context ID comparator value
> +Depends : ctxid_idx
> +
> +File : ctxid_masks (rw)
> +Trace Registers : CIDCCTLR0, CIDCCTLR1, CIDCVR<0-7>
> +Notes : Pair of values to set the byte masks for 1-8 context ID
> + comparators. Automatically clears masked bytes to 0 in CID
> + value registers.
> +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > ctxid_masks'
> + 32 bit values made up of mask bytes, where mN represents a
> + byte mask value for Ctxt ID comparator N.
> + Second value not required on systems that have fewer than 4
> + context ID comparators
> +
> +File : numcidc (ro)
> +Trace Registers : From IDR4
> +Notes : Number of Context ID comparators
> +
> +File : vmid_idx (rw)
> +Trace Registers : None
> +Notes : Select the VM ID comparator to access.
> +Syntax : 'echo idx > vmid_idx'
> + Where idx < numvmidc
> +
> +File : vmid_val (rw)
> +Trace Registers : VMIDCVR[idx]
> +Notes : Set the VM ID comparator value
> +Depends : vmid_idx
> +
> +File : vmid_masks (rw)
> +Trace Registers : VMIDCCTLR0, VMIDCCTLR1, VMIDCVR<0-7>
> +Notes : Pair of values to set the byte masks for 1-8 VM ID
> + comparators. Automatically clears masked bytes to 0 in VMID
> + value registers.
> +Syntax : 'echo m3m2m1m0 [m7m6m5m4] > vmid_masks'
> + Where mN represents a byte mask value for VMID comparator N.
> + Second value not required on systems that have fewer than
> + 4 VMID comparators.
> +
> +File : numvmidc (ro)
> +Trace Registers : From IDR4
> +Notes : Number of VMID comparators
> +
> +File : res_idx (rw)
> +Trace Registers : None.
> +Notes : Select the resource selector control to access. Must be 2 or
> + higher as selectors 0 and 1 are hardwired.
> +Syntax : 'echo idx > res_idx'
> + Where 2 <= idx < nr_resource x 2
> +
> +File : res_ctrl (rw)
> +Trace Registers : RSCTLR[idx]
> +Notes : Set resource selector control value. Value per ETMv4 spec.
> +Depends : res_idx
> +Syntax : 'echo val > res_cntr'
> + Where val is per ETMv4 spec.
> +
> +File : nr_resource (ro)
> +Trace Registers : From IDR4
> +Notes : Number of resource selector pairs
> +
> +File : event (rw)
> +Trace Registers : EVENTCTRL0R
> +Notes : Set up to 4 implemented event fields.
> +Syntax : 'echo ev3ev2ev1ev0 > event'
> + Where evN is an 8 bit event field. Up to 4 event fields make up
> + the 32bit input value. Number of valid fields implementation
> + dependent defined in IDR0.
> +
> +File : event_instren (rw)
> +Trace Registers : EVENTCTRL1R
> +Notes : Choose events which insert event packets into trace stream.
> +Depends : EVENTCTRL0R
> +Syntax : 'echo bitfield > event_instren'
> + Where bitfield is up to 4 bits according to number of event
> + fields.
> +
> +File : event_ts (rw)
> +Trace Registers : TSCTLR
> +Notes : Set the event that will generate timestamp requests.
> +Depends : TS activated
> +Syntax : 'echo evfield > event_ts'
> + Where evfield is an 8 bit event selector.
> +
> +File : seq_idx (rw)
> +Trace Registers : None
> +Notes : Sequencer event register select - 0 to 2
> +
> +
> +File : seq_state (rw)
> +Trace Registers : SEQSTR
> +Notes : Sequencer current state - 0 to 3.
> +
> +File : seq_event (rw)
> +Trace Registers : SEQEVR[idx]
> +Notes : State transition event registers
> +Depends : seq_idx
> +Syntax : 'echo evBevF > seq_event'
> + Where evBevF is a 16 bit value made up of two event selectors,
> + evB - back, evF - forwards.
> +
> +File : seq_reset_event (rw)
> +Trace Registers : SEQRSTEVR
> +Notes : Sequencer reset event
> +Syntax : 'echo evfield > seq_reset_event'
> + Where evfield is an 8 bit event selector.
> +
> +File : nrseqstate (ro)
> +Trace Registers : From IDR5
> +Notes : Number of sequencer states (0 or 4)
> +
> +File : nr_pe_cmp (ro)
> +Trace Registers : From IDR4
> +Notes : Number of PE comparator inputs
> +
> +File : nr_ext_inp (ro)
> +Trace Registers : From IDR5
> +Notes : Number of external inputs
> +
> +File : nr_ss_cmp (ro)
> +Trace Registers : From IDR4
> +Notes : Number of Single Shot control registers
> +
> +Note: When programming any address comparator the driver will tag the
> +comparator with a type used - i.e. RANGE, SINGLE, START, STOP. Once this tag
> +is set, then only the values can be changed using the same sysfs file / type
> +used to program it.
> +
> +Thus:-
> +% echo 0 > addr_idx ; select address comparator 0
> +% echo 0x1000 0x5000 0 > addr_range ; set address range on comparators 0 and 1.
> +% echo 0x2000 > addr_start ; this will error as comparator 0 is a
> + ; range comparator
> +% echo 2 > addr_idx ; select address comparator 2
> +% echo 0x2000 > addr_start ; this is OK as comparator 2 is unused,
> +% echo 0x3000 > addr_stop ; this will error as comparator 2 a start
> + ; address comparator
> +% echo 2 > addr_idx ; select address comparator 3
> +% echo 0x3000 > addr_stop ; this is OK
> +
> +To remove programming on all the comparators (and all the other hardware) use
> +the reset parameter:
> +
> +% echo 1 > reset
> +
> +The ‘mode’ sysfs parameter.
> +---------------------------
> +
> +This is a bitfield selection parameter that sets the overall trace mode for the
> +ETM. The table below describes the bits, using the defines from the driver
> +source file, along with a description of the feature these represent. Many
> +features are optional and therefore dependent on implementation in the
> +hardware.
> +
> +Bit assignements shown below:-
> +
> +bit (0) : #define ETM_MODE_EXCLUDE
> +description : This is the default value for the include / exclude function when
> + setting address ranges. Set 1 for exclude range. When the mode
> + parameter is set this value is applied to the currently indexed
> + address range.
> +
> +bit (4) : #define ETM_MODE_BB
> +description : Set to enable branch broadcast if supported in hardware [IDR0].
> +
> +bit (5) : #define ETMv4_MODE_CYCACC
> +description : Set to enable cycle accurate trace if supported [IDR0].
> +
> +bit (6) : ETMv4_MODE_CTXID
> +description : Set to enable context ID tracing if supported in hardware [IDR2].
> +
> +bit (7) : ETM_MODE_VMID
> +description : Set to enable virtual machine ID tracing if supported [IDR2].
> +
> +bit (11) : ETMv4_MODE_TIMESTAMP
> +description : Set to enable timestamp generation if supported [IDR0].
> +
> +bit (12) : ETM_MODE_RETURNSTACK
> +description : Set to enable trace return stack use if supported [IDR0].
> +
> +bit (13-14) : ETM_MODE_QELEM(val)
> +description : ‘val’ determines level of Q element support enabled if
> + implemented by the ETM [IDR0]
> +
> +bit (19) : ETM_MODE_ATB_TRIGGER
> +description : Set to enable the ATBTRIGGER bit in the event control register
> + [EVENTCTLR1] if supported [IDR5].
> +
> +bit (20) : ETM_MODE_LPOVERRIDE
> +description : Set to enable the LPOVERRIDE bit in the event control register
> + [EVENTCTLR1], if supported [IDR5].
> +
> +bit (21) : ETM_MODE_ISTALL_EN
> +description : Set to enable the ISTALL bit in the stall control register
> + [STALLCTLR]
> +
> +bit (23) : ETM_MODE_INSTPRIO
> +description : Set to enable the INSTPRIORITY bit in the stall control register
> + [STALLCTLR] , if supported [IDR0].
> +
> +bit (24) : ETM_MODE_NOOVERFLOW
> +description : Set to enable the NOOVERFLOW bit in the stall control register
> + [STALLCTLR], if supported [IDR3].
> +
> +bit (25) : ETM_MODE_TRACE_RESET
> +description : Set to enable the TRCRESET bit in the viewinst control register
> + [VICTLR] , if supported [IDR3].
> +
> +bit (26) : ETM_MODE_TRACE_ERR
> +description : Set to enable the TRCCTRL bit in the viewinst control register
> + [VICTLR].
> +
> +bit (27) : ETM_MODE_VIEWINST_STARTSTOP
> +description : Set the initial state value of the ViewInst start / stop logic
> + in the viewinst control register [VICTLR]
> +
> +bit (30) : ETM_MODE_EXCL_KERN
> +description : Set default trace setup to exclude kernel mode trace (see note a)
> +
> +bit (31) : ETM_MODE_EXCL_USER
> +description : Set default trace setup to exclude user space trace (see note a)
> +
> +Note a) On startup the ETM is programmed to trace the complete address space
> +using address range comparator 0. ‘mode’ bits 30 / 31 modify this setting to
> +set EL exclude bits for NS state in either user space (EL0) or kernel space
> +(EL1) in the address range comparator. (the default setting excludes all
> +secure EL, and NS EL2)
> +
> +Once the reset parameter has been used, and/or custom programming has been
> +implemented - using these bits will result in the EL bits for address
> +comparator 0 being set in the same way.
> +
> +Note b) Bits 2-3, 8-10, 15-16, 18, 22, control features that only work with
> +data trace. As A profile data trace is architecturally prohibited in ETMv4,
> +these have been omitted here. Possible uses could be where a kernel has
> +support for control of R or M profile infrastructure as part of a heterogeneous
> +system.
> +
> +Bits 17, 28-29 are unused.
> +
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight/coresight.txt
> similarity index 100%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight/coresight.txt
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 783569e3c4b4..777b77fde29b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1582,8 +1582,7 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: drivers/hwtracing/coresight/*
> -F: Documentation/trace/coresight.txt
> -F: Documentation/trace/coresight-cpu-debug.txt
> +F: Documentation/trace/coresight/*
> F: Documentation/devicetree/bindings/arm/coresight.txt
> F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
> F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] coresight: etm4x: Add missing single-shot control API to sysfs
From: Mathieu Poirier @ 2019-08-27 22:27 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190819205720.24457-8-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:19PM +0100, Mike Leach wrote:
> An API to control single-shot comparator operation was missing from sysfs.
> This adds the parameters to sysfs to allow programming of this feature.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 122 ++++++++++++++++++
> drivers/hwtracing/coresight/coresight-etm4x.c | 26 +++-
> drivers/hwtracing/coresight/coresight-etm4x.h | 3 +
> 3 files changed, 150 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 483976074779..7c019dda1236 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -239,6 +239,7 @@ static ssize_t reset_store(struct device *dev,
> for (i = 0; i < drvdata->nr_resource; i++)
> config->res_ctrl[i] = 0x0;
>
> + config->ss_idx = 0x0;
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> config->ss_ctrl[i] = 0x0;
> config->ss_pe_cmp[i] = 0x0;
> @@ -1713,6 +1714,123 @@ static ssize_t res_ctrl_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(res_ctrl);
>
> +static ssize_t sshot_idx_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + val = config->ss_idx;
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t sshot_idx_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> + if (val >= drvdata->nr_ss_cmp)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + config->ss_idx = val;
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(sshot_idx);
> +
> +static ssize_t sshot_ctrl_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + val = config->ss_ctrl[config->ss_idx];
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t sshot_ctrl_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->ss_idx;
> + config->ss_ctrl[idx] = val & GENMASK(24, 0);
> + /* must clear bit 31 in related status register on programming */
> + config->ss_status[idx] &= ~BIT(31);
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(sshot_ctrl);
> +
> +static ssize_t sshot_status_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + val = config->ss_status[config->ss_idx];
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +static DEVICE_ATTR_RO(sshot_status);
> +
> +static ssize_t sshot_pe_ctrl_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + spin_lock(&drvdata->spinlock);
> + val = config->ss_pe_cmp[config->ss_idx];
> + spin_unlock(&drvdata->spinlock);
> + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t sshot_pe_ctrl_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t size)
> +{
> + u8 idx;
> + unsigned long val;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> +
> + if (kstrtoul(buf, 16, &val))
> + return -EINVAL;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->ss_idx;
> + config->ss_ctrl[idx] = val & GENMASK(7, 0);
config->ss_pe_cmp[idx] = val & GENMASK(7, 0);
> + /* must clear bit 31 in related status register on programming */
> + config->ss_status[idx] &= ~BIT(31);
> + spin_unlock(&drvdata->spinlock);
> + return size;
> +}
> +static DEVICE_ATTR_RW(sshot_pe_ctrl);
> +
> static ssize_t ctxid_idx_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -2169,6 +2287,10 @@ static struct attribute *coresight_etmv4_attrs[] = {
> &dev_attr_addr_exlevel_s_ns.attr,
> &dev_attr_addr_cmp_view.attr,
> &dev_attr_vinst_pe_cmp_start_stop.attr,
> + &dev_attr_sshot_idx.attr,
> + &dev_attr_sshot_ctrl.attr,
> + &dev_attr_sshot_pe_ctrl.attr,
> + &dev_attr_sshot_status.attr,
> &dev_attr_seq_idx.attr,
> &dev_attr_seq_state.attr,
> &dev_attr_seq_event.attr,
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index d8b078d0cc7f..fb7083218410 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -149,6 +149,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> drvdata->base + TRCRSCTLRn(i));
>
> for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> + /* always clear status bit on restart if using single-shot */
> + if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
> + config->ss_status[i] &= ~BIT(31);
> writel_relaxed(config->ss_ctrl[i],
> drvdata->base + TRCSSCCRn(i));
> writel_relaxed(config->ss_status[i],
> @@ -448,6 +451,9 @@ static void etm4_disable_hw(void *info)
> {
> u32 control;
> struct etmv4_drvdata *drvdata = info;
> + struct etmv4_config *config = &drvdata->config;
> + struct device *etm_dev = &drvdata->csdev->dev;
> + int i;
>
> CS_UNLOCK(drvdata->base);
>
> @@ -470,6 +476,18 @@ static void etm4_disable_hw(void *info)
> isb();
> writel_relaxed(control, drvdata->base + TRCPRGCTLR);
>
> + /* wait for TRCSTATR.PMSTABLE to go to '1' */
> + if (coresight_timeout(drvdata->base, TRCSTATR,
> + TRCSTATR_PMSTABLE_BIT, 1))
> + dev_err(etm_dev,
> + "timeout while waiting for PM stable Trace Status\n");
> +
> + /* read the status of the single shot comparators */
> + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> + config->ss_status[i] =
> + readl_relaxed(drvdata->base + TRCSSCSRn(i));
> + }
> +
> coresight_disclaim_device_unlocked(drvdata->base);
>
> CS_LOCK(drvdata->base);
> @@ -576,6 +594,7 @@ static void etm4_init_arch_data(void *info)
> u32 etmidr4;
> u32 etmidr5;
> struct etmv4_drvdata *drvdata = info;
> + int i;
>
> /* Make sure all registers are accessible */
> etm4_os_unlock(drvdata);
> @@ -699,9 +718,14 @@ static void etm4_init_arch_data(void *info)
> drvdata->nr_resource = BMVAL(etmidr4, 16, 19) + 1;
> /*
> * NUMSSCC, bits[23:20] the number of single-shot
> - * comparator control for tracing
> + * comparator control for tracing. Read any status regs as these
> + * also contain RO capability data.
> */
> drvdata->nr_ss_cmp = BMVAL(etmidr4, 20, 23);
> + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> + drvdata->config.ss_status[i] =
> + readl_relaxed(drvdata->base + TRCSSCSRn(i));
> + }
> /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> drvdata->numcidc = BMVAL(etmidr4, 24, 27);
> /* NUMVMIDC, bits[31:28] number of VMID comparators for tracing */
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> index 60bc2fb5159b..be8b32ea1654 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> @@ -175,6 +175,7 @@
> ETM_MODE_EXCL_USER)
>
> #define TRCSTATR_IDLE_BIT 0
> +#define TRCSTATR_PMSTABLE_BIT 1
> #define ETM_DEFAULT_ADDR_COMP 0
>
> /* PowerDown Control Register bits */
> @@ -226,6 +227,7 @@
> * @cntr_val: Sets or returns the value for a counter.
> * @res_idx: Resource index selector.
> * @res_ctrl: Controls the selection of the resources in the trace unit.
> + * @ss_idx: Single-shot index selector.
> * @ss_ctrl: Controls the corresponding single-shot comparator resource.
> * @ss_status: The status of the corresponding single-shot comparator.
> * @ss_pe_cmp: Selects the PE comparator inputs for Single-shot control.
> @@ -269,6 +271,7 @@ struct etmv4_config {
> u32 cntr_val[ETMv4_MAX_CNTR];
> u8 res_idx;
> u32 res_ctrl[ETM_MAX_RES_SEL];
> + u8 ss_idx;
> u32 ss_ctrl[ETM_MAX_SS_CMP];
> u32 ss_status[ETM_MAX_SS_CMP];
> u32 ss_pe_cmp[ETM_MAX_SS_CMP];
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v2 1/2] dt-bindings: usb: mtk-xhci: add an optional xhci_ck clock
From: Rob Herring @ 2019-08-27 22:27 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland, devicetree, Mathias Nyman, Ian Campbell,
Greg Kroah-Hartman, linux-usb, linux-kernel, Chunfeng Yun,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1566542425-20082-1-git-send-email-chunfeng.yun@mediatek.com>
On Fri, 23 Aug 2019 14:40:24 +0800, Chunfeng Yun wrote:
> Add a new optional clock xhci_ck
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2 changes:
> 1. add the new clock at the end, suggested by Rob
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/10] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a
From: Rob Herring @ 2019-08-27 22:26 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, devicetree,
gregkh, linuxppc-dev, linux-pci, linux-kernel, kishon,
minghuan.Lian, gustavo.pimentel, jingoohan1, bhelgaas,
andrew.murray, leoyang.li, shawnguo, mingkai.hu, linux-arm-kernel
In-Reply-To: <20190822112242.16309-4-xiaowei.bao@nxp.com>
On Thu, Aug 22, 2019 at 07:22:36PM +0800, Xiaowei Bao wrote:
> Add compatible strings for ls1088a and ls2088a.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v2:
> - No change.
>
> Documentation/devicetree/bindings/pci/layerscape-pci.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index e20ceaa..16f592e 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -22,7 +22,10 @@ Required properties:
> "fsl,ls1043a-pcie"
> "fsl,ls1012a-pcie"
> EP mode:
> - "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
> + "fsl,ls-pcie-ep"
Wasn't this a fallback? Each line should be one valid combination of
compatible strings.
> + "fsl,ls1046a-pcie-ep"
> + "fsl,ls1088a-pcie-ep"
> + "fsl,ls2088a-pcie-ep"
> - reg: base addresses and lengths of the PCIe controller register blocks.
> - interrupts: A list of interrupt outputs of the controller. Must contain an
> entry for each entry in the interrupt-names property.
> --
> 2.9.5
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 05/20] dt-bindings: phy-mmp3-usb: Add bindings
From: Rob Herring @ 2019-08-27 22:24 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, linux-kernel, Lubomir Rintel, Olof Johansson,
linux-clk, linux-arm-kernel
In-Reply-To: <20190822092643.593488-6-lkundrak@v3.sk>
On Thu, 22 Aug 2019 11:26:28 +0200, Lubomir Rintel wrote:
> This is the PHY chip for USB OTG on MMP3 platform.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - s/usbphy@/usb-phy@/
> - Dropped a reference to Documentation/phy.txt
>
> .../devicetree/bindings/phy/phy-mmp3-usb.txt | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-mmp3-usb.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/7] arm64: dts: meson: ir keymap updates
From: Kevin Hilman @ 2019-08-27 22:24 UTC (permalink / raw)
To: Martin Blumenstingl, Christian Hewitt
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
linux-amlogic, linux-arm-kernel
In-Reply-To: <CAFBinCD0uhE9Fj1we2MkaTbk7RwtmKh7Fn1C-2nn9wiWqCoNfg@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> On Sun, Aug 25, 2019 at 6:03 AM Christian Hewitt
> <christianshewitt@gmail.com> wrote:
>>
>> This series adds keymaps for several box/board vendor IR remote devices
>> to respective device-tree files. The keymaps were submitted in [0] and
>> have been queued for inclusion in Linux 5.4.
>>
>> The Khadas remote change swaps the rc-geekbox keymap for rc-khadas. The
>> Geekbox branded remote was only sold for a brief period when VIM(1) was
>> a new device. The Khadas branded remote that replaced it exchanged the
>> Geekbox full-screen key for an Android mouse button using a different IR
>> keycode. The rc-khadas keymap supports the mouse button keycode and maps
>> it to KEY_MUTE.
>>
>> [0] https://patchwork.kernel.org/project/linux-media/list/?series=160309
>>
>> Christian Hewitt (7):
>> arm64: dts: meson-g12b-odroid-n2: add rc-odroid keymap
>> arm64: dts: meson-g12a-x96-max: add rc-x96max keymap
>> arm64: dts: meson-gxbb-wetek-hub: add rc-wetek-hub keymap
>> arm64: dts: meson-gxbb-wetek-play2: add rc-wetek-play2 keymap
>> arm64: dts: meson-gxl-s905x-khadas-vim: use rc-khadas keymap
>> arm64: dts: meson-gxl-s905w-tx3-mini: add rc-tx3mini keymap
>> arm64: dts: meson-gxm-khadas-vim2: use rc-khadas keymap
>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Queued for v5.4 w/Martin's tag,
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/20] dt-bindings: mrvl,intc: Add a MMP3 interrupt controller
From: Rob Herring @ 2019-08-27 22:23 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, linux-kernel, Lubomir Rintel, Olof Johansson,
linux-clk, linux-arm-kernel
In-Reply-To: <20190822092643.593488-5-lkundrak@v3.sk>
On Thu, 22 Aug 2019 11:26:27 +0200, Lubomir Rintel wrote:
> Similar to MMP2 one, but has an extra range for the other core. The
> muxes stay the same.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Reformat the compatible property documentation to higlight the valid
> combinations
> - Drop an unneeded mmp3-intc example
>
> .../bindings/interrupt-controller/mrvl,intc.txt | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Bjorn Andersson @ 2019-08-27 22:23 UTC (permalink / raw)
To: Suman Anna
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <9c5f95a0-c95b-bf68-e78f-6e3d4d837b1e@ti.com>
On Tue 27 Aug 15:17 PDT 2019, Suman Anna wrote:
> On 8/27/19 5:15 PM, Suman Anna wrote:
> > On 8/27/19 5:07 PM, Bjorn Andersson wrote:
> >> On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
> >>
> >>> Hi Bjorn,
> >>>
> >>> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
> >>>> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
> >>>>
> >>>>> Hi Bjorn,
> >>>>>
> >>>>
> >>>> Hi Suman
> >>>>
> >>>>> On 10/23/18 8:19 PM, Suman Anna wrote:
> >>>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> >>>>>> printing the vring buffer address. This prints only a hashed
> >>>>>> pointer even for previliged users. Use "%pK" instead so that
> >>>>>> the address can be printed during debug using kptr_restrict
> >>>>>> sysctl.
> >>>>>
> >>>>> Seems to have been lost among the patches, can you pick up this trivial
> >>>>> patch for 5.4? Should apply cleanly on the latest HEAD as well.
> >>>>>
> >>>>
> >>>> I share Andrew's question regarding what benefit you have from knowing
> >>>> this value. Should we not just remove the va from the print? Or do you
> >>>> actually have a use case for it?.
> >>>
> >>> I mainly use it during debug when comparing against kernel_page_tables
> >>> and vmallocinfo. The pools that we use are not always guaranteed to be
> >>> from linear memory, and behavior changes when using with CMA or DMA pools.
> >>>
> >>
> >> Thanks Suman. It seems to me that there's room for improvement to aid
> >> this kind of debugging. But your usecase seems reasonable, so I'm
> >> merging the patch.
> >
> > Thanks Bjorn.
>
> Btw, looks like you applied the patch against rproc-next instead of
> rpmsg-next.
>
Thanks for noticing so quick; I moved the change to the correct
branch.
Regards,
Bjorn
> regards
> Suman
>
> >
> >>
> >>> Note that usage of %pK does not leak the addresses automatically, but
> >>> atleast enables me to get the values when needed. The changes also bring
> >>> the usage in rpmsg core in sync with the remoteproc core.
> >>>
> >>
> >> Sounds like shouldn't have merged them in remoteproc then ;P
> >
> > Slightly different reasoning looking at the commit, it was probably when
> > %p was leaking the addresses.
> >
> > regards
> > Suman
> >
> >>
> >> Thanks,
> >> Bjorn
> >>
> >>> regards
> >>> Suman
> >>>
> >>>>
> >>>> Regards,
> >>>> Bjorn
> >>>>
> >>>>> regards
> >>>>> Suman
> >>>>>
> >>>>>>
> >>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
> >>>>>> ---
> >>>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> >>>>>> index f29dee731026..1345f373a1a0 100644
> >>>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> >>>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> >>>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >>>>>> goto vqs_del;
> >>>>>> }
> >>>>>>
> >>>>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> >>>>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
> >>>>>> bufs_va, &vrp->bufs_dma);
> >>>>>>
> >>>>>> /* half of the buffers is dedicated for RX */
> >>>>>>
> >>>>>
> >>>
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] dt-bindings: net: dsa: mt7530: Add support for port 5
From: Rob Herring @ 2019-08-27 22:22 UTC (permalink / raw)
To: René van Dorst
Cc: Andrew Lunn, Florian Fainelli, Frank Wunderlich, netdev,
Sean Wang, linux-mips, David S . Miller, devicetree,
linux-mediatek, John Crispin, Matthias Brugger, Vivien Didelot,
linux-arm-kernel
In-Reply-To: <20190821144547.15113-3-opensource@vdorst.com>
On Wed, Aug 21, 2019 at 04:45:46PM +0200, René van Dorst wrote:
> MT7530 port 5 has many modes/configurations.
> Update the documentation how to use port 5.
>
> Signed-off-by: René van Dorst <opensource@vdorst.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> v1->v2:
> * Adding extra note about RGMII2 and gpio use.
> rfc->v1:
> * No change
The changelog goes below the '---'
> ---
> .../devicetree/bindings/net/dsa/mt7530.txt | 218 ++++++++++++++++++
> 1 file changed, 218 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> index 47aa205ee0bd..43993aae3f9c 100644
> --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> @@ -35,6 +35,42 @@ Required properties for the child nodes within ports container:
> - phy-mode: String, must be either "trgmii" or "rgmii" for port labeled
> "cpu".
>
> +Port 5 of the switch is muxed between:
> +1. GMAC5: GMAC5 can interface with another external MAC or PHY.
> +2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC
> + of the SOC. Used in many setups where port 0/4 becomes the WAN port.
> + Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to
> + GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not
> + connected to external component!
> +
> +Port 5 modes/configurations:
> +1. Port 5 is disabled and isolated: An external phy can interface to the 2nd
> + GMAC of the SOC.
> + In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd
> + GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC!
> +2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC.
> + It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode
> + and RGMII delay.
> +3. Port 5 is muxed to GMAC5 and can interface to an external phy.
> + Port 5 becomes an extra switch port.
> + Only works on platform where external phy TX<->RX lines are swapped.
> + Like in the Ubiquiti ER-X-SFP.
> +4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port.
> + Currently a 2nd CPU port is not supported by DSA code.
> +
> +Depending on how the external PHY is wired:
> +1. normal: The PHY can only connect to 2nd GMAC but not to the switch
> +2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
> + a ethernet port. But can't interface to the 2nd GMAC.
> +
> +Based on the DT the port 5 mode is configured.
> +
> +Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
> +When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
> +phy-mode must be set, see also example 2 below!
> + * mt7621: phy-mode = "rgmii-txid";
> + * mt7623: phy-mode = "rgmii";
> +
> See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required, optional properties and how the integrated switch subnodes must
> be specified.
> @@ -94,3 +130,185 @@ Example:
> };
> };
> };
> +
> +Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
> +
> +ð {
> + status = "okay";
Don't show status in examples.
This should show the complete node.
> +
> + gmac0: mac@0 {
> + compatible = "mediatek,eth-mac";
> + reg = <0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> +
> + gmac1: mac@1 {
> + compatible = "mediatek,eth-mac";
> + reg = <1>;
> + phy-mode = "rgmii-txid";
> + phy-handle = <&phy4>;
> + };
> +
> + mdio: mdio-bus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Internal phy */
> + phy4: ethernet-phy@4 {
> + reg = <4>;
> + };
> +
> + mt7530: switch@1f {
> + compatible = "mediatek,mt7621";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1f>;
> + pinctrl-names = "default";
> + mediatek,mcm;
> +
> + resets = <&rstctrl 2>;
> + reset-names = "mcm";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan0";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan3";
> + };
> +
> +/* Commented out. Port 4 is handled by 2nd GMAC.
> + port@4 {
> + reg = <4>;
> + label = "lan4";
> + };
> +*/
> +
> + cpu_port0: port@6 {
> + reg = <6>;
> + label = "cpu";
> + ethernet = <&gmac0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
> +
> +ð {
> + status = "okay";
> +
> + gmac0: mac@0 {
> + compatible = "mediatek,eth-mac";
> + reg = <0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> +
> + mdio: mdio-bus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* External phy */
> + ephy5: ethernet-phy@7 {
> + reg = <7>;
> + };
> +
> + mt7530: switch@1f {
> + compatible = "mediatek,mt7621";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1f>;
> + pinctrl-names = "default";
> + mediatek,mcm;
> +
> + resets = <&rstctrl 2>;
> + reset-names = "mcm";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan0";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan3";
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "lan4";
> + };
> +
> + port@5 {
> + reg = <5>;
> + label = "lan5";
> + phy-mode = "rgmii";
> + phy-handle = <&ephy5>;
> + };
> +
> + cpu_port0: port@6 {
> + reg = <6>;
> + label = "cpu";
> + ethernet = <&gmac0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> +};
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/5] arm64: meson: add support for SM1 Power Domains
From: Kevin Hilman @ 2019-08-27 22:21 UTC (permalink / raw)
To: Neil Armstrong, ulf.hansson
Cc: linux-amlogic, linux-pm, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190823090418.17148-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This patchset introduces a new "Everything-Else Power Domain Controller"
> designed to handle all the different non-Always On peripherals like :
> - VPU
> - Ethernet Memories
> - USB, PCIe, Audio, NNA on SM1
>
> The current "gx-vpu-pwrc" process has been integrated to support the VPU
> and the other power domains in a single driver.
>
> Support for SoC domains has been made generic and easily extendable.
>
> In order to restart from clean architecture :
> - the PWRC node has been moved into the HHI simple-mfd, this suits much
> better than beeing in the AO RTI simple-mfd
> - a brand new yaml bindings schemas has been written
> - reset-names has been added to clarify which resets are needed, so we can
> dispatch them to domains
>
> For G12A, the PWRC now offers support for the ethmac memory power domain.
>
> For SM1, it also offers support for PCIe, USB, NNA, ethmac and Audio power
> domains.
>
> The DOS domains has been excluded for now, but can be added very easily.
>
> GX hasn't been integrated for now, but it would follow the same scheme
> as G12A support.
>
> Changes since v1 at [1]:
> - removed open-coded reset & clock get, enable/assert, disable/deassert
> - moved to clk_bulk and reset_array with count check with a warning
> - removed remaining sm1_pwrc in probe
> - reordered arguments for VPU_PD and TOP_PD
> - added get_power for TOP_PD aswell
> - ported special VPU handling from gx-vpu-pwrc
> - added shutdown driver call to avoid errors on reboot
> - fixed patch 4 commit log
> - collected rob's review tag on patch 1
>
> [1] https://patchwork.kernel.org/cover/11106393/
Series queued for v5.4...
> Neil Armstrong (5):
> dt-bindings: power: add Amlogic Everything-Else power domains bindings
> soc: amlogic: Add support for Everything-Else power domains controller
These two in v5.4/drivers,
> arm64: meson-g12: add Everything-Else power domain controller
> arm64: dts: meson-sm1-sei610: add HDMI display support
> arm64: dts: meson-sm1-sei610: add USB support
and these 3 in v5.4/dt64,
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/5] soc: amlogic: Add support for Everything-Else power domains controller
From: Kevin Hilman @ 2019-08-27 22:20 UTC (permalink / raw)
To: Neil Armstrong, Martin Blumenstingl
Cc: linux-amlogic, ulf.hansson, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <25e60f94-9be1-76b0-147f-abdd2d01872f@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On 27/08/2019 00:40, Martin Blumenstingl wrote:
>> Hi Neil,
>>
>> On Mon, Aug 26, 2019 at 10:10 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>
>>> On 25/08/2019 23:10, Martin Blumenstingl wrote:
>>>> Hi Neil,
>>>>
>>>> thank you for this update
>>>> I haven't tried this on the 32-bit SoCs yet, but I am confident that I
>>>> can make it work by "just" adding the SoC specific bits!
>>>>
>>>> On Fri, Aug 23, 2019 at 11:06 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>> [...]
>>>>> +/* AO Offsets */
>>>>> +
>>>>> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
>>>>> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
>>>>> +
>>>>> +/* HHI Offsets */
>>>>> +
>>>>> +#define HHI_MEM_PD_REG0 (0x40 << 2)
>>>>> +#define HHI_VPU_MEM_PD_REG0 (0x41 << 2)
>>>>> +#define HHI_VPU_MEM_PD_REG1 (0x42 << 2)
>>>>> +#define HHI_VPU_MEM_PD_REG3 (0x43 << 2)
>>>>> +#define HHI_VPU_MEM_PD_REG4 (0x44 << 2)
>>>>> +#define HHI_AUDIO_MEM_PD_REG0 (0x45 << 2)
>>>>> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
>>>>> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
>>>>> +#define HHI_VPU_MEM_PD_REG2 (0x4d << 2)
>>>> should we switch to the actual register offsets like we did in the
>>>> clock drivers?
>>>
>>> I find it simpler to refer to the numbers in the documentation...
>> OK, I have no strong preference here
>> for the 32-bit SoCs I will need to use the offsets based on the
>> "amlogic,meson8b-pmu", "syscon" [0], so these will be magic anyways
>>
>> [...]
>>>>> +#define VPU_HHI_MEMPD(__reg) \
>>>>> + { __reg, BIT(8) }, \
>>>>> + { __reg, BIT(9) }, \
>>>>> + { __reg, BIT(10) }, \
>>>>> + { __reg, BIT(11) }, \
>>>>> + { __reg, BIT(12) }, \
>>>>> + { __reg, BIT(13) }, \
>>>>> + { __reg, BIT(14) }, \
>>>>> + { __reg, BIT(15) }
>>>> the Amlogic implementation from buildroot-openlinux-A113-201901 (the
>>>> latest one I have)
>>>> kernel/aml-4.9/drivers/amlogic/media/vout/hdmitx/hdmi_tx_20/hw/hdmi_tx_hw.c
>>>> uses:
>>>> hd_set_reg_bits(P_HHI_MEM_PD_REG0, 0, 8, 8)
>>>> that basically translates to: GENMASK(15, 8) (which means we could
>>>> drop this macro)
>>>>
>>>> the datasheet also states: 15~8 [...] HDMI memory PD (as a single
>>>> 8-bit wide register)
>>>
>>> Yep, but the actual code setting the VPU power domain is in u-boot :
>>>
>>> drivers/vpu/aml_vpu_power_init.c:
>>> 108 for (i = 8; i < 16; i++) {
>>> 109 vpu_hiu_setb(HHI_MEM_PD_REG0, 0, i, 1);
>>> 110 udelay(5);
>>> 111 }
>>>
>>> the linux code is like never used here, my preference goes to the u-boot code
>>> implementation.
>> I see, let's keep your implementation then
>>
>>>>
>>>> [...]
>>>>> +static struct meson_ee_pwrc_domain_desc g12a_pwrc_domains[] = {
>>>>> + [PWRC_G12A_VPU_ID] = VPU_PD("VPU", &g12a_pwrc_vpu, g12a_pwrc_mem_vpu,
>>>>> + pwrc_ee_get_power, 11, 2),
>>>>> + [PWRC_G12A_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
>>>>> +};
>>>>> +
>>>>> +static struct meson_ee_pwrc_domain_desc sm1_pwrc_domains[] = {
>>>>> + [PWRC_SM1_VPU_ID] = VPU_PD("VPU", &sm1_pwrc_vpu, sm1_pwrc_mem_vpu,
>>>>> + pwrc_ee_get_power, 11, 2),
>>>>> + [PWRC_SM1_NNA_ID] = TOP_PD("NNA", &sm1_pwrc_nna, sm1_pwrc_mem_nna,
>>>>> + pwrc_ee_get_power),
>>>>> + [PWRC_SM1_USB_ID] = TOP_PD("USB", &sm1_pwrc_usb, sm1_pwrc_mem_usb,
>>>>> + pwrc_ee_get_power),
>>>>> + [PWRC_SM1_PCIE_ID] = TOP_PD("PCI", &sm1_pwrc_pci, sm1_pwrc_mem_pcie,
>>>>> + pwrc_ee_get_power),
>>>>> + [PWRC_SM1_GE2D_ID] = TOP_PD("GE2D", &sm1_pwrc_ge2d, sm1_pwrc_mem_ge2d,
>>>>> + pwrc_ee_get_power),
>>>>> + [PWRC_SM1_AUDIO_ID] = MEM_PD("AUDIO", sm1_pwrc_mem_audio),
>>>>> + [PWRC_SM1_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
>>>>> +};
>>>> my impression: I find this hard to read as it merges the TOP and
>>>> Memory PD domains from above, adding some seemingly random "11, 2" for
>>>> the VPU PD as well as pwrc_ee_get_power for some of the power domains
>>>> personally I like the way we describe clk_regmap because it's easy to
>>>> read (even though it adds a bit of boilerplate). I'm not sure if we
>>>> can make it work here, but this (not compile tested) is what I have in
>>>> mind (I chose two random power domains):
>>>> [PWRC_SM1_VPU_ID] = {
>>>> .name = "VPU",
>>>> .top_pd = SM1_EE_PD(8),
>>>> .mem_pds = {
>>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG0),
>>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG1),
>>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG2),
>>>> VPU_MEMPD(HHI_VPU_MEM_PD_REG3),
>>>> { HHI_VPU_MEM_PD_REG4, GENMASK(1, 0) },
>>>> { HHI_VPU_MEM_PD_REG4, GENMASK(3, 2) },
>>>> { HHI_VPU_MEM_PD_REG4, GENMASK(5, 4) },
>>>> { HHI_VPU_MEM_PD_REG4, GENMASK(7, 6) },
>>>> { HHI_MEM_PD_REG0, GENMASK(15, 8) },
>>>> },
>>>> .num_mem_pds = 9,
>>>> .reset_names_count = 11,
>>>> .clk_names_count = 2,
>>>> },
>>>> [PWRC_SM1_ETH_ID] = {
>>>> .name = "ETH",
>>>> .mem_pds = { HHI_MEM_PD_REG0, GENMASK(3, 2) },
>>>> .num_mem_pds = 1,
>>>> },
>>>> ...
>>>>
>>>> I'd like to get Kevin's feedback on this
>>>> what you have right now is probably good enough for the initial
>>>> version of this driver. I'm bringing this discussion up because we
>>>> will add support for more SoCs to this driver (we migrate GX over to
>>>> it and I want to add 32-bit SoC support, which probably means at least
>>>> Meson8 - assuming they kept the power domains identical between
>>>> Meson8/8b/8m2).
>>>
>>> I find it more compact, but nothing is set in stone, you can refactor this as
>>> will when adding meson8 support, no problems here.
>> OK. if Kevin (or someone else) has feedback on this then I don't have
>> to waste time if it turns out that it's not a great idea ;)
>>
>>>>
>>>> [...]
>>>>> +struct meson_ee_pwrc_domain {
>>>>> + struct generic_pm_domain base;
>>>>> + bool enabled;
>>>>> + struct meson_ee_pwrc *pwrc;
>>>>> + struct meson_ee_pwrc_domain_desc desc;
>>>>> + struct clk_bulk_data *clks;
>>>>> + int num_clks;
>>>>> + struct reset_control *rstc;
>>>>> + int num_rstc;
>>>>> +};
>>>>> +
>>>>> +struct meson_ee_pwrc {
>>>>> + struct regmap *regmap_ao;
>>>>> + struct regmap *regmap_hhi;
>>>>> + struct meson_ee_pwrc_domain *domains;
>>>>> + struct genpd_onecell_data xlate;
>>>>> +};
>>>> (my impressions on this: I was surprised to find more structs down
>>>> here, I expected them to be together with the other structs further
>>>> up)
>>>
>>> These are the "live" structures, opposed to the static structures defining the
>>> data and these are allocated and filled a probe time.
>> I see, thanks for the explanation
>>
>>> I dislike changing static global data at runtime, this is why I clearly separated both.
>> I didn't mean to make them static - the thing that caught my eye was
>> that some of the structs are defined at the top of the driver while
>> these two are define much further down
>> I am used to having all struct definitions in one place
>
> I'll let Kevin leave his feedback on this aswell.
I don't find the current approach super easy to read either, but OTOH, I
don't have any (good) ideas for doing it better, so I'm fine with the
current approach.
My primay wish is to have a single domain controller for all the EE
domains, which this series provides well. We can iterate on cleanups as
we expand to other SoCs.
Unless there are major objections, I plan to queue this for v5.4.
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Suman Anna @ 2019-08-27 22:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <619b06b0-c3cc-e36f-c3e5-d13e98520c9c@ti.com>
On 8/27/19 5:15 PM, Suman Anna wrote:
> On 8/27/19 5:07 PM, Bjorn Andersson wrote:
>> On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
>>
>>> Hi Bjorn,
>>>
>>> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
>>>> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
>>>>
>>>>> Hi Bjorn,
>>>>>
>>>>
>>>> Hi Suman
>>>>
>>>>> On 10/23/18 8:19 PM, Suman Anna wrote:
>>>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>>>>> printing the vring buffer address. This prints only a hashed
>>>>>> pointer even for previliged users. Use "%pK" instead so that
>>>>>> the address can be printed during debug using kptr_restrict
>>>>>> sysctl.
>>>>>
>>>>> Seems to have been lost among the patches, can you pick up this trivial
>>>>> patch for 5.4? Should apply cleanly on the latest HEAD as well.
>>>>>
>>>>
>>>> I share Andrew's question regarding what benefit you have from knowing
>>>> this value. Should we not just remove the va from the print? Or do you
>>>> actually have a use case for it?.
>>>
>>> I mainly use it during debug when comparing against kernel_page_tables
>>> and vmallocinfo. The pools that we use are not always guaranteed to be
>>> from linear memory, and behavior changes when using with CMA or DMA pools.
>>>
>>
>> Thanks Suman. It seems to me that there's room for improvement to aid
>> this kind of debugging. But your usecase seems reasonable, so I'm
>> merging the patch.
>
> Thanks Bjorn.
Btw, looks like you applied the patch against rproc-next instead of
rpmsg-next.
regards
Suman
>
>>
>>> Note that usage of %pK does not leak the addresses automatically, but
>>> atleast enables me to get the values when needed. The changes also bring
>>> the usage in rpmsg core in sync with the remoteproc core.
>>>
>>
>> Sounds like shouldn't have merged them in remoteproc then ;P
>
> Slightly different reasoning looking at the commit, it was probably when
> %p was leaking the addresses.
>
> regards
> Suman
>
>>
>> Thanks,
>> Bjorn
>>
>>> regards
>>> Suman
>>>
>>>>
>>>> Regards,
>>>> Bjorn
>>>>
>>>>> regards
>>>>> Suman
>>>>>
>>>>>>
>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>>> ---
>>>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>>> index f29dee731026..1345f373a1a0 100644
>>>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>>>> goto vqs_del;
>>>>>> }
>>>>>>
>>>>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>>>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>>>>> bufs_va, &vrp->bufs_dma);
>>>>>>
>>>>>> /* half of the buffers is dedicated for RX */
>>>>>>
>>>>>
>>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Suman Anna @ 2019-08-27 22:15 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <20190827220711.GK6167@minitux>
On 8/27/19 5:07 PM, Bjorn Andersson wrote:
> On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
>
>> Hi Bjorn,
>>
>> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
>>> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
>>>
>>>> Hi Bjorn,
>>>>
>>>
>>> Hi Suman
>>>
>>>> On 10/23/18 8:19 PM, Suman Anna wrote:
>>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>>>> printing the vring buffer address. This prints only a hashed
>>>>> pointer even for previliged users. Use "%pK" instead so that
>>>>> the address can be printed during debug using kptr_restrict
>>>>> sysctl.
>>>>
>>>> Seems to have been lost among the patches, can you pick up this trivial
>>>> patch for 5.4? Should apply cleanly on the latest HEAD as well.
>>>>
>>>
>>> I share Andrew's question regarding what benefit you have from knowing
>>> this value. Should we not just remove the va from the print? Or do you
>>> actually have a use case for it?.
>>
>> I mainly use it during debug when comparing against kernel_page_tables
>> and vmallocinfo. The pools that we use are not always guaranteed to be
>> from linear memory, and behavior changes when using with CMA or DMA pools.
>>
>
> Thanks Suman. It seems to me that there's room for improvement to aid
> this kind of debugging. But your usecase seems reasonable, so I'm
> merging the patch.
Thanks Bjorn.
>
>> Note that usage of %pK does not leak the addresses automatically, but
>> atleast enables me to get the values when needed. The changes also bring
>> the usage in rpmsg core in sync with the remoteproc core.
>>
>
> Sounds like shouldn't have merged them in remoteproc then ;P
Slightly different reasoning looking at the commit, it was probably when
%p was leaking the addresses.
regards
Suman
>
> Thanks,
> Bjorn
>
>> regards
>> Suman
>>
>>>
>>> Regards,
>>> Bjorn
>>>
>>>> regards
>>>> Suman
>>>>
>>>>>
>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>> ---
>>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>> index f29dee731026..1345f373a1a0 100644
>>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>>> goto vqs_del;
>>>>> }
>>>>>
>>>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>>>> bufs_va, &vrp->bufs_dma);
>>>>>
>>>>> /* half of the buffers is dedicated for RX */
>>>>>
>>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Bjorn Andersson @ 2019-08-27 22:07 UTC (permalink / raw)
To: Suman Anna
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <8d36d695-dd66-c21f-f49e-f6dc3dbdfc5a@ti.com>
On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
> Hi Bjorn,
>
> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
> > On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
> >
> >> Hi Bjorn,
> >>
> >
> > Hi Suman
> >
> >> On 10/23/18 8:19 PM, Suman Anna wrote:
> >>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> >>> printing the vring buffer address. This prints only a hashed
> >>> pointer even for previliged users. Use "%pK" instead so that
> >>> the address can be printed during debug using kptr_restrict
> >>> sysctl.
> >>
> >> Seems to have been lost among the patches, can you pick up this trivial
> >> patch for 5.4? Should apply cleanly on the latest HEAD as well.
> >>
> >
> > I share Andrew's question regarding what benefit you have from knowing
> > this value. Should we not just remove the va from the print? Or do you
> > actually have a use case for it?.
>
> I mainly use it during debug when comparing against kernel_page_tables
> and vmallocinfo. The pools that we use are not always guaranteed to be
> from linear memory, and behavior changes when using with CMA or DMA pools.
>
Thanks Suman. It seems to me that there's room for improvement to aid
this kind of debugging. But your usecase seems reasonable, so I'm
merging the patch.
> Note that usage of %pK does not leak the addresses automatically, but
> atleast enables me to get the values when needed. The changes also bring
> the usage in rpmsg core in sync with the remoteproc core.
>
Sounds like shouldn't have merged them in remoteproc then ;P
Thanks,
Bjorn
> regards
> Suman
>
> >
> > Regards,
> > Bjorn
> >
> >> regards
> >> Suman
> >>
> >>>
> >>> Signed-off-by: Suman Anna <s-anna@ti.com>
> >>> ---
> >>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> >>> index f29dee731026..1345f373a1a0 100644
> >>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> >>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> >>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >>> goto vqs_del;
> >>> }
> >>>
> >>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> >>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
> >>> bufs_va, &vrp->bufs_dma);
> >>>
> >>> /* half of the buffers is dedicated for RX */
> >>>
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v2 00/14] arm64: dts: meson: fixes following YAML bindings schemas conversion
From: Kevin Hilman @ 2019-08-27 21:59 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190823070248.25832-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This is the first set of DT fixes following the first YAML bindings conversion
> at [1], [2] and [3].
>
> After this set of fixes, the remaining errors are :
> meson-axg-s400.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
> meson-g12a-sei510.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
> meson-g12b-odroid-n2.dt.yaml: usb-hub: gpios:0:0: 20 is not valid under any of the given schemas
> meson-g12b-odroid-n2.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
> meson-g12a-x96-max.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
>
> These are only cosmetic changes, and should not break drivers implementation
> following the bindings.
Queued for v5.4,
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: meson-g12: specify suspend OPP
From: Kevin Hilman @ 2019-08-27 21:56 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190827100307.21661-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Tag the 1,2GHz OPP as suspend OPP to be set before going in suspend mode,
> for the G12A, G12B and SM1 SoCs.
>
> It has been reported that using various OPPs can lead to error or
> resume with a different OPP from the ROM, thus use this safe OPP as
> it is the default OPP used by the BL2 boot firmware.
>
> Neil Armstrong (3):
> arm64: dts: meson-g12a: specify suspend OPP
> arm64: dts: meson-sm1: specify suspend OPP
> arm64: dts: meson-g12b: specify suspend OPP
Queued patches 1, 3 for v5.4.
The SM1 patch has a dependency on the SM1 DVFS series, which in turn has
a dependency on clock changes. Once I get a stable tag for the SM1
clock changes, I'll queue up the rest.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: Rob Herring @ 2019-08-27 21:51 UTC (permalink / raw)
To: René van Dorst
Cc: devicetree, Nelson Chang, Frank Wunderlich, netdev, Sean Wang,
linux-mips, linux-mediatek, John Crispin, Matthias Brugger,
Stefan Roese, David S . Miller, linux-arm-kernel
In-Reply-To: <20190821144336.9259-4-opensource@vdorst.com>
On Wed, Aug 21, 2019 at 04:43:36PM +0200, René van Dorst wrote:
> This patch the removes the recently added mediatek,physpeed property.
> Use the fixed-link property speed = <2500> to set the phy in 2.5Gbit.
> See mt7622-bananapi-bpi-r64.dts for a working example.
>
> Signed-off-by: René van Dorst <opensource@vdorst.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> --
> v1->v2:
> * SGMII port only support BASE-X at 2.5Gbit.
> ---
> .../arm/mediatek/mediatek,sgmiisys.txt | 2 --
Bindings and dts files should be separate patches.
> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +++++++++++++------
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
> 3 files changed, 19 insertions(+), 12 deletions(-)
In any case,
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/8] coresight: etm4x: Add view comparator settings API to sysfs.
From: Mathieu Poirier @ 2019-08-27 21:40 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190819205720.24457-7-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:18PM +0100, Mike Leach wrote:
> Currently it is not possible to view the current settings of a given
> address comparator without knowing what type it is set to. For example, if
> a comparator is set as an addr_start comparator, attempting to read
> addr_stop for the same index will result in an error.
>
> addr_cmp_view is added to allow the user to see the current settings of
> the indexed address comparator without resorting to trail and error when
> the set type is not known.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 51 +++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index baac5b48b7ac..483976074779 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -1272,6 +1272,56 @@ static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(addr_exlevel_s_ns);
>
> +static const char * const addr_type_names[] = {
> + "unused",
> + "single",
> + "range",
> + "start",
> + "stop"
> +};
> +
> +static ssize_t addr_cmp_view_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + u8 idx, addr_type;
> + unsigned long addr_v, addr_v2, addr_ctrl;
> + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> + struct etmv4_config *config = &drvdata->config;
> + int size = 0;
> + bool exclude = false;
> +
> + spin_lock(&drvdata->spinlock);
> + idx = config->addr_idx;
> + addr_v = config->addr_val[idx];
> + addr_ctrl = config->addr_acc[idx];
> + addr_type = config->addr_type[idx];
> + if (addr_type == ETM_ADDR_TYPE_RANGE) {
> + if (idx%2) {
> + idx -= 1;
> + addr_v2 = addr_v;
> + addr_v = config->addr_val[idx];
> + } else
> + addr_v2 = config->addr_val[idx+1];
s/"idx+1"/"idx + 1"/
With that:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> + exclude = config->viiectlr & BIT(idx / 2 + 16);
> + }
> + spin_unlock(&drvdata->spinlock);
> + if (addr_type) {
> + size = scnprintf(buf, PAGE_SIZE, "addr_cmp[%i] %s %#lx", idx,
> + addr_type_names[addr_type], addr_v);
> + if (addr_type == ETM_ADDR_TYPE_RANGE) {
> + size += scnprintf(buf+size, PAGE_SIZE-size,
> + " %#lx %s", addr_v2,
> + exclude ? "exclude" : "include");
> + }
> + size += scnprintf(buf+size, PAGE_SIZE-size,
> + " ctrl(%#lx)\n", addr_ctrl);
> + } else {
> + size = scnprintf(buf, PAGE_SIZE, "addr_cmp[%i] unused\n", idx);
> + }
> + return size;
> +}
> +static DEVICE_ATTR_RO(addr_cmp_view);
> +
> static ssize_t vinst_pe_cmp_start_stop_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -2117,6 +2167,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> &dev_attr_addr_ctxtype.attr,
> &dev_attr_addr_context.attr,
> &dev_attr_addr_exlevel_s_ns.attr,
> + &dev_attr_addr_cmp_view.attr,
> &dev_attr_vinst_pe_cmp_start_stop.attr,
> &dev_attr_seq_idx.attr,
> &dev_attr_seq_state.attr,
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/8] coresight: etm4x: Improve usability of sysfs API.
From: Mathieu Poirier @ 2019-08-27 21:35 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20190819205720.24457-6-mike.leach@linaro.org>
On Mon, Aug 19, 2019 at 09:57:17PM +0100, Mike Leach wrote:
> Some changes to make the sysfs programming more intuitive.
>
> 1) Setting include / exclude on a range had to be done by setting
> the bit in 'mode' before setting the range. However, setting this
> bit also had the effect of altering the current range as well.
>
> Changed to only set include / exclude setting of a range at the point of
> setting that range. Either use a 3rd input parameter as the include exclude
> value, or if not present use the current value of 'mode'. Do not change
> current range when 'mode' changes.
>
> 2) Context ID and VM ID masks required 2 value inputs, even when the
> second value is ignored as insufficient CID / VMID comparators are
> implemented.
> Permit a single value to be used if that is sufficient to cover all
> implemented comparators.
Please split in two patches. With that:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../coresight/coresight-etm4x-sysfs.c | 24 +++++++++++++------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 3bcc260c9e55..baac5b48b7ac 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -297,8 +297,6 @@ static ssize_t mode_store(struct device *dev,
>
> spin_lock(&drvdata->spinlock);
> config->mode = val & ETMv4_MODE_ALL;
> - etm4_set_mode_exclude(drvdata,
> - config->mode & ETM_MODE_EXCLUDE ? true : false);
>
> if (drvdata->instrp0 == true) {
> /* start by clearing instruction P0 field */
> @@ -972,8 +970,12 @@ static ssize_t addr_range_store(struct device *dev,
> unsigned long val1, val2;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
> + int elements, exclude;
>
> - if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
> + elements = sscanf(buf, "%lx %lx %x", &val1, &val2, &exclude);
> +
> + /* exclude is optional, but need at least two parameter */
> + if (elements < 2)
> return -EINVAL;
> /* lower address comparator cannot have a higher address value */
> if (val1 > val2)
> @@ -1001,9 +1003,11 @@ static ssize_t addr_range_store(struct device *dev,
> /*
> * Program include or exclude control bits for vinst or vdata
> * whenever we change addr comparators to ETM_ADDR_TYPE_RANGE
> + * use supplied value, or default to bit set in 'mode'
> */
> - etm4_set_mode_exclude(drvdata,
> - config->mode & ETM_MODE_EXCLUDE ? true : false);
> + if (elements != 3)
> + exclude = config->mode & ETM_MODE_EXCLUDE;
> + etm4_set_mode_exclude(drvdata, exclude ? true : false);
>
> spin_unlock(&drvdata->spinlock);
> return size;
> @@ -1787,6 +1791,7 @@ static ssize_t ctxid_masks_store(struct device *dev,
> unsigned long val1, val2, mask;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
> + int nr_inputs;
>
> /*
> * Don't use contextID tracing if coming from a PID namespace. See
> @@ -1802,7 +1807,9 @@ static ssize_t ctxid_masks_store(struct device *dev,
> */
> if (!drvdata->ctxid_size || !drvdata->numcidc)
> return -EINVAL;
> - if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
> + /* one mask if < 4 comparators, two for up to 8 */
> + nr_inputs = sscanf(buf, "%lx %lx", &val1, &val2);
> + if ((drvdata->numcidc > 4) && (nr_inputs != 2))
> return -EINVAL;
>
> spin_lock(&drvdata->spinlock);
> @@ -1976,6 +1983,7 @@ static ssize_t vmid_masks_store(struct device *dev,
> unsigned long val1, val2, mask;
> struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct etmv4_config *config = &drvdata->config;
> + int nr_inputs;
>
> /*
> * only implemented when vmid tracing is enabled, i.e. at least one
> @@ -1983,7 +1991,9 @@ static ssize_t vmid_masks_store(struct device *dev,
> */
> if (!drvdata->vmid_size || !drvdata->numvmidc)
> return -EINVAL;
> - if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
> + /* one mask if < 4 comparators, two for up to 8 */
> + nr_inputs = sscanf(buf, "%lx %lx", &val1, &val2);
> + if ((drvdata->numvmidc > 4) && (nr_inputs != 2))
> return -EINVAL;
>
> spin_lock(&drvdata->spinlock);
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv4 0/3] Odroid c2 usb fixs
From: Martin Blumenstingl @ 2019-08-27 21:19 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Neil Armstrong, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CANAwSgTsua_x6fi7NzC2XjcV19OJcN3NhOT_niKXN4RR4X+qVQ@mail.gmail.com>
On Mon, Aug 26, 2019 at 6:38 AM Anand Moon <linux.amoon@gmail.com> wrote:
>
> Hi Martin,
>
> On Sun, 25 Aug 2019 at 02:48, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
> >
> > Hi Anand,
> >
> > thank you for the patches
> >
> > On Sat, Aug 24, 2019 at 8:49 PM Anand Moon <linux.amoon@gmail.com> wrote:
> > [...]
> > > Anand Moon (3):
> > > arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
> > > arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
> > > arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power
> > > failed warning
> > this whole series is:
> > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> Thanks, I have some more patch in line for this board.
great, any improvement counts (especially since most boards are
derived from Amlogic reference designs, so it's likely that more than
just the Odroid-C2 will benefit from your patches) :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] amlogic: arm: add Amlogic SM1 based Khadas VIM3 variant bindings
From: Martin Blumenstingl @ 2019-08-27 21:18 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman, linux-amlogic, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <c853d934-113c-2305-f229-1e2c7138fc3f@baylibre.com>
On Mon, Aug 26, 2019 at 9:42 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
[...]
> >> diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
> >> index b48ea1e4913a..2751dd778ce0 100644
> >> --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
> >> @@ -150,9 +150,10 @@ properties:
> >> - const: amlogic,s922x
> >> - const: amlogic,g12b
> >>
> >> - - description: Boards with the Amlogic Meson SM1 S905X3 SoC
> >> + - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
> >> items:
> >> - enum:
> >> - seirobotics,sei610
> >> + - khadas,vim3
>
> Khadas asked me to rename the board to "vim3l", which is the commercial name,
> should I only change the DT name or also the compatible "khadas,vim3l" ?
I vote for being consistent:
- rename the .dts to vim3l
- and change the compatible string
> >> - const: amlogic,sm1
> > on the GXL we differentiate between S905X and S905D
> > do we need to differentiate S905X3 from S905D3 (for example)?
>
> From a pure SoC die perspective they are the same, exactly like
> the S905X and S905D, only the package changes.
> So only the board DT will determine which eth PHY is used,
> if a DSI panel is connected, a demodulator is connected.. even
> if the underlying package is S905Y3 without any of these pins
> available.
OK, I see - fine for me then
GXL's S905W and/or S805X are the "special cases" then which (AFAIK)
use a different (smaller) package (so it made sense to differentiate
all GXL SoCs)
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-27 21:15 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <0e9c7c7cb17b6fdea8d49b06925badb0b3d2ff8b.camel@alliedtelesis.co.nz>
On Tue, Aug 27, 2019 at 09:13:11PM +0000, Chris Packham wrote:
> On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
> wrote:
> > On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > > wrote:
> > > > Just send the single patch to the patch tracker - having it against
> > > > 5.3-rc is fine (I don't think anything has changed for a long time
> > > > with that file.)
> > >
> > > Done
> > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> > >
> > > I'm still not entirely sure what to put for the KernelVersion tag. In
> > > hindsight think I misinterpreted your comment above and set it to 5.3rc
> > > (where you meant a series based on 5.3-rcX should apply cleanly). It
> > > probably should have been next or master because it's way past the
> > > merge window for 5.3.
> >
> > Think about it as "which kernel version was _this_ patch generated
> > against" - it's a guide for me to know which kernel version it
> > should be applied to. The nearest Linus release (rc or final) is
> > generally sufficient.
> >
> > If it doesn't apply to my current base, then I might check out that
> > version, apply it there, and then merge it in, resolving any
> > conflicts during the merge.
> >
> > It started off with a different purpose: when we had the older
> > development system, such as the 2.x series kernels, we would have
> > even x being the current stable kernels, and concurrently we'd
> > also have x+1 as the development series. When someone sent me a
> > patch back then, it was important to know which kernel series it
> > was meant for.
> >
> > I decided not to get rid of it because it provides useful
> > information when patches don't apply, and gives more options
> > than me just discarding the patch with a comment saying it
> > doesn't apply.
> >
>
> Thanks for the info. So 5.3-rc is not as wrong as I thought it was.
>
> One could even summarize the above as.
>
> git format-patch --add-header \
> "KernelVersion: $(git describe --abbrev=0 HEAD)"
Yep, I should probably update the patch system help with that, and
actually strip out everything about the old diff and patch way of
working.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Chris Packham @ 2019-08-27 21:13 UTC (permalink / raw)
To: linux@armlinux.org.uk
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <20190827210713.GO13294@shell.armlinux.org.uk>
On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
wrote:
> On Tue, Aug 27, 2019 at 08:56:05PM +0000, Chris Packham wrote:
> > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> > wrote:
> > > Just send the single patch to the patch tracker - having it against
> > > 5.3-rc is fine (I don't think anything has changed for a long time
> > > with that file.)
> >
> > Done
> > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8902/1
> >
> > I'm still not entirely sure what to put for the KernelVersion tag. In
> > hindsight think I misinterpreted your comment above and set it to 5.3rc
> > (where you meant a series based on 5.3-rcX should apply cleanly). It
> > probably should have been next or master because it's way past the
> > merge window for 5.3.
>
> Think about it as "which kernel version was _this_ patch generated
> against" - it's a guide for me to know which kernel version it
> should be applied to. The nearest Linus release (rc or final) is
> generally sufficient.
>
> If it doesn't apply to my current base, then I might check out that
> version, apply it there, and then merge it in, resolving any
> conflicts during the merge.
>
> It started off with a different purpose: when we had the older
> development system, such as the 2.x series kernels, we would have
> even x being the current stable kernels, and concurrently we'd
> also have x+1 as the development series. When someone sent me a
> patch back then, it was important to know which kernel series it
> was meant for.
>
> I decided not to get rid of it because it provides useful
> information when patches don't apply, and gives more options
> than me just discarding the patch with a comment saying it
> doesn't apply.
>
Thanks for the info. So 5.3-rc is not as wrong as I thought it was.
One could even summarize the above as.
git format-patch --add-header \
"KernelVersion: $(git describe --abbrev=0 HEAD)"
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] i2c: bcm2835: Add full name of devicetree node to adapter name
From: Scott Branden @ 2019-08-27 21:10 UTC (permalink / raw)
To: Stefan Wahren, Wolfram Sang, Eric Anholt, Florian Fainelli,
Ray Jui, Scott Branden
Cc: linux-i2c, linux-arm-kernel
In-Reply-To: <1566925456-5928-4-git-send-email-wahrenst@gmx.net>
On 2019-08-27 10:04 a.m., Stefan Wahren wrote:
> Inspired by Lori Hikichi's patch for iproc, this adds the full name of
> the devicetree node to the adapter name. With the introduction of
> BCM2711 it's very difficult to distinguish between the multiple instances.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Acked-by: Scott Branden <scott.branden@broadcom.com>
> =2D--
> drivers/i2c/busses/i2c-bcm2835.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm=
> 2835.c
> index ab5502f..e01b2b5 100644
> =2D-- a/drivers/i2c/busses/i2c-bcm2835.c
> +++ b/drivers/i2c/busses/i2c-bcm2835.c
> @@ -472,7 +472,8 @@ static int bcm2835_i2c_probe(struct platform_device *p=
> dev)
> i2c_set_adapdata(adap, i2c_dev);
> adap->owner =3D THIS_MODULE;
> adap->class =3D I2C_CLASS_DEPRECATED;
> - strlcpy(adap->name, "bcm2835 I2C adapter", sizeof(adap->name));
> + snprintf(adap->name, sizeof(adap->name), "bcm2835 (%s)",
> + of_node_full_name(pdev->dev.of_node));
> adap->algo =3D &bcm2835_i2c_algo;
> adap->dev.parent =3D &pdev->dev;
> adap->dev.of_node =3D pdev->dev.of_node;
> =2D-
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox