* [PATCH v9 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Jia He @ 2019-09-25 2:59 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
In-Reply-To: <20190925025922.176362-1-justin.he@arm.com>
We unconditionally set the HW_AFDBM capability and only enable it on
CPUs which really have the feature. But sometimes we need to know
whether this cpu has the capability of HW AF. So decouple AF from
DBM by new helper cpu_has_hw_af().
Signed-off-by: Jia He <justin.he@arm.com>
Suggested-by: Suzuki Poulose <Suzuki.Poulose@arm.com>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index c96ffa4722d3..c2e3abd39faa 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -667,6 +667,16 @@ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
default: return CONFIG_ARM64_PA_BITS;
}
}
+
+/* Check whether hardware update of the Access flag is supported */
+static inline bool cpu_has_hw_af(void)
+{
+ if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
+ return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
+
+ return false;
+}
+
#endif /* __ASSEMBLY__ */
#endif
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
From: Jia He @ 2019-09-25 2:59 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
In-Reply-To: <20190925025922.176362-1-justin.he@arm.com>
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He <justin.he@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/pgtable.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..2b035befb66d 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -868,6 +868,20 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying from user will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. We don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ WARN_ON(preemptible());
+
+ return !cpu_has_hw_af();
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Jia He @ 2019-09-25 2:59 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm, Suzuki Poulose
Cc: Ralph Campbell, Jia He, Anshuman Khandual, Alex Van Brunt,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner
In-Reply-To: <20190925025922.176362-1-justin.he@arm.com>
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
in case there can be some obscure use-case.(by Kirill)
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Signed-off-by: Jia He <justin.he@arm.com>
Reported-by: Yibo Cai <Yibo.Cai@arm.com>
---
mm/memory.c | 99 +++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 84 insertions(+), 15 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..a0a381b36ff2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2140,32 +2147,82 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
+static inline bool cow_user_page(struct page *dst, struct page *src,
+ struct vm_fault *vmf)
{
+ bool ret;
+ void *kaddr;
+ void __user *uaddr;
+ bool force_mkyoung;
+ struct vm_area_struct *vma = vmf->vma;
+ struct mm_struct *mm = vma->vm_mm;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
+ if (likely(src)) {
+ copy_user_highpage(dst, src, addr, vma);
+ return true;
+ }
+
/*
* If the source page was a PFN mapping, we don't have
* a "struct page" for it. We do a best-effort copy by
* just copying from the original user address. If that
* fails, we just zero-fill it. Live with it.
*/
- if (unlikely(!src)) {
- void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ kaddr = kmap_atomic(dst);
+ uaddr = (void __user *)(addr & PAGE_MASK);
+
+ /*
+ * On architectures with software "accessed" bits, we would
+ * take a double page fault, so mark it accessed here.
+ */
+ force_mkyoung = arch_faults_on_old_pte() && !pte_young(vmf->orig_pte);
+ if (force_mkyoung) {
+ pte_t entry;
+
+ vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, &vmf->ptl);
+ if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ /*
+ * Other thread has already handled the fault
+ * and we don't need to do anything. If it's
+ * not the case, the fault will be triggered
+ * again on the same address.
+ */
+ ret = false;
+ goto pte_unlock;
+ }
+
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr, vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ }
+ /*
+ * This really shouldn't fail, because the page is there
+ * in the page tables. But it might just be unreadable,
+ * in which case we just give up and fill the result with
+ * zeroes.
+ */
+ if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
/*
- * This really shouldn't fail, because the page is there
- * in the page tables. But it might just be unreadable,
- * in which case we just give up and fill the result with
- * zeroes.
+ * Give a warn in case there can be some obscure
+ * use-case
*/
- if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
- clear_page(kaddr);
- kunmap_atomic(kaddr);
- flush_dcache_page(dst);
- } else
- copy_user_highpage(dst, src, va, vma);
+ WARN_ON_ONCE(1);
+ clear_page(kaddr);
+ }
+
+ ret = true;
+
+pte_unlock:
+ if (force_mkyoung)
+ pte_unmap_unlock(vmf->pte, vmf->ptl);
+ kunmap_atomic(kaddr);
+ flush_dcache_page(dst);
+
+ return ret;
}
static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
@@ -2318,7 +2375,19 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
vmf->address);
if (!new_page)
goto oom;
- cow_user_page(new_page, old_page, vmf->address, vma);
+
+ if (!cow_user_page(new_page, old_page, vmf)) {
+ /*
+ * COW failed, if the fault was solved by other,
+ * it's fine. If not, userspace would re-fault on
+ * the same address and we will handle the fault
+ * from the second attempt.
+ */
+ put_page(new_page);
+ if (old_page)
+ put_page(old_page);
+ return 0;
+ }
}
if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v9 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Justin He (Arm Technology China) @ 2019-09-25 3:03 UTC (permalink / raw)
To: Matthew Wilcox, Kirill A. Shutemov
Cc: Mark Rutland, Marc Zyngier, Ralph Campbell, Anshuman Khandual,
Will Deacon, Suzuki Poulose, linux-kernel@vger.kernel.org,
Alex Van Brunt, linux-mm@kvack.org,
Kaly Xin (Arm Technology China), Jérôme Glisse,
James Morse, Punit Agrawal, Catalin Marinas, hejianet@gmail.com,
Andrew Morton, nd, Robin Murphy, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190925025922.176362-4-justin.he@arm.com>
Hi Matthew and Kirill
I didn't add your previous r-b and a-b tag since I refactored the cow_user_page
and changed the ptl range in v9. Please have a review, thanks
--
Cheers,
Justin (Jia He)
> -----Original Message-----
> From: Jia He <justin.he@arm.com>
> Sent: 2019年9月25日 10:59
> To: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> <will@kernel.org>; Mark Rutland <Mark.Rutland@arm.com>; James Morse
> <James.Morse@arm.com>; Marc Zyngier <maz@kernel.org>; Matthew
> Wilcox <willy@infradead.org>; Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-mm@kvack.org; Suzuki Poulose
> <Suzuki.Poulose@arm.com>
> Cc: Punit Agrawal <punitagrawal@gmail.com>; Anshuman Khandual
> <Anshuman.Khandual@arm.com>; Alex Van Brunt
> <avanbrunt@nvidia.com>; Robin Murphy <Robin.Murphy@arm.com>;
> Thomas Gleixner <tglx@linutronix.de>; Andrew Morton <akpm@linux-
> foundation.org>; Jérôme Glisse <jglisse@redhat.com>; Ralph Campbell
> <rcampbell@nvidia.com>; hejianet@gmail.com; Kaly Xin (Arm Technology
> China) <Kaly.Xin@arm.com>; nd <nd@arm.com>; Justin He (Arm
> Technology China) <Justin.He@arm.com>
> Subject: [PATCH v9 3/3] mm: fix double page fault on arm64 if PTE_AF is
> cleared
>
> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest,
> there
> will be a double page fault in __copy_from_user_inatomic of
> cow_user_page.
>
> Below call trace is from arm64 do_page_fault for debugging purpose
> [ 110.016195] Call trace:
> [ 110.016826] do_page_fault+0x5a4/0x690
> [ 110.017812] do_mem_abort+0x50/0xb0
> [ 110.018726] el1_da+0x20/0xc4
> [ 110.019492] __arch_copy_from_user+0x180/0x280
> [ 110.020646] do_wp_page+0xb0/0x860
> [ 110.021517] __handle_mm_fault+0x994/0x1338
> [ 110.022606] handle_mm_fault+0xe8/0x180
> [ 110.023584] do_page_fault+0x240/0x690
> [ 110.024535] do_mem_abort+0x50/0xb0
> [ 110.025423] el0_da+0x20/0x24
>
> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003,
> pmd=000000023d4b3003, pte=360000298607bd3
>
> As told by Catalin: "On arm64 without hardware Access Flag, copying from
> user will fail because the pte is old and cannot be marked young. So we
> always end up with zeroed page after fork() + CoW for pfn mappings. we
> don't always have a hardware-managed access flag on arm64."
>
> This patch fix it by calling pte_mkyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
> in case there can be some obscure use-case.(by Kirill)
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Signed-off-by: Jia He <justin.he@arm.com>
> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> ---
> mm/memory.c | 99
> +++++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 84 insertions(+), 15 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..a0a381b36ff2 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> 2;
> #endif
>
> +#ifndef arch_faults_on_old_pte
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return false;
> +}
> +#endif
> +
> static int __init disable_randmaps(char *s)
> {
> randomize_va_space = 0;
> @@ -2140,32 +2147,82 @@ static inline int pte_unmap_same(struct
> mm_struct *mm, pmd_t *pmd,
> return same;
> }
>
> -static inline void cow_user_page(struct page *dst, struct page *src,
> unsigned long va, struct vm_area_struct *vma)
> +static inline bool cow_user_page(struct page *dst, struct page *src,
> + struct vm_fault *vmf)
> {
> + bool ret;
> + void *kaddr;
> + void __user *uaddr;
> + bool force_mkyoung;
> + struct vm_area_struct *vma = vmf->vma;
> + struct mm_struct *mm = vma->vm_mm;
> + unsigned long addr = vmf->address;
> +
> debug_dma_assert_idle(src);
>
> + if (likely(src)) {
> + copy_user_highpage(dst, src, addr, vma);
> + return true;
> + }
> +
> /*
> * If the source page was a PFN mapping, we don't have
> * a "struct page" for it. We do a best-effort copy by
> * just copying from the original user address. If that
> * fails, we just zero-fill it. Live with it.
> */
> - if (unlikely(!src)) {
> - void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> + kaddr = kmap_atomic(dst);
> + uaddr = (void __user *)(addr & PAGE_MASK);
> +
> + /*
> + * On architectures with software "accessed" bits, we would
> + * take a double page fault, so mark it accessed here.
> + */
> + force_mkyoung = arch_faults_on_old_pte() && !pte_young(vmf-
> >orig_pte);
> + if (force_mkyoung) {
> + pte_t entry;
> +
> + vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr,
> &vmf->ptl);
> + if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> + /*
> + * Other thread has already handled the fault
> + * and we don't need to do anything. If it's
> + * not the case, the fault will be triggered
> + * again on the same address.
> + */
> + ret = false;
> + goto pte_unlock;
> + }
> +
> + entry = pte_mkyoung(vmf->orig_pte);
> + if (ptep_set_access_flags(vma, addr, vmf->pte, entry, 0))
> + update_mmu_cache(vma, addr, vmf->pte);
> + }
>
> + /*
> + * This really shouldn't fail, because the page is there
> + * in the page tables. But it might just be unreadable,
> + * in which case we just give up and fill the result with
> + * zeroes.
> + */
> + if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
> /*
> - * This really shouldn't fail, because the page is there
> - * in the page tables. But it might just be unreadable,
> - * in which case we just give up and fill the result with
> - * zeroes.
> + * Give a warn in case there can be some obscure
> + * use-case
> */
> - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> - clear_page(kaddr);
> - kunmap_atomic(kaddr);
> - flush_dcache_page(dst);
> - } else
> - copy_user_highpage(dst, src, va, vma);
> + WARN_ON_ONCE(1);
> + clear_page(kaddr);
> + }
> +
> + ret = true;
> +
> +pte_unlock:
> + if (force_mkyoung)
> + pte_unmap_unlock(vmf->pte, vmf->ptl);
> + kunmap_atomic(kaddr);
> + flush_dcache_page(dst);
> +
> + return ret;
> }
>
> static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
> @@ -2318,7 +2375,19 @@ static vm_fault_t wp_page_copy(struct
> vm_fault *vmf)
> vmf->address);
> if (!new_page)
> goto oom;
> - cow_user_page(new_page, old_page, vmf->address, vma);
> +
> + if (!cow_user_page(new_page, old_page, vmf)) {
> + /*
> + * COW failed, if the fault was solved by other,
> + * it's fine. If not, userspace would re-fault on
> + * the same address and we will handle the fault
> + * from the second attempt.
> + */
> + put_page(new_page);
> + if (old_page)
> + put_page(old_page);
> + return 0;
> + }
> }
>
> if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL,
> &memcg, false))
> --
> 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Biwen Li @ 2019-09-25 3:13 UTC (permalink / raw)
To: Leo Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB667690EE76D327D0FC09F7818F840@AM0PR04MB6676.eurprd04.prod.outlook.com>
> >
> > The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata
> > A-008646 on LS1021A
> >
> > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > ---
> > Change in v3:
> > - rename property name
> > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> >
> > Change in v2:
> > - update desc of the property 'fsl,rcpm-scfg'
> >
> > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > index 5a33619d881d..157dcf6da17c 100644
> > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > Optional properties:
> > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > will be Big Endian (default case).
> > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC LS1021A,
>
> You probably should mention this is related to a hardware issue on LS1021a
> and only needed on LS1021a.
Okay, got it, thanks, I will add this in v4.
>
> > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
>
> #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.
> However you are defining an offset to scfg registers here. Why these two
> are related? The length here should actually be related to the #address-cells
> of the soc/. But since this is only needed for LS1021, you can just make it 3.
I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for IPPDEXPCR1).
But because of the hardware issue on LS1021A, I need store the value of IPPDEXPCR registers
to an alt address. So I defining an offset to scfg registers, then RCPM driver get an abosolute address from offset,
RCPM driver write the value of IPPDEXPCR registers to these abosolute addresses(backup the value of IPPDEXPCR registers).
>
> > + The first entry must be a link to the SCFG device node.
> > + The non-first entry must be offset of registers of SCFG.
> >
> > Example:
> > The RCPM node for T4240:
> > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > #fsl,rcpm-wakeup-cells = <2>;
> > };
> >
> > +The RCPM node for LS1021A:
> > + rcpm: rcpm@1ee2140 {
> > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
> > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > + #fsl,rcpm-wakeup-cells = <2>;
> > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > SCFG_SPARECR8 */
> > + };
> > +
> > +
> > * Freescale RCPM Wakeup Source Device Tree Bindings
> > -------------------------------------------
> > Required fsl,rcpm-wakeup property should be added to a device node if
> > the device
> > --
> > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Leo Li @ 2019-09-25 3:26 UTC (permalink / raw)
To: Biwen Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR04MB449034C4BBAA89685A2130F78F870@DB7PR04MB4490.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Biwen Li
> Sent: Tuesday, September 24, 2019 10:13 PM
> To: Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; Ran Wang
> <ran.wang_1@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicetree@vger.kernel.org
> Subject: RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-
> addr' property
>
> > >
> > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata
> > > A-008646 on LS1021A
> > >
> > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > ---
> > > Change in v3:
> > > - rename property name
> > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > >
> > > Change in v2:
> > > - update desc of the property 'fsl,rcpm-scfg'
> > >
> > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > ++++++++++++++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > index 5a33619d881d..157dcf6da17c 100644
> > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > Optional properties:
> > > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > will be Big Endian (default case).
> > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC LS1021A,
> >
> > You probably should mention this is related to a hardware issue on
> > LS1021a and only needed on LS1021a.
> Okay, got it, thanks, I will add this in v4.
> >
> > > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
> >
> > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.
> > However you are defining an offset to scfg registers here. Why these
> > two are related? The length here should actually be related to the
> > #address-cells of the soc/. But since this is only needed for LS1021, you can
> just make it 3.
> I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device
> node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for IPPDEXPCR1).
> But because of the hardware issue on LS1021A, I need store the value of
> IPPDEXPCR registers to an alt address. So I defining an offset to scfg registers,
> then RCPM driver get an abosolute address from offset, RCPM driver write
> the value of IPPDEXPCR registers to these abosolute addresses(backup the
> value of IPPDEXPCR registers).
I understand what you are trying to do. The problem is that the new fsl,ippdexpcr-alt-addr property contains a phandle and an offset. The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> >
> > > + The first entry must be a link to the SCFG device node.
> > > + The non-first entry must be offset of registers of SCFG.
> > >
> > > Example:
> > > The RCPM node for T4240:
> > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > #fsl,rcpm-wakeup-cells = <2>;
> > > };
> > >
> > > +The RCPM node for LS1021A:
> > > + rcpm: rcpm@1ee2140 {
> > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
> > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > + #fsl,rcpm-wakeup-cells = <2>;
> > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > SCFG_SPARECR8 */
> > > + };
> > > +
> > > +
> > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > -------------------------------------------
> > > Required fsl,rcpm-wakeup property should be added to a device node
> > > if the device
> > > --
> > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Biwen Li @ 2019-09-25 3:30 UTC (permalink / raw)
To: Leo Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB66762594DDFC6E5B00BD103C8F870@AM0PR04MB6676.eurprd04.prod.outlook.com>
> > > >
> > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata
> > > > A-008646 on LS1021A
> > > >
> > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > ---
> > > > Change in v3:
> > > > - rename property name
> > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > >
> > > > Change in v2:
> > > > - update desc of the property 'fsl,rcpm-scfg'
> > > >
> > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > ++++++++++++++
> > > > 1 file changed, 14 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > index 5a33619d881d..157dcf6da17c 100644
> > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > > Optional properties:
> > > > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > > will be Big Endian (default case).
> > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > + LS1021A,
> > >
> > > You probably should mention this is related to a hardware issue on
> > > LS1021a and only needed on LS1021a.
> > Okay, got it, thanks, I will add this in v4.
> > >
> > > > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
> > >
> > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.
> > > However you are defining an offset to scfg registers here. Why
> > > these two are related? The length here should actually be related
> > > to the #address-cells of the soc/. But since this is only needed
> > > for LS1021, you can
> > just make it 3.
> > I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device
> > node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for IPPDEXPCR1).
> > But because of the hardware issue on LS1021A, I need store the value
> > of IPPDEXPCR registers to an alt address. So I defining an offset to
> > scfg registers, then RCPM driver get an abosolute address from offset,
> > RCPM driver write the value of IPPDEXPCR registers to these abosolute
> > addresses(backup the value of IPPDEXPCR registers).
>
> I understand what you are trying to do. The problem is that the new
> fsl,ippdexpcr-alt-addr property contains a phandle and an offset. The size
> of it shouldn't be related to #fsl,rcpm-wakeup-cells.
You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/* SCFG_SPARECR8 */
>
> > >
> > > > + The first entry must be a link to the SCFG device node.
> > > > + The non-first entry must be offset of registers of SCFG.
> > > >
> > > > Example:
> > > > The RCPM node for T4240:
> > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > };
> > > >
> > > > +The RCPM node for LS1021A:
> > > > + rcpm: rcpm@1ee2140 {
> > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
> > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > SCFG_SPARECR8 */
> > > > + };
> > > > +
> > > > +
> > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > -------------------------------------------
> > > > Required fsl,rcpm-wakeup property should be added to a device
> > > > node if the device
> > > > --
> > > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Leo Li @ 2019-09-25 3:34 UTC (permalink / raw)
To: Biwen Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR04MB4490FECDC76507AADC35948E8F870@DB7PR04MB4490.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Biwen Li
> Sent: Tuesday, September 24, 2019 10:30 PM
> To: Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; Ran Wang
> <ran.wang_1@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicetree@vger.kernel.org
> Subject: RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-
> addr' property
>
> > > > >
> > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an
> > > > > errata
> > > > > A-008646 on LS1021A
> > > > >
> > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > ---
> > > > > Change in v3:
> > > > > - rename property name
> > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > >
> > > > > Change in v2:
> > > > > - update desc of the property 'fsl,rcpm-scfg'
> > > > >
> > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > ++++++++++++++
> > > > > 1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > > > Optional properties:
> > > > > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > > > will be Big Endian (default case).
> > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > > + LS1021A,
> > > >
> > > > You probably should mention this is related to a hardware issue on
> > > > LS1021a and only needed on LS1021a.
> > > Okay, got it, thanks, I will add this in v4.
> > > >
> > > > > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1 entries).
> > > >
> > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an SoC.
> > > > However you are defining an offset to scfg registers here. Why
> > > > these two are related? The length here should actually be related
> > > > to the #address-cells of the soc/. But since this is only needed
> > > > for LS1021, you can
> > > just make it 3.
> > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device
> > > node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for IPPDEXPCR1).
> > > But because of the hardware issue on LS1021A, I need store the value
> > > of IPPDEXPCR registers to an alt address. So I defining an offset to
> > > scfg registers, then RCPM driver get an abosolute address from
> > > offset, RCPM driver write the value of IPPDEXPCR registers to these
> > > abosolute addresses(backup the value of IPPDEXPCR registers).
> >
> > I understand what you are trying to do. The problem is that the new
> > fsl,ippdexpcr-alt-addr property contains a phandle and an offset. The
> > size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/*
> SCFG_SPARECR8 */
No. The #address-cell for the soc/ is 2, so the offset to scfg should be 0x0 0x51c. The total size should be 3, but it shouldn't be coming from #fsl,rcpm-wakeup-cells like you mentioned in the binding.
> >
> > > >
> > > > > + The first entry must be a link to the SCFG device node.
> > > > > + The non-first entry must be offset of registers of SCFG.
> > > > >
> > > > > Example:
> > > > > The RCPM node for T4240:
> > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > > };
> > > > >
> > > > > +The RCPM node for LS1021A:
> > > > > + rcpm: rcpm@1ee2140 {
> > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> 2.1+";
> > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > > SCFG_SPARECR8 */
> > > > > + };
> > > > > +
> > > > > +
> > > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > -------------------------------------------
> > > > > Required fsl,rcpm-wakeup property should be added to a device
> > > > > node if the device
> > > > > --
> > > > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 0/2] mm/debug: Add tests for architecture exported page table helpers
From: Anshuman Khandual @ 2019-09-25 3:36 UTC (permalink / raw)
To: Mike Rapoport, Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, Gerald Schaefer, linux-snps-arc,
linux-arm-kernel, Kees Cook, Masahiro Yamada, Mark Brown,
Dan Williams, Vlastimil Babka, Christophe Leroy,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller, Mike Kravetz
In-Reply-To: <20190924123146.GC5202@linux.ibm.com>
On 09/24/2019 06:01 PM, Mike Rapoport wrote:
> On Tue, Sep 24, 2019 at 02:51:01PM +0300, Kirill A. Shutemov wrote:
>> On Fri, Sep 20, 2019 at 12:03:21PM +0530, Anshuman Khandual wrote:
>>> This series adds a test validation for architecture exported page table
>>> helpers. Patch in the series adds basic transformation tests at various
>>> levels of the page table. Before that it exports gigantic page allocation
>>> function from HugeTLB.
>>>
>>> This test was originally suggested by Catalin during arm64 THP migration
>>> RFC discussion earlier. Going forward it can include more specific tests
>>> with respect to various generic MM functions like THP, HugeTLB etc and
>>> platform specific tests.
>>>
>>> https://lore.kernel.org/linux-mm/20190628102003.GA56463@arrakis.emea.arm.com/
>>>
>>> Testing:
>>>
>>> Successfully build and boot tested on both arm64 and x86 platforms without
>>> any test failing. Only build tested on some other platforms. Build failed
>>> on some platforms (known) in pud_clear_tests() as there were no available
>>> __pgd() definitions.
>>>
>>> - ARM32
>>> - IA64
>>
>> Hm. Grep shows __pgd() definitions for both of them. Is it for specific
>> config?
>
> For ARM32 it's defined only for 3-lelel page tables, i.e with LPAE on.
> For IA64 it's defined for !STRICT_MM_TYPECHECKS which is even not a config
> option, but a define in arch/ia64/include/asm/page.h
Right. So now where we go from here ! We will need help from platform folks to
fix this unless its trivial. I did propose this on last thread (v2), wondering if
it will be a better idea to restrict DEBUG_ARCH_PGTABLE_TEST among architectures
which have fixed all pending issues whether build or run time. Though enabling all
platforms where the test builds at the least might make more sense, we might have
to just exclude arm32 and ia64 for now. Then run time problems can be fixed later
platform by platform. Any thoughts ?
BTW the test is known to run successfully on arm64, x86, ppc32 platforms. Gerald
has been trying to get it working on s390. in the meantime., if there are other
volunteers to test this on ppc64, sparc, riscv, mips, m68k etc platforms, it will
be really helpful.
- Anshuman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Biwen Li @ 2019-09-25 3:47 UTC (permalink / raw)
To: Leo Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB6676BD24B814C3D1D67CF9F88F870@AM0PR04MB6676.eurprd04.prod.outlook.com>
> > > > > >
> > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an
> > > > > > errata
> > > > > > A-008646 on LS1021A
> > > > > >
> > > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > > ---
> > > > > > Change in v3:
> > > > > > - rename property name
> > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > > >
> > > > > > Change in v2:
> > > > > > - update desc of the property 'fsl,rcpm-scfg'
> > > > > >
> > > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > > ++++++++++++++
> > > > > > 1 file changed, 14 insertions(+)
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > > > > Optional properties:
> > > > > > - little-endian : RCPM register block is Little Endian. Without it
> RCPM
> > > > > > will be Big Endian (default case).
> > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > > > + LS1021A,
> > > > >
> > > > > You probably should mention this is related to a hardware issue
> > > > > on LS1021a and only needed on LS1021a.
> > > > Okay, got it, thanks, I will add this in v4.
> > > > >
> > > > > > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2 + 1
> entries).
> > > > >
> > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on an
> SoC.
> > > > > However you are defining an offset to scfg registers here. Why
> > > > > these two are related? The length here should actually be
> > > > > related to the #address-cells of the soc/. But since this is
> > > > > only needed for LS1021, you can
> > > > just make it 3.
> > > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0 device
> > > > node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > > > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for
> IPPDEXPCR1).
> > > > But because of the hardware issue on LS1021A, I need store the
> > > > value of IPPDEXPCR registers to an alt address. So I defining an
> > > > offset to scfg registers, then RCPM driver get an abosolute
> > > > address from offset, RCPM driver write the value of IPPDEXPCR
> > > > registers to these abosolute addresses(backup the value of IPPDEXPCR
> registers).
> > >
> > > I understand what you are trying to do. The problem is that the new
> > > fsl,ippdexpcr-alt-addr property contains a phandle and an offset.
> > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> > You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/*
> > SCFG_SPARECR8 */
>
> No. The #address-cell for the soc/ is 2, so the offset to scfg should be 0x0
> 0x51c. The total size should be 3, but it shouldn't be coming from
> #fsl,rcpm-wakeup-cells like you mentioned in the binding.
Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative with #address-cells instead of #fsl,rcpm-wakeup-cells.
>
> > >
> > > > >
> > > > > > + The first entry must be a link to the SCFG device node.
> > > > > > + The non-first entry must be offset of registers of SCFG.
> > > > > >
> > > > > > Example:
> > > > > > The RCPM node for T4240:
> > > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > > > };
> > > > > >
> > > > > > +The RCPM node for LS1021A:
> > > > > > + rcpm: rcpm@1ee2140 {
> > > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> > 2.1+";
> > > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > > > SCFG_SPARECR8 */
> > > > > > + };
> > > > > > +
> > > > > > +
> > > > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > -------------------------------------------
> > > > > > Required fsl,rcpm-wakeup property should be added to a device
> > > > > > node if the device
> > > > > > --
> > > > > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Leo Li @ 2019-09-25 3:48 UTC (permalink / raw)
To: Biwen Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR04MB4490EAE9591B5AE7112C9D188F870@DB7PR04MB4490.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Biwen Li
> Sent: Tuesday, September 24, 2019 10:47 PM
> To: Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; Ran Wang
> <ran.wang_1@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicetree@vger.kernel.org
> Subject: RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-
> addr' property
>
> > > > > > >
> > > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an
> > > > > > > errata
> > > > > > > A-008646 on LS1021A
> > > > > > >
> > > > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > > > ---
> > > > > > > Change in v3:
> > > > > > > - rename property name
> > > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > > > >
> > > > > > > Change in v2:
> > > > > > > - update desc of the property 'fsl,rcpm-scfg'
> > > > > > >
> > > > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > > > ++++++++++++++
> > > > > > > 1 file changed, 14 insertions(+)
> > > > > > >
> > > > > > > diff --git
> > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > @@ -34,6 +34,11 @@ Chassis Version Example
> Chips
> > > > > > > Optional properties:
> > > > > > > - little-endian : RCPM register block is Little Endian.
> > > > > > > Without it
> > RCPM
> > > > > > > will be Big Endian (default case).
> > > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > > > > + LS1021A,
> > > > > >
> > > > > > You probably should mention this is related to a hardware
> > > > > > issue on LS1021a and only needed on LS1021a.
> > > > > Okay, got it, thanks, I will add this in v4.
> > > > > >
> > > > > > > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such as:
> > > > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2 +
> > > > > > > + 1
> > entries).
> > > > > >
> > > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers on
> > > > > > an
> > SoC.
> > > > > > However you are defining an offset to scfg registers here.
> > > > > > Why these two are related? The length here should actually be
> > > > > > related to the #address-cells of the soc/. But since this is
> > > > > > only needed for LS1021, you can
> > > > > just make it 3.
> > > > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0
> > > > > device node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > > > > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for
> > IPPDEXPCR1).
> > > > > But because of the hardware issue on LS1021A, I need store the
> > > > > value of IPPDEXPCR registers to an alt address. So I defining an
> > > > > offset to scfg registers, then RCPM driver get an abosolute
> > > > > address from offset, RCPM driver write the value of IPPDEXPCR
> > > > > registers to these abosolute addresses(backup the value of
> > > > > IPPDEXPCR
> > registers).
> > > >
> > > > I understand what you are trying to do. The problem is that the
> > > > new fsl,ippdexpcr-alt-addr property contains a phandle and an offset.
> > > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> > > You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/*
> > > SCFG_SPARECR8 */
> >
> > No. The #address-cell for the soc/ is 2, so the offset to scfg should
> > be 0x0 0x51c. The total size should be 3, but it shouldn't be coming
> > from #fsl,rcpm-wakeup-cells like you mentioned in the binding.
> Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative with #address-cells
> instead of #fsl,rcpm-wakeup-cells.
Yes.
Regards,
Leo
> >
> > > >
> > > > > >
> > > > > > > + The first entry must be a link to the SCFG device node.
> > > > > > > + The non-first entry must be offset of registers of SCFG.
> > > > > > >
> > > > > > > Example:
> > > > > > > The RCPM node for T4240:
> > > > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > };
> > > > > > >
> > > > > > > +The RCPM node for LS1021A:
> > > > > > > + rcpm: rcpm@1ee2140 {
> > > > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> > > 2.1+";
> > > > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > > > > SCFG_SPARECR8 */
> > > > > > > + };
> > > > > > > +
> > > > > > > +
> > > > > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > -------------------------------------------
> > > > > > > Required fsl,rcpm-wakeup property should be added to a
> > > > > > > device node if the device
> > > > > > > --
> > > > > > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Biwen Li @ 2019-09-25 4:06 UTC (permalink / raw)
To: Leo Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB6676B8A6F7C7C3BC822B45B28F870@AM0PR04MB6676.eurprd04.prod.outlook.com>
> >
> > > > > > > >
> > > > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle an
> > > > > > > > errata
> > > > > > > > A-008646 on LS1021A
> > > > > > > >
> > > > > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > > > > ---
> > > > > > > > Change in v3:
> > > > > > > > - rename property name
> > > > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > > > > >
> > > > > > > > Change in v2:
> > > > > > > > - update desc of the property 'fsl,rcpm-scfg'
> > > > > > > >
> > > > > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > > > > ++++++++++++++
> > > > > > > > 1 file changed, 14 insertions(+)
> > > > > > > >
> > > > > > > > diff --git
> > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > @@ -34,6 +34,11 @@ Chassis Version Example
> > Chips
> > > > > > > > Optional properties:
> > > > > > > > - little-endian : RCPM register block is Little Endian.
> > > > > > > > Without it
> > > RCPM
> > > > > > > > will be Big Endian (default case).
> > > > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for SoC
> > > > > > > > + LS1021A,
> > > > > > >
> > > > > > > You probably should mention this is related to a hardware
> > > > > > > issue on LS1021a and only needed on LS1021a.
> > > > > > Okay, got it, thanks, I will add this in v4.
> > > > > > >
> > > > > > > > + Must include n + 1 entries (n = #fsl,rcpm-wakeup-cells, such
> as:
> > > > > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include 2
> > > > > > > > + +
> > > > > > > > + 1
> > > entries).
> > > > > > >
> > > > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR registers
> > > > > > > on an
> > > SoC.
> > > > > > > However you are defining an offset to scfg registers here.
> > > > > > > Why these two are related? The length here should actually
> > > > > > > be related to the #address-cells of the soc/. But since
> > > > > > > this is only needed for LS1021, you can
> > > > > > just make it 3.
> > > > > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0
> > > > > > device node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > > > > > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for
> > > IPPDEXPCR1).
> > > > > > But because of the hardware issue on LS1021A, I need store the
> > > > > > value of IPPDEXPCR registers to an alt address. So I defining
> > > > > > an offset to scfg registers, then RCPM driver get an abosolute
> > > > > > address from offset, RCPM driver write the value of IPPDEXPCR
> > > > > > registers to these abosolute addresses(backup the value of
> > > > > > IPPDEXPCR
> > > registers).
> > > > >
> > > > > I understand what you are trying to do. The problem is that the
> > > > > new fsl,ippdexpcr-alt-addr property contains a phandle and an offset.
> > > > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> > > > You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/*
> > > > SCFG_SPARECR8 */
> > >
> > > No. The #address-cell for the soc/ is 2, so the offset to scfg
> > > should be 0x0 0x51c. The total size should be 3, but it shouldn't
> > > be coming from #fsl,rcpm-wakeup-cells like you mentioned in the binding.
> > Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative with
> > #address-cells instead of #fsl,rcpm-wakeup-cells.
>
> Yes.
I got an example from drivers/pci/controller/dwc/pci-layerscape.c
and arch/arm/boot/dts/ls1021a.dtsi as follows:
fsl,pcie-scfg = <&scfg 0>, 0 is an index
In my fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>,
It means that 0x0 is an alt offset address for IPPDEXPCR0, 0x51c is an alt offset address
For IPPDEXPCR1 instead of 0x0 and 0x51c compose to an alt address of SCFG_SPARECR8.
>
> Regards,
> Leo
> > >
> > > > >
> > > > > > >
> > > > > > > > + The first entry must be a link to the SCFG device node.
> > > > > > > > + The non-first entry must be offset of registers of SCFG.
> > > > > > > >
> > > > > > > > Example:
> > > > > > > > The RCPM node for T4240:
> > > > > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > > };
> > > > > > > >
> > > > > > > > +The RCPM node for LS1021A:
> > > > > > > > + rcpm: rcpm@1ee2140 {
> > > > > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> > > > 2.1+";
> > > > > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > > > > > SCFG_SPARECR8 */
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > +
> > > > > > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > -------------------------------------------
> > > > > > > > Required fsl,rcpm-wakeup property should be added to a
> > > > > > > > device node if the device
> > > > > > > > --
> > > > > > > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v3,3/3] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr-alt-addr' property
From: Biwen Li @ 2019-09-25 4:21 UTC (permalink / raw)
To: Leo Li, shawnguo@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Ran Wang
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR04MB44902BADDDFD090BAF4178C68F870@DB7PR04MB4490.eurprd04.prod.outlook.com>
> > >
> > > > > > > > >
> > > > > > > > > The 'fsl,ippdexpcr-alt-addr' property is used to handle
> > > > > > > > > an errata
> > > > > > > > > A-008646 on LS1021A
> > > > > > > > >
> > > > > > > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > > > > > > ---
> > > > > > > > > Change in v3:
> > > > > > > > > - rename property name
> > > > > > > > > fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
> > > > > > > > >
> > > > > > > > > Change in v2:
> > > > > > > > > - update desc of the property 'fsl,rcpm-scfg'
> > > > > > > > >
> > > > > > > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14
> > > > > > > > > ++++++++++++++
> > > > > > > > > 1 file changed, 14 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > index 5a33619d881d..157dcf6da17c 100644
> > > > > > > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > > > > > > @@ -34,6 +34,11 @@ Chassis Version Example
> > > Chips
> > > > > > > > > Optional properties:
> > > > > > > > > - little-endian : RCPM register block is Little Endian.
> > > > > > > > > Without it
> > > > RCPM
> > > > > > > > > will be Big Endian (default case).
> > > > > > > > > + - fsl,ippdexpcr-alt-addr : Must add the property for
> > > > > > > > > + SoC LS1021A,
> > > > > > > >
> > > > > > > > You probably should mention this is related to a hardware
> > > > > > > > issue on LS1021a and only needed on LS1021a.
> > > > > > > Okay, got it, thanks, I will add this in v4.
> > > > > > > >
> > > > > > > > > + Must include n + 1 entries (n =
> > > > > > > > > + #fsl,rcpm-wakeup-cells, such
> > as:
> > > > > > > > > + #fsl,rcpm-wakeup-cells equal to 2, then must include
> > > > > > > > > + 2
> > > > > > > > > + +
> > > > > > > > > + 1
> > > > entries).
> > > > > > > >
> > > > > > > > #fsl,rcpm-wakeup-cells is the number of IPPDEXPCR
> > > > > > > > registers on an
> > > > SoC.
> > > > > > > > However you are defining an offset to scfg registers here.
> > > > > > > > Why these two are related? The length here should
> > > > > > > > actually be related to the #address-cells of the soc/.
> > > > > > > > But since this is only needed for LS1021, you can
> > > > > > > just make it 3.
> > > > > > > I need set the value of IPPDEXPCR resgiters from ftm_alarm0
> > > > > > > device node(fsl,rcpm-wakeup = <&rcpm 0x0 0x20000000>;
> > > > > > > 0x0 is a value for IPPDEXPCR0, 0x20000000 is a value for
> > > > IPPDEXPCR1).
> > > > > > > But because of the hardware issue on LS1021A, I need store
> > > > > > > the value of IPPDEXPCR registers to an alt address. So I
> > > > > > > defining an offset to scfg registers, then RCPM driver get
> > > > > > > an abosolute address from offset, RCPM driver write the
> > > > > > > value of IPPDEXPCR registers to these abosolute
> > > > > > > addresses(backup the value of IPPDEXPCR
> > > > registers).
> > > > > >
> > > > > > I understand what you are trying to do. The problem is that
> > > > > > the new fsl,ippdexpcr-alt-addr property contains a phandle and an
> offset.
> > > > > > The size of it shouldn't be related to #fsl,rcpm-wakeup-cells.
> > > > > You maybe like this: fsl,ippdexpcr-alt-addr = <&scfg 0x51c>;/*
> > > > > SCFG_SPARECR8 */
> > > >
> > > > No. The #address-cell for the soc/ is 2, so the offset to scfg
> > > > should be 0x0 0x51c. The total size should be 3, but it shouldn't
> > > > be coming from #fsl,rcpm-wakeup-cells like you mentioned in the
> binding.
> > > Oh, I got it. You want that fsl,ippdexpcr-alt-add is relative with
> > > #address-cells instead of #fsl,rcpm-wakeup-cells.
> >
> > Yes.
> I got an example from drivers/pci/controller/dwc/pci-layerscape.c
> and arch/arm/boot/dts/ls1021a.dtsi as follows:
> fsl,pcie-scfg = <&scfg 0>, 0 is an index
>
> In my fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>, It means that 0x0 is an alt
> offset address for IPPDEXPCR0, 0x51c is an alt offset address For
> IPPDEXPCR1 instead of 0x0 and 0x51c compose to an alt address of
> SCFG_SPARECR8.
Maybe I need write it as:
fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x0 0x0 0x51c>;
first two 0x0 compose an alt offset address for IPPDEXPCR0,
last 0x0 and 0x51c compose an alt address for IPPDEXPCR1,
Best Regards,
Biwen Li
> >
> > Regards,
> > Leo
> > > >
> > > > > >
> > > > > > > >
> > > > > > > > > + The first entry must be a link to the SCFG device node.
> > > > > > > > > + The non-first entry must be offset of registers of SCFG.
> > > > > > > > >
> > > > > > > > > Example:
> > > > > > > > > The RCPM node for T4240:
> > > > > > > > > @@ -43,6 +48,15 @@ The RCPM node for T4240:
> > > > > > > > > #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > +The RCPM node for LS1021A:
> > > > > > > > > + rcpm: rcpm@1ee2140 {
> > > > > > > > > + compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-
> > > > > 2.1+";
> > > > > > > > > + reg = <0x0 0x1ee2140 0x0 0x8>;
> > > > > > > > > + #fsl,rcpm-wakeup-cells = <2>;
> > > > > > > > > + fsl,ippdexpcr-alt-addr = <&scfg 0x0 0x51c>; /*
> > > > > > > > > SCFG_SPARECR8 */
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > * Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > > -------------------------------------------
> > > > > > > > > Required fsl,rcpm-wakeup property should be added to a
> > > > > > > > > device node if the device
> > > > > > > > > --
> > > > > > > > > 2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] arm64: use generic free_initrd_mem()
From: Mike Rapoport @ 2019-09-25 5:09 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland
Cc: Mike Rapoport, Laura Abbott, linux-kernel, linux-arm-kernel,
Anshuman Khandual
From: Mike Rapoport <rppt@linux.ibm.com>
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved is unused, so the only purpose
of the memblock_free() call is to keep track of initrd memory for debugging
and accounting.
Without the memblock_free() call the only difference between arm64 and the
generic versions of free_initrd_mem() is the memory poisoning.
Move memblock_free() call to the generic code, enable it there
for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
implementaion of free_initrd_mem() on arm64.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
v3:
* fix powerpc build
v2:
* add memblock_free() to the generic free_initrd_mem()
* rebase on the current upstream
arch/arm64/mm/init.c | 12 ------------
init/initramfs.c | 5 +++++
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a5..87a0e3b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -580,18 +580,6 @@ void free_initmem(void)
unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
}
-#ifdef CONFIG_BLK_DEV_INITRD
-void __init free_initrd_mem(unsigned long start, unsigned long end)
-{
- unsigned long aligned_start, aligned_end;
-
- aligned_start = __virt_to_phys(start) & PAGE_MASK;
- aligned_end = PAGE_ALIGN(__virt_to_phys(end));
- memblock_free(aligned_start, aligned_end - aligned_start);
- free_reserved_area((void *)start, (void *)end, 0, "initrd");
-}
-#endif
-
/*
* Dump out memory limit information on panic.
*/
diff --git a/init/initramfs.c b/init/initramfs.c
index c47dad0..3d61e13 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -10,6 +10,7 @@
#include <linux/syscalls.h>
#include <linux/utime.h>
#include <linux/file.h>
+#include <linux/memblock.h>
static ssize_t __init xwrite(int fd, const char *p, size_t count)
{
@@ -531,6 +532,10 @@ void __weak free_initrd_mem(unsigned long start, unsigned long end)
{
free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
"initrd");
+
+#ifdef CONFIG_ARCH_KEEP_MEMBLOCK
+ memblock_free(__pa(start), end - start);
+#endif
}
#ifdef CONFIG_KEXEC_CORE
--
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
* [RFC PATCH] interconnect: Replace of_icc_get() with icc_get() and reduce DT binding
From: Stephen Boyd @ 2019-09-25 5:41 UTC (permalink / raw)
To: Georgi Djakov
Cc: devicetree, linux-pm, linux-arm-msm, David Dai, linux-kernel,
Maxime Ripard, Bjorn Andersson, Rob Herring, Evan Green,
linux-arm-kernel
I don't see any users of icc_get() in the kernel today, and adding them
doesn't make sense. That's because adding calls to that function in a
driver will make the driver SoC specific given that the arguments are
some sort of source and destination numbers that would typically be
listed in DT or come from platform data so they can match a global
numberspace of interconnect numbers. It would be better to follow the
approach of other kernel frameworks where the API is the same no matter
how the platform is described (i.e. platform data, DT, ACPI, etc.) and
swizzle the result in the framework to match whatever the device is by
checking for a DT node pointer or a fwnode pointer, etc. Therefore,
install icc_get() as the defacto API and make drivers use that instead
of of_icc_get() which implies the driver is DT specific when it doesn't
need to be.
The DT binding could also be simplified somewhat. Currently a path needs
to be specified in DT for each and every use case that is possible for a
device to want. Typically the path is to memory, which looks to be
reserved for in the binding with the "dma-mem" named path, but sometimes
the path is from a device to the CPU or more generically from a device
to another device which could be a CPU, cache, DMA master, or another
device if some sort of DMA to DMA scenario is happening. Let's remove
the pair part of the binding so that we just list out a device's
possible endpoints on the bus or busses that it's connected to.
If the kernel wants to figure out what the path is to memory or the CPU
or a cache or something else it should be able to do that by finding the
node for the "destination" endpoint, extracting that node's
"interconnects" property, and deriving the path in software. For
example, we shouldn't need to write out each use case path by path in DT
for each endpoint node that wants to set a bandwidth to memory. We
should just be able to indicate what endpoint(s) a device sits on based
on the interconnect provider in the system and then walk the various
interconnects to find the path from that source endpoint to the
destination endpoint.
Obviously this patch doesn't compile but I'm sending it out to start
this discussion so we don't get stuck on the binding or the kernel APIs
for a long time. It looks like we should be OK in terms of backwards
compatibility because we can just ignore the second element in an old
binding, but maybe we'll want to describe paths in different directions
(e.g. the path from the CPU to the SD controller may be different than
the path the SD controller takes to the CPU) and that may require
extending interconnect-names to indicate what direction/sort of path it
is. I'm basically thinking about master vs. slave ports in AXI land.
Cc: Maxime Ripard <mripard@kernel.org>
Cc: <linux-pm@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: <devicetree@vger.kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: David Dai <daidavid1@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
.../bindings/interconnect/interconnect.txt | 19 ++++---------------
include/linux/interconnect.h | 13 ++-----------
2 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 6f5d23a605b7..f8979186b8a7 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -11,7 +11,7 @@ The interconnect provider binding is intended to represent the interconnect
controllers in the system. Each provider registers a set of interconnect
nodes, which expose the interconnect related capabilities of the interconnect
to consumer drivers. These capabilities can be throughput, latency, priority
-etc. The consumer drivers set constraints on interconnect path (or endpoints)
+etc. The consumer drivers set constraints on interconnect paths (or endpoints)
depending on the use case. Interconnect providers can also be interconnect
consumers, such as in the case where two network-on-chip fabrics interface
directly.
@@ -42,23 +42,12 @@ multiple paths from different providers depending on use case and the
components it has to interact with.
Required properties:
-interconnects : Pairs of phandles and interconnect provider specifier to denote
- the edge source and destination ports of the interconnect path.
-
-Optional properties:
-interconnect-names : List of interconnect path name strings sorted in the same
- order as the interconnects property. Consumers drivers will use
- interconnect-names to match interconnect paths with interconnect
- specifier pairs.
-
- Reserved interconnect names:
- * dma-mem: Path from the device to the main memory of
- the system
+interconnects : phandle and interconnect provider specifier to denote
+ the edge source for this node.
Example:
sdhci@7864000 {
...
- interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
- interconnect-names = "sdhc-mem";
+ interconnects = <&pnoc MASTER_SDCC_1>;
};
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index d70a914cba11..e1ae704f5ab1 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -25,23 +25,14 @@ struct device;
#if IS_ENABLED(CONFIG_INTERCONNECT)
-struct icc_path *icc_get(struct device *dev, const int src_id,
- const int dst_id);
-struct icc_path *of_icc_get(struct device *dev, const char *name);
+struct icc_path *icc_get(struct device *dev, const char *name);
void icc_put(struct icc_path *path);
int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
void icc_set_tag(struct icc_path *path, u32 tag);
#else
-static inline struct icc_path *icc_get(struct device *dev, const int src_id,
- const int dst_id)
-{
- return NULL;
-}
-
-static inline struct icc_path *of_icc_get(struct device *dev,
- const char *name)
+static inline struct icc_path *icc_get(struct device *dev, const char *name)
{
return NULL;
}
base-commit: b5b3bd898ba99fb0fb6aed3b23ec6353a1724d6f
--
Sent by a computer through tubes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH v2 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Artur Świgoń @ 2019-09-25 5:44 UTC (permalink / raw)
To: Chanwoo Choi, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-pm, dri-devel
Cc: b.zolnierkie, sw0312.kim, Artur Świgoń, krzk, inki.dae,
myungjoo.ham, leonard.crestez, georgi.djakov, m.szyprowski
In-Reply-To: <2e49bd2c-e074-038b-f8a2-7dd8dea4a9af@samsung.com>
Hi,
On Fri, 2019-09-20 at 11:15 +0900, Chanwoo Choi wrote:
> Hi,
>
> As I already replied on v1, patch1/2/3 clean-up code
> for readability without any behavior changes.
>
> I think that you better to merge patch1/2/3 to one patch.
Yes, when writing the cover letter I think I forgot to explain why I decided not
to merge these patches. Basically, none of the diff algorithms available in git
(I've got v2.17.1) is able to produce a readable patch with these changes
combined together into a single patch (functions are intermixed together in the
output, git thinks that 'exynos_bus_probe' is a new function).
Please take a look at the diff at the bottom of this message to see how patches
01..03 look when combined. If such patch looks acceptable to you, I can merge.
> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> > From: Artur Świgoń <a.swigon@partner.samsung.com>
> >
> > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > from exynos_bus_probe().
> >
> > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > ---
> > drivers/devfreq/exynos-bus.c | 92 +++++++++++++++++++++---------------
> > 1 file changed, 53 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 29f422469960..78f38b7fb596 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -287,12 +287,62 @@ static int exynos_bus_parse_of(struct device_node *np,
> > return ret;
> > }
> >
> > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > + struct devfreq_dev_profile *profile)
> > +{
> > + struct device *dev = bus->dev;
> > + struct devfreq_simple_ondemand_data *ondemand_data;
> > + int ret;
> > +
> > + /* Initialize the struct profile and governor data for parent device */
> > + profile->polling_ms = 50;
> > + profile->target = exynos_bus_target;
> > + profile->get_dev_status = exynos_bus_get_dev_status;
> > + profile->exit = exynos_bus_exit;
> > +
> > + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > + if (!ondemand_data) {
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > + ondemand_data->upthreshold = 40;
> > + ondemand_data->downdifferential = 5;
> > +
> > + /* Add devfreq device to monitor and handle the exynos bus */
> > + bus->devfreq = devm_devfreq_add_device(dev, profile,
> > + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > + ondemand_data);
> > + if (IS_ERR(bus->devfreq)) {
> > + dev_err(dev, "failed to add devfreq device\n");
> > + ret = PTR_ERR(bus->devfreq);
> > + goto err;
> > + }
> > +
> > + /*
> > + * Enable devfreq-event to get raw data which is used to determine
> > + * current bus load.
> > + */
> > + ret = exynos_bus_enable_edev(bus);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to enable devfreq-event devices\n");
> > + goto err;
> > + }
> > +
> > + ret = exynos_bus_set_event(bus);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to set event to devfreq-event devices\n");
> > + goto err;
> > + }
> > +
> > +err:
> > + return ret;
> > +}
> > +
> > static int exynos_bus_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > struct device_node *np = dev->of_node, *node;
> > struct devfreq_dev_profile *profile;
> > - struct devfreq_simple_ondemand_data *ondemand_data;
> > struct devfreq_passive_data *passive_data;
> > struct devfreq *parent_devfreq;
> > struct exynos_bus *bus;
> > @@ -334,45 +384,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > if (passive)
> > goto passive;
> >
> > - /* Initialize the struct profile and governor data for parent device */
> > - profile->polling_ms = 50;
> > - profile->target = exynos_bus_target;
> > - profile->get_dev_status = exynos_bus_get_dev_status;
> > - profile->exit = exynos_bus_exit;
> > -
> > - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > - if (!ondemand_data) {
> > - ret = -ENOMEM;
> > + ret = exynos_bus_profile_init(bus, profile);
> > + if (ret < 0)
> > goto err;
> > - }
> > - ondemand_data->upthreshold = 40;
> > - ondemand_data->downdifferential = 5;
> > -
> > - /* Add devfreq device to monitor and handle the exynos bus */
> > - bus->devfreq = devm_devfreq_add_device(dev, profile,
> > - DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > - ondemand_data);
> > - if (IS_ERR(bus->devfreq)) {
> > - dev_err(dev, "failed to add devfreq device\n");
> > - ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > - }
> > -
> > - /*
> > - * Enable devfreq-event to get raw data which is used to determine
> > - * current bus load.
> > - */
> > - ret = exynos_bus_enable_edev(bus);
> > - if (ret < 0) {
> > - dev_err(dev, "failed to enable devfreq-event devices\n");
> > - goto err;
> > - }
> > -
> > - ret = exynos_bus_set_event(bus);
> > - if (ret < 0) {
> > - dev_err(dev, "failed to set event to devfreq-event devices\n");
> > - goto err;
> > - }
> >
> > goto out;
> > passive:
commit cacf8e4ea0e111908d11779977c81e29d6418801
Author: Artur Świgoń <a.swigon@partner.samsung.com>
Date: Tue Aug 27 13:17:28 2019 +0200
tmp: merge patches 01-03
Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 29f422469960..60ad4319fd80 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -287,52 +287,12 @@ static int exynos_bus_parse_of(struct device_node *np,
return ret;
}
-static int exynos_bus_probe(struct platform_device *pdev)
+static int exynos_bus_profile_init(struct exynos_bus *bus,
+ struct devfreq_dev_profile *profile)
{
- struct device *dev = &pdev->dev;
- struct device_node *np = dev->of_node, *node;
- struct devfreq_dev_profile *profile;
+ struct device *dev = bus->dev;
struct devfreq_simple_ondemand_data *ondemand_data;
- struct devfreq_passive_data *passive_data;
- struct devfreq *parent_devfreq;
- struct exynos_bus *bus;
- int ret, max_state;
- unsigned long min_freq, max_freq;
- bool passive = false;
-
- if (!np) {
- dev_err(dev, "failed to find devicetree node\n");
- return -EINVAL;
- }
-
- bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
- if (!bus)
- return -ENOMEM;
- mutex_init(&bus->lock);
- bus->dev = &pdev->dev;
- platform_set_drvdata(pdev, bus);
-
- profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
- if (!profile)
- return -ENOMEM;
-
- node = of_parse_phandle(dev->of_node, "devfreq", 0);
- if (node) {
- of_node_put(node);
- passive = true;
- } else {
- ret = exynos_bus_parent_parse_of(np, bus);
- if (ret < 0)
- return ret;
- }
-
- /* Parse the device-tree to get the resource information */
- ret = exynos_bus_parse_of(np, bus);
- if (ret < 0)
- goto err_reg;
-
- if (passive)
- goto passive;
+ int ret;
/* Initialize the struct profile and governor data for parent device */
profile->polling_ms = 50;
@@ -374,8 +334,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
goto err;
}
- goto out;
-passive:
+err:
+ return ret;
+}
+
+static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
+ struct devfreq_dev_profile *profile)
+{
+ struct device *dev = bus->dev;
+ struct devfreq_passive_data *passive_data;
+ struct devfreq *parent_devfreq;
+ int ret = 0;
+
/* Initialize the struct profile and governor data for passive device */
profile->target = exynos_bus_target;
profile->exit = exynos_bus_passive_exit;
@@ -404,7 +374,59 @@ static int exynos_bus_probe(struct platform_device *pdev)
goto err;
}
-out:
+err:
+ return ret;
+}
+
+static int exynos_bus_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node, *node;
+ struct devfreq_dev_profile *profile;
+ struct exynos_bus *bus;
+ int ret, max_state;
+ unsigned long min_freq, max_freq;
+ bool passive = false;
+
+ if (!np) {
+ dev_err(dev, "failed to find devicetree node\n");
+ return -EINVAL;
+ }
+
+ bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
+ if (!bus)
+ return -ENOMEM;
+ mutex_init(&bus->lock);
+ bus->dev = &pdev->dev;
+ platform_set_drvdata(pdev, bus);
+
+ profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
+ if (!profile)
+ return -ENOMEM;
+
+ node = of_parse_phandle(dev->of_node, "devfreq", 0);
+ if (node) {
+ of_node_put(node);
+ passive = true;
+ } else {
+ ret = exynos_bus_parent_parse_of(np, bus);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Parse the device-tree to get the resource information */
+ ret = exynos_bus_parse_of(np, bus);
+ if (ret < 0)
+ goto err_reg;
+
+ if (passive)
+ ret = exynos_bus_profile_init_passive(bus, profile);
+ else
+ ret = exynos_bus_profile_init(bus, profile);
+
+ if (ret < 0)
+ goto err;
+
max_state = bus->devfreq->profile->max_state;
min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
From: Artur Świgoń @ 2019-09-25 5:47 UTC (permalink / raw)
To: Chanwoo Choi, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-pm, dri-devel
Cc: b.zolnierkie, sw0312.kim, krzk, inki.dae, myungjoo.ham,
cpgs (cpgs@samsung.com), leonard.crestez, georgi.djakov,
m.szyprowski
In-Reply-To: <d8550f93-d4cf-f215-c083-8ecad267d430@samsung.com>
Hi,
On Fri, 2019-09-20 at 11:14 +0900, Chanwoo Choi wrote:
> Hi Artur,
>
> I tried to just build this patch on mainline kernel or linux-next.
> But, when I applied them, merge conflict happens. You didn't develop
> them on latest version. Please rebase them based on latest mainline kernel.
I developed on top of next-20190918 on which I applied
https://patchwork.kernel.org/cover/11149497/ as I mentioned in the cover
letter. The dev_pm_qos patches and my RFC have just cleanly rebased together on
top of next-20190920. Could you check if you have the dev_pm_qos patches (v5,
the version number is missing in this one; link above) and if so, where does the
conflict appear?
> On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote:
> > Hi Artur,
> >
> > On v1, I mentioned that we need to discuss how to change
> > the v2 for this. But, I have not received any reply from you on v1.
> > And, without your reply from v1, you just send v2.
> >
> > I think that it is not proper development sequence.
> > I have spent many times to review your patches
> > and also I'll review your patches. You have to take care
> > the reply of reviewer and and keep the basic rule
> > of mailing contribution for discussion.
> >
> > On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> > > The following patchset adds interconnect[1][2] framework support to the
> > > exynos-bus devfreq driver. Extending the devfreq driver with interconnect
> > > capabilities started as a response to the issue referenced in [3]. The
> > > patches can be subdivided into four logical groups:
> > >
> > > (a) Refactoring the existing devfreq driver in order to improve readability
> > > and accommodate for adding new code (patches 01--04/11).
> > >
> > > (b) Tweaking the interconnect framework to support the exynos-bus use case
> > > (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to
> > > avoid hardcoding every single graph edge in the DT or driver source, and
> > > relaxing the requirement contained in that function removes the need to
> > > provide dummy node IDs in the DT. Adjusting the logic in
> > > apply_constraints() (drivers/interconnect/core.c) accounts for the fact
> > > that every bus is a separate entity and therefore a separate interconnect
> > > provider, albeit constituting a part of a larger hierarchy.
> > >
> > > (c) Implementing interconnect providers in the exynos-bus devfreq driver
> > > and adding required DT properties for one selected platform, namely
> > > Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a
> > > generic driver for various Exynos SoCs, node IDs are generated dynamically
> > > rather than hardcoded. This has been determined to be a simpler approach,
> > > but depends on changes described in (b).
> > >
> > > (d) Implementing a sample interconnect consumer for exynos-mixer targeted
> > > at the issue referenced in [3], again with DT info only for Exynos4412
> > > (patches 10--11/11).
> > >
> > > Integration of devfreq and interconnect functionalities is achieved by
> > > using dev_pm_qos_*() API[5]. All new code works equally well when
> > > CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all
> > > interconnect API functions are no-ops.
> > >
> > > This patchset depends on [5].
> > >
> > > --- Changes since v1 [6]:
> > > * Rebase on [4] (coupled regulators).
> > > * Rebase on [5] (dev_pm_qos for devfreq).
> > > * Use dev_pm_qos_*() API[5] instead of overriding frequency in
> > > exynos_bus_target().
> > > * Use IDR for node ID allocation.
> > > * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04).
> > > * Reverse order of multiplication and division in
> > > mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow.
> > >
> > > ---
> > > Artur Świgoń
> > > Samsung R&D Institute Poland
> > > Samsung Electronics
> > >
> > > ---
> > > References:
> > > [1] Documentation/interconnect/interconnect.rst
> > > [2] Documentation/devicetree/bindings/interconnect/interconnect.txt
> > > [3] https://patchwork.kernel.org/patch/10861757/ (original issue)
> > > [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged)
> > > [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq)
> > > [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
> > >
> > > Artur Świgoń (10):
> > > devfreq: exynos-bus: Extract exynos_bus_profile_init()
> > > devfreq: exynos-bus: Extract exynos_bus_profile_init_passive()
> > > devfreq: exynos-bus: Change goto-based logic to if-else logic
> > > devfreq: exynos-bus: Clean up code
> > > interconnect: Export of_icc_get_from_provider()
> > > interconnect: Relax requirement in of_icc_get_from_provider()
> > > interconnect: Relax condition in apply_constraints()
> > > arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
> > > devfreq: exynos-bus: Add interconnect functionality to exynos-bus
> > > arm: dts: exynos: Add interconnects to Exynos4412 mixer
> > >
> > > Marek Szyprowski (1):
> > > drm: exynos: mixer: Add interconnect support
> > >
> > > .../boot/dts/exynos4412-odroid-common.dtsi | 1 +
> > > arch/arm/boot/dts/exynos4412.dtsi | 10 +
> > > drivers/devfreq/exynos-bus.c | 319 +++++++++++++-----
> > > drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++-
> > > drivers/interconnect/core.c | 12 +-
> > > include/linux/interconnect-provider.h | 6 +
> > > 6 files changed, 327 insertions(+), 92 deletions(-)
> > >
> >
> >
>
>
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] interconnect: Replace of_icc_get() with icc_get() and reduce DT binding
From: Bjorn Andersson @ 2019-09-25 5:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: devicetree, linux-pm, linux-arm-msm, David Dai, linux-kernel,
Maxime Ripard, Rob Herring, Evan Green, Georgi Djakov,
linux-arm-kernel
In-Reply-To: <20190925054133.206992-1-swboyd@chromium.org>
On Tue 24 Sep 22:41 PDT 2019, Stephen Boyd wrote:
> I don't see any users of icc_get() in the kernel today, and adding them
> doesn't make sense. That's because adding calls to that function in a
> driver will make the driver SoC specific given that the arguments are
> some sort of source and destination numbers that would typically be
> listed in DT or come from platform data so they can match a global
> numberspace of interconnect numbers. It would be better to follow the
> approach of other kernel frameworks where the API is the same no matter
> how the platform is described (i.e. platform data, DT, ACPI, etc.) and
> swizzle the result in the framework to match whatever the device is by
> checking for a DT node pointer or a fwnode pointer, etc. Therefore,
> install icc_get() as the defacto API and make drivers use that instead
> of of_icc_get() which implies the driver is DT specific when it doesn't
> need to be.
>
+1 on this part!
> The DT binding could also be simplified somewhat. Currently a path needs
> to be specified in DT for each and every use case that is possible for a
> device to want. Typically the path is to memory, which looks to be
> reserved for in the binding with the "dma-mem" named path, but sometimes
> the path is from a device to the CPU or more generically from a device
> to another device which could be a CPU, cache, DMA master, or another
> device if some sort of DMA to DMA scenario is happening. Let's remove
> the pair part of the binding so that we just list out a device's
> possible endpoints on the bus or busses that it's connected to.
>
> If the kernel wants to figure out what the path is to memory or the CPU
> or a cache or something else it should be able to do that by finding the
> node for the "destination" endpoint, extracting that node's
> "interconnects" property, and deriving the path in software. For
> example, we shouldn't need to write out each use case path by path in DT
> for each endpoint node that wants to set a bandwidth to memory. We
> should just be able to indicate what endpoint(s) a device sits on based
> on the interconnect provider in the system and then walk the various
> interconnects to find the path from that source endpoint to the
> destination endpoint.
>
But doesn't this implies that the other end of the path is always some
specific node, e.g. DDR? With a single node how would you describe
CPU->LLCC or GPU->OCIMEM?
> Obviously this patch doesn't compile but I'm sending it out to start
> this discussion so we don't get stuck on the binding or the kernel APIs
> for a long time. It looks like we should be OK in terms of backwards
> compatibility because we can just ignore the second element in an old
> binding, but maybe we'll want to describe paths in different directions
> (e.g. the path from the CPU to the SD controller may be different than
> the path the SD controller takes to the CPU) and that may require
> extending interconnect-names to indicate what direction/sort of path it
> is. I'm basically thinking about master vs. slave ports in AXI land.
>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: <linux-pm@vger.kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: <devicetree@vger.kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Evan Green <evgreen@chromium.org>
> Cc: David Dai <daidavid1@codeaurora.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> .../bindings/interconnect/interconnect.txt | 19 ++++---------------
> include/linux/interconnect.h | 13 ++-----------
> 2 files changed, 6 insertions(+), 26 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> index 6f5d23a605b7..f8979186b8a7 100644
> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
> @@ -11,7 +11,7 @@ The interconnect provider binding is intended to represent the interconnect
> controllers in the system. Each provider registers a set of interconnect
> nodes, which expose the interconnect related capabilities of the interconnect
> to consumer drivers. These capabilities can be throughput, latency, priority
> -etc. The consumer drivers set constraints on interconnect path (or endpoints)
> +etc. The consumer drivers set constraints on interconnect paths (or endpoints)
> depending on the use case. Interconnect providers can also be interconnect
> consumers, such as in the case where two network-on-chip fabrics interface
> directly.
> @@ -42,23 +42,12 @@ multiple paths from different providers depending on use case and the
> components it has to interact with.
>
> Required properties:
> -interconnects : Pairs of phandles and interconnect provider specifier to denote
> - the edge source and destination ports of the interconnect path.
> -
> -Optional properties:
> -interconnect-names : List of interconnect path name strings sorted in the same
> - order as the interconnects property. Consumers drivers will use
> - interconnect-names to match interconnect paths with interconnect
> - specifier pairs.
> -
> - Reserved interconnect names:
> - * dma-mem: Path from the device to the main memory of
> - the system
> +interconnects : phandle and interconnect provider specifier to denote
> + the edge source for this node.
>
> Example:
>
> sdhci@7864000 {
> ...
> - interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
> - interconnect-names = "sdhc-mem";
> + interconnects = <&pnoc MASTER_SDCC_1>;
This example seems incomplete, as it doesn't describe the path between
CPU and the config space, with this in place I think you need the
interconnect-names.
But with a single interconnect, the interconnect-names should be
omitted, as done in other frameworks.
> };
> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> index d70a914cba11..e1ae704f5ab1 100644
> --- a/include/linux/interconnect.h
> +++ b/include/linux/interconnect.h
> @@ -25,23 +25,14 @@ struct device;
>
> #if IS_ENABLED(CONFIG_INTERCONNECT)
>
> -struct icc_path *icc_get(struct device *dev, const int src_id,
> - const int dst_id);
> -struct icc_path *of_icc_get(struct device *dev, const char *name);
> +struct icc_path *icc_get(struct device *dev, const char *name);
> void icc_put(struct icc_path *path);
> int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> void icc_set_tag(struct icc_path *path, u32 tag);
>
> #else
>
> -static inline struct icc_path *icc_get(struct device *dev, const int src_id,
> - const int dst_id)
> -{
> - return NULL;
> -}
> -
> -static inline struct icc_path *of_icc_get(struct device *dev,
> - const char *name)
> +static inline struct icc_path *icc_get(struct device *dev, const char *name)
I like this part, if mimics what's done in other frameworks and removes
the ties to OF from the API.
Regards,
Bjorn
> {
> return NULL;
> }
>
> base-commit: b5b3bd898ba99fb0fb6aed3b23ec6353a1724d6f
> --
> Sent by a computer through tubes
>
_______________________________________________
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 01/17] kexec: quiet down kexec reboot
From: Dave Young @ 2019-09-25 6:04 UTC (permalink / raw)
To: Pavel Tatashin
Cc: sashal, mark.rutland, vladimir.murzin, corbet, marc.zyngier,
catalin.marinas, bhsharma, kexec, linux-kernel, jmorris, linux-mm,
james.morse, ebiederm, matthias.bgg, will, linux-arm-kernel
In-Reply-To: <20190923203427.294286-2-pasha.tatashin@soleen.com>
On 09/23/19 at 04:34pm, Pavel Tatashin wrote:
> Here is a regular kexec command sequence and output:
> =====
> $ kexec --reuse-cmdline -i --load Image
> $ kexec -e
> [ 161.342002] kexec_core: Starting new kernel
>
> Welcome to Buildroot
> buildroot login:
> =====
>
> Even when "quiet" kernel parameter is specified, "kexec_core: Starting
> new kernel" is printed.
>
> This message has KERN_EMERG level, but there is no emergency, it is a
> normal kexec operation, so quiet it down to appropriate KERN_NOTICE.
>
> Machines that have slow console baud rate benefit from less output.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> Reviewed-by: Simon Horman <horms@verge.net.au>
> ---
> kernel/kexec_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index d5870723b8ad..2c5b72863b7b 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1169,7 +1169,7 @@ int kernel_kexec(void)
> * CPU hotplug again; so re-enable it here.
> */
> cpu_hotplug_enable();
> - pr_emerg("Starting new kernel\n");
> + pr_notice("Starting new kernel\n");
> machine_shutdown();
> }
>
Acked-by: Dave Young <dyoung@redhat.com>
Thanks
Dave
_______________________________________________
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 13/17] kexec: add machine_kexec_post_load()
From: Dave Young @ 2019-09-25 6:05 UTC (permalink / raw)
To: Pavel Tatashin
Cc: sashal, mark.rutland, vladimir.murzin, corbet, marc.zyngier,
catalin.marinas, bhsharma, kexec, linux-kernel, jmorris, linux-mm,
james.morse, ebiederm, matthias.bgg, will, linux-arm-kernel
In-Reply-To: <20190923203427.294286-14-pasha.tatashin@soleen.com>
On 09/23/19 at 04:34pm, Pavel Tatashin wrote:
> It is the same as machine_kexec_prepare(), but is called after segments are
> loaded. This way, can do processing work with already loaded relocation
> segments. One such example is arm64: it has to have segments loaded in
> order to create a page table, but it cannot do it during kexec time,
> because at that time allocations won't be possible anymore.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> ---
> kernel/kexec.c | 4 ++++
> kernel/kexec_core.c | 6 ++++++
> kernel/kexec_file.c | 4 ++++
> kernel/kexec_internal.h | 2 ++
> 4 files changed, 16 insertions(+)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 1b018f1a6e0d..27b71dc7b35a 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -159,6 +159,10 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
>
> kimage_terminate(image);
>
> + ret = machine_kexec_post_load(image);
> + if (ret)
> + goto out;
> +
> /* Install the new kernel and uninstall the old */
> image = xchg(dest_image, image);
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 2c5b72863b7b..8360645d1bbe 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -587,6 +587,12 @@ static void kimage_free_extra_pages(struct kimage *image)
> kimage_free_page_list(&image->unusable_pages);
>
> }
> +
> +int __weak machine_kexec_post_load(struct kimage *image)
> +{
> + return 0;
> +}
> +
> void kimage_terminate(struct kimage *image)
> {
> if (*image->entry != 0)
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index b8cc032d5620..cb531d768114 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -391,6 +391,10 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
>
> kimage_terminate(image);
>
> + ret = machine_kexec_post_load(image);
> + if (ret)
> + goto out;
> +
> /*
> * Free up any temporary buffers allocated which are not needed
> * after image has been loaded
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 48aaf2ac0d0d..39d30ccf8d87 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -13,6 +13,8 @@ void kimage_terminate(struct kimage *image);
> int kimage_is_destination_range(struct kimage *image,
> unsigned long start, unsigned long end);
>
> +int machine_kexec_post_load(struct kimage *image);
> +
> extern struct mutex kexec_mutex;
>
> #ifdef CONFIG_KEXEC_FILE
> --
> 2.23.0
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Acked-by: Dave Young <dyoung@redhat.com>
Thanks
Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
From: Chanwoo Choi @ 2019-09-25 6:12 UTC (permalink / raw)
To: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-pm, dri-devel
Cc: b.zolnierkie, sw0312.kim, krzk, inki.dae, myungjoo.ham,
cpgs (cpgs@samsung.com), leonard.crestez, georgi.djakov,
m.szyprowski
In-Reply-To: <c06ca89f2b40e0282f19727b95da5e5b0158d7e3.camel@samsung.com>
Hi,
On 19. 9. 25. 오후 2:47, Artur Świgoń wrote:
> Hi,
>
> On Fri, 2019-09-20 at 11:14 +0900, Chanwoo Choi wrote:
>> Hi Artur,
>>
>> I tried to just build this patch on mainline kernel or linux-next.
>> But, when I applied them, merge conflict happens. You didn't develop
>> them on latest version. Please rebase them based on latest mainline kernel.
>
> I developed on top of next-20190918 on which I applied
> https://patchwork.kernel.org/cover/11149497/ as I mentioned in the cover
> letter. The dev_pm_qos patches and my RFC have just cleanly rebased together on
> top of next-20190920. Could you check if you have the dev_pm_qos patches (v5,
> the version number is missing in this one; link above) and if so, where does the
> conflict appear?
I faced on the merge conflict of drivers/devfreq/exynos-bus.c.
I think that It is not related to to dev_pm_qos patch.
Maybe, Kamil's patches[1] changed the many things of exynos-bus.c
If your test branch doesn't contain following patches,
you need to rebase your patches based on latest mainline kernel
from Linus Torvald.
[1] https://patchwork.kernel.org/cover/11083663/
- [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
Today, I tried to apply these patch again based on latest mainline kernel.
The merge conflict happen still.
- merge conflict log
Applying: devfreq: exynos-bus: Extract exynos_bus_profile_init()
error: patch failed: drivers/devfreq/exynos-bus.c:334
error: drivers/devfreq/exynos-bus.c: patch does not apply
Patch failed at 0001 devfreq: exynos-bus: Extract exynos_bus_profile_init()
>
>> On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote:
>>> Hi Artur,
>>>
>>> On v1, I mentioned that we need to discuss how to change
>>> the v2 for this. But, I have not received any reply from you on v1.
>>> And, without your reply from v1, you just send v2.
>>>
>>> I think that it is not proper development sequence.
>>> I have spent many times to review your patches
>>> and also I'll review your patches. You have to take care
>>> the reply of reviewer and and keep the basic rule
>>> of mailing contribution for discussion.
>>>
>>> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
>>>> The following patchset adds interconnect[1][2] framework support to the
>>>> exynos-bus devfreq driver. Extending the devfreq driver with interconnect
>>>> capabilities started as a response to the issue referenced in [3]. The
>>>> patches can be subdivided into four logical groups:
>>>>
>>>> (a) Refactoring the existing devfreq driver in order to improve readability
>>>> and accommodate for adding new code (patches 01--04/11).
>>>>
>>>> (b) Tweaking the interconnect framework to support the exynos-bus use case
>>>> (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to
>>>> avoid hardcoding every single graph edge in the DT or driver source, and
>>>> relaxing the requirement contained in that function removes the need to
>>>> provide dummy node IDs in the DT. Adjusting the logic in
>>>> apply_constraints() (drivers/interconnect/core.c) accounts for the fact
>>>> that every bus is a separate entity and therefore a separate interconnect
>>>> provider, albeit constituting a part of a larger hierarchy.
>>>>
>>>> (c) Implementing interconnect providers in the exynos-bus devfreq driver
>>>> and adding required DT properties for one selected platform, namely
>>>> Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a
>>>> generic driver for various Exynos SoCs, node IDs are generated dynamically
>>>> rather than hardcoded. This has been determined to be a simpler approach,
>>>> but depends on changes described in (b).
>>>>
>>>> (d) Implementing a sample interconnect consumer for exynos-mixer targeted
>>>> at the issue referenced in [3], again with DT info only for Exynos4412
>>>> (patches 10--11/11).
>>>>
>>>> Integration of devfreq and interconnect functionalities is achieved by
>>>> using dev_pm_qos_*() API[5]. All new code works equally well when
>>>> CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all
>>>> interconnect API functions are no-ops.
>>>>
>>>> This patchset depends on [5].
>>>>
>>>> --- Changes since v1 [6]:
>>>> * Rebase on [4] (coupled regulators).
>>>> * Rebase on [5] (dev_pm_qos for devfreq).
>>>> * Use dev_pm_qos_*() API[5] instead of overriding frequency in
>>>> exynos_bus_target().
>>>> * Use IDR for node ID allocation.
>>>> * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04).
>>>> * Reverse order of multiplication and division in
>>>> mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow.
>>>>
>>>> ---
>>>> Artur Świgoń
>>>> Samsung R&D Institute Poland
>>>> Samsung Electronics
>>>>
>>>> ---
>>>> References:
>>>> [1] Documentation/interconnect/interconnect.rst
>>>> [2] Documentation/devicetree/bindings/interconnect/interconnect.txt
>>>> [3] https://patchwork.kernel.org/patch/10861757/ (original issue)
>>>> [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged)
>>>> [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq)
>>>> [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
>>>>
>>>> Artur Świgoń (10):
>>>> devfreq: exynos-bus: Extract exynos_bus_profile_init()
>>>> devfreq: exynos-bus: Extract exynos_bus_profile_init_passive()
>>>> devfreq: exynos-bus: Change goto-based logic to if-else logic
>>>> devfreq: exynos-bus: Clean up code
>>>> interconnect: Export of_icc_get_from_provider()
>>>> interconnect: Relax requirement in of_icc_get_from_provider()
>>>> interconnect: Relax condition in apply_constraints()
>>>> arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
>>>> devfreq: exynos-bus: Add interconnect functionality to exynos-bus
>>>> arm: dts: exynos: Add interconnects to Exynos4412 mixer
>>>>
>>>> Marek Szyprowski (1):
>>>> drm: exynos: mixer: Add interconnect support
>>>>
>>>> .../boot/dts/exynos4412-odroid-common.dtsi | 1 +
>>>> arch/arm/boot/dts/exynos4412.dtsi | 10 +
>>>> drivers/devfreq/exynos-bus.c | 319 +++++++++++++-----
>>>> drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++-
>>>> drivers/interconnect/core.c | 12 +-
>>>> include/linux/interconnect-provider.h | 6 +
>>>> 6 files changed, 327 insertions(+), 92 deletions(-)
>>>>
>>>
>>>
>>
>>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [PATCH 4/5] dt-bindings: display: imx: add bindings for DCSS
From: Laurentiu Palcu @ 2019-09-25 6:14 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Philipp Zabel, Shawn Guo,
Sascha Hauer, linux-kernel@vger.kernel.org, dri-devel,
dl-linux-imx, Pengutronix Kernel Team, Fabio Estevam,
Guido Günther,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Lucas Stach
In-Reply-To: <CAL_JsqK1egTpkqsgVUMUiYzKvVJ=nWtJu+OeujJotRCD9ADsnw@mail.gmail.com>
Hi,
On Tue, Sep 24, 2019 at 01:53:28PM -0500, Rob Herring wrote:
> On Mon, Sep 23, 2019 at 9:14 AM Laurentiu Palcu <laurentiu.palcu@nxp.com> wrote:
> >
> > Add bindings for iMX8MQ Display Controller Subsystem.
> >
> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
> > ---
> > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 86 ++++++++++++++++++++++
> > 1 file changed, 86 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
>
> Fails to build with 'make dt_binding_check':
Must be because of the extra '0x' Stephen Boyd pointed out. Funny thing
is I ran:
make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
at my side, before sending out the patchset, and it passed. The command
also runs dt_binding_check, AFAIS:
SCHEMA Documentation/devicetree/bindings/processed-schema.yaml
CHKDT Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
DTC Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.example.dt.yaml
CHECK Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.example.dt.yaml
Not sure what I'm doing wrong when running it. I should've catched that. :/
Anyway, already fixed it and will be included in v2.
Thanks,
laurentiu
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F1166073%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7Cf97847ce739b46fdb72308d74120858b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049480244424980&sdata=fjyq52livEnMAQYzVAGqO%2FOtmLS83dungSvPqHYle10%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Chanwoo Choi @ 2019-09-25 6:37 UTC (permalink / raw)
To: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-pm, dri-devel
Cc: b.zolnierkie, sw0312.kim, krzk, inki.dae, myungjoo.ham,
leonard.crestez, georgi.djakov, m.szyprowski
In-Reply-To: <f51aac4cacb7a0196ab6919b110ad9fcf4009c88.camel@samsung.com>
Hi,
On 19. 9. 25. 오후 2:44, Artur Świgoń wrote:
> Hi,
>
> On Fri, 2019-09-20 at 11:15 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> As I already replied on v1, patch1/2/3 clean-up code
>> for readability without any behavior changes.
>>
>> I think that you better to merge patch1/2/3 to one patch.
>
> Yes, when writing the cover letter I think I forgot to explain why I decided not
> to merge these patches. Basically, none of the diff algorithms available in git
> (I've got v2.17.1) is able to produce a readable patch with these changes
> combined together into a single patch (functions are intermixed together in the
> output, git thinks that 'exynos_bus_probe' is a new function).
After merged three patches, as you commented, looks like that 'exynos_bus_probe'
is new function. Your patch style(three patches) is better than one merged patch.
Keep your original patches. Thanks.
>
> Please take a look at the diff at the bottom of this message to see how patches
> 01..03 look when combined. If such patch looks acceptable to you, I can merge.
>
>> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
>>> From: Artur Świgoń <a.swigon@partner.samsung.com>
>>>
>>> This patch adds a new static function, exynos_bus_profile_init(), extracted
>>> from exynos_bus_probe().
>>>
>>> Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
>>> ---
>>> drivers/devfreq/exynos-bus.c | 92 +++++++++++++++++++++---------------
>>> 1 file changed, 53 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 29f422469960..78f38b7fb596 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -287,12 +287,62 @@ static int exynos_bus_parse_of(struct device_node *np,
>>> return ret;
>>> }
>>>
>>> +static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> + struct devfreq_dev_profile *profile)
>>> +{
>>> + struct device *dev = bus->dev;
>>> + struct devfreq_simple_ondemand_data *ondemand_data;
>>> + int ret;
>>> +
>>> + /* Initialize the struct profile and governor data for parent device */
>>> + profile->polling_ms = 50;
>>> + profile->target = exynos_bus_target;
>>> + profile->get_dev_status = exynos_bus_get_dev_status;
>>> + profile->exit = exynos_bus_exit;
>>> +
>>> + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> + if (!ondemand_data) {
>>> + ret = -ENOMEM;
>>> + goto err;
>>> + }
>>> + ondemand_data->upthreshold = 40;
>>> + ondemand_data->downdifferential = 5;
>>> +
>>> + /* Add devfreq device to monitor and handle the exynos bus */
>>> + bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> + ondemand_data);
>>> + if (IS_ERR(bus->devfreq)) {
>>> + dev_err(dev, "failed to add devfreq device\n");
>>> + ret = PTR_ERR(bus->devfreq);
>>> + goto err;
>>> + }
>>> +
>>> + /*
>>> + * Enable devfreq-event to get raw data which is used to determine
>>> + * current bus load.
>>> + */
>>> + ret = exynos_bus_enable_edev(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> + ret = exynos_bus_set_event(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> +err:
>>> + return ret;
>>> +}
>>> +
>>> static int exynos_bus_probe(struct platform_device *pdev)
>>> {
>>> struct device *dev = &pdev->dev;
>>> struct device_node *np = dev->of_node, *node;
>>> struct devfreq_dev_profile *profile;
>>> - struct devfreq_simple_ondemand_data *ondemand_data;
>>> struct devfreq_passive_data *passive_data;
>>> struct devfreq *parent_devfreq;
>>> struct exynos_bus *bus;
>>> @@ -334,45 +384,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> if (passive)
>>> goto passive;
>>>
>>> - /* Initialize the struct profile and governor data for parent device */
>>> - profile->polling_ms = 50;
>>> - profile->target = exynos_bus_target;
>>> - profile->get_dev_status = exynos_bus_get_dev_status;
>>> - profile->exit = exynos_bus_exit;
>>> -
>>> - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> - if (!ondemand_data) {
>>> - ret = -ENOMEM;
>>> + ret = exynos_bus_profile_init(bus, profile);
>>> + if (ret < 0)
>>> goto err;
>>> - }
>>> - ondemand_data->upthreshold = 40;
>>> - ondemand_data->downdifferential = 5;
>>> -
>>> - /* Add devfreq device to monitor and handle the exynos bus */
>>> - bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> - DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> - ondemand_data);
>>> - if (IS_ERR(bus->devfreq)) {
>>> - dev_err(dev, "failed to add devfreq device\n");
>>> - ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> - }
>>> -
>>> - /*
>>> - * Enable devfreq-event to get raw data which is used to determine
>>> - * current bus load.
>>> - */
>>> - ret = exynos_bus_enable_edev(bus);
>>> - if (ret < 0) {
>>> - dev_err(dev, "failed to enable devfreq-event devices\n");
>>> - goto err;
>>> - }
>>> -
>>> - ret = exynos_bus_set_event(bus);
>>> - if (ret < 0) {
>>> - dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> - goto err;
>>> - }
>>>
>>> goto out;
>>> passive:
>
> commit cacf8e4ea0e111908d11779977c81e29d6418801
> Author: Artur Świgoń <a.swigon@partner.samsung.com>
> Date: Tue Aug 27 13:17:28 2019 +0200
>
> tmp: merge patches 01-03
>
> Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 29f422469960..60ad4319fd80 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -287,52 +287,12 @@ static int exynos_bus_parse_of(struct device_node *np,
> return ret;
> }
>
> -static int exynos_bus_probe(struct platform_device *pdev)
> +static int exynos_bus_profile_init(struct exynos_bus *bus,
> + struct devfreq_dev_profile *profile)
> {
> - struct device *dev = &pdev->dev;
> - struct device_node *np = dev->of_node, *node;
> - struct devfreq_dev_profile *profile;
> + struct device *dev = bus->dev;
> struct devfreq_simple_ondemand_data *ondemand_data;
> - struct devfreq_passive_data *passive_data;
> - struct devfreq *parent_devfreq;
> - struct exynos_bus *bus;
> - int ret, max_state;
> - unsigned long min_freq, max_freq;
> - bool passive = false;
> -
> - if (!np) {
> - dev_err(dev, "failed to find devicetree node\n");
> - return -EINVAL;
> - }
> -
> - bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> - if (!bus)
> - return -ENOMEM;
> - mutex_init(&bus->lock);
> - bus->dev = &pdev->dev;
> - platform_set_drvdata(pdev, bus);
> -
> - profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
> - if (!profile)
> - return -ENOMEM;
> -
> - node = of_parse_phandle(dev->of_node, "devfreq", 0);
> - if (node) {
> - of_node_put(node);
> - passive = true;
> - } else {
> - ret = exynos_bus_parent_parse_of(np, bus);
> - if (ret < 0)
> - return ret;
> - }
> -
> - /* Parse the device-tree to get the resource information */
> - ret = exynos_bus_parse_of(np, bus);
> - if (ret < 0)
> - goto err_reg;
> -
> - if (passive)
> - goto passive;
> + int ret;
>
> /* Initialize the struct profile and governor data for parent device */
> profile->polling_ms = 50;
> @@ -374,8 +334,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
> goto err;
> }
>
> - goto out;
> -passive:
> +err:
> + return ret;
> +}
> +
> +static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
> + struct devfreq_dev_profile *profile)
> +{
> + struct device *dev = bus->dev;
> + struct devfreq_passive_data *passive_data;
> + struct devfreq *parent_devfreq;
> + int ret = 0;
> +
> /* Initialize the struct profile and governor data for passive device */
> profile->target = exynos_bus_target;
> profile->exit = exynos_bus_passive_exit;
> @@ -404,7 +374,59 @@ static int exynos_bus_probe(struct platform_device *pdev)
> goto err;
> }
>
> -out:
> +err:
> + return ret;
> +}
> +
> +static int exynos_bus_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node, *node;
> + struct devfreq_dev_profile *profile;
> + struct exynos_bus *bus;
> + int ret, max_state;
> + unsigned long min_freq, max_freq;
> + bool passive = false;
> +
> + if (!np) {
> + dev_err(dev, "failed to find devicetree node\n");
> + return -EINVAL;
> + }
> +
> + bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> + if (!bus)
> + return -ENOMEM;
> + mutex_init(&bus->lock);
> + bus->dev = &pdev->dev;
> + platform_set_drvdata(pdev, bus);
> +
> + profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
> + if (!profile)
> + return -ENOMEM;
> +
> + node = of_parse_phandle(dev->of_node, "devfreq", 0);
> + if (node) {
> + of_node_put(node);
> + passive = true;
> + } else {
> + ret = exynos_bus_parent_parse_of(np, bus);
> + if (ret < 0)
> + return ret;
> + }
> +
> + /* Parse the device-tree to get the resource information */
> + ret = exynos_bus_parse_of(np, bus);
> + if (ret < 0)
> + goto err_reg;
> +
> + if (passive)
> + ret = exynos_bus_profile_init_passive(bus, profile);
> + else
> + ret = exynos_bus_profile_init(bus, profile);
> +
> + if (ret < 0)
> + goto err;
> +
> max_state = bus->devfreq->profile->max_state;
> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
From: Artur Świgoń @ 2019-09-25 6:37 UTC (permalink / raw)
To: Chanwoo Choi, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-pm, dri-devel
Cc: b.zolnierkie, k.konieczny, sw0312.kim, a.swigon, krzk, inki.dae,
myungjoo.ham, cpgs (cpgs@samsung.com), leonard.crestez,
georgi.djakov, m.szyprowski
In-Reply-To: <0cceb46a-fca1-62ae-c2cc-fb0f9b9bd132@samsung.com>
On Wed, 2019-09-25 at 15:12 +0900, Chanwoo Choi wrote:
> Hi,
>
> On 19. 9. 25. 오후 2:47, Artur Świgoń wrote:
> > Hi,
> >
> > On Fri, 2019-09-20 at 11:14 +0900, Chanwoo Choi wrote:
> > > Hi Artur,
> > >
> > > I tried to just build this patch on mainline kernel or linux-next.
> > > But, when I applied them, merge conflict happens. You didn't develop
> > > them on latest version. Please rebase them based on latest mainline kernel.
> >
> > I developed on top of next-20190918 on which I applied
> > https://patchwork.kernel.org/cover/11149497/ as I mentioned in the cover
> > letter. The dev_pm_qos patches and my RFC have just cleanly rebased together on
> > top of next-20190920. Could you check if you have the dev_pm_qos patches (v5,
> > the version number is missing in this one; link above) and if so, where does the
> > conflict appear?
>
> I faced on the merge conflict of drivers/devfreq/exynos-bus.c.
> I think that It is not related to to dev_pm_qos patch.
I think that it is actually related to the specific version of dev_pm_qos (v5) that
I used because patch 08/08 of dev_pm_qos series modifies exynos_bus_probe() in
drivers/devfreq/exynos-bus.c (https://patchwork.kernel.org/patch/11149507/).
I will rebase the next RFC (v3) on latest dev_pm_qos patches from Leonard and the
latest Linux-next kernel.
> Maybe, Kamil's patches[1] changed the many things of exynos-bus.c
> If your test branch doesn't contain following patches,
> you need to rebase your patches based on latest mainline kernel
> from Linus Torvald.
> [1] https://patchwork.kernel.org/cover/11083663/
> - [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
Yes, requiring Kamil's patches is one of the changes in this RFC (v2), since they
are already merged.
> Today, I tried to apply these patch again based on latest mainline kernel.
> The merge conflict happen still.
>
> - merge conflict log
> Applying: devfreq: exynos-bus: Extract exynos_bus_profile_init()
> error: patch failed: drivers/devfreq/exynos-bus.c:334
> error: drivers/devfreq/exynos-bus.c: patch does not apply
> Patch failed at 0001 devfreq: exynos-bus: Extract exynos_bus_profile_init()
>
>
> >
> > > On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote:
> > > > Hi Artur,
> > > >
> > > > On v1, I mentioned that we need to discuss how to change
> > > > the v2 for this. But, I have not received any reply from you on v1.
> > > > And, without your reply from v1, you just send v2.
> > > >
> > > > I think that it is not proper development sequence.
> > > > I have spent many times to review your patches
> > > > and also I'll review your patches. You have to take care
> > > > the reply of reviewer and and keep the basic rule
> > > > of mailing contribution for discussion.
> > > >
> > > > On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> > > > > The following patchset adds interconnect[1][2] framework support to the
> > > > > exynos-bus devfreq driver. Extending the devfreq driver with interconnect
> > > > > capabilities started as a response to the issue referenced in [3]. The
> > > > > patches can be subdivided into four logical groups:
> > > > >
> > > > > (a) Refactoring the existing devfreq driver in order to improve readability
> > > > > and accommodate for adding new code (patches 01--04/11).
> > > > >
> > > > > (b) Tweaking the interconnect framework to support the exynos-bus use case
> > > > > (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to
> > > > > avoid hardcoding every single graph edge in the DT or driver source, and
> > > > > relaxing the requirement contained in that function removes the need to
> > > > > provide dummy node IDs in the DT. Adjusting the logic in
> > > > > apply_constraints() (drivers/interconnect/core.c) accounts for the fact
> > > > > that every bus is a separate entity and therefore a separate interconnect
> > > > > provider, albeit constituting a part of a larger hierarchy.
> > > > >
> > > > > (c) Implementing interconnect providers in the exynos-bus devfreq driver
> > > > > and adding required DT properties for one selected platform, namely
> > > > > Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a
> > > > > generic driver for various Exynos SoCs, node IDs are generated dynamically
> > > > > rather than hardcoded. This has been determined to be a simpler approach,
> > > > > but depends on changes described in (b).
> > > > >
> > > > > (d) Implementing a sample interconnect consumer for exynos-mixer targeted
> > > > > at the issue referenced in [3], again with DT info only for Exynos4412
> > > > > (patches 10--11/11).
> > > > >
> > > > > Integration of devfreq and interconnect functionalities is achieved by
> > > > > using dev_pm_qos_*() API[5]. All new code works equally well when
> > > > > CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all
> > > > > interconnect API functions are no-ops.
> > > > >
> > > > > This patchset depends on [5].
> > > > >
> > > > > --- Changes since v1 [6]:
> > > > > * Rebase on [4] (coupled regulators).
> > > > > * Rebase on [5] (dev_pm_qos for devfreq).
> > > > > * Use dev_pm_qos_*() API[5] instead of overriding frequency in
> > > > > exynos_bus_target().
> > > > > * Use IDR for node ID allocation.
> > > > > * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04).
> > > > > * Reverse order of multiplication and division in
> > > > > mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow.
> > > > >
> > > > > ---
> > > > > Artur Świgoń
> > > > > Samsung R&D Institute Poland
> > > > > Samsung Electronics
> > > > >
> > > > > ---
> > > > > References:
> > > > > [1] Documentation/interconnect/interconnect.rst
> > > > > [2] Documentation/devicetree/bindings/interconnect/interconnect.txt
> > > > > [3] https://patchwork.kernel.org/patch/10861757/ (original issue)
> > > > > [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged)
> > > > > [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq)
> > > > > [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
> > > > >
> > > > > Artur Świgoń (10):
> > > > > devfreq: exynos-bus: Extract exynos_bus_profile_init()
> > > > > devfreq: exynos-bus: Extract exynos_bus_profile_init_passive()
> > > > > devfreq: exynos-bus: Change goto-based logic to if-else logic
> > > > > devfreq: exynos-bus: Clean up code
> > > > > interconnect: Export of_icc_get_from_provider()
> > > > > interconnect: Relax requirement in of_icc_get_from_provider()
> > > > > interconnect: Relax condition in apply_constraints()
> > > > > arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
> > > > > devfreq: exynos-bus: Add interconnect functionality to exynos-bus
> > > > > arm: dts: exynos: Add interconnects to Exynos4412 mixer
> > > > >
> > > > > Marek Szyprowski (1):
> > > > > drm: exynos: mixer: Add interconnect support
> > > > >
> > > > > .../boot/dts/exynos4412-odroid-common.dtsi | 1 +
> > > > > arch/arm/boot/dts/exynos4412.dtsi | 10 +
> > > > > drivers/devfreq/exynos-bus.c | 319 +++++++++++++-----
> > > > > drivers/gpu/drm/exynos/exynos_mixer.c | 71 +++-
> > > > > drivers/interconnect/core.c | 12 +-
> > > > > include/linux/interconnect-provider.h | 6 +
> > > > > 6 files changed, 327 insertions(+), 92 deletions(-)
> > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Artur Świgoń @ 2019-09-25 6:41 UTC (permalink / raw)
To: Chanwoo Choi, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-pm, dri-devel
Cc: b.zolnierkie, sw0312.kim, a.swigon, krzk, inki.dae, myungjoo.ham,
leonard.crestez, georgi.djakov, m.szyprowski
In-Reply-To: <9cd6267e-cc06-107e-9bdf-33d4b66f35da@samsung.com>
On Wed, 2019-09-25 at 15:37 +0900, Chanwoo Choi wrote:
> Hi,
>
> On 19. 9. 25. 오후 2:44, Artur Świgoń wrote:
> > Hi,
> >
> > On Fri, 2019-09-20 at 11:15 +0900, Chanwoo Choi wrote:
> > > Hi,
> > >
> > > As I already replied on v1, patch1/2/3 clean-up code
> > > for readability without any behavior changes.
> > >
> > > I think that you better to merge patch1/2/3 to one patch.
> >
> > Yes, when writing the cover letter I think I forgot to explain why I decided not
> > to merge these patches. Basically, none of the diff algorithms available in git
> > (I've got v2.17.1) is able to produce a readable patch with these changes
> > combined together into a single patch (functions are intermixed together in the
> > output, git thinks that 'exynos_bus_probe' is a new function).
>
> After merged three patches, as you commented, looks like that 'exynos_bus_probe'
> is new function. Your patch style(three patches) is better than one merged patch.
> Keep your original patches. Thanks.
I know that having three separate patches is suboptimal, but they are more readable
this way. I am glad you agree. I will keep them separate. Thank you for your
comments.
> >
> > Please take a look at the diff at the bottom of this message to see how patches
> > 01..03 look when combined. If such patch looks acceptable to you, I can merge.
> >
> > > On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> > > > From: Artur Świgoń <a.swigon@partner.samsung.com>
> > > >
> > > > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > > > from exynos_bus_probe().
> > > >
> > > > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > > > ---
> > > > drivers/devfreq/exynos-bus.c | 92 +++++++++++++++++++++---------------
> > > > 1 file changed, 53 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > > > index 29f422469960..78f38b7fb596 100644
> > > > --- a/drivers/devfreq/exynos-bus.c
> > > > +++ b/drivers/devfreq/exynos-bus.c
> > > > @@ -287,12 +287,62 @@ static int exynos_bus_parse_of(struct device_node *np,
> > > > return ret;
> > > > }
> > > >
> > > > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > > > + struct devfreq_dev_profile *profile)
> > > > +{
> > > > + struct device *dev = bus->dev;
> > > > + struct devfreq_simple_ondemand_data *ondemand_data;
> > > > + int ret;
> > > > +
> > > > + /* Initialize the struct profile and governor data for parent device */
> > > > + profile->polling_ms = 50;
> > > > + profile->target = exynos_bus_target;
> > > > + profile->get_dev_status = exynos_bus_get_dev_status;
> > > > + profile->exit = exynos_bus_exit;
> > > > +
> > > > + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > > > + if (!ondemand_data) {
> > > > + ret = -ENOMEM;
> > > > + goto err;
> > > > + }
> > > > + ondemand_data->upthreshold = 40;
> > > > + ondemand_data->downdifferential = 5;
> > > > +
> > > > + /* Add devfreq device to monitor and handle the exynos bus */
> > > > + bus->devfreq = devm_devfreq_add_device(dev, profile,
> > > > + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > > > + ondemand_data);
> > > > + if (IS_ERR(bus->devfreq)) {
> > > > + dev_err(dev, "failed to add devfreq device\n");
> > > > + ret = PTR_ERR(bus->devfreq);
> > > > + goto err;
> > > > + }
> > > > +
> > > > + /*
> > > > + * Enable devfreq-event to get raw data which is used to determine
> > > > + * current bus load.
> > > > + */
> > > > + ret = exynos_bus_enable_edev(bus);
> > > > + if (ret < 0) {
> > > > + dev_err(dev, "failed to enable devfreq-event devices\n");
> > > > + goto err;
> > > > + }
> > > > +
> > > > + ret = exynos_bus_set_event(bus);
> > > > + if (ret < 0) {
> > > > + dev_err(dev, "failed to set event to devfreq-event devices\n");
> > > > + goto err;
> > > > + }
> > > > +
> > > > +err:
> > > > + return ret;
> > > > +}
> > > > +
> > > > static int exynos_bus_probe(struct platform_device *pdev)
> > > > {
> > > > struct device *dev = &pdev->dev;
> > > > struct device_node *np = dev->of_node, *node;
> > > > struct devfreq_dev_profile *profile;
> > > > - struct devfreq_simple_ondemand_data *ondemand_data;
> > > > struct devfreq_passive_data *passive_data;
> > > > struct devfreq *parent_devfreq;
> > > > struct exynos_bus *bus;
> > > > @@ -334,45 +384,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > > > if (passive)
> > > > goto passive;
> > > >
> > > > - /* Initialize the struct profile and governor data for parent device */
> > > > - profile->polling_ms = 50;
> > > > - profile->target = exynos_bus_target;
> > > > - profile->get_dev_status = exynos_bus_get_dev_status;
> > > > - profile->exit = exynos_bus_exit;
> > > > -
> > > > - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > > > - if (!ondemand_data) {
> > > > - ret = -ENOMEM;
> > > > + ret = exynos_bus_profile_init(bus, profile);
> > > > + if (ret < 0)
> > > > goto err;
> > > > - }
> > > > - ondemand_data->upthreshold = 40;
> > > > - ondemand_data->downdifferential = 5;
> > > > -
> > > > - /* Add devfreq device to monitor and handle the exynos bus */
> > > > - bus->devfreq = devm_devfreq_add_device(dev, profile,
> > > > - DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > > > - ondemand_data);
> > > > - if (IS_ERR(bus->devfreq)) {
> > > > - dev_err(dev, "failed to add devfreq device\n");
> > > > - ret = PTR_ERR(bus->devfreq);
> > > > - goto err;
> > > > - }
> > > > -
> > > > - /*
> > > > - * Enable devfreq-event to get raw data which is used to determine
> > > > - * current bus load.
> > > > - */
> > > > - ret = exynos_bus_enable_edev(bus);
> > > > - if (ret < 0) {
> > > > - dev_err(dev, "failed to enable devfreq-event devices\n");
> > > > - goto err;
> > > > - }
> > > > -
> > > > - ret = exynos_bus_set_event(bus);
> > > > - if (ret < 0) {
> > > > - dev_err(dev, "failed to set event to devfreq-event devices\n");
> > > > - goto err;
> > > > - }
> > > >
> > > > goto out;
> > > > passive:
> >
> > commit cacf8e4ea0e111908d11779977c81e29d6418801
> > Author: Artur Świgoń <a.swigon@partner.samsung.com>
> > Date: Tue Aug 27 13:17:28 2019 +0200
> >
> > tmp: merge patches 01-03
> >
> > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 29f422469960..60ad4319fd80 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -287,52 +287,12 @@ static int exynos_bus_parse_of(struct device_node *np,
> > return ret;
> > }
> >
> > -static int exynos_bus_probe(struct platform_device *pdev)
> > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > + struct devfreq_dev_profile *profile)
> > {
> > - struct device *dev = &pdev->dev;
> > - struct device_node *np = dev->of_node, *node;
> > - struct devfreq_dev_profile *profile;
> > + struct device *dev = bus->dev;
> > struct devfreq_simple_ondemand_data *ondemand_data;
> > - struct devfreq_passive_data *passive_data;
> > - struct devfreq *parent_devfreq;
> > - struct exynos_bus *bus;
> > - int ret, max_state;
> > - unsigned long min_freq, max_freq;
> > - bool passive = false;
> > -
> > - if (!np) {
> > - dev_err(dev, "failed to find devicetree node\n");
> > - return -EINVAL;
> > - }
> > -
> > - bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> > - if (!bus)
> > - return -ENOMEM;
> > - mutex_init(&bus->lock);
> > - bus->dev = &pdev->dev;
> > - platform_set_drvdata(pdev, bus);
> > -
> > - profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
> > - if (!profile)
> > - return -ENOMEM;
> > -
> > - node = of_parse_phandle(dev->of_node, "devfreq", 0);
> > - if (node) {
> > - of_node_put(node);
> > - passive = true;
> > - } else {
> > - ret = exynos_bus_parent_parse_of(np, bus);
> > - if (ret < 0)
> > - return ret;
> > - }
> > -
> > - /* Parse the device-tree to get the resource information */
> > - ret = exynos_bus_parse_of(np, bus);
> > - if (ret < 0)
> > - goto err_reg;
> > -
> > - if (passive)
> > - goto passive;
> > + int ret;
> >
> > /* Initialize the struct profile and governor data for parent device */
> > profile->polling_ms = 50;
> > @@ -374,8 +334,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > goto err;
> > }
> >
> > - goto out;
> > -passive:
> > +err:
> > + return ret;
> > +}
> > +
> > +static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
> > + struct devfreq_dev_profile *profile)
> > +{
> > + struct device *dev = bus->dev;
> > + struct devfreq_passive_data *passive_data;
> > + struct devfreq *parent_devfreq;
> > + int ret = 0;
> > +
> > /* Initialize the struct profile and governor data for passive device */
> > profile->target = exynos_bus_target;
> > profile->exit = exynos_bus_passive_exit;
> > @@ -404,7 +374,59 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > goto err;
> > }
> >
> > -out:
> > +err:
> > + return ret;
> > +}
> > +
> > +static int exynos_bus_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node, *node;
> > + struct devfreq_dev_profile *profile;
> > + struct exynos_bus *bus;
> > + int ret, max_state;
> > + unsigned long min_freq, max_freq;
> > + bool passive = false;
> > +
> > + if (!np) {
> > + dev_err(dev, "failed to find devicetree node\n");
> > + return -EINVAL;
> > + }
> > +
> > + bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> > + if (!bus)
> > + return -ENOMEM;
> > + mutex_init(&bus->lock);
> > + bus->dev = &pdev->dev;
> > + platform_set_drvdata(pdev, bus);
> > +
> > + profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
> > + if (!profile)
> > + return -ENOMEM;
> > +
> > + node = of_parse_phandle(dev->of_node, "devfreq", 0);
> > + if (node) {
> > + of_node_put(node);
> > + passive = true;
> > + } else {
> > + ret = exynos_bus_parent_parse_of(np, bus);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> > + /* Parse the device-tree to get the resource information */
> > + ret = exynos_bus_parse_of(np, bus);
> > + if (ret < 0)
> > + goto err_reg;
> > +
> > + if (passive)
> > + ret = exynos_bus_profile_init_passive(bus, profile);
> > + else
> > + ret = exynos_bus_profile_init(bus, profile);
> > +
> > + if (ret < 0)
> > + goto err;
> > +
> > max_state = bus->devfreq->profile->max_state;
> > min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> > max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
> >
> >
> >
> >
>
>
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
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