* How to support SDIO wifi/bt in DT
From: Chen-Yu Tsai @ 2014-01-16 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116133649.GV15937@n2100.arm.linux.org.uk>
Hi,
On Thu, Jan 16, 2014 at 9:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Okay, I'm hitting something of a dead end with trying to work out how to
> support this in DT.
>
> The Wifi/BT (bcrmfmac) device has multiple connections to the host device
> - it has a SDIO connection, a UART connection, and an audio connection.
> In addition, a series of GPIOs are wired to control this device:
>
> - Reset for bluetooth plus two additional GPIOs (unused I think)
The other 2 are wake and host wake (interrupts in either direction) I suppose?
The device should support in-band signaling over the UART as well, and
we have no way to tie these 2 interrupts to the bluetooth device anyway.
> - Reset for Wifi plus two additional GPIOs (again, I think unused)
Again, should be out-of-band interrupts in both directions.
> - GPIO to control regulator supplying power to the Wifi/BT chip
> - GPIO to control regulator supplying power to the oscillator for
> the Wifi/BT chip.
>
> The Wifi/BT chip can only be detected via probing the SDIO connection, and
> only when the device has been powered up and released from reset - so we
> have to power up and reset the bcrm device before we probe via the SDIO
> bus.
>
> While it's possible to attach the power supply for the Wifi/BT chip to the
> vmmc-supply property of the host, it's not possible to do that with the
> oscillator supply. Neither is there any provision for manipulating the
> GPIOs to deal with the resets.
Android devices would probably use a custom rfkill device.
> I can't find any examples of anything similar in our existing set of DT
> files, so I suspect either this is a device which no one supports on any
> DT platform, or there's some clever way to handle this.
>
> How do other people support this in DT? Do they hack up some platform
> specific code (which isn't nice)? What other solutions are there to get
> around this problem? How does this kind of thing get represented in DT?
AFAIK, there is none at the moment.
I am working on a patch series that adds DT support to rfkill-gpio.
rfkill-gpio takes at most 2 GPIOs and 1 clock for each rfkill control.
You would register one for wifi, and one for bluetooth. The patches
should be posted by tomorrow, hopefully.
But the brcmfmac driver also registers one itself, so you would have
2 wifi rfkills in the system. So I register my wifi power as a regulator
that is always on, using fixed-regulator with the regulator-always-on DT
property.
> (Don't suggest adding DT support to the bcrmfmac driver - this is a
> chicken-and-egg problem. The driver isn't being probed at the moment
> because the device is powered down and/or held in reset, so is
> undetectable. The kernel needs to power it up and release the reset
> so it becomes detectable.)
The brcmfmac driver also has a platform device component, which one can
give power on/off callbacks through platform data. Maybe we can add DT
support to this bit as well.
I'v already completed device tree support for the SDIO device part, to
be able to use out-of-band interrupt signaling. However the sunxi GPIO
driver isn't well tested, and I am not getting interrupts. Still have to
sort this out to actually test my work.
Cheers,
ChenYu
^ permalink raw reply
* [PATCH v6 1/3] AArch64: KGDB: Add Basic KGDB support
From: Catalin Marinas @ 2014-01-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387453851-19341-2-git-send-email-vijay.kilari@gmail.com>
On Thu, Dec 19, 2013 at 11:50:49AM +0000, vijay.kilari at gmail.com wrote:
> --- /dev/null
> +++ b/arch/arm64/include/asm/kgdb.h
[...]
> +#ifndef __ARM_KGDB_H__
> +#define __ARM_KGDB_H__
[...]
> +#endif /* __ASM_KGDB_H__ */
Nitpick (while you are addressing the other issues): please change
header guards to __ASM_KGDB_H for consistency with most of the other
files.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Mark Brown @ 2014-01-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401161219.01038.arnd@arndb.de>
On Thu, Jan 16, 2014 at 12:19:00PM +0100, Arnd Bergmann wrote:
> 1. Other platforms also require the syscon driver to be active before
> the regular device driver probing starts. Michal Simek has the same
> issue in the zynq clock driver that you have for SMP initialization.
> We have talked about this with Mark Brown already, and I think we will
> find a solution for this in the end, but it's not as straightforward
> as I first hoped. We can probably use help in this area.
I thought the solution with deferring registration of the resource for
dev_get_regmap() until a proper device materialised seemed simple and
enough, did you folks run into any problems with that? I had assumed a
patch was likely to materialise so wasn't worrying about it myself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140116/e6781d1d/attachment.sig>
^ permalink raw reply
* [PATCH] ARM64: perf: support dwarf unwinding in compat mode
From: Jean Pihet @ 2014-01-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116125727.GI30257@mudshark.cambridge.arm.com>
Will,
On 16 January 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Jan 16, 2014 at 12:26:53PM +0000, Jean Pihet wrote:
>> On 16 January 2014 12:56, Will Deacon <will.deacon@arm.com> wrote:
>> > In your previous series, compat backtracing is actually split out into a
>> > separate function (compat_user_backtrace), so it would be more consistent to
>> > have a compat_user_stack_pointer macro, rather than add this check here.
The compat_user_backtrace function is used to unwind using the frame
pointer, it is not used to unwind using the dwarf info (which uses the
user stack pointer).
>>
>> Do you mean this change instead?
>
> I don't think so...
>
>> diff --git a/kernel/events/internal.h b/kernel/events/internal.h
>> index 569b2187..9b88d2e 100644
>> --- a/kernel/events/internal.h
>> +++ b/kernel/events/internal.h
>> @@ -185,7 +185,8 @@ static inline bool arch_perf_have_user_stack_dump(void)
>> return true;
>> }
>>
>> -#define perf_user_stack_pointer(regs) user_stack_pointer(regs)
>> +#define perf_user_stack_pointer(regs) \
>> + (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
>
> This doesn't belong in core code; compat_user_mode and the fields of regs
> are arm64-specific.
Right.
> So I suppose you need to rework your original patch to
> call compat_user_stack_pointer (which we already define in compat.h for
> arm64) if compat_user_mode(regs)).
The perf core code calls perf_user_stack_pointer(regs) to retrieve the
stack pointer, with perf_user_stack_pointer(regs) defined as
user_stack_pointer(regs).
The problem is that perf is not aware of the compat mode, so every
arch has to implement user_stack_pointer(regs) correctly.
For this reason I think the first patch proposal is the right one
unless the perf core code is redesigned to handle different ABIs. Do
you see a better implementation?
>
> The problem there is the inconsistency with respect to the regs argument:
>
> user_stack_pointer(regs) // Returns user stack pointer for regs
> current_user_stack_pointer() // Returns current user stack pointer
> compat_user_stack_pointer() // Doesn't take a regs argument!
>
> On top of that, x86 treats those last two functions differently when current
> is a compat task.
>
> So the simplest thing would be to make compat_user_stack_pointer expand to
> user_stack_pointer(current_pt_regs()) on arm64 and merge that in with your
> original patch fixing user_stack_pointer.
>
> Will
Thx!
Jean
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Catalin Marinas @ 2014-01-16 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387453851-19341-1-git-send-email-vijay.kilari@gmail.com>
On Thu, Dec 19, 2013 at 11:50:48AM +0000, vijay.kilari at gmail.com wrote:
> Vijaya Kumar K (3):
> AArch64: KGDB: Add Basic KGDB support
> AArch64: KGDB: Add step debugging support
> KGDB: make kgdb_breakpoint() as noinline
I gave them a try and now I have some doubts about your testing
methodology:
1. There is no HAVE_ARCH_KGDB anywhere in these patches, so
the code here isn't compiled.
2. There are several compiler warnings that need to be addressed.
3. I enabled CONFIG_KGDB_TESTS and CONFIG_KGDB_TESTS_ON_BOOT and that's
what really scared me.
Please address these before we can consider the patches for merging.
--
Catalin
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Michal Simek @ 2014-01-16 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401161219.01038.arnd@arndb.de>
On 01/16/2014 12:19 PM, Arnd Bergmann wrote:
> On Thursday 16 January 2014, Marc C wrote:
>>> And then you can add a regular device driver to drivers/reset that provides a
>>> device_reset() API to other drivers, or a system-reset function to be registered as
>>> arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to get access
>>> to a regmap pointer, and then use either hardcoded offsets into the regmap, or get
>>> those offsets from numbers in the devicetree, as provided in the example above.
>>
>> I was able to port a standalone "reboot" driver using syscon + regmap. However, for the
>> SMP initialization case, it turns out that syscon is configured after SMP init. Do you
>> have any advice for this type of situation?
>>
>> I'd hate to go around in circles, but without resorting to hard-coded offsets, perhaps I
>> can just add the remaining "non-regmap" register offsets in the DT?
>
> You are not the first one to stumble over this problem. There are
> two ways to get out of it, and we should probably implement both in
> the long run:
>
> 1. Other platforms also require the syscon driver to be active before
> the regular device driver probing starts. Michal Simek has the same
> issue in the zynq clock driver that you have for SMP initialization.
> We have talked about this with Mark Brown already, and I think we will
> find a solution for this in the end, but it's not as straightforward
> as I first hoped. We can probably use help in this area.
I wouldn't say issue because we have created workaround which should be acceptable.
For more info.
https://lkml.org/lkml/2014/1/6/349 patch 2/7 is that what we have done
to get it work.
Also I hope that this can go to mainline before any nice solution will be find
not to stop work on others drivers which use regmap.
But there is definitely a space for doing this better.
> 2. There is actually no reason for the SMP code to be called this early,
> and multiple platforms would like to move SMP init to a later stage.
> Stephen Boyd has recently started reworking the way we do SMP init,
> and he may have some more insight.
>
> In the meantime, I'd suggest you do the binding under the assumption
> that it will work eventually, and then work around the current limitations
> in the SMP code by looking for the device nodes you need and map them
> manually, as you did in the previous versions of your patch set.
Yep, that's exactly what we have done just because of other driver developing
till this is resolved.
Thanks,
Michal
^ permalink raw reply
* [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller
From: Ivan T. Ivanov @ 2014-01-16 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115164604.GI14405@codeaurora.org>
Hi,
On Wed, 2014-01-15 at 08:46 -0800, Stephen Boyd wrote:
> On 01/13, Bjorn Andersson wrote:
> > +/*
> > + * QUP driver for Qualcomm MSM platforms
> > + *
> > + */
>
> This comment seems redundant, we know what file we're looking at.
>
> > +
> > +struct qup_i2c_dev {
> > + struct device *dev;
> > + void __iomem *base;
> > + struct pinctrl *pctrl;
>
> This is unused.
>
> > + int irq;
> > + struct clk *clk;
> > + struct clk *pclk;
> > + struct i2c_adapter adap;
> > +
> > + int clk_freq;
>
> This is only ever used in probe, so why do we need to store it
> away?
>
> > + int clk_ctl;
> > + int one_bit_t;
> > + int out_fifo_sz;
> > + int in_fifo_sz;
> > + int out_blk_sz;
> > + int in_blk_sz;
> > + unsigned long xfer_time;
> > + unsigned long wait_idle;
> > +
> > + struct i2c_msg *msg;
> > + /* Current possion in user message buffer */
>
> s/possion/position/?
>
> > + int pos;
> > + /* Keep number of bytes left to be transmitted */
> > + int cnt;
> > + /* I2C protocol errors */
> > + u32 bus_err;
> > + /* QUP core errors */
> > + u32 qup_err;
> > + /*
> > + * maximum bytes that could be send (per iterration). could be
>
> s/iterration/iteration/?
>
> > + * equal of fifo size or block size (in block mode)
> > + */
> > + int chunk_sz;
> > + struct completion xfer;
> > +};
> > +
> > +static irqreturn_t qup_i2c_interrupt(int irq, void *dev)
> > +{
> > + struct qup_i2c_dev *qup = dev;
> > + u32 bus_err;
> > + u32 qup_err;
> > + u32 opflags;
> > +
> [...]
> > +
> > + if (opflags & QUP_OUT_SVC_FLAG)
> > + writel(QUP_OUT_SVC_FLAG, qup->base + QUP_OPERATIONAL);
> > +
> > + if (!(qup->msg->flags == I2C_M_RD))
>
> Should this be?
>
> if (!(qup->msg->flags & I2C_M_RD))
>
> Otherwise it should be
>
> if (qup->msg->flags != I2C_M_RD)
>
This check is actually broken. Intention was that if this is read
transaction and there is no QUP_MX_INPUT_DONE or QUP_IN_SVC_FLAG
to exit without wakeup transfer thread. As is it now it will never
complete write transactions.
Regards,
Ivan
> > + return IRQ_HANDLED;
> > +
> > + if ((opflags & QUP_MX_INPUT_DONE) || (opflags & QUP_IN_SVC_FLAG))
> > + writel(QUP_IN_SVC_FLAG, qup->base + QUP_OPERATIONAL);
> > +
> > +done:
> > + qup->qup_err = qup_err;
> > + qup->bus_err = bus_err;
> > + complete(&qup->xfer);
> > + return IRQ_HANDLED;
> > +}
> > +
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Russell King - ARM Linux @ 2014-01-16 13:36 UTC (permalink / raw)
To: linux-arm-kernel
Okay, I'm hitting something of a dead end with trying to work out how to
support this in DT.
The Wifi/BT (bcrmfmac) device has multiple connections to the host device
- it has a SDIO connection, a UART connection, and an audio connection.
In addition, a series of GPIOs are wired to control this device:
- Reset for bluetooth plus two additional GPIOs (unused I think)
- Reset for Wifi plus two additional GPIOs (again, I think unused)
- GPIO to control regulator supplying power to the Wifi/BT chip
- GPIO to control regulator supplying power to the oscillator for
the Wifi/BT chip.
The Wifi/BT chip can only be detected via probing the SDIO connection, and
only when the device has been powered up and released from reset - so we
have to power up and reset the bcrm device before we probe via the SDIO
bus.
While it's possible to attach the power supply for the Wifi/BT chip to the
vmmc-supply property of the host, it's not possible to do that with the
oscillator supply. Neither is there any provision for manipulating the
GPIOs to deal with the resets.
I can't find any examples of anything similar in our existing set of DT
files, so I suspect either this is a device which no one supports on any
DT platform, or there's some clever way to handle this.
How do other people support this in DT? Do they hack up some platform
specific code (which isn't nice)? What other solutions are there to get
around this problem? How does this kind of thing get represented in DT?
(Don't suggest adding DT support to the bcrmfmac driver - this is a
chicken-and-egg problem. The driver isn't being probed at the moment
because the device is powered down and/or held in reset, so is
undetectable. The kernel needs to power it up and release the reset
so it becomes detectable.)
--
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 v4 4/4] pinctrl: Enable pinctrl for Broadcom Capri SoCs
From: Linus Walleij @ 2014-01-16 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387592016-13740-5-git-send-email-syin@broadcom.com>
On Sat, Dec 21, 2013 at 3:13 AM, Sherman Yin <syin@broadcom.com> wrote:
> Enable pinctrl for Broadcom Capri (BCM281xx) SoCs.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Christian Daudt <bcm@fixthebug.org>
> Reviewed-by: Matt Porter <matt.porter@linaro.org>
I've applied this to the pinctrl tree as well.
Same thing here: if it conflicts with ARM SoC it goes out.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 1/4] pinctrl: Add void * to pinctrl_pin_desc
From: Linus Walleij @ 2014-01-16 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387592016-13740-2-git-send-email-syin@broadcom.com>
On Sat, Dec 21, 2013 at 3:13 AM, Sherman Yin <syin@broadcom.com> wrote:
> drv_data is added to the pinctrl_pin_desc for drivers to define additional
> driver-specific per-pin data.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Christian Daudt <bcm@fixthebug.org>
> Reviewed-by: Matt Porter <matt.porter@linaro.org>
This patch applied as well.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 2/4] pinctrl: Add pinctrl binding for Broadcom Capri SoCs
From: Linus Walleij @ 2014-01-16 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387592016-13740-3-git-send-email-syin@broadcom.com>
On Sat, Dec 21, 2013 at 3:13 AM, Sherman Yin <syin@broadcom.com> wrote:
> Adds pinctrl driver devicetree binding for Broadcom Capri (BCM281xx) SoCs.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Christian Daudt <bcm@fixthebug.org>
> Reviewed-by: Matt Porter <matt.porter@linaro.org>
> ---
> v4: Changed valid values for "bias-pull-up" property for I2C pins. Expanded
> pin configuration node example.
Patch applied with Mark R's ACK and a copy of his ECG.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
From: Linus Walleij @ 2014-01-16 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387592016-13740-4-git-send-email-syin@broadcom.com>
On Sat, Dec 21, 2013 at 3:13 AM, Sherman Yin <syin@broadcom.com> wrote:
'> Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Christian Daudt <bcm@fixthebug.org>
> Reviewed-by: Matt Porter <matt.porter@linaro.org>
> ---
> v4: - PINCTRL selected in Kconfig, PINCTRL_CAPRI selected in bcm_defconfig
> - make use of regmap
> - change CAPRI_PIN_UPDATE from macro to inline function.
> - Handle pull-up strength arg in Ohm instead of enum
Patch applied. It is really good now! It's late before the merge
window, but you've done a tremendous work on this driver and
I don't want to delay its deployment further.
But note:
> arch/arm/configs/bcm_defconfig | 1 +
> arch/arm/mach-bcm/Kconfig | 1 +
I've optimistically applied these two hunks of the patch as well,
but if there is any conflict with the ARM SoC tree I will just rebase
the patch and pull these *out*.
ARM SoC maintainers: be warned if something collides.
Yours,
Linus Walleij
^ permalink raw reply
* Multiple CCR definitions (was: Re: mmc: omap_hsmmc: use the generic config for omap2plus devices)
From: Geert Uytterhoeven @ 2014-01-16 13:07 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 10, 2013 at 11:05 PM, Linux Kernel Mailing List
<linux-kernel@vger.kernel.org> wrote:
> mmc: omap_hsmmc: use the generic config for omap2plus devices
>
> OMAP's hs_mmc driver is used for MMC controller operation on many
> omap2plus SoCs (OMAP2430, OMAP3, 4, 5 and AM335x).
>
> Considering that the device tree entries are already present for these,
> allow the driver to be built using the config ARCH_OMAP2PLUS rather
> than individually adding a config for each SoC to enable the
> support.
>
> Use COMPILE_TEST to enable the build for other platforms.
>
> Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Cc: Nishanth Menon <nm@ti.com>
> Acked-by: Felipe Balbi <balbi@ti.com>
> Acked-by: Balaji T K <balajitk@ti.com>
> Signed-off-by: Chris Ball <cjb@laptop.org>
> ---
> drivers/mmc/host/Kconfig | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 84102bc..b8ce939 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -284,11 +284,11 @@ config MMC_OMAP
>
> config MMC_OMAP_HS
> tristate "TI OMAP High Speed Multimedia Card Interface support"
> - depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4
> + depends on ARCH_OMAP2PLUS || COMPILE_TEST
sh-allmodconfig (http://kisskb.ellerman.id.au/kisskb/buildresult/10477672/):
include/linux/omap-dma.h:171:8: error: expected identifier before
numeric constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
It fails because sh #defines "CCR", which is one of the enum values in
include/linux/omap-dma.h.
I expect a similar failure on blackfin, which also has #define CCR.
Possible solutions:
1. Rename CCR in sh/bfin to e.g. SH_CCR resp. BF_CCR.
2. Use "depends on ARCH_OMAP2PLUS || (COMPILE_TEST && ARM)
3. Stop using include/linux/omap-dma.h, as it says:
* Legacy OMAP DMA handling defines and functions
*
* NOTE: Do not use these any longer.
*
* Use the generic dmaengine functions as defined in
* include/linux/dmaengine.h.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM64: perf: support dwarf unwinding in compat mode
From: Will Deacon @ 2014-01-16 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFrcx1=eAHsGZDsedGvvNai7Vrnf5p8RKLGFPS+cn5yGp7UQJw@mail.gmail.com>
On Thu, Jan 16, 2014 at 12:26:53PM +0000, Jean Pihet wrote:
> On 16 January 2014 12:56, Will Deacon <will.deacon@arm.com> wrote:
> > In your previous series, compat backtracing is actually split out into a
> > separate function (compat_user_backtrace), so it would be more consistent to
> > have a compat_user_stack_pointer macro, rather than add this check here.
>
> Do you mean this change instead?
I don't think so...
> diff --git a/kernel/events/internal.h b/kernel/events/internal.h
> index 569b2187..9b88d2e 100644
> --- a/kernel/events/internal.h
> +++ b/kernel/events/internal.h
> @@ -185,7 +185,8 @@ static inline bool arch_perf_have_user_stack_dump(void)
> return true;
> }
>
> -#define perf_user_stack_pointer(regs) user_stack_pointer(regs)
> +#define perf_user_stack_pointer(regs) \
> + (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
This doesn't belong in core code; compat_user_mode and the fields of regs
are arm64-specific. So I suppose you need to rework your original patch to
call compat_user_stack_pointer (which we already define in compat.h for
arm64) if compat_user_mode(regs)).
The problem there is the inconsistency with respect to the regs argument:
user_stack_pointer(regs) // Returns user stack pointer for regs
current_user_stack_pointer() // Returns current user stack pointer
compat_user_stack_pointer() // Doesn't take a regs argument!
On top of that, x86 treats those last two functions differently when current
is a compat task.
So the simplest thing would be to make compat_user_stack_pointer expand to
user_stack_pointer(current_pt_regs()) on arm64 and merge that in with your
original patch fixing user_stack_pointer.
Will
^ permalink raw reply
* [PATCH 4/4] ARM: dts: imx6: edmqmx6: Add LED support
From: Sascha Hauer @ 2014-01-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876750-29880-1-git-send-email-s.hauer@pengutronix.de>
The edmqmx6 has some GPIO controlled LEDs. Add support for them.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index bafc392..b8a1ff4 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -11,6 +11,7 @@
/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
#include "imx6q.dtsi"
/ {
@@ -58,6 +59,31 @@
enable-active-high;
};
};
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ label = "blue";
+ gpios = <&stmpe_gpio 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-green {
+ label = "green";
+ gpios = <&stmpe_gpio 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-pink {
+ label = "pink";
+ gpios = <&stmpe_gpio 10 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-red {
+ label = "red";
+ gpios = <&stmpe_gpio 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
&fec {
@@ -186,6 +212,7 @@
interrupt-parent = <&gpio3>;
stmpe_gpio: stmpe_gpio {
+ #gpio-cells = <2>;
compatible = "st,stmpe-gpio";
};
};
--
1.8.5.2
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx6: edmqmx6: add PF0100 PMIC to device tree
From: Sascha Hauer @ 2014-01-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876750-29880-1-git-send-email-s.hauer@pengutronix.de>
From: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 104 ++++++++++++++++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index fe990bc..bafc392 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -65,6 +65,7 @@
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-reset-gpios = <&gpio3 23 0>;
+ phy-supply = <&vgen2_1v2_eth>;
status = "okay";
};
@@ -75,6 +76,109 @@
&pinctrl_stmpe>;
status = "okay";
+ pmic: pfuze100 at 08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <20 8>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ regulator-always-on;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_1v2_eth: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vdd_high_in: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+
stmpe: stmpe1601 at 40 {
compatible = "st,stmpe1601";
reg = <0x40>;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: imx6: edmqmx6: Add sata support
From: Sascha Hauer @ 2014-01-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876750-29880-1-git-send-email-s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index 7ce2038..fe990bc 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -148,6 +148,10 @@
};
};
+&sata {
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: imx6: edmqmx6: Add usdhc4 (emmc) support
From: Sascha Hauer @ 2014-01-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876750-29880-1-git-send-email-s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
index 84f5143..7ce2038 100644
--- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
+++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
@@ -141,6 +141,10 @@
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <MX6QDL_USDHC3_PINGRP_D4>;
};
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = <MX6QDL_USDHC4_PINGRP_D8>;
+ };
};
};
@@ -176,3 +180,12 @@
vmmc-supply = <®_3p3v>;
status = "okay";
};
+
+&usdhc4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4>;
+ vmmc-supply = <®_3p3v>;
+ non-removable;
+ bus-width = <8>;
+ status = "okay";
+};
--
1.8.5.2
^ permalink raw reply related
* [PATCH] ARM: imx6: dmo edmqmx6 updates
From: Sascha Hauer @ 2014-01-16 12:52 UTC (permalink / raw)
To: linux-arm-kernel
This series adds some additional features to the recently introduced
DataModul edmqmx6 board.
Sascha
----------------------------------------------------------------
Philipp Zabel (1):
ARM: dts: imx6: edmqmx6: add PF0100 PMIC to device tree
Sascha Hauer (3):
ARM: dts: imx6: edmqmx6: Add usdhc4 (emmc) support
ARM: dts: imx6: edmqmx6: Add sata support
ARM: dts: imx6: edmqmx6: Add LED support
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 148 ++++++++++++++++++++++++++++++++
1 file changed, 148 insertions(+)
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Zhangfei Gao @ 2014-01-16 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389839502-13046-1-git-send-email-zhangfei.gao@linaro.org>
Introduced from commit bf626e5550f24aec24975a0e85ad8e572ca76a6b
CDETECT is ignored since negated return value of mmc_gpio_get_cd(mmc)
can not be checked by IS_ERR_VALUE.
Add spin_lock_bh(&host->lock) for atomic accessing DW_MMC_CARD_PRESENT,
otherwise sd detect may occasionally fail.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reported-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org>
Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/mmc/host/dw_mmc.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a776f24f4311..55cd110a49c4 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci_board *brd = slot->host->pdata;
- int gpio_cd = !mmc_gpio_get_cd(mmc);
+ struct dw_mci *host = slot->host;
+ int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
else if (brd->get_cd)
present = !brd->get_cd(slot->id);
else if (!IS_ERR_VALUE(gpio_cd))
- present = !!gpio_cd;
+ present = gpio_cd;
else
present = (mci_readl(slot->host, CDETECT) & (1 << slot->id))
== 0 ? 1 : 0;
+ spin_lock_bh(&host->lock);
if (present) {
set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
dev_dbg(&mmc->class_dev, "card is present\n");
@@ -1053,6 +1055,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
dev_dbg(&mmc->class_dev, "card is not present\n");
}
+ spin_unlock_bh(&host->lock);
return present;
}
@@ -2081,7 +2084,7 @@ static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
return gpio;
}
-/* find the cd gpio for a given slot; or -1 if none specified */
+/* find the cd gpio for a given slot */
static void dw_mci_of_get_cd_gpio(struct device *dev, u8 slot,
struct mmc_host *mmc)
{
@@ -2411,6 +2414,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
if (of_find_property(np, "caps2-mmc-hs200-1_2v", NULL))
pdata->caps2 |= MMC_CAP2_HS200_1_2V_SDR;
+ if (of_get_property(np, "cd-inverted", NULL))
+ pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
return pdata;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: dts: imx6q: Add support for Zealz GK802
From: Sascha Hauer @ 2014-01-16 12:48 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the GK802 'QUAD CORE Mini PC', which seems to be loosely
based on the Freescale i.MX6Q HDMI dongle reference design.
It is supposedly identical to the Hiapad Hi802.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-gk802.dts | 151 ++++++++++++++++++++++++++++++++++++++
2 files changed, 152 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-gk802.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index aeb8053..9ed00a0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx6q-arm2.dtb \
imx6q-cm-fx6.dtb \
imx6q-dmo-edmqmx6.dtb \
+ imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
imx6q-gw52xx.dtb \
imx6q-gw53xx.dtb \
diff --git a/arch/arm/boot/dts/imx6q-gk802.dts b/arch/arm/boot/dts/imx6q-gk802.dts
new file mode 100644
index 0000000..0d010df
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-gk802.dts
@@ -0,0 +1,151 @@
+/*
+ * Copyright (C) 2013 Philipp Zabel
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+
+/ {
+ model = "Zealz GK802";
+ compatible = "zealz,imx6q-gk802", "fsl,imx6q";
+
+ chosen {
+ linux,stdout-path = &uart4;
+ };
+
+ memory {
+ reg = <0x10000000 0x40000000>;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_3p3v: 3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ recovery-button {
+ label = "recovery";
+ gpios = <&gpio3 16 1>;
+ linux,code = <0x198>; /* KEY_RESTART */
+ gpio-key,wakeup;
+ };
+ };
+};
+
+/* Internal I2C */
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2_gk802>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ /* SDMC DM2016 1024 bit EEPROM + 128 bit OTP */
+ eeprom: dm2016 at 51 {
+ compatible = "sdmc,dm2016";
+ reg = <0x51>;
+ };
+};
+
+/* External I2C via HDMI */
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3_gk802>;
+ clock-frequency = <100000>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ hog {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* Recovery button, active-low */
+ MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x100b1
+ /* RTL8192CU enable GPIO, active-low */
+ MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
+ >;
+ };
+ };
+
+ i2c {
+ pinctrl_i2c2_gk802: i2c2grp-1 {
+ fsl,pins = <MX6QDL_I2C2_PINGRP2>;
+ };
+
+ pinctrl_i2c3_gk802: i2c3grp-1 {
+ fsl,pins = <MX6QDL_I2C3_PINGRP3>;
+ };
+ };
+
+ uart {
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <MX6QDL_UART4_PINGRP1>;
+ };
+ };
+
+ usdhc {
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <MX6QDL_USDHC3_PINGRP_D4>;
+ };
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = <MX6QDL_USDHC4_PINGRP_D4>;
+ };
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+/* External USB-A port (USBOTG) */
+&usbotg {
+ disable-over-current;
+ status = "okay";
+};
+
+/* Internal USB port (USBH1), connected to RTL8192CU */
+&usbh1 {
+ disable-over-current;
+ status = "okay";
+};
+
+/* External microSD */
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <4>;
+ cd-gpios = <&gpio6 11 0>;
+ vmmc-supply = <®_3p3v>;
+ status = "okay";
+};
+
+/* Internal microSD */
+&usdhc4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4>;
+ bus-width = <4>;
+ vmmc-supply = <®_3p3v>;
+ status = "okay";
+};
--
1.8.5.2
^ permalink raw reply related
* [PATCH] ARM: dts: imx6: Add DFI FS700-M60 board support
From: Sascha Hauer @ 2014-01-16 12:45 UTC (permalink / raw)
To: linux-arm-kernel
The DFI FS700-M60 is a q7 board with i.MX6 quad, dual, duallite or solo
SoC. This adds support for it.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts | 23 +++++
arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts | 23 +++++
arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi | 145 +++++++++++++++++++++++++++
4 files changed, 193 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts
create mode 100644 arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index aeb8053..485ed47 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -158,6 +158,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx53-qsrb.dtb \
imx53-smd.dtb \
imx53-voipac-bsb.dtb \
+ imx6dl-dfi-fs700-m60.dtb \
imx6dl-gw51xx.dtb \
imx6dl-gw52xx.dtb \
imx6dl-gw53xx.dtb \
@@ -170,6 +171,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx6dl-wandboard.dtb \
imx6q-arm2.dtb \
imx6q-cm-fx6.dtb \
+ imx6q-dfi-fs700-m60.dtb \
imx6q-dmo-edmqmx6.dtb \
imx6q-gw51xx.dtb \
imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts b/arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts
new file mode 100644
index 0000000..994f96a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-dfi-fs700-m60.dts
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2013 Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DTS_V1__
+#define __DTS_V1__
+/dts-v1/;
+#endif
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-dfi-fs700-m60.dtsi"
+
+/ {
+ model = "DFI FS700-M60-6DL i.MX6dl Q7 Board";
+ compatible = "dfi,fs700-m60-6dl", "dfi,fs700e-m60", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts b/arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts
new file mode 100644
index 0000000..fd0ad9a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-dfi-fs700-m60.dts
@@ -0,0 +1,23 @@
+/*
+ * Copyright 2013 Sascha Hauer <s.hauer@pengutronix.de>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DTS_V1__
+#define __DTS_V1__
+/dts-v1/;
+#endif
+
+#include "imx6q.dtsi"
+#include "imx6qdl-dfi-fs700-m60.dtsi"
+
+/ {
+ model = "DFI FS700-M60-6QD i.MX6qd Q7 Board";
+ compatible = "dfi,fs700-m60-6qd", "dfi,fs700e-m60", "fsl,imx6q";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi b/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
new file mode 100644
index 0000000..ca3c748
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-dfi-fs700-m60.dtsi
@@ -0,0 +1,145 @@
+/ {
+ regulators {
+ compatible = "simple-bus";
+
+ dummy_reg: fixed at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "dummy-supply";
+ };
+
+ reg_usb_otg_vbus: usb_otg_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 0>;
+ enable-active-high;
+ };
+ };
+
+ chosen {
+ linux,stdout-path = &uart1;
+ };
+};
+
+&ecspi3 {
+ fsl,spi-num-chipselects = <1>;
+ cs-gpios = <&gpio4 24 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+
+ flash: m25p80 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "sst,sst25vf040b", "m25p80";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ status = "okay";
+ phy-mode = "rgmii";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ imx6qdl-dfi-fs700-m60 {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x80000000
+ MX6QDL_PAD_GPIO_18__GPIO7_IO13 0x80000000 /* PMIC irq */
+ MX6QDL_PAD_EIM_D26__GPIO3_IO26 0x80000000 /* MAX11801 irq */
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000030b0 /* Backlight enable */
+ MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x80000000 /* SD2 card detect */
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <MX6QDL_ENET_PINGRP1>;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <MX6QDL_I2C2_PINGRP1>;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <MX6QDL_UART1_PINGRP1>;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <MX6QDL_USBOTG_PINGRP2>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <MX6QDL_USDHC2_PINGRP_D4>;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <MX6QDL_USDHC3_PINGRP_D4>;
+ };
+
+ pinctrl_usdhc4: usdhc4grp {
+ fsl,pins = <MX6QDL_USDHC4_PINGRP_D8>;
+ };
+ };
+
+ ecspi3 {
+ pinctrl_ecspi3: ecspi3_csgrp {
+ fsl,pins = <
+ MX6QDL_ECSPI3_PINGRP1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000 /* SPI NOR chipselect */
+ >;
+ };
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc2 { /* module slot */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ cd-gpios = <&gpio2 2 0>;
+ status = "okay";
+};
+
+&usdhc3 { /* baseboard slot */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+};
+
+&usdhc4 { /* eMMC */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
--
1.8.5.2
^ permalink raw reply related
* [PATCH v6 2/6] misc: sram: implement mmio-sram-reserved option
From: Mark Rutland @ 2014-01-16 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1669323.jqjZBfkRx4@phil>
On Wed, Jan 15, 2014 at 09:41:28PM +0000, Heiko St?bner wrote:
> This implements support for the mmio-sram-reserved option to keep the
> genpool from using these areas.
>
> Suggested-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> ---
> drivers/misc/sram.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 110 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> index afe66571..7fb60f3 100644
> --- a/drivers/misc/sram.c
> +++ b/drivers/misc/sram.c
> @@ -36,13 +36,23 @@ struct sram_dev {
> struct clk *clk;
> };
>
> +struct sram_reserve {
> + unsigned long start;
> + unsigned long size;
> +};
> +
> static int sram_probe(struct platform_device *pdev)
> {
> void __iomem *virt_base;
> struct sram_dev *sram;
> struct resource *res;
> - unsigned long size;
> - int ret;
> + unsigned long size, cur_start, cur_size;
> + const __be32 *reserved_list = NULL;
> + int reserved_size = 0;
> + struct sram_reserve *rblocks;
> + unsigned int nblocks;
> + int ret = 0;
> + int i;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> virt_base = devm_ioremap_resource(&pdev->dev, res);
> @@ -65,19 +75,111 @@ static int sram_probe(struct platform_device *pdev)
> if (!sram->pool)
> return -ENOMEM;
>
> - ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> - res->start, size, -1);
> - if (ret < 0) {
> - if (sram->clk)
> - clk_disable_unprepare(sram->clk);
> - return ret;
> + if (pdev->dev.of_node) {
> + reserved_list = of_get_property(pdev->dev.of_node,
> + "mmio-sram-reserved",
> + &reserved_size);
> + if (reserved_list) {
> + reserved_size /= sizeof(*reserved_list);
As a general observation, It looks like a lot of people need to know how
many array elements a property might hold (for datastructure
allocation), and are open-coding element counting.
I think it would be nice if we had a helper function to count how many
elements a property can hold (of_property_count_u32_elems?) that would
centralise strict sanity checking (e.g. prop->len % elem_size == 0) and
DTB format details (so you don't have to care about endianness, and it
becomes possible to add DTB metadata later and get runtime type
checking).
That can all come later and shouldn't block this patch.
> + if (!reserved_size || reserved_size % 2) {
> + dev_warn(&pdev->dev, "wrong number of arguments in mmio-sram-reserved\n");
> + reserved_list = NULL;
> + reserved_size = 0;
> + }
> + }
> + }
> +
> + /*
> + * We need an additional block to mark the end of the memory region
> + * after the reserved blocks from the dt are processed.
> + */
> + nblocks = reserved_size / 2 + 1;
> + rblocks = kmalloc((nblocks) * sizeof(*rblocks), GFP_KERNEL);
> + if (!rblocks) {
> + ret = -ENOMEM;
> + goto err_alloc;
> + }
> +
> + cur_start = 0;
> + for (i = 0; i < nblocks - 1; i++) {
> + rblocks[i].start = be32_to_cpu(*reserved_list++);
> + rblocks[i].size = be32_to_cpu(*reserved_list++);
It feels a little odd to have to have to care about the format of the
dtb and do endianness conversion here. It would be nice to limit the
scope of DTB format details to the of_ helper functions.
Could you use of_property_read_u32_index here instead please?
Otherwise this looks fine to me.
Cheers,
Mark.
^ permalink raw reply
* [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Andreas Herrmann @ 2014-01-16 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876263-25759-1-git-send-email-andreas.herrmann@calxeda.com>
Instead of using just one bitmap to keep track of IO virtual addresses
(handed out for IOMMU use) introduce a list of iova_ranges (each
having its own bitmap). This allows us to extend existing mappings
when running out of iova space for a mapping.
If there is not enough space in the mapping to service an IO virtual
address allocation request, __alloc_iova() tries to extend the mapping
-- by allocating another bitmap -- and makes another allocation
attempt using the freshly allocated bitmap.
This allows arm iommu drivers to start with a decent initial size when
an dma_iommu_mapping is created and still to avoid running out of IO
virtual addresses for the mapping.
Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
I've used SZ_512K both for initial mapping size and grow_size.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
---
arch/arm/include/asm/dma-iommu.h | 17 ++++-
arch/arm/mm/dma-mapping.c | 147 ++++++++++++++++++++++++++++++++------
2 files changed, 139 insertions(+), 25 deletions(-)
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index 50edacd..987d62c 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -8,15 +8,26 @@
#include <linux/dma-debug.h>
#include <linux/kmemcheck.h>
#include <linux/kref.h>
+#include <linux/list.h>
+
+struct dma_iommu_iova_range {
+ struct list_head list_head;
+ unsigned long *bitmap;
+ size_t bits;
+ dma_addr_t base;
+ dma_addr_t size;
+};
struct dma_iommu_mapping {
/* iommu specific data */
struct iommu_domain *domain;
- void *bitmap;
- size_t bits;
- unsigned int order;
+ struct list_head iova_ranges;
dma_addr_t base;
+ dma_addr_t size;
+ dma_addr_t grow_size;
+ dma_addr_t max_size;
+ unsigned int order;
spinlock_t lock;
struct kref kref;
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ccea46a..503e8d6 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -26,6 +26,7 @@
#include <linux/io.h>
#include <linux/vmalloc.h>
#include <linux/sizes.h>
+#include <linux/list.h>
#include <asm/memory.h>
#include <asm/highmem.h>
@@ -1069,6 +1070,8 @@ fs_initcall(dma_debug_do_init);
/* IOMMU */
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
+
static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
size_t size)
{
@@ -1076,6 +1079,8 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
unsigned int align = 0;
unsigned int count, start;
unsigned long flags;
+ struct dma_iommu_iova_range *e;
+ bool area_found;
if (order > CONFIG_ARM_DMA_IOMMU_ALIGNMENT)
order = CONFIG_ARM_DMA_IOMMU_ALIGNMENT;
@@ -1086,32 +1091,80 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
if (order > mapping->order)
align = (1 << (order - mapping->order)) - 1;
+ area_found = false;
spin_lock_irqsave(&mapping->lock, flags);
- start = bitmap_find_next_zero_area(mapping->bitmap, mapping->bits, 0,
- count, align);
- if (start > mapping->bits) {
- spin_unlock_irqrestore(&mapping->lock, flags);
- return DMA_ERROR_CODE;
+ list_for_each_entry(e, &mapping->iova_ranges, list_head) {
+ start = bitmap_find_next_zero_area(e->bitmap, e->bits, 0,
+ count, align);
+ if (start > e->bits)
+ continue;
+
+ bitmap_set(e->bitmap, start, count);
+ area_found = true;
+ break;
}
- bitmap_set(mapping->bitmap, start, count);
+ /*
+ * Try to extend the existing mapping and perform a second
+ * attempt to reserve an IO virtual address range of size
+ * bytes.
+ */
+ if (!area_found) {
+ if (extend_iommu_mapping(mapping)) {
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ return DMA_ERROR_CODE;
+ }
+ e = list_entry(mapping->iova_ranges.prev,
+ struct dma_iommu_iova_range, list_head);
+ start = bitmap_find_next_zero_area(e->bitmap, e->bits, 0,
+ count, align);
+ if (start > e->bits) {
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ return DMA_ERROR_CODE;
+ }
+ bitmap_set(e->bitmap, start, count);
+ }
spin_unlock_irqrestore(&mapping->lock, flags);
- return mapping->base + (start << (mapping->order + PAGE_SHIFT));
+ return e->base + (start << (mapping->order + PAGE_SHIFT));
}
static inline void __free_iova(struct dma_iommu_mapping *mapping,
dma_addr_t addr, size_t size)
{
- unsigned int start = (addr - mapping->base) >>
- (mapping->order + PAGE_SHIFT);
- unsigned int count = ((size >> PAGE_SHIFT) +
- (1 << mapping->order) - 1) >> mapping->order;
+ struct dma_iommu_iova_range *e;
+ unsigned int start, count, tmp;
unsigned long flags;
- spin_lock_irqsave(&mapping->lock, flags);
- bitmap_clear(mapping->bitmap, start, count);
- spin_unlock_irqrestore(&mapping->lock, flags);
+ list_for_each_entry(e, &mapping->iova_ranges, list_head) {
+ if (!size)
+ break;
+ if ((addr < e->base) || (addr >= e->base + e->size))
+ continue;
+
+ start = (addr - e->base) >> (mapping->order + PAGE_SHIFT);
+ if (addr + size > e->base + e->size) {
+ /*
+ * The address range to be freed crosses an
+ * iova_range boundary.
+ * Hence calc count parameter to fit within
+ * current iova_range and prepare addr and
+ * size for next iteration.
+ */
+ tmp = (e->base + e->size) - addr;
+ count = ((tmp >> PAGE_SHIFT) +
+ (1 << mapping->order) - 1) >> mapping->order;
+ size -= tmp;
+ addr += tmp;
+ } else {
+ count = ((size >> PAGE_SHIFT) +
+ (1 << mapping->order) - 1) >> mapping->order;
+ size -= size;
+ }
+ spin_lock_irqsave(&mapping->lock, flags);
+ bitmap_clear(e->bitmap, start, count);
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ }
}
static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
@@ -1892,6 +1945,7 @@ arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
unsigned int count = size >> (PAGE_SHIFT + order);
unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
struct dma_iommu_mapping *mapping;
+ struct dma_iommu_iova_range *iovar;
int err = -ENOMEM;
if (!count)
@@ -1901,23 +1955,37 @@ arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
if (!mapping)
goto err;
- mapping->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!mapping->bitmap)
+ INIT_LIST_HEAD(&mapping->iova_ranges);
+ spin_lock_init(&mapping->lock);
+
+ iovar = kzalloc(sizeof(struct dma_iommu_iova_range), GFP_KERNEL);
+ if (!iovar)
goto err2;
- mapping->base = base;
- mapping->bits = BITS_PER_BYTE * bitmap_size;
+ iovar->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ if (!iovar->bitmap)
+ goto err3;
+
+ iovar->bits = BITS_PER_BYTE * bitmap_size;
+ list_add_tail(&iovar->list_head, &mapping->iova_ranges);
+
+ mapping->base = iovar->base = base;
+ mapping->size = iovar->size = size;
+
mapping->order = order;
- spin_lock_init(&mapping->lock);
+ mapping->grow_size = grow_size;
+ mapping->max_size = max_size;
mapping->domain = iommu_domain_alloc(bus);
if (!mapping->domain)
- goto err3;
+ goto err4;
kref_init(&mapping->kref);
return mapping;
+err4:
+ kfree(iovar->bitmap);
err3:
- kfree(mapping->bitmap);
+ kfree(iovar);
err2:
kfree(mapping);
err:
@@ -1927,14 +1995,49 @@ EXPORT_SYMBOL_GPL(arm_iommu_create_mapping);
static void release_iommu_mapping(struct kref *kref)
{
+ struct dma_iommu_iova_range *e, *tmp;
struct dma_iommu_mapping *mapping =
container_of(kref, struct dma_iommu_mapping, kref);
iommu_domain_free(mapping->domain);
- kfree(mapping->bitmap);
+ list_for_each_entry_safe(e, tmp, &mapping->iova_ranges, list_head) {
+ list_del(&e->list_head);
+ kfree(e->bitmap);
+ kfree(e);
+ }
kfree(mapping);
}
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping)
+{
+ struct dma_iommu_iova_range *iovar;
+ unsigned int count = mapping->grow_size >> (PAGE_SHIFT + mapping->order);
+ unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
+
+ if (!mapping->grow_size ||
+ (mapping->size + mapping->grow_size) >= mapping->max_size)
+ return -EINVAL;
+
+ iovar = kzalloc(sizeof(struct dma_iommu_iova_range), GFP_ATOMIC);
+ if (!iovar)
+ return -ENOMEM;
+
+ iovar->bitmap = kzalloc(bitmap_size, GFP_ATOMIC);
+ if (!iovar->bitmap) {
+ kfree(iovar);
+ return -ENOMEM;
+ }
+
+ iovar->bits = BITS_PER_BYTE * bitmap_size;
+ iovar->base = mapping->base + mapping->size;
+ iovar->size = mapping->grow_size;
+
+ mapping->size += mapping->grow_size;
+ list_add_tail(&iovar->list_head, &mapping->iova_ranges);
+
+ return 0;
+}
+
void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping)
{
if (mapping)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/11] arm: dma-mapping: Add additional parameters to arm_iommu_create_mapping
From: Andreas Herrmann @ 2014-01-16 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876263-25759-1-git-send-email-andreas.herrmann@calxeda.com>
The new parameters are
dma_addr_t grow_size
Specifies the size by which the mapping will be extended in
case that no sufficient space is left in the mapping to
handle an iova allocation request. If a grow_size of 0 is
specified the mapping is not extended.
dma_addr_t max_size
Specifies the maximum size for the entire mapping --
including all extensions made over time. The mapping can only
be extended if the entire size is less than or equal to
max_size.
Adapt existing calls to arm_iommu_create_mapping in exynos_drm_iommu.c
and shmobile-iommu.c such that they do not make use of the extension
feature.
Adapt existing call to arm_iommu_create_mapping in arm-smmu.c such
that the extension feature will be used.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
---
arch/arm/include/asm/dma-iommu.h | 4 ++--
arch/arm/mm/dma-mapping.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 ++--
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/shmobile-iommu.c | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index a8c56ac..50edacd 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -23,8 +23,8 @@ struct dma_iommu_mapping {
};
struct dma_iommu_mapping *
-arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
- int order);
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
+ int order, dma_addr_t grow_size, dma_addr_t max_size);
void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f61a570..ccea46a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1887,7 +1887,7 @@ struct dma_map_ops iommu_coherent_ops = {
*/
struct dma_iommu_mapping *
arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
- int order)
+ int order, dma_addr_t grow_size, dma_addr_t max_size)
{
unsigned int count = size >> (PAGE_SHIFT + order);
unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index fb8db03..c1cd18b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -40,8 +40,8 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
priv->da_space_order = EXYNOS_DEV_ADDR_ORDER;
mapping = arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
- priv->da_space_size,
- priv->da_space_order);
+ priv->da_space_size,
+ priv->da_space_order, 0, 0);
if (IS_ERR(mapping))
return PTR_ERR(mapping);
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 68bbe45..31414e5 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2124,7 +2124,7 @@ static int arm_smmu_device_notifier(struct notifier_block *nb,
break;
mapping = arm_iommu_create_mapping(&platform_bus_type,
- 0, SZ_128M, 0);
+ 0, SZ_128M, 0, SZ_128M, SZ_2G);
if (IS_ERR(mapping)) {
ret = PTR_ERR(mapping);
dev_info(dev, "arm_iommu_create_mapping failed\n");
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index d572863..1ba3a01 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -343,7 +343,7 @@ static int shmobile_iommu_add_device(struct device *dev)
mapping = archdata->iommu_mapping;
if (!mapping) {
mapping = arm_iommu_create_mapping(&platform_bus_type, 0,
- L1_LEN << 20, 0);
+ L1_LEN << 20, 0, 0, 0);
if (IS_ERR(mapping))
return PTR_ERR(mapping);
archdata->iommu_mapping = mapping;
--
1.7.9.5
^ 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