* [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 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: 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] 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 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 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 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] 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] 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
* 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 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
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Mike Turquette @ 2014-02-01 4:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2009408.gnUEcoqA3p@phil>
Quoting Heiko St?bner (2014-01-30 07:09:04)
> On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote:
> > Hi Mike,
> >
> > On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette <mturquette@linaro.org>
> wrote:
> > > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham <ta.omasab@gmail.com>
> wrote:
> > >> Hi Mike,
> > >>
> > >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette <mturquette@linaro.org>
> wrote:
> > >>> Quoting Thomas Abraham (2014-01-18 04:10:51)
> > >>>
> > > As far as I can tell
> > > the remux does not happen because it is necessary to generate the
> > > required clock rate, but because we don't want to run the ARM core out
> > > of spec for a short time while the PLL relocks. Assuming I have that
> > > part of it right, I prefer for the parent mux operation to be a part
> > > of the CPUfreq driver's .target callback instead of hidden away in the
> > > clock driver.
> >
> > The re-parenting is mostly done to keep the ARM CPU clocked while the
> > PLL is stopped, reprogrammed and restarted. One of the side effects of
> > that is, the clock speed of the temporary parent could be higher then
> > what is allowed due to the ARM voltage at the time of re-parenting.
> > That is the reason to use the safe voltage.
>
> The Rockchip-SoCs use something similar, so I'm following quite closely what
> Thomas is trying to do here, as similar solution would also solve this issue
> for me.
>
> On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced from
> the divided armclk, creating additional constraints.
>
> But on the RKs (at least in the upstream sources) the armclk is simply equal
> to the pll output. A divider exists, but is only used to make sure that the
> armclk stays below the original rate when sourced from the temp-parent, like
>
> if (clk_get_rate(temp_parent) > clk_get_rate(main_parent)
> set_divider(something so that rate(temp) <= rate(main)
> clk_set_parent(...)
>
> Isn't there a similar possiblity on your platform, as it would remove the need
> for the safe-voltage?
>
>
> In general I also like the approach of hiding the rate-change logic inside
> this composite clock, as the depending clocks can be easily kept in sync. As
> with the Rockchips the depending clocks are different for each of the three
> Cortex-A9 SoCs I looked at, it would be "interesting" if all of this would
> need to be done in a cpufreq driver.
I wonder if hiding these details inside of the composite clock
implementation indicates the lack of some needed feature in the clk
core? I've discussed the idea of "coordinated rate changes" before. E.g:
_________________________________________________________
| clk | opp-low | opp-mid | opp-fast |
| | | | |
|pll | 300000 | 600000 | 600000 |
| | | | |
|div | 150000 | 300000 | 600000 |
| | | | |
|mpu_clk| 150000 | 300000 | 600000 |
| | | | |
|periph | 150000 | 150000 | 300000 |
---------------------------------------------------------
A call to clk_set_rate() against any of those clocks will result in all
of their dividers being updated. At the implementation level this might
look something like this extremely simplified pseudocode:
int clk_set_rate(struct clk* clk, unsigned long rate)
{
/* trap clks that support coordinated rate changes */
if (clk->ops->coordinate_rate)
return clk->ops->coordinate_rate(clk->hw, rate);
...
}
and,
struct coord_rates {
struct clk_hw *hw;
struct clk *parent;
struct clk *rate;
};
and in the clock driver,
#define PLL 0
#define DIV 1
#define MPU 2
#define PER 3
#define NR_OPP 4
#define NR_CLK 4
struct coord_rates my_opps[NR_OPP][NR_CLK]; // populated from DT data
int my_coordinate_rate_callback(struct clk_hw *hw, unsigned long rate)
{
struct coord_rate **selected_opp;
for(i = 0; i < NR_OPP; i++) {
for(j = 0; j < NR_CLK; j++) {
if (my_opps[i][j]->hw == hw &&
my_opps[i][j]->rate == rate)
selected_opp = my_opps[i];
break;
}
}
/*
* order of operations is specific to my hardware and should be
* managed by my clock driver, not generic code
*/
__clk_set_parent(selected_opp[DIV]->hw, temp_parent);
__clk_set_rate(selected_opp[PLL]->hw, selected_opp[PLL]->rate);
__clk_set_parent(selected_opp[DIV]->hw,
selected_opp[PLL]->hw->clk);
...
/*
* note that the above could be handled by a switch-case or
* something else
*/
}
Thoughts? Please forgive any gaps in my logic or abuse of C.
I have long thought that something like the above would someday go into
a generic dvfs layer instead of the clock framework, but maybe starting
with the clk framework makes more sense?
Regards,
Mike
>
>
> Heiko
>
^ permalink raw reply
* [RFC] dt-bindings: configuration of parent clocks and clock frequency
From: Mike Turquette @ 2014-02-01 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DE6CAB.10008@samsung.com>
Quoting Sylwester Nawrocki (2014-01-21 04:48:43)
> 5. Similarly to the regulator bindings the clock names could be appended
> to name of a DT property:
>
> [clk_name]-assigned-clock-parent = <...>;
> [clk_name]-assigned-clock-rate = <...>;
I have always been partial to the way that the reg framework does its
[reg_name]-supply. We could shorten it to something like:
[clk-name]-asn-parent = ....
[clk-name]-asn-rate = ...
This is actually the format that was discussed at the ARM kernel summit
IIRC.
Regards,
Mike
^ permalink raw reply
* [PATCH V3 2/2] ARM: multi_v7_defconfig: add mvebu drivers
From: Jason Cooper @ 2014-02-01 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131232333.GD11138@quad.lixom.net>
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?
thx,
Jason.
^ permalink raw reply
* [PATCH] clk: Fix notifier documentation
From: Sören Brinkmann @ 2014-02-01 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390420117-25930-1-git-send-email-soren.brinkmann@xilinx.com>
ping?
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
* NFS client broken in Linus' tip
From: Russell King - ARM Linux @ 2014-02-01 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391201970.6978.1.camel@leira.trondhjem.org>
On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> On Thu, 2014-01-30 at 15:38 +0000, Russell King - ARM Linux wrote:
> > On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > > On Thu, Jan 30, 2014 at 02:27:52PM +0000, Russell King - ARM Linux wrote:
> > > > Yes and no. I still end up with an empty /etc/mtab, but the file now
> > > > exists. However, I can create and echo data into /etc/mtab, but it seems
> > > > that can't happen at boot time.
> > >
> > > Odd. Can you disable CONFIG_NFSD_V3_ACL for now to isolate the issue?
> >
> > Unfortunately, that results in some problem at boot time, which
> > ultimately ends up with the other three CPUs being stopped, and
> > hence the original reason scrolls off the screen before it can be
> > read... even at 1920p.
> >
> Hi Russell,
>
> The following patch fixes the issue for me.
It doesn't entirely fix the issue for me, instead we've got even weirder
behaviour:
root at cubox-i4:~# ls -al test
ls: cannot access test: No such file or directory
root at cubox-i4:~# touch test
root at cubox-i4:~# ls -al test
-rw-r--r-- 1 root root 0 Feb 1 01:01 test
root at cubox-i4:~# echo foo > test
root at cubox-i4:~# ls -al test
-rw-r--r-- 1 root root 4 Feb 1 01:01 test
root at cubox-i4:~# cat test
foo
root at cubox-i4:~# rm test
root at cubox-i4:~# echo foo > test
-bash: test: Operation not supported
root at cubox-i4:~# ls -al test
-rw-r--r-- 1 root root 0 Feb 1 01:01 test
--
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] arm64: Align CMA sizes to PAGE_SIZE
From: Laura Abbott @ 2014-02-01 0:23 UTC (permalink / raw)
To: linux-arm-kernel
dma_alloc_from_contiguous takes number of pages for a size.
Align up the dma size passed in to page size to avoid truncation
and allocation failures on sizes less than PAGE_SIZE.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 864b256..be2696e 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -44,6 +44,8 @@ static void *arm64_swiotlb_alloc_coherent(struct device *dev, size_t size,
flags |= GFP_DMA32;
if (IS_ENABLED(CONFIG_CMA)) {
unsigned long pfn;
+
+ size = PAGE_ALIGN(size);
pfn = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
get_order(size));
if (!pfn)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V3 2/2] ARM: multi_v7_defconfig: add mvebu drivers
From: Olof Johansson @ 2014-01-31 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a95aff6b85c8974e3e5cfea0b0765b3a9bedc80.1390936638.git.jason@lakedaemon.net>
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.
-Olof
^ permalink raw reply
* [PATCH 27/73] drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
From: Mike Turquette @ 2014-01-31 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390339396-3479-28-git-send-email-paul.gortmaker@windriver.com>
Quoting Paul Gortmaker (2014-01-21 13:22:30)
> The clk-nomadik.o is built for ARCH_NOMADIK -- which is bool, and
> hence this code is either present or absent. It will never be
> modular, so using module_init as an alias for __initcall can be
> somewhat misleading.
>
> Fix this up now, so that we can relocate module_init from
> init.h into module.h in the future. If we don't do this, we'd
> have to add module.h to obviously non-modular code, and that
> would be a worse thing.
>
> Note that direct use of __initcall is discouraged, vs. one
> of the priority categorized subgroups. As __initcall gets
> mapped onto device_initcall, our use of device_initcall
> directly in this change means that the runtime impact is
> zero -- it will remain at level 6 in initcall ordering.
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Looks good to me.
Regards,
Mike
> ---
> drivers/clk/clk-nomadik.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
> index 6a934a5..5be9b9f 100644
> --- a/drivers/clk/clk-nomadik.c
> +++ b/drivers/clk/clk-nomadik.c
> @@ -500,8 +500,7 @@ static int __init nomadik_src_clk_init_debugfs(void)
> NULL, NULL, &nomadik_src_clk_debugfs_ops);
> return 0;
> }
> -
> -module_init(nomadik_src_clk_init_debugfs);
> +device_initcall(nomadik_src_clk_init_debugfs);
>
> #endif
>
> --
> 1.8.4.1
>
^ permalink raw reply
* [PATCH v4] ARM/serial: at91: switch atmel serial to use gpiolib
From: Olof Johansson @ 2014-01-31 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBBB84.9050705@gmail.com>
On Fri, Jan 31, 2014 at 04:04:36PM +0100, Richard Genoud wrote:
> On 13/01/2014 14:39, Linus Walleij wrote:
> > On Thu, Nov 7, 2013 at 10:25 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> >> This passes the errata fix using a GPIO to control the RTS pin
> >> on one of the AT91 chips to use gpiolib instead of the
> >> AT91-specific interfaces. Also remove the reliance on
> >> compile-time #defines and the cpu_* check and rely on the
> >> platform passing down the proper GPIO pin through platform
> >> data.
> >>
> >> This is a prerequisite for getting rid of the local GPIO
> >> implementation in the AT91 platform and move toward
> >> multiplatform.
> >>
> >> The patch also adds device tree support for getting the
> >> RTS GPIO pin from the device tree on DT boot paths.
> >>
> >> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> >> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> >> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >> ---
> >> ChangeLog v3->v4:
> >
> > ARM SoC folks, if you're not taking this in through the <timex.h> removal
> > series then please ACK this patch so I can take it through the GPIO
> > tree instead (unless you want to apply this single patch, which would
> > be even better, you have Greg's ACK in this thread).
> >
> I can't find this patch in linux-next, did I missed something ?
Yeah, looks like we dropped the ball on it. We'll queue it up for 3.15 as soon
as -rc1 is out.
-Olof
^ permalink raw reply
* [PATCH] drivers: bus: fix CCI driver kcalloc call parameters swap
From: Olof Johansson @ 2014-01-31 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390819837-32196-1-git-send-email-lorenzo.pieralisi@arm.com>
On Mon, Jan 27, 2014 at 10:50:37AM +0000, Lorenzo Pieralisi wrote:
> This patch fixes a bug/typo in the CCI driver kcalloc usage
> that inadvertently swapped the parameters order in the
> kcalloc call and went unnoticed.
>
> Reported-by: Xia Feng <xiafeng@allwinnertech.com>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Applied, thanks.
-Olof
^ permalink raw reply
* [RESEND PATCH] ARM: dts: bcm28155-ap: Fix Card Detection GPIO
From: Olof Johansson @ 2014-01-31 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAYSxhpSz8ZF_urMfQ4xdc1fhFdQC-_=9U1dvNn=EU_OoNsWbw@mail.gmail.com>
On Fri, Jan 24, 2014 at 10:48:40AM -0800, Tim Kryger wrote:
> On Wed, Jan 8, 2014 at 4:54 PM, Christian Daudt <bcm@fixthebug.org> wrote:
> > On Wed, Jan 8, 2014 at 4:28 PM, Tim Kryger <tim.kryger@linaro.org> wrote:
> >> On Wed, Jan 8, 2014 at 3:38 PM, Christian Daudt <bcm@fixthebug.org> wrote:
> >>> On Tue, Jan 7, 2014 at 10:53 AM, Tim Kryger <tim.kryger@linaro.org> wrote:
> >>>> The board schematic states that the "SD_CARD_DET_N gets pulled to GND
> >>>> when card is inserted" so the polarity has been updated to active low.
> >>>>
> >>>> Polarity is now specified with a GPIO define instead of a magic number.
> >>>>
> >>>> Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
> >>>> Reviewed-by: Matt Porter <matt.porter@linaro.org>
> >>>> ---
> >>>> arch/arm/boot/dts/bcm28155-ap.dts | 4 +++-
> >>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/bcm28155-ap.dts b/arch/arm/boot/dts/bcm28155-ap.dts
> >>>> index 08e47c2..27dd110 100644
> >>>> --- a/arch/arm/boot/dts/bcm28155-ap.dts
> >>>> +++ b/arch/arm/boot/dts/bcm28155-ap.dts
> >>>> @@ -13,6 +13,8 @@
> >>>>
> >>>> /dts-v1/;
> >>>>
> >>>> +#include <dt-bindings/gpio/gpio.h>
> >>>> +
> >>>> #include "bcm11351.dtsi"
> >>>>
> >>>> / {
> >>>> @@ -40,7 +42,7 @@
> >>>>
> >>>> sdio4: sdio at 3f1b0000 {
> >>>> max-frequency = <48000000>;
> >>>> - cd-gpios = <&gpio 14 0>;
> >>>> + cd-gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> >>>> status = "okay";
> >>>> };
> >>>> };
> >>>> --
> >>>> 1.8.0.1
> >>>>
> >>> Tim,
> >>> Does bcm11351-brt not also suffer from the same bug? If it does can
> >>> you pls update the patch to also fix it?
> >>>
> >>> Thanks,
> >>> csd
> >>
> >> The BRT and AP boards are similar so it may have the same problem but
> >> I don't have a BRT and wouldn't be able to test any changes to its DTS
> >> file.
> >>
> >> -Tim
> >
> > [sorry for the resend for those that get it twice]
> > Agreed - it's time that dts file go away. In this case:
> > Acked-by: Christian Daudt <bcm@fixthebug.org>
> >
> > Olof - can you pls pull in this patch. This is the bugfix that was
> > discussed in irc earlier today.
> >
> > thanks,
> > csd
>
> Christian,
>
> I'm not sure Olof saw your reply. Olof and Kevin are now on CC.
Nope, applied now. Had to touch it up a bit since we're missing some of the
patches that this was based on for 3.14, but the cd-gpios property is fixed.
-Olof
^ permalink raw reply
* [PATCH] ARM: keystone: config: fix build warning when CONFIG_DMADEVICES is not set
From: Santosh Shilimkar @ 2014-01-31 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131230410.GB9804@quad.lixom.net>
On Friday 31 January 2014 06:04 PM, Olof Johansson wrote:
> On Thu, Jan 09, 2014 at 09:37:06AM -0500, Santosh Shilimkar wrote:
>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>>
>> Drop automatic selection of TI_EDMA from Keystone Kconfig file,
>> as it produces build warning in case if CONFIG_DMADEVICES is not set:
>>
>> warning: (ARCH_KEYSTONE) selects TI_EDMA which has unmet direct dependencies (DMADEVICES && (ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE))
>>
>> Instead enable TI EDMA support from defconfig.
>>
>> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>>
>> Kevin, Olof, Arnd,
>>
>> Please let me know if you can pick this patch in 3.14 arm-soc
>> queue or you prefer a pull request for the same. It applies against
>> 'next/soc' cleanly.
>
> Seems like it was missed, I've applied it to fixes now.
>
Yep. Thanks.
Regards,
Santosh
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Select CONFIG_AT803X_PHY
From: Olof Johansson @ 2014-01-31 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389456976-5110-1-git-send-email-festevam@gmail.com>
On Sat, Jan 11, 2014 at 02:16:16PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Select CONFIG_AT803X_PHY so that we can boot hummingboard via NFS.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied to fixes.
-Olof
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131221553.GF2502@saruman.home>
On Friday 31 January 2014 05:15 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote:
>
> [ snip ]
>
>>> note that because of pm_runtime_set_active() that first
>>> pm_runtime_get_sync() in probe() will simply increase the reference
>>> counter without calling my ->runtime_resume() callback, which is exactly
>>> what we want, as that would completely avoid situations of bad context
>>> being restored because of that initial pm_runtime_get_sync().
>>>
>> Thanks for making your point bit clear.
>
> no problem.
>
>>> Then, we can even make pm_runtime completely async easily, because
>>> clk_prepare() was called only on probe() (or before it, for that
>>> matter).
>>>
>>> Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
>>> clk_enable() and pm_runtime_set_active() will be called properly before
>>> my probe, i'll be more than happy to comply with your request above as
>>> that will greatly simplify my driver.
>>>
>> Which is the case at least I see on Keystone. And hence the patch from
>
> I was going over pm_domain.c and drivers/base/power/clock_ops.c and none
> of them enable pm_runtime or make sure pm_runtime_set_active() is
> called.
>
>> Grygorii works. I also noticed your proposal for wider platform to
>> enforce above behavior which seems to be a good idea.
>
> it'll take months to stabilize though ;-)
>
>>> Just make, also, that if this clock is shared between dwc3-keystone
>>> wrapper and dwc3 core, you clk_get() on both driver's probe.
>>>
>> I understand. In summary, whichever patch you pick(yours) or Grygorii's,
>> its completely safe to remove the clock handling from Keystone USB driver.
>
> alright, since I can't really test, I'll take this as a true statement.
> If there are any regressions I can blame you, hehehe.
>
No problem... :D
Grygorii patch has been working well so all good with that
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox