* [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
* [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
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