CoreSight

coresight@lists.linaro.org

6 participants
2469 discussions

[PATCHv2] coresight: tmc: Add shutdown callback for TMC ETR/ETF

by Sai Prakash Ranjan

Implement a shutdown callback to ensure ETR/ETF hardware is properly shutdown in reboot/shutdown path. This is required for ETR/ETF which has SMMU address translation enabled like on SC7180 SoC and few others. If the hardware is still accessing memory after SMMU translation is disabled as part of SMMU shutdown callback in system reboot or shutdown path, then IOVAs(I/O virtual address) which it was using will go on the bus as the physical addresses which might result in unknown crashes (NoC/interconnect errors). So we make sure from this shutdown callback that the ETR/ETF is shutdown before SMMU translation is disabled and device_link in SMMU driver will take care of ordering of shutdown callbacks such that SMMU shutdown callback is not called before any of its consumer shutdown callbacks. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org> --- Changes since v1: * Use mode flag and drop enable flag as Mike suggested. * Use spinlock before tmc hw disable as Mike suggested. --- .../hwtracing/coresight/coresight-tmc-etf.c | 4 +-- .../hwtracing/coresight/coresight-tmc-etr.c | 2 +- drivers/hwtracing/coresight/coresight-tmc.c | 33 +++++++++++++++++++ drivers/hwtracing/coresight/coresight-tmc.h | 3 ++ 4 files changed, 39 insertions(+), 3 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c index 36cce2bfb744..cba3e7592820 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c @@ -85,7 +85,7 @@ static void __tmc_etb_disable_hw(struct tmc_drvdata *drvdata) CS_LOCK(drvdata->base); } -static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata) +void tmc_etb_disable_hw(struct tmc_drvdata *drvdata) { __tmc_etb_disable_hw(drvdata); coresight_disclaim_device(drvdata->base); @@ -118,7 +118,7 @@ static int tmc_etf_enable_hw(struct tmc_drvdata *drvdata) return 0; } -static void tmc_etf_disable_hw(struct tmc_drvdata *drvdata) +void tmc_etf_disable_hw(struct tmc_drvdata *drvdata) { CS_UNLOCK(drvdata->base); diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c index 625882bc8b08..b29c2db94d96 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c @@ -1110,7 +1110,7 @@ static void __tmc_etr_disable_hw(struct tmc_drvdata *drvdata) } -static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata) +void tmc_etr_disable_hw(struct tmc_drvdata *drvdata) { __tmc_etr_disable_hw(drvdata); /* Disable CATU device if this ETR is connected to one */ diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c index 39fba1d16e6e..c7902ce0bd3b 100644 --- a/drivers/hwtracing/coresight/coresight-tmc.c +++ b/drivers/hwtracing/coresight/coresight-tmc.c @@ -538,6 +538,38 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id) return ret; } +static void tmc_shutdown(struct amba_device *adev) +{ + unsigned long flags; + struct tmc_drvdata *drvdata = amba_get_drvdata(adev); + + spin_lock_irqsave(&drvdata->spinlock, flags); + + if (drvdata->mode == CS_MODE_DISABLED) + goto out; + + /* + * We do not care about the active trace sessions here + * since the system is going down unlike remove callback, + * just make sure that the hardware is shutdown. + */ + switch (drvdata->config_type) { + case TMC_CONFIG_TYPE_ETB: + tmc_etb_disable_hw(drvdata); + break; + case TMC_CONFIG_TYPE_ETF: + tmc_etf_disable_hw(drvdata); + break; + case TMC_CONFIG_TYPE_ETR: + tmc_etr_disable_hw(drvdata); + } + +out: + spin_unlock_irqrestore(&drvdata->spinlock, flags); + misc_deregister(&drvdata->miscdev); + coresight_unregister(drvdata->csdev); +} + static const struct amba_id tmc_ids[] = { CS_AMBA_ID(0x000bb961), /* Coresight SoC 600 TMC-ETR/ETS */ @@ -556,6 +588,7 @@ static struct amba_driver tmc_driver = { .suppress_bind_attrs = true, }, .probe = tmc_probe, + .shutdown = tmc_shutdown, .id_table = tmc_ids, }; builtin_amba_driver(tmc_driver); diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h index 71de978575f3..0a77f2f25090 100644 --- a/drivers/hwtracing/coresight/coresight-tmc.h +++ b/drivers/hwtracing/coresight/coresight-tmc.h @@ -260,6 +260,8 @@ u32 tmc_get_memwidth_mask(struct tmc_drvdata *drvdata); /* ETB/ETF functions */ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata); int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata); +void tmc_etb_disable_hw(struct tmc_drvdata *drvdata); +void tmc_etf_disable_hw(struct tmc_drvdata *drvdata); extern const struct coresight_ops tmc_etb_cs_ops; extern const struct coresight_ops tmc_etf_cs_ops; @@ -268,6 +270,7 @@ ssize_t tmc_etb_get_sysfs_trace(struct tmc_drvdata *drvdata, /* ETR functions */ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata); int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata); +void tmc_etr_disable_hw(struct tmc_drvdata *drvdata); extern const struct coresight_ops tmc_etr_cs_ops; ssize_t tmc_etr_get_sysfs_trace(struct tmc_drvdata *drvdata, loff_t pos, size_t len, char **bufpp); base-commit: 059e38815950dbec65beafe03757bce9436e89a4 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 3 months

