* Re: [linux-sunxi] [PATCH v2 15/15] arm64: dts: allwinner: a64: Add Video Engine node
From: Paul Kocialkowski @ 2018-12-10 9:00 UTC (permalink / raw)
To: Jernej Škrabec, linux-sunxi
Cc: devel, devicetree, Sakari Ailus, Maxime Ripard, linux-kernel,
Hans Verkuil, Chen-Yu Tsai, Rob Herring, Thomas Petazzoni,
Mark Rutland, Mauro Carvalho Chehab, linux-arm-kernel,
linux-media
In-Reply-To: <2823800.C4zEU5jiS7@jernej-laptop>
Hi,
On Fri, 2018-12-07 at 22:22 +0100, Jernej Škrabec wrote:
> Hi!
>
> Dne sreda, 05. december 2018 ob 10:24:44 CET je Paul Kocialkowski napisal(a):
> > This adds the Video Engine node for the A64. Since it can map the whole
> > DRAM range, there is no particular need for a reserved memory node
> > (unlike platforms preceding the A33).
> >
> > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> > 8557d52c7c99..8d024c10d7cb 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -397,6 +397,17 @@
> > };
> > };
> >
> > + video-codec@1c0e000 {
> > + compatible = "allwinner,sun50i-h5-video-engine";
>
> You meant A64 instead of H5, right?
Ah yes definitely, that's a mistake right here.
I'll send a follow-up patch for switching the compatible to describe
the a64 instead of the h5. In practice, having the a64 use the h5
compatible doesn't cause any issue, but it should be fixed
nevertheless.
Cheers,
Paul
> Best regards,
> Jernej
>
> > + reg = <0x01c0e000 0x1000>;
> > + clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
> > + <&ccu CLK_DRAM_VE>;
> > + clock-names = "ahb", "mod", "ram";
> > + resets = <&ccu RST_BUS_VE>;
> > + interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
> > + allwinner,sram = <&ve_sram 1>;
> > + };
> > +
> > mmc0: mmc@1c0f000 {
> > compatible = "allwinner,sun50i-a64-mmc";
> > reg = <0x01c0f000 0x1000>;
>
>
>
--
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
_______________________________________________
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 2/8] KVM: arm/arm64: Re-factor setting the Stage 2 entry to exec on fault
From: Christoffer Dall @ 2018-12-10 9:00 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Anshuman Khandual, marc.zyngier, Punit Agrawal, will.deacon,
linux-kernel, punitagrawal, kvmarm, linux-arm-kernel
In-Reply-To: <f078ae84-9906-4394-957f-8f041b08827f@arm.com>
On Wed, Dec 05, 2018 at 10:47:10AM +0000, Suzuki K Poulose wrote:
>
>
> On 03/12/2018 13:32, Anshuman Khandual wrote:
> >
> >
> >On 10/31/2018 11:27 PM, Punit Agrawal wrote:
> >>Stage 2 fault handler marks a page as executable if it is handling an
> >>execution fault or if it was a permission fault in which case the
> >>executable bit needs to be preserved.
> >>
> >>The logic to decide if the page should be marked executable is
> >>duplicated for PMD and PTE entries. To avoid creating another copy
> >>when support for PUD hugepages is introduced refactor the code to
> >>share the checks needed to mark a page table entry as executable.
> >>
> >>Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> >>Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >>Cc: Christoffer Dall <christoffer.dall@arm.com>
> >>Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>---
> >> virt/kvm/arm/mmu.c | 28 +++++++++++++++-------------
> >> 1 file changed, 15 insertions(+), 13 deletions(-)
> >>
> >>diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >>index 59595207c5e1..6912529946fb 100644
> >>--- a/virt/kvm/arm/mmu.c
> >>+++ b/virt/kvm/arm/mmu.c
> >>@@ -1475,7 +1475,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> unsigned long fault_status)
> >> {
> >> int ret;
> >>- bool write_fault, exec_fault, writable, force_pte = false;
> >>+ bool write_fault, writable, force_pte = false;
> >>+ bool exec_fault, needs_exec;
> >
> >New line not required, still within 80 characters.
> >
> >> unsigned long mmu_seq;
> >> gfn_t gfn = fault_ipa >> PAGE_SHIFT;
> >> struct kvm *kvm = vcpu->kvm;
> >>@@ -1598,19 +1599,25 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> if (exec_fault)
> >> invalidate_icache_guest_page(pfn, vma_pagesize);
> >>+ /*
> >>+ * If we took an execution fault we have made the
> >>+ * icache/dcache coherent above and should now let the s2
> >
> >Coherent or invalidated with invalidate_icache_guest_page ?
>
> We also do clean_dcache above if needed. So that makes sure
> the data is coherent. Am I missing something here ?
>
I think you've got it right. We have made the icache coherent with the
data/instructions in the page by invalidating the icache. I think the
comment is ok either way.
Thanks,
Christoffer
_______________________________________________
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 01/19] dt-bindings: clock: tegra124-dfll: Update DFLL binding for PWM regulator
From: Jon Hunter @ 2018-12-10 8:59 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, devicetree, linux-clk, linux-arm-kernel
In-Reply-To: <46b5eafa-00a0-1d91-1f4d-97ab119fcf21@nvidia.com>
On 10/12/2018 08:49, Joseph Lo wrote:
> Hi Jon,
>
> Thanks for reviewing this series.
>
> On 12/7/18 9:41 PM, Jon Hunter wrote:
>>
>> On 04/12/2018 09:25, Joseph Lo wrote:
>>> From: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>
>>> Add new properties to configure the DFLL PWM regulator support. Also
>>> add an example and make the I2C clock only required when I2C support is
>>> used.
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>> Signed-off-by: Joseph Lo <josephl@nvidia.com>
>>> ---
>>> .../bindings/clock/nvidia,tegra124-dfll.txt | 73 ++++++++++++++++++-
>>> 1 file changed, 71 insertions(+), 2 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>>> b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>>> index dff236f524a7..8c97600d2bad 100644
>>> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>>> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>>> @@ -8,7 +8,6 @@ the fast CPU cluster. It consists of a free-running
>>> voltage controlled
>>> oscillator connected to the CPU voltage rail (VDD_CPU), and a
>>> closed loop
>>> control module that will automatically adjust the VDD_CPU voltage by
>>> communicating with an off-chip PMIC either via an I2C bus or via
>>> PWM signals.
>>> -Currently only the I2C mode is supported by these bindings.
>>> Required properties:
>>> - compatible : should be "nvidia,tegra124-dfll"
>>> @@ -45,10 +44,28 @@ Required properties for the control loop parameters:
>>> Optional properties for the control loop parameters:
>>> - nvidia,cg-scale: Boolean value, see the field
>>> DFLL_PARAMS_CG_SCALE in the TRM.
>>> +Optional properties for mode selection:
>>> +- nvidia,pwm-to-pmic: Use PWM to control regulator rather then I2C.
>>> +
>>> Required properties for I2C mode:
>>> - nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
>>> -Example:
>>> +Required properties for PWM mode:
>>> +- nvidia,pwm-period: period of PWM square wave in microseconds.
>>> +- nvidia,init-uv: Regulator voltage in micro volts when PWM control
>>> is disabled.
>>
>> Maybe consider 'pwm-inactive-voltage-microvolt'.
> Ah, I think I need to refine the description here. It should be
> something like below.
> - nvidia,pwm-init-microvolt : Regulator voltage in micro volts when PWM
> control is initialized
>
> This is the initial voltage that when we just initialize the DFLL
> hardware for PWM output. And before we switch the CPU clock from PLLX to
> DFLL, we will enable DFLL hardware in closed loop mode which will aplly
> the DVFS table that was calculated from CVB table.
>
> The original description maybe make you think that it's the working
> voltage when it's under open-loop mode. But it's not. Sorry.
>
> When we working on open-loop mode which will switch to low voltage range
> which also follows the DVFS table. Not this one.
OK, but I am still not sure what this voltage is. I mean that I
understand it is the initial voltage, but how exactly do we define this
number? Where does it come from, how is this determined?
>>
>>> +- nvidia,align-offset-uv: Regulator voltage in micro volts when PWM
>>> control is
>>> + enabled and PWM output is low.
>>
>> Would this be considered the minimum pwm active voltage?
> This would be used for minimum voltage for LUT table, which is the table
> that PMIC can output. The real minimum voltage in PWM mode still depends
> on the CVB table.
>
> So maybe change this one to 'nvidia,pwm-offset-uv'.
So is this the min supported by the PMIC? Maybe the name should reflect
that because the above name does not reflect this. Furthermore, if this
is a min then maybe the name should use 'min' as opposed to 'offset'.
for example, 'nvidia,pwm-pmic-min-microvolts'.
Does this need to be described in DT, can it not be queried from the PMIC?
Cheers
Jon
--
nvpublic
_______________________________________________
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 2/8] KVM: arm/arm64: Re-factor setting the Stage 2 entry to exec on fault
From: Christoffer Dall @ 2018-12-10 8:59 UTC (permalink / raw)
To: Anshuman Khandual
Cc: suzuki.poulose, marc.zyngier, Punit Agrawal, will.deacon,
linux-kernel, punitagrawal, kvmarm, linux-arm-kernel
In-Reply-To: <12212830-ffc6-a0e0-5de6-3e6a15ed7141@arm.com>
On Mon, Dec 03, 2018 at 07:02:23PM +0530, Anshuman Khandual wrote:
>
>
> On 10/31/2018 11:27 PM, Punit Agrawal wrote:
> > Stage 2 fault handler marks a page as executable if it is handling an
> > execution fault or if it was a permission fault in which case the
> > executable bit needs to be preserved.
> >
> > The logic to decide if the page should be marked executable is
> > duplicated for PMD and PTE entries. To avoid creating another copy
> > when support for PUD hugepages is introduced refactor the code to
> > share the checks needed to mark a page table entry as executable.
> >
> > Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> > Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Christoffer Dall <christoffer.dall@arm.com>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> > virt/kvm/arm/mmu.c | 28 +++++++++++++++-------------
> > 1 file changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> > index 59595207c5e1..6912529946fb 100644
> > --- a/virt/kvm/arm/mmu.c
> > +++ b/virt/kvm/arm/mmu.c
> > @@ -1475,7 +1475,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> > unsigned long fault_status)
> > {
> > int ret;
> > - bool write_fault, exec_fault, writable, force_pte = false;
> > + bool write_fault, writable, force_pte = false;
> > + bool exec_fault, needs_exec;
>
> New line not required, still within 80 characters.
>
He's trying to logically group the two variables. I don't see a problem
with that.
Thanks,
Christoffer
_______________________________________________
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 RESEND] ARM: dma-mapping: update comment about handling dma_ops when detaching from IOMMU
From: Wolfram Sang @ 2018-12-10 8:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, Wolfram Sang, Geert Uytterhoeven, Russell King,
Linux ARM
In-Reply-To: <CAMuHMdVpRYSCyho4n2R8p2s4WV1bXv8MM4VbMA9NVJjwT_rHzg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]
Hi Geert,
> Probably you should contact Russell's patch system, instead of Russell's
> human email instance, cfr. Documentation/arm/README
I didn't do this so far because rmk's patch tracker says "please submit
all patches to the linux-arm-kernel mailing list for community review
prior to submission here."
But hey, you reviewed it, maybe this will do :)
Thanks,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] KVM: arm/arm64: Share common code in user_mem_abort()
From: Christoffer Dall @ 2018-12-10 8:56 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Anshuman Khandual, marc.zyngier, will.deacon, linux-kernel,
punitagrawal, kvmarm, linux-arm-kernel
In-Reply-To: <8fd34e5f-7d75-4de2-3fee-d6d70805685c@arm.com>
On Mon, Dec 03, 2018 at 01:37:37PM +0000, Suzuki K Poulose wrote:
> Hi Anshuman,
>
> On 03/12/2018 12:11, Anshuman Khandual wrote:
> >
> >
> >On 10/31/2018 11:27 PM, Punit Agrawal wrote:
> >>The code for operations such as marking the pfn as dirty, and
> >>dcache/icache maintenance during stage 2 fault handling is duplicated
> >>between normal pages and PMD hugepages.
> >>
> >>Instead of creating another copy of the operations when we introduce
> >>PUD hugepages, let's share them across the different pagesizes.
> >>
> >>Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> >>Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >>Cc: Christoffer Dall <christoffer.dall@arm.com>
> >>Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>---
> >> virt/kvm/arm/mmu.c | 49 ++++++++++++++++++++++++++++------------------
> >> 1 file changed, 30 insertions(+), 19 deletions(-)
> >>
> >>diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >>index 5eca48bdb1a6..59595207c5e1 100644
> >>--- a/virt/kvm/arm/mmu.c
> >>+++ b/virt/kvm/arm/mmu.c
> >>@@ -1475,7 +1475,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> unsigned long fault_status)
> >> {
> >> int ret;
> >>- bool write_fault, exec_fault, writable, hugetlb = false, force_pte = false;
> >>+ bool write_fault, exec_fault, writable, force_pte = false;
> >> unsigned long mmu_seq;
> >> gfn_t gfn = fault_ipa >> PAGE_SHIFT;
> >> struct kvm *kvm = vcpu->kvm;
> >>@@ -1484,7 +1484,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> kvm_pfn_t pfn;
> >> pgprot_t mem_type = PAGE_S2;
> >> bool logging_active = memslot_is_logging(memslot);
> >>- unsigned long flags = 0;
> >>+ unsigned long vma_pagesize, flags = 0;
> >
> >A small nit s/vma_pagesize/pagesize. Why call it VMA ? Its implicit.
>
> May be we could call it mapsize. pagesize is confusing.
>
I'm ok with mapsize. I see the vma_pagesize name coming from the fact
that this is initially set to the return value from vma_kernel_pagesize.
I have not problems with either vma_pagesize or mapsize.
> >
> >> write_fault = kvm_is_write_fault(vcpu);
> >> exec_fault = kvm_vcpu_trap_is_iabt(vcpu);
> >>@@ -1504,10 +1504,16 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> return -EFAULT;
> >> }
> >>- if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
> >>- hugetlb = true;
> >>+ vma_pagesize = vma_kernel_pagesize(vma);
> >>+ if (vma_pagesize == PMD_SIZE && !logging_active) {
> >> gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
> >> } else {
> >>+ /*
> >>+ * Fallback to PTE if it's not one of the Stage 2
> >>+ * supported hugepage sizes
> >>+ */
> >>+ vma_pagesize = PAGE_SIZE;
> >
> >This seems redundant and should be dropped. vma_kernel_pagesize() here either
> >calls hugetlb_vm_op_pagesize (via hugetlb_vm_ops->pagesize) or simply returns
> >PAGE_SIZE. The vm_ops path is taken if the QEMU VMA covering any given HVA is
> >backed either by HugeTLB pages or simply normal pages. vma_pagesize would
> >either has a value of PMD_SIZE (HugeTLB hstate based) or PAGE_SIZE. Hence if
> >its not PMD_SIZE it must be PAGE_SIZE which should not be assigned again.
>
> We may want to force using the PTE mappings when logging_active (e.g, migration
> ?) to prevent keep tracking of huge pages. So the check is still valid.
>
>
Agreed, and let's not try additionally change the logic and flow with
this patch.
> >
> >>+
> >> /*
> >> * Pages belonging to memslots that don't have the same
> >> * alignment for userspace and IPA cannot be mapped using
> >>@@ -1573,23 +1579,33 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> if (mmu_notifier_retry(kvm, mmu_seq))
> >> goto out_unlock;
> >>- if (!hugetlb && !force_pte)
> >>- hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
> >>+ if (vma_pagesize == PAGE_SIZE && !force_pte) {
> >>+ /*
> >>+ * Only PMD_SIZE transparent hugepages(THP) are
> >>+ * currently supported. This code will need to be
> >>+ * updated to support other THP sizes.
> >>+ */
> >
> >This comment belongs to transparent_hugepage_adjust() but not here.
>
> I think this is relevant here than in thp_adjust, unless we rename
> the function below to something generic, handle_hugepage_adjust().
>
Agreed.
> >>+ if (transparent_hugepage_adjust(&pfn, &fault_ipa))
> >>+ vma_pagesize = PMD_SIZE;
> >
> >IIUC transparent_hugepage_adjust() is only getting called here. Instead of
> >returning 'true' when it is able to detect a huge page backing and doing
> >an adjustment there after, it should rather return THP size (PMD_SIZE) to
> >accommodate probable multi size THP support in future .
>
> That makes sense.
>
That's fine.
> >
> >>+ }
> >>+
> >>+ if (writable)
> >>+ kvm_set_pfn_dirty(pfn);
> >>- if (hugetlb) {
> >>+ if (fault_status != FSC_PERM)
> >>+ clean_dcache_guest_page(pfn, vma_pagesize);
> >>+
> >>+ if (exec_fault)
> >>+ invalidate_icache_guest_page(pfn, vma_pagesize);
> >>+
> >>+ if (vma_pagesize == PMD_SIZE) {
> >> pmd_t new_pmd = pfn_pmd(pfn, mem_type);
> >> new_pmd = pmd_mkhuge(new_pmd);
> >>- if (writable) {
> >>+ if (writable)
> >> new_pmd = kvm_s2pmd_mkwrite(new_pmd);
> >>- kvm_set_pfn_dirty(pfn);
> >>- }
> >>-
> >>- if (fault_status != FSC_PERM)
> >>- clean_dcache_guest_page(pfn, PMD_SIZE);
> >> if (exec_fault) {
> >> new_pmd = kvm_s2pmd_mkexec(new_pmd);
> >>- invalidate_icache_guest_page(pfn, PMD_SIZE);
> >> } else if (fault_status == FSC_PERM) {
> >> /* Preserve execute if XN was already cleared */
> >> if (stage2_is_exec(kvm, fault_ipa))
> >>@@ -1602,16 +1618,11 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >> if (writable) {
> >> new_pte = kvm_s2pte_mkwrite(new_pte);
> >>- kvm_set_pfn_dirty(pfn);
> >> mark_page_dirty(kvm, gfn);
> >> }
> >>- if (fault_status != FSC_PERM)
> >>- clean_dcache_guest_page(pfn, PAGE_SIZE);
> >>-
> >> if (exec_fault) {
> >> new_pte = kvm_s2pte_mkexec(new_pte);
> >>- invalidate_icache_guest_page(pfn, PAGE_SIZE);
> >> } else if (fault_status == FSC_PERM) {
> >> /* Preserve execute if XN was already cleared */
> >> if (stage2_is_exec(kvm, fault_ipa))
> >>
> >
> >kvm_set_pfn_dirty, clean_dcache_guest_page, invalidate_icache_guest_page
> >can all be safely moved before setting the page table entries either as
> >PMD or PTE.
>
> I think this is what we do currently. So I assume this is fine.
>
Agreed, I don't understand the comment raised by Anshuman here.
Thanks,
Christoffer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 6/6] perf cs-etm: Generate branch sample for exception packet
From: Leo Yan @ 2018-12-10 8:53 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Robert Walker, Mike Leach, Leo Yan
In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org>
The exception packet appears as one element with 'elem_type' ==
OCSD_GEN_TRC_ELEM_EXCEPTION or OCSD_GEN_TRC_ELEM_EXCEPTION_RET,
which present for exception entry and exit respectively. The decoder
set packet fields 'packet->exc' and 'packet->exc_ret' to indicate the
exception packets; but exception packets don't have dedicated sample
type and shares the same sample type CS_ETM_RANGE with normal
instruction packets.
As result, the exception packets are taken as normal instruction packets
and this introduces confusion to mix different packet types.
Furthermore, these instruction range packets will be processed for
branch sample only when 'packet->last_instr_taken_branch' is true,
otherwise they will be omitted, this can introduce mess for exception
and exception returning due we don't have complete address range info
for context switching.
To process exception packets properly, this patch introduce two new
sample type: CS_ETM_EXCEPTION and CS_ETM_EXCEPTION_RET; for these two
kind packets, they will be handled by cs_etm__exception(). The func
cs_etm__exception() forces to set previous CS_ETM_RANGE packet flag
'prev_packet->last_instr_taken_branch' to true, this matches well with
the program flow when the exception is trapped from user space to kernel
space, no matter if the most recent flow has branch taken or not; this
is also safe for returning to user space after exception handling.
After exception packets have their own sample type, the packet fields
'packet->exc' and 'packet->exc_ret' aren't needed anymore, so remove
them.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Robert Walker <robert.walker@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 26 +++++++++++++++++------
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 4 ++--
tools/perf/util/cs-etm.c | 28 +++++++++++++++++++++++++
3 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index bcb5c98..6d89d0e 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -291,8 +291,6 @@ static void cs_etm_decoder__clear_buffer(struct cs_etm_decoder *decoder)
decoder->packet_buffer[i].instr_count = 0;
decoder->packet_buffer[i].last_instr_taken_branch = false;
decoder->packet_buffer[i].last_instr_size = 0;
- decoder->packet_buffer[i].exc = false;
- decoder->packet_buffer[i].exc_ret = false;
decoder->packet_buffer[i].cpu = INT_MIN;
}
}
@@ -320,8 +318,6 @@ cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
decoder->packet_buffer[et].sample_type = sample_type;
decoder->packet_buffer[et].isa = CS_ETM_ISA_UNKNOWN;
- decoder->packet_buffer[et].exc = false;
- decoder->packet_buffer[et].exc_ret = false;
decoder->packet_buffer[et].cpu = *((int *)inode->priv);
decoder->packet_buffer[et].start_addr = CS_ETM_INVAL_ADDR;
decoder->packet_buffer[et].end_addr = CS_ETM_INVAL_ADDR;
@@ -398,6 +394,22 @@ cs_etm_decoder__buffer_discontinuity(struct cs_etm_decoder *decoder,
CS_ETM_DISCONTINUITY);
}
+static ocsd_datapath_resp_t
+cs_etm_decoder__buffer_exception(struct cs_etm_decoder *decoder,
+ const uint8_t trace_chan_id)
+{
+ return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
+ CS_ETM_EXCEPTION);
+}
+
+static ocsd_datapath_resp_t
+cs_etm_decoder__buffer_exception_ret(struct cs_etm_decoder *decoder,
+ const uint8_t trace_chan_id)
+{
+ return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
+ CS_ETM_EXCEPTION_RET);
+}
+
static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
const void *context,
const ocsd_trc_index_t indx __maybe_unused,
@@ -426,10 +438,12 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_EXCEPTION:
- decoder->packet_buffer[decoder->tail].exc = true;
+ resp = cs_etm_decoder__buffer_exception(decoder,
+ trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_EXCEPTION_RET:
- decoder->packet_buffer[decoder->tail].exc_ret = true;
+ resp = cs_etm_decoder__buffer_exception_ret(decoder,
+ trace_chan_id);
break;
case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
case OCSD_GEN_TRC_ELEM_ADDR_NACC:
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index a272317..a6407d4 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -26,6 +26,8 @@ enum cs_etm_sample_type {
CS_ETM_EMPTY,
CS_ETM_RANGE,
CS_ETM_DISCONTINUITY,
+ CS_ETM_EXCEPTION,
+ CS_ETM_EXCEPTION_RET,
};
enum cs_etm_isa {
@@ -43,8 +45,6 @@ struct cs_etm_packet {
u32 instr_count;
u8 last_instr_taken_branch;
u8 last_instr_size;
- u8 exc;
- u8 exc_ret;
int cpu;
};
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index cea3158..27a374d 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1000,6 +1000,25 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
return 0;
}
+static int cs_etm__exception(struct cs_etm_queue *etmq)
+{
+ /*
+ * When the exception packet is inserted, whether the last instruction
+ * in previous range packet is taken branch or not, we need to force
+ * to set 'prev_packet->last_instr_taken_branch' to true. This ensures
+ * to generate branch sample for the instruction range before the
+ * exception is trapped to kernel or before the exception returning.
+ *
+ * The exception packet includes the dummy address values, so don't
+ * swap PACKET with PREV_PACKET. This keeps PREV_PACKET to be useful
+ * for generating instruction and branch samples.
+ */
+ if (etmq->prev_packet->sample_type == CS_ETM_RANGE)
+ etmq->prev_packet->last_instr_taken_branch = true;
+
+ return 0;
+}
+
static int cs_etm__flush(struct cs_etm_queue *etmq)
{
int err = 0;
@@ -1148,6 +1167,15 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
*/
cs_etm__sample(etmq);
break;
+ case CS_ETM_EXCEPTION:
+ case CS_ETM_EXCEPTION_RET:
+ /*
+ * If the exception packet is coming,
+ * make sure the previous instruction
+ * range packet to be handled properly.
+ */
+ cs_etm__exception(etmq);
+ break;
case CS_ETM_DISCONTINUITY:
/*
* Discontinuity in trace, flush
--
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 related
* [PATCH v2 5/6] perf cs-etm: Treat EO_TRACE element as trace discontinuity
From: Leo Yan @ 2018-12-10 8:53 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Robert Walker, Mike Leach, Leo Yan
In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org>
If decoder outputs EO_TRACE element, it means the end of the trace
buffer; this is a discontinuity and in this case the end of trace data
needs to be saved.
This patch generates CS_ETM_DISCONTINUITY packet for EO_TRACE element
hereby flushing the end of trace data in cs-etm.c.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Robert Walker <robert.walker@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 46b67f1..bcb5c98 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -411,6 +411,7 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
case OCSD_GEN_TRC_ELEM_UNKNOWN:
break;
case OCSD_GEN_TRC_ELEM_NO_SYNC:
+ case OCSD_GEN_TRC_ELEM_EO_TRACE:
resp = cs_etm_decoder__buffer_discontinuity(decoder,
trace_chan_id);
decoder->trace_on = false;
@@ -431,7 +432,6 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
decoder->packet_buffer[decoder->tail].exc_ret = true;
break;
case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
- case OCSD_GEN_TRC_ELEM_EO_TRACE:
case OCSD_GEN_TRC_ELEM_ADDR_NACC:
case OCSD_GEN_TRC_ELEM_TIMESTAMP:
case OCSD_GEN_TRC_ELEM_CYCLE_COUNT:
--
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 related
* [PATCH v2 4/6] perf cs-etm: Treat NO_SYNC element as trace discontinuity
From: Leo Yan @ 2018-12-10 8:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Robert Walker, Mike Leach, Leo Yan
In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org>
CoreSight tracer driver might insert barrier packet between different
buffers, thus the decoder can spot the boundaries based on the barrier
packet; the decoder is possible to hit a barrier packet and emit a
NO_SYNC element, then the decoder will find a periodic synchronisation
point inside that next trace block that starts trace again but does not
have the TRACE_ON element as indicator - usually because this block of
trace has wrapped the buffer so we have lost the original point that
trace was enabled.
In upper case, it results in the trace stream only inserts the
OCSD_GEN_TRC_ELEM_NO_SYNC element in the middle of tracing stream, but
we don't handle NO_SYNC element properly and at the end users miss to
see the info for trace discontinuity.
Though OCSD_GEN_TRC_ELEM_NO_SYNC is different from CS_ETM_TRACE_ON when
output from the decoder, but both of them indicate the trace data is
discontinuous; this patch treats OCSD_GEN_TRC_ELEM_NO_SYNC as trace
discontinuity and generates CS_ETM_DISCONTINUITY packet for it, so
cs-etm can handle discontinuity for this case, finally it saves the last
trace data for previous trace block and restart samples for new block.
Credit to Mike Leach and Robert Walker who made me clear for underlying
mechanism for NO_SYNC element, Mike also shared with me for detailed
explanation for why we can treat NO_SYNC and TRACE_ON elements as the
same, so this commit log reused most of his explanation.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Robert Walker <robert.walker@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index a3994f1..46b67f1 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -411,6 +411,8 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
case OCSD_GEN_TRC_ELEM_UNKNOWN:
break;
case OCSD_GEN_TRC_ELEM_NO_SYNC:
+ resp = cs_etm_decoder__buffer_discontinuity(decoder,
+ trace_chan_id);
decoder->trace_on = false;
break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
--
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 related
* [PATCH v2 3/6] perf cs-etm: Rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY
From: Leo Yan @ 2018-12-10 8:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Robert Walker, Mike Leach, Leo Yan
In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org>
TRACE_ON element is used at the beginning of trace, it also can be
appeared in the middle of trace data to indicate discontinuity; for
example, it's possible to see multiple TRACE_ON elements in the trace
stream if the trace is being limited by address range filtering.
Furthermore, except TRACE_ON element is for discontinuity, NO_SYNC and
EO_TRACE also can be used to indicate discontinuity, though they are
used for different scenarios for trace is interrupted.
This patch is to rename sample type CS_ETM_TRACE_ON to
CS_ETM_DISCONTINUITY, firstly the new name describes more closely the
purpose of the packet; secondly this is a preparation for other output
elements which also cause the trace discontinuity thus they can share
the same one packet type.
This patch also refactors the enumerations in cs_etm_sample_type by
converting from bit shifting value to continuous numbers.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Robert Walker <robert.walker@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 +++++-----
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 +++---
tools/perf/util/cs-etm.c | 12 ++++++------
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 0b4c862..a3994f1 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -391,11 +391,11 @@ cs_etm_decoder__buffer_range(struct cs_etm_decoder *decoder,
}
static ocsd_datapath_resp_t
-cs_etm_decoder__buffer_trace_on(struct cs_etm_decoder *decoder,
- const uint8_t trace_chan_id)
+cs_etm_decoder__buffer_discontinuity(struct cs_etm_decoder *decoder,
+ const uint8_t trace_chan_id)
{
return cs_etm_decoder__buffer_packet(decoder, trace_chan_id,
- CS_ETM_TRACE_ON);
+ CS_ETM_DISCONTINUITY);
}
static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
@@ -414,8 +414,8 @@ static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
decoder->trace_on = false;
break;
case OCSD_GEN_TRC_ELEM_TRACE_ON:
- resp = cs_etm_decoder__buffer_trace_on(decoder,
- trace_chan_id);
+ resp = cs_etm_decoder__buffer_discontinuity(decoder,
+ trace_chan_id);
decoder->trace_on = true;
break;
case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
index b295dd2..a272317 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
@@ -23,9 +23,9 @@ struct cs_etm_buffer {
};
enum cs_etm_sample_type {
- CS_ETM_EMPTY = 0,
- CS_ETM_RANGE = 1 << 0,
- CS_ETM_TRACE_ON = 1 << 1,
+ CS_ETM_EMPTY,
+ CS_ETM_RANGE,
+ CS_ETM_DISCONTINUITY,
};
enum cs_etm_isa {
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index ffc4fe5..cea3158 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -562,8 +562,8 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
{
- /* Returns 0 for the CS_ETM_TRACE_ON packet */
- if (packet->sample_type == CS_ETM_TRACE_ON)
+ /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
+ if (packet->sample_type == CS_ETM_DISCONTINUITY)
return 0;
return packet->start_addr;
@@ -572,8 +572,8 @@ static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
static inline
u64 cs_etm__last_executed_instr(const struct cs_etm_packet *packet)
{
- /* Returns 0 for the CS_ETM_TRACE_ON packet */
- if (packet->sample_type == CS_ETM_TRACE_ON)
+ /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
+ if (packet->sample_type == CS_ETM_DISCONTINUITY)
return 0;
return packet->end_addr - packet->last_instr_size;
@@ -972,7 +972,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
bool generate_sample = false;
/* Generate sample for tracing on packet */
- if (etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
+ if (etmq->prev_packet->sample_type == CS_ETM_DISCONTINUITY)
generate_sample = true;
/* Generate sample for branch taken packet */
@@ -1148,7 +1148,7 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
*/
cs_etm__sample(etmq);
break;
- case CS_ETM_TRACE_ON:
+ case CS_ETM_DISCONTINUITY:
/*
* Discontinuity in trace, flush
* previous branch stack
--
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 related
* [PATCH v2 2/6] perf cs-etm: Avoid stale branch samples when flush packet
From: Leo Yan @ 2018-12-10 8:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Robert Walker, Mike Leach, Leo Yan
In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org>
At the end of trace buffer handling, function cs_etm__flush() is invoked
to flush any remaining branch stack entries. As a side effect, it also
generates branch sample, because the 'etmq->packet' doesn't contains any
new coming packet but point to one stale packet after packets swapping,
so it wrongly makes synthesize branch samples with stale packet info.
We could review below detailed flow which causes issue:
Packet1: start_addr=0xffff000008b1fbf0 end_addr=0xffff000008b1fbfc
Packet2: start_addr=0xffff000008b1fb5c end_addr=0xffff000008b1fb6c
step 1: cs_etm__sample():
sample: ip=(0xffff000008b1fbfc-4) addr=0xffff000008b1fb5c
step 2: flush packet in cs_etm__run_decoder():
cs_etm__run_decoder()
`-> err = cs_etm__flush(etmq, false);
sample: ip=(0xffff000008b1fb6c-4) addr=0xffff000008b1fbf0
Packet1 and packet2 are two continuous packets, when packet2 is the new
coming packet, cs_etm__sample() generates branch sample for these two
packets and use [packet1::end_addr - 4 => packet2::start_addr] as branch
jump flow, thus we can see the first generated branch sample in step 1.
At the end of cs_etm__sample() it swaps packets so 'etm->prev_packet'=
packet2 and 'etm->packet'=packet1, so far it's okay for branch sample.
If packet2 is the last one packet in trace buffer, even there have no
any new coming packet, cs_etm__run_decoder() invokes cs_etm__flush() to
flush branch stack entries as expected, but it also generates branch
samples by taking 'etm->packet' as a new coming packet, thus the branch
jump flow is as [packet2::end_addr - 4 => packet1::start_addr]; this
is the second sample which is generated in step 2. So actually the
second sample is a stale sample and we should not generate it.
This patch introduces a new function cs_etm__end_block(), at the end of
trace block this function is invoked to only flush branch stack entries
and thus can avoid to generate branch sample for stale packet.
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Robert Walker <robert.walker@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 789707b..ffc4fe5 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1055,6 +1055,39 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
return err;
}
+static int cs_etm__end_block(struct cs_etm_queue *etmq)
+{
+ int err;
+
+ /*
+ * It has no new packet coming and 'etmq->packet' contains the stale
+ * packet which was set at the previous time with packets swapping;
+ * so skip to generate branch sample to avoid stale packet.
+ *
+ * For this case only flush branch stack and generate a last branch
+ * event for the branches left in the circular buffer at the end of
+ * the trace.
+ */
+ if (etmq->etm->synth_opts.last_branch &&
+ etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+ /*
+ * Use the address of the end of the last reported execution
+ * range.
+ */
+ u64 addr = cs_etm__last_executed_instr(etmq->prev_packet);
+
+ err = cs_etm__synth_instruction_sample(
+ etmq, addr,
+ etmq->period_instructions);
+ if (err)
+ return err;
+
+ etmq->period_instructions = 0;
+ }
+
+ return 0;
+}
+
static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
{
struct cs_etm_auxtrace *etm = etmq->etm;
@@ -1137,7 +1170,7 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
if (err == 0)
/* Flush any remaining branch stack entries */
- err = cs_etm__flush(etmq);
+ err = cs_etm__end_block(etmq);
}
return err;
--
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 related
* [PATCH v2 1/6] perf cs-etm: Correct packets swapping in cs_etm__flush()
From: Leo Yan @ 2018-12-10 8:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Robert Walker, Mike Leach, Leo Yan
In-Reply-To: <1544431981-24144-1-git-send-email-leo.yan@linaro.org>
The structure cs_etm_queue uses 'prev_packet' to point to previous
packet, this can be used to combine with new coming packet to generate
samples.
In function cs_etm__flush() it swaps packets only when the flag
'etm->synth_opts.last_branch' is true, this means that it will not
swap packets if without option '--itrace=il' to generate last branch
entries; thus for this case the 'prev_packet' doesn't point to the
correct previous packet and the stale packet still will be used to
generate sequential sample. Thus if dump trace with 'perf script'
command we can see the incorrect flow with the stale packet's address
info.
This patch corrects packets swapping in cs_etm__flush(); except using
the flag 'etm->synth_opts.last_branch' it also checks the another flag
'etm->sample_branches', if any flag is true then it swaps packets so
can save correct content to 'prev_packet'. Finally this can fix the
wrong program flow dumping issue.
The patch has a minor refactoring to use 'etm->synth_opts.last_branch'
instead of 'etmq->etm->synth_opts.last_branch' for condition checking,
this is consistent with that is done in cs_etm__sample().
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Robert Walker <robert.walker@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 23159c33..789707b 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1042,7 +1042,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
}
swap_packet:
- if (etmq->etm->synth_opts.last_branch) {
+ if (etm->sample_branches || etm->synth_opts.last_branch) {
/*
* Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
* the next incoming packet.
--
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 related
* [PATCH v2 0/6] perf cs-etm: Correct packets handling
From: Leo Yan @ 2018-12-10 8:52 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, linux-arm-kernel, linux-kernel,
Coresight ML
Cc: Leo Yan
perf cs-etm module converts decoder elements to packets and then we have
more context crossing packets to generate synthenize samples, finally
perf tool can faciliate samples for statistics and report the results.
This patch series is to address several issues found related with
packets handling and samples generation when worked firstly on branch
sample flags support for Arm CoreSight trace data, so this patch series
is dependency for sample flags setting, will send another dedicated
patch series for sample flags later.
In this patch series, the first two patches are mainly to fix issues in
cs_etm__flush(): patch 0001 corrects packets swapping in cs_etm__flush()
and this can fix the wrong branch sample caused by the missed packets
swapping; patch 0002 is to fix the wrong samples generation with stale
packets at the end of trace block.
Patch 0003 is to rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY, we use
a more general packet type to present trace discontinuity, so it can be
used by TRACE_ON event, and also can be used by NO_SYNC and EO_TRACE
elements.
Patch 0004 is used to support NO_SYNC packet, otherwise the trace
decoding cannot reflect the tracing discontinuity caused by NO_SYNC
packet.
Patch 0005 is used to support EO_TRACE packet, which also introduces
the tracing discontinuity at the end of trace and we should save last
trace data for it.
Patch 0006 is used to generate branch sample for exception packets.
This patch series is applied on the acme's perf/core branch [1] with
latest commit 4085fed6373f ("perf trace: Add ordered processing");
Since Rob's patch 'perf: Support for Arm A32/T32 instruction sets in
CoreSight trace' has been merged into perf/core branch, this patch
series can directly be applied onto perf/core branch.
With applying the dependency patch, this patch series has been tested
for branch samples dumping with below command on Juno board:
# perf script -F,-time,+ip,+sym,+dso,+addr,+symoff -k vmlinux
Changes from v1:
* Synced the consistent code in patch 0001 for condition checking.
* Introduced new function cs_etm__end_block() for flushing packet
at the end of trace block.
* Added new patch 0003 to rename CS_ETM_TRACE_ON to
CS_ETM_DISCONTINUITY.
* Used the same one packet type CS_ETM_DISCONTINUITY for all
trace discontinuity (include support TRACE_ON/EO_TRACE/NO_SYNC
packets).
* Removed tracking exception number patch, which will be added in
sample flag patch series.
Leo Yan (6):
perf cs-etm: Correct packets swapping in cs_etm__flush()
perf cs-etm: Avoid stale branch samples when flush packet
perf cs-etm: Rename CS_ETM_TRACE_ON to CS_ETM_DISCONTINUITY
perf cs-etm: Treat NO_SYNC element as trace discontinuity
perf cs-etm: Treat EO_TRACE element as trace discontinuity
perf cs-etm: Generate branch sample for exception packet
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 40 +++++++++----
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 10 ++--
tools/perf/util/cs-etm.c | 77 ++++++++++++++++++++++---
3 files changed, 102 insertions(+), 25 deletions(-)
--
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
* Re: [PATCH v5 0/7] spi: add support for octal mode
From: Boris Brezillon @ 2018-12-10 8:50 UTC (permalink / raw)
To: Yogesh Narayan Gaur
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Vignesh R,
robh@kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, marek.vasut@gmail.com,
frieder.schrempf@exceet.de, Mark Brown,
linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB572609DBC52F7496A656915E99A50@VI1PR04MB5726.eurprd04.prod.outlook.com>
On Mon, 10 Dec 2018 08:39:20 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Hi Boris,
>
> Sorry for confusion.
>
> My intention was just to point to the correct patch number only. Earlier you have asked Mark to pick the patch [1] but that patch number was not correct.
Look at the context in [1] (we have good reasons to reply inline instead
of top-posting). I asked Mark to pick "spi: nxp-fspi: add octal mode
flag bit for octal support", not the m25p80 changes. I was wrong
though, as the patch I pointed to depends on your nxp-fspi patchset
which as not been merged yet.
>
> [1] https://lkml.org/lkml/2018/12/5/758
_______________________________________________
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 01/19] dt-bindings: clock: tegra124-dfll: Update DFLL binding for PWM regulator
From: Joseph Lo @ 2018-12-10 8:49 UTC (permalink / raw)
To: Jon Hunter, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, devicetree, linux-clk, linux-arm-kernel
In-Reply-To: <af1211f0-dda0-bdde-f320-03e54f82d7e1@nvidia.com>
Hi Jon,
Thanks for reviewing this series.
On 12/7/18 9:41 PM, Jon Hunter wrote:
>
> On 04/12/2018 09:25, Joseph Lo wrote:
>> From: Peter De Schrijver <pdeschrijver@nvidia.com>
>>
>> Add new properties to configure the DFLL PWM regulator support. Also
>> add an example and make the I2C clock only required when I2C support is
>> used.
>>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>> Signed-off-by: Joseph Lo <josephl@nvidia.com>
>> ---
>> .../bindings/clock/nvidia,tegra124-dfll.txt | 73 ++++++++++++++++++-
>> 1 file changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>> index dff236f524a7..8c97600d2bad 100644
>> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
>> @@ -8,7 +8,6 @@ the fast CPU cluster. It consists of a free-running voltage controlled
>> oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
>> control module that will automatically adjust the VDD_CPU voltage by
>> communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
>> -Currently only the I2C mode is supported by these bindings.
>>
>> Required properties:
>> - compatible : should be "nvidia,tegra124-dfll"
>> @@ -45,10 +44,28 @@ Required properties for the control loop parameters:
>> Optional properties for the control loop parameters:
>> - nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM.
>>
>> +Optional properties for mode selection:
>> +- nvidia,pwm-to-pmic: Use PWM to control regulator rather then I2C.
>> +
>> Required properties for I2C mode:
>> - nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
>>
>> -Example:
>> +Required properties for PWM mode:
>> +- nvidia,pwm-period: period of PWM square wave in microseconds.
>> +- nvidia,init-uv: Regulator voltage in micro volts when PWM control is disabled.
>
> Maybe consider 'pwm-inactive-voltage-microvolt'.
Ah, I think I need to refine the description here. It should be
something like below.
- nvidia,pwm-init-microvolt : Regulator voltage in micro volts when
PWM control is initialized
This is the initial voltage that when we just initialize the DFLL
hardware for PWM output. And before we switch the CPU clock from PLLX to
DFLL, we will enable DFLL hardware in closed loop mode which will aplly
the DVFS table that was calculated from CVB table.
The original description maybe make you think that it's the working
voltage when it's under open-loop mode. But it's not. Sorry.
When we working on open-loop mode which will switch to low voltage range
which also follows the DVFS table. Not this one.
>
>> +- nvidia,align-offset-uv: Regulator voltage in micro volts when PWM control is
>> + enabled and PWM output is low.
>
> Would this be considered the minimum pwm active voltage?
This would be used for minimum voltage for LUT table, which is the table
that PMIC can output. The real minimum voltage in PWM mode still depends
on the CVB table.
So maybe change this one to 'nvidia,pwm-offset-uv'.
>
>> +- nvidia,align-step-uv: Voltage increase in micro volts corresponding to a
>> + 1/33th increase in duty cycle. Eg the voltage for 2/33th
>> + duty cycle would be:
>
> Maybe consider 'pwm-voltage-step-microvolt'.
Okay.
>
>> + nvidia,align-offset-uv + nvidia,align-step-uv * 2.
>> +- pinctrl-0: I/O pad configuration when PWM control is enabled.
>> +- pinctrl-1: I/O pad configuration when PWM control is disabled.
>> +- pinctrl-names: must include the following entries:
>> + - dvfs_pwm_enable: I/O pad configuration when PWM control is enabled.
>> + - dvfs_pwm_disable: I/O pad configuration when PWM control is disabled.
>
> Please see Rob's feedback on the above [0].
Yes, I did refer that comments in this patch. And fixed that in
description but missed for bindings ...
Thanks,
Joseph
>
> Cheers
> Jon
>
> [0] https://lore.kernel.org/patchwork/patch/885328/
>
_______________________________________________
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] spi-nor: Add Octal SPI support
From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw)
To: Vignesh R
Cc: devicetree, Yogesh Gaur, Tudor Ambarus, linux-kernel, Marek Vasut,
Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List
In-Reply-To: <0e4286ea-85d1-a909-17c0-47f9506b3e5a@ti.com>
On Sun, 9 Dec 2018 14:17:18 +0530
Vignesh R <vigneshr@ti.com> wrote:
> Hi Boris,
>
> On 03/10/18 10:26 PM, Vignesh R wrote:
> > This series adds support for octal mode of mt35x flash. Also, adds
> > support for OSPI version of Cadence QSPI controller.
> >
> > Based on top of patches adding basic support for mt35xu512aba here:
> > https://patchwork.ozlabs.org/cover/971437/
> >
> > Vignesh R (3):
> > mtd: spi-nor: Add Octal mode support for mt35xu512aba
>
>
> > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC
> > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
>
> Could you consider above two patches for v4.21 once [1][2] are merged?
>
> [1] https://patchwork.ozlabs.org/patch/1006717/
> [2] https://patchwork.ozlabs.org/patch/1006715/
I asked Tudor to have a look at those patches. I'll apply them once I
have his R-b.
>
> Let me know if this needs to be re-posted.
>
> >
> > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 +
> > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++
> > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++-
> > include/linux/mtd/spi-nor.h | 2 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
>
_______________________________________________
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] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw)
To: Vignesh R
Cc: devicetree, Yogesh Gaur, linux-kernel, Marek Vasut, Rob Herring,
linux-mtd, Brian Norris, Linux ARM Mailing List
In-Reply-To: <20181003165603.2579-4-vigneshr@ti.com>
On Wed, 3 Oct 2018 22:26:03 +0530
Vignesh R <vigneshr@ti.com> wrote:
> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
> It also has an integrated PHY. IP register layout is very
> similar to existing QSPI IP except for additional bits to support Octal
> and Octal DDR mode. Therefore, extend current driver to support Octal
> mode.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
> index e24db817154e..48b00e75a879 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -101,6 +101,7 @@ struct cqspi_st {
> #define CQSPI_INST_TYPE_SINGLE 0
> #define CQSPI_INST_TYPE_DUAL 1
> #define CQSPI_INST_TYPE_QUAD 2
> +#define CQSPI_INST_TYPE_OCTAL 3
>
> #define CQSPI_DUMMY_CLKS_PER_BYTE 8
> #define CQSPI_DUMMY_BYTES_MAX 4
> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read)
> case SNOR_PROTO_1_1_4:
> f_pdata->data_width = CQSPI_INST_TYPE_QUAD;
> break;
> + case SNOR_PROTO_1_1_8:
> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL;
> + break;
> default:
> return -EINVAL;
> }
> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
> SNOR_HWCAPS_READ_FAST |
> SNOR_HWCAPS_READ_1_1_2 |
> SNOR_HWCAPS_READ_1_1_4 |
> + SNOR_HWCAPS_READ_1_1_8 |
Is this really supported on qspi versions of this IP? I guess not given
the description in the commit message and the name of the new
compatible (ospi instead of qspi).
> SNOR_HWCAPS_PP,
> };
> struct platform_device *pdev = cqspi->pdev;
> @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = {
> .compatible = "ti,k2g-qspi",
> .data = (void *)CQSPI_NEEDS_WR_DELAY,
> },
> + {
> + .compatible = "ti,am654-ospi",
> + .data = (void *)CQSPI_NEEDS_WR_DELAY,
> + },
> { /* end of table */ }
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] i2c: at91: Save the bus clock frequency in adapter
From: Tudor.Ambarus @ 2018-12-10 8:41 UTC (permalink / raw)
To: wsa
Cc: alexandre.belloni, Tudor.Ambarus, linux-kernel, Ludovic.Desroches,
linux-i2c, linux-arm-kernel
In-Reply-To: <20181210084111.6938-1-tudor.ambarus@microchip.com>
From: Tudor Ambarus <tudor.ambarus@microchip.com>
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c clients that need to know the bus clock frequency in order to
compute their wake token (see atecc508a i2c client).
The clock-frequency value has to be propagated to the i2c clients, otherwise,
if they will not find the i2c bus clock frequency in the device tree, they
will have to make their own assumption of the clock frequency.
Spare the i2c clients of making wrong assumptions of the i2c bus clock
frequency and provide the bus clock frequency in adapter.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v2: no change
drivers/i2c/busses/i2c-at91.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 3f3e8b3bf5ff..9aa0937817ac 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -1124,6 +1124,7 @@ static int at91_twi_probe(struct platform_device *pdev)
dev->adapter.quirks = &at91_twi_quirks;
dev->adapter.dev.parent = dev->dev;
dev->adapter.nr = pdev->id;
+ dev->adapter.bus_freq_hz = bus_clk_rate;
dev->adapter.timeout = AT91_I2C_TIMEOUT;
dev->adapter.dev.of_node = pdev->dev.of_node;
--
2.9.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] i2c: enable buses to save their clock frequency in adapter
From: Tudor.Ambarus @ 2018-12-10 8:41 UTC (permalink / raw)
To: wsa
Cc: alexandre.belloni, Tudor.Ambarus, linux-kernel, Ludovic.Desroches,
linux-i2c, linux-arm-kernel
In-Reply-To: <20181210084111.6938-1-tudor.ambarus@microchip.com>
From: Tudor Ambarus <tudor.ambarus@microchip.com>
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c clients that need to know the bus clock frequency in order to
compute their wake token (see atecc508a i2c client).
The clock-frequency value has to be propagated to the i2c clients, otherwise,
if they will not find the i2c bus clock frequency in the device tree, they
will have to make their own assumption of the clock frequency.
Spare the i2c clients of making wrong assumptions of the i2c bus clock
frequency and enable the buses to save their clock frequency in adapter.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
v2: fix typo in R-b tag
include/linux/i2c.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 65b4eaed1d96..f238da204c49 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -677,6 +677,7 @@ struct i2c_adapter {
struct rt_mutex bus_lock;
struct rt_mutex mux_lock;
+ u32 bus_freq_hz;
int timeout; /* in jiffies */
int retries;
struct device dev; /* the adapter device */
--
2.9.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/2] i2c: enable buses to save their clock frequency in adapter
From: Tudor.Ambarus @ 2018-12-10 8:41 UTC (permalink / raw)
To: wsa
Cc: alexandre.belloni, Tudor.Ambarus, linux-kernel, Ludovic.Desroches,
linux-i2c, linux-arm-kernel
From: Tudor Ambarus <tudor.ambarus@microchip.com>
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c clients that need to know the bus clock frequency in order to
compute their wake token (see atecc508a i2c client).
The clock-frequency value has to be propagated to the i2c clients, otherwise,
if they will not find the i2c bus clock frequency in the device tree, they
will have to make their own assumption of the clock frequency.
Spare the i2c clients of making wrong assumptions of the i2c bus clock
frequency and enable the buses to save their clock frequency in adapter.
v2: fix typo in R-b tag
since rfc: reword commit messages
Tudor Ambarus (2):
i2c: enable buses to save their clock frequency in adapter
i2c: at91: Save the bus clock frequency in adapter
drivers/i2c/busses/i2c-at91.c | 1 +
include/linux/i2c.h | 1 +
2 files changed, 2 insertions(+)
--
2.9.4
_______________________________________________
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 RESEND] ARM: dma-mapping: update comment about handling dma_ops when detaching from IOMMU
From: Geert Uytterhoeven @ 2018-12-10 8:40 UTC (permalink / raw)
To: Wolfram Sang
Cc: Linux-Renesas, Wolfram Sang, Geert Uytterhoeven, Russell King,
Linux ARM
In-Reply-To: <20181209215154.GB5856@kunai>
Hi Wolfram,
On Sun, Dec 9, 2018 at 10:51 PM Wolfram Sang <wsa@the-dreams.de> wrote:
> On Mon, Oct 15, 2018 at 12:55:17PM +0200, Wolfram Sang wrote:
> > Update the comment because we don't set the pointer to NULL anymore.
> > Also use the correct pointer name 'dma_ops' instead of 'dma_map_ops'.
> >
> > Fixes: 1874619a7df4 ("ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()")
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Russell, is this patch in your realm? If not, whom should I contact?
Probably you should contact Russell's patch system, instead of Russell's
human email instance, cfr. Documentation/arm/README
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 v5 0/7] spi: add support for octal mode
From: Yogesh Narayan Gaur @ 2018-12-10 8:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Vignesh R,
robh@kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, marek.vasut@gmail.com,
frieder.schrempf@exceet.de, Mark Brown,
linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210092208.0971c3be@bbrezillon>
Hi Boris,
Sorry for confusion.
My intention was just to point to the correct patch number only. Earlier you have asked Mark to pick the patch [1] but that patch number was not correct.
[1] https://lkml.org/lkml/2018/12/5/758
--
Regards
Yogesh Gaur
> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Monday, December 10, 2018 1:52 PM
> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
> Cc: Mark Brown <broonie@kernel.org>; Vignesh R <vigneshr@ti.com>; linux-
> mtd@lists.infradead.org; marek.vasut@gmail.com; linux-spi@vger.kernel.org;
> devicetree@vger.kernel.org; robh@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; linux-arm-kernel@lists.infradead.org;
> computersforpeace@gmail.com; frieder.schrempf@exceet.de; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH v5 0/7] spi: add support for octal mode
>
> Hi Yogesh,
>
> On Mon, 10 Dec 2018 04:13:28 +0000
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
>
> > Hi Mark,
> >
> > Patch has been resend [1], this patch is depends on the series of patch[2] and
> this series has been applied by Boris already.
>
> You're still not asking the right person. Every patches touching things in
> drivers/mtd/ should be taken by me (or another MTD maintainer), and patches
> touching things in drivers/spi/ should be taken by Mark. So, the patch you're
> pointing to should be applied by me. Plus, I told you I would apply it after 4.21-
> rc1 because I don't want to deal with the mtd -> spi dependency.
>
> Please be patient.
>
> Regards,
>
> Boris
_______________________________________________
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 v6 8/8] mfd: axp20x: Add supported cells for AXP803
From: Quentin Schulz @ 2018-12-10 8:29 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Rutland, devicetree, linux-pm, Maxime Ripard,
Sebastian Reichel, linux-kernel, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Oskari Lemmela, arm-linux
In-Reply-To: <20181210062718.GO26661@dell>
[-- Attachment #1.1: Type: text/plain, Size: 2613 bytes --]
Hi Lee,
On Mon, Dec 10, 2018 at 06:27:18AM +0000, Lee Jones wrote:
> On Sat, 08 Dec 2018, Quentin Schulz wrote:
>
> > Hi Lee,
> >
> > On Fri, Dec 07, 2018 at 07:22:37PM +0000, Lee Jones wrote:
> > > On Fri, 07 Dec 2018, Vasily Khoruzhick wrote:
> > >
> > > > On Fri, Dec 7, 2018 at 8:40 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > >
> > > > > My OCD-dar is going crazy.
> > > > >
> > > > > Why haven't you used the same alignment as is already there?
> > > > >
> > > > > If it starts to run over 80-chars then bring the others back.
> > > > >
> > > > > Also why is there a single liner shoved in the middle of the
> > > > > multi-line entries? Please move the singles to the top or the
> > > > > bottom.
> > > >
> > > > Hi Lee,
> > > >
> > > > Could you please reformat it in the way that makes your OCD-dar happy?
> > > > It would be really nice to get
> > >
> > > I'm afraid not, for a multitude of reasons.
> > >
> > > The most important of which surround testing.
> > >
> > > > AC and battery support for APX8x3 merged -- it'll make Pinebook and
> > > > Teres-I pretty well supported by mainline kernel.
> > >
> > > That's great. A worthy cause indeed. So I'm sure you guys will want
> > > to turn the patch around in short order so that it's applied in time
> > > for the next merge window.
> > >
> >
> > Aren't the MFD cells probed in order?
> >
> > In that case, it makes little sense to short order them for this
> > particular device (X-Powers PMICs in general). It will just make the
> > system boot slower because of probe deferring.
> >
> > Why? As explained by Chen-Yu in v3[1], axp-gpios can be muxed as
> > regulators, thus should be probed before axp-regulators. axp-adc is
> > often used by axp-battery, axp-usb-power, axp-ac-power, thus should be
> > probed beforehand as well.
>
> If there are inter-dependencies between the devices, it makes sense to
> keep them in the most efficient order.
>
> > For the alignment that also triggered your OCD, I can send you a patch
> > the day you merge this one if it can help. I sent a few patches for this
> > driver that didn't respect the alignment so I'm fine fixing the mfd
> > cells (and eventually re-order them as I saw a few axp-gpio cells being
> > declared after axp-regulators).
>
> That's fine. Please send the patch (based on this set) right away.
>
Since Oskari sent a new version with an alignment fix patch and you
merged that version, I assume I do not have any work to do anymore on
this matter.
Thank you all for the patches,
Quentin
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v5 0/7] spi: add support for octal mode
From: Boris Brezillon @ 2018-12-10 8:22 UTC (permalink / raw)
To: Yogesh Narayan Gaur
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Vignesh R,
robh@kernel.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, marek.vasut@gmail.com,
frieder.schrempf@exceet.de, Mark Brown,
linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB572641541BB83E587541BBD099A50@VI1PR04MB5726.eurprd04.prod.outlook.com>
Hi Yogesh,
On Mon, 10 Dec 2018 04:13:28 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> Hi Mark,
>
> Patch has been resend [1], this patch is depends on the series of patch[2] and this series has been applied by Boris already.
You're still not asking the right person. Every patches touching
things in drivers/mtd/ should be taken by me (or another MTD
maintainer), and patches touching things in drivers/spi/ should be
taken by Mark. So, the patch you're pointing to should be applied by
me. Plus, I told you I would apply it after 4.21-rc1 because I don't
want to deal with the mtd -> spi dependency.
Please be patient.
Regards,
Boris
_______________________________________________
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 V6 0/9] clk: add imx7ulp clk support
From: Shawn Guo @ 2018-12-10 8:14 UTC (permalink / raw)
To: Stephen Boyd
Cc: Aisheng DONG, Jacky Bai, Anson Huang, mturquette@baylibre.com,
linux-kernel@vger.kernel.org, dl-linux-imx,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <154403886196.88331.15597466595875847820@swboyd.mtv.corp.google.com>
On Wed, Dec 05, 2018 at 11:41:01AM -0800, Stephen Boyd wrote:
> No worries, I fixed it up and merged to clk-next.
Hi Stephen,
In order to send imx7ulp device tree for 4.21, I pulled branch
clk-imx7ulp into IMX tree to resolve the dependency on clock ID
definitions. So please keep the branch stable, thanks.
Shawn
_______________________________________________
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