* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: Arnd Bergmann @ 2016-11-08 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582180F7.5060100@gmail.com>
On Tuesday, November 8, 2016 1:08:31 PM CET Anurup M wrote:
> On Tuesday 08 November 2016 12:32 PM, Tan Xiaojun wrote:
> > On 2016/11/7 21:26, Arnd Bergmann wrote:
> >> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
> >>> From: Tan Xiaojun <tanxiaojun@huawei.com>
> >>> + /* ensure the djtag operation is done */
> >>> + do {
> >>> + djtag_read32_relaxed(regs_base, SC_DJTAG_MSTR_START_EN_EX, &rd);
> >>> +
> >>> + if (!(rd & DJTAG_MSTR_START_EN_EX))
> >>> + break;
> >>> +
> >>> + udelay(1);
> >>> + } while (timeout--);
> >> This one is obviously not performance critical at all, so use a non-relaxed
> >> accessor. Same for the other two in this function.
> >>
> >> Are these functions ever called from atomic context? If yes, please document
> >> from what context they can be called, otherwise please consider changing
> >> the udelay calls into sleeping waits.
> >>
> > Yes, this is not reentrant.
> The read/write functions shall also be called from irq handler (for
> handling counter overflow).
> So need to use udelay calls. Shall Document it in v2.
Ok.
> >>> +static const struct of_device_id djtag_of_match[] = {
> >>> + /* for hip05(D02) cpu die */
> >>> + { .compatible = "hisilicon,hip05-cpu-djtag-v1",
> >>> + .data = (void *)djtag_readwrite_v1 },
> >>> + /* for hip05(D02) io die */
> >>> + { .compatible = "hisilicon,hip05-io-djtag-v1",
> >>> + .data = (void *)djtag_readwrite_v1 },
> >>> + /* for hip06(D03) cpu die */
> >>> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
> >>> + .data = (void *)djtag_readwrite_v1 },
> >>> + /* for hip06(D03) io die */
> >>> + { .compatible = "hisilicon,hip06-io-djtag-v2",
> >>> + .data = (void *)djtag_readwrite_v2 },
> >>> + /* for hip07(D05) cpu die */
> >>> + { .compatible = "hisilicon,hip07-cpu-djtag-v2",
> >>> + .data = (void *)djtag_readwrite_v2 },
> >>> + /* for hip07(D05) io die */
> >>> + { .compatible = "hisilicon,hip07-io-djtag-v2",
> >>> + .data = (void *)djtag_readwrite_v2 },
> >>> + {},
> >>> +};
> >>
> >> If these are backwards compatible, just mark them as compatible in DT,
> >> e.g. hip06 can use
> >>
> >> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
> >>
> >> so you can tell the difference if you need to, but the driver only has to
> >> list the oldest one here.
> >>
> >> What is the difference between the cpu and io djtag interfaces?
> On some chips like hip06, the djtag version is different for IO die.
In what way? The driver doesn't seem to care about the difference.
Arnd
^ permalink raw reply
* [PATCH] iommu/dma-iommu: properly respect configured address space size
From: Robin Murphy @ 2016-11-08 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523973-8828-1-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
On 07/11/16 13:06, Marek Szyprowski wrote:
> When one called iommu_dma_init_domain() with size smaller than device's
> DMA mask, the alloc_iova() will not respect it and always assume that all
> IOVA addresses will be allocated from the the (base ... dev->dma_mask) range.
Is that actually a problem for anything?
> This patch fixes this issue by taking the configured address space size
> parameter into account (if it is smaller than the device's dma_mask).
TBH I've been pondering ripping the size stuff out of dma-iommu, as it
all stems from me originally failing to understand what dma_32bit_pfn is
actually for. The truth is that iova_domains just don't have a size or
upper limit; however if devices with both large and small DMA masks
share a domain, then the top-down nature of the allocator means that
allocating for the less-capable devices would involve walking through
every out-of-range entry in the tree every time. Having cached32_node
based on dma_32bit_pfn just provides an optimised starting point for
searching within the smaller mask.
Would it hurt any of your use-cases to relax/rework the reinitialisation
checks in iommu_dma_init_domain()? Alternatively if we really do have a
case for wanting a hard upper limit, it might make more sense to add an
end_pfn to the iova_domain and handle it in the allocator itself.
Robin.
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/iommu/dma-iommu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..8b4b72654359 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -212,11 +212,13 @@ static struct iova *__alloc_iova(struct iommu_domain *domain, size_t size,
>
> if (domain->geometry.force_aperture)
> dma_limit = min(dma_limit, domain->geometry.aperture_end);
> +
> + dma_limit = min(dma_limit >> shift, (dma_addr_t)iovad->dma_32bit_pfn);
> /*
> * Enforce size-alignment to be safe - there could perhaps be an
> * attribute to control this per-device, or at least per-domain...
> */
> - return alloc_iova(iovad, length, dma_limit >> shift, true);
> + return alloc_iova(iovad, length, dma_limit, true);
> }
>
> /* The IOVA allocator knows what we mapped, so just unmap whatever that was */
>
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: John Garry @ 2016-11-08 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2467231.EbVekJun1R@wuerfel>
On 07/11/2016 20:08, Arnd Bergmann wrote:
> On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote:
>>
>> Hi Arnd,
>>
>> The new bus type tries to model the djtag in a similar way to I2C/USB
>> driver arch, where we have a host bus adapter and child devices attached
>> to the bus. The child devices are bus driver devices and have bus
>> addresses. We think of the djtag as a separate bus, so we are modelling
>> it as such.
>>
>> The bus driver offers a simple host interface for clients to read/write
>> to the djtag bus: bus accesses are hidden from the client, the host
>> drives the bus.
>
> Ok, in that case we should probably start out by having a bus specific
> DT binding, and separating the description from that of the bus master
> device.
OK
>
> I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the master
> node, and listing the children by reg property. If the address is not
> easily expressed as a single integer, use a larger #address-cells value.
We already have something equivalent to reg in "module-id" (see patch
02/11), which is the slave device bus address; here's a sample:
+ /* For L3 cache PMU */
+ pmul3c0 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ scl-id = <0x02>;
+ num-events = <0x16>;
+ num-counters = <0x08>;
+ module-id = <0x04>;
+ num-banks = <0x04>;
+ cfgen-map = <0x02 0x04 0x01 0x08>;
+ counter-reg = <0x170>;
+ evctrl-reg = <0x04>;
+ event-en = <0x1000000>;
+ evtype-reg = <0x140>;
+ };
FYI, "module-id" is our own internal hw nomenclature.
>
> Another option that we have previously used was to actually pretend that
> a vendor specific bus is an i2c bus and use the i2c probing infrastructure,
> but that only makes sense if the software side closely resembles i2c
> (this was the case for Allwinner I think, but I have not looked at
> your driver in enough detail to know if it is true here as well).
>
OK, let me check this. By chance do you remember the specific AllWinner
driver/hw?
Cheers,
John
> Arnd
>
> .
>
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC updates for 4.10
From: Neil Armstrong @ 2016-11-08 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107212648.GC2106@localhost>
On 11/07/2016 10:26 PM, Olof Johansson wrote:
> On Mon, Oct 31, 2016 at 10:52:53AM +0100, Neil Armstrong wrote:
>> Dear arm-soc maintainers,
>>
>> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>>
>> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>>
>> are available in the git repository at:
>>
>> https://github.com/OXNAS/linux.git tags/oxnas-arm-soc-for-4.10
>>
>> for you to fetch changes up to b3cdb3c5ef514687891f03442f2677850340bcfa:
>>
>> ARM: oxnas: Add OX820 config and makefile entry (2016-10-31 10:41:33 +0100)
>>
>> ----------------------------------------------------------------
>> - Add SMP support for the Oxford Semiconductor OX820 SoC
>> from http://lkml.kernel.org/r/20161021085848.1754-1-narmstrong at baylibre.com
>>
>> ----------------------------------------------------------------
>> Neil Armstrong (2):
>> ARM: oxnas: Add OX820 SMP support
>> ARM: oxnas: Add OX820 config and makefile entry
>
> Hi Neil,
Hi Olof,
>
> Sorry for being picky here, please be patient with us. :-)
Seems legit !
>
> Overall comments on this patch set:
>
> 1) Copyrights seem to be a bit varied. All 3 new source files have
> different copyright holders. Only one has yours, one is from 2003, one
> is also from 2013. Is this expected? Seems like it's worth mentioning
> in commit messages at least.
Yes, the files comes from various places :
- hotplug.c was taken from versatile by Ma Haijun and left verbatim, so I left the original header
- headsmp.S was taken from the versatile code and adapted by Ma Haijun
- platsmp.c is a mix from versatile code, Ma Haijun code and my code for DT
The two first file were only modified in order to build and pass checkpatch actually.
I tried to find the *real* copyright holders, but it was not easy...
>
> 2) Please remove the linux/arch/... lines from the top of the files. It's
> something we've been trying to remove for a while and don't want to
> introduce more occurrances of.
>
> I'd say (2) is fine to do incremental, but please provide clarification on (1).
> I could just add that to the merge commit message so don't respin the branch
> yet, depending on what we hear back!
>
Ok, please tell me if/when I need to send a new pull for the (2) fix.
>> arch/arm/Makefile | 1 +
>> arch/arm/mach-oxnas/Kconfig | 30 +++++++++++++++++++---------
>> arch/arm/mach-oxnas/Makefile | 2 ++
>> arch/arm/mach-oxnas/headsmp.S | 28 ++++++++++++++++++++++++++
>> arch/arm/mach-oxnas/hotplug.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> arch/arm/mach-oxnas/platsmp.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Git tip: If you redirect the output to a file (or pipe through cat), the
> diffstat will be limited to 80 characters and look better in email.
>
>
> Thanks,
>
> -Olof
>
Thanks,
Neil
^ permalink raw reply
* [RESPIN-PATCH v2 2/2] ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
From: Pankaj Dubey @ 2016-11-08 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478603984-504-1-git-send-email-pankaj.dubey@samsung.com>
As no more user of soc_is_exynos{4,5} we can safely remove them.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm/mach-exynos/common.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index dd5d8e8..fb12d11 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -105,11 +105,6 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK)
# define soc_is_exynos5800() 0
#endif
-#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
- soc_is_exynos4412())
-#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410() || \
- soc_is_exynos5420() || soc_is_exynos5800())
-
extern u32 cp15_save_diag;
extern u32 cp15_save_power;
--
2.7.4
^ permalink raw reply related
* [RESPIN-PATCH v2 1/2] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Pankaj Dubey @ 2016-11-08 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478603984-504-1-git-send-email-pankaj.dubey@samsung.com>
Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC based boards.
Instead use mapping from device tree node of SCU.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm/mach-exynos/common.h | 1 +
arch/arm/mach-exynos/exynos.c | 22 ------------------
arch/arm/mach-exynos/include/mach/map.h | 2 --
arch/arm/mach-exynos/platsmp.c | 34 +++++++++++++++++++++-------
arch/arm/mach-exynos/pm.c | 5 ++--
arch/arm/mach-exynos/suspend.c | 13 ++++-------
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
7 files changed, 34 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 9424a8a..dd5d8e8 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -161,6 +161,7 @@ extern void exynos_cpu_restore_register(void);
extern void exynos_pm_central_suspend(void);
extern int exynos_pm_central_resume(void);
extern void exynos_enter_aftr(void);
+extern int exynos_scu_enable(void);
extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 757fc11..fa08ef9 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -28,15 +28,6 @@
#include "common.h"
-static struct map_desc exynos4_iodesc[] __initdata = {
- {
- .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
- .pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
- .length = SZ_8K,
- .type = MT_DEVICE,
- },
-};
-
static struct platform_device exynos_cpuidle = {
.name = "exynos_cpuidle",
#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
return 1;
}
-/*
- * exynos_map_io
- *
- * register the standard cpu IO areas
- */
-static void __init exynos_map_io(void)
-{
- if (soc_is_exynos4())
- iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-}
-
static void __init exynos_init_io(void)
{
debug_ll_io_init();
@@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
-
- exynos_map_io();
}
/*
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 5fb0040..0eef407 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -18,6 +18,4 @@
#define EXYNOS_PA_CHIPID 0x10000000
-#define EXYNOS4_PA_COREPERI 0x10500000
-
#endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index a5d6841..94405c7 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -168,6 +168,27 @@ int exynos_cluster_power_state(int cluster)
S5P_CORE_LOCAL_PWR_EN);
}
+/**
+ * exynos_scu_enable : enables SCU for Cortex-A9 based system
+ * returns 0 on success else non-zero error code
+ */
+int exynos_scu_enable(void)
+{
+ struct device_node *np;
+ void __iomem *scu_base;
+
+ np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
+ scu_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!scu_base) {
+ pr_err("%s failed to map scu_base\n", __func__);
+ return -ENOMEM;
+ }
+ scu_enable(scu_base);
+ iounmap(scu_base);
+ return 0;
+}
+
static void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
@@ -224,11 +245,6 @@ static void write_pen_release(int val)
sync_cache_w(&pen_release);
}
-static void __iomem *scu_base_addr(void)
-{
- return (void __iomem *)(S5P_VA_SCU);
-}
-
static DEFINE_SPINLOCK(boot_lock);
static void exynos_secondary_init(unsigned int cpu)
@@ -393,9 +409,11 @@ static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
exynos_set_delayed_reset_assertion(true);
- if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
- scu_enable(scu_base_addr());
-
+ if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ /* if exynos_scu_enable fails, return */
+ if (exynos_scu_enable())
+ return;
+ }
/*
* Write the address of secondary startup into the
* system-wide flags register. The boot monitor waits
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 487295f..23db2af 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -18,6 +18,7 @@
#include <linux/cpu_pm.h>
#include <linux/io.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/soc/samsung/exynos-regs-pmu.h>
#include <linux/soc/samsung/exynos-pmu.h>
@@ -26,8 +27,6 @@
#include <asm/suspend.h>
#include <asm/cacheflush.h>
-#include <mach/map.h>
-
#include "common.h"
static inline void __iomem *exynos_boot_vector_addr(void)
@@ -177,7 +176,7 @@ void exynos_enter_aftr(void)
cpu_suspend(0, exynos_aftr_finisher);
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
- scu_enable(S5P_VA_SCU);
+ exynos_scu_enable();
if (call_firmware_op(resume) == -ENOSYS)
exynos_cpu_restore_register();
}
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 06332f6..c73c857 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -34,8 +34,6 @@
#include <asm/smp_scu.h>
#include <asm/suspend.h>
-#include <mach/map.h>
-
#include <plat/pm-common.h>
#include "common.h"
@@ -461,12 +459,11 @@ static void exynos_pm_resume(void)
/* For release retention */
exynos_pm_release_retention();
- if (cpuid == ARM_CPU_PART_CORTEX_A9)
- scu_enable(S5P_VA_SCU);
-
- if (call_firmware_op(resume) == -ENOSYS
- && cpuid == ARM_CPU_PART_CORTEX_A9)
- exynos_cpu_restore_register();
+ if (cpuid == ARM_CPU_PART_CORTEX_A9) {
+ exynos_scu_enable();
+ if (call_firmware_op(resume) == -ENOSYS)
+ exynos_cpu_restore_register();
+ }
early_wakeup:
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index 0fe2828..512ed1f 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -15,10 +15,6 @@
#define S5P_VA_CHIPID S3C_ADDR(0x02000000)
-#define S5P_VA_COREPERI_BASE S3C_ADDR(0x02800000)
-#define S5P_VA_COREPERI(x) (S5P_VA_COREPERI_BASE + (x))
-#define S5P_VA_SCU S5P_VA_COREPERI(0x0)
-
#define VA_VIC(x) (S3C_VA_IRQ + ((x) * 0x10000))
#define VA_VIC0 VA_VIC(0)
#define VA_VIC1 VA_VIC(1)
--
2.7.4
^ permalink raw reply related
* [RESPIN-PATCH v2 0/2] Remove static mapping of SCU from mach-exynos
From: Pankaj Dubey @ 2016-11-08 11:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is part of patch series [1], which adds support of SCU
device node for Cortex-A9 based Exynos4 SoC. First two patches of the same
has been accepted and hence not included them in v2.
This patch series does some cleanup for Exynos4 SoC based boards.
We are currently statically mapping SCU SFRs in mach-exynos/exynos.c
which can be avoided if map this from device node of SCU
[1]: https://www.spinics.net/lists/arm-kernel/msg540498.html
This patch series is prepared on Krzysztof's for-next
(SHA_ID: b33c7bb9d59c3f4100d4)
I have tested these patches on Exynos4210 based on Origen board for SMP boot.
Patchset v1 was tested by Marek Szyprowski on Exynos4412-based Odroid U3
for SMP boot and S2R.
To confirm concern raised by Alim, I intentionally removed SCU device node
from exynos4.dtsi and tested on Origen board, I can see code handles this
case gracefully without any crash and system boot was fine. Of-course in such
case only single core will be able to boot.
Following boot message observed on Origen in case of missing SCU node
-------------
[ 0.000864] CPU: Testing write buffer coherency: ok
[ 0.001068] CPU0: thread -1, cpu 0, socket 9, mpidr 80000900
[ 0.001456] exynos_scu_enable failed to map scu_base
[ 0.001477] Setting up static identity map for 0x40100000 - 0x40100058
[ 1.120003] CPU1: failed to come online
[ 1.120059] Brought up 1 CPUs
[ 1.120068] SMP: Total of 1 processors activated (48.00 BogoMIPS).
[ 1.120076] CPU: All CPU(s) started in SVC mode.
-------------
Changes since v1:
- Address review comments from Krzysztof
- Moved scu_enable from pm.c and suspend.c to single place in platsmp.c
- Added error handling during scu_enable in platsmp.c
- Added Reviewed-by tag from Alim.
Pankaj Dubey (2):
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
arch/arm/mach-exynos/common.h | 6 +----
arch/arm/mach-exynos/exynos.c | 22 ------------------
arch/arm/mach-exynos/include/mach/map.h | 2 --
arch/arm/mach-exynos/platsmp.c | 34 +++++++++++++++++++++-------
arch/arm/mach-exynos/pm.c | 5 ++--
arch/arm/mach-exynos/suspend.c | 13 ++++-------
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
7 files changed, 34 insertions(+), 52 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-08 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108110735.GA13098@ulmo.ba.sec>
On 08/11/16 11:07, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Nov 08, 2016 at 09:47:42AM +0000, Jon Hunter wrote:
>>
>> On 08/11/16 08:54, Peter De Schrijver wrote:
>>> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>>>>
>>>> On 07/11/16 13:28, Thierry Reding wrote:
>>>>>> Old Signed by an unknown key
>>>>>
>>>>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>>>>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>>>>>> no OTG-enabled connector.
>>>>>>
>>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>>>> ---
>>>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> Where is this information coming from? I don't have one of the Nyans
>>>>> myself, but one of the Tegra132 devices I have, which I think was
>>>>> derived from one of the Nyans uses one of the external host ports as
>>>>> forced recovery port, for which it would need OTG.
>>>>>
>>>>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
>>>>> In that case I think one of the ports must be OTG.
>>>>
>>>> It is true that the port on the back on the nyan-big can be used with
>>>> recovery mode. I was thinking that this is not a true OTG port as it is
>>>> just a 4-pin type A socket and does not have an ID pin. Thinking some
>>>> more about this the USB spec does include a "Host Negotiation Protocol
>>>> (HNP)" that allows a host and device to swap roles and so keeping it as
>>>> OTG seems valid afterall.
>>>
>>> I don't think the bootrom implements that though. I expect recovery mode
>>> to just program the controller in device mode, without performing any
>>> negotiation.
>>
>> I am not talking about the bootrom and I would not expect the bootrom to
>> do that. However, the kernel could.
>
> Either way, configuring the controller in device mode is enough to make
> the host detect it, otherwise tegrarcm wouldn't work.
>
> From the point of view of the binding I think "otg" is the most accurate
> option because we know that the controller can operate in both modes. If
> it currently doesn't or how exactly switching modes is done is outside
> the scope of this property.
>
> Is everyone okay with just dropping this patch?
Fine with me.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Thierry Reding @ 2016-11-08 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58046fbb-8e19-e629-770a-940a40ca6ef9@nvidia.com>
On Tue, Nov 08, 2016 at 09:47:42AM +0000, Jon Hunter wrote:
>
> On 08/11/16 08:54, Peter De Schrijver wrote:
> > On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
> >>
> >> On 07/11/16 13:28, Thierry Reding wrote:
> >>> * PGP Signed by an unknown key
> >>>
> >>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
> >>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
> >>>> no OTG-enabled connector.
> >>>>
> >>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >>>> ---
> >>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> Where is this information coming from? I don't have one of the Nyans
> >>> myself, but one of the Tegra132 devices I have, which I think was
> >>> derived from one of the Nyans uses one of the external host ports as
> >>> forced recovery port, for which it would need OTG.
> >>>
> >>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> >>> In that case I think one of the ports must be OTG.
> >>
> >> It is true that the port on the back on the nyan-big can be used with
> >> recovery mode. I was thinking that this is not a true OTG port as it is
> >> just a 4-pin type A socket and does not have an ID pin. Thinking some
> >> more about this the USB spec does include a "Host Negotiation Protocol
> >> (HNP)" that allows a host and device to swap roles and so keeping it as
> >> OTG seems valid afterall.
> >
> > I don't think the bootrom implements that though. I expect recovery mode
> > to just program the controller in device mode, without performing any
> > negotiation.
>
> I am not talking about the bootrom and I would not expect the bootrom to
> do that. However, the kernel could.
Either way, configuring the controller in device mode is enough to make
the host detect it, otherwise tegrarcm wouldn't work.
>From the point of view of the binding I think "otg" is the most accurate
option because we know that the controller can operate in both modes. If
it currently doesn't or how exactly switching modes is done is outside
the scope of this property.
Is everyone okay with just dropping this patch?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/a45c4288/attachment.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Jean-Francois Moine @ 2016-11-08 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107200505.g76zz7adtfy4ltku@lukather>
On Mon, 7 Nov 2016 21:05:05 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > >
> > > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > > > ---
> > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > - it handles the H3
> > >
> > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > the newer SoCs.
> >
> > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > regmap.
> > Many H3 registers are common with the A10, but some of them have more
> > or less fields, the fields may be at different offsets. And, finally,
> > some registers are completely different.
> > This would not raise any problem, except with regmap which is really
> > painful.
>
> That's weird, because regmap's regmap_field should make that much
> easier.
#define field_relaxed(addr, mask, val) \
writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
> > As I may understood, regmap is used to simplify suspend/resume, but, is
> > it useful to save the I2S register on suspend?
> > Practically, I am streaming some tune on my device. I suspend it for
> > any reason. The next morning, I resume it. Are you sure I want to
> > continue to hear the end of the tune?
> >
> > I better think that streaming should be simply stopped on suspend.
>
> You're mistaken. The code in there is for *runtime* suspend, ie when
> the device is no longer used, so that case shouldn't even happen at
> all.
>
> (And real suspend isn't supported anyway)
Is it time to remove this useless code?
> > Then, there is no need to save the playing registers, and, here I am,
> > there is no need to use regmap.
> >
> > May I go this way?
>
> No, please don't. regmap is also providing very useful features, such
> as access to all the registers through debugfs, or tracing. What
> exactly feels painful to you?
When the I/O registers are in memory (that's the case), you may access
them (read and write) thru /dev/mem.
Also, is a register access trace really needed in this driver?
The pain is to define the regmap_config (which registers can be
read/write/volatile and which can be the values the u-boot let us in
the registers at startup time), and the lot of code which is run instead
of simple load/store machine instructions.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 1/1] pinctrl: st: st_pctl_dt_parse_groups simplify expression
From: Linus Walleij @ 2016-11-08 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105143515.4668-1-xypron.glpk@gmx.de>
On Sat, Nov 5, 2016 at 3:35 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> for_each_property_of_node(pins, pp) checks that pp is not NULL.
> So there is no need to check it inside the loop.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Patch applied with Patrice's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: acpi: arch_apei_get_mem_attributes() should use memblock
From: James Morse @ 2016-11-08 10:27 UTC (permalink / raw)
To: linux-arm-kernel
arm64's arch_apei_get_mem_attributes() tries to use
efi_mem_attributes() to read the memory attributes from the efi
memory map.
drivers/firmware/efi/arm-init.c:efi_init() calls efi_memmap_unmap(),
which clears the EFI_MEMMAP bit from efi.flags once efi_init() has
finished with the memory map. This causes efi_mem_attributes() to
return 0 meaning PROT_DEVICE_nGnRnE is the chosen memory type for
all ACPI APEI mappings.
APEI may call this from NMI context, so we can't re-map the EFI
memory map as this may need to allocate virtual address space.
'ghes_ioremap_area' is APEIs cache of virtual address space to
access the buffer once we tell it the memory attributes.
Do as acpi_os_ioremap() does, and consult memblock to learn if
the provided address is memory, or not.
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Fixes: 89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()")
This doesn't code even get built on mainline as HAVE_ACPI_APEI isn't
defined, until https://lkml.org/lkml/2016/8/10/231 gets merged.
I don't think this should go to stable.
I also took the opportunity to remove some unnecessarily ifdef'd
includes.
arch/arm64/kernel/acpi.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 252a6d9c1da5..985f721f3bdd 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/cpumask.h>
+#include <linux/efi.h>
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/irqdomain.h>
@@ -28,13 +29,9 @@
#include <asm/cputype.h>
#include <asm/cpu_ops.h>
+#include <asm/pgtable.h>
#include <asm/smp_plat.h>
-#ifdef CONFIG_ACPI_APEI
-# include <linux/efi.h>
-# include <asm/pgtable.h>
-#endif
-
int acpi_noirq = 1; /* skip ACPI IRQ initialization */
int acpi_disabled = 1;
EXPORT_SYMBOL(acpi_disabled);
@@ -241,22 +238,13 @@ void __init acpi_boot_table_init(void)
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
{
/*
- * According to "Table 8 Map: EFI memory types to AArch64 memory
- * types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
- * mapped to a corresponding MAIR attribute encoding.
- * The EFI memory attribute advises all possible capabilities
- * of a memory region. We use the most efficient capability.
+ * The EFI memmap isn't mapped, instead read the version exported
+ * into memblock. EFI's reserve_regions() call adds memory with the
+ * WB attribute to memblock via early_init_dt_add_memory_arch().
*/
+ if (!memblock_is_memory(addr))
+ return __pgprot(PROT_DEVICE_nGnRnE);
- u64 attr;
-
- attr = efi_mem_attributes(addr);
- if (attr & EFI_MEMORY_WB)
- return PAGE_KERNEL;
- if (attr & EFI_MEMORY_WT)
- return __pgprot(PROT_NORMAL_WT);
- if (attr & EFI_MEMORY_WC)
- return __pgprot(PROT_NORMAL_NC);
- return __pgprot(PROT_DEVICE_nGnRnE);
+ return PAGE_KERNEL;
}
#endif
--
2.10.1
^ permalink raw reply related
* [PATCH 1/1] pinctrl: st: st_pinconf_dbg_show wrong format string
From: Linus Walleij @ 2016-11-08 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105142515.4377-1-xypron.glpk@gmx.de>
On Sat, Nov 5, 2016 at 3:25 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> function is defined as unsigned int.
> So we need %u to print it.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Patch applied with Patrice's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-08 10:06 UTC (permalink / raw)
To: linux-arm-kernel
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
Changes in v4:
- move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
Changes in v5:
- delete devfreq_opp_get_suspend_opp() in devfreq.h
drivers/devfreq/devfreq.c | 15 +++++++++++++--
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 2 ++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..af06891 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,7 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
+ if (devfreq->suspend_freq) {
+ update_devfreq(devfreq);
+ devfreq->suspend_flag = true;
+ }
devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(&devfreq->lock);
@@ -390,7 +393,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
devfreq->last_stat_updated = jiffies;
devfreq->stop_polling = false;
-
+ if (devfreq->suspend_freq)
+ devfreq->suspend_flag = false;
if (devfreq->profile->get_cur_freq &&
!devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
devfreq->previous_freq = freq;
@@ -524,6 +528,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
struct devfreq *devfreq;
struct devfreq_governor *governor;
int err = 0;
+ struct dev_pm_opp *suspend_opp;
if (!dev || !profile || !governor_name) {
dev_err(dev, "%s: Invalid parameters.\n", __func__);
@@ -558,6 +563,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
devfreq_set_freq_table(devfreq);
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..84b3ce1 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->suspend_flag) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..8567153 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
@@ -179,6 +180,7 @@ struct devfreq {
unsigned long min_freq;
unsigned long max_freq;
bool stop_polling;
+ bool suspend_flag;
/* information for device frequency transition */
unsigned int total_trans;
--
2.6.6
^ permalink raw reply related
* [PATCH] fpga zynq: Check the bitstream for validity
From: Matthias Brugger @ 2016-11-08 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108004642.GB32444@obsidianresearch.com>
On 11/08/2016 01:46 AM, Jason Gunthorpe wrote:
> On Fri, Oct 28, 2016 at 05:09:26PM -0700, Moritz Fischer wrote:
>
>> That being said, I don't like the idea of the driver having to search
>> either...
>
> I think we are stuck with that, considering what Xilinx tools
> produce..
>
> Here is a v2, what do you think?
>
> From 93ffde371ca50809ba9b4cdca17051a050b0f92d Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Date: Wed, 26 Oct 2016 16:51:26 -0600
> Subject: [PATCH v2] fpga zynq: Check the bitstream for validity
>
> There is no sense in sending a bitstream we know will not work, and
> with the variety of options for bitstream generation in Xilinx tools
> it is not terribly clear or very well documented what the correct
> input should be, especially since auto-detection was removed from this
> driver.
>
> All Zynq full configuration bitstreams must start with the sync word in
> the correct byte order.
>
> Zynq is also only able to DMA dword quantities, so bitstreams must be
> a multiple of 4 bytes. This also fixes a DMA-past the end bug.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/zynq-fpga.c | 35 ++++++++++++++++++++++++++---------
> 1 file changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> index c2fb4120bd62..de475a6a1882 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -175,6 +175,19 @@ static irqreturn_t zynq_fpga_isr(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +/* Sanity check the proposed bitstream. It must start with the sync word in
> + * the correct byte order. The input is a Xilinx .bin file with every 32 bit
> + * quantity swapped.
> + */
> +static bool zynq_fpga_has_sync(const char *buf, size_t count)
> +{
> + for (; count > 4; buf += 4, --count)
> + if (buf[0] == 0x66 && buf[1] == 0x55 && buf[2] == 0x99 &&
> + buf[3] == 0xaa)
> + return true;
> + return false;
> +}
> +
> static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> const char *buf, size_t count)
> {
> @@ -184,12 +197,23 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>
> priv = mgr->priv;
>
> + /* The hardware can only DMA multiples of 4 bytes, and we need at
> + * least the sync word and something else to do anything.
> + */
> + if (count <= 4 || (count % 4) != 0)
> + return -EINVAL;
> +
> err = clk_enable(priv->clk);
> if (err)
> return err;
>
> /* don't globally reset PL if we're doing partial reconfig */
> if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + if (!zynq_fpga_has_sync(buf, count)) {
Maybe we should add an error message here to let the user know what went
wrong, as I think this error path could easily be hit by an user.
Regards,
Matthias
> + err = -EINVAL;
> + goto out_err;
> + }
> +
> /* assert AXI interface resets */
> regmap_write(priv->slcr, SLCR_FPGA_RST_CTRL_OFFSET,
> FPGA_RST_ALL_MASK);
> @@ -287,12 +311,9 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> struct zynq_fpga_priv *priv;
> int err;
> char *kbuf;
> - size_t in_count;
> dma_addr_t dma_addr;
> - u32 transfer_length;
> u32 intr_status;
>
> - in_count = count;
> priv = mgr->priv;
>
> kbuf = dma_alloc_coherent(priv->dev, count, &dma_addr, GFP_KERNEL);
> @@ -318,11 +339,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> */
> zynq_fpga_write(priv, DMA_SRC_ADDR_OFFSET, (u32)(dma_addr) + 1);
> zynq_fpga_write(priv, DMA_DST_ADDR_OFFSET, (u32)DMA_INVALID_ADDRESS);
> -
> - /* convert #bytes to #words */
> - transfer_length = (count + 3) / 4;
> -
> - zynq_fpga_write(priv, DMA_SRC_LEN_OFFSET, transfer_length);
> + zynq_fpga_write(priv, DMA_SRC_LEN_OFFSET, count / 4);
> zynq_fpga_write(priv, DMA_DEST_LEN_OFFSET, 0);
>
> wait_for_completion(&priv->dma_done);
> @@ -338,7 +355,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr,
> clk_disable(priv->clk);
>
> out_free:
> - dma_free_coherent(priv->dev, in_count, kbuf, dma_addr);
> + dma_free_coherent(priv->dev, count, kbuf, dma_addr);
>
> return err;
> }
>
^ permalink raw reply
* [PATCH 2/2] irqchip/gicv3-its: Test code for measuring Read-allocate
From: kbuild test robot @ 2016-11-08 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c3ea714-5bd2-6784-8eae-8b953860c8f6@codeaurora.org>
Hi Shanker,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.9-rc4 next-20161028]
[cannot apply to tip/irq/core arm-jcooper/irqchip/core]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shanker-Donthineni/irqchip-gicv3-its-Test-code-for-measuring-Read-allocate/20161108-154723
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
/tmp/ccEUFgcT.s: Assembler messages:
>> /tmp/ccEUFgcT.s:700: Error: selected processor does not support requested special purpose register -- `mrs r10,pmccntr_el0'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 38721 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/f74b1c64/attachment-0001.gz>
^ permalink raw reply
* [PATCH v4] PM/devfreq: add suspend frequency support
From: hl @ 2016-11-08 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58219B96.6060106@samsung.com>
Hi Chanwoo Choi,
On 2016?11?08? 17:32, Chanwoo Choi wrote:
> Hi Lin,
>
> On 2016? 11? 08? 18:11, Lin Huang wrote:
>> Add suspend frequency support and if needed set it to
>> the frequency obtained from the suspend opp (can be defined
>> using opp-v2 bindings and is optional).
>>
>> Signed-off-by: Lin Huang <hl@rock-chips.com>
>> ---
>> Changes in v2:
>> - use update_devfreq() instead devfreq_update_status()
>> Changes in v3:
>> - fix build error
>> Changes in v4:
>> - move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
>>
>> drivers/devfreq/devfreq.c | 15 +++++++++++++--
>> drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
>> include/linux/devfreq.h | 9 +++++++++
>> 3 files changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index bf3ea76..d9d56e1 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
>> mutex_unlock(&devfreq->lock);
>> return;
>> }
>> -
>> + if (devfreq->suspend_freq) {
>> + update_devfreq(devfreq);
>> + devfreq->suspend_flag = true;
> You don't need the additional variable (devfreq->suspend_flag).
> When adding the devfreq on devfreq_add_device(),
> you can initialize the devfreq->suspend_freq as zero(0).
>
> You can check whether devfreq->suspend_freq is 0 or not
> without the new suspend_flag.
>
>> + }
>> devfreq_update_status(devfreq, devfreq->previous_freq);
>> devfreq->stop_polling = true;
>> mutex_unlock(&devfreq->lock);
>> @@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>>
>> devfreq->last_stat_updated = jiffies;
>> devfreq->stop_polling = false;
>> -
>> + if (devfreq->suspend_freq)
>> + devfreq->suspend_flag = false;
> ditto. You don't need to add this code.
>
>> if (devfreq->profile->get_cur_freq &&
>> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
>> devfreq->previous_freq = freq;
>> @@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> struct devfreq *devfreq;
>> struct devfreq_governor *governor;
>> int err = 0;
>> + struct dev_pm_opp *suspend_opp;
>>
>> if (!dev || !profile || !governor_name) {
>> dev_err(dev, "%s: Invalid parameters.\n", __func__);
>> @@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> devfreq->data = data;
>> devfreq->nb.notifier_call = devfreq_notifier_call;
>>
>> + rcu_read_lock();
>> + suspend_opp = dev_pm_opp_get_suspend_opp(dev);
>> + if (suspend_opp)
>> + devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
>> + rcu_read_unlock();
>> +
>> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
>> mutex_unlock(&devfreq->lock);
>> devfreq_set_freq_table(devfreq);
>> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
>> index ae72ba5..84b3ce1 100644
>> --- a/drivers/devfreq/governor_simpleondemand.c
>> +++ b/drivers/devfreq/governor_simpleondemand.c
>> @@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
>> struct devfreq_simple_ondemand_data *data = df->data;
>> unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>>
>> + /*
>> + * if devfreq in suspend status and have suspend_freq,
>> + * the frequency need to set to suspend_freq
>> + */
>> + if (df->suspend_flag) {
>> + *freq = df->suspend_freq;
>> + return 0;
>> + }
> You can check it as following:
>
> if (df->suspend_freq != 0)
> *freq = df->suspend_freq;
If i do like this, it will always return suspend frequency, since
devfreq->suspend_freq will be assigned value
if we define it on dts. But what we want is only in suspend status we
return the suspend frequency.
>
>> +
>> err = devfreq_update_stats(df);
>> if (err)
>> return err;
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index 2de4e2e..c463ae1 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -172,6 +172,7 @@ struct devfreq {
>> struct delayed_work work;
>>
>> unsigned long previous_freq;
>> + unsigned long suspend_freq;
>> struct devfreq_dev_status last_status;
>>
>> void *data; /* private data for governors */
>> @@ -179,6 +180,7 @@ struct devfreq {
>> unsigned long min_freq;
>> unsigned long max_freq;
>> bool stop_polling;
>> + bool suspend_flag;
> You don't need to add new variable.
>
>>
>> /* information for device frequency transition */
>> unsigned int total_trans;
>> @@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
>> /* Helper functions for devfreq user device driver with OPP. */
>> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
>> unsigned long *freq, u32 flags);
>> +extern void devfreq_opp_get_suspend_opp(struct device *dev,
>> + struct devfreq *devfreq);
> Why do you need this function? Also, this patch don't include the body
> of devfreq_opp_get_suspend_opp() function.
Oh, forget to delete it, sorry about that.
>
>> extern int devfreq_register_opp_notifier(struct device *dev,
>> struct devfreq *devfreq);
>> extern int devfreq_unregister_opp_notifier(struct device *dev,
>> @@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
>> return ERR_PTR(-EINVAL);
>> }
>>
>> +static inline void devfreq_opp_get_suspend_opp(struct device *dev,
>> + struct devfreq *devfreq)
>> +{
>> +}
>> +
>> static inline int devfreq_register_opp_notifier(struct device *dev,
>> struct devfreq *devfreq)
>> {
>>
--
Lin Huang
^ permalink raw reply
* [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Adrian Hunter @ 2016-11-08 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478018277-10097-3-git-send-email-scott.branden@broadcom.com>
On 01/11/16 18:37, Scott Branden wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
This is unchanged from V1 which I acked, so:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-08 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108085420.GG2478@tbergstrom-lnx.Nvidia.com>
On 08/11/16 08:54, Peter De Schrijver wrote:
> On Mon, Nov 07, 2016 at 02:09:31PM +0000, Jon Hunter wrote:
>>
>> On 07/11/16 13:28, Thierry Reding wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>>>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>>>> no OTG-enabled connector.
>>>>
>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>> ---
>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Where is this information coming from? I don't have one of the Nyans
>>> myself, but one of the Tegra132 devices I have, which I think was
>>> derived from one of the Nyans uses one of the external host ports as
>>> forced recovery port, for which it would need OTG.
>>>
>>> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
>>> In that case I think one of the ports must be OTG.
>>
>> It is true that the port on the back on the nyan-big can be used with
>> recovery mode. I was thinking that this is not a true OTG port as it is
>> just a 4-pin type A socket and does not have an ID pin. Thinking some
>> more about this the USB spec does include a "Host Negotiation Protocol
>> (HNP)" that allows a host and device to swap roles and so keeping it as
>> OTG seems valid afterall.
>
> I don't think the bootrom implements that though. I expect recovery mode
> to just program the controller in device mode, without performing any
> negotiation.
I am not talking about the bootrom and I would not expect the bootrom to
do that. However, the kernel could.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Linus Walleij @ 2016-11-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103192002.GB12945@kozik-lap>
On Thu, Nov 3, 2016 at 8:20 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Nov 03, 2016 at 03:39:06PM +0900, Chanwoo Choi wrote:
>> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
>> to support the multiple memory map because the registers of GPFx are located
>> in the different domain.
>>
>> Cc: Tomasz Figa <tomasz.figa@gmail.com>
>> Cc: Krzysztof Kozlowski <krzk@kernel.org>
>> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Cc: Kukjin Kim <kgene@kernel.org>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-gpio at vger.kernel.org
>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>
> I think that, instead of in previous patch, the
> "samsung,exynos5433-pinctrl" compatible should be documented here along
> with information that it requires two addresses for mappings.
True but too small detail to respin the patches about,
and I'm not perfectionist, so patch applied anyways.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/5] pinctrl: samsung: Add GPF support for Exynos5433
From: Linus Walleij @ 2016-11-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-3-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 3, 2016 at 7:39 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
> to support the multiple memory map because the registers of GPFx are located
> in the different domain.
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio at vger.kernel.org
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 1/5] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
From: Linus Walleij @ 2016-11-08 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478155149-28527-2-git-send-email-cw00.choi@samsung.com>
On Thu, Nov 3, 2016 at 7:39 AM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch supports the multiple IORESOURCE_MEM resources for one pin-bank.
> In the pre-existing Exynos series, the registers of the gpio bank are included
> in the one memory map. But, some gpio bank need to support the one more memory
> map (IORESOURCE_MEM) because the registers of gpio bank are separated into
> the different memory map.
>
> For example,
> The both ALIVE and IMEM domain have the different memory base address.
> The GFP[1-5] of exynos5433 are composed as following:
> - ALIVE domain : WEINT_* registers
> - IMEM domain : CON/DAT/PUD/DRV/CONPDN/PUDPDN register
>
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-gpio at vger.kernel.org
> Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Patch applied with Krzysztof's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-11-08 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478596289-7442-1-git-send-email-hl@rock-chips.com>
Hi Lin,
On 2016? 11? 08? 18:11, Lin Huang wrote:
> Add suspend frequency support and if needed set it to
> the frequency obtained from the suspend opp (can be defined
> using opp-v2 bindings and is optional).
>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - use update_devfreq() instead devfreq_update_status()
> Changes in v3:
> - fix build error
> Changes in v4:
> - move dev_pm_opp_get_suspend_opp() to devfreq_add_device()
>
> drivers/devfreq/devfreq.c | 15 +++++++++++++--
> drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
> include/linux/devfreq.h | 9 +++++++++
> 3 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index bf3ea76..d9d56e1 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -363,7 +363,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
> mutex_unlock(&devfreq->lock);
> return;
> }
> -
> + if (devfreq->suspend_freq) {
> + update_devfreq(devfreq);
> + devfreq->suspend_flag = true;
You don't need the additional variable (devfreq->suspend_flag).
When adding the devfreq on devfreq_add_device(),
you can initialize the devfreq->suspend_freq as zero(0).
You can check whether devfreq->suspend_freq is 0 or not
without the new suspend_flag.
> + }
> devfreq_update_status(devfreq, devfreq->previous_freq);
> devfreq->stop_polling = true;
> mutex_unlock(&devfreq->lock);
> @@ -394,7 +397,8 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>
> devfreq->last_stat_updated = jiffies;
> devfreq->stop_polling = false;
> -
> + if (devfreq->suspend_freq)
> + devfreq->suspend_flag = false;
ditto. You don't need to add this code.
> if (devfreq->profile->get_cur_freq &&
> !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> devfreq->previous_freq = freq;
> @@ -528,6 +532,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> struct devfreq *devfreq;
> struct devfreq_governor *governor;
> int err = 0;
> + struct dev_pm_opp *suspend_opp;
>
> if (!dev || !profile || !governor_name) {
> dev_err(dev, "%s: Invalid parameters.\n", __func__);
> @@ -563,6 +568,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq->data = data;
> devfreq->nb.notifier_call = devfreq_notifier_call;
>
> + rcu_read_lock();
> + suspend_opp = dev_pm_opp_get_suspend_opp(dev);
> + if (suspend_opp)
> + devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
> + rcu_read_unlock();
> +
> if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> mutex_unlock(&devfreq->lock);
> devfreq_set_freq_table(devfreq);
> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
> index ae72ba5..84b3ce1 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> struct devfreq_simple_ondemand_data *data = df->data;
> unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>
> + /*
> + * if devfreq in suspend status and have suspend_freq,
> + * the frequency need to set to suspend_freq
> + */
> + if (df->suspend_flag) {
> + *freq = df->suspend_freq;
> + return 0;
> + }
You can check it as following:
if (df->suspend_freq != 0)
*freq = df->suspend_freq;
> +
> err = devfreq_update_stats(df);
> if (err)
> return err;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 2de4e2e..c463ae1 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -172,6 +172,7 @@ struct devfreq {
> struct delayed_work work;
>
> unsigned long previous_freq;
> + unsigned long suspend_freq;
> struct devfreq_dev_status last_status;
>
> void *data; /* private data for governors */
> @@ -179,6 +180,7 @@ struct devfreq {
> unsigned long min_freq;
> unsigned long max_freq;
> bool stop_polling;
> + bool suspend_flag;
You don't need to add new variable.
>
> /* information for device frequency transition */
> unsigned int total_trans;
> @@ -214,6 +216,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
> /* Helper functions for devfreq user device driver with OPP. */
> extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> unsigned long *freq, u32 flags);
> +extern void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq);
Why do you need this function? Also, this patch don't include the body
of devfreq_opp_get_suspend_opp() function.
> extern int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq);
> extern int devfreq_unregister_opp_notifier(struct device *dev,
> @@ -348,6 +352,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
> return ERR_PTR(-EINVAL);
> }
>
> +static inline void devfreq_opp_get_suspend_opp(struct device *dev,
> + struct devfreq *devfreq)
> +{
> +}
> +
> static inline int devfreq_register_opp_notifier(struct device *dev,
> struct devfreq *devfreq)
> {
>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH] pinctrl: sx150x: fix up headers
From: Linus Walleij @ 2016-11-08 9:27 UTC (permalink / raw)
To: linux-arm-kernel
Include <linux/gpio/driver.h> rather than <linux/gpio.h>
Drop <linux/pinctrl/machine.h>.
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-sx150x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index dc1341fdc73d..63778058eec7 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -27,8 +27,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/gpio.h>
-#include <linux/pinctrl/machine.h>
+#include <linux/gpio/driver.h>
#include <linux/pinctrl/pinconf.h>
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinmux.h>
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Huang Shijie @ 2016-11-08 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108070851.GA15044@sha-win-210.asiapac.arm.com>
Hi Gerald,
On Tue, Nov 08, 2016 at 03:08:52PM +0800, Huang Shijie wrote:
> On Tue, Nov 08, 2016 at 10:19:30AM +0800, Huang Shijie wrote:
> > On Mon, Nov 07, 2016 at 04:25:04PM +0100, Gerald Schaefer wrote:
> > > On Thu, 3 Nov 2016 10:51:38 +0800
> > > Huang Shijie <shijie.huang@arm.com> wrote:
> > >
> > > > When testing the gigantic page whose order is too large for the buddy
> > > > allocator, the libhugetlbfs test case "counter.sh" will fail.
> > > >
> > > > The failure is caused by:
> > > > 1) kernel fails to allocate a gigantic page for the surplus case.
> > > > And the gather_surplus_pages() will return NULL in the end.
> > > >
> > > > 2) The condition checks for "over-commit" is wrong.
> > > >
> > > > This patch adds code to allocate the gigantic page in the
> > > > __alloc_huge_page(). After this patch, gather_surplus_pages()
> > > > can return a gigantic page for the surplus case.
> > > >
> > > > This patch also changes the condition checks for:
> > > > return_unused_surplus_pages()
> > > > nr_overcommit_hugepages_store()
> > > >
> > > > After this patch, the counter.sh can pass for the gigantic page.
> > > >
> > > > Acked-by: Steve Capper <steve.capper@arm.com>
> > > > Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> > > > ---
> > > > mm/hugetlb.c | 15 ++++++++++-----
> > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > index 0bf4444..2b67aff 100644
> > > > --- a/mm/hugetlb.c
> > > > +++ b/mm/hugetlb.c
> > > > @@ -1574,7 +1574,7 @@ static struct page *__alloc_huge_page(struct hstate *h,
> > > > struct page *page;
> > > > unsigned int r_nid;
> > > >
> > > > - if (hstate_is_gigantic(h))
> > > > + if (hstate_is_gigantic(h) && !gigantic_page_supported())
> > > > return NULL;
> > >
> > > Is it really possible to stumble over gigantic pages w/o having
> > > gigantic_page_supported()?
> > >
> > > Also, I've just tried this on s390 and counter.sh still fails after these
> > > patches, and it should fail on all archs as long as you use the gigantic
> > I guess the failure you met is caused by the libhugetlbfs itself, there are
> > several bugs in the libhugetlbfs. I have a patch set for the
> > libhugetlbfs too. I will send it as soon as possible.
> >
> > > hugepage size as default hugepage size. This is because you only changed
> > > nr_overcommit_hugepages_store(), which handles nr_overcommit_hugepages
> > > in sysfs, and missed hugetlb_overcommit_handler() which handles
> > > /proc/sys/vm/nr_overcommit_hugepages for the default sized hugepages.
> > This is wrong. :)
> Sorry, I was wrong :). The counters test does call the /proc/sys/vm/nr_overcommit_hugepages.
> But in the arm64, it does not trigger a fail for the counters test.
> In an other word, I did not change the hugetlb_overcommit_handler(),
> the counters.sh also can pass in arm64.
After I add the "default_hugepagesz=32M" to the kernel cmdlin, I can
reproduce this issue. Thanks for point this.
>
> I will look at the lockdep issue.
I tested the new patch (will be sent out later) on the arm64 platform,
and I did not meet the lockdep issue when I enabled the lockdep.
The following is my config:
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
So do I miss something?
Thanks
Huang Shijie
^ 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