Re: Random Softlockups when SMMU translation is enabled for TMC ETR

by Sai Prakash Ranjan

Hi guys, On 2020-05-28 14:16, Sai Prakash Ranjan wrote: > Hi folks, > > I was trying to enable SMMU translation for coresight TMC ETR > component via "iommus" property on SC7180 SoC. > And on enabling the trace, I observe random softlockups everytime. For > enabling trace, I just select ETR as > the sink and ETM as the source via sysfs and immediately start seeing > lockups. I have looked from the hardware > point of view and there is no errata as such and it works fine on > downstream kernel which is very old - 4.14 kernel. > This is reproducible even with KASAN disabled as well. Also I have > dumped other CPU stacks as well during softlockup > via adding dump_stack in ipi_cpu_stop and and no interesting logs > there as other cpus are idle. > As an update, this turned out to be due to firmware misconfiguration. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 3 months

[PATCHv3 0/2] coresight: etm4x: Add support to skip trace unit power up

by Sai Prakash Ranjan

This series adds support to skip powering up of trace unit on systems with an errata which stops CPU watchdog counter when power up bit is set (TRCPDCR.PU = 1). Setting this bit is not required on Qualcomm Technologies Inc. chipsets where this errata exists since the ETMs are in the same power domain as their respective CPU cores. Changes since v2: * Fix checkpatch warning for 80 characters. Changes since v1: * Use qcom,skip-power-up for naming as suggested by Mathieu. * Have check for DT property in initialization as per Mathieu. * Reword description for property as per Mathieu. * Split up dt-binding patch as checkpatch complains. Tingwei Zhang (2): coresight: etm4x: Add support to skip trace unit power up dt-bindings: arm: coresight: Add support to skip trace unit power up .../devicetree/bindings/arm/coresight.txt | 7 +++++ drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++++++++++++------- drivers/hwtracing/coresight/coresight-etm4x.h | 3 +++ 3 files changed, 27 insertions(+), 10 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 3 months

Random Softlockups when SMMU translation is enabled for TMC ETR

by Sai Prakash Ranjan

