* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Alexandre Bailon @ 2016-12-06 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fc7a4ef-02ad-fc15-66ea-9f75756086f8@ti.com>
On 12/06/2016 10:33 AM, Sekhar Nori wrote:
> On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
>> Everytime the usb20 phy is enabled, there is a
>> "sleeping function called from invalid context" BUG.
>>
>> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
>> before to invoke the callback usb20_phy_clk_enable().
>> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
>> which may sleep.
>> Move clk_get() to da8xx_register_usb20_phy_clk() and
>> replace clk_prepare_enable() by clk_enable().
>>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>
> This will still cause the recursive locking problem reported by David.
> Not sure what the point of sending this version was.
>
> Thanks,
> Sekhar
>
What am I supposed to do ?
Thanks,
Alexandre
^ permalink raw reply
* [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT
From: Lee Jones @ 2016-12-06 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e15186cb-a93e-c2e7-13bb-6704be5e8949@st.com>
On Mon, 05 Dec 2016, Alexandre Torgue wrote:
> On 12/02/2016 02:22 PM, Lee Jones wrote:
> > On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
> >
> > > Add general purpose timers and it sub-nodes into DT for stm32f4.
> > > Define and enable pwm1 and pwm3 for stm32f469 discovery board
> > >
> > > version 3:
> > > - use "st,stm32-timer-trigger" in DT
> > >
> > > version 2:
> > > - use parameters to describe hardware capabilities
> > > - do not use references for pwm and iio timer subnodes
> > >
> > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> > > ---
> > > arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++++++++++++++++++++++-
> > > arch/arm/boot/dts/stm32f469-disco.dts | 28 +++
> > > 2 files changed, 360 insertions(+), 1 deletion(-)
[...]
If you're only commenting on a little piece of the patch, it's always
a good idea to trim the rest.
> > > diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> > > index 8a163d7..df4ca7e 100644
> > > --- a/arch/arm/boot/dts/stm32f469-disco.dts
> > > +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> > > @@ -81,3 +81,31 @@
> > > &usart3 {
> > > status = "okay";
> > > };
> > > +
> > > +&gptimer1 {
> > > + status = "okay";
> > > +
> > > + pwm1 at 0 {
> > > + pinctrl-0 = <&pwm1_pins>;
> > > + pinctrl-names = "default";
> > > + status = "okay";
> > > + };
> > > +
> > > + timer1 at 0 {
> > > + status = "okay";
> > > + };
> > > +};
> >
> > This is a much *better* format than before.
> >
> > I still don't like the '&' syntax though.
>
> Please keep "&" format to match with existing nodes.
Right. I wasn't suggesting that he differs from the current format in
*this* set. I am suggesting that we change the format in a subsequent
set though.
> > > +&gptimer3 {
> > > + status = "okay";
> > > +
> > > + pwm3 at 0 {
> > > + pinctrl-0 = <&pwm3_pins>;
> > > + pinctrl-names = "default";
> > > + status = "okay";
> > > + };
> > > +
> > > + timer3 at 0 {
> > > + status = "okay";
> > > + };
> > > +};
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Will Deacon @ 2016-12-06 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205122619.25045-1-lorenzo.pieralisi@arm.com>
On Mon, Dec 05, 2016 at 12:26:19PM +0000, Lorenzo Pieralisi wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Sricharan R <sricharan@codeaurora.org>
> ---
> Joerg,
>
> pending Rafael's ACK on it, given the 4.10 release timing and that the
> series is queued via the IOMMU tree please consider applying this patch to
> your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> the x86/ia64 code path; I prefer preventing any issue related to default
> dma masks on x86/ia64 so I hope it can get merged along with the rest of
> the ACPI IORT SMMU series.
>
> Thanks a lot and apologies,
> Lorenzo
>
> drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
> drivers/acpi/scan.c | 14 +-------------
> include/linux/acpi_iort.h | 2 ++
> 3 files changed, 25 insertions(+), 13 deletions(-)
Looks straightforward to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Joerg can probably just pick this on top of his queue.
Will
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: imx6: Support Poslab Savageboard dual & quad
From: Fabio Estevam @ 2016-12-06 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206070829.24098-1-woogyom.kim@gmail.com>
Hi Milo,
On Tue, Dec 6, 2016 at 5:08 AM, Milo Kim <woogyom.kim@gmail.com> wrote:
> Poslab Savageboard is i.MX6 SoC base, but BSP code from the vendor is
> not mainline u-boot and kernel. Personal reason of using this board is
> testing etnaviv user-space driver, so I re-write device tree files based on
> mainline kernel for the first step.
>
> This patchset includes common DT file, dual and quad board files.
>
> Supported components are
> - Display: HDMI and LVDS panel
> - eMMC and SD card
> - Ethernet
> - Pinmux configuration
> - SATA: only for Savageboard quad
> - UART1 for debug console
> - USB host
>
> Missing features are
> - Audio (WM8903)
> - USB OTG
> - PMIC WM8326: default settings are used so no issue to bring-up the system
> - MIPI DSI, CSI
>
> Patches are tested on the Savageboard quad but the dual version should work
> because the only difference between dual and quad is SATA support.
>
> More information in http://www.savageboard.org
>
> v2:
> Fix DT node for regulator, phy-reset-gpios and iomuxc node.
>
> Milo Kim (3):
> ARM: dts: imx6: Add Savageboard common file
> ARM: dts: imx6: Support Savageboard dual
> ARM: dts: imx6: Support Savageboard quad
>
> arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++
> arch/arm/boot/dts/imx6q-savageboard.dts | 54 ++++++
> arch/arm/boot/dts/imx6qdl-savageboard.dtsi | 262 +++++++++++++++++++++++++++++
You missed to add imx6q-savageboard.dtb and imx6dl-savageboard.dtb
entries into arch/arm/boot/dts/Makefile
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Lorenzo Pieralisi @ 2016-12-06 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hbc61=QCYDgHZ_KbxR7VkSSWrHVGvU47fG6hsQrSJKhw@mail.gmail.com>
Hi Joerg,
On Mon, Dec 05, 2016 at 11:18:56PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > The introduction of acpi_dma_configure() allows to configure DMA
> > and related IOMMU for any device that is DMA capable. To achieve
> > that goal it ensures DMA masks are set-up to sane default values
> > before proceeding with IOMMU and DMA ops configuration.
> >
> > On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> > called for every device that has an ACPI companion, in that every device
> > is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> > which has the side effect of initializing dma masks also for
> > pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> > whose dma masks were not set-up before the acpi_dma_configure() API was
> > introduced, which may have noxious side effects.
> >
> > Therefore, in preparation for IORT firmware specific DMA masks set-up,
> > wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> > specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> > default expected behaviour on x86/ia64 systems and keeping DMA default
> > masks set-up on IORT based (ie ARM) arch configurations.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Tomasz Nowicki <tn@semihalf.com>
> > Cc: Joerg Roedel <joro@8bytes.org>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Sricharan R <sricharan@codeaurora.org>
>
> Acked -by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> > ---
> > Joerg,
> >
> > pending Rafael's ACK on it, given the 4.10 release timing and that the
> > series is queued via the IOMMU tree please consider applying this patch to
> > your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> > the x86/ia64 code path; I prefer preventing any issue related to default
> > dma masks on x86/ia64 so I hope it can get merged along with the rest of
> > the ACPI IORT SMMU series.
I can apply Rafael and Hanjun's tags and resend a v2 to you if you
prefer, it would be great if you could apply this patch to your arm/smmu
branch for v4.10 as per description above, please let me know.
Thank you !
Lorenzo
> >
> > Thanks a lot and apologies,
> > Lorenzo
> >
> > drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
> > drivers/acpi/scan.c | 14 +-------------
> > include/linux/acpi_iort.h | 2 ++
> > 3 files changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 47bace8..e0d2e6e 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
> > }
> >
> > /**
> > + * iort_set_dma_mask - Set-up dma mask for a device.
> > + *
> > + * @dev: device to configure
> > + */
> > +void iort_set_dma_mask(struct device *dev)
> > +{
> > + /*
> > + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> > + * setup the correct supported mask.
> > + */
> > + if (!dev->coherent_dma_mask)
> > + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> > +
> > + /*
> > + * Set it to coherent_dma_mask by default if the architecture
> > + * code has not set it.
> > + */
> > + if (!dev->dma_mask)
> > + dev->dma_mask = &dev->coherent_dma_mask;
> > +}
> > +
> > +/**
> > * iort_iommu_configure - Set-up IOMMU configuration for a device.
> > *
> > * @dev: device to configure
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 80698d3..93b00cf 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> > {
> > const struct iommu_ops *iommu;
> >
> > - /*
> > - * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> > - * setup the correct supported mask.
> > - */
> > - if (!dev->coherent_dma_mask)
> > - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> > -
> > - /*
> > - * Set it to coherent_dma_mask by default if the architecture
> > - * code has not set it.
> > - */
> > - if (!dev->dma_mask)
> > - dev->dma_mask = &dev->coherent_dma_mask;
> > + iort_set_dma_mask(dev);
> >
> > iommu = iort_iommu_configure(dev);
> >
> > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> > index dcb2b60..77e0809 100644
> > --- a/include/linux/acpi_iort.h
> > +++ b/include/linux/acpi_iort.h
> > @@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
> > u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> > struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> > /* IOMMU interface */
> > +void iort_set_dma_mask(struct device *dev);
> > const struct iommu_ops *iort_iommu_configure(struct device *dev);
> > #else
> > static inline void acpi_iort_init(void) { }
> > @@ -45,6 +46,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> > u32 req_id)
> > { return NULL; }
> > /* IOMMU interface */
> > +static inline void iort_set_dma_mask(struct device *dev) { }
> > static inline
> > const struct iommu_ops *iort_iommu_configure(struct device *dev)
> > { return NULL; }
> > --
> > 2.10.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 14/18] arm64: signal32: move ilp32 and aarch32 common code to separated file
From: Yury Norov @ 2016-12-06 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205161823.GF14429@e104818-lin.cambridge.arm.com>
On Mon, Dec 05, 2016 at 04:18:24PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:13PM +0300, Yury Norov wrote:
> > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
>
> Please add some description, even if it means copying the subject.
>
> > ---
> > arch/arm64/include/asm/signal32.h | 3 +
> > arch/arm64/include/asm/signal32_common.h | 27 +++++++
> > arch/arm64/kernel/Makefile | 2 +-
> > arch/arm64/kernel/signal32.c | 107 ------------------------
> > arch/arm64/kernel/signal32_common.c | 135 +++++++++++++++++++++++++++++++
> > 5 files changed, 166 insertions(+), 108 deletions(-)
> > create mode 100644 arch/arm64/include/asm/signal32_common.h
> > create mode 100644 arch/arm64/kernel/signal32_common.c
>
> I wonder whether you can make such patches more readable by setting
> "diff.renames" to "copy" in your gitconfig (unless it's set already and
> Git cannot detect partial file code moving/copying).
I tried "git format-patch -C --find-copies-harder" - the same result.
Yury
^ permalink raw reply
* [PATCH] ARM: dts: da850: enable high speed for mmc
From: Sekhar Nori @ 2016-12-06 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201141041.31386-1-ahaslam@baylibre.com>
On Thursday 01 December 2016 07:40 PM, Axel Haslam wrote:
> The mmc controller in da850 supports high speed modes
> so add cap-sd-highspeed and cap-mmc-highspeed.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Forgot to reply earlier, but this was applied.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Sekhar Nori @ 2016-12-06 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480947224-26222-1-git-send-email-abailon@baylibre.com>
On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
> Everytime the usb20 phy is enabled, there is a
> "sleeping function called from invalid context" BUG.
>
> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
> before to invoke the callback usb20_phy_clk_enable().
> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
> which may sleep.
> Move clk_get() to da8xx_register_usb20_phy_clk() and
> replace clk_prepare_enable() by clk_enable().
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
This will still cause the recursive locking problem reported by David.
Not sure what the point of sending this version was.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Ard Biesheuvel @ 2016-12-06 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481012975-44478-1-git-send-email-maninder1.s@samsung.com>
On 6 December 2016 at 08:29, Maninder Singh <maninder1.s@samsung.com> wrote:
> This patch defines new macro MODULE_START to ensure kernel text
> and module remains within 32 MB of address range.
>
> Tried this patch by inserting 20 MB size module on 4.1 kernel:-
>
> Earlier:-
> ==========
> sh# insmod size.ko
> ....
> insmod: ERROR: could not insert module size.ko: Cannot allocate memory
> sh#
>
> With this patch
> ===============
> sh# insmod size.ko
> ...
> sh# lsmod
> Module Size Used by
> size 20972425 0
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> Reviewed-by: Ajeet Yadav <ajeet.y@samsung.com>
> ---
> arch/arm/include/asm/memory.h | 4 ++--
> arch/arm/kernel/module.c | 9 ++++++++-
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c..1a0a6e5 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -37,7 +37,7 @@
> * TASK_SIZE - the maximum size of a user space task.
> * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
> */
> -#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
> +#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_32M))
> #define TASK_UNMAPPED_BASE ALIGN(TASK_SIZE / 3, SZ_16M)
>
> /*
> @@ -50,7 +50,7 @@
> * and PAGE_OFFSET - it must be within 32MB of the kernel text.
> */
> #ifndef CONFIG_THUMB2_KERNEL
> -#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
> +#define MODULES_VADDR (PAGE_OFFSET - SZ_32M)
> #else
> /* smaller range for Thumb-2 symbols relocation (2^24)*/
> #define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index 4f14b5c..b8e1f9c 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -35,12 +35,19 @@
> */
> #undef MODULES_VADDR
> #define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
> +#define MODULES_START MODULES_VADDR
> +#else
> +#ifndef CONFIG_THUMB2_KERNEL
> +#define MODULES_START ALIGN((unsigned long)_etext - SZ_32M, PAGE_SIZE)
On a multi_v7_defconfig kernel, the text size is >8 MB, which means
you are only adding ~7 MB to the module area, while consuming 16 MB of
additional address space. Given that 20 MB modules are very uncommon,
I think it is better to enable CONFIG_ARM_MODULE_PLTS instead. That
way, there is no need to update these defaults for everyone.
> +#else
> +#define MODULES_START MODULES_VADDR
> +#endif
> #endif
>
> #ifdef CONFIG_MMU
> void *module_alloc(unsigned long size)
> {
> - void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> + void *p = __vmalloc_node_range(size, 1, MODULES_START, MODULES_END,
> GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
> __builtin_return_address(0));
> if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ARM: dts: STiH410-b2260: Identify the UART RTS line
From: Patrice Chotard @ 2016-12-06 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202141146.31281-1-lee.jones@linaro.org>
Hi Lee
Except the typo in patch 2
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
On 12/02/2016 03:11 PM, Lee Jones wrote:
> Configure the UART RTS line as a GPIO for manipulation within the UART driver.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/stih410-b2260.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stih410-b2260.dts b/arch/arm/boot/dts/stih410-b2260.dts
> index 7fb507f..f46603f 100644
> --- a/arch/arm/boot/dts/stih410-b2260.dts
> +++ b/arch/arm/boot/dts/stih410-b2260.dts
> @@ -63,6 +63,7 @@
> uart0: serial at 9830000 {
> label = "LS-UART0";
> status = "okay";
> + rts-gpios = <&pio17 3 GPIO_ACTIVE_LOW>;
> };
>
> /* Low speed expansion connector */
>
^ permalink raw reply
* [PATCH 06/11] ARM: dts: imx: Add imx6sll EVK board dts support
From: Jacky Bai @ 2016-12-06 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C5-tq-OWTYcmzJt=_57wOyXzNMUes1mctwwyoegwzJyQ@mail.gmail.com>
Hi Fabio,
Please see below.
> Subject: Re: [PATCH 06/11] ARM: dts: imx: Add imx6sll EVK board dts support
>
> On Fri, Dec 2, 2016 at 4:39 AM, Bai Ping <ping.bai@nxp.com> wrote:
> > Add basic dts support for imx6sll EVK baoard.
>
> s/baord/board
ok, I will fix this typo.
>
> > + battery: max8903 at 0 {
> > + compatible = "fsl,max8903-charger";
> > + pinctrl-names = "default";
> > + dok_input = <&gpio4 13 1>;
> > + uok_input = <&gpio4 13 1>;
> > + chg_input = <&gpio4 15 1>;
> > + flt_input = <&gpio4 14 1>;
> > + fsl,dcm_always_high;
> > + fsl,dc_valid;
> > + fsl,adc_disable;
>
> These properties do not exist in mainline, please remove them.
ok, thanks for you comment.
>
>
> > + status = "okay";
> > + };
> > +
> > + pxp_v4l2_out {
> > + compatible = "fsl,imx6sl-pxp-v4l2";
> > + status = "okay";
> > + };
>
> We don't have pxp support in mainline kernel, please remove it.
Ok, I will remove it.
>
> > +
> > + regulators {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
>
> Please remove it and place the regulator nodes directly as below:
ok, I will fix it.
>
>
> > +
> > + reg_usb_otg1_vbus: regulator at 0 {
> > + compatible = "regulator-fixed";
> > + reg = <0>;
> > + regulator-name = "usb_otg1_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + gpio = <&gpio4 0 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
>
> reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb_otg1_vbus";
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> gpio = <&gpio4 0 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> };
>
> > +&cpu0 {
> > + arm-supply = <&sw1a_reg>;
> > + soc-supply = <&sw1c_reg>;
> > +};
>
> This is only for LDO bypass mode, right? We don't support LDO-bypass in
> mainline.
>
On i.MX6SLL, no internal LDO for ARM and SOC. We can only use external regulator for DVFS.
> > +&gpc {
> > + fsl,ldo-bypass = <1>;
>
> We don't support ldo-bypass in mainline, please remove it.
>
> > +&pxp {
> > + status = "okay";
> > +};
>
> We don't support PXP in mainline, please remove it.
ok I will remove it.
BR
Jacky Bai
^ permalink raw reply
* [PATCH 2/2] arm64: dts: NS2: add support for XMC form factor
From: kbuild test robot @ 2016-12-06 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480979542-26871-3-git-send-email-jon.mason@broadcom.com>
Hi Jon,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc8]
[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/Jon-Mason/arm64-dts-NS2-reserve-memory-for-Nitro-firmware/20161206-125631
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-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=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:56.1-6 Label or path enet not found
>> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:132.1-7 Label or path pcie8 not found
>> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:148.1-6 Label or path qspi not found
>> FATAL ERROR: Syntax error parsing input tree
---
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: 52465 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/fc197763/attachment-0001.gz>
^ permalink raw reply
* ILP32 for ARM64: testing with glibc testsuite
From: Andreas Schwab @ 2016-12-06 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480966437.29811.23.camel@caviumnetworks.com>
On Dez 05 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote:
> FAIL: nptl/tst-cancel26
> FAIL: nptl/tst-cancel27
> FAIL: rt/tst-mqueue1
> FAIL: rt/tst-mqueue2
> FAIL: rt/tst-mqueue4
> FAIL: rt/tst-mqueue7
I don't see these failures. Maybe you need to rebuild libgcc?
https://build.opensuse.org/package/live_build_log/devel:ARM:AArch64:ILP32/glibc-testsuite/standard/aarch64_ilp32
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Maninder Singh @ 2016-12-06 8:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch defines new macro MODULE_START to ensure kernel text
and module remains within 32 MB of address range.
Tried this patch by inserting 20 MB size module on 4.1 kernel:-
Earlier:-
==========
sh# insmod size.ko
....
insmod: ERROR: could not insert module size.ko: Cannot allocate memory
sh#
With this patch
===============
sh# insmod size.ko
...
sh# lsmod
Module Size Used by
size 20972425 0
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Reviewed-by: Ajeet Yadav <ajeet.y@samsung.com>
---
arch/arm/include/asm/memory.h | 4 ++--
arch/arm/kernel/module.c | 9 ++++++++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c..1a0a6e5 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -37,7 +37,7 @@
* TASK_SIZE - the maximum size of a user space task.
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
*/
-#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
+#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_32M))
#define TASK_UNMAPPED_BASE ALIGN(TASK_SIZE / 3, SZ_16M)
/*
@@ -50,7 +50,7 @@
* and PAGE_OFFSET - it must be within 32MB of the kernel text.
*/
#ifndef CONFIG_THUMB2_KERNEL
-#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
+#define MODULES_VADDR (PAGE_OFFSET - SZ_32M)
#else
/* smaller range for Thumb-2 symbols relocation (2^24)*/
#define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 4f14b5c..b8e1f9c 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -35,12 +35,19 @@
*/
#undef MODULES_VADDR
#define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
+#define MODULES_START MODULES_VADDR
+#else
+#ifndef CONFIG_THUMB2_KERNEL
+#define MODULES_START ALIGN((unsigned long)_etext - SZ_32M, PAGE_SIZE)
+#else
+#define MODULES_START MODULES_VADDR
+#endif
#endif
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ void *p = __vmalloc_node_range(size, 1, MODULES_START, MODULES_END,
GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
--
1.9.1
^ permalink raw reply related
* [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: David.Wu @ 2016-12-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1737869.ycGphUXI8X@phil>
Hi Heiko,
? 2016/12/5 18:54, Heiko Stuebner ??:
> Hi David,
>
> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>> During suspend there may still be some i2c access happening.
>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>> i2c is in irq mode of operation.
>
> can you describe the issue you're trying to fix a bit more please?
Sometimes we could see the i2c timeout errors during suspend/resume,
which makes the duration of suspend/resume too longer.
[ 484.171541] CPU4: Booted secondary processor [410fd082]
[ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
[ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
800000 800000 mV): -110
[ 487.172874] cpu cpu4: failed to set volt 800000
>
> I.e. I'd think the i2c-core does suspend i2c-client devices first, so that
> these should be able to finish up their ongoing transfers and not start any
> new ones instead?
>
> Your irq can still happen slightly after the system started going to actually
> sleep, so to me it looks like you just widened the window where irqs can be
> handled. Especially as your irq could also just simply stem from the start
> state, so you cannot even be sure if your transaction actually is finished.
Okay, you are right. I want to give it a double insurance at first, but
it may hide the unhappend issue.
>
> So to me it looks like the i2c-connected device driver should be fixed instead?
I tell them to fix it in rk808 driver.
>
> In the past I solved this for example in the zforce_ts driver [0] to
> prevent i2c transfers from happening during suspend.
>
>
> Heiko
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/touchscreen/zforce_ts.c
>
>
>>
>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>> ---
>> drivers/i2c/busses/i2c-rk3x.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
>> index df22066..67af32a 100644
>> --- a/drivers/i2c/busses/i2c-rk3x.c
>> +++ b/drivers/i2c/busses/i2c-rk3x.c
>> @@ -1261,7 +1261,7 @@ static int rk3x_i2c_probe(struct platform_device
>> *pdev) }
>>
>> ret = devm_request_irq(&pdev->dev, irq, rk3x_i2c_irq,
>> - 0, dev_name(&pdev->dev), i2c);
>> + IRQF_NO_SUSPEND, dev_name(&pdev->dev), i2c);
>> if (ret < 0) {
>> dev_err(&pdev->dev, "cannot request IRQ\n");
>> return ret;
>
>
>
>
>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Icenowy Zheng @ 2016-12-06 8:08 UTC (permalink / raw)
To: linux-arm-kernel
Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
has a dedicated enable pin (PL8 in the reference design).
Enable the pin in the same way as the WLAN enable pins.
Tested on an A33 Q8 tablet with RTL8703AS.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
This patch should be coupled with the uart1 node patch I send before:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
https://github.com/lwfinger/rtl8723bs_bt
arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index c676940..4aeb5bb 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -88,7 +88,7 @@
&r_pio {
wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 {
- pins = "PL6", "PL7", "PL11";
+ pins = "PL6", "PL7", "PL8", "PL11";
function = "gpio_in";
bias-pull-up;
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-06 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17819681480935706@web24g.yandex.ru>
On Mon, Dec 05, 2016 at 07:01:46PM +0800, Icenowy Zheng wrote:
>
>
> 05.12.2016, 17:40, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Mon, Dec 05, 2016 at 04:59:44PM +0800, Icenowy Zheng wrote:
> >> ?2016?12?5? 16:52? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >> ?>
> >> ?> On Fri, Dec 02, 2016 at 10:22:30PM +0800, Icenowy Zheng wrote:
> >> ?> >
> >> ?> >
> >> ?> > 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> >> ?> > > On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
> >> ?> > >> ?> Something more interesting happened.
> >> ?> > >> ?>
> >> ?> > >> ?> Xunlong made a add-on board for Orange Pi Zero, which exposes the
> >> ?> > >> ?> two USB Controllers exported at expansion bus as USB Type-A
> >> ?> > >> ?> connectors.
> >> ?> > >> ?>
> >> ?> > >> ?> Also it exposes a analog A/V jack and a microphone.
> >> ?> > >> ?>
> >> ?> > >> ?> Should I enable {e,o}hci{2.3} in the device tree?
> >> ?> > >>
> >> ?> > >> ?Actually we should do this regardless of this extension board. The USB
> >> ?> > >> ?pins are not multiplexed and are exposed on user accessible pins (just
> >> ?> > >> ?not soldered, but that's a detail), so I think they qualify for DT
> >> ?> > >> ?enablement. And even if a user can't use them, it doesn't hurt to have
> >> ?> > >> ?them (since they are not multiplexed).
> >> ?> > >
> >> ?> > > My main concern about this is that we'll leave regulators enabled by
> >> ?> > > default, for a minority of users. And that minority will prevent to do
> >> ?> > > a proper power management when the times come since we'll have to keep
> >> ?> > > that behaviour forever.
> >> ?> >
> >> ?> > I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
> >> ?>
> >> ?> You can't ask that from the majority of users. These users will take
> >> ?> debian or fedora, install it, and expect everything to work
> >> ?> properly. I would make the opposite argument actually. If someone is
> >> ?> knowledgeable enough to solder the USB pins a connector, then (s)he'll
> >> ?> be able to make that u-boot call.
> >>
> >> ?Now (s)he do not need soldering.
> >>
> >> ?(S)he needs only paying $1.99 more to Xunlong to get the expansion
> >> ?board, and insert it on the OPi Zero.
> >
> > Which is going to require an overlay anyway, so we could have the USB
> > bits in there too.
>
> If so, I think the [PATCH -next v3 2/2] is ready to be merged ;-)
I meant enabling the USB in the overlay, you enabled it in the base DT.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161206/efad492b/attachment.sig>
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Hanjun Guo @ 2016-12-06 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205122619.25045-1-lorenzo.pieralisi@arm.com>
On 2016/12/5 20:26, Lorenzo Pieralisi wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
Add this patch on top of your v9 acpi smmu patchset,
tested on Hisilicon D03 (ARM64), devices with SMMU
enabled work fine,
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
^ permalink raw reply
* [PATCH] media/platform/exynos4-is/fimc-is - Unmap region obtained by of_iomap
From: Arvind Yadav @ 2016-12-06 7:42 UTC (permalink / raw)
To: linux-arm-kernel
Free memory mapping, if fimc_is_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/media/platform/exynos4-is/fimc-is.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 32ca55f..10d98a5 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -818,12 +818,13 @@ static int fimc_is_probe(struct platform_device *pdev)
is->irq = irq_of_parse_and_map(dev->of_node, 0);
if (!is->irq) {
dev_err(dev, "no irq found\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_iounmap;
}
ret = fimc_is_get_clocks(is);
if (ret < 0)
- return ret;
+ goto err_iounmap;
platform_set_drvdata(pdev, is);
@@ -877,6 +878,8 @@ err_irq:
free_irq(is->irq, is);
err_clk:
fimc_is_put_clocks(is);
+err_iounmap:
+ iounmap(is->pmu_regs);
return ret;
}
@@ -932,6 +935,7 @@ static int fimc_is_remove(struct platform_device *pdev)
fimc_is_unregister_subdevs(is);
vb2_dma_contig_clear_max_seg_size(dev);
fimc_is_put_clocks(is);
+ iounmap(is->pmu_regs);
fimc_is_debugfs_remove(is);
release_firmware(is->fw.f_w);
fimc_is_free_cpu_memory(is);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 11/18] arm64: ilp32: share aarch32 syscall handlers
From: Yury Norov @ 2016-12-06 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205171242.GH14429@e104818-lin.cambridge.arm.com>
On Mon, Dec 05, 2016 at 05:12:43PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:10PM +0300, Yury Norov wrote:
> > off_t is passed in register pair just like in aarch32.
> > In this patch corresponding aarch32 handlers are shared to
> > ilp32 code.
> [...]
> > +/*
> > + * Note: off_4k (w5) is always in units of 4K. If we can't do the
> > + * requested offset because it is not page-aligned, we return -EINVAL.
> > + */
> > +ENTRY(compat_sys_mmap2_wrapper)
> > +#if PAGE_SHIFT > 12
> > + tst w5, #~PAGE_MASK >> 12
> > + b.ne 1f
> > + lsr w5, w5, #PAGE_SHIFT - 12
> > +#endif
> > + b sys_mmap_pgoff
> > +1: mov x0, #-EINVAL
> > + ret
> > +ENDPROC(compat_sys_mmap2_wrapper)
>
> For compat sys_mmap2, the pgoff argument is in multiples of 4K. This was
> traditionally used for architectures where off_t is 32-bit to allow
> mapping files to 2^44.
>
> Since off_t is 64-bit with AArch64/ILP32, should we just pass the off_t
> as a 64-bit value in two different registers (w5 and w6)?
Current glibc implementation becomes broken for 64-bit off_t if
if I'll do what you want.
sysdeps/unix/sysv/linux/generic/wordsize-32/mmap.c
28 __ptr_t
29 __mmap (__ptr_t addr, size_t len, int prot, int flags, int fd, off_t offset)
30 {
31 if (offset & (MMAP_PAGE_UNIT - 1))
32 {
33 __set_errno (EINVAL);
34 return MAP_FAILED;
35 }
36 return (__ptr_t) INLINE_SYSCALL (mmap2, 6, addr, len, prot, flags, fd,
37 offset / MMAP_PAGE_UNIT);
38 }
39
40 weak_alias (__mmap, mmap)
So it requires changes both in glibc and in kernel. I can do it. But
I'd like to collect opinions of kernel and glibc developers before
starting it.
Yury
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1
From: Milo Kim @ 2016-12-06 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205080932.xaqyl2httgxgso67@lukather>
On 12/05/2016 05:09 PM, Maxime Ripard wrote:
> On Mon, Dec 05, 2016 at 11:00:31AM +0900, Milo Kim wrote:
>> The board has DDR3 512MB. This patch helps scanning the memory and
>> adding memblock through the DT.
>>
>> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
>> ---
>> arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> index ec63d10..be3668f 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> @@ -45,6 +45,11 @@
>> / {
>> model = "FriendlyArm NanoPi M1";
>> compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
>> +
>> + memory at 40000000 {
>> + device_type = "memory";
>> + reg = <0x40000000 0x20000000>;
>> + };
>
> U-boot will fill that up, so there's no need to put it there.
Right, my intention was adding memblock through the DT whether the
bootload does or not. However I'm not sure the situation (missing
memblock in u-boot) could really happen.
Best regards,
Milo
^ permalink raw reply
* [PATCH] ipmi: bt-bmc: Use a regmap for register access
From: Cédric Le Goater @ 2016-12-06 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025715.2002-1-andrew@aj.id.au>
On 12/06/2016 03:57 AM, Andrew Jeffery wrote:
> The registers for the bt-bmc device live under the Aspeed LPC
> controller. Devicetree bindings have recently been introduced for the
> LPC controller where the "host" portion of the LPC register space is
> described as a syscon device. Future devicetrees describing the bt-bmc
> device should nest its node under the appropriate "simple-mfd", "syscon"
> compatible node.
>
> This change allows the bt-bmc driver to function with both syscon and
> non-syscon- based devicetree descriptions by always using a regmap for
> register access, either retrieved from the parent syscon device or
> instantiated if none exists.
>
> The patch has been tested on an OpenPOWER Palmetto machine, successfully
> booting, rebooting and powering down the host.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
It would be nice to have an example of the associated binding.
I did not see it. A part from that :
Reviewed-by: C?dric Le Goater <clg@kaod.org>
Thanks,
C.
> ---
> drivers/char/ipmi/Kconfig | 1 +
> drivers/char/ipmi/bt-bmc.c | 82 ++++++++++++++++++++++++++++++++++------------
> 2 files changed, 62 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> index 7f816655cbbf..b5d48d9af124 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -79,6 +79,7 @@ endif # IPMI_HANDLER
>
> config ASPEED_BT_IPMI_BMC
> depends on ARCH_ASPEED
> + depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
> tristate "BT IPMI bmc driver"
> help
> Provides a driver for the BT (Block Transfer) IPMI interface
> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
> index fc9e8891eae3..ca1e20f6c6c5 100644
> --- a/drivers/char/ipmi/bt-bmc.c
> +++ b/drivers/char/ipmi/bt-bmc.c
> @@ -12,10 +12,13 @@
> #include <linux/errno.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> +#include <linux/mfd/syscon.h>
> #include <linux/miscdevice.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/poll.h>
> +#include <linux/regmap.h>
> #include <linux/sched.h>
> #include <linux/timer.h>
>
> @@ -60,7 +63,8 @@
> struct bt_bmc {
> struct device dev;
> struct miscdevice miscdev;
> - void __iomem *base;
> + struct regmap *map;
> + int offset;
> int irq;
> wait_queue_head_t queue;
> struct timer_list poll_timer;
> @@ -69,14 +73,31 @@ struct bt_bmc {
>
> static atomic_t open_count = ATOMIC_INIT(0);
>
> +static struct regmap_config bt_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
> {
> - return ioread8(bt_bmc->base + reg);
> + uint32_t val = 0;
> + int rc;
> +
> + rc = regmap_read(bt_bmc->map, bt_bmc->offset + reg, &val);
> + WARN(rc != 0, "%s:%d: regmap_read() failed: %d\n",
> + __FILE__, __LINE__, rc);
> +
> + return rc == 0 ? (u8) val : 0;
> }
>
> static void bt_outb(struct bt_bmc *bt_bmc, u8 data, int reg)
> {
> - iowrite8(data, bt_bmc->base + reg);
> + int rc;
> +
> + rc = regmap_write(bt_bmc->map, bt_bmc->offset + reg, data);
> + WARN(rc != 0, "%s:%d: regmap_write() failed: %d\n",
> + __FILE__, __LINE__, rc);
> }
>
> static void clr_rd_ptr(struct bt_bmc *bt_bmc)
> @@ -367,14 +388,18 @@ static irqreturn_t bt_bmc_irq(int irq, void *arg)
> {
> struct bt_bmc *bt_bmc = arg;
> u32 reg;
> + int rc;
> +
> + rc = regmap_read(bt_bmc->map, bt_bmc->offset + BT_CR2, ®);
> + if (rc)
> + return IRQ_NONE;
>
> - reg = ioread32(bt_bmc->base + BT_CR2);
> reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY;
> if (!reg)
> return IRQ_NONE;
>
> /* ack pending IRQs */
> - iowrite32(reg, bt_bmc->base + BT_CR2);
> + regmap_write(bt_bmc->map, bt_bmc->offset + BT_CR2, reg);
>
> wake_up(&bt_bmc->queue);
> return IRQ_HANDLED;
> @@ -384,7 +409,6 @@ static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
> struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - u32 reg;
> int rc;
>
> bt_bmc->irq = platform_get_irq(pdev, 0);
> @@ -405,18 +429,17 @@ static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
> * will be cleared (along with B2H) when we can write the next
> * message to the BT buffer
> */
> - reg = ioread32(bt_bmc->base + BT_CR1);
> - reg |= BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY;
> - iowrite32(reg, bt_bmc->base + BT_CR1);
> + rc = regmap_update_bits(bt_bmc->map, bt_bmc->offset + BT_CR1,
> + (BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY),
> + (BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY));
>
> - return 0;
> + return rc;
> }
>
> static int bt_bmc_probe(struct platform_device *pdev)
> {
> struct bt_bmc *bt_bmc;
> struct device *dev;
> - struct resource *res;
> int rc;
>
> if (!pdev || !pdev->dev.of_node)
> @@ -431,10 +454,27 @@ static int bt_bmc_probe(struct platform_device *pdev)
>
> dev_set_drvdata(&pdev->dev, bt_bmc);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - bt_bmc->base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(bt_bmc->base))
> - return PTR_ERR(bt_bmc->base);
> + bt_bmc->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
> + if (IS_ERR(bt_bmc->map)) {
> + struct resource *res;
> + void __iomem *base;
> +
> + /*
> + * Assume it's not the MFD-based devicetree description, in
> + * which case generate a regmap ourselves
> + */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + bt_bmc->map = devm_regmap_init_mmio(dev, base, &bt_regmap_cfg);
> + bt_bmc->offset = 0;
> + } else {
> + rc = of_property_read_u32(dev->of_node, "reg", &bt_bmc->offset);
> + if (rc)
> + return rc;
> + }
>
> mutex_init(&bt_bmc->mutex);
> init_waitqueue_head(&bt_bmc->queue);
> @@ -461,12 +501,12 @@ static int bt_bmc_probe(struct platform_device *pdev)
> add_timer(&bt_bmc->poll_timer);
> }
>
> - iowrite32((BT_IO_BASE << BT_CR0_IO_BASE) |
> - (BT_IRQ << BT_CR0_IRQ) |
> - BT_CR0_EN_CLR_SLV_RDP |
> - BT_CR0_EN_CLR_SLV_WRP |
> - BT_CR0_ENABLE_IBT,
> - bt_bmc->base + BT_CR0);
> + regmap_write(bt_bmc->map, bt_bmc->offset + BT_CR0,
> + (BT_IO_BASE << BT_CR0_IO_BASE) |
> + (BT_IRQ << BT_CR0_IRQ) |
> + BT_CR0_EN_CLR_SLV_RDP |
> + BT_CR0_EN_CLR_SLV_WRP |
> + BT_CR0_ENABLE_IBT);
>
> clr_b_busy(bt_bmc);
>
>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6: Add Savageboard common file
From: Milo Kim @ 2016-12-06 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BzLc7Xr9G0hLP1O4aYx+7J5gy0VHdQ3Kz0GFq=WdQ1gw@mail.gmail.com>
On 12/05/2016 08:36 PM, Fabio Estevam wrote:
> On Sun, Dec 4, 2016 at 11:07 PM, Milo Kim <woogyom.kim@gmail.com> wrote:
>
>> + regulators {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + reg_3p3v: regulator at 0 {
>> + compatible = "regulator-fixed";
>> + reg = <0>;
>> + regulator-name = "3P3V";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + };
>
> Please remove the regulators container and put the regulator node
> directly as follows:
>
> reg_3p3v: regulator-3p3v {
> compatible = "regulator-fixed";
> regulator-name = "3P3V";
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> regulator-always-on;
> }
>
>> + };
>> +};
>> +
>> +&clks {
>> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
>> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
>> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
>> + <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
>> +};
>> +
>> +&fec {
>> + phy-mode = "rgmii";
>> + phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
>
> I think you meant
> phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
>
>> +&iomuxc {
>> + savageboard {
>> + pinctrl_emmc: emmcgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
>> + MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
>> + MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
>> + MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
>> + MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
>> + MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
>> + MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
>> + MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
>> + MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
>> + MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>> + >;
>> + };
>
> You can remove the savegeboard level. Please check
> arch/arm/boot/dts/imx6q-tbs2910.dts.
>
> iomux usually go as the last node of the dts file.
Thanks a lot for all your feedback. I just submitted the v2.
Best regards,
Milo
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: imx6: Support Savageboard quad
From: Milo Kim @ 2016-12-06 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206070829.24098-1-woogyom.kim@gmail.com>
Use common board file and support SATA interface additionally.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/imx6q-savageboard.dts | 54 +++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-savageboard.dts
diff --git a/arch/arm/boot/dts/imx6q-savageboard.dts b/arch/arm/boot/dts/imx6q-savageboard.dts
new file mode 100644
index 0000000..8d74002
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-savageboard.dts
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Quad";
+ compatible = "poslab,imx6q-savageboard", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: imx6: Support Savageboard dual
From: Milo Kim @ 2016-12-06 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206070829.24098-1-woogyom.kim@gmail.com>
Common savageboard DT file is used for board support.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
diff --git a/arch/arm/boot/dts/imx6dl-savageboard.dts b/arch/arm/boot/dts/imx6dl-savageboard.dts
new file mode 100644
index 0000000..2cac30d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-savageboard.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Dual";
+ compatible = "poslab,imx6dl-savageboard", "fsl,imx6dl";
+};
--
2.9.3
^ permalink raw reply related
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