* [PATCH 0/5] Support for Marvell switches with integrated CPUs
From: Chris Packham @ 2016-12-22 4:13 UTC (permalink / raw)
To: linux-arm-kernel
The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
integrated CPUs. They CPU block is common within these product lines and
(as far as I can tell/have been told) is based on the Armada XP. There
are a few differences due to the fact they have to squeeze the CPU into
the same package as the switch.
Chris Packham (4):
clk: mvebu: support for 98DX3236 SoC
arm: mvebu: support for SMP on 98DX3336 SoC
arm: mvebu: Add device tree for 98DX3236 SoCs
arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
Kalyan Kinthada (1):
pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
.../bindings/arm/marvell/98dx3236-resume-ctrl.txt | 18 ++
.../devicetree/bindings/arm/marvell/98dx3236.txt | 10 +
.../pinctrl/marvell,armada-98dx3236-pinctrl.txt | 46 ++++
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 231 +++++++++++++++++++++
arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 78 +++++++
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 78 +++++++
arch/arm/boot/dts/db-dxbc2.dts | 159 ++++++++++++++
arch/arm/boot/dts/db-xc3-24g4xg.dts | 155 ++++++++++++++
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/common.h | 1 +
arch/arm/mach-mvebu/platsmp.c | 43 ++++
arch/arm/mach-mvebu/pmsu-98dx3236.c | 69 ++++++
drivers/clk/mvebu/Makefile | 2 +-
drivers/clk/mvebu/armada-xp.c | 42 ++++
drivers/clk/mvebu/clk-cpu.c | 33 ++-
drivers/clk/mvebu/mv98dx3236-corediv.c | 207 ++++++++++++++++++
drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 145 +++++++++++++
17 files changed, 1314 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
create mode 100644 arch/arm/boot/dts/db-dxbc2.dts
create mode 100644 arch/arm/boot/dts/db-xc3-24g4xg.dts
create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
--
2.11.0.24.ge6920cf
^ permalink raw reply
* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Suman Anna @ 2016-12-22 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481846632-4778-1-git-send-email-spjoshi@codeaurora.org>
Hi Sarang,
On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
> The function wkup_m3_rproc_boot_thread waits for asynchronous
> firmware loading to complete successfully before calling
> rproc_boot(). The same can be achieved by just setting
> rproc->auto_boot flag. Change this. As a result this change
> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
> initialization to the wkup_m3_ipc_probe().
>
> Other than the current usage, the firmware_loading_complete is
> only used in rproc_del() where it's no longer needed. This
> change is in preparation for removing firmware_loading_complete
> completely.
Based on the comments so far, I am assuming that you are dropping this
series.
In any case, this series did break our PM stack. We definitely don't
want to auto-boot the wkup_m3_rproc device, that responsibility will
need to stay with the wkup_m3_ipc driver.
regards
Suman
>
> CC: Dave Gerlach <d-gerlach@ti.com>
> CC: Suman Anna <s-anna@ti.com>
> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
>
> Hi Suman,
>
> Unfortunately, I don't have a TI device and couldn't test this
> change. Is it possible for you to test this change on TI device?
>
> Thanks in advance.
>
> Regards,
> Sarang
>
> drivers/remoteproc/wkup_m3_rproc.c | 2 +-
> drivers/soc/ti/wkup_m3_ipc.c | 35 ++---------------------------------
> 2 files changed, 3 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
> index 18175d0..79ea022 100644
> --- a/drivers/remoteproc/wkup_m3_rproc.c
> +++ b/drivers/remoteproc/wkup_m3_rproc.c
> @@ -167,7 +167,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
> goto err;
> }
>
> - rproc->auto_boot = false;
> + rproc->auto_boot = true;
>
> wkupm3 = rproc->priv;
> wkupm3->rproc = rproc;
> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
> index 8823cc8..31090d70 100644
> --- a/drivers/soc/ti/wkup_m3_ipc.c
> +++ b/drivers/soc/ti/wkup_m3_ipc.c
> @@ -17,7 +17,6 @@
>
> #include <linux/err.h>
> #include <linux/kernel.h>
> -#include <linux/kthread.h>
> #include <linux/interrupt.h>
> #include <linux/irq.h>
> #include <linux/module.h>
> @@ -365,22 +364,6 @@ void wkup_m3_ipc_put(struct wkup_m3_ipc *m3_ipc)
> }
> EXPORT_SYMBOL_GPL(wkup_m3_ipc_put);
>
> -static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
> -{
> - struct device *dev = m3_ipc->dev;
> - int ret;
> -
> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
> -
> - init_completion(&m3_ipc->sync_complete);
> -
> - ret = rproc_boot(m3_ipc->rproc);
> - if (ret)
> - dev_err(dev, "rproc_boot failed\n");
> -
> - do_exit(0);
> -}
> -
> static int wkup_m3_ipc_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -388,7 +371,6 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
> phandle rproc_phandle;
> struct rproc *m3_rproc;
> struct resource *res;
> - struct task_struct *task;
> struct wkup_m3_ipc *m3_ipc;
>
> m3_ipc = devm_kzalloc(dev, sizeof(*m3_ipc), GFP_KERNEL);
> @@ -402,6 +384,8 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
> return PTR_ERR(m3_ipc->ipc_mem_base);
> }
>
> + init_completion(&m3_ipc->sync_complete);
> +
> irq = platform_get_irq(pdev, 0);
> if (!irq) {
> dev_err(&pdev->dev, "no irq resource\n");
> @@ -449,25 +433,10 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>
> m3_ipc->ops = &ipc_ops;
>
> - /*
> - * Wait for firmware loading completion in a thread so we
> - * can boot the wkup_m3 as soon as it's ready without holding
> - * up kernel boot
> - */
> - task = kthread_run((void *)wkup_m3_rproc_boot_thread, m3_ipc,
> - "wkup_m3_rproc_loader");
> -
> - if (IS_ERR(task)) {
> - dev_err(dev, "can't create rproc_boot thread\n");
> - goto err_put_rproc;
> - }
> -
> m3_ipc_state = m3_ipc;
>
> return 0;
>
> -err_put_rproc:
> - rproc_put(m3_rproc);
> err_free_mbox:
> mbox_free_channel(m3_ipc->mbox);
> return ret;
>
^ permalink raw reply
* [PATCH v3 3/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-12-22 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209233628.6642-4-f.fainelli@gmail.com>
On 12/09/2016 03:36 PM, Florian Fainelli wrote:
> x86 has an option: CONFIG_DEBUG_VIRTUAL to do additional checks on
> virt_to_phys calls. The goal is to catch users who are calling
> virt_to_phys on non-linear addresses immediately. This includes caller
> using __virt_to_phys() on image addresses instead of __pa_symbol(). This
> is a generally useful debug feature to spot bad code (particulary in
> drivers).
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/memory.h | 16 ++++++++++++--
> arch/arm/mm/Makefile | 1 +
> arch/arm/mm/physaddr.c | 51 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 67 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/mm/physaddr.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5d529fdffab..5e66173c5787 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2,6 +2,7 @@ config ARM
> bool
> default y
> select ARCH_CLOCKSOURCE_DATA
> + select ARCH_HAS_DEBUG_VIRTUAL
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index bee7511c5098..d90300193adf 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -213,7 +213,7 @@ extern const void *__pv_table_begin, *__pv_table_end;
> : "r" (x), "I" (__PV_BITS_31_24) \
> : "cc")
>
> -static inline phys_addr_t __virt_to_phys(unsigned long x)
> +static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
> {
> phys_addr_t t;
>
> @@ -245,7 +245,7 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
> #define PHYS_OFFSET PLAT_PHYS_OFFSET
> #define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
>
> -static inline phys_addr_t __virt_to_phys(unsigned long x)
> +static inline phys_addr_t __virt_to_phys_nodebug(unsigned long x)
> {
> return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
> }
> @@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
> ((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
> PHYS_PFN_OFFSET)
>
> +#define __pa_symbol_nodebug(x) __virt_to_phys_nodebug((x))
> +
> +#ifdef CONFIG_DEBUG_VIRTUAL
> +extern phys_addr_t __virt_to_phys(unsigned long x);
> +extern phys_addr_t __phys_addr_symbol(unsigned long x);
> +#else
> +#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
> +#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
> +#endif
> +
> /*
> * These are *only* valid on the kernel direct mapped RAM memory.
> * Note: Drivers should NOT use these. They are the wrong
> @@ -283,9 +293,11 @@ static inline void *phys_to_virt(phys_addr_t x)
> * Drivers should NOT use these either.
> */
> #define __pa(x) __virt_to_phys((unsigned long)(x))
> +#define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
> #define pfn_to_kaddr(pfn) __va((phys_addr_t)(pfn) << PAGE_SHIFT)
>
> +
> extern long long arch_phys_to_idmap_offset;
>
> /*
> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
> index e8698241ece9..b3dea80715b4 100644
> --- a/arch/arm/mm/Makefile
> +++ b/arch/arm/mm/Makefile
> @@ -14,6 +14,7 @@ endif
>
> obj-$(CONFIG_ARM_PTDUMP) += dump.o
> obj-$(CONFIG_MODULES) += proc-syms.o
> +obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
>
> obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
> obj-$(CONFIG_HIGHMEM) += highmem.o
> diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c
> new file mode 100644
> index 000000000000..0288760306ce
> --- /dev/null
> +++ b/arch/arm/mm/physaddr.c
> @@ -0,0 +1,51 @@
> +#include <linux/bug.h>
> +#include <linux/export.h>
> +#include <linux/types.h>
> +#include <linux/mmdebug.h>
> +#include <linux/mm.h>
> +
> +#include <asm/sections.h>
> +#include <asm/memory.h>
> +#include <asm/fixmap.h>
> +#include <asm/dma.h>
> +
> +#include "mm.h"
> +
> +static inline bool __virt_addr_valid(unsigned long x)
> +{
> + /* high_memory does not get immediately defined, and there
> + * are early callers of __pa() against PAGE_OFFSET, just catch
> + * these here, then do normal checks, with the exception of
> + * MAX_DMA_ADDRESS.
> + */
> + if ((x >= PAGE_OFFSET && !high_memory) ||
> + (x >= PAGE_OFFSET &&
> + high_memory && x < (unsigned long)high_memory) ||
> + x == MAX_DMA_ADDRESS)
> + return true;
This is difficult to read, it's easier to read if it's split out:
if (!high_memory && x >= PAGE_OFFSET)
return true;
if (high_memory && x >= PAGE_OFFSET && x < (unsigned long) high_memory)
return true;
if (x == MAX_DMA_ADDRESS)
return true;
I'm really not a fan of the check for MAX_DMA_ADDRESS. arm64 gets away
with this because it uses the asm-generic version of dma.h which sets
MAX_DMA_ADDRESS to PAGE_OFFSET. __pa(MAX_DMA_ADDRESS) is used a
bunch of places in the kernel as a lower limit for memblock
allocation. The implication seems to be that MAX_DMA_ADDRESS
corresponds to something that corresponds to a real physical address.
The existing code happens to work because it will simply retry the
allocation if without the lower bound.
I don't see a good way to fix this though. It doesn't look like
MAX_DMA_ADDRESS can be changed if it's actually going to be used
for DMA and there isn't a unified way to just get a physical address.
Thanks,
Laura
> +
> + return false;
> +}
> +
> +phys_addr_t __virt_to_phys(unsigned long x)
> +{
> + WARN(!__virt_addr_valid(x),
> + "virt_to_phys used for non-linear address: %pK (%pS)\n",
> + (void *)x,
> + (void *)x);
> +
> + return __virt_to_phys_nodebug(x);
> +}
> +EXPORT_SYMBOL(__virt_to_phys);
> +
> +phys_addr_t __phys_addr_symbol(unsigned long x)
> +{
> + /* This is bounds checking against the kernel image only.
> + * __pa_symbol should only be used on kernel symbol addresses.
> + */
> + VIRTUAL_BUG_ON(x < (unsigned long)KERNEL_START ||
> + x > (unsigned long)KERNEL_END);
> +
> + return __pa_symbol_nodebug(x);
> +}
> +EXPORT_SYMBOL(__phys_addr_symbol);
>
^ permalink raw reply
* [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: zhangfei @ 2016-12-22 2:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221232551.GB8288@codeaurora.org>
Hi, Stephen
Thanks for the suggestion.
On 2016?12?22? 07:25, Stephen Boyd wrote:
> On 12/15, Zhangfei Gao wrote:
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Add some commit text here?
OK
>
>> 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.
Yes, this is simpler.
>
>> +
>> + 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?
Do you mean put in different .c / drivers?
They have to be put in the same file, since the parent / child relate to
each other.
They are for the same chip, but some put in different region for
privilege control.
>
>> + 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.
ok, got it.
Thanks
^ permalink raw reply
* [PATCH 02/11] clk: bcm2835: Register the DSI0/DSI1 pixel clocks.
From: Eric Anholt @ 2016-12-22 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221231446.GA8288@codeaurora.org>
Stephen Boyd <sboyd@codeaurora.org> writes:
> 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.
It looks like that will work fine. We'll only be missing parents from
the end of the array.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/0343dbad/attachment.sig>
^ permalink raw reply
* [RFC PATCH] Memory hotplug support for arm64 platform
From: Scott Branden @ 2016-12-22 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7977063a-20bb-cc85-449f-51bb7d20761e@virtualopensystems.com>
Hi Maciej,
On 16-12-21 01:44 AM, Maciej Bielski wrote:
> Hi Scott,
>
> Thanks for testing it and providing us the feedback. For replicating the problem you have reported,
> could you provide more info on your system configuration, please?
> Among others, few questions that we have in mind are:
> * What is the RAM size at boot? Is it multiple of 1GB (or precisely `1<<MIN_MEMORY_BLOCK_SIZE`) ?
RAM size at boot is 64MB, not a multiple of 1GB. I will try next week
on a system with multi-GB@boot to see if it makes a difference.
SECTION_SIZE_BITS in sparsemem.h has been modified to 28 to allow for
256MB hotplug regions to be added.
> * Do you run the kernel with `mem=YYY` option?
no, memory is defined in dts file with a few reserved regions:
/memreserve/ 0x75000000 0x00800000;
/memreserve/ 0x77f00000 0x00100000;
&memory {
reg = <0x00000000 0x74000000 0x0 0x04000000>; /* 64MB */
};
> * Do you follow steps (1) and (2) for performing the hotplug?
no, only step 1 is done, auto-online is enabled. I'll try turning that
off and see if it makes a difference.
> * Do you have any other configuration flags enabled except for CONFIG_MEMORY_HOTPLUG?
> * Any other non-defaults?
Yes, a lot of config options have been disabled to reduce kernel size.
The memory auto-online is also enabled. I'll try with the default
defconfig to see if it makes a difference.
>
> Up to now the patch was passing our simple tests but if we miss something we will be very thankful
> if you could help us to sort it out. If you have found something after your deeper analysis, please
> keep us informed.
I think the path forward is to get a normal multi-GB system going and
then reduce the memory on boot and then hotplug it in after to see if
that works. Or, if you can reduce your memory down and give it a try
that might uncover a problem as well.
>
>
> On 20/12/2016 20:12, Scott Branden wrote:
>> Hi Maciej,
>>
>> I have applied that patch ontop of the patches I previously sent out
>> and tested.
>>
>> It does recognized the memory in /proc/iomem but I get memory corruption of the original system
>> RAM soon after. It appears the page allocation gets corrupted. I will try to dig into it further
>> but if somebody else could try it out in their system to see what results they get it would help.
>>
>> Regards,
>> Scott
>>
>> On 16-12-14 04:16 AM, Maciej Bielski wrote:
>>> This patch relates to the work previously announced in [1]. This builds on the
>>> work by Scott Branden [2] and, henceforth, it needs to be applied on top of
>>> Scott's patches [2]. Comments are very welcome.
>>>
>>> Changes from the original patchset and known issues:
>>>
>>> - Compared to Scott's original patchset, this work adds the mapping of
>>> the new hotplugged pages into the kernel page tables. This is done by
>>> copying the old swapper_pg_dir over a new page, adding the new mappings,
>>> and then switching to the newly built pg_dir (see `hotplug_paging` in
>>> arch/arm64/mmu.c). There might be better ways to to this: suggestions
>>> are more than welcome.
>>>
>>> - The stub function for `arch_remove_memory` has been removed for now; we
>>> are working in parallel on memory hot remove, and we plan to contribute
>>> it as a separate patch.
>>>
>>> - Corresponding Kconfig flags have been added;
>>>
>>> - Note that this patch does not work when NUMA is enabled; in fact,
>>> the function `memory_add_physaddr_to_nid` does not have an
>>> implementation when the NUMA flag is on: this function is supposed to
>>> return the nid the hotplugged memory should be associated with. However
>>> it is not really clear to us yet what the semantics of this function
>>> in the context of a NUMA system should be. A quick and dirty fix would
>>> be to always attach to the first available NUMA node.
>>>
>>> - In arch/arm64/mm/init.c `arch_add_memory`, we are doing a hack with the
>>> nomap memory block flags to satisfy preconditions and postconditions of
>>> `__add_pages` and postconditions of `arch_add_memory`. Compared to
>>> memory hotplug implementation for other architectures, the "issue"
>>> seems to be in the implemenation of `pfn_valid`. Suggestions on how
>>> to cleanly avoid this hack are welcome.
>>>
>>> This patchset can be tested by starting the kernel with the `mem=X` flag, where
>>> X is less than the total available physical memory and has to be multiple of
>>> MIN_MEMORY_BLOCK_SIZE. We also tested it on a customised version of QEMU
>>> capable to emulate physical hotplug on arm64 platform.
>>>
>>> To enable the feature the CONFIG_MEMORY_HOTPLUG compilation flag
>>> needs to be set to true. Then, after memory is physically hotplugged,
>>> the standard two steps to make it available (as also documented in
>>> Documentation/memory-hotplug.txt) are:
>>>
>>> (1) Notify memory hot-add
>>> echo '0xYY000000' > /sys/devices/system/memory/probe
>>>
>>> where 0xYY000000 is the first physical address of the new memory section.
>>>
>>> (2) Online new memory block(s)
>>> echo online > /sys/devices/system/memory/memoryXXX/state
>>>
>>> where XXX corresponds to the ids of newly added blocks.
>>>
>>> Onlining can optionally be automatic at hot-add notification by enabling
>>> the global flag:
>>> echo online > /sys/devices/system/memory/auto_online_blocks
>>> or by setting the corresponding config flag in the kernel build.
>>>
>>> Again, any comment is highly appreciated.
>>>
>>> [1] https://lkml.org/lkml/2016/11/17/49
>>> [2] https://lkml.org/lkml/2016/12/1/811
>>>
>>> Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
>>> Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
>>> ---
>>> arch/arm64/Kconfig | 4 +--
>>> arch/arm64/include/asm/mmu.h | 3 +++
>>> arch/arm64/mm/init.c | 58 +++++++++++++++++++++++++++++++-------------
>>> arch/arm64/mm/mmu.c | 24 ++++++++++++++++++
>>> include/linux/memblock.h | 1 +
>>> mm/memblock.c | 10 ++++++++
>>> 6 files changed, 80 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 2482fdd..bd8ddf2 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -577,9 +577,7 @@ config HOTPLUG_CPU
>>> can be controlled through /sys/devices/system/cpu.
>>>
>>> config ARCH_ENABLE_MEMORY_HOTPLUG
>>> - def_bool y
>>> -
>>> -config ARCH_ENABLE_MEMORY_HOTREMOVE
>>> + depends on !NUMA
>>> def_bool y
>>>
>>> # Common NUMA Features
>>> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
>>> index 8d9fce0..2499745 100644
>>> --- a/arch/arm64/include/asm/mmu.h
>>> +++ b/arch/arm64/include/asm/mmu.h
>>> @@ -36,5 +36,8 @@ extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
>>> unsigned long virt, phys_addr_t size,
>>> pgprot_t prot, bool allow_block_mappings);
>>> extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
>>> +#ifdef CONFIG_MEMORY_HOTPLUG
>>> +extern void hotplug_paging(phys_addr_t start, phys_addr_t size);
>>> +#endif
>>>
>>> #endif
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 687d087..a7c740e 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -544,37 +544,61 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>>> struct zone *zone;
>>> unsigned long start_pfn = start >> PAGE_SHIFT;
>>> unsigned long nr_pages = size >> PAGE_SHIFT;
>>> + unsigned long end_pfn = start_pfn + nr_pages;
>>> + unsigned long max_sparsemem_pfn = 1UL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
>>> + unsigned long pfn;
>>> int ret;
>>>
>>> + if (end_pfn > max_sparsemem_pfn) {
>>> + pr_err("end_pfn too big");
>>> + return -1;
>>> + }
>>> + hotplug_paging(start, size);
>>> +
>>> + /*
>>> + * Mark all the page range as unsuable.
>>> + * This is needed because __add_section (within __add_pages)
>>> + * wants pfn_valid to be false, and in arm64 pfn falid is implemented
>>> + * by just checking at the nomap flag for existing blocks
>>> + */
>>> + memblock_mark_nomap(start, size);
>>> +
>>> pgdat = NODE_DATA(nid);
>>>
>>> zone = pgdat->node_zones +
>>> zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
>>> ret = __add_pages(nid, zone, start_pfn, nr_pages);
>>>
>>> - if (ret)
>>> - pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
>>> - __func__, ret);
>>> + /*
>>> + * Make the pages usable after they have been added.
>>> + * This will make pfn_valid return true
>>> + */
>>> + memblock_clear_nomap(start, size);
>>>
>>> - return ret;
>>> -}
>>> + /*
>>> + * This is a hack to avoid having to mix arch specific code into arch
>>> + * independent code. SetPageReserved is supposed to be called by __add_zone
>>> + * (within __add_section, within __add_pages). However, when it is called
>>> + * there, it assumes that pfn_valid returns true. For the way pfn_valid is
>>> + * implemented in arm64 (a check on the nomap flag), the only way to make
>>> + * this evaluate true inside __add_zone is to clear the nomap flags of
>>> + * blocks in architecture independent code.
>>> + *
>>> + * To avoid this, we set the Reserved flag here after we cleared the nomap
>>> + * flag in the line above.
>>> + */
>>> + for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) {
>>> + if (!pfn_valid(pfn))
>>> + continue;
>>>
>>> -#ifdef CONFIG_MEMORY_HOTREMOVE
>>> -int arch_remove_memory(u64 start, u64 size)
>>> -{
>>> - unsigned long start_pfn = start >> PAGE_SHIFT;
>>> - unsigned long nr_pages = size >> PAGE_SHIFT;
>>> - struct zone *zone;
>>> - int ret;
>>> + SetPageReserved(pfn_to_page(pfn));
>>> + }
>>>
>>> - zone = page_zone(pfn_to_page(start_pfn));
>>> - ret = __remove_pages(zone, start_pfn, nr_pages);
>>> if (ret)
>>> - pr_warn("%s: Problem encountered in __remove_pages() ret=%d\n",
>>> + pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
>>> __func__, ret);
>>>
>>> return ret;
>>> }
>>> #endif
>>> -#endif
>>>
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>> index 05615a3..9efa7d1 100644
>>> --- a/arch/arm64/mm/mmu.c
>>> +++ b/arch/arm64/mm/mmu.c
>>> @@ -493,6 +493,30 @@ void __init paging_init(void)
>>> SWAPPER_DIR_SIZE - PAGE_SIZE);
>>> }
>>>
>>> +#ifdef CONFIG_MEMORY_HOTPLUG
>>> +/*
>>> + * hotplug_paging() is used by memory hotplug to build new page tables
>>> + * for hot added memory.
>>> + */
>>> +void hotplug_paging(phys_addr_t start, phys_addr_t size)
>>> +{
>>> + phys_addr_t pgd_phys = pgd_pgtable_alloc();
>>> + pgd_t *pgd = pgd_set_fixmap(pgd_phys);
>>> +
>>> + memcpy(pgd, swapper_pg_dir, PAGE_SIZE);
>>> +
>>> + __create_pgd_mapping(pgd, start, __phys_to_virt(start), size,
>>> + PAGE_KERNEL, pgd_pgtable_alloc, false);
>>> +
>>> + cpu_replace_ttbr1(__va(pgd_phys));
>>> + memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
>>> + cpu_replace_ttbr1(swapper_pg_dir);
>>> +
>>> + pgd_clear_fixmap();
>>> + memblock_free(pgd_phys, PAGE_SIZE);
>>> +}
>>> +#endif
>>> +
>>> /*
>>> * Check whether a kernel address is valid (derived from arch/x86/).
>>> */
>>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>>> index 5b759c9..5f78257 100644
>>> --- a/include/linux/memblock.h
>>> +++ b/include/linux/memblock.h
>>> @@ -92,6 +92,7 @@ int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
>>> int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
>>> int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
>>> int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
>>> +int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
>>> ulong choose_memblock_flags(void);
>>>
>>> /* Low level functions */
>>> diff --git a/mm/memblock.c b/mm/memblock.c
>>> index 7608bc3..05e7676 100644
>>> --- a/mm/memblock.c
>>> +++ b/mm/memblock.c
>>> @@ -814,6 +814,16 @@ int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
>>> }
>>>
>>> /**
>>> + * memblock_clear_nomap - Clear a flag of MEMBLOCK_NOMAP memory region
>>> + * @base: the base phys addr of the region
>>> + * @size: the size of the region
>>> + */
>>> +int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
>>> +{
>>> + return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
>>> +}
>>> +
>>> +/**
>>> * __next_reserved_mem_region - next function for for_each_reserved_region()
>>> * @idx: pointer to u64 loop variable
>>> * @out_start: ptr to phys_addr_t for start address of the region, can be %NULL
>>>
>
> BR,
>
^ permalink raw reply
* [RESEND PATCH v2] arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399
From: Xing Zheng @ 2016-12-22 1:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WFFGSc7yBeaE+++VAuRKwMixpGUwA9bCCro4TCe0+GAA@mail.gmail.com>
Hi Doug,
? 2016?12?22? 08:47, Doug Anderson ??:
> 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
>
I will *ping* Frank and William to answer your questions until they
finish the business travel.
Thanks.
--
- Xing Zheng
^ permalink raw reply
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Vladimir Zapolskiy @ 2016-12-22 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CifMQGu2dFAm4a5BTUrqdJS77k-n3daBR6qCqtdX_W-Q@mail.gmail.com>
On 12/21/2016 10:28 PM, Fabio Estevam wrote:
> On Wed, Dec 21, 2016 at 6:24 PM, Vladimir Zapolskiy <vz@mleia.com> wrote:
>
>> Correct, I would recommend to postpone adding any extensions to the driver
>> platform data, which by the way is found in include/linux/mfd/mc13xxx.h
>>
>> The extension can be added only when it becomes needed.
>
> Yes, I agree.
>
So, for reference here is a snippet from the i.MX31 Lite board DTS:
&spi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cspi2>;
/*
* Note that intentionally there is no GPIO CS, i.MX31 CSPI
* controller does not support GPIO CS and this must be specially
* accounted in the driver, which currently fails to register
* without a provided "cs-gpios" property.
*/
fsl,spi-num-chipselects = <1>;
status = "okay";
pmic: mc13783 at 0 {
compatible = "fsl,mc13783";
reg = <0>;
spi-cs-high;
spi-max-frequency = <1000000>;
interrupt-parent = <&gpio1>;
interrupts = <3 IRQ_TYPE_EDGE_RISING>;
fsl,mc13xxx-uses-rtc;
};
};
I'm running the current pre-rc1 v4.10. The MFD device is registered and
MC13783 primary interrupt connected to GPIO1_3 is fired as expected
independently if the fixup under discussion is applied or not:
root at mx31lite:~# dmesg | grep spi
[ 2.017217] mc13xxx spi32766.0: mc13783: rev: 3.3, fin: 0, fab: 0, icid: 2/0
[ 2.072029] spi_imx 50010000.cspi: probed
root at mx31lite:~# dmesg | grep rtc0
[ 2.682459] mc13xxx-rtc mc13783-rtc: rtc core: registered mc13783-rtc as rtc0
root at mx31lite:~# cat /proc/interrupts | grep mc13xxx-rtc
176: 0 spi32766.0 31 Edge mc13xxx-rtc
177: 0 spi32766.0 25 Edge mc13xxx-rtc
root at mx31lite:~# echo +5 > /sys/class/rtc/rtc0/wakealarm ; sleep 5
root at mx31lite:~# cat /proc/interrupts | grep mc13xxx-rtc
176: 0 spi32766.0 31 Edge mc13xxx-rtc
177: 1 spi32766.0 25 Edge mc13xxx-rtc
So the change at least does not break i.MX31 Lite board with DTS support,
however I'm not sure if the change is still valid for any board with DTS
if the type of the interrupt is specified as IRQ_TYPE_EDGE_FALLING.
>> FWIW I ran the v4.9-rc kernel with device trees on i.MX31 Lite board
>> with MC13783, and what I can confirm is that in my case the proposed
>> change is not needed at all. Thus I'm going to verify shortly that
>> the commit does not break the currently correct runtime behaviour on
>> my board.
>
> Nice to see imx31 with dt support :-)
>
Basic support is done, IOMUX driver is developed, practically everything
but multimedia and USB are tested and working well, SPI driver needs
some minor special attention mentioned above, hopefully I'll find time
to submit core imx31.dtsi changes this week.
--
With best wishes,
Vladimir
^ permalink raw reply
* 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
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