Hi folks, I was trying to enable SMMU translation for coresight TMC ETR component via "iommus" property on SC7180 SoC. And on enabling the trace, I observe random softlockups everytime. For enabling trace, I just select ETR as the sink and ETM as the source via sysfs and immediately start seeing lockups. I have looked from the hardware point of view and there is no errata as such and it works fine on downstream kernel which is very old - 4.14 kernel. This is reproducible even with KASAN disabled as well. Also I have dumped other CPU stacks as well during softlockup via adding dump_stack in ipi_cpu_stop and and no interesting logs there as other cpus are idle. Logs for softlockup, [ 69.725539] watchdog: BUG: soft lockup - CPU#0 stuck for 11s! [ksoftirqd/0:9] [ 69.772709] irq event stamp: 144 [ 69.776047] hardirqs last enabled at (143): [<ffffffd05a0fb908>] run_ksoftirqd+0x34/0x70 [ 69.784452] hardirqs last disabled at (144): [<ffffffd05ab7bbd8>] __schedule+0x158/0x940 [ 69.792768] softirqs last enabled at (142): [<ffffffd05a0819dc>] __do_softirq+0x4bc/0x51c [ 69.801255] softirqs last disabled at (69): [<ffffffd05a0fb904>] run_ksoftirqd+0x30/0x70 [ 69.824147] pstate: 60400009 (nZCv daif +PAN -UAO) [ 69.829082] pc : skb_release_data+0x60/0x1a4 [ 69.833475] lr : skb_release_data+0x50/0x1a4 [ 69.837864] sp : ffffff8147cab770 [ 69.841279] x29: ffffff8147cab770 x28: ffffff8133277d00 [ 69.846744] x27: 0000000000000034 x26: ffffff814441a30e [ 69.852204] x25: ffffff811f0c0000 x24: 0000000000000000 [ 69.857666] x23: ffffff81292cc000 x22: ffffff814441a380 [ 69.863133] x21: 0000000000000001 x20: ffffff814441a3a0 [ 69.868595] x19: ffffff81055a7540 x18: ffffff8114f80280 [ 69.874062] x17: 00000000000005a4 x16: ffffff8114f80278 [ 69.879526] x15: 0000000000000000 x14: 0000000000000001 [ 69.884994] x13: 00000000caf7cc01 x12: 00000000b6bc5499 [ 69.890453] x11: 0000000000000000 x10: dfffffd000000001 [ 69.895920] x9 : 0000000000000001 x8 : 0000000000000000 [ 69.901377] x7 : 0000000000000000 x6 : 0000000000000000 [ 69.906839] x5 : 0000000000000000 x4 : 0000000000000000 [ 69.912307] x3 : ffffffd05a99ea98 x2 : 0000000000000001 [ 69.917771] x1 : 0000000000000004 x0 : 0000000000000001 [ 69.923231] Call trace: [ 69.925765] skb_release_data+0x60/0x1a4 [ 69.929801] skb_release_all+0x2c/0x38 [ 69.933669] consume_skb+0x48/0x6c [ 69.937177] packet_rcv+0x5c/0x3f0 [ 69.940685] __netif_receive_skb_one_core+0x50/0x60 [ 69.945704] __netif_receive_skb+0x4c/0x8c [ 69.949926] netif_receive_skb_internal+0xb8/0x198 [ 69.954856] napi_gro_receive+0x19c/0x360 [ 69.959030] r8152_poll+0x518/0x7b4 [r8152] [ 69.963336] net_rx_action+0x114/0x32c [ 69.967198] __do_softirq+0x258/0x51c [ 69.970968] irq_exit+0xd8/0xf8 [ 69.974215] __handle_domain_irq+0x8c/0xc4 [ 69.978430] gic_handle_irq+0x100/0x1c4 [ 69.982378] el1_irq+0xbc/0x180 [ 69.985619] smpboot_thread_fn+0x84/0x2bc [ 69.989753] kthread+0x128/0x138 [ 69.993081] ret_from_fork+0x10/0x18 [ 69.996769] Kernel panic - not syncing: softlockup: hung tasks [ 70.017342] Call trace: [ 70.019867] dump_backtrace+0x0/0x188 [ 70.023640] show_stack+0x20/0x2c [ 70.027061] dump_stack+0xdc/0x144 [ 70.030573] panic+0x174/0x37c [ 70.033724] softlockup_fn+0x0/0x60 [ 70.037324] __hrtimer_run_queues+0x264/0x498 [ 70.041808] hrtimer_interrupt+0xf0/0x22c [ 70.045946] arch_timer_handler_phys+0x40/0x50 [ 70.050524] handle_percpu_devid_irq+0x8c/0x158 [ 70.055190] __handle_domain_irq+0x84/0xc4 [ 70.059412] gic_handle_irq+0x100/0x1c4 [ 70.063359] el1_irq+0xbc/0x180 [ 70.066595] skb_release_data+0x60/0x1a4 [ 70.070638] skb_release_all+0x2c/0x38 [ 70.074498] consume_skb+0x48/0x6c [ 70.078007] packet_rcv+0x5c/0x3f0 [ 70.081518] __netif_receive_skb_one_core+0x50/0x60 [ 70.086533] __netif_receive_skb+0x4c/0x8c [ 70.090746] netif_receive_skb_internal+0xb8/0x198 [ 70.095673] napi_gro_receive+0x19c/0x360 [ 70.099825] r8152_poll+0x518/0x7b4 [r8152] [ 70.104129] net_rx_action+0x114/0x32c [ 70.107984] __do_softirq+0x258/0x51c [ 70.111760] irq_exit+0xd8/0xf8 [ 70.115003] __handle_domain_irq+0x8c/0xc4 [ 70.119215] gic_handle_irq+0x100/0x1c4 [ 70.123168] el1_irq+0xbc/0x180 [ 70.126410] smpboot_thread_fn+0x84/0x2bc [ 70.130540] kthread+0x128/0x138 [ 70.133862] ret_from_fork+0x10/0x18 [ 70.137570] SMP: stopping secondary CPUs [ 70.355132] Kernel Offset: 0x4a000000 from 0xffffffd010000000 [ 70.361047] PHYS_OFFSET: 0xfffffffac0000000 [ 70.365357] CPU features: 0x0006,2a80aa18 [ 70.369489] Memory Limit: none One more such softlockup, [ 122.634764] watchdog: BUG: soft lockup - CPU#0 stuck for 11s! [sugov:0:1729] [ 122.683618] irq event stamp: 0 [ 122.686813] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 122.693310] hardirqs last disabled at (0): [<ffffffd254aec380>] copy_process+0x3e4/0xca8 [ 122.701655] softirqs last enabled at (0): [<ffffffd254aec398>] copy_process+0x3fc/0xca8 [ 122.710003] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 122.731030] pstate: 20400009 (nzCv daif +PAN -UAO) [ 122.736001] pc : preempt_schedule_irq+0x48/0x84 [ 122.740697] lr : preempt_schedule_irq+0x44/0x84 [ 122.745389] sp : ffffffc015c13a80 [ 122.748828] x29: ffffffc015c13a80 x28: ffffff815285af80 [ 122.754330] x27: ffffff815285af80 x26: ffffffc010004000 [ 122.759833] x25: ffffffc010000000 x24: 0000000000000000 [ 122.765332] x23: 0000000080c00009 x22: ffffffd2555492e8 [ 122.770826] x21: 0000000000000060 x20: 00000000000000e0 [ 122.776321] x19: ffffff815285af80 x18: 0000000000000005 [ 122.781825] x17: 0000000000000000 x16: 0000000000000001 [ 122.787319] x15: 0000000000000010 x14: 0000000000000010 [ 122.792822] x13: 0000000000000000 x12: ffffffd254a9bb14 [ 122.798320] x11: 632d4b6b9e7ff300 x10: 632d4b6b9e7ff300 [ 122.803820] x9 : ffffffd25554750c x8 : 0000000000000000 [ 122.809318] x7 : ffffffd254ba17b4 x6 : 0000000000000000 [ 122.814815] x5 : 0000000000010000 x4 : 0000000000000080 [ 122.820312] x3 : ffffffc015c13a00 x2 : ffffffd254a93c04 [ 122.825809] x1 : ffffffc015c13a00 x0 : ffffffd255548028 [ 122.831309] Call trace: [ 122.833876] preempt_schedule_irq+0x48/0x84 [ 122.838217] arm64_preempt_schedule_irq+0x4c/0x70 [ 122.843092] el1_irq+0xd4/0x180 [ 122.846364] __mutex_unlock_slowpath+0x260/0x290 [ 122.851150] mutex_unlock+0x24/0x30 [ 122.854780] dev_pm_opp_xlate_required_opp+0xd8/0x114 [ 122.860010] qcom_cpufreq_hw_target_index+0xf4/0x1a4 [ 122.865160] __cpufreq_driver_target+0x1e8/0x2f4 [ 122.869947] sugov_work+0x58/0x70 [ 122.873397] kthread_worker_fn+0x10c/0x1f8 [ 122.877652] kthread+0x11c/0x12c [ 122.881014] ret_from_fork+0x10/0x18 [ 122.884733] Kernel panic - not syncing: softlockup: hung tasks [ 122.905309] Call trace: [ 122.907872] dump_backtrace+0x0/0x188 [ 122.911678] show_stack+0x20/0x2c [ 122.915130] dump_stack+0xc8/0x124 [ 122.918667] panic+0x168/0x388 [ 122.921857] softlockup_fn+0x0/0x60 [ 122.925485] __hrtimer_run_queues+0x250/0x47c [ 122.930003] hrtimer_interrupt+0xf0/0x22c [ 122.934171] arch_timer_handler_phys+0x40/0x50 [ 122.938782] handle_percpu_devid_irq+0x8c/0x158 [ 122.943485] __handle_domain_irq+0x84/0xc4 [ 122.947737] gic_handle_irq+0xd0/0x178 [ 122.951625] el1_irq+0xbc/0x180 [ 122.954903] preempt_schedule_irq+0x48/0x84 [ 122.959239] arm64_preempt_schedule_irq+0x4c/0x70 [ 122.964110] el1_irq+0xd4/0x180 [ 122.967387] __mutex_unlock_slowpath+0x260/0x290 [ 122.972169] mutex_unlock+0x24/0x30 [ 122.975791] dev_pm_opp_xlate_required_opp+0xd8/0x114 [ 122.981015] qcom_cpufreq_hw_target_index+0xf4/0x1a4 [ 122.986150] __cpufreq_driver_target+0x1e8/0x2f4 [ 122.990933] sugov_work+0x58/0x70 [ 122.994378] kthread_worker_fn+0x10c/0x1f8 [ 122.998629] kthread+0x11c/0x12c [ 123.001982] ret_from_fork+0x10/0x18 [ 123.005741] SMP: stopping secondary CPUs [ 123.223202] Kernel Offset: 0x1244a00000 from 0xffffffc010000000 [ 123.229319] PHYS_OFFSET: 0xffffffdb80000000 [ 123.233655] CPU features: 0x0006,2a80aa18 [ 123.237809] Memory Limit: none Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 3 months

Your Email Password will expire today 5/28/2020 12:08:10 a.m.

by MAIL SERVER

5 years, 3 months

[RFC PATCH v3 0/6] Allow CoreSight to specify and select default sink

by Mike Leach

This patchset provides a proposed infrastructure to allow for the automatic selection of a sink during CoreSight tracing operations. Currently starting tracing using perf requires a sink selection on the command line:- sudo ./perf record -e cs_etm/@tmc_etr0/ --per-thread uname -a After this set the infrastructure will be able to select a default sink:- sudo ./perf record -e cs_etm// --per-thread uname -a This matches with the default operation provided with perf and intelpt. Where no sink is specified at the start of a trace session, the CoreSight system will walk the connection graph from the source ETM, to find a suitable sink using the first encountered highest priority device. The CoreSight infrastructure is updated to define sink sub_types to differentiate between sinks with built in buffers (ETB / ETF) - BUFFER type , and those that use system memory (ETR) - SYSMEM - types. SYSMEM types are considered higher priority. When two sinks are found of equal priority, then the closest sink to the source in terms of connection nodes is chosen. The automatic sink selection will also operate if an ETM is enabled using sysfs commands, and no sink is currently enabled. Applies to Linux coresight/next branch Changes since v2: 1) changed from explicit set priority value to using the sink_subtype in the coresight_device as the selection priority value. 2) Added in search depth to the find algorithm to ensure that the closest sink to the source with the highest priority is chosen. 3) A default sink is cached with the source when the search is first undertaken, reducing the need for repeat searches for a given source. Changes since v1: 1) Dropped the device-tree attribute labelling of sinks for selection and implemented the priority schema preferring first encountered ETR, after mailing list discussions. 2) Added in sysfs support for auto sink selection. Mike Leach (6): coresight: Fix comment in main header file. coresight: Add default sink selection to CoreSight base coresight: tmc: Update sink types for default selection. coresight: etm: perf: Add default sink selection to etm perf coresight: sysfs: Allow select default sink on source enable. perf: cs-etm: Allow no CoreSight sink to be specified on command line .../hwtracing/coresight/coresight-etm-perf.c | 17 +- drivers/hwtracing/coresight/coresight-priv.h | 2 + drivers/hwtracing/coresight/coresight-tmc.c | 3 +- drivers/hwtracing/coresight/coresight.c | 148 +++++++++++++++++- include/linux/coresight.h | 6 +- tools/perf/arch/arm/util/cs-etm.c | 6 +- 6 files changed, 172 insertions(+), 10 deletions(-) -- 2.17.1

