* ARM: imx: mmdc: Fix completely broken cpu hotplug code
From: Shawn Guo @ 2016-12-22 0:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1612211928430.3424@nanos>
On Wed, Dec 21, 2016 at 07:32:06PM +0100, Thomas Gleixner wrote:
> On Wed, 21 Dec 2016, Thomas Gleixner wrote:
> > The cpu hotplug support of this perf driver is broken in several ways:
> >
> > 1) It adds a instance before setting up the state.
> >
> > 2) The state for the instance is different from the state of the
> > callback. It's just a randomly chosen state.
> >
> > 3) The instance registration is not error checked so nobody noticed that
> > the call can never succeed.
> >
> > 4) The state for the multi install callbacks is chosen randomly and
> > overwrites existing state. This is now prevented by the core code so the
> > call is guaranteed to fail.
> >
> > 5) The error exit path in the init function leaves the instance registered
> > and then frees the memory which contains the enqueued hlist node.
> >
> > 6) The remove function is removing the state and not the instance.
> >
> > Fix it by:
> >
> > - Setting up the state before adding instances. Use a dynamically allocated
> > state for it.
> >
> > - Install instances after the state has been set up
> >
> > - Remove the instance in the error path before freeing memory
> >
> > - Remove instance not the state in the driver remove callback
> >
> > While at is use raw_cpu_processor_id(), because cpu_processor_id() cannot
> > be used in preemptible context, and set the driver data after successful
> > registration of the pmu.
> >
> > Fixes: e76bdfd7403a ("ARM: imx: Added perf functionality to mmdc driver")
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Zhengyu Shen <zhengyu.shen@nxp.com>
> > Cc: Frank Li <frank.li@nxp.com>
> > Cc: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shawn Guo <shawnguo@kernel.org>
>
> Shawn,
>
> as I have the final hotplug notifier removal pending here, which will break
> also the compilation of this driver, I would prefer to merge that through
> my tree before the removal patches to avoid build breakage.
Okay, thanks for taking care of it.
Shawn
^ permalink raw reply
* [RESEND PATCH v2] arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399
From: Doug Anderson @ 2016-12-22 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482316865-2769-1-git-send-email-zhengxing@rock-chips.com>
Hi,
On Wed, Dec 21, 2016 at 2:41 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> From: William wu <wulf@rock-chips.com>
>
> We found that the suspend process was blocked when it run into
> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>
> The root cause is that usb2-phy suspended earlier than ehci/ohci
> (usb2-phy will be auto suspended if no devices plug-in). and the
> clk-480m provided by it was disabled if no module used. However,
> some suspend process related ehci/ohci are base on this clock,
> so we should refer it into ehci/ohci driver to prevent this case.
>
> The u2phy clock flow like this:
> ===
> u2phy ________________
> | | |-----> UTMI_CLK ---------> | EHCI |
> OSC_24M ---|---> PHY_PLL----|----|
> |________^_______| |-----> 480M_CLK ---|G|---> | USBPHY_480M_SRC| ----> USBPHY_480M for SoC
> |
> |
> GRF
> ===
>
> Signed-off-by: William wu <wulf@rock-chips.com>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v2:
> - update the commit message
> - remove patches whic add and export the USBPHYx_480M_SRC clock IDs
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index b65c193..2ad9255 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -315,8 +315,10 @@
> compatible = "generic-ehci";
> reg = <0x0 0xfe380000 0x0 0x20000>;
> interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
> - clock-names = "hclk_host0", "hclk_host0_arb";
> + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> + <&u2phy0>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> phys = <&u2phy0_host>;
> phy-names = "usb";
> status = "disabled";
> @@ -326,8 +328,12 @@
> compatible = "generic-ohci";
> reg = <0x0 0xfe3a0000 0x0 0x20000>;
> interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>;
> - clock-names = "hclk_host0", "hclk_host0_arb";
> + clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
> + <&u2phy0>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> + phys = <&u2phy0_host>;
> + phy-names = "usb";
> status = "disabled";
> };
>
> @@ -335,8 +341,10 @@
> compatible = "generic-ehci";
> reg = <0x0 0xfe3c0000 0x0 0x20000>;
> interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
> - clock-names = "hclk_host1", "hclk_host1_arb";
> + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>,
> + <&u2phy1>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> phys = <&u2phy1_host>;
> phy-names = "usb";
> status = "disabled";
> @@ -346,8 +354,12 @@
> compatible = "generic-ohci";
> reg = <0x0 0xfe3e0000 0x0 0x20000>;
> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>;
> - clock-names = "hclk_host1", "hclk_host1_arb";
> + clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>,
> + <&u2phy1>;
> + clock-names = "usbhost", "arbiter",
> + "utmi";
> + phys = <&u2phy1_host>;
> + phy-names = "usb";
This all looks better to me. From a device tree point of view it
makes lots of sense to expose this PHY clock to the controller. Thus:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
I can't say that I understand all the interactions between the PHY
code and the USB driver, but presumably others have reviewed that
more? Offline Heiko pointed me at rockchip_usb2phy_otg_sm_work()
which apparently calls rockchip_usb2phy_power_off() and
rockchip_usb2phy_power_on() directly sometimes behind the back of the
PHY framework. Very strange.
I will also say that there were still some unanswered questions from
the previous thread, namely:
A) Heiko: Also, with the change, the ehci will keep the clock (and
thus the phy) always on. Does the phy-autosuspend even save anything
now?
B) Brian: Is thre a race between power_off() and the delayed work in
your USB2 PHY driver?
IMHO neither of those two questions affect the correctness of this
patch: that this clock ought to be provided to the USB Controller.
...but they both are important questions that should be answered.
One other last note is that we probably should be specifying a more
specific compatible string, like:
"rk3399-ehci", "generic-ehci"
That will allow us later to use these same device tree files and
perhaps deal with the clocks / PHYs in a more efficient way.
-Doug
^ permalink raw reply
* [PATCHv2 2/3] clk: mvebu: adjust clock handling for the CP110 system controller
From: Stephen Boyd @ 2016-12-22 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482316017-22154-3-git-send-email-thomas.petazzoni@free-electrons.com>
On 12/21, Thomas Petazzoni wrote:
> This commit:
>
> - makes the GOP_DP (bit 9) gatable clock a child clock of the
> SD_MMC_GOP (bit 18) clock, as it should have been. The clock for bit
> 18 was just named SD_MMC, but since it also covers the GOP block, it
> is renamed SD_MMC_GOP.
>
> - makes the MG (bit 5) gatable clock a child clock of the MG_CORE
> clock (bit 6)
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv2 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Stephen Boyd @ 2016-12-22 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482316017-22154-2-git-send-email-thomas.petazzoni@free-electrons.com>
On 12/21, Thomas Petazzoni wrote:
> It turns out that in the CP110 HW block present in Marvell Armada
> 7K/8K SoCs, gatable clock n?18 not only controls SD/MMC, but also the
> GOP block. This commit updates the Device Tree binding for this piece
> of hardware accordingly.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 7/9] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-8-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
> from pll-sai-p.
>
> The SDIO clock could be also derived from 48Mhz or from sys clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 6/9] clk: stm32f4: Add SAI clocks
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-7-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces SAI clocks for stm32f4 socs.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 5/9] clk: stm32f4: Add I2S clock
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-6-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces I2S clock for stm32f4 soc.
> The I2S clock could be derived from an external clock or from pll-i2s
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 4/9] clk: stm32f4: Add lcd-tft clock
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-5-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces lcd-tft clock for stm32f4 soc.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 3/9] clk: stm32f4: Add post divisor for I2S & SAI PLLs
From: Stephen Boyd @ 2016-12-22 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-4-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds post dividers of I2S & SAI PLLs.
> These dividers are managed by a dedicated register (RCC_DCKCFGR).
> The PLL should be off before a set rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 2/9] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Stephen Boyd @ 2016-12-22 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-3-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces PLL_I2S and PLL_SAI.
> Vco clock of these PLLs can be modify by DT (only n multiplicator,
> m divider is still fixed by the boot-loader).
> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-stm32f4 and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 1/9] clk: stm32f4: Update DT bindings documentation
From: Stephen Boyd @ 2016-12-22 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-2-git-send-email-gabriel.fernandez@st.com>
On 12/13, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Creation of dt include file for specific stm32f4 clocks.
> These specific clocks are not derived from system clock (SYSCLOCK)
> We should use index 1 to use these clocks in DT.
> e.g. <&rcc 1 CLK_LSI>
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-stm32f4 and merged into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Icenowy Zheng @ 2016-12-22 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221224159.wnziqeanjkp63y4o@lukather>
22.12.2016, 06:42, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote:
>> ?Lichee Pi One is a low-cost Allwinner A13-based development board, with
>> ?an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
>> ?RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
>> ?headers and two MicroSD card slots (connected to mmc0 and mmc2, both
>> ?bootable).
>>
>> ?Add support for it.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Excuse me. Who should apply it?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* jemalloc testsuite stalls in memset
From: Minchan Kim @ 2016-12-21 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d1gshscr.fsf@suse.de>
Hello, Andreas
Sorry for long delay. I was on vacation.
On Fri, Dec 16, 2016 at 03:16:20PM +0100, Andreas Schwab wrote:
> On Dez 16 2016, Minchan Kim <minchan@kernel.org> wrote:
>
> > Below helps?
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index e10a4fe..dc37c9a 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1611,6 +1611,7 @@ int madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> > tlb->fullmm);
> > orig_pmd = pmd_mkold(orig_pmd);
> > orig_pmd = pmd_mkclean(orig_pmd);
> > + orig_pmd = pmd_wrprotect(orig_pmd);
> >
> > set_pmd_at(mm, addr, pmd, orig_pmd);
> > tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
>
> Thanks, this fixes the issue (tested with 4.9).
It was a quick hack to know what exact problem is there and your confirming
helped a lot to understand the problem clear.
More right approach is to support pmd dirty handling in general page fault
handler rather than tweaking MADV_FREE. I just sent a new patch with Ccing
you.
Could you test it, please?
Thanks!
^ permalink raw reply
* [PATCH] mm: pmd dirty emulation in page fault handler
From: Minchan Kim @ 2016-12-21 23:48 UTC (permalink / raw)
To: linux-arm-kernel
Andreas reported [1] made a test in jemalloc hang in THP mode in arm64.
http://lkml.kernel.org/r/mvmmvfy37g1.fsf at hawking.suse.de
The problem is page fault handler supports only accessed flag emulation
for THP page of SW-dirty/accessed architecture.
This patch enables dirty-bit emulation for those architectures.
Without it, MADV_FREE makes application hang by repeated fault forever.
[1] mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called
Cc: Jason Evans <je@fb.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arch at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: <stable@vger.kernel.org> [4.5+]
Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
Reported-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
mm/huge_memory.c | 6 ++++--
mm/memory.c | 18 ++++++++++--------
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 10eedbf..29ec8a4 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -883,15 +883,17 @@ void huge_pmd_set_accessed(struct vm_fault *vmf, pmd_t orig_pmd)
{
pmd_t entry;
unsigned long haddr;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
vmf->ptl = pmd_lock(vmf->vma->vm_mm, vmf->pmd);
if (unlikely(!pmd_same(*vmf->pmd, orig_pmd)))
goto unlock;
entry = pmd_mkyoung(orig_pmd);
+ if (write)
+ entry = pmd_mkdirty(entry);
haddr = vmf->address & HPAGE_PMD_MASK;
- if (pmdp_set_access_flags(vmf->vma, haddr, vmf->pmd, entry,
- vmf->flags & FAULT_FLAG_WRITE))
+ if (pmdp_set_access_flags(vmf->vma, haddr, vmf->pmd, entry, write))
update_mmu_cache_pmd(vmf->vma, vmf->address, vmf->pmd);
unlock:
diff --git a/mm/memory.c b/mm/memory.c
index 36c774f..7408ddc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3637,18 +3637,20 @@ static int __handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
if (pmd_protnone(orig_pmd) && vma_is_accessible(vma))
return do_huge_pmd_numa_page(&vmf, orig_pmd);
- if ((vmf.flags & FAULT_FLAG_WRITE) &&
- !pmd_write(orig_pmd)) {
- ret = wp_huge_pmd(&vmf, orig_pmd);
- if (!(ret & VM_FAULT_FALLBACK))
+ if (vmf.flags & FAULT_FLAG_WRITE) {
+ if (!pmd_write(orig_pmd)) {
+ ret = wp_huge_pmd(&vmf, orig_pmd);
+ if (ret == VM_FAULT_FALLBACK)
+ goto pte_fault;
return ret;
- } else {
- huge_pmd_set_accessed(&vmf, orig_pmd);
- return 0;
+ }
}
+
+ huge_pmd_set_accessed(&vmf, orig_pmd);
+ return 0;
}
}
-
+pte_fault:
return handle_pte_fault(&vmf);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Stephen Boyd @ 2016-12-21 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220225530.96699-2-code@mmayer.net>
On 12/20, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> Add binding document for brcm,brcmstb-cpu-clk-div.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
> .../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 83 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> new file mode 100644
> index 0000000..3bc99c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,83 @@
> +The CPU divider node serves as the sole clock for the CPU complex. It supports
> +power-of-2 clock division, with a divider of "1" as the default highest-speed
> +setting.
> +
> +Required properties:
> +- compatible: shall be "brcm,brcmstb-cpu-clk-div"
> +- reg: address and width of the divider configuration register
> +- #clock-cells: shall be set to 0
> +- clocks: phandle of clock provider which provides the source clock
> + (this would typically be a "fixed-clock" type PLL)
> +- div-table: list of (raw_value,divider) ordered pairs that correspond to the
> + allowed clock divider settings
> +- div-shift-width: least-significant bit position and width of divider value
> +
> +Optional properties:
> +- clocks: additional clocks can be specified if needed
> +- clock-names: clocks can be named, so they can be looked up
> +
> +Example:
> + sw_scb: sw_scb {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <432000000>;
> + };
> +
Is this a PLL?
> + fixed0: fixed0 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <54000000>;
> + };
And perhaps some sort of oscillator?
> +
> + cpu_pdiv: cpu_pdiv at f04e0008 {
> + compatible = "divider-clock";
> + #clock-cells = <0>;
> + reg = <0xf04e0008 0x4>;
> + bit-shift = <10>;
> + bit-mask = <0xf>;
> + index-starts-at-one;
> + clocks = <&fixed0>;
> + clock-names = "fixed0";
> + };
> +
> + cpu_ndiv_int: cpu_ndiv_int {
> + compatible = "fixed-factor-clock";
Ok..
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <167>;
> + clocks = <&cpu_pdiv>;
> + clock-names = "cpu_pdiv";
> + };
> +
> + cpu_mdiv_ch0: cpu_mdiv_ch0 at f04e0000 {
> + compatible = "divider-clock";
Is there a binding for this?
> + #clock-cells = <0>;
> + reg = <0xf04e0000 0x4>;
> + bit-shift = <1>;
> + bit-mask = <0xff>;
> + index-starts-at-one;
> + clocks = <&cpu_ndiv_int>;
> + clock-names = "cpu_ndiv_int";
> + };
> +
> + cpupll: cpupll at 0 {
> + #clock-cells = <0>;
> + clock-frequency = <1503000000>;
> + compatible = "fixed-clock";
> + };
> +
> + cpuclkdiv: cpu-clk-div at 0 {
Wrong unit address. Should be f03e257c?
> + #clock-cells = <0>;
> + clock-names = "cpupll",
> + "cpu_mdiv_ch0",
> + "cpu_ndiv_int",
> + "sw_scb";
> + clocks = <&cpupll,
> + &cpu_mdiv_ch0,
> + &cpu_ndiv_int,
> + &sw_scb>;
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;
> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
This entire DT design seems wrong. We don't put these sorts of
register level details into DT. There should be a driver that
knows the type of device that is present and how to drive that
hardware.
>From what I can tell there's something like a mux controller at
0xf04e0000 and then there's some sort of divider controller at
0xf03e0000. Perhaps those are two different devices that need
independent drivers? My wild guess is the PLL control is in those
register regions too, but we're not exposing control of them.
That's ok, but don't put the PLL into the DT as a fixed clock.
Just register it from the driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725348-860-1-git-send-email-gabriel.fernandez@st.com>
On 12/14, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Clock and reset controller use same compatible strings (same IP).
>
> Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
> clocks") the OF core flags clock controllers registered with the
> CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
> compatible string will not be registered.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/3] clk: zte: add audio clocks for zx296718
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481873207-22929-4-git-send-email-shawnguo@kernel.org>
On 12/16, Shawn Guo wrote:
> From: Jun Nie <jun.nie@linaro.org>
>
> The audio related clock support is missing from the existing zx296718
> clock driver. Let's add it, so that the upstream ZX SPDIF driver can
> work for HDMI audio support.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Applied to clk-next + I added static to some more structures.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: zx296718-clk: add compatible for audio clock controller
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481873207-22929-3-git-send-email-shawnguo@kernel.org>
On 12/16, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> It adds the compatible string for zx296718 audio clock controller.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/3] clk: zx296718: do not panic on failure
From: Stephen Boyd @ 2016-12-21 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481873207-22929-2-git-send-email-shawnguo@kernel.org>
On 12/16, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> Instead of using panic, we should give an error message and return error
> code when of_clk_add_hw_provider() call fails.
>
> Since we have error prompt for failures, the "init over" pr_info output
> isn't really necessary but becomes a debug noise. So let's clean it up
> along the way.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-21 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481781493-6188-3-git-send-email-zhangfei.gao@linaro.org>
On 12/15, Zhangfei Gao wrote:
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Add some commit text here?
> diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c
> new file mode 100644
> index 0000000..42ca47d
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3660.c
> @@ -0,0 +1,601 @@
> +/*
> + * Copyright (c) 2016-2017 Linaro Ltd.
> + * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <dt-bindings/clock/hi3660-clock.h>
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
This isn't needed.
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk.h"
> +
[...]
> +
> +static int hi3660_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = pdev->dev.of_node;
> + const struct of_device_id *of_id;
> + enum hi3660_clk_type type;
> +
> + of_id = of_match_device(hi3660_clk_match_table, dev);
> + if (!of_id)
> + return -EINVAL;
> +
> + type = (enum hi3660_clk_type)of_id->data;
Use of_device_get_match_data() instead please.
> +
> + switch (type) {
> + case HI3660_CRGCTRL:
> + hi3660_clk_crgctrl_init(np);
> + break;
> + case HI3660_PCTRL:
> + hi3660_clk_pctrl_init(np);
> + break;
> + case HI3660_PMUCTRL:
> + hi3660_clk_pmuctrl_init(np);
> + break;
> + case HI3660_SCTRL:
> + hi3660_clk_sctrl_init(np);
> + break;
> + case HI3660_IOMCU:
> + hi3660_clk_iomcu_init(np);
> + break;
This "multi-device" driver design is sort of odd. Why not have
different files and struct drivers for the different devices in
the system that are clock controllers? I don't really understand
why we're controlling the devices with one struct driver
instance. Is something shared between the devices?
> + default:
> + break;
> + }
> + return 0;
> +}
[...]
> +
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi3660-clk");
> +MODULE_DESCRIPTION("HiSilicon Hi3660 Clock Driver");
You can drop these MODULE_* things as they're not going to be
used in builtin only code.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/2] mark driver as non-removable
From: Russell King - ARM Linux @ 2016-12-21 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-1-alexander.stein@systec-electronic.com>
On Wed, Dec 21, 2016 at 04:03:38PM +0100, Alexander Stein wrote:
> Changes in v2;
> * Instead of adding a remove function which is unused otherwise, mark the driver
> as non-remoable
>
> Using DEBUG_TEST_DRIVER_REMOVE every driver gets probed, removed and probed
> again. This breaks drivers without removal function, e.g. arm perf
> resulting in the following dump:
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x6c/0x7c
> sysfs: cannot create duplicate filename '/devices/armv7_cortex_a7'
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #212
> Hardware name: Freescale LS1021A
> Backtrace:
> [<8020c044>] (dump_backtrace) from [<8020c2f0>] (show_stack+0x18/0x1c)
> r7:00000009 r6:60000013 r5:80c1776c r4:00000000
> [<8020c2d8>] (show_stack) from [<8046ead8>] (dump_stack+0x94/0xa8)
> [<8046ea44>] (dump_stack) from [<8021ecd0>] (__warn+0xec/0x104)
> r7:00000009 r6:8092efc8 r5:00000000 r4:bf04bd80
> [<8021ebe4>] (__warn) from [<8021ed28>] (warn_slowpath_fmt+0x40/0x48)
> r9:80a32848 r8:00000000 r7:00000000 r6:bf0ab780 r5:8091d590 r4:bf0df000
> [<8021ecec>] (warn_slowpath_fmt) from [<8036d53c>] (sysfs_warn_dup+0x6c/0x7c)
> r3:bf0df000 r2:8092ef94
> [<8036d4d0>] (sysfs_warn_dup) from [<8036d628>] (sysfs_create_dir_ns+0x8c/0x9c)
> r6:bf0ab780 r5:bf20ee08 r4:ffffffef
> [<8036d59c>] (sysfs_create_dir_ns) from [<80471860>] (kobject_add_internal+0xa8/0x34c)
> r6:bf0aa198 r5:00000000 r4:bf20ee08
> [<804717b8>] (kobject_add_internal) from [<80471b54>] (kobject_add+0x50/0x94)
> r7:00000000 r6:00000000 r5:00000000 r4:bf20ee08
> [<80471b08>] (kobject_add) from [<80524590>] (device_add+0xe4/0x590)
> r3:00000000 r2:00000000
> r6:bf20ee00 r5:00000000 r4:bf20ee08
> [<805244ac>] (device_add) from [<802a38a8>] (pmu_dev_alloc+0x88/0xd8)
> r10:00000091 r9:80a32848 r8:00000000 r7:80a32840 r6:80c0ed3c r5:00000000
> r4:bf1fe800
> [<802a3820>] (pmu_dev_alloc) from [<80a0cd20>] (perf_event_sysfs_init+0x5c/0xb4)
> r7:80a32840 r6:00000000 r5:bf1fe800 r4:80c0ede0
> [<80a0ccc4>] (perf_event_sysfs_init) from [<80201778>] (do_one_initcall+0x48/0x178)
> r6:80c45000 r5:80a0ccc4 r4:00000006
> [<80201730>] (do_one_initcall) from [<80a00ecc>] (kernel_init_freeable+0x168/0x20c)
> r8:80a00610 r7:80a32840 r6:80c45000 r5:80c45000 r4:00000006
> [<80a00d64>] (kernel_init_freeable) from [<806febcc>] (kernel_init+0x10/0x11c)
> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:806febbc
> r4:00000000
> [<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c)
> r5:806febbc r4:00000000
> ---[ end trace 9d251d389382804f ]---
Please consider putting some of the above in patch 2's description, so
the reason for the patch doesn't get lost. If you want to reduce the
commit message, you could consider cutting the registers from the
backtrace (which are only useful when doing in-depth debugging, not for
illustrating the callpath.)
I'd like to see acks on both of these before I take patch 2, but I'm not
expecting that to happen until the new year.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 02/11] clk: bcm2835: Register the DSI0/DSI1 pixel clocks.
From: Stephen Boyd @ 2016-12-21 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214194621.16499-3-eric@anholt.net>
On 12/14, Eric Anholt wrote:
>
> /* the gates */
>
> @@ -1890,8 +1976,18 @@ static int bcm2835_clk_probe(struct platform_device *pdev)
> if (IS_ERR(cprman->regs))
> return PTR_ERR(cprman->regs);
>
> - cprman->osc_name = of_clk_get_parent_name(dev->of_node, 0);
> - if (!cprman->osc_name)
> + for (i = 0; i < ARRAY_SIZE(cprman_parent_names); i++) {
> + cprman->real_parent_names[i] =
> + of_clk_get_parent_name(dev->of_node, i);
> + }
Can we use of_clk_parent_fill() here? Or do we need to support
holes in the parent array? If it's the latter please add a
comment so we don't mistakenly change this later.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] arm64: Don't trace __switch_to if function graph tracer is enabled
From: Joel Fernandes @ 2016-12-21 22:44 UTC (permalink / raw)
To: linux-arm-kernel
Function graph tracer shows negative time (wrap around) when tracing
__switch_to if the nosleep-time trace option is enabled.
Time compensation for nosleep-time is done by an ftrace probe on
sched_switch. This doesn't work well for the following events (with
letters representing timestamps):
A - sched switch probe called for task T switch out
B - __switch_to calltime is recorded
C - sched_switch probe called for task T switch in
D - __switch_to rettime is recorded
If C - A > D - B, then we end up over compensating for the time spent in
__switch_to giving rise to negative times in the trace output.
On x86, __switch_to is not traced if function graph tracer is enabled.
Do the same for arm64 as well.
Cc: Todd Kjos <tkjos@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
arch/arm64/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 01753cd..e84ee27 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -324,7 +324,7 @@ void uao_thread_switch(struct task_struct *next)
/*
* Thread switching.
*/
-struct task_struct *__switch_to(struct task_struct *prev,
+__notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *next)
{
struct task_struct *last;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Maxime Ripard @ 2016-12-21 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-3-icenowy@aosc.xyz>
On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote:
> Lichee Pi One is a low-cost Allwinner A13-based development board, with
> an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
> RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
> headers and two MicroSD card slots (connected to mmc0 and mmc2, both
> bootable).
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/1e2e9f64/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
On Thu, Dec 22, 2016 at 04:02:33AM +0800, Icenowy Zheng wrote:
> Lichee Pi is a new "Pi"-named development board series.
>
> Currently available device, Lichee Pi One, is by only one person as
> night job, so the device series name is chosen to be the vendor prefix.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/ec2af551/attachment.sig>
^ 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