* [PATCH v3 05/11] ARM: LPAE: provide an IPA capable pmd_addr_end
From: Christoffer Dall @ 2014-02-07 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207154401.GC5925@arm.com>
On Fri, Feb 07, 2014 at 03:44:01PM +0000, Catalin Marinas wrote:
> On Fri, Feb 07, 2014 at 04:04:56AM +0000, Christoffer Dall wrote:
> > On Thu, Feb 06, 2014 at 10:43:28AM +0000, Catalin Marinas wrote:
> > > On Wed, Feb 05, 2014 at 07:55:45PM +0000, Marc Zyngier wrote:
> > > > The default pmd_addr_end macro uses an unsigned long to represent
> > > > the VA. When used with KVM and stage-2 translation, the VA is
> > > > actually an IPA, which is up to 40 bits. This also affect the
> > > > SMMU driver, which also deals with stage-2 translation.
> > > >
> > > > Instead, provide an implementation that can cope with larger VAs
> > > > by using a u64 instead. This version will overload the default
> > > > one provided in include/asm-generic/pgtable.h.
> > > >
> > > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > > > ---
> > > > arch/arm/include/asm/pgtable-3level.h | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
> > > > index 03243f7..594867b 100644
> > > > --- a/arch/arm/include/asm/pgtable-3level.h
> > > > +++ b/arch/arm/include/asm/pgtable-3level.h
> > > > @@ -262,6 +262,11 @@ static inline int has_transparent_hugepage(void)
> > > > return 1;
> > > > }
> > > >
> > > > +#define pmd_addr_end(addr, end) \
> > > > +({ u64 __boundary = ((addr) + PMD_SIZE) & PMD_MASK; \
> > > > + (__boundary - 1 < (end) - 1)? __boundary: (end); \
> > > > +})
> > >
> > > I see why you need this but it affects all the other uses of
> > > pmd_addr_end() with 32-bit VA. It would be slight performance, I don't
> > > think it's noticeable.
> > >
> > > A different approach could be something like (untested):
> > >
> > > #define pmd_addr_end(addr, end) \
> > > ({ __typeof__(addr) __boundary = ...
> > > ...
> > > })
> > >
> > > What about the pgd_addr_end(), do we need this or it's not used by KVM?
> > >
> >
> > What about pud_addr_end(), is that defined as a noop on LPAE, or?
> >
> > I would be in favor of introducing them all using your approach to avoid
> > somebody being inspired by the KVM code when dealing with IPAs and
> > breaking things unknowingly.
>
> I had a brief chat with Marc yesterday around this and it may be safer
> to simply introduce kvm_p*d_addr_end() macros. You already do this for
> pgd_addr_end() since it cannot be overridden in the generic headers.
>
Sounds good to me. We should introduce all of them then.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
From: Jean-Francois Moine @ 2014-02-07 17:11 UTC (permalink / raw)
To: linux-arm-kernel
This patch series tries to simplify the code of simple devices in case
they are part of componentised subsystems, are declared in a DT, and
are not using the component bin/unbind functions.
Jean-Francois Moine (2):
drivers/base: permit base components to omit the bind/unbind ops
drivers/base: declare phandle DT nodes as components
drivers/base/component.c | 21 +++++++++++++++++++--
drivers/base/core.c | 18 ++++++++++++++++++
include/linux/of.h | 2 ++
3 files changed, 39 insertions(+), 2 deletions(-)
--
1.9.rc1
^ permalink raw reply
* [PATCH v2] ARM: at91: add Atmel's SAMA5D3 Xplained board
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-02-07 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F4EFA4.6070205@atmel.com>
On 15:37 Fri 07 Feb , Nicolas Ferre wrote:
> On 07/02/2014 09:01, Jean-Christophe PLAGNIOL-VILLARD :
> > On 09:35 Wed 05 Feb , Nicolas Ferre wrote:
> >> Add DT file for new SAMA5D3 Xpained board.
> >> This board is based on Atmel's SAMA5D36 Cortex-A5 SoC.
> >>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >> ---
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 233 ++++++++++++++++++++++++++++
> >> 2 files changed, 234 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index b9d6a8b485e0..6d1e43d46187 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -38,6 +38,7 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9g35ek.dtb
> >> dtb-$(CONFIG_ARCH_AT91) += at91sam9x25ek.dtb
> >> dtb-$(CONFIG_ARCH_AT91) += at91sam9x35ek.dtb
> >> # sama5d3
> >> +dtb-$(CONFIG_ARCH_AT91) += at91-sama5d3_xplained.dtb
> >> dtb-$(CONFIG_ARCH_AT91) += sama5d31ek.dtb
> >> dtb-$(CONFIG_ARCH_AT91) += sama5d33ek.dtb
> >> dtb-$(CONFIG_ARCH_AT91) += sama5d34ek.dtb
> >> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> >> new file mode 100644
> >> index 000000000000..fb1349ca60a4
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> >> @@ -0,0 +1,233 @@
> >> +/*
> >> + * at91-sama5d3_xplained.dts - Device Tree file for the SAMA5D3 Xplained board
> >> + *
> >> + * Copyright (C) 2014 Atmel,
> >> + * 2014 Nicolas Ferre <nicolas.ferre@atmel.com>
> >> + *
> >> + * Licensed under GPLv2 or later.
> >> + */
> >> +/dts-v1/;
> >> +#include "sama5d36.dtsi"
> >> +
> >> +/ {
> >> + model = "SAMA5D3 Xplained";
> >> + compatible = "atmel,sama5d3-xplained", "atmel,sama5d3", "atmel,sama5";
> >> +
> >> + chosen {
> >> + bootargs = "console=ttyS0,115200";
> > can you describe it via linux,stdout
>
> Well I would have liked, but the code in the serial driver is not there yet.
> So, I keep it like this for the moment.
>
> >> + };
> >> +
> >> + memory {
> >> + reg = <0x20000000 0x10000000>;
> >> + };
> >> +
> >> + ahb {
> >> + apb {
> >> + mmc0: mmc at f0000000 {
> >> + pinc?trl-names = "default";
> > ?? this is SoC should never been seen here
this need to move to dtsi not here
> >> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_dat4_7 &pinctrl_mmc0_cd>;
> >> + status = "okay";
> >> + slot at 0 {
> >> + reg = <0>;
> >> + bus-width = <8>;
> >> + cd-gpios = <&pioE 0 GPIO_ACTIVE_LOW>;
> >> + };
> >> + };
> >> +
> >> + spi0: spi at f0004000 {
> >> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> > if you use only one CS no need to specified all
> >
> > we need to add macro per SoC for the hw CS used as GPIO so it's more clear
>
> No, I do not think so.
yes as you dopy &pioD 13 0 everywhere instead of doing
#define SAMA5D3_SPI_CS0_GPIO &pioD 13 GPIO_ACTIVE_LOW
and then
cs-gpios = <SAMA5D3_SPI_CS0_GPIO>;
and drop the
, <0>, <0>, <0>;
> >> + status = "okay";
> >> + };
> >> +
> >> + can0: can at f000c000 {
> >> + status = "okay";
> >> + };
> >> +
> >> + i2c0: i2c at f0014000 {
> >> + status = "okay";
> >> + };
> >> +
> >> + i2c1: i2c at f0018000 {
> >> + status = "okay";
> >> + };
> >> +
> >> + macb0: ethernet at f0028000 {
> >> + phy-mode = "rgmii";
> >> + status = "okay";
> >> + };
> >> +
> >> + usart0: serial at f001c000 {
> >> + status = "okay";
> >> + };
> >> +
> >> + usart1: serial at f0020000 {
> >> + pinctrl-names = "default";
> > same as mmc
> >> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> >> + status = "okay";
> >> + };
> >> +
> >> + uart0: serial at f0024000 {
> >> + status = "okay";
> >> + };
> >> +
> >> + mmc1: mmc at f8000000 {
> >> + pinctrl-names = "default";
> > ditto
> >> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> >> + status = "okay";
> >> + slot at 0 {
> >> + reg = <0>;
> >> + bus-width = <4>;
> >> + cd-gpios = <&pioE 1 GPIO_ACTIVE_HIGH>;
> >> + };
> >> + };
> >> +
> >> + spi1: spi at f8008000 {
> >> + cs-gpios = <&pioC 25 0>, <0>, <0>, <&pioD 16 0>;
> >> + status = "okay";
> >> + };
> >> +
> >> + adc0: adc at f8018000 {
> >> + pinctrl-names = "default";
> > ditto
> >> + pinctrl-0 = <
> >> + &pinctrl_adc0_adtrg
> >> + &pinctrl_adc0_ad0
> >> + &pinctrl_adc0_ad1
> >> + &pinctrl_adc0_ad2
> >> + &pinctrl_adc0_ad3
> >> + &pinctrl_adc0_ad4
> >> + &pinctrl_adc0_ad5
> >> + &pinctrl_adc0_ad6
> >> + &pinctrl_adc0_ad7
> >> + &pinctrl_adc0_ad8
> >> + &pinctrl_adc0_ad9
> >> + >;
> >> + status = "okay";
> >> + };
> >> +
> >> + i2c2: i2c at f801c000 {
> >> + dmas = <0>, <0>; /* Do not use DMA for i2c2 */
> > why?
>
> Because we use the channels for other peripherals
>
> >> + status = "okay";
> >> + };
> >> +
> >> + macb1: ethernet at f802c000 {
> >> + phy-mode = "rmii";
> >> + status = "okay";
> >> + };
> >> +
> >> + dbgu: serial at ffffee00 {
> >> + status = "okay";
> >> + };
> >> +
> >> + pinctrl at fffff200 {
> >> + board {
> >> + pinctrl_mmc0_cd: mmc0_cd {
> >> + atmel,pins =
> >> + <AT91_PIOE 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> >> + };
> >> +
> >> + pinctrl_mmc1_cd: mmc1_cd {
> >> + atmel,pins =
> >> + <AT91_PIOE 1 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> >> + };
> >> +
> >> + pinctrl_usba_vbus: usba_vbus {
> >> + atmel,pins =
> >> + <AT91_PIOE 9 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PE9, conflicts with A9 */
> > in this case we should have ifdef so we could choose what we want via make
> > file
>
> No, we choose by modifying the DTS.
exactly what I've said describe it via ifdef in the dts
>
> >> + };
> >> + };
> >> + };
> >> +
> >> + pmc: pmc at fffffc00 {
> >> + main: mainck {
> >> + clock-frequency = <12000000>;
> >> + };
> >> + };
> >> + };
> >> +
> >> + nand0: nand at 60000000 {
> >> + nand-bus-width = <8>;
> >> + nand-ecc-mode = "hw";
> >> + atmel,has-pmecc;
> >> + atmel,pmecc-cap = <4>;
> >> + atmel,pmecc-sector-size = <512>;
> >> + nand-on-flash-bbt;
> >> + status = "okay";
> >> +
> >> + at91bootstrap at 0 {
> >> + label = "at91bootstrap";
> >> + reg = <0x0 0x40000>;
> >> + };
> >> +
> >> + bootloader at 40000 {
> >> + label = "bootloader";
> >> + reg = <0x40000 0x80000>;
> >> + };
> >> +
> >> + bootloaderenv at c0000 {
> >> + label = "bootloader env";
> >> + reg = <0xc0000 0xc0000>;
> >> + };
> >> +
> >> + dtb at 180000 {
> >> + label = "device tree";
> >> + reg = <0x180000 0x80000>;
> >> + };
> >> +
> >> + kernel at 200000 {
> >> + label = "kernel";
> >> + reg = <0x200000 0x600000>;
> >> + };
> >> +
> >> + rootfs at 800000 {
> >> + label = "rootfs";
> >> + reg = <0x800000 0x0f800000>;
> >> + };
> > more I read this partition more it's seems wrong those days
> >
> > we really need to switch to UBI
>
> I am using UBI with this layout.
so put the kernel & dts on UBI to have wareleveling on it too
and then we do not need to knwown the kernel/rootfs/dtc partition size and
position
>
> >> + };
> >> +
> >> + usb0: gadget at 00500000 {
> >> + atmel,vbus-gpio = <&pioE 9 GPIO_ACTIVE_HIGH>; /* PE9, conflicts with A9 */
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&pinctrl_usba_vbus>;
> >> + status = "okay";
> >> + };
> >> +
> >> + usb1: ohci at 00600000 {
> >> + num-ports = <3>;
> >> + atmel,vbus-gpio = <0
> >> + &pioE 3 GPIO_ACTIVE_LOW
> >> + &pioE 4 GPIO_ACTIVE_LOW
> >> + >;
> >> + status = "okay";
> >> + };
> >> +
> >> + usb2: ehci at 00700000 {
> >> + status = "okay";
> >> + };
> >> + };
> >> +
> >> + gpio_keys {
> >> + compatible = "gpio-keys";
> >> +
> >> + bp3 {
> >> + label = "PB_USER";
> >> + gpios = <&pioE 29 GPIO_ACTIVE_LOW>;
> >> + linux,code = <0x104>;
> >> + gpio-key,wakeup;
> >> + };
> >> + };
> >> +
> >> + leds {
> >> + compatible = "gpio-leds";
> >> +
> >> + d2 {
> >> + label = "d2";
> >> + gpios = <&pioE 23 GPIO_ACTIVE_LOW>; /* PE23, conflicts with A23, CTS2 */
> >> + linux,default-trigger = "heartbeat";
> >> + };
> >> +
> >> + d3 {
> >> + label = "d3";
> >> + gpios = <&pioE 24 GPIO_ACTIVE_HIGH>;
> >> + };
> >> + };
> >> +};
> >> --
> >> 1.8.2.2
> >>
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.14 #1
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-02-07 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391790986-31936-1-git-send-email-nicolas.ferre@atmel.com>
On 17:36 Fri 07 Feb , Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
>
> This is a first "fixes" series for AT91 on 3.14.
> The content is only DT-related and quite boring.
> I took the opportunity of this early "fixes" pull-request to collect
> some Documentation patches that were lying around and I guess that
> they can be merged by arm-soc nicely (addition of CCF to 2 drivers).
> A new board is added to the lot because it is dead simple and integrates
> well with the new sama5d36 SoC that we added earlier in this development cycle.
>
> Thanks, best regards,
>
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>
> Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>
> are available in the git repository at:
>
> git://github.com/at91linux/linux-at91.git tags/at91-fixes
>
> for you to fetch changes up to b7c2b6157079811586180d13c44a1095b57c2d47:
>
> ARM: at91: add Atmel's SAMA5D3 Xplained board (2014-02-07 17:20:39 +0100)
>
> ----------------------------------------------------------------
> First series of AT91 fixes for 3.14.
> All of them are DT-related.
> - fixes for typos in i2c and ohci clocks
> - addition of a USB host node for at91sam9n12ek
> - 2 DT documentation updates that have been sent a long time ago
> - a new board based on the sama5d36 SoC
>
> ----------------------------------------------------------------
> Bo Shen (1):
> ARM: at91: enable USB host on at91sam9n12ek board
>
> Boris BREZILLON (3):
> ARM: at91/dt: fix sama5d3 ohci hclk clock reference
> mmc: atmel-mci: document clock properties
> spi/atmel: document clock properties
>
> Jean-Jacques Hiblot (1):
> ARM: at91/dt: sam9263: fix compatibility string for the I2C
>
> Nicolas Ferre (1):
> ARM: at91: add Atmel's SAMA5D3 Xplained board
still comment on it please drop it on the PULL
Best Regards,
J.
>
> .../devicetree/bindings/mmc/atmel-hsmci.txt | 5 +
> .../devicetree/bindings/spi/spi_atmel.txt | 5 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 229 +++++++++++++++++++++
> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9n12ek.dts | 4 +
> arch/arm/boot/dts/sama5d3.dtsi | 2 +-
> 7 files changed, 246 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/at91-sama5d3_xplained.dts
>
> --
> Nicolas Ferre
^ permalink raw reply
* [PATCH] dma-buf: avoid using IS_ERR_OR_NULL
From: Colin Cross @ 2014-02-07 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207164313.GA32655@kroah.com>
On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
>> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross <ccross@android.com> wrote:
>> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
>> > ERR_PTR on a error. This encourages a common buggy pattern in
>> > callers:
>> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
>> > if (IS_ERR_OR_NULL(sgt))
>> > return PTR_ERR(sgt);
>> >
>> > This causes the caller to return 0 on an error. IS_ERR_OR_NULL
>> > is almost always a sign of poorly-defined error handling.
>> >
>> > This patch converts dma_buf_map_attachment to always return
>> > ERR_PTR, and fixes the callers that incorrectly handled NULL.
>> > There are a few more callers that were not checking for NULL
>> > at all, which would have dereferenced a NULL pointer later.
>> > There are also a few more callers that correctly handled NULL
>> > and ERR_PTR differently, I left those alone but they could also
>> > be modified to delete the NULL check.
>> >
>> > This patch also converts dma_buf_vmap to always return NULL.
>> > All the callers to dma_buf_vmap only check for NULL, and would
>> > have dereferenced an ERR_PTR and panic'd if one was ever
>> > returned. This is not consistent with the rest of the dma buf
>> > APIs, but matches the expectations of all of the callers.
>> >
>> > Signed-off-by: Colin Cross <ccross@android.com>
>> > ---
>> > drivers/base/dma-buf.c | 18 +++++++++++-------
>> > drivers/gpu/drm/drm_prime.c | 2 +-
>> > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
>> > drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
>> > 4 files changed, 14 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
>> > index 1e16cbd61da2..cfe1d8bc7bb8 100644
>> > --- a/drivers/base/dma-buf.c
>> > +++ b/drivers/base/dma-buf.c
>> > @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>> > * @dmabuf: [in] buffer to attach device to.
>> > * @dev: [in] device to be attached.
>> > *
>> > - * Returns struct dma_buf_attachment * for this attachment; may return negative
>> > - * error codes.
>> > - *
>> > + * Returns struct dma_buf_attachment * for this attachment; returns ERR_PTR on
>> > + * error.
>> > */
>> > struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>> > struct device *dev)
>> > @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
>> > * @attach: [in] attachment whose scatterlist is to be returned
>> > * @direction: [in] direction of DMA transfer
>> > *
>> > - * Returns sg_table containing the scatterlist to be returned; may return NULL
>> > - * or ERR_PTR.
>> > - *
>> > + * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
>> > + * on error.
>> > */
>> > struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>> > enum dma_data_direction direction)
>> > @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
>> > return ERR_PTR(-EINVAL);
>> >
>> > sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>> > + if (!sg_table)
>> > + sg_table = ERR_PTR(-ENOMEM);
>> >
>> > return sg_table;
>> > }
>> > @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
>> > * These calls are optional in drivers. The intended use for them
>> > * is for mapping objects linear in kernel space for high use objects.
>> > * Please attempt to use kmap/kunmap before thinking about these interfaces.
>> > + *
>> > + * Returns NULL on error.
>> > */
>> > void *dma_buf_vmap(struct dma_buf *dmabuf)
>> > {
>> > @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
>> > BUG_ON(dmabuf->vmap_ptr);
>> >
>> > ptr = dmabuf->ops->vmap(dmabuf);
>> > - if (IS_ERR_OR_NULL(ptr))
>> > + if (WARN_ON_ONCE(IS_ERR(ptr)))
>>
>> since vmap is optional, the WARN_ON might be a bit strong.. although
>> it would be a bit strange for an exporter to supply a vmap fxn which
>> always returned NULL, not sure about that. Just thought I'd mention
>> it in case anyone else had an opinion about that.
>
> Yeah, I don't like this, it could cause unnecessary reports of problems.
The WARN_ON_ONCE is only if the vmap op returns ERR_PTR, not if it
returns NULL. This is designed to catch vmap ops that don't follow
the spec, so I would call them necessary reports, but I can take it
out if you still disagree.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH] irq: Add new flag to ack level-triggered interrupts before unmasking
From: Thomas Gleixner @ 2014-02-07 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOQ7t2b5qVTUXOB4iWAOoTehm=u6zxP0-zQmirSF0DvEk8KddQ@mail.gmail.com>
On Fri, 7 Feb 2014, Carlo Caione wrote:
> Yeah, no really difference between threaded and non threaded.
> For the record, from a mail exchange with Allwinner's engineers: "the
> NMI module is a signal conversion module. It catches the NMI pin's
> state and generates irq to GIC", so GIC does not really ACK anything.
> BTW being a dummy "signal conversion module" this is probably why I
> still need to clear the pending status even though my IRQ line has
> already been cleared.
A pretty useless signal conversion module it seems creating a big mess
for a single interrupt line :)
> > I'm not against having a flag, but this should be done less convoluted
> > and have proper names which make the use case clear along with a good
> > technical explanation of the flag in the comment.
>
> Ok, at this point do you think that a patch in the core could be
> useful or is it better to stick with modifying the unmask callback?
Not sure, really, but I tend to a core patch. Though we really want to
know whether the issue is threaded only or not. If it's a general
issue then this wants to go into unmask_irq() itself and not into an
extra unmask_threaded_irq() function.
Thanks,
tglx
^ permalink raw reply
* [PATCH v3 0/2] *** SUBJECT HERE ***
From: Greg Kroah-Hartman @ 2014-02-07 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391792986.git.moinejf@free.fr>
On Fri, Feb 07, 2014 at 06:09:46PM +0100, Jean-Francois Moine wrote:
> *** BLURB HERE ***
Subject and BLURB forgotten?
^ permalink raw reply
* [PATCH 21/21] ARM: Kirkwood: Remove DT support
From: Sebastian Hesselbarth @ 2014-02-07 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207151522.GZ8533@titan.lakedaemon.net>
On 02/07/2014 04:15 PM, Jason Cooper wrote:
> On Fri, Feb 07, 2014 at 04:09:54PM +0100, Thomas Petazzoni wrote:
>> On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote:
>>> If we want something leaner than multi_v7, how about
>>> armada_370-xp_defconfig to replace the current mvebu_defconfig?
>>
>> Doesn't work for me: we're going to introduce soon the support for
>> other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should
>> be built as part of this.
>>
>> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both
>> Dove and Armada 370/XP (and the other ones we are going to introduce
>> soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find
>> enough time to work on this platform).
>
> Yeah, I can go with that, as long as Sebastian doesn't see a need for a
> separate dove_defconfig in the long term (DT only). Sebastian?
Nope, I have no plans to keep a special dove_defconfig for Dove in
mach-mvebu.
>> This way, ultimately we can simply remove kirkwood_defconfig and
>> dove_defconfig, as soon as all legacy platforms have been either
>> converted to DT, or removed.
>
> Yep, the fewer builds I have to do per patch submission, the better.
Sounds good to me.
Sebastian
^ permalink raw reply
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-07 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6raZY0sKdDn4d92SKpi=eqUpf23vW8K_bEi-v62V2jdPA@mail.gmail.com>
On 07/02/14 16:43, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 16:15, Sudeep Holla wrote:
>>> On 07/02/14 15:19, Thomas Abraham wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Add a new optional boost-frequency binding for specifying the frequencies
>>>> usable in boost mode.
>>>>
>>>> Cc: Nishanth Menon <nm@ti.com>
>>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>>> ---
>>>> Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> new file mode 100644
>>>> index 0000000..d925e38
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> @@ -0,0 +1,11 @@
>>>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>>>> +
>>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>>>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>>>> +operating conditions.
>>>> +
>>>> +Optional Properties:
>>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>>>> + This list should be a subset of frequencies listed in "operating-points"
>>>> + property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>>>> + details about "operating-points" property.
>>>>
>>>
>>> Won't single entry for boost frequency suffice which would be the starting
>>> frequency in the boost range. IOW will there be OPP list with frequencies:
>>> A > B > C > D, but only B and C are boost frequency. That seems little odd,
>>> unless it's some configuration chosen purely on software basis rather than
>>> hardware. For me B marks the beginning of over-clocking.
>>>
>> Ah, I meant A < B < C < D in the above example.
>
> Should'nt we let the SoC dts define that - traditionally, yes, but
> consider the following:
> A, B, C uses clk_parent X which describes B, C as overclocked.
> and say D uses clk_parent Y which is not "over clocked", then you have
> the scenario that on the first look seems counter-intutive.
>
Yes I thought of exactly similar clock setup, but was not convinced that it
should be part of OPP. In that case it looks like we are trying to represent
clock internals through some OPP bindings.
Yes I think its counter-intuitive as it's visible to the userspace(list of
frequencies and the boost parameters are exposed through sysfs)
Regards,
Sudeep
^ permalink raw reply
* [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
From: Russell King - ARM Linux @ 2014-02-07 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391793068.git.moinejf@free.fr>
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> This patch series tries to simplify the code of simple devices in case
> they are part of componentised subsystems, are declared in a DT, and
> are not using the component bin/unbind functions.
I wonder - I said earlier today that this works absolutely fine without
modification with DT, so why are you messing about with it adding DT
support?
This is totally the wrong approach. The idea is that this deals with
/devices/ and /devices/ only. It groups up /devices/.
It's up to the add_component callback to the master device to decide
how to deal with that.
> Jean-Francois Moine (2):
> drivers/base: permit base components to omit the bind/unbind ops
And this patch has me wondering if you even understand how to use
this... The master bind/unbind callbacks are the ones which establish
the "card" based context with the subsystem.
Please, before buggering up this nicely designed implementation, please
/first/ look at the imx-drm rework which was posted back in early January
which illustrates how this is used in a DT context - which is something
I've already pointed you at once today already.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [GIT PULL] arm64 fixes for 3.14
From: Catalin Marinas @ 2014-02-07 17:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 fixes below for 3.14. Thanks.
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to 55834a773fe343912b705bef8114ec93fd337188:
arm64: defconfig: Expand default enabled features (2014-02-07 17:17:28 +0000)
----------------------------------------------------------------
- Relax VDSO alignment requirements so that the kernel-picked one (4K)
does not conflict with the dynamic linker's one (64K)
- VDSO gettimeofday fix
- Barrier fixes for atomic operations and cache flushing
- TLB invalidation when overriding early page mappings during boot
- Wired up new 32-bit arm (compat) syscalls
- LSM_MMAP_MIN_ADDR when COMPAT is enabled
- defconfig update
- Clean-up (comments, pgd_alloc).
----------------------------------------------------------------
Catalin Marinas (2):
arm64: Invalidate the TLB when replacing pmd entries during boot
arm64: compat: Wire up new AArch32 syscalls
Colin Cross (1):
security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
Laura Abbott (1):
arm64: Align CMA sizes to PAGE_SIZE
Mark Rutland (3):
arm64: fix typo: s/SERRROR/SERROR/
arm64: simplify pgd_alloc
arm64: defconfig: Expand default enabled features
Nathan Lynch (2):
arm64: vdso: fix coarse clock handling
arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE
Vinayak Kale (1):
arm64: add DSB after icache flush in __flush_icache_all()
Will Deacon (4):
arm64: vdso: prevent ld from aligning PT_LOAD segments to 64k
arm64: barriers: allow dsb macro to take option parameter
arm64: atomics: fix use of acquire + release for full barrier semantics
arm64: asm: remove redundant "cc" clobbers
arch/arm64/Kconfig | 1 +
arch/arm64/configs/defconfig | 18 +++++++++---
arch/arm64/include/asm/atomic.h | 53 ++++++++++++++++++++---------------
arch/arm64/include/asm/barrier.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 1 +
arch/arm64/include/asm/cmpxchg.h | 17 +++++------
arch/arm64/include/asm/esr.h | 2 +-
arch/arm64/include/asm/futex.h | 10 ++++---
arch/arm64/include/asm/kvm_arm.h | 2 +-
arch/arm64/include/asm/spinlock.h | 10 +++----
arch/arm64/include/asm/unistd32.h | 5 +++-
arch/arm64/kernel/kuser32.S | 6 ++--
arch/arm64/kernel/vdso.c | 4 +--
arch/arm64/kernel/vdso/Makefile | 2 +-
arch/arm64/kernel/vdso/gettimeofday.S | 7 ++++-
arch/arm64/lib/bitops.S | 3 +-
arch/arm64/mm/dma-mapping.c | 1 +
arch/arm64/mm/mmu.c | 12 ++++++--
arch/arm64/mm/pgd.c | 11 ++------
security/Kconfig | 2 +-
20 files changed, 102 insertions(+), 67 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH RFC 1/2] drivers/base: permit base components to omit the bind/unbind ops
From: Russell King - ARM Linux @ 2014-02-07 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9b3c3c2c982f31b026fd1516a2b608026d55b1e9.1391793068.git.moinejf@free.fr>
On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
> Some simple components don't need to do any specific action on
> bind to / unbind from a master component.
>
> This patch permits such components to omit the bind/unbind
> operations.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/base/component.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index c53efe6..0a39d7a 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
> {
> WARN_ON(!component->bound);
>
> - component->ops->unbind(component->dev, master->dev, data);
> + if (component->ops)
> + component->ops->unbind(component->dev, master->dev, data);
> component->bound = false;
>
> /* Release all resources claimed in the binding of this component */
> @@ -274,7 +275,11 @@ static int component_bind(struct component *component, struct master *master,
> dev_dbg(master->dev, "binding %s (ops %ps)\n",
> dev_name(component->dev), component->ops);
>
> - ret = component->ops->bind(component->dev, master->dev, data);
> + if (component->ops)
> + ret = component->ops->bind(component->dev, master->dev, data);
> + else
> + ret = 0;
> +
NAK. If this is done, there's absolutely no point to this code.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 21/21] ARM: Kirkwood: Remove DT support
From: Sebastian Hesselbarth @ 2014-02-07 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391730137-14814-22-git-send-email-andrew@lunn.ch>
On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> Now that all the device tree support is in mach-mvebu, remove it from
> mach-kirkwood.
>
> Regenerate kirkwood_defconfig, removing all DT support, and a couple
> of other redundent options have been removed in the process.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
Hmm, I wonder what Ian thinks of removing this so quickly again...
Maybe let it rot for 1-2 kernel versions?
Sebastian
^ permalink raw reply
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Nishanth Menon @ 2014-02-07 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F51888.5010608@arm.com>
On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> Yes I thought of exactly similar clock setup, but was not convinced that it
> should be part of OPP. In that case it looks like we are trying to represent
> clock internals through some OPP bindings.
And this series (rightly) does not make it an OPP behavior. instead
all it does is to list the boost-frequencies and mark those in cpufreq
table. the description is left to the dts and implementation to the
clock drivers involved.
> Yes I think its counter-intuitive as it's visible to the userspace(list of
> frequencies and the boost parameters are exposed through sysfs)
That will be a different problem -> as currently every single
frequency in the cpufreq list has ability to be marked as boost
frequency - if userspace does not maintain that, then, IMHO, fix the
userspace :D
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Nishanth Menon @ 2014-02-07 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6ofC4NNPiTNcSnXUvT3RZJo54=XyjetR-ok5hCBrVZkKg@mail.gmail.com>
On Fri, Feb 7, 2014 at 11:37 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> Yes I thought of exactly similar clock setup, but was not convinced that it
>> should be part of OPP. In that case it looks like we are trying to represent
>> clock internals through some OPP bindings.
>
> And this series (rightly) does not make it an OPP behavior. instead
> all it does is to list the boost-frequencies and mark those in cpufreq
> table. the description is left to the dts and implementation to the
> clock drivers involved.
One more thing, before I forget -> currently
dev_pm_opp_[init|free]_cpufreq_table is in drivers/base/power/opp.c ->
this probably should go away to drivers/cpufreq to keep opp.c
independent of frameworks using it. i dont see any code that is
introduced in the mentioned functions as being OPP behavior specific,
instead, I consider them as cpufreq+opp behaviors, which this change
fits into.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v6 05/19] watchdog: orion: Make sure the watchdog is initially stopped
From: Jason Gunthorpe @ 2014-02-07 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207104044.GA11063@localhost>
On Fri, Feb 07, 2014 at 07:40:45AM -0300, Ezequiel Garcia wrote:
> Well, this is related to the discussion about the bootloader not
> reseting the watchdog properly, provoking spurious watchdog triggering.
>
> Jason Gunthorpe explained [1] that we needed a particular sequence:
>
> 1. Disable WDT
> 2. Clear bridge
> 3. Enable WDT
>
> We added the irq handling to satisfy (2), and the watchdog stop for (1).
The issue here is the driver configures two 'machine kill' elements:
the PANIC IRQ and the RstOut setup.
Before configuring either of those the driver needs to ensure that any
old watchdog events are cleared out of the HW. We must not get a
spurious event.
I agree not disabling an already functional and properly configured
counter from the bootloader is desirable.
So lets break it down a bit..
1) The IRQ:
It looks like the cause bit latches high on watchdog timer
expiration but has no side effect unless it is unmasked.
The new IRQ flow code ensures the bit is cleared during request_irq
so no old events can trigger the IRQ. Thus it is solved now.
2) The RstOut:
It is a bit unspecific, but I think this signal latches high when
any unmasked rst event occurs and stays high until the RstIn pin
is asserted.
So we don't need to worry about clearing old events from here
Alternatively the WDRstOutEn routes the Cause bit into the RstOut
pin.
3) The timer itself:
The WDT is just a general timer with an optional hookup to the
rst control. If it is harmlessly counting but not resetting we need
to stop that before enabling rst out.
So, how about this for psuedo-code in probe:
if (readl(RSTOUTn) & WDRstOutEn)
{
/* Watchdog is configured and may be down counting,
don't touch it */
request_irq(..);
}
else
{
/* Watchdog is not configured, fully disable the timer
and configure for watchdog operation. */
disable_watchdog();
request_irq();
writel(RSTOUTn), .. WDRstOutEn);
}
Jason
^ permalink raw reply
* [PATCH RFC 2/2] drivers/base: declare phandle DT nodes as components
From: Russell King - ARM Linux @ 2014-02-07 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f8bbe28b00160cab2cedffa3f8fb42121035964.1391793068.git.moinejf@free.fr>
On Fri, Feb 07, 2014 at 05:53:27PM +0100, Jean-Francois Moine wrote:
> At system startup time, some devices depends on the availability of
> some other devices before starting. The infrastructure for componentised
> subsystems permits to handle this dependence, each driver defining
> its own role.
>
> This patch does an automatic creation of the lowest components in
> case of DT. This permits simple devices to be part of complex
> componentised subsystems without any specific code.
A component with no operations makes precisely no sense - with that,
there's no way for the component to be a stand-alone driver. Your
approach forces your ideas onto every DT device that is referenced
as a phandle. That's extremely restrictive.
I don't want the component stuff knowing anything about OF. I don't
want it knowing about driver matching. I don't want it knowing about
ACPI either. That's the whole point behind it - it is 100% agnostic
about how that stuff works.
The model is quite simply this:
- a master device is the covering component for the "card"
- the master device knows what components to expect by some means.
In the case of DT, that's by phandle references to the components.
- the master device handles the component independent setup of the
"card", creating the common resources that are required. When it's
ready, it asks for the components to be bound.
- upon removal of any component, the master component is unbound,
which triggers the removal of the "card" from the subsystem.
- as part of the removal, sub-components are unbound.
- the master device should have as /little/ knowledge about the
components as possible to permit component re-use.
- a component driver should be independent of it's master.
- A component which is probed from the device model should simply
register itself using component_add() with an appropriate operations
structure, and a removal function which deletes itself.
- When the driver is ready to be initialised (when the "card" level
resources have been set in place) the "bind" method will be called.
At this point, the component does everything that a classical driver
model driver would do in it's probe callback.
- unbind is the same as remove in the classical driver model.
So, please, no DT stuff in the component support - it's simply not
required.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Jason Gunthorpe @ 2014-02-07 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207114607.GE5976@mudshark.cambridge.arm.com>
On Fri, Feb 07, 2014 at 11:46:07AM +0000, Will Deacon wrote:
> > In practice, there can be various ways that a system requires something
> > more complex:
> >
> > * You can have a memory space range that puts PCI bus address zero
> > at the start of the pci->mem resource. In this case, you have
> > mem_offset = pci->mem.start. We should probably try not to do
> > this, but there is existing hardware doing it.
>
> If it's not the common case, then the generic driver might not need to care
> (at least, initially).
Something to think about, other people are going to reference this
driver when writing drivers for their own hardware, it would be nice
to see it perfect..
AFAIK, the job is fairly simple, when you call pci_add_resource_offset
for memory compute the offset from
of_pci_range.pci_addr - of_pci_range.cpu_addr
(or is it the other way around ?)
And when you do it for IO then you compute the offset between the
requested io mapping base to the pci_addr.
> > * You might have multiple sections of the PCI bus space mapped
> > into CPU physical space. If you want to support legacy VGA
> > console, you probably want to map the first 16MB of the bus
> > space at an arbitrary location (with the mem_offset as above),
> > plus a second, larger section of the bus space with an identity
> > mapping (mem_offset_= 0) for all devices other than VGA.
> > You'd also need to copy some VGA specific code from arm32 to
> > arm64 to actually make this work.
>
> Again, I'd rather cross that bridge (no pun intended) when we decide we want
> legacy VGA.
Fortuantely if you compute the offset directly from the DT then you
don't need to do anything more. If someone wants to use this
arrangement then they just have to setup the HW and write a proper DT
with two ranges lines for memory and everything should just work.
> Okey doke, is anybody working on that? (I see the follow up from
> Jason, but it's not clear whether that's going to be merged).
Nope, just a thought to stimulate discussion :)
Regards,
Jason
^ permalink raw reply
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-07 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6ofC4NNPiTNcSnXUvT3RZJo54=XyjetR-ok5hCBrVZkKg@mail.gmail.com>
On 07/02/14 17:37, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
[...]
>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>> frequencies and the boost parameters are exposed through sysfs)
>
> That will be a different problem -> as currently every single
> frequency in the cpufreq list has ability to be marked as boost
> frequency - if userspace does not maintain that, then, IMHO, fix the
> userspace :D
>
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
the list of frequencies based on the state of the boost feature at anytime.
Intuitively the list without boost shouldn't have any frequency above the range
when it's enabled :), that's what I was referring to. So I am not talking about
any issue with user-space maintenance.
Regards,
Sudeep
^ permalink raw reply
* [GIT PULL] irqchip: dove: drivers for v3.14
From: Jason Cooper @ 2014-02-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1402042230230.24986@ionos.tec.linutronix.de>
On Tue, Feb 04, 2014 at 10:30:53PM +0100, Thomas Gleixner wrote:
> On Tue, 4 Feb 2014, Jason Cooper wrote:
>
> > On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote:
> > > On Tue, 28 Jan 2014, Jason Cooper wrote:
> > > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting
> > > > near to the end of the merge window and there's been no activity on this
> > > > pull request.
> > > >
> > > > Please let us know if there's anything we can do to assist.
> > >
> > > Nah. I simply forgot about it. About to send a pull request to Linus.
> >
> > hmmm. I see the pull request contains the patches from
> > mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip
> > (dove):
> >
> > 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller.
> >
> > which is what this thread was originally a pull request for.
> >
> >
> > Are you planning to send a second pull request to Linus?
>
> Duh. I'll pick that up tomorrow
Ping?
thx,
Jason.
^ permalink raw reply
* [PATCH] i2c: mv64xxx: Fix locked bus when offload is selected but not used on a message
From: Kevin Hilman @ 2014-02-07 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207150958.GY8533@titan.lakedaemon.net>
Jason Cooper <jason@lakedaemon.net> writes:
> On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
>> Offload can be used only on regular transactions and for 1 to byte
>> transfers. In the other cases we switch back to usual work flow.
>>
>> In this case we need to call mv64xxx_i2c_prepare_for_io() as this
>> function is not used when we try to use offloading.
>>
>> This commit adds this missing call when offloading have failed in the
>> MV64XXX_I2C_ACTION_OFFLOAD_SEND_START case.
>>
>> This fix the timeout seen when the the i2c driver try to access an
>> address where the device is absent on the Armada XP bases board.
>>
>> Cc: stable at vger.kernel.org # v3.12+
>> Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> drivers/i2c/busses/i2c-mv64xxx.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> I'd like to get a few tested-by's on this before this is pushed. We've
> had quite a bit of fixes this round :( Please test both multi_v7 and
> mvebu defconfigs.
>
> Kevin, I know you're busy with a lot more than us, but if you could
> confirm that this fixes the bus hangs you reported, that would be great.
I applied this patch on top of next-20140207 and tested this on the
armada-xp openblocks ax3, which is where I was seeing the I2C timeouts.
I confirm it fixes the timeouts I was seeing.
Tested-by: Kevin Hilman <khilman@linaro.org>
Kevin
^ permalink raw reply
* [PATCH] clk: respect the clock dependencies in of_clk_init
From: Gregory CLEMENT @ 2014-02-07 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F506E4.8070900@elopez.com.ar>
On 07/02/2014 17:16, Emilio L?pez wrote:
> Hi Gregory,
>
> El 07/02/14 12:12, Gregory CLEMENT escribi?:
>> On 07/02/2014 16:00, Emilio L?pez wrote:
>>> El 07/02/14 11:49, Gregory CLEMENT escribi?:
>>>> On 07/02/2014 15:43, Ezequiel Garcia wrote:
>>>>> On Fri, Feb 07, 2014 at 09:24:30AM -0500, Jason Cooper wrote:
>>>>>> On Fri, Feb 07, 2014 at 10:06:08AM -0300, Emilio L?pez wrote:
>>>>>>
>>>>>> [snip a great explanation]
>>>>>>
>>>>>> Guys, can I get some Tested-by's on this?
>>>>>>
>>>>>
>>>>> In case someone missed Emilio's comment about it, I gave his oneliner
>>>>> a test on A370 Reference Design. It worked just as well as Sebastian's.
>>>>
>>>> Well ok it's working but this patch is not better than Sebastian, it is
>>>> even worth. I don't think it is a good idea at all to totally ignore the
>>>> information given by the device tree.
>>>
>>> With a bit more work, you can replace the clk_get magic with a call to
>>> of_clk_get_parent_name() or similar to be able to keep overriding stuff
>>> from DT. This way it would completely match the behaviour on
>>> mvebu_coreclk_setup (default to "tclk", allow overriding with DT).
>>>
>>
>> I think you didn't have a look on our implementation:
>
> I did, several times in fact.
>
>> the name of the clock
>> are created by the driver during the initialization.
>
> The name of the clock is always "tclk", as hardcoded on the driver,
> unless overridden via clock-output-names from DT (see
> mvebu_coreclk_setup). Currently none of your DT that I can see does
> this, so in practice it's always "tclk".
It's not because currently we always use "tclk" that we should not use
the information given by the device tree. Else it will be very
misleading to have a information written in the dts and doing something
else in the code.
>
>> That's why we need that
>> the parent clock are initialized before the gating clock.
>
> You don't really *need* that. The driver just does that because it may
We need it, see my comment in your code.
> have been convenient at the time and it worked. Defaulting to "tclk" on
> mvebu_clk_gating_setup and overriding it if it turns out it has some
> other name on the DT (just like on mvebu_coreclk_setup!) should work as
> well, and doesn't require complex, bloaty, dependency management.
>
> Rough, untested patch below, so you get the idea.
>
> Cheers,
>
> Emilio
>
>
>
> ---
> drivers/clk/mvebu/common.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
> index 25ceccf..730625b 100644
> --- a/drivers/clk/mvebu/common.c
> +++ b/drivers/clk/mvebu/common.c
> @@ -119,19 +119,20 @@ void __init mvebu_clk_gating_setup(struct
> device_node *np,
> const struct clk_gating_soc_desc *desc)
> {
> struct clk_gating_ctrl *ctrl;
> - struct clk *clk;
> void __iomem *base;
> - const char *default_parent = NULL;
> + struct of_phandle_args clkspec;
> + const char *default_parent = "tclk";
> int n;
>
> base = of_iomap(np, 0);
> if (WARN_ON(!base))
> return;
>
> - clk = of_clk_get(np, 0);
> - if (!IS_ERR(clk)) {
> - default_parent = __clk_get_name(clk);
> - clk_put(clk);
> + if (!of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
> &clkspec)) {
> + of_property_read_string_index(clkspec.np, "clock-output-names",
> + clkspec.args_count ? clkspec.args[0] : 0,
> + &default_parent);
> + of_node_put(clkspec.np);
OK here you duplicate the code from of_clk_get_parent_name, I wonder why
you didn't use the function.But whatever.
Here you will get default_parent = "mvebu-sar" which is the name of the node, you
can't have "tclk" because this name is not in the device tree, but it will be
created by the initialization of the core clocks.
> }
>
> ctrl = kzalloc(sizeof(*ctrl), GFP_KERNEL);
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] i2c: mv64xxx: Fix locked bus when offload is selected but not used on a message
From: Jason Cooper @ 2014-02-07 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h7g96bxqm.fsf@paris.lan>
On Fri, Feb 07, 2014 at 10:09:53AM -0800, Kevin Hilman wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
>
> > On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
> >> Offload can be used only on regular transactions and for 1 to byte
> >> transfers. In the other cases we switch back to usual work flow.
> >>
> >> In this case we need to call mv64xxx_i2c_prepare_for_io() as this
> >> function is not used when we try to use offloading.
> >>
> >> This commit adds this missing call when offloading have failed in the
> >> MV64XXX_I2C_ACTION_OFFLOAD_SEND_START case.
> >>
> >> This fix the timeout seen when the the i2c driver try to access an
> >> address where the device is absent on the Armada XP bases board.
> >>
> >> Cc: stable at vger.kernel.org # v3.12+
> >> Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
> >>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >> drivers/i2c/busses/i2c-mv64xxx.c | 9 ++++++++-
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > I'd like to get a few tested-by's on this before this is pushed. We've
> > had quite a bit of fixes this round :( Please test both multi_v7 and
> > mvebu defconfigs.
> >
> > Kevin, I know you're busy with a lot more than us, but if you could
> > confirm that this fixes the bus hangs you reported, that would be great.
>
> I applied this patch on top of next-20140207 and tested this on the
> armada-xp openblocks ax3, which is where I was seeing the I2C timeouts.
>
> I confirm it fixes the timeouts I was seeing.
>
> Tested-by: Kevin Hilman <khilman@linaro.org>
Thanks, Kevin!
thx,
Jason.
^ permalink raw reply
* [PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache
From: Jason Gunthorpe @ 2014-02-07 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207093206.GE17758@lunn.ch>
On Fri, Feb 07, 2014 at 10:32:06AM +0100, Andrew Lunn wrote:
> > I'd prefer to fallback to hardcoded register address here. We know
> > we're on kirkwood at this point.
>
> We could also be on mv78xx0, sometime in the future. So we need to at
> least look at the compatible string to see what SoC we are. It is also
> rather ugly having hard coded addresses. We might as well go back to
> platform devices.
The driver should have a default mode "marvell,feroceon-cache" which
doesn't manipulate the write through register at all. In this mode you
don't need any register mapping or DT block, just do the mcr/mrc
operations to switch the cache on and inhibit printing of the write
through status.
So, I'd suggest rough logic like:
int feroceon_of_init()
{
writethrough = -1;
if (np = of_find_compatible("marvell,kirkwood-cache")) {
writethrough = set_writethrough(np, L2_WT_REG_KIRKWOOD,
L2_WRITETHROUGH_KIRKWOOD);
else if (np = of_find_compatible("marvell,mv78xx0-cache")) {
writethrough = set_writethrough(np, L2_WT_REG_MV78XX0,
L2_WRITETHROUGH_MV78XX0);
feroceon_l2_init(writethrough);
[..]
void __init feroceon_l2_init(int __l2_wt_override)
{
/* If we don't know the write through state then assume it is
write back, as that is the safest option. */
if (__l2_wt_override == -1)
l2_wt_override = 0;
else
l2_wt_override = __l2_wt_override;
[..]
printk(KERN_INFO "Feroceon L2: Cache support initialised%s.\n",
l2_wt_override == 1 ? ", write through enabled" : "");
> I would prefer upping this to pr_err(FW_INFO, and not falling back to
> hard coded values. This is not a fatal error, the machine continues to
> run, just a bit slower.
The only loss with not having the register mappings is you must assume
write back and thus the system must do possibly useless cache flushes
in the DMA path. Otherwise the cache can be fully enabled without
needing model specific registers.
The writethrough disable is such an obscure feature, I think we can
just skip having a compatibility fall back for missing DT node.
BTW, if you have a git URL for your patch set I can probably give v2 a
try here on Kirkwood..
Regards,
Jason
^ permalink raw reply
* [PATCH] clk: respect the clock dependencies in of_clk_init
From: Emilio López @ 2014-02-07 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F52189.5090506@free-electrons.com>
Hi,
El 07/02/14 15:10, Gregory CLEMENT escribi?:
(snip)
>> ---
>> drivers/clk/mvebu/common.c | 13 +++++++------
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
>> index 25ceccf..730625b 100644
>> --- a/drivers/clk/mvebu/common.c
>> +++ b/drivers/clk/mvebu/common.c
>> @@ -119,19 +119,20 @@ void __init mvebu_clk_gating_setup(struct
>> device_node *np,
>> const struct clk_gating_soc_desc *desc)
>> {
>> struct clk_gating_ctrl *ctrl;
>> - struct clk *clk;
>> void __iomem *base;
>> - const char *default_parent = NULL;
>> + struct of_phandle_args clkspec;
>> + const char *default_parent = "tclk";
>> int n;
>>
>> base = of_iomap(np, 0);
>> if (WARN_ON(!base))
>> return;
>>
>> - clk = of_clk_get(np, 0);
>> - if (!IS_ERR(clk)) {
>> - default_parent = __clk_get_name(clk);
>> - clk_put(clk);
>> + if (!of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
>> &clkspec)) {
>> + of_property_read_string_index(clkspec.np, "clock-output-names",
>> + clkspec.args_count ? clkspec.args[0] : 0,
>> + &default_parent);
>> + of_node_put(clkspec.np);
>
> OK here you duplicate the code from of_clk_get_parent_name, I wonder why
> you didn't use the function.But whatever.
I specifically duplicated it because of_clk_get_parent_name returns the
node name if there's no clock-output-names. That wouldn't be useful in
this case.
> Here you will get default_parent = "mvebu-sar" which is the name of the node, you
> can't have "tclk" because this name is not in the device tree, but it will be
> created by the initialization of the core clocks.
No, default_parent would be "tclk" still because clock-output-names
property doesn't exist. If you ever add such a property, it will
override "tclk".
Cheers,
Emilio
^ 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