* [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
* [PATCH] ARM: keystone: config: fix build warning when CONFIG_DMADEVICES is not set
From: Olof Johansson @ 2014-01-31 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389278226-23071-1-git-send-email-santosh.shilimkar@ti.com>
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.
-Olof
^ permalink raw reply
* [PATCH v2] MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
From: Olof Johansson @ 2014-01-31 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388719453-12447-1-git-send-email-21cnbao@gmail.com>
On Fri, Jan 03, 2014 at 11:24:13AM +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> instead of listing drivers one by one, use regex patterns to involve all
> SiRF drivers directly.
> this also adds sirf UART and watchdog drivers automatically from:
> drivers/tty/serial/sirfsoc_uart.*
> drivers/watchdog/sirfsoc_wdt.c
>
> Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
Applied to fixes for 3.14.
-Olof
^ permalink raw reply
* [GIT PULL] Xilinx Zynq dt fixes for v3.14
From: Olof Johansson @ 2014-01-31 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA7976.7030709@monstr.eu>
On Thu, Jan 30, 2014 at 05:10:30PM +0100, Michal Simek wrote:
> Hi guys,
>
> please consider to queue this patch to 3.14 because it enables Arasan
> SDHCI driver which has been merged to the tree. It took for a while
> to get it to the mainline that's why I didn't push this patch
> in regular arm-soc merge window. I was talking about it
> with Kevin some weeks ago.
>
> There will be one more patch which I have discussed with Russell but
> I will send it out for reviewed first.
> https://lkml.org/lkml/2014/1/27/212
I ended up cherry-picking the patch instead, since your base is different from
what we have today. But the patch has been applied to our fixes branch now and
will be sent up.
-Olof
^ permalink raw reply
* [PATCH] ARM: hisi: don't select SMP
From: Olof Johansson @ 2014-01-31 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391205990-22506-1-git-send-email-robherring2@gmail.com>
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.
-Olof
^ permalink raw reply
* [PATCHv3] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Kees Cook @ 2014-01-31 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391115944-10183-1-git-send-email-lauraa@codeaurora.org>
On Thu, Jan 30, 2014 at 1:05 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> arm64 currently lacks support for -fstack-protector. Add
> similar functionality to arm to detect stack corruption.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Thanks!
Acked-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* [PATCH 3/3] spi: switch to devm_spi_alloc_master
From: Maxime Ripard @ 2014-01-31 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBCCCD.301@wwwdotorg.org>
On Fri, Jan 31, 2014 at 09:18:21AM -0700, Stephen Warren wrote:
> On 01/31/2014 03:23 AM, Maxime Ripard wrote:
> > Make the existing users of devm_spi_register_master use the
> > devm_spi_alloc_master function to avoid leaking memory.
>
> > diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
>
> > @@ -1087,14 +1085,13 @@ static int tegra_spi_probe(struct platform_device *pdev)
> > if (ret < 0) {
> > dev_err(&pdev->dev, "Failed to register ISR for IRQ %d\n",
> > tspi->irq);
> > - goto exit_free_master;
> > + return ret;
> > }
> >
> > tspi->clk = devm_clk_get(&pdev->dev, "spi");
> > if (IS_ERR(tspi->clk)) {
> > dev_err(&pdev->dev, "can not get clock\n");
> > - ret = PTR_ERR(tspi->clk);
> > - goto exit_free_irq;
> > + return PTR_ERR(tspi->clk);
> > }
> >
> > tspi->max_buf_size = SPI_FIFO_DEPTH << 2;
> > @@ -1152,8 +1149,6 @@ exit_rx_dma_free:
> > tegra_spi_deinit_dma_param(tspi, true);
> > exit_free_irq:
> > free_irq(spi_irq, tspi);
> > -exit_free_master:
> > - spi_master_put(master);
> > return ret;
>
> Doesn't that s/goto exit_free_irq/return/ leak spi_irq? It's only OK to
> replace goto free_master with a direct return.
>
> The other two Tegra drivers don't seem to have this problem.
Ah, right. Thanks for noticing.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140131/282a6769/attachment.sig>
^ permalink raw reply
* [PATCH v3 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-01-31 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131124809.GE22609@sirena.org.uk>
On Fri, Jan 31, 2014 at 12:48:09PM +0000, Mark Brown wrote:
> On Fri, Jan 31, 2014 at 11:55:50AM +0100, Maxime Ripard wrote:
>
> > + master = devm_spi_alloc_master(&pdev->dev, sizeof(struct sun6i_spi));
> > + if (!master) {
> > + dev_err(&pdev->dev, "Unable to allocate SPI Master\n");
> > + return -ENOMEM;
> > + }
>
> This now depends on your other series which as I said doesn't look like
> the best approach.
Indeed, I forgot to mention it in the cover letter. My bad.
>
> > + pm_runtime_enable(&pdev->dev);
> > + if (!pm_runtime_enabled(&pdev->dev)) {
> > + ret = sun6i_spi_runtime_resume(&pdev->dev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't resume the device\n");
> > + return ret;
> > + }
> > + }
>
> No, as discussed don't do this - notice how other drivers aren't written
> this way either. Like I said leave the device powered on startup and
> then let it be idled by runtime PM.
Well, some SPI drivers are actually written like that (all the tegra
SPI drivers for example). It's not an excuse, but waking up the device
only to put it back in suspend right away seems kind of
inefficient. Plus, the pm_runtime_idle callback you suggested are
actually calling runtime_idle, while we want to call runtime_suspend.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140131/3f2c9212/attachment.sig>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBF790.3090407@ti.com>
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.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/8ff6eefd/attachment.sig>
^ permalink raw reply
* [PATCH v7 0/7] ARM: rockchip: add smp functionality
From: Rob Herring @ 2014-01-31 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13010296.nzTT2PqdSR@phil>
On Fri, Jan 31, 2014 at 4:03 PM, Heiko St?bner <heiko@sntech.de> 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 :-) .
Acked-by: Rob Herring <robh@kernel.org>
Rob
>
>
>> 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?
>
>
> Thanks
> Heiko
>
>
>> ARM: rockchip: add snoop-control-unit
>> ARM: rockchip: add sram dt nodes and documentation
>> ARM: rockchip: add power-management-unit
>> ARM: rockchip: add smp bringup code
>>
>> .../devicetree/bindings/arm/rockchip/pmu.txt | 16 ++
>> .../devicetree/bindings/arm/rockchip/smp-sram.txt | 23 +++
>> Documentation/devicetree/bindings/misc/sram.txt | 8 +
>> arch/arm/boot/dts/rk3066a.dtsi | 6 +
>> arch/arm/boot/dts/rk3188.dtsi | 6 +
>> arch/arm/boot/dts/rk3xxx.dtsi | 10 +
>> arch/arm/mach-rockchip/Kconfig | 1 +
>> arch/arm/mach-rockchip/Makefile | 1 +
>> arch/arm/mach-rockchip/core.h | 22 +++
>> arch/arm/mach-rockchip/headsmp.S | 30 +++
>> arch/arm/mach-rockchip/platsmp.c | 208
>> ++++++++++++++++++++ arch/arm/mach-rockchip/rockchip.c |
>> 2 +
>> drivers/misc/sram.c | 121 +++++++++++-
>> drivers/of/base.c | 32 +++
>> include/linux/of.h | 76 +++++++
>> 15 files changed, 554 insertions(+), 8 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
>> create mode 100644
>> Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt create mode
>> 100644 arch/arm/mach-rockchip/core.h
>> create mode 100644 arch/arm/mach-rockchip/headsmp.S
>> create mode 100644 arch/arm/mach-rockchip/platsmp.c
>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401311608590.12368-100000@netrider.rowland.org>
On Fri, Jan 31, 2014 at 04:13:19PM -0500, Alan Stern wrote:
> On Fri, 31 Jan 2014, Felipe Balbi wrote:
>
> > probe()
> > {
> > ...
> >
> > clk_get(dev, "fck");
> > clk_prepare(clk);
> > clk_enable(clk);
> > pm_runtime_set_active(dev);
> > pm_runtime_enable(dev);
> > pm_runtime_get_sync(dev);
> > ...
> > }
>
> > 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().
>
> Very minor note... A slightly better way to do the same thing is:
>
> pm_runtime_set_active(dev);
> pm_runtime_get_noresume(dev);
> pm_runtime_enable(dev);
>
> The get_noresume says that you want to increment the usage counter
> without performing any callbacks, and doing it before the
> pm_runtime_enable avoids any window during which a runtime suspend
> might somehow occur.
aha, that's perfect :-) Thanks Alan.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/f29ba556/attachment.sig>
^ 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