* [PATCH V3 2/2] ARM: multi_v7_defconfig: add mvebu drivers
From: Olof Johansson @ 2014-02-01 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140201021337.GC8533@titan.lakedaemon.net>
On Fri, Jan 31, 2014 at 6:13 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Fri, Jan 31, 2014 at 03:23:33PM -0800, Olof Johansson wrote:
>> On Tue, Jan 28, 2014 at 07:27:15PM +0000, Jason Cooper wrote:
>> > Recent boot farm testing has highlighted some issues with mvebu and
>> > multiplatform kernels. Increase the test coverage so we can discover
>> > these issues earlier.
>> >
>> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
>> > ---
>> > v2 -> v3:
>> > - rebase onto arm-soc/for-next so arm-soc can apply directly for v3.14-rcX
>> >
>> > v1 -> v2:
>> > - split into two patches, update and +mvebu
>> >
>> > arch/arm/configs/multi_v7_defconfig | 10 ++++++++++
>> > 1 file changed, 10 insertions(+)
>>
>> Applied. I ended up redoing the 1/2 patch myself but this one is applied as-is
>> with minor fixup.
>
> It looks like Kevin applied this yesterday:
>
> 1c53e04e8050 ARM: multi_v7_defconfig: add mvebu drivers
> 64a5cb10bdc5 ARM: multi_v7_defconfig: update for v3.14-rc1
>
> It's in arm-soc/for_3.14/fixes which was pulled into arm-soc/to-build
> yesterday...
>
> confused?
Right, but that conflicted with the tegra updates we had done (which I
told you about before). So I ended up rebuilding the branch to get the
ordering right, which resulted in the above.
-Olof
^ permalink raw reply
* arm-soc for-next branch reset; not all late contents made it in for 3.14
From: Olof Johansson @ 2014-02-01 5:18 UTC (permalink / raw)
To: linux-arm-kernel
I've reset for-next (old contents is in for-next2), and merged in our
first fixes branch into it.
Unfortunately not all late/* branch contents made it in, in particular
some of the stuff we had in late/drivers. If your patches are among
these, please send us fresh pull requests past -rc1.
As far as patches go, we currently should be in sync with what's come
in, and I've made a pass to try to catch any straggling ones. Please
take a look and let us know if we've missed any of your code that we
had queued.
We're also including a few defconfig and dts changes in this batch of
fixes, but we hope to not continue doing too much of that from here on
out. So if you think you need any, let us know sooner rather than
later.
Besides that, we're back to business as usual. :)
-Olof
^ permalink raw reply
* [PATCH] clk: Fix notifier documentation
From: Mike Turquette @ 2014-02-01 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57c43634-23a6-4dcf-8aff-f49961d7f4d6@TX2EHSMHS005.ehs.local>
On Fri, Jan 31, 2014 at 5:49 PM, S?ren Brinkmann
<soren.brinkmann@xilinx.com> wrote:
> ping?
Hi Soren,
I'm a bit slow to review patches during the merge window. Thanks for
the doc update. I'll take it in after -rc1 drops.
Regards,
Mik
>
> On Wed, Jan 22, 2014 at 11:48:37AM -0800, Soren Brinkmann wrote:
>> Contradicting to documenation, the notifier callbacks do receive
>> the original clock rate in struct clk_notifier_data.old_rate and the new
>> frequency struct clk_notifier_data.new_rate, independent of the
>> notification reason.
>>
>> This behavior also seems to make more sense, since callbacks can use the
>> same code to deterimine whether clocks are scaled up or down. Something
>> which would not even possible in the post-rate-change case if the
>> behavior was as documented.
>>
>> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
>> ---
>> Hi Mike,
>>
>> I am working with some clock notifiers and if my results are correct the
>> notifiers behave differently from how they are documented.
>> I think the actual behavior makes more sense than the documented and my original
>> plan was to change the behavior, but it seems I might get away with a
>> doc-update.
>>
>> Thanks,
>> S?ren
>>
>> drivers/clk/clk.c | 15 +++------------
>> 1 file changed, 3 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 2cf2ea6b77a1..26825db03e64 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1983,20 +1983,11 @@ EXPORT_SYMBOL_GPL(devm_clk_unregister);
>> * re-enter into the clk framework by calling any top-level clk APIs;
>> * this will cause a nested prepare_lock mutex.
>> *
>> - * Pre-change notifier callbacks will be passed the current, pre-change
>> - * rate of the clk via struct clk_notifier_data.old_rate. The new,
>> - * post-change rate of the clk is passed via struct
>> + * In all notification cases cases (pre, post and abort rate change) the
>> + * original clock rate is passed to the callback via struct
>> + * clk_notifier_data.old_rate and the new frequency is passed via struct
>> * clk_notifier_data.new_rate.
>> *
>> - * Post-change notifiers will pass the now-current, post-change rate of
>> - * the clk in both struct clk_notifier_data.old_rate and struct
>> - * clk_notifier_data.new_rate.
>> - *
>> - * Abort-change notifiers are effectively the opposite of pre-change
>> - * notifiers: the original pre-change clk rate is passed in via struct
>> - * clk_notifier_data.new_rate and the failed post-change rate is passed
>> - * in via struct clk_notifier_data.old_rate.
>> - *
>> * clk_notifier_register() must be called from non-atomic context.
>> * Returns -EINVAL if called with null arguments, -ENOMEM upon
>> * allocation failure; otherwise, passes along the return value of
>> --
>> 1.8.5.3
>>
>>
>
^ permalink raw reply
* [PATCH] Detect section mismatches in thumb relocations
From: Rusty Russell @ 2014-02-01 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391193193-28572-1-git-send-email-dave.long@linaro.org>
David Long <dave.long@linaro.org> writes:
> From: "David A. Long" <dave.long@linaro.org>
>
> Add processing for normally encountered thumb relocation types so that
> section mismatches will be detected.
>
> Signed-off-by: David A. Long <dave.long@linaro.org>
Happiest for this to go through an ARM tree, so:
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Cheers,
Rusty.
> ---
> scripts/mod/modpost.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 1785576..9e6c996 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1498,6 +1498,16 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
> #define R_ARM_JUMP24 29
> #endif
>
> +#ifndef R_ARM_THM_CALL
> +#define R_ARM_THM_CALL 10
> +#endif
> +#ifndef R_ARM_THM_JUMP24
> +#define R_ARM_THM_JUMP24 30
> +#endif
> +#ifndef R_ARM_THM_JUMP19
> +#define R_ARM_THM_JUMP19 51
> +#endif
> +
> static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
> {
> unsigned int r_typ = ELF_R_TYPE(r->r_info);
> @@ -1511,6 +1521,9 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
> case R_ARM_PC24:
> case R_ARM_CALL:
> case R_ARM_JUMP24:
> + case R_ARM_THM_CALL:
> + case R_ARM_THM_JUMP24:
> + case R_ARM_THM_JUMP19:
> /* From ARM ABI: ((S + A) | T) - P */
> r->r_addend = (int)(long)(elf->hdr +
> sechdr->sh_offset +
> --
> 1.8.1.2
^ permalink raw reply
* [PATCH v2 00/21] pinctrl: mvebu: restructure and remove hardcoded addresses from Dove pinctrl
From: Andrew Lunn @ 2014-02-01 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EB080A.2020200@gmail.com>
On Fri, Jan 31, 2014 at 03:18:50AM +0100, Sebastian Hesselbarth wrote:
> On 01/30/2014 09:25 PM, Andrew Lunn wrote:
> >On Thu, Jan 30, 2014 at 07:50:34PM +0100, Sebastian Hesselbarth wrote:
> >>On 01/30/2014 07:29 PM, Andrew Lunn wrote:
> >>>On Tue, Jan 28, 2014 at 01:39:12AM +0100, Sebastian Hesselbarth wrote:
> >>>>This patch set is one required step for Dove to hop into mach-mvebu.
> >>>>Until now, pinctrl-dove was hardcoding some registers that do not
> >>>>directly belong to MPP core registers. This is not compatible with
> >>>>what we want for mach-mvebu.
> >>>
> >>>I think there might be something wrong here....
> >>
> >>There _is_ something wrong. I'll have a look at it. For the record,
> >>what SoC are you testing with? From the base address, I guess it is
> >>Kirkwood?
> >
> >Yes, Kirkwood. Sorry for not saying.
>
> This time I push a branch before sending out the patches. Also, I
> think I'll postpone removal of hardcoded addresses until this is
> sorted out. The patch set was growing way to quick and I have to
> do this step-by-step for me and everybody else to actually understand ;)
>
> So, at least the MVEBU guys should test the following branch on
> their SoCs. Again, I have tested Dove and now confirmed that settings
> are still correct. The others are compile-tested.
>
> https://github.com/shesselba/linux-dove.git unstable/mvebu-pinctrl-v3.14_v3
Hi Sebastian
Tested on Kirkwood. /debug/pinctrl is now identical with and without
the patch.
I've not looked at the actual patches, but please add a
Tested-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2] arm: keystone: enable watchdog support
From: Ivan Khoronzhuk @ 2014-02-01 12:25 UTC (permalink / raw)
To: linux-arm-kernel
Keystone SoC uses the same watchdog driver as Davinci, so
enable WDT and core used by it.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Conflicts:
arch/arm/configs/keystone_defconfig
---
Rebased on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master
arch/arm/configs/keystone_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index a018244..061ec999 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -131,6 +131,8 @@ CONFIG_SPI_DAVINCI=y
CONFIG_SPI_SPIDEV=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_DAVINCI_WATCHDOG=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2] arm: dts: keystone: add watchdog entry
From: Ivan Khoronzhuk @ 2014-02-01 12:29 UTC (permalink / raw)
To: linux-arm-kernel
Add watchdog entry to keystone device tree.
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Conflicts:
arch/arm/boot/dts/keystone.dtsi
---
Rebased on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master
arch/arm/boot/dts/keystone.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index b420290..3a83ffe 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -208,5 +208,11 @@
usb-phy = <&usb_phy>, <&usb_phy>;
};
};
+
+ wdt: wdt at 022f0080 {
+ compatible = "ti,keystone-wdt","ti,davinci-wdt";
+ reg = <0x022f0080 0x80>;
+ clocks = <&clkwdtimer0>;
+ };
};
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH] ARM: sun7i: dt: Fix interrupt trigger types
From: Maxime Ripard @ 2014-02-01 15:46 UTC (permalink / raw)
To: linux-arm-kernel
The Allwinner A20 uses the ARM GIC as its internal interrupts controller. The
GIC can work on several interrupt triggers, and the A20 was actually setting it
up to use a rising edge as a trigger, while it was actually a level high
trigger, leading to some interrupts that would be completely ignored if the
edge was missed.
Fix this for the remaining DT nodes that slipped through.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: stable at vger.kernel.org
---
arch/arm/boot/dts/sun7i-a20.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 119f066..2374f5a 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -454,7 +454,7 @@
rtc: rtc at 01c20d00 {
compatible = "allwinner,sun7i-a20-rtc";
reg = <0x01c20d00 0x20>;
- interrupts = <0 24 1>;
+ interrupts = <0 24 4>;
};
sid: eeprom at 01c23800 {
@@ -596,10 +596,10 @@
hstimer at 01c60000 {
compatible = "allwinner,sun7i-a20-hstimer";
reg = <0x01c60000 0x1000>;
- interrupts = <0 81 1>,
- <0 82 1>,
- <0 83 1>,
- <0 84 1>;
+ interrupts = <0 81 4>,
+ <0 82 4>,
+ <0 83 4>,
+ <0 84 4>;
clocks = <&ahb_gates 28>;
};
--
1.8.4.2
^ permalink raw reply related
* [PATCH] ARM: hisi: don't select SMP
From: Rob Herring @ 2014-02-01 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131225116.GA6284@quad.lixom.net>
On Fri, Jan 31, 2014 at 4:51 PM, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Jan 31, 2014 at 04:06:30PM -0600, Rob Herring wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> SMP is a user configurable option, not a hardware feature and should not
>> be selected.
>>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>
> Yep, you're right. applied to fixes.
After doing some randconfig builds I found HAVE_ARM_TWD and
HAVE_ARM_SCU need to have "if SMP" added here. I also found OMAP and
SH-Mobile are still using LOCAL_TIMER which has been gone for a year.
I guess everyone tests with other platforms enabled or don't notice
they are using broadcast timer. Patch is coming.
Rob
^ permalink raw reply
* [PATCH 0/3] RFC/RFT: Powering on MMC Wifi/BT modules in MMC core
From: Russell King - ARM Linux @ 2014-02-01 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130214917.GE15937@n2100.arm.linux.org.uk>
On Thu, Jan 30, 2014 at 09:49:17PM +0000, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 07:56:52PM -0800, Olof Johansson wrote:
> > This is a small series enhancing the MMC core code to power on modules
> > before the host in cases where needed, and the corresponding DT bindings
> > changes.
> >
> > I've got some other issues to debug on the Chromebook, i.e. the interface
> > doens't actually work. So far it seems unrelated to this patch set so
> > it's worth posting this and get things going since others need the same
> > functionality (i.e Cubox-i).
> >
> > As mentioned in the patch in the series, I haven't implemented power-down
> > yet, I wanted to make sure that the power-on side will be adequate for
> > those who are looking to use it right away.
> >
> > Comments/test reports/etc welcome.
>
> So, I thought I'd give this a go on the Cubox-i4, and... it doesn't work
> there. It's not your patches, it's down to sdhci-esdhc-imx.c not using
> mmc_of_parse() at all, so those new properties have no way to be used
> there.
>
> It doesn't look like it could in its current form use mmc_of_parse(),
> as the imx code manually parses some of the generic properties to hand
> them into the sdhci layer. This looks icky, and it looks like something
> that should be fixed - why should drivers be parsing the core attributes
> themselves?
Here's an illustration of why it's icky.
If we call mmc_of_parse() in the sdhci-esdhc-imx driver (which we'd need to
do in order to get information on how to configure the card detection etc)
then this fills in mmc->f_max.
However, the subsequent call to sdhci_add_host() computes the maximum clock
from the sdhci capabilities, and then does this:
host->max_clk *= 1000000;
if (host->max_clk == 0 || host->quirks &
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN) {
if (!host->ops->get_max_clock) {
pr_err("%s: Hardware doesn't specify base clock "
"frequency.\n", mmc_hostname(mmc));
return -ENODEV;
}
host->max_clk = host->ops->get_max_clock(host);
}
...
/*
* Set host parameters.
*/
mmc->ops = &sdhci_ops;
mmc->f_max = host->max_clk;
which would have the effect of overwriting a previously set f_max from
the OF data.
There's also the whole "cd-gpios" thing which would need sorting out -
the imx sdhci driver already parses this property itself, and sets its
own internal data (so it knows whether it has to use the controller
based card detect or the gpio card detect) and simply adding a call to
mmc_of_parse() would result in the gpio slot stuff being setup twice.
The obvious solution here is to rewrite the sdhci initialisation such
that it uses the generic infrastructure, but I don't have the motivation
to do that (I've already plenty of patches to deal with that I don't
need any more at the moment.)
A simpler solution would be to split mmc_of_parse() so that the new bits
are a separate function, which the generic MMC core always calls for
every host - taking the decision over whether this is supported completely
away from hosts. I think that makes a lot of sense, especially as this
has nothing to do with the facilities found on any particular host.
There's another issue here about resets. Let's take the case where the
external card is powered off, but has active high resets. At the moment,
the sequence is this:
power: _____/~~~~~~~~~~~~
reset: __/~~~~\__________
That's not particularly nice, as the reset signal will tend do drive power
into the device before it's powered up via the clamping diodes in the case.
Generally, devices are not designed to be powered in this way. However,
this is a relatively minor issue though compared to this one, which is what
happens if the card uses active low reset:
power: _____/~~~~~~~~~~~~
reset: ~~\_____/~~~~~~~~~
This is definitely not good, because it means that the reset is higher for
longer, which may result in unacceptable dissapation in the package from
those clamping diodes. What we need instead is for active low reset is:
power: _____/~~~~~~~~~~~~
reset: ________/~~~~~~~~~
So, we need the GPIO layer to tell us whether the output is active high or
active low and adjust the initial setting accordingly. Basically, whenever
the attached device is powered down, GPIOs to it should be held at low level
or high impedance (with a pull-down to reduce the risks of ESD damage.)
I've seen designs get this wrong in the past - Intel Assabet is a good one
where the UDA1341 audio codec ends up illuminating a LED by being powered
not via it's supply pin, but by a CPLD output driving one of the I2S pins
high. The result is that the CPLD output sources quite a bit of current
into the UDA1341, which then holds other pins on the SA1110 around mid-rail,
which is the /worst/ thing you can do with CMOS. Powering chips via their
inputs is basically a big no-no.
So, I think something like the below is needed on top of your patches.
Note that I added -EPROBE_DEFER handling too (which fixes a bug, because
regulator_get() returns pointer-errors):
drivers/mmc/core/host.c | 90 +++++++++++++++++++++++++++-----------
1 files changed, 65 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index e6b850b3241f..64942eb495b6 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -316,7 +316,7 @@ int mmc_of_parse(struct mmc_host *host)
u32 bus_width;
bool explicit_inv_wp, gpio_inv_wp = false;
enum of_gpio_flags flags;
- int i, len, ret, gpio;
+ int len, ret, gpio;
if (!host->parent || !host->parent->of_node)
return 0;
@@ -419,30 +419,6 @@ int mmc_of_parse(struct mmc_host *host)
if (explicit_inv_wp ^ gpio_inv_wp)
host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
- /* Parse card power/reset/clock control */
- if (of_find_property(np, "card-reset-gpios", NULL)) {
- struct gpio_desc *gpd;
- for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
- gpd = devm_gpiod_get_index(host->parent, "card-reset", i);
- if (IS_ERR(gpd))
- break;
- gpiod_direction_output(gpd, 0);
- host->card_reset_gpios[i] = gpd;
- }
-
- gpd = devm_gpiod_get_index(host->parent, "card-reset", ARRAY_SIZE(host->card_reset_gpios));
- if (!IS_ERR(gpd)) {
- dev_warn(host->parent, "More reset gpios than we can handle");
- gpiod_put(gpd);
- }
- }
-
- host->card_clk = of_clk_get_by_name(np, "card_ext_clock");
- if (IS_ERR(host->card_clk))
- host->card_clk = NULL;
-
- host->card_regulator = regulator_get(host->parent, "card-external-vcc");
-
if (of_find_property(np, "cap-sd-highspeed", &len))
host->caps |= MMC_CAP_SD_HIGHSPEED;
if (of_find_property(np, "cap-mmc-highspeed", &len))
@@ -467,6 +443,66 @@ int mmc_of_parse(struct mmc_host *host)
EXPORT_SYMBOL(mmc_of_parse);
+static int mmc_of_parse_child(struct mmc_host *host)
+{
+ struct device_node *np;
+ struct clk *clk;
+ int i;
+
+ if (!host->parent || !host->parent->of_node)
+ return 0;
+
+ np = host->parent->of_node;
+
+ host->card_regulator = regulator_get(host->parent, "card-external-vcc");
+ if (IS_ERR(host->card_regulator)) {
+ if (PTR_ERR(host->card_regulator) == -EPROBE_DEFER)
+ return PTR_ERR(host->card_regulator);
+ host->card_regulator = NULL;
+ }
+
+ /* Parse card power/reset/clock control */
+ if (of_find_property(np, "card-reset-gpios", NULL)) {
+ struct gpio_desc *gpd;
+ int level = 0;
+
+ /*
+ * If the regulator is enabled, then we can hold the
+ * card in reset with an active high resets. Otherwise,
+ * hold the resets low.
+ */
+ if (host->card_regulator && regulator_is_enabled(host->card_regulator))
+ level = 1;
+
+ for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
+ gpd = devm_gpiod_get_index(host->parent, "card-reset", i);
+ if (IS_ERR(gpd)) {
+ if (PTR_ERR(gpd) == -EPROBE_DEFER)
+ return PTR_ERR(gpd);
+ break;
+ }
+ gpiod_direction_output(gpd, gpiod_is_active_low(gpd) | level);
+ host->card_reset_gpios[i] = gpd;
+ }
+
+ gpd = devm_gpiod_get_index(host->parent, "card-reset", ARRAY_SIZE(host->card_reset_gpios));
+ if (!IS_ERR(gpd)) {
+ dev_warn(host->parent, "More reset gpios than we can handle");
+ gpiod_put(gpd);
+ }
+ }
+
+ clk = of_clk_get_by_name(np, "card_ext_clock");
+ if (IS_ERR(clk)) {
+ if (PTR_ERR(clk) == -EPROBE_DEFER)
+ return PTR_ERR(clk);
+ clk = NULL;
+ }
+ host->card_clk = clk;
+
+ return 0;
+}
+
/**
* mmc_alloc_host - initialise the per-host structure.
* @extra: sizeof private data structure
@@ -546,6 +582,10 @@ int mmc_add_host(struct mmc_host *host)
{
int err;
+ err = mmc_of_parse_child(host);
+ if (err)
+ return err;
+
WARN_ON((host->caps & MMC_CAP_SDIO_IRQ) &&
!host->ops->enable_sdio_irq);
--
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 related
* [PATCH] ARM: hisi: don't select SMP
From: Olof Johansson @ 2014-02-01 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJPVDQ1_gpMKWxMpUYcU0HyedrNvOsu0qa2gZnXnDUHbA@mail.gmail.com>
On Sat, Feb 1, 2014 at 7:52 AM, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Jan 31, 2014 at 4:51 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Fri, Jan 31, 2014 at 04:06:30PM -0600, Rob Herring wrote:
>>> From: Rob Herring <robh@kernel.org>
>>>
>>> SMP is a user configurable option, not a hardware feature and should not
>>> be selected.
>>>
>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>
>> Yep, you're right. applied to fixes.
>
> After doing some randconfig builds I found HAVE_ARM_TWD and
> HAVE_ARM_SCU need to have "if SMP" added here. I also found OMAP and
> SH-Mobile are still using LOCAL_TIMER which has been gone for a year.
> I guess everyone tests with other platforms enabled or don't notice
> they are using broadcast timer. Patch is coming.
Yep, I noticed the same yesterday but please send the patch over and
I'll apply it before sending up the current batch.
The OMAP platform that uses LOCAL_TIMER is OMAP5, and 5 isn't
functional in mainline yet -- I can guarantee you that nobody is
testing it. :(
-Olof
^ permalink raw reply
* [PATCH v3 3/5] ASoC: tda998x: add DT documentation of the tda998x CODEC
From: Jean-Francois Moine @ 2014-02-01 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391274627.git.moinejf@free.fr>
This patch adds the DT documentation of the NXP TDA998x CODEC.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index d7df01c..aa0d81b 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -15,6 +15,17 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>
+Optional subnodes:
+
+ - codec: audio CODEC
+
+Required codec subnode properties:
+ - compatible: must be "nxp,tda998x-codec".
+ - audio-ports: one or two values corresponding to entries in
+ the audio-port-names property.
+ - audio-port-names: must contain "i2s", "spdif" entries
+ matching entries in the audio-ports property.
+
Example:
tda998x: hdmi-encoder {
@@ -24,4 +35,10 @@ Example:
interrupts = <27 2>; /* falling edge */
pinctrl-0 = <&pmx_camera>;
pinctrl-names = "default";
+ hdmi_codec: codec {
+ compatible = "nxp,tda998x-codec";
+ audio-ports = <0x03>, <0x04>;
+ audio-port-names = "i2s", "spdif";
+ #sound-dai-cells = <1>;
+ };
};
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 0/5] add a TDA998x CODEC
From: Jean-Francois Moine @ 2014-02-01 17:10 UTC (permalink / raw)
To: linux-arm-kernel
The TDA998x HDMI transmitter accepts audio input from either I2S or
S/PDIF.
Theses inputs have different intrinsic constraints and these constraints
may be modified by the audio parameters of the connected video device.
The choice of I2S or S/PDIF may be the done by the user or by automatic
processing (DPCM?) at each audio starting time. This asks for a dynamic
audio input switch in the HDMI driver.
This patch series implements the TDA998x specific CODEC.
A simple function call mechanism is used for exchanges between the
CODEC and the HDMI driver.
Note: the changes in the TDA998x I2C driver are based on my previous
patch series:
http://lists.freedesktop.org/archives/dri-devel/2014-January/052837.html
- v3
- move the DT description of the CODEC as a subnode of the
TDA998x I2C (Mark Brown remark - is this the right way?)
- change CODEC loading mechanism
- simplify tda998x i2c reference search
- CODEC DT documentation in drm/i2c/tda998x.txt
- v2
- add ACLK setting and code optimization in patch 1
- from Mark Brown's remarks in patch 2:
- don't compile the codec when CONFIG_ALL_CODECS
- simplify the code about start/stop audio
- fix coding style errors
- add audio-port-names associated to audio-ports
- add audio-port-names in patch 4
- add patch 5 'adjust the audio CTS_N pre-divider from audio format'
for the Beaglebone-Black board (Jyri Sarha)
Jean-Francois Moine (5):
drm/i2c: tda998x: add a function for dynamic audio input switch
ASoC: tda998x: add a codec driver for the TDA998x
ASoC: tda998x: add DT documentation of the tda998x CODEC
ASoC: tda998x: adjust the audio hw parameters from EDID
ASoC: tda998x: adjust the audio CTS_N pre-divider from audio format
.../devicetree/bindings/drm/i2c/tda998x.txt | 17 ++
drivers/gpu/drm/i2c/tda998x_drv.c | 86 +++++-
include/drm/i2c/tda998x.h | 11 +-
sound/soc/codecs/Kconfig | 6 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tda998x.c | 303 +++++++++++++++++++++
6 files changed, 419 insertions(+), 6 deletions(-)
create mode 100644 sound/soc/codecs/tda998x.c
--
1.9.rc1
^ permalink raw reply
* [PATCH 0/3] spi: core: Introduce devm_spi_alloc_master
From: Mark Brown @ 2014-02-01 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131133111.GF2950@lukather>
On Fri, Jan 31, 2014 at 02:31:11PM +0100, Maxime Ripard wrote:
> On Fri, Jan 31, 2014 at 12:12:15PM +0000, Mark Brown wrote:
> > This seems confusing - the idea here is that if we've handed the device
> > off to the managed function then the managed function deals with
> > destroying it. Note that spi_alloc_master() says that the put is only
> > required after errors adding the device (which would be the expected
> > behaviour if you look at other APIs). Looking at the code I think there
> > is an issue here but I'm not at all clear that this is the best fix.
> Ah, right, spi_master_put doesn't free the memory either...
The memory is freed by the driver core calling the spi_master_release()
callback when it's safe to do so (after the last reference to the device
has gone away).
> I guess we have a few choices here, either:
> - Add a devm_kzalloc to spi_alloc_master, since most of the drivers
> I've been looking at fail to free the memory, this would be the
> least intrusive solution. We'd still have to remove all the kfree
> calls in the driver that rightfully free the memory.
> - Make devm_unregister_master also call kfree on the master
> - Add a kfree to my devm_put_master so that the memory is reclaimed,
> which isn't the case for now.
> I don't have a strong preference here, maybe for the third one, since
> it makes obvious that it's managed and you don't have to do anything
> about it, while the other do not.
None of the above, definitely nothing to do with calling kfree() once
the device is registered. We already have that free, it's not the
issue. The issue is making sure that we hold references when we need
them and drop them when we don't. I (or someone) needs to sit down and
think it through since things are a bit confused in the code.
-------------- 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/20140201/40180c68/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
From: Robert Jarzmik @ 2014-02-01 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ha8y76rn.fsf@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
>> Hi Arnd,
>>
>> I cannot reach Haojian, and my platform is currently screen-broken without
>> Thierry's patch (see [1] and [2]). I'm trying to have it since -rc6, with no luck.
... zip ...
Hi Eric and Russell,
Since more than a month I've been trying to have a fix applied in the PXA tree,
since v3.13-rc6. I cannot reach Haojian, and Arnd seems unresponsive too.
The history mails are in [1], the patch in [2].
Your are the 2 other maintainers of the PXA tree, Could you please help me ?
Cheers.
--
Robert
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/223116.html
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/221013.html
---8>---
From: Thierry Reding <thierry.reding@gmail.com>
Subject: [PATCH] ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
To: Haojian Zhuang <haojian.zhuang@gmail.com>, Robert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-pwm at vger.kernel.org, linux-arm-kernel at lists.infradead.org
Date: Fri, 20 Dec 2013 10:46:52 +0100 (6 weeks, 1 day, 8 hours ago)
Message-Id: <1387532812-11742-1-git-send-email-thierry.reding@gmail.com>
X-Mailer: git-send-email 1.8.4.2
Recent changes to the pwm-backlight driver have made the power supply
mandatory. There is code in the regulator core to deal with situations
where no regulator is specified and provide a dummy, but that works on
DT-based boards only.
The situation can be remedied by adding a dummy regulator during board
initialization.
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
---
arch/arm/mach-pxa/mioa701.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index f70583fee59f..29997bde277d 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -38,6 +38,7 @@
#include <linux/mtd/physmap.h>
#include <linux/usb/gpio_vbus.h>
#include <linux/reboot.h>
+#include <linux/regulator/fixed.h>
#include <linux/regulator/max1586.h>
#include <linux/slab.h>
#include <linux/i2c/pxa-i2c.h>
@@ -714,6 +715,10 @@ static struct gpio global_gpios[] = {
{ GPIO56_MT9M111_nOE, GPIOF_OUT_INIT_LOW, "Camera nOE" },
};
+static struct regulator_consumer_supply fixed_5v0_consumers[] = {
+ REGULATOR_SUPPLY("power", "pwm-backlight"),
+};
+
static void __init mioa701_machine_init(void)
{
int rc;
@@ -753,6 +758,10 @@ static void __init mioa701_machine_init(void)
pxa_set_i2c_info(&i2c_pdata);
pxa27x_set_i2c_power_info(NULL);
pxa_set_camera_info(&mioa701_pxacamera_platform_data);
+
+ regulator_register_always_on(0, "fixed-5.0V", fixed_5v0_consumers,
+ ARRAY_SIZE(fixed_5v0_consumers),
+ 5000000);
}
static void mioa701_machine_exit(void)
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Lars-Peter Clausen @ 2014-02-01 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131174451.GA20512@qualcomm.com>
On 01/31/2014 06:44 PM, Andy Gross wrote:
> On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
>> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
>>> Hi Lars,
>>>
>>> On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>>>> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
>>>> [...]
>>>>> +/**
>>>>> + * xilinx_vdma_device_control - Configure DMA channel of the device
>>>>> + * @dchan: DMA Channel pointer
>>>>> + * @cmd: DMA control command
>>>>> + * @arg: Channel configuration
>>>>> + *
>>>>> + * Return: '0' on success and failure value on error
>>>>> + */
>>>>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
>>>>> + enum dma_ctrl_cmd cmd, unsigned long arg)
>>>>> +{
>>>>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
>>>>> +
>>>>> + switch (cmd) {
>>>>> + case DMA_TERMINATE_ALL:
>>>>> + xilinx_vdma_terminate_all(chan);
>>>>> + return 0;
>>>>> + case DMA_SLAVE_CONFIG:
>>>>> + return xilinx_vdma_slave_config(chan,
>>>>> + (struct xilinx_vdma_config *)arg);
>>>>
>>>> You really shouldn't be overloading the generic API with your own semantics.
>>>> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
>>>
>>> Ok. The driver needs few additional configuration from the slave
>>> device like Vertical
>>> Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
>>> suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
>>> defined for Freescale drivers?
>>
>> In my opinion it is not a good idea to have driver implement a generic API,
>> but at the same time let the driver have custom semantics for those API
>> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
>> values passed to gpio_set_value instead of 0 and 1. It completely defeats
>> the purpose of a generic API, namely that you are able to write generic code
>> that makes use of the API without having to know about which implementation
>> API it is talking to. The dmaengine framework provides the
>> dmaengine_prep_interleaved_dma() function to setup two dimensional
>> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
>>
>
> The comments in the include/linux/dmaengine.h state that if you have
> non-generic, non-fixed configuration then you can just create your own
> structure and embed the dma_slave_config. Using the container_of you can get
> back your structure.
We should probably revise that, since it is not going to work that well.
>
> I agree that we should always use the generic structure if possible, but
> sometimes there are some non-standard things that you have to do for your
> hardware. I am currently in a bind for adding some quirky features that are
> required by peripherals who want to use the QCOM DMA devices.
Well there are two types of extensions to the API. The first type changes the
semantics of the API so it is no longer possible to use the API without knowing
about the extension. This is in my opinion a complete no-go since goes against
the very idea of a common API. If you implement the common API with custom
semantics you have a custom API. It's just better hidden since you use the same
function names. My opinion on this is if you want/need a custom API make it a
custom API with custom function names. This on one hand avoids confusion about
the behavior and on the other hand reduces the maintenance burden for the
common API (e.g. if somebody makes changes to the common API they don't have to
bother to update your driver and don't have to try to understand the custom
semantics). The other kind of extensions are those that add additional
functionality on top of the common API, while keeping the normal semantics for
the common API. Which means a user that does not know about the extensions is
still able to function. A user that knows about the extension can make use of
the additional features.
That said, everybody always thinks their hardware is special and requires
special extensions. Usually this is not the case, there will always sooner or
later somebody else who needs the same extensions. The dmaengine API is not set
in stone, so if you think something is missing to properly to support your
hardware it is worth investigating if it makes sense to add the missing parts
to the common API. As I said before the whole point of the exercise of having a
common API is that we want to abstract away (hardware) implementation specific
details. This allows the upper layers to have platform independent common code
to take care of setting up the DMA transfers. E.g. in ALSA subsystem we went
from 10+ custom implementations of a PCM driver build on top of dmaengine to 1
generic implementation that is shared between platforms. All those custom PCM
drivers had hardcoded assumptions about the behavior and features of the
underlying dmaengine driver. To be able to have one generic PCM driver it was
necessarily to extend the dmaengine API to be able to expose these differences
in features and behavior. So as I said the API is not set in stone if it is
necessary to extend or modify it to support something properly do it. Other
subsystems also want to go the direction of having more shared code that makes
use of the dmaengine API at the subsytem level rather than having every driver
basically implement the same stuff (with slight variations) over and over
again. Having custom extensions in your dmaengine will not make it possible to
write a generic user.
>
> If the context field in prep_slave_sg and prep_dma_cyclic was exposed to
> everyone, that would allow an easy way to pass in hardware specific
> configuration without bastardizing the slave_config. I noticed that rapidio is
> the only consumer of that field and that they have their own prep function.
>
> If we are not going to allow people to do their own slave_config when they need
> to, then we need to remove the comments from the include file and expose the
> context to the dmaengine_prep_slave_sg and dmaengine_prep_dma_cyclic.
I don't think the way the rapidio stuff is handled is good for the reasons
stated above. It uses the same names, but has different semantics. A user of
the dmaengine interface that does not know that the underlying dmaengine driver
expects rapidio semantics does not work.
- Lars
^ permalink raw reply
* [PATCH v3 3/5] ASoC: tda998x: add DT documentation of the tda998x CODEC
From: Sergei Shtylyov @ 2014-02-01 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e4231b7a55802f58a14dd07ac5cd8b0babb1dce.1391274628.git.moinejf@free.fr>
Hello.
On 01-02-2014 20:48, Jean-Francois Moine wrote:
> This patch adds the DT documentation of the NXP TDA998x CODEC.
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> index d7df01c..aa0d81b 100644
> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
[...]
> @@ -24,4 +35,10 @@ Example:
> interrupts = <27 2>; /* falling edge */
> pinctrl-0 = <&pmx_camera>;
> pinctrl-names = "default";
> + hdmi_codec: codec {
This line is indented too far to the right.
> + compatible = "nxp,tda998x-codec";
> + audio-ports = <0x03>, <0x04>;
> + audio-port-names = "i2s", "spdif";
> + #sound-dai-cells = <1>;
> + };
> };
WBR, Sergei
^ permalink raw reply
* [PATCH] ARM: mm: Fix the memblock allocation for LPAE machines
From: Santosh Shilimkar @ 2014-02-01 20:14 UTC (permalink / raw)
To: linux-arm-kernel
Commit ad6492b8 added much needed memblock_virt_alloc_low() and further
commit 07bacb3 {memblock, bootmem: restore goal for alloc_low} fixed the
issue with low memory limit thansk to Yinghai. But even after all these fixes,
there is still one case where the limit check done with ARCH_LOW_ADDRESS_LIMIT
for low memory fails. Russell pointed out the issue with 32 bit LPAE machines
in below thread.
https://lkml.org/lkml/2014/1/28/364
Since on some LPAE machines where memory start address is beyond 4GB,
the low memory marker in memblock will be set to default
ARCH_LOW_ADDRESS_LIMIT which is wrong. We can fix this by letting
architectures set the ARCH_LOW_ADDRESS_LIMIT using another export
similar to memblock_set_current_limit() but am not sure whether
its worth the trouble. Tell me if you think otherwise.
Rather am just trying to fix that one broken case using memblock_virt_alloc()
in setup code since the memblock.current_limit is updated appropriately
makes it work on all ARM 32 bit machines.
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Strashko, Grygorii <grygorii.strashko@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b0df976..1e8b030 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -731,7 +731,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
kernel_data.end = virt_to_phys(_end - 1);
for_each_memblock(memory, region) {
- res = memblock_virt_alloc_low(sizeof(*res), 0);
+ res = memblock_virt_alloc(sizeof(*res), 0);
res->name = "System RAM";
res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] ARM: SoC "fixes" for 3.14-rc1
From: Olof Johansson @ 2014-02-01 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
See tag for branch contents. As you'll see, the commit dates are recent;
we've mostly collected these fixes in the last few days but I also had
to rebuild the branch yesterday to sort out some internal conflicts
which reset the timestamps. The changes should have been tested by each
platform maintainer already (and few of them have cross-platform impact)
so I'm personally not too concerned by it at this time.
Please pull.
Thanks!
-Olof
The following changes since commit e7651b819e90da924991d727d3c007200a18670d:
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs (2014-01-30 20:08:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus
for you to fetch changes up to f39aa2753724215706d150fac5cb4a989793faef:
ARM: multi_v7_defconfig: remove redundant entries and re-enable TI_EDMA (2014-01-31 21:04:33 -0800)
----------------------------------------------------------------
ARM: SoC fixes for 3.14-rc1
Here's a set of patches for (hopefully) -rc1. Some of them are fixes,
but a good number of them also do things such as enable new drivers in
the defconfigs for platforms that have such devices, increases coverage
of the multiplatform defconfig and some DTS changes that plumbs up some
of the devices that now have bindings and driver support.
----------------------------------------------------------------
Arnaud Ebalard (1):
ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP)
Barry Song (1):
MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
Ben Dooks (1):
ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference
Ezequiel Garcia (1):
ARM: kirkwood: kirkwood_pm_init() should return void
Fabio Estevam (1):
ARM: multi_v7_defconfig: Select CONFIG_AT803X_PHY
Gregory CLEMENT (1):
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed
Grygorii Strashko (1):
ARM: keystone: config: fix build warning when CONFIG_DMADEVICES is not set
Linus Walleij (2):
ARM: integrator: restore static map on the CP
ARM: iop32x: fix power off handling for the EM7210 board
Lorenzo Pieralisi (1):
drivers: bus: fix CCI driver kcalloc call parameters swap
Nishanth Menon (1):
ARM: OMAP4+: move errata initialization to omap4_pm_init_early
Olof Johansson (4):
Merge tag 'mvebu-fixes-3.13-2' of git://git.infradead.org/linux-mvebu into fixes
Merge tag 'renesas-dt-fixes2-for-v3.14' of git://git.kernel.org/.../horms/renesas into fixes
ARM: multi_v7_defconfig: add mvebu drivers
ARM: multi_v7_defconfig: remove redundant entries and re-enable TI_EDMA
Rob Herring (1):
ARM: hisi: don't select SMP
Sebastian Hesselbarth (1):
ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER
Soren Brinkmann (1):
ARM: dts: zynq: Add SDHCI nodes
Stephen Boyd (2):
ARM: dts: msm: Add clock controller nodes and hook into uart
ARM: msm_defconfig: Enable MSM clock drivers
Stephen Warren (2):
ARM: multi_v7: copy most options from tegra_defconfig
ARM: tegra: rebuild tegra_defconfig to add DEBUG_FS
Strashko, Grygorii (1):
ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
Tim Kryger (2):
ARM: dts: bcm28155-ap: Fix Card Detection GPIO
clocksource: kona: Add basic use of external clock
MAINTAINERS | 9 +-
arch/arm/boot/dts/bcm28155-ap.dts | 4 +-
arch/arm/boot/dts/qcom-msm8660-surf.dts | 11 +++
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 18 ++++
arch/arm/boot/dts/qcom-msm8974.dtsi | 24 +++++
arch/arm/boot/dts/r8a7790.dtsi | 8 +-
arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++
arch/arm/boot/dts/zynq-zc702.dts | 4 +
arch/arm/boot/dts/zynq-zc706.dts | 4 +
arch/arm/boot/dts/zynq-zed.dts | 4 +
arch/arm/configs/keystone_defconfig | 1 +
arch/arm/configs/msm_defconfig | 4 +
arch/arm/configs/multi_v7_defconfig | 154 ++++++++++++++++++++++++++++--
arch/arm/configs/tegra_defconfig | 11 +--
arch/arm/mach-hisi/Kconfig | 1 -
arch/arm/mach-integrator/integrator_cp.c | 6 ++
arch/arm/mach-iop32x/em7210.c | 32 ++++++-
arch/arm/mach-keystone/Kconfig | 1 -
arch/arm/mach-kirkwood/pm.c | 4 +-
arch/arm/mach-mvebu/mvebu-soc-id.c | 2 +-
arch/arm/mach-omap2/common.h | 7 ++
arch/arm/mach-omap2/cpuidle44xx.c | 26 ++++-
arch/arm/mach-omap2/io.c | 1 +
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 3 +
arch/arm/mach-omap2/omap-smp.c | 6 +-
arch/arm/mach-omap2/omap4-common.c | 6 ++
arch/arm/mach-omap2/pm44xx.c | 15 +++
arch/arm/plat-orion/irq.c | 47 +++++++++
drivers/bus/arm-cci.c | 2 +-
drivers/clocksource/bcm_kona_timer.c | 14 ++-
drivers/irqchip/irq-armada-370-xp.c | 4 +-
31 files changed, 396 insertions(+), 57 deletions(-)
^ permalink raw reply
* [PATCH v7 0/7] ARM: rockchip: add smp functionality
From: Philipp Zabel @ 2014-02-01 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13010296.nzTT2PqdSR@phil>
Hi Heiko,
On Fri, Jan 31, 2014 at 11:03:03PM +0100, Heiko St?bner wrote:
> On Monday, 20. January 2014 16:41:43 Heiko St?bner wrote:
> > This series enables the use of the additional cores on Rockchip
> > Cortex-A9 SoCs.
>
> So, two weeks without any general complaints, but I guess part of the more
> general patches could use an ack.
>
> Going forward, what would be best way to merge them?
> As one pull request to arm-soc, or for example splitting them into the first
> three patches going through the misc tree and the rockchip specific stuff going
> through arm-soc? Or something else altogether?
>
>
> > Heiko Stuebner (7):
> > of: add functions to count number of elements in a property
>
> One of the intermediate versions of this patch got a
> Reviewed-by: Mark Rutland <mark.rutland@arm.com> .
> Mark, is this still true for this variant addressing some additional wished
> from Rob?
>
> And this final version got a "Looks good" from Rob Herring in the original
> thread, but a more formal "ack" might be nice :-) .
>
>
> > dt-bindings: sram: describe option to reserve parts of the memory
> > misc: sram: implement mmio-sram-reserved option
>
> Philipp, you acked an intermediate version, and this v7 now should also
> contain the two separate loops (1st gathering data and 2nd creating the pool
> parts) you asked for.
>
> Could I persuade you to take a look again?
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH] ARM: hisi: don't select SMP
From: Rob Herring @ 2014-02-01 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgQG=ozUDZzp2Pu7uLt3EZRxaBM-kO3XZJ0y+RDdaLqeA@mail.gmail.com>
On Sat, Feb 1, 2014 at 10:43 AM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Feb 1, 2014 at 7:52 AM, Rob Herring <robherring2@gmail.com> wrote:
>> On Fri, Jan 31, 2014 at 4:51 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Fri, Jan 31, 2014 at 04:06:30PM -0600, Rob Herring wrote:
>>>> From: Rob Herring <robh@kernel.org>
>>>>
>>>> SMP is a user configurable option, not a hardware feature and should not
>>>> be selected.
>>>>
>>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>>
>>> Yep, you're right. applied to fixes.
>>
>> After doing some randconfig builds I found HAVE_ARM_TWD and
>> HAVE_ARM_SCU need to have "if SMP" added here. I also found OMAP and
>> SH-Mobile are still using LOCAL_TIMER which has been gone for a year.
>> I guess everyone tests with other platforms enabled or don't notice
>> they are using broadcast timer. Patch is coming.
>
> Yep, I noticed the same yesterday but please send the patch over and
> I'll apply it before sending up the current batch.
>
> The OMAP platform that uses LOCAL_TIMER is OMAP5, and 5 isn't
> functional in mainline yet -- I can guarantee you that nobody is
> testing it. :(
Actually that is needed for OMAP4 as ARM_TWD is the Cortex-A9 timers.
Rob
^ permalink raw reply
* [PATCH 0/3] kconfig selection fixes
From: Rob Herring @ 2014-02-01 22:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
Olof,
Here are a few kconfig select fixes. The first one can be squashed into
my previous patch for HiSilicon removing SMP select if you want to.
I'm still looking into the cpufreq select issue with highbank. I'll
follow-up with Viresh on that.
Rob
Rob Herring (3):
ARM: hisi: fix kconfig warning on HAVE_ARM_TWD
ARM: moxart: move DMA_OF selection to driver
ARM: fix HAVE_ARM_TWD selection for OMAP and shmobile
arch/arm/mach-hisi/Kconfig | 2 +-
arch/arm/mach-moxart/Kconfig | 1 -
arch/arm/mach-omap2/Kconfig | 2 +-
arch/arm/mach-shmobile/Kconfig | 2 +-
drivers/dma/Kconfig | 1 +
5 files changed, 4 insertions(+), 4 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/3] ARM: hisi: fix kconfig warning on HAVE_ARM_TWD
From: Rob Herring @ 2014-02-01 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391294144-27787-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Commit "ARM: hisi: don't select SMP" introduced a kconfig warning:
warning: (ARCH_HI3xxx) selects HAVE_ARM_TWD which has unmet direct dependencies (SMP)
Fix HAVE_ARM_TWD to depend on SMP.
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-hisi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index 8f4649b..1abae5f 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -8,7 +8,7 @@ config ARCH_HI3xxx
select CLKSRC_OF
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
- select HAVE_ARM_TWD
+ select HAVE_ARM_TWD if SMP
select HAVE_SMP
select PINCTRL
select PINCTRL_SINGLE
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] ARM: moxart: move DMA_OF selection to driver
From: Rob Herring @ 2014-02-01 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391294144-27787-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
Move the DMA_OF selection to the DMA driver to fix kconfig warning:
warning: (ARCH_MOXART) selects DMA_OF which has unmet direct dependencies (DMADEVICES && OF)
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-moxart/Kconfig | 1 -
drivers/dma/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-moxart/Kconfig b/arch/arm/mach-moxart/Kconfig
index ba470d6..3795ae2 100644
--- a/arch/arm/mach-moxart/Kconfig
+++ b/arch/arm/mach-moxart/Kconfig
@@ -2,7 +2,6 @@ config ARCH_MOXART
bool "MOXA ART SoC" if ARCH_MULTI_V4T
select CPU_FA526
select ARM_DMA_MEM_BUFFERABLE
- select DMA_OF
select USE_OF
select CLKSRC_OF
select CLKSRC_MMIO
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9bed1a2..605b016 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -346,6 +346,7 @@ config MOXART_DMA
tristate "MOXART DMA support"
depends on ARCH_MOXART
select DMA_ENGINE
+ select DMA_OF
select DMA_VIRTUAL_CHANNELS
help
Enable support for the MOXA ART SoC DMA controller.
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/3] ARM: fix HAVE_ARM_TWD selection for OMAP and shmobile
From: Rob Herring @ 2014-02-01 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391294144-27787-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <robh@kernel.org>
The selection of HAVE_ARM_TWD for OMAP and shmobile depend on LOCAL_TIMER
which no longer exists. They should depend on SMP instead.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-omap2/Kconfig | 2 +-
arch/arm/mach-shmobile/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 653b489..e2ce4f8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -54,7 +54,7 @@ config SOC_OMAP5
select ARM_GIC
select CPU_V7
select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if LOCAL_TIMERS
+ select HAVE_ARM_TWD if SMP
select HAVE_SMP
select HAVE_ARM_ARCH_TIMER
select ARM_ERRATA_798181 if SMP
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3386406..05fa505 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -8,7 +8,7 @@ config ARCH_SHMOBILE_MULTI
select CPU_V7
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if LOCAL_TIMERS
+ select HAVE_ARM_TWD if SMP
select HAVE_SMP
select ARM_GIC
select MIGHT_HAVE_CACHE_L2X0
--
1.8.3.2
^ 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