* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Shawn Guo @ 2013-01-28 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127172358.GM29973@lunn.ch>
On Sun, Jan 27, 2013 at 06:23:58PM +0100, Andrew Lunn wrote:
> > > + clkspec.np = np;
> > > + clkspec.args_count = 1;
> > > + clkspec.args[0] = 1;
> > > +
> > > + priv.cpu_clk = of_clk_get_from_provider(&clkspec);
> >
> > Oh, yet another way to get clocks...
>
> Yep. I didn't like it, but could not find a better way. It has been
> argued that cpufreq drivers should not have nodes in DT. So the normal
> of_clk_get() does not work. Since the clocks themselves are
> instantiated from DT, there are no clkdev alias, so plain clk_get()
> also does not work.
>
But you should have a cpu node in DT, and it will be perfectly fine to
have cpu node consume that core_clk.
Shawn
^ permalink raw reply
* [GIT PULL] perf updates for 3.9
From: Olof Johansson @ 2013-01-28 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123180347.GG26811@mudshark.cambridge.arm.com>
On Wed, Jan 23, 2013 at 06:03:47PM +0000, Will Deacon wrote:
> Hi Russell, Arnd, Olof,
>
> Please can you pull these perf updates for 3.9? They should go via both
> rmk and arm-soc as they are a dependency for kvm and some Tegra SCU
> stuff. I'll keep this branch stable, so others can base against it if
> they like.
Thanks, I've added a copy of this as depends/rmk-perf in arm-soc, will
merge into branches as pull requests that depend on it come in.
-Olof
^ permalink raw reply
* [GIT PULL] psci client-side implementation for 3.9
From: Olof Johansson @ 2013-01-28 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123180507.GH26811@mudshark.cambridge.arm.com>
On Wed, Jan 23, 2013 at 06:05:07PM +0000, Will Deacon wrote:
> Hello again guys,
>
> Please pull my PSCI client-side implementation for 3.9. This is used by
> the mach-virt platform, for which I'll send another pull request later
> on (since there are some timer dependencies that need resolving first).
>
> As before, I'll keep this branch stable so others can base against it.
>
> Thanks,
>
> Will
>
> --->8
>
> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
>
> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-rmk/virt/psci
Thanks, added as depends/rmk-psci in arm-soc, just as rmk-perf I have not
actually merged it in with anything yet though.
-Olof
^ permalink raw reply
* [PATCH] ARM: davinci: da850: add RTC driver DT entries
From: Katepallewar, Mrugesh @ 2013-01-28 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51026AEA.5050503@ti.com>
On Fri, Jan 25, 2013 at 16:52:18, Nori, Sekhar wrote:
> On 1/25/2013 4:34 PM, Katepallewar, Mrugesh wrote:
> > On Fri, Jan 25, 2013 at 16:04:22, Nori, Sekhar wrote:
> >> On 1/25/2013 11:43 AM, Mrugesh Katepallewar wrote:
> >>> Add RTC DT entries in da850 dts file.
> >>>
> >>> Signed-off-by: Mrugesh Katepallewar <mrugesh.mk@ti.com>
> >>> ---
> >>> Applies on top of v3.8-rc4 of linus tree.
> >>>
> >>> Tested on da850-evm device.
> >>>
> >>> Test Procedure:
> >>> date [YYYY.]MM.DD-hh:mm[:ss]
> >>> hwclock -w
> >>> reset board and check system time.
> >>>
> >>> :100644 100644 37dc5a3... b16efd4... M arch/arm/boot/dts/da850-evm.dts
> >>> :100644 100644 640ab75... a8eb1b1... M arch/arm/boot/dts/da850.dtsi
> >>> arch/arm/boot/dts/da850-evm.dts | 3 +++
> >>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> >>> 2 files changed, 11 insertions(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/da850-evm.dts
> >>> b/arch/arm/boot/dts/da850-evm.dts index 37dc5a3..b16efd4 100644
> >>> --- a/arch/arm/boot/dts/da850-evm.dts
> >>> +++ b/arch/arm/boot/dts/da850-evm.dts
> >>> @@ -24,5 +24,8 @@
> >>> serial2: serial at 1d0d000 {
> >>> status = "okay";
> >>> };
> >>> + rtc at 1c23000 {
>
> I did not mention this last time, but this should be:
>
> rtc0: rtc at 1c23000 {
>
> to be consistent with rest of the file.
Okay. I will send this in next version.
>
> >>> + status = "okay";
> >>> + };
> >>> };
> >>> };
> >>> diff --git a/arch/arm/boot/dts/da850.dtsi
> >>> b/arch/arm/boot/dts/da850.dtsi index 640ab75..a8eb1b1 100644
> >>> --- a/arch/arm/boot/dts/da850.dtsi
> >>> +++ b/arch/arm/boot/dts/da850.dtsi
> >>> @@ -56,5 +56,13 @@
> >>> interrupt-parent = <&intc>;
> >>> status = "disabled";
> >>> };
> >>> + rtc at 1c23000 {
>
> Here too.
>
Okay. I will send this in next version.
> >>> + compatible = "ti,da830-rtc";
> >>> + reg = <0x23000 0x1000>;
> >>> + interrupts = <19
> >>> + 19>;
> >>
> >> Why two interrupts of the same number? If there is only one interrupt line then only one should be specified, no?
> > We are using common OMAP RTC driver for da850 and other ti SoC's
> > (e.g.am33xx). I have seen in am33xx.dtsi rtc timer and alarm interrupts are different. So, two interrupt numbers are expected from RTC DT node.
>
> Okay. Looking at the OMAP-L138 TRM, I see that the IP on that SoC supports both alarm and timer events and both arrive on the same interrupt number (as opposed to am335x where they supposedly arrive on different interrupt lines). What you have looks fine to me considering this.
>
> Also, the interrupt-parent setting needs to be removed. See the patch Prabhakar just submitted.
Okay. I will send this in next version.
>
> Thanks,
> Sekhar
>
Regards,
Mrugesh
^ permalink raw reply
* [PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Shawn Guo @ 2013-01-28 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=kCKbxX6ThzEty0F-MxxhsRMhh8++Nc7BqBaXNfaozoJw@mail.gmail.com>
On Mon, Jan 28, 2013 at 09:42:29AM +0530, Viresh Kumar wrote:
> > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > platform_device_register_full(&devinfo);
>
> Something similar was being discussed with Andrew (cc'd) on his patch
> for kikwood cpufreq driver.
>
> We shouldn't encourage addition of above as we are moving towards DT.
Moving towards DT does not really mean that we should never register
platform_device from platform code. DT is designed to present physical
devices, while what I'm adding here is somewhat a virtual one. I'm
just using the platform_device/platform_driver mechanism to instantiate
the driver on particular platform.
> So, i would except an compatible array too in your patch and then driver
> can be probed based on compatible string being present in cpu node.
I believe device tree maintainer already stated that we should not
have node/compatible for cpuidle/cpufreq such stuff in DT merely for
asking DT core to create platform_device for them.
Shawn
^ permalink raw reply
* [GIT PULL] CSR SiRFmarco SoC infrastructures for 3.9
From: Olof Johansson @ 2013-01-28 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4z-7z8=3xQwU6iEsqHEcVrRWK+Fm7eoBEbjC-EAewGypA@mail.gmail.com>
On Thu, Jan 24, 2013 at 11:21:02AM +0800, Barry Song wrote:
> Hi Olof, Arnd,
>
> pls pull the following changes for CSR SiRFmarco SoC. it has been
> rebased againest arm-soc timer/cleanup tree.
>
> since commit 90cf214d6a549bf482e3c5751ee256cc885b96ea:
>
> ARM: at91: fix board-rm9200-dt after sys_timer conversion
> (2013-01-14 10:14:04 -0800)
>
> are available in the git repository at:
> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git
> marco-timer-cleanup-rebase
Pulled in as prima2/marco, included in next/soc. Thanks!
I noticed that there is no defconfig for any mach-prima2 platforms. Feel
free to submit one so we get build coverage of the platform.
-Olof
^ permalink raw reply
* [PATCHv1 for soc 1/5] arm: socfpga: Add new device tree source for actual socfpga HW
From: Olof Johansson @ 2013-01-28 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-2-git-send-email-dinguyen@altera.com>
Hi,
Nit below.
On Thu, Jan 24, 2013 at 07:00:29PM -0600, dinguyen at altera.com wrote:
> diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
> new file mode 100644
> index 0000000..df3551f
> --- /dev/null
> +++ b/arch/arm/boot/dts/socfpga_vt.dts
> @@ -0,0 +1,60 @@
> +/*
> + * Copyright (C) 2013 Altera Corporation <www.altera.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/dts-v1/;
> +/include/ "socfpga.dtsi"
> +
> +/ {
> + model = "Altera SOCFPGA VT";
> + compatible = "altr,socfpga-vt";
> +
[...]
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index 6732924..198f491 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -99,6 +99,7 @@ static void __init socfpga_cyclone5_init(void)
> static const char *altera_dt_match[] = {
> "altr,socfpga",
> "altr,socfpga-cyclone5",
> + "altr,socfpga-vt",
> NULL
> };
If you add "altr,socfpga" as a second compatible field in the dts for
the board, then you won't have to update the board C file every time you
add a new board dts (as long as you don't need to do something special
with that board).
-Olof
^ permalink raw reply
* [PATCHv1 for soc 2/5] arm: socfpga: Add clock entries to socfpga.dtsi
From: Olof Johansson @ 2013-01-28 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-3-git-send-email-dinguyen@altera.com>
Hi,
On Thu, Jan 24, 2013 at 07:00:30PM -0600, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Pavel Machek <pavel@denx.de>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index 936d230..688729f 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -78,6 +78,43 @@
> };
> };
>
> + clkmgr at ffd04000 {
> + compatible = "altr, clk-mgr";
No space after "altr,". Also, this should have documented bindings under
Documentation/device-tree/bindings (and those should be cc:d to the appropriate
maintainers).
-Olof
^ permalink raw reply
* [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
From: Hiroshi Doyu @ 2013-01-28 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgtaCkiv285TU_vbAokN5M2MrANQ9piDcyXu5YMmbQq3A@mail.gmail.com>
Hi Russell,
On Tue, 22 Jan 2013 18:04:46 +0100
Olof Johansson <olof@lixom.net> wrote:
> Since Russell had comments on it earlier, I'd like him to give a nod
> that he's happy with it too.
Is this ok for you?
The original patch is:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/143552.html
^ permalink raw reply
* [PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Viresh Kumar @ 2013-01-28 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128070206.GB31689@S2101-09.ap.freescale.net>
On 28 January 2013 12:32, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Mon, Jan 28, 2013 at 09:42:29AM +0530, Viresh Kumar wrote:
>> > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
>> > platform_device_register_full(&devinfo);
>>
>> Something similar was being discussed with Andrew (cc'd) on his patch
>> for kikwood cpufreq driver.
>>
>> We shouldn't encourage addition of above as we are moving towards DT.
>
> Moving towards DT does not really mean that we should never register
> platform_device from platform code. DT is designed to present physical
> devices, while what I'm adding here is somewhat a virtual one. I'm
> just using the platform_device/platform_driver mechanism to instantiate
> the driver on particular platform.
>
>> So, i would except an compatible array too in your patch and then driver
>> can be probed based on compatible string being present in cpu node.
>
> I believe device tree maintainer already stated that we should not
> have node/compatible for cpuidle/cpufreq such stuff in DT merely for
> asking DT core to create platform_device for them.
I see. I am really not sure if the alternative of DT node (i.e. platform_device)
is good enough.
@Arnd: What do you say?
^ permalink raw reply
* [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
From: Paul Walmsley @ 2013-01-28 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9388C@DBDE01.ent.ti.com>
Hi
On Fri, 25 Jan 2013, Mohammed, Afzal wrote:
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > On Wed, 23 Jan 2013, Afzal Mohammed wrote:
>
> > > Currently round rate function would return proper rate iff requested
> > > rate exactly matches the PLL lockable rate. This causes set_rate to
> > > fail if exact rate could not be set. Instead round rate may return
> > > closest rate possible (less than the requested). And if any user is
> > > badly in need of exact rate, then return value of round rate could
> > > be used to decide whether to invoke set rate or not.
> > >
> > > Modify round rate so that it return closest possible rate.
> >
> > This doesn't look like the right approach to me. For some PLLs, an exact
> > rate is desired.
>
> If exact rate is required, there is a way to achieve it as mentioned
> in the commit message, i.e. by first invoking round rate over reqd. rate
> and if it doesn't match, bail out w/o invoking set_rate.
>
> And it seems requirement of CCF w.r.t to round rate is to return closest
> possible rate.
Hmm. Maybe I need to take a closer look. I'm a little worried that,
since __clk_round_rate() can be called from omap3_noncore_dpll_set_rate(),
we might wind up with inconsistent behavior. Effectively we'd need to
mandate that clk_round_rate() would have to be called first for any DPLL
where we'd expect to set an exact rate.
- Paul
^ permalink raw reply
* [GIT PULL] i.MX SoC updates for v3.9
From: Olof Johansson @ 2013-01-28 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125101510.GK1906@pengutronix.de>
Hi,
I know i.MX usually doesn't have a whole lot of patches for each release,
so requiring you to split up in 3-4 branches due to category might not
make much sense. Keep it in mind if you do have higher volume for some
merge window though.
Some comments below, mostly to keep in mind for future code reviews.
I've pulled this in as imx/soc, part of next/soc.
On Fri, Jan 25, 2013 at 11:15:10AM +0100, Sascha Hauer wrote:
> Hi Arnd, Olof,
>
> Please pull the following (mostly clock relates) updates for v3.9.
>
> Sascha
>
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
>
> Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
>
> are available in the git repository at:
>
> git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-soc
>
> for you to fetch changes up to 3ea8098572280d16163a429e0f8dfd90492a5934:
>
> ARM: clk-imx35: Fix build warnings with W=1 (2013-01-25 11:12:38 +0100)
>
> ----------------------------------------------------------------
> ARM i.MX SoC updates for next
>
> Mostly clock related updates, most notably the conversion of
> i.MX31 to a DT based lookup.
>
> ----------------------------------------------------------------
> Fabio Estevam (4):
> ARM: Let CONFIG_MACH_IMX31_DT be built by default
Patch subject here isn't quite right. This is really more like "ARM:
imx: add CONFIG_MACH_IMX31_DT to defconfig". Missing platform prefix too.
> ARM: clk-imx31: Add dummy clock
> ARM: mx31: Replace clk_register_clkdev with clock DT lookup
This could maybe have been split up in a few changes -- adding infrastructure
/ code in one, dts/dtsi updates in a second and a third with auxdata removal.
Either way, same end result so not a big deal.
I didn't see the patch posted to devicetree-discuss, but since the binding is
pretty standard I won't hold back due to it.
-Olof
^ permalink raw reply
* [PATCH V2] ARM: davinci: da850: add RTC DT entries
From: Mrugesh Katepallewar @ 2013-01-28 7:47 UTC (permalink / raw)
To: linux-arm-kernel
Add RTC DT entries in da850 dts file.
Signed-off-by: Mrugesh Katepallewar <mrugesh.mk@ti.com>
---
Applies on top of v3.8-rc4 of linus tree.
This patch is depending on
"ARM: davinci: da850: add interrupt-parent property in soc node"
https://patchwork.kernel.org/patch/2044101/
Tested on da850-evm device.
Test Procedure:
date 2013.01.28-10:00:00 (usage: date[YYYY.]MM.DD-hh:mm[:ss])
hwclock -w
reset board and check system time.
Changes Since V1:
Remove interrupt-parent property from RTC node.
Change RTC node name in dts and dtsi file.
:100644 100644 37dc5a3... af4b7cc... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 640ab75... 90be701... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 7 +++++++
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..af4b7cc 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -24,5 +24,8 @@
serial2: serial at 1d0d000 {
status = "okay";
};
+ rtc0: rtc at 1c23000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 640ab75..90be701 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,5 +56,12 @@
interrupt-parent = <&intc>;
status = "disabled";
};
+ rtc0: rtc at 1c23000 {
+ compatible = "ti,da830-rtc";
+ reg = <0x23000 0x1000>;
+ interrupts = <19
+ 19>;
+ status = "disabled";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 06/10] gpio: pxa: define nr gpios in platform data
From: Igor Grinberg @ 2013-01-28 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358929554-32265-7-git-send-email-haojian.zhuang@linaro.org>
On 01/23/13 10:25, Haojian Zhuang wrote:
> Avoid to define gpio numbers in gpio driver. Define it in platform data
> instead.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> ---
> arch/arm/mach-mmp/aspenite.c | 1 +
> arch/arm/mach-mmp/avengers_lite.c | 1 +
> arch/arm/mach-mmp/brownstone.c | 1 +
> arch/arm/mach-mmp/flint.c | 1 +
> arch/arm/mach-mmp/gplugd.c | 1 +
> arch/arm/mach-mmp/tavorevb.c | 1 +
> arch/arm/mach-mmp/teton_bga.c | 1 +
> arch/arm/mach-mmp/ttc_dkb.c | 1 +
> arch/arm/mach-pxa/pxa25x.c | 3 +++
> arch/arm/mach-pxa/pxa27x.c | 1 +
> arch/arm/mach-pxa/pxa3xx.c | 15 +++++++++++-
> drivers/gpio/gpio-pxa.c | 48 +++++++------------------------------
> include/linux/gpio-pxa.h | 1 +
> 13 files changed, 35 insertions(+), 41 deletions(-)
[...]
> diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
> index 656a1bb..a0cc797 100644
> --- a/arch/arm/mach-pxa/pxa3xx.c
> +++ b/arch/arm/mach-pxa/pxa3xx.c
> @@ -435,6 +435,10 @@ void __init pxa3xx_set_i2c_power_info(struct i2c_pxa_platform_data *info)
> pxa_register_device(&pxa3xx_device_i2c_power, info);
> }
>
> +static struct pxa_gpio_platform_data pxa3xx_gpio_info __initdata = {
> + .nr_gpios = 128,
> +};
This misses the:
#include <linux/gpio-pxa.h>
> +
> static struct platform_device *devices[] __initdata = {
> &pxa_device_gpio,
> &pxa27x_device_udc,
> @@ -482,8 +486,17 @@ static int __init pxa3xx_init(void)
> register_syscore_ops(&pxa3xx_mfp_syscore_ops);
> register_syscore_ops(&pxa3xx_clock_syscore_ops);
>
> - if (!of_have_populated_dt())
> + if (!of_have_populated_dt()) {
> + if (cpu_is_pxa93x())
> + pxa3xx_gpio_info.nr_gpios = 192;
> + ret = platform_device_add_data(&pxa_device_gpio,
> + &pxa3xx_gpio_info,
> + sizeof(struct pxa_gpio_platform_data);
Closing parenthesis is missing...
> + if (ret < 0)
> + break;
> +
> ret = platform_add_devices(devices, ARRAY_SIZE(devices));
> + }
> }
>
> return ret;
[...]
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 26/26] mfd: ab8500-gpadc: Use new ab8500_gpadc_get() with name parameter
From: Lee Jones @ 2013-01-28 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235405.GU1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:56:06PM +0000, Lee Jones wrote:
> > From: Philippe Langlais <philippe.langlais@linaro.org>
> >
> > The new format of ab8500_gpadc_get() accepts a device name as a
> > parameter to specify which device to retrieve. This patch
> > enforces the use of that new format.
> Where is that new API coming from ? I couldn't find it in the previous 25
> patches. If it's there, this one should be merged with the patch that changes
> this API.
The API is already upstream:
6321992c (Daniel Willerud 2011-03-05 11:46:13 +0100 133) struct
ab8500_gpadc *ab8500_gpadc_get(char *name)
The branch I'm trying to upstream from used the old one before now.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 23/26] mfd: ab8500-pwm: Enable support for AB8505 PWMLED blink
From: Lee Jones @ 2013-01-28 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235348.GT1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:56:03PM +0000, Lee Jones wrote:
> > From: Naga Radhesh <naga.radheshy@stericsson.com>
> >
> > Enable support for PWM OUT LED blinking for AB8505. Instead of
> > having 3 pwm instances from ab8500 core file add it as platform data.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Naga Radhesh <naga.radheshy@stericsson.com>
> > Reviewed-by: Arun MURTHY <arun.murthy@stericsson.com>
> > Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
> > ---
> > drivers/mfd/ab8500-core.c | 10 --
> > drivers/misc/ab8500-pwm.c | 282 ++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/ab8500/pwmleds.h | 20 +++
> > include/linux/mfd/abx500/ab8500.h | 2 +
> > 4 files changed, 304 insertions(+), 10 deletions(-)
> > create mode 100644 drivers/misc/ab8500-pwm.c
> This pretty much looks like the already existing and PWM API compliant
> drivers/pwm/ab8500-pwm.c. What's the point here ?
This patch pre-dates the new PWM interface.
It's probably the same thing. I'll look into it.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 09/26] mfd: ab8500-debugfs: Provide a means for a user subscribe to IRQs
From: Lee Jones @ 2013-01-28 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235259.GO1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:55:49PM +0000, Lee Jones wrote:
> > Allow users to subscribe to and view IRQ events live from debugfs.
> I seem to remember that I got a similar patch some time ago for the same
> purpose and my answer was: Please use a UIO driver for this. There already is
> such driver, it's uio_pdrv_genirq. What your debugfs registration entry could
> do is adding a platform device for the specific interrupt number. This would
> avoid the irq handler registration and the sysfs entry creation, both things I
> believe are not very elegant and open coded. It also gives you an IRQ count
> implementation.
> Ideally, the UIO framework could be improved to support IRQ ranges (through
> IRQ domains) instead of the current single interrupt number.
>
> Have you considered going through that path ?
I haven't looked into re-writing any of the MFD stuff yet. Instead I
have a plan of action:
1. Upstream as many of the 100 patches from the internal kernel up
into Mainline.
2. Mark any patches which are unsuitable for Mainlining and re-work
them after the remainder have been accepted. Not withstanding small
fixups, as these can be done on the fly without too much disruption.
3. Upstream the remainder once re-worked.
If I don't follow this work-flow and fix-up/re-work as I go, not only
will it take forever, but I'm also likely to encounter too many
complications in the way of conflicts in the latter stages.
I'm also following the same work-flow for 'drivers/power' and
'drivers/regulator'.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Shawn Guo @ 2013-01-28 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7196597.b9sJl95POM@vostro.rjw.lan>
On Sat, Jan 26, 2013 at 11:21:27PM +0100, Rafael J. Wysocki wrote:
> On Saturday, January 26, 2013 09:55:50 PM Shawn Guo wrote:
> > As multiplatform build is being adopted by more and more ARM platforms,
> > initcall function should be used very carefully. For example, when
> > GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
> > will be called on all the platforms to initialize cpufreq-cpu0 driver.
> >
> > To eliminate this undesired the effect, the patch changes cpufreq-cpu0
> > driver to have it instantiated as a platform_driver. Then it will only
> > run on platforms that create the platform_device "cpufreq-cpu0".
> >
> > Along with the change, it also changes cpu_dev to be &pdev->dev,
> > so that managed functions can start working, and module build gets
> > supported too.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > ---
> > Rafael,
> >
> > The patch depends patch "power: export opp cpufreq functions".
> > https://patchwork.kernel.org/patch/1847261/
>
> That one should use EXPORT_SYMBOL_GPL() for exporting symbols, though.
>
When commit 80126ce (PM / OPP: Export symbols for module usage.)
already exported a few symbols with EXPORT_SYMBOL()?
> Care to add a fixed version to the patch set along with the $subject one?
>
> > AnilKumar,
> >
> > Unfortunately, the change will require some platform level adoption
> > to have cpufreq-cpu0 driver continue working for am33xx. But it should
> > be as simple as something like below.
> >
> > struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> > platform_device_register_full(&devinfo);
>
> That should be included in your patch, then.
>
Fair enough. Will do.
Shawn
^ permalink raw reply
* [PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init
From: Nicolas Ferre @ 2013-01-28 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359153858-31992-11-git-send-email-arnd@arndb.de>
On 01/25/2013 11:44 PM, Arnd Bergmann :
> The device IDs are referenced by the driver and potentially
> used beyond the init time, as kbuild correctly warns
> about. Remove the __initconst annotation.
>
> Without this patch, building at91_dt_defconfig results in:
>
> WARNING: drivers/watchdog/built-in.o(.data+0x28): Section mismatch in reference from the variable at91wdt_driver to the (unknown reference) .init.rodata:(unknown)
> The variable at91wdt_driver references
> the (unknown reference) __initconst (unknown)
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wim Van Sebroeck <wim@iguana.be>
> Cc: linux-watchdog at vger.kernel.org
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks,
> Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
> drivers/watchdog/at91sam9_wdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> index dc42e44..6dad954 100644
> --- a/drivers/watchdog/at91sam9_wdt.c
> +++ b/drivers/watchdog/at91sam9_wdt.c
> @@ -304,7 +304,7 @@ static int __exit at91wdt_remove(struct platform_device *pdev)
> }
>
> #if defined(CONFIG_OF)
> -static const struct of_device_id at91_wdt_dt_ids[] __initconst = {
> +static const struct of_device_id at91_wdt_dt_ids[] = {
> { .compatible = "atmel,at91sam9260-wdt" },
> { /* sentinel */ }
> };
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 14/19] spi/atmel: remove incorrect __exit_p()
From: Nicolas Ferre @ 2013-01-28 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359153858-31992-15-git-send-email-arnd@arndb.de>
On 01/25/2013 11:44 PM, Arnd Bergmann :
> Since we no longer allow building without hotplug, the
> atmel_spi_remove function is always present and we should
> not use __exit_p() to refer to it.
>
> Without this patch, building at91_dt_defconfig results in:
>
> drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not used [-Wunused-function]
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: spi-devel-general at lists.sourceforge.net
> ---
> drivers/spi/spi-atmel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index ab34497..656d137 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
> .suspend = atmel_spi_suspend,
> .resume = atmel_spi_resume,
> .probe = atmel_spi_probe,
> - .remove = __exit_p(atmel_spi_remove),
> + .remove = atmel_spi_remove,
> };
> module_platform_driver(atmel_spi_driver);
>
>
--
Nicolas Ferre
^ permalink raw reply
* [RFC] ARM: dma-mapping: Return 0 if no ->set_dma_mask()
From: Hiroshi Doyu @ 2013-01-28 8:33 UTC (permalink / raw)
To: linux-arm-kernel
struct dma_map_ops iommu_ops doesn't have ->set_dma_mask, which causes
crash when dma_set_mask() is called from some driver.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/include/asm/dma-mapping.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index a58e0f5..95328bf 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -32,7 +32,11 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
static inline int dma_set_mask(struct device *dev, u64 mask)
{
- return get_dma_ops(dev)->set_dma_mask(dev, mask);
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (ops->set_dma_mask)
+ return ops->set_dma_mask(dev, mask);
+ return 0;
}
#ifdef __arch_page_to_dma
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] cpufreq, highbank: add support for highbank cpufreq
From: Shawn Guo @ 2013-01-28 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523559.2KevGvelzH@vostro.rjw.lan>
Rafael,
On Sat, Jan 26, 2013 at 11:24:12PM +0100, Rafael J. Wysocki wrote:
> > As we are moving to multiplatform build, this init function will run
> > on all other platforms built together with highbank. We should
> > probably eliminate that effect.
>
> That change can be made on top of the Mark's patches I think, right?
>
Yes.
> If so, I'd prefer it that way. The Mark's patches have been in a limbo for
> too long already and that issue doesn't seem to be serious enough to block
> them any longer.
>
Ok, I will take care of the changes needed on highbank. Do you have
a branch with Mark's series and the EXPORT_SYMBOL() one applied,
so that I can start my patch from there.
Shawn
^ permalink raw reply
* [PATCH 06/26] mfd: ab8500-sysctrl: Provide configuration for SysClkReqRfClkBuf registers
From: Lee Jones @ 2013-01-28 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235248.GN1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee, Kennet,
>
> On Tue, Jan 15, 2013 at 12:55:46PM +0000, Lee Jones wrote:
> > From: Kennet Wallden <kennet.wallden@stericsson.com>
> >
> > Add the possibility to pass configuration settings for
> > SysCl1kReqRfClkBuf to SysClk8ReqRfClkBuf via platform data.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Kennet Wallden <kennet.wallden@stericsson.com>
> > Reviewed-by: Karl-Johan PERNTZ <karl-johan.perntz@stericsson.com>
> > Reviewed-by: Bengt JONSSON <bengt.g.jonsson@stericsson.com>
> > ---
> > drivers/mfd/ab8500-sysctrl.c | 25 +++++++++++++++++++++++++
> > include/linux/mfd/abx500/ab8500-sysctrl.h | 5 +++++
> > include/linux/mfd/abx500/ab8500.h | 2 ++
> > 3 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
> > index cf58f69..19a024e 100644
> > --- a/drivers/mfd/ab8500-sysctrl.c
> > +++ b/drivers/mfd/ab8500-sysctrl.c
> > @@ -113,11 +113,36 @@ int ab8500_sysctrl_write(u16 reg, u8 mask, u8 value)
> > static int __devinit ab8500_sysctrl_probe(struct platform_device *pdev)
> > {
> > struct ab8500_platform_data *plat;
> > + struct ab8500_sysctrl_platform_data *pdata;
> >
> > sysctrl_dev = &pdev->dev;
> > plat = dev_get_platdata(pdev->dev.parent);
> > if (plat->pm_power_off)
> > pm_power_off = ab8500_power_off;
> > +
> > + pdata = plat->sysctrl;
> > +
> > + if (pdata) {
> > + int ret;
> > + int i;
> > + int j;
> Cosmetic
> int i, j, ret;
Hmmm... this is how I'd prefer it too, but other maintainers prefer
one-per-line. It would be better if we could standardise it somewhere
to prevent unnecessary fixups.
> > + for (i = AB8500_SYSCLKREQ1RFCLKBUF;
> > + i <= AB8500_SYSCLKREQ8RFCLKBUF; i++) {
> > + j = i - AB8500_SYSCLKREQ1RFCLKBUF;
> > + ret = ab8500_sysctrl_write(i, 0xff,
> > + pdata->initial_req_buf_config[j]);
> > + dev_dbg(&pdev->dev,
> > + "Setting SysClkReq%dRfClkBuf 0x%X\n",
> > + j + 1,
> > + pdata->initial_req_buf_config[j]);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev,
> > + "unable to set sysClkReq%dRfClkBuf: "
> > + "%d\n", j + 1, ret);
> > + }
> > + }
> > + }
> > +
> > return 0;
> > }
> >
> > diff --git a/include/linux/mfd/abx500/ab8500-sysctrl.h b/include/linux/mfd/abx500/ab8500-sysctrl.h
> > index 10eb509..ebf12e7 100644
> > --- a/include/linux/mfd/abx500/ab8500-sysctrl.h
> > +++ b/include/linux/mfd/abx500/ab8500-sysctrl.h
> > @@ -37,6 +37,11 @@ static inline int ab8500_sysctrl_clear(u16 reg, u8 bits)
> > return ab8500_sysctrl_write(reg, bits, 0);
> > }
> >
> > +/* Configuration data for SysClkReq1RfClkBuf - SysClkReq8RfClkBuf */
> > +struct ab8500_sysctrl_platform_data {
> > + u8 initial_req_buf_config[8];
> > +};
> > +
> > /* Registers */
> > #define AB8500_TURNONSTATUS 0x100
> > #define AB8500_RESETSTATUS 0x101
> > diff --git a/include/linux/mfd/abx500/ab8500.h b/include/linux/mfd/abx500/ab8500.h
> > index 96840c4..3f4e6d1 100644
> > --- a/include/linux/mfd/abx500/ab8500.h
> > +++ b/include/linux/mfd/abx500/ab8500.h
> > @@ -270,6 +270,7 @@ struct regulator_reg_init;
> > struct regulator_init_data;
> > struct ab8500_gpio_platform_data;
> > struct ab8500_codec_platform_data;
> > +struct ab8500_sysctrl_platform_data;
> >
> > /**
> > * struct ab8500_platform_data - AB8500 platform data
> > @@ -291,6 +292,7 @@ struct ab8500_platform_data {
> > struct regulator_init_data *regulator;
> > struct ab8500_gpio_platform_data *gpio;
> > struct ab8500_codec_platform_data *codec;
> > + struct ab8500_sysctrl_platform_data *sysctrl;
> > };
> >
> > extern int __devinit ab8500_init(struct ab8500 *ab8500,
>
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 05/26] mfd: ab8500-gpadc: Change to mdelay for greater resolution
From: Lee Jones @ 2013-01-28 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235239.GM1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee, Jonas,
>
> On Tue, Jan 15, 2013 at 12:55:45PM +0000, Lee Jones wrote:
> > From: Jonas Aaberg <jonas.aberg@stericsson.com>
> >
> > The resolution of msleep is related to HZ, so with HZ set to
> > 100 any msleep of less than 10ms will become ~10ms.
> usleep_range would be more appropriate, sleeping should be preferred over
> spinning.
I believe this patch was written before usleep_range() was around. This
is addressed in a latter patch. Please allow this one in for a)
historical reasons (trying to keep the development history) and b) to
prevent any conflicts when we do reach the fixup patch.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 02/26] mfd: ab8500-sysctrl: If a charger is present, reboot instead
From: Lee Jones @ 2013-01-28 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235230.GL1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:55:42PM +0000, Lee Jones wrote:
> > From: Jonas Aaberg <jonas.aberg@stericsson.com>
> >
> > If a changer is attached on power off, reboot the system
> s/changer/charger/
I'll fixup.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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