5 years, 3 months

COFFER TABLE SET Helen

by Helen

5 years, 3 months

[PATCHv2 0/4] Add support for replicators which loses context on clock removal

by Sai Prakash Ranjan

This series is mainly to add support for replicators which lose context on removing AMBA clock like on SC7180 SoC where replicator in AOSS domain loses context. Patch 1 and 2 are minor cleanups to use macros. Patch 3 and 4 adds support for replicators which loses context on removing AMBA clock. Previous version is here - https://lore.kernel.org/patchwork/patch/1239923/ More discussion is found here - https://lore.kernel.org/patchwork/patch/1231182/ There were no patch 1 and patch 2 in v1. Sai Prakash Ranjan (4): coresight: replicator: Use CS_AMBA_ID macro for id table coresight: catu: Use CS_AMBA_ID macro for id table coresight: replicator: Reset replicator if context is lost dt-bindings: arm: coresight: Add optional property to replicators .../devicetree/bindings/arm/coresight.txt | 6 ++ drivers/hwtracing/coresight/coresight-catu.c | 5 +- .../coresight/coresight-replicator.c | 66 +++++++++++-------- 3 files changed, 46 insertions(+), 31 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 3 months

libopencsd in debian: new git repos and 0.14.1-1 now in 'testing'

by Wookey

I updated debian to 0.14.1. I am also trying out a dgit-based workflow for the package, so the package uploaded to the archive is also available as https://browse.dgit.debian.org/libopencsd.git/ You can pull down the latest version with: From the archive, as tarball+diff: apt From the archive, as git repo: dgit From a URL, as tarball+diff: dget None of this should make much difference to any of you, but this does make it much easier for people used to a git workflow to contribute to the debian package if need be. It should also mean that the debian package matches the git history of upstream much more closely. In case anyone cares I have chosen the dgit 'merge' workflow about of about 11 possible schemes (https://wiki.debian.org/GitPackagingSurvey) (debian never has just one way of doing anything :-) For those not familiar: dgit is a tool to provide bi-direcitonal translation between the debian archive format (.dsc, tarball and debian diff) and git repositories. Package maintainers can continue to use either system and the git/tarball views of the world are synchonised at upload. I've also added a development view of the package on debian's gitlab instance: https://salsa.debian.org/wookey/libopencsd I would prefer patches as patches in bug reports, but I have left the 'merge request' thingy turned on so I guess people can use that too (but I don't know how to drive it yet :-). I reserve the right to give up with all this complicated fancy stuff and go back to uploading debianised tarballs, which is quick, simple and I understand it properly :-) but this stuff should make things a little more accessible. I'd be interested to hear if anyone actually finds it useful (nearly everyone on this list will be working with upstream primarily so rarely/never fiddle with the debian packages, I presume). ----- Forwarded message from Debian testing watch <noreply(a)release.debian.org> ----- Date: Tue, 19 May 2020 04:39:06 +0000 From: Debian testing watch <noreply(a)release.debian.org> To: libopencsd(a)packages.debian.org Subject: libopencsd 0.14.1-1 MIGRATED to testing FYI: The status of the libopencsd source package in Debian's testing distribution has changed. Previous version: 0.14.0-1 Current version: 0.14.1-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ----- End forwarded message ----- Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

5 years, 3 months

Re: Coresight enablement on NXP ARMv8 device

by Mathieu Poirier

Hi Poonam, Please CC the coresight mailing list (as I did) when asking questions - there is a lot of well informed people on there that can also help you. On Thu, 23 Jan 2020 at 22:33, Poonam Aggrwal <poonam.aggrwal(a)nxp.com> wrote: > > Hello Mathieu > > > > Greetings! > > > > I have started to take a look at the Linux coresight framework, and get this enabled on a NXP ARMv8 device. > > > > Can you share some documentation on the configs required to be enabled and the device tree nodes? For V8 we have to reference implementation - ARM Juno and the dragonboard 410c. I highly recommend purchasing the latter (because it is very cheap) in order to get an understanding of what a working coresight system look like. It is much easier to start from a working example than nothing at all. Other than that the coresight bindings [1] are full of good examples. I would also have a look at the DT for Juno [2] and the dragonboard[3]. The HOWTO.md [4] on github is a really good starting point when you'll get to test things out. [1]. https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bin… [2]. https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/arm/juno… [3]. https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm… [4]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md > > To start I am looking to enable the ARMv8 ETM tracing. Before going further I advise you to look at the source and sink configuration on your platform. Up to now we've been working with configurations where sources share a single sink (N:1 topology). Newer SoC will have one source per sink (1:1 topology). At this time only the former is supported by the framework. Supporting 1:1 topologies would require a fair amount of refactoring, something we haven't had the opportunity to do for lack of HW platform to work with. Regards, Mathieu > > Is there a reference which I can check in Linux for device tree and config. > > > > Many Thanks > > Poonam

5 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight