* [PATCH] ARM: mxs: gpio-mxs: Add IRQ_TYPE_EDGE_BOTH support
From: Linus Walleij @ 2013-01-28 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359306248-28690-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
On Sun, Jan 27, 2013 at 6:04 PM, Gwenhael Goavec-Merou
<gwenhael.goavec-merou@armadeus.com> wrote:
> This patch adds support for IRQ_TYPE_EDGE_BOTH needed for some driver
> (gpio-keys).
> Inspired from gpio-mxc.c
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Looks correct to me, Shawn do you ACK this?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 09/26] mfd: ab8500-debugfs: Provide a means for a user subscribe to IRQs
From: Lee Jones @ 2013-01-28 10:22 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'm going to have to put this patch-set in the bin. Pulling this
patch, causes lots of conflicts to the remaining patches in the
set.
I'll start again from scratch and find another way to sync the ab* MFD
drivers. I might even have to do it manually i.e. throw out all
commit history and upstream it as my own patches pulled in from diffs.
--
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 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init
From: Fabio Porcedda @ 2013-01-28 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51063791.9090606@atmel.com>
On Mon, Jan 28, 2013 at 9:32 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> 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>
Tested-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Thanks.
>> ---
>> 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
--
Fabio Porcedda
^ permalink raw reply
* [PATCH 2/2] gpio: pca953x: use managed resources
From: Linus Walleij @ 2013-01-28 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359133168-14879-3-git-send-email-gregory.clement@free-electrons.com>
On Fri, Jan 25, 2013 at 5:59 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> Using the devm_* managed resources the pca driver can be simplified
> and cut down on boilerplate code.
>
> [gcl: fixed a inccorect reference to a removed label, "goto fail_out"
> became "return ret"]
Oh now "gcl" means both Grant C. Likely and Gregory CLement :-)
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] gpio: pca953x: use simple irqdomain
From: Linus Walleij @ 2013-01-28 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359133168-14879-2-git-send-email-gregory.clement@free-electrons.com>
On Fri, Jan 25, 2013 at 5:59 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> This switches the legacy irqdomain to the simple one, which will
> auto-allocate descriptors, and also make sure that we use
> irq_create_mapping() in the to_irq function. Also use the map function
> of irq_domain_ops to setup the irq configuration on demand and no more
> statically during the initialization of the driver.
>
> Based on a initial patch from Linus Walleij <linus.walleij@linaro.org>
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied!
Thanks,
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] Improvement for pca953x drivers
From: Linus Walleij @ 2013-01-28 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359133168-14879-1-git-send-email-gregory.clement@free-electrons.com>
On Fri, Jan 25, 2013 at 5:59 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> those two patches are the begining of the improvement work we have
> spoken about earlier. I started with the two patches you sent.
Thanks for doing this!! :-)
> I've just made a small fix to make it build on the 2nd patch so I keep
> your autorship and signed-off.
OK I don't care about authorship & such stuff, the important thing
to me is that the code works and looks nice and maintainable.
> I've compiled and run it, but as I don't have support for the pca905
> interrupt on my board, I can't say it didn't break anything. Maybe
> this time again Maxime will be willing to test it.
I will apply the patches and then Maxime can shout if it breaks :-)
> For the remaining improvement related to the PWA and MMP #ifdef, I
> hope to be able to work on it this week-end.
Excellent, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V3 7/8] mv643xx.c: Add basic device tree support.
From: Mark Rutland @ 2013-01-28 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2db6ddfddf90dd79c6c6c90a6006887076dea1a.1359146831.git.jason@lakedaemon.net>
Hello,
I've taken a quick look at this, and I have a couple of comments on the binding
and the way it's parsed.
On Fri, Jan 25, 2013 at 08:53:59PM +0000, Jason Cooper wrote:
> From: Ian Molton <ian.molton@codethink.co.uk>
>
> This patch adds basic device tree support to the mv643xx ethernet driver.
>
> It should be enough for most current users of the device, and should allow
> a painless migration.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
>
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> Documentation/devicetree/bindings/net/mv643xx.txt | 75 ++++++++++++++++++
> drivers/net/ethernet/marvell/mv643xx_eth.c | 93 +++++++++++++++++++++--
> 2 files changed, 161 insertions(+), 7 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/mv643xx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/mv643xx.txt b/Documentation/devicetree/bindings/net/mv643xx.txt
> new file mode 100644
> index 0000000..2727f798
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mv643xx.txt
> @@ -0,0 +1,75 @@
> +mv643xx related nodes.
> +
> +marvell,mdio-mv643xx:
> +
> +Required properties:
> +
> + - interrupts : <a> where a is the SMI interrupt number.
> + - reg : the base address and size of the controllers register space.
> +
> +Optional properties:
> + - shared_smi : on some chips, the second PHY is "shared", meaning it is
> + really accessed via the first SMI controller. It is passed in this
> + way due to the present structure of the driver, which requires the
> + base address for the MAC to be passed in via the SMI controllers
> + platform data.
The phrase "the present structure of the driver" is not something that's
generally good to hear in a binding document. Is shared_smi always going to be
required for such configurations, or is there going to be any driver rework
that makes it irrelevant?
> + - tx_csum_limit : on some devices, this option is required for proper
> + operation wrt. jumbo frames.
This doesn't explain what this property is. Also "limit" doesn't describe
what's limited (e.g. size, rate). How about something like
max-tx-checksum-size?
> +
> +
> +Example:
> +
> +smi0: mdio at 72000 {
> + compatible = "marvell,mdio-mv643xx";
> + reg = <0x72000 0x4000>;
> + interrupts = <46>;
> + tx_csum_limit = <1600>;
> + status = "disabled";
> +};
> +
> +smi1: mdio at 76000 {
> + compatible = "marvell,mdio-mv643xx";
> + reg = <0x76000 0x4000>;
> + interrupts = <47>;
> + shared_smi = <&smi0>;
> + tx_csum_limit = <1600>;
> + status = "disabled";
> +};
> +
> +
> +
> +marvell,mv643xx-eth:
> +
> +Required properties:
> + - interrupts : the port interrupt number.
> + - mdio : phandle of the smi device as drescribed above
> +
> +Optional properties:
> + - port_number : the port number on this bus.
> + - phy_addr : the PHY address.
> + - reg : should match the mdio reg this device is attached to.
> + this is a required hack for now due to the way the
> + driver is constructed. This allows the device clock to be
> + kept running so that the MAC is not lost after boot.
More s/_/-/ candidates.
Is there any reason to have "phy_addr" rather than "phy_address"? We already
have #address-cells, which would seem to have set a precedent for naming.
[...]
> @@ -2610,6 +2613,26 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
> if (msp->base == NULL)
> goto out_free;
>
> + if (pdev->dev.of_node) {
> + struct device_node *np = NULL;
> +
> + /* when all users of this driver use FDT, we can remove this */
> + pd = kzalloc(sizeof(*pd), GFP_KERNEL);
> + if (!pd) {
> + dev_dbg(&pdev->dev, "Could not allocate platform data\n");
> + goto out_free;
> + }
> +
> + of_property_read_u32(pdev->dev.of_node,
> + "tx_csum_limit", &pd->tx_csum_limit);
Is there any upper limit on what this property could be? It would be nice to
have a sanity check.
Also, of_property_read_u32 reads a u32, but pd->tx_csum_limit is an int. It
would be good to use a u32 temporary.
[...]
> @@ -2858,7 +2893,36 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
> struct resource *res;
> int err;
>
> - pd = pdev->dev.platform_data;
> + if (pdev->dev.of_node) {
> + struct device_node *np = NULL;
> +
> + /* when all users of this driver use FDT, we can remove this */
> + pd = kzalloc(sizeof(*pd), GFP_KERNEL);
> + if (!pd) {
> + dev_dbg(&pdev->dev, "Could not allocate platform data\n");
> + return -ENOMEM;
> + }
> +
> + of_property_read_u32(pdev->dev.of_node,
> + "port_number", &pd->port_number);
> +
> + if (!of_property_read_u32(pdev->dev.of_node,
> + "phy_addr", &pd->phy_addr))
> + pd->phy_addr = MV643XX_ETH_PHY_ADDR(pd->phy_addr);
>From a cursory glance at mv643xx_eth.c, it looks like phy_addr needs to be in
the range 0 to 0x1f. It might be worth a sanity check here (even if it just
prints a warning).
> + else
> + pd->phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT;
> +
> + np = of_parse_phandle(pdev->dev.of_node, "mdio", 0);
> + if (np) {
> + pd->shared = of_find_device_by_node(np);
> + } else {
> + kfree(pd);
> + return -ENODEV;
> + }
> + } else {
> + pd = pdev->dev.platform_data;
> + }
> +
> if (pd == NULL) {
> dev_err(&pdev->dev, "no mv643xx_eth_platform_data\n");
> return -ENODEV;
[...]
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL] CSR SiRFmarco SoC infrastructures for 3.9
From: Barry Song @ 2013-01-28 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128070848.GG25723@quad.lixom.net>
2013/1/28 Olof Johansson <olof@lixom.net>:
> 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!
Olof, 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.
there have been. arch/arm/configs/prima2_defconfig
>
> -Olof
-barry
^ permalink raw reply
* [PATCH] mfd/vexpress: vexpress_sysreg_setup must not be __init
From: Pawel Moll @ 2013-01-28 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359140032-6039-1-git-send-email-arnd@arndb.de>
On Fri, 2013-01-25 at 18:53 +0000, Arnd Bergmann wrote:
> The patch 52666298a 'mfd: vexpress-sysreg: Don't skip initialization
> on probe' adds a call to vexpress_sysreg_setup from a non-__init
> function, so this also has to lose its __init annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: arm at kernel.org
> ---
> drivers/mfd/vexpress-sysreg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
> index 77048b1..558c292 100644
> --- a/drivers/mfd/vexpress-sysreg.c
> +++ b/drivers/mfd/vexpress-sysreg.c
> @@ -313,7 +313,7 @@ static void vexpress_sysreg_config_complete(unsigned long data)
> }
>
>
> -void __init vexpress_sysreg_setup(struct device_node *node)
> +void vexpress_sysreg_setup(struct device_node *node)
> {
> if (WARN_ON(!vexpress_sysreg_base))
> return;
Acked-by: Pawel Moll <pawel.moll@arm.com>
Thanks!
Pawel
^ permalink raw reply
* [BUG] panda board locks up on boot
From: Mats Liljegren @ 2013-01-28 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51053AD2.8080805@gmail.com>
> From: Nishanth Menon [mailto:menon.nishanth at gmail.com]
> Sent: den 27 januari 2013 15:34
> To: Paolo Pisati
> Cc: Mats Liljegren; Tony Lindgren; LKML; Steven Rostedt; Igor Grinberg;
> Russell King; Venkatraman S; linux-arm-kernel; linux-omap
> Subject: Re: [BUG] panda board locks up on boot
>
> On 01/27/2013 08:12 AM, Paolo Pisati wrote:
> > On Fri, Jan 25, 2013 at 08:43:15AM +0000, Mats Liljegren wrote:
> >> Hi Steven,
> >>
> >> Do you have CONFIG_CPU_FREQ enabled? As I posted earlier in linux-
> kernel forum ("Failed booting PandaBoard ES with Linux 3.8 RC4" two days
> ago) my PandaBoard ES hangs while booting with this option enabled. It
> works fine without it. I have not bisected it down to a single commit though.
> >
> > glad i'm not the only one who hit this problem:
> >
> > "3.8rc4+ and cpu_freq omap: hangs, oopses, etcetc"
> >
> > http://www.mail-archive.com/linux-
> omap at vger.kernel.org/msg83693.html
> >
>
> Support for TPS is not yet in mainline kernel. you may want to do:
>
> you could try running 'mw.w 0x4A31E05A 0x1' before bootm in u-boot -> This
> will hack the pad of panda ES pin mean for controlling TPS voltage register
> (again a kernel bug where the GPIO block setup by bootloader got reset).
>
> CPUfreq needs both voltage and frequency scaling to work and without
> support of the TPS voltage scaling on vdd_MPU, you are stuck at boot
> voltage, and just scaling frequency. with the not-enough boot voltage,
> moving to higher frequencies can/will result in unpredictable behavior.
>
> ---
> Regards,
> NM
Thanks for the suggestion. Unfortunately it didn't make any difference for me, neither did an upgrade to 3.8-rc5. I guess I have to wait for the TPS support to hit mainline kernel.
Regards
Mats
^ permalink raw reply
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Thierry Reding @ 2013-01-28 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51064687.5090605@epfl.ch>
On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote:
> Hello,
>
> Le 28/01/2013 09:45, Peter Ujfalusi a ?crit :
> >hi Thierry,
> >
> >On 01/26/2013 06:40 AM, Thierry Reding wrote:
[...]
> >>>+{
> >>>+ return pwm->chip->can_sleep;
> >>>+}
> >>>+EXPORT_SYMBOL_GPL(pwm_cansleep);
> >>
> >>Would it make sense to check for NULL pointers here? I guess that
> >>passing NULL into the function could be considered a programming error
> >>and an oops would be okay, but in that case there's no point in making
> >>the function return an int. Also see my next comment.
> >
> >While it is unlikely to happen it is better to be safe, something like this
> >will do:
> >
> >return pwm ? pwm->chip->can_sleep : 0;
> >
>
> Ok. And what about:
>
> BUG_ON(pwm == NULL);
> return pwm->chip->can_sleep;
I don't think we need that. In case pwm == NULL, dereferencing it will
oops anyway. So either we make it safe and return an error code, or we
let it oops without explicit BUG_ON().
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130128/4f4439e5/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Mohammed, Afzal @ 2013-01-28 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGtrHBxvnp052K6z3aj3dAxJf1hy7H72EoAWr6PhTtwr8Q@mail.gmail.com>
Hi Rob,
On Fri, Jan 25, 2013 at 20:22:55, Rob Clark wrote:
> On Fri, Jan 25, 2013 at 8:15 AM, Mohammed, Afzal <afzal@ti.com> wrote:
> > It's not about being simple, but not doing the wrong way, here you are
> > relying on a platform specific clock in a driver, think about the case
> > where same IP is used on another platform. Either way it is not a good
> > thing to handle platform specific details (about disp_clk) in driver.
> Right, but I was trying to understand what was the benefit that the
> added complexity is. I didn't realize on davinci that you are limited
Here I am referring to usage of disp_clk,
Driver is not supposed to do platform hacks - here you are trying to
configure something (PLL) in your driver which is not part of LCDC IP.
And LCDC IP is not aware of PLL which is a platform specific matter
(existent only in AM335x), it is only aware of functional clock.
You can set the rate on "fck" (functional clock) in AM335x using my patch,
"ARM: AM33XX: clock: SET_RATE_PARENT in lcd path", and there
would not be any need for driver to be aware of platform specific PLL.
> >> >> + priv->clk = clk_get(dev->dev, "fck");
> >> >> + priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
> at the moment all this discussion is a bit moot. I'd propose leaving
> the driver as it is for now, because that at least makes it useful on
> am33xx. And when CCF and davinci have the needed support in place,
Let's forget about leveraging CCF in driver, but sane solution w.r.t PLL
configuration would be to do as mentioned above.
Regards
Afzal
^ permalink raw reply
* [PATCH 10/19] watchdog: at91sam9: at91_wdt_dt_ids cannot be __init
From: Fabio Porcedda @ 2013-01-28 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359153858-31992-11-git-send-email-arnd@arndb.de>
Hi Arnd,
On Fri, Jan 25, 2013 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 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)
Thanks for fixing my commit.
Best regards
> 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>
> 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 */ }
> };
> --
> 1.8.0
>
--
Fabio Porcedda
^ permalink raw reply
* [PATCH v2] DMAEngine: sirf: add DMA pause/resume support
From: Vinod Koul @ 2013-01-28 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355482762-28688-1-git-send-email-Barry.Song@csr.com>
On Fri, 2012-12-14 at 18:59 +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> pause/resume are important for users like ALSA sound drivers,
> this patches make the sirf prima2/marco support DMA commands
> DMA_PAUSE and DMA_RESUME.
Applied this and sirf: lock the shared registers access in
sirfsoc_dma_terminate_all, thanks
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Florian Vaussard @ 2013-01-28 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51063AB5.2060108@ti.com>
Hello,
Le 28/01/2013 09:45, Peter Ujfalusi a ?crit :
> hi Thierry,
>
> On 01/26/2013 06:40 AM, Thierry Reding wrote:
>>> + * @pwm: PWM device
>>> + *
>>> + * It returns nonzero if accessing the PWM can sleep.
>>> + */
>>> +int pwm_cansleep(struct pwm_device *pwm)
>>
>> I actually liked pwm_can_sleep() better. I find it to be more consistent
>> with the naming of other function names. It would furthermore match the
>> field name.
>
> I was looking at the GPIO API to suggest this name change, but you are right
> we should be consistent with the PWM API here.
> Sorry Florian.
>
No problem, I agree with the PWM API consistency.
>>
>>> +{
>>> + return pwm->chip->can_sleep;
>>> +}
>>> +EXPORT_SYMBOL_GPL(pwm_cansleep);
>>
>> Would it make sense to check for NULL pointers here? I guess that
>> passing NULL into the function could be considered a programming error
>> and an oops would be okay, but in that case there's no point in making
>> the function return an int. Also see my next comment.
>
> While it is unlikely to happen it is better to be safe, something like this
> will do:
>
> return pwm ? pwm->chip->can_sleep : 0;
>
Ok. And what about:
BUG_ON(pwm == NULL);
return pwm->chip->can_sleep;
>>
>>> +
>>> #ifdef CONFIG_DEBUG_FS
>>> static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
>>> {
>>> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
>>> index 70655a2..e2cb5c7 100644
>>> --- a/include/linux/pwm.h
>>> +++ b/include/linux/pwm.h
>>> @@ -146,6 +146,8 @@ struct pwm_ops {
>>> * @base: number of first PWM controlled by this chip
>>> * @npwm: number of PWMs controlled by this chip
>>> * @pwms: array of PWM devices allocated by the framework
>>> + * @can_sleep: flag must be set iff config()/enable()/disable() methods sleep,
>>> + * as they must while accessing PWM chips over I2C or SPI
>>> */
>>> struct pwm_chip {
>>> struct device *dev;
>>> @@ -159,6 +161,7 @@ struct pwm_chip {
>>> struct pwm_device * (*of_xlate)(struct pwm_chip *pc,
>>> const struct of_phandle_args *args);
>>> unsigned int of_pwm_n_cells;
>>> + unsigned int can_sleep:1;
>>
>> What's the reason for making this a bitfield? Couldn't we just use a
>> bool instead?
>
> I have also overlooked this. In my version I had the can_sleep as bool also.
>
Ok for a bool.
Thank you for your reviews. I will send a v3 sometimes today.
Cheers,
Florian
^ permalink raw reply
* [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
From: Mohammed, Afzal @ 2013-01-28 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125222032.10623.47200@quantum>
Hi Mike,
On Sat, Jan 26, 2013 at 03:50:32, Mike Turquette wrote:
> Is MULT_ROUND_UP doing the right thing for you in the clk_divider code?
> What is the clock rate requested of the parent PLL? I just want to make
> sure that we're doing the right thing in the basic divider code.
Actually MULT_ROUND_UP made my life difficult earlier, and finally came up
with this solution instead of removing it.
It was something like 60000000 requested of PLL, for i = 1, but for other
values, it was something like 60000001, 60000002 etc.
Even if round rate rounds, I thought removing MULT_ROUND_UP would be ok,
couldn't spend time to understand fully rational behind it, and as it was
in generic code, kept away from doing it.
Regards
Afzal
^ permalink raw reply
* [PATCH v2 1/2] clk: divider: prepare for minimum divider
From: Mohammed, Afzal @ 2013-01-28 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125223524.10623.29375@quantum>
Hi Mike,
On Sat, Jan 26, 2013 at 04:05:24, Mike Turquette wrote:
> Thank you for the information. In short, the way you program your clock
> depend on the configuration of your lcdc device.
>
> As such I am not sure the basic divider is the right choice for you.
> You might be better off creating a clock for your IP which takes into
> account these details. Luckily it is possible to inherit from the basic
> clock types and create a new type.
>
> An example of this is the MXS divider. It uses the basic divider as a
> "parent class" and adds a busy bit. This is a better approach than
> putting every feature into the basic divider type. You can see how it
> was done in drivers/clk/mxs/clk-div.c
>
> Let me know what you think.
Yes, a derived divider is better.
As mentioned in other thread, the modeling of clock nodes (derived plus
gates) would bring in considerable (relative to complete driver) code, the
advantage being higher pixel clock resolution. Current use cases work
as per existing divider setting in driver. Hence now it seems a better
decision now is to proceed with logic as in v2 (not using clock nodes).
And later depending on the use case requirement, clock tree modeling can
be implemented.
Thanks for your input.
Regards
Afzal
^ permalink raw reply
* [PATCH v5 31/45] blackfin/smp: Use get/put_online_cpus_atomic() to prevent CPU offline
From: Bob Liu @ 2013-01-28 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122074123.13822.39102.stgit@srivatsabhat.in.ibm.com>
On Tue, Jan 22, 2013 at 3:41 PM, Srivatsa S. Bhat
<srivatsa.bhat@linux.vnet.ibm.com> wrote:
> Once stop_machine() is gone from the CPU offline path, we won't be able to
> depend on preempt_disable() or local_irq_disable() to prevent CPUs from
> going offline from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
> while invoking from atomic context.
>
> Cc: Mike Frysinger <vapier@gentoo.org>
> Cc: Bob Liu <lliubbo@gmail.com>
> Cc: Steven Miao <realmz6@gmail.com>
> Cc: uclinux-dist-devel at blackfin.uclinux.org
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Thanks, will be applied to my blackfin arch tree.
> ---
>
> arch/blackfin/mach-common/smp.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/blackfin/mach-common/smp.c b/arch/blackfin/mach-common/smp.c
> index bb61ae4..6cc6d7a 100644
> --- a/arch/blackfin/mach-common/smp.c
> +++ b/arch/blackfin/mach-common/smp.c
> @@ -194,6 +194,7 @@ void send_ipi(const struct cpumask *cpumask, enum ipi_message_type msg)
> struct ipi_data *bfin_ipi_data;
> unsigned long flags;
>
> + get_online_cpus_atomic();
> local_irq_save(flags);
> smp_mb();
> for_each_cpu(cpu, cpumask) {
> @@ -205,6 +206,7 @@ void send_ipi(const struct cpumask *cpumask, enum ipi_message_type msg)
> }
>
> local_irq_restore(flags);
> + put_online_cpus_atomic();
> }
>
> void arch_send_call_function_single_ipi(int cpu)
> @@ -238,13 +240,13 @@ void smp_send_stop(void)
> {
> cpumask_t callmap;
>
> - preempt_disable();
> + get_online_cpus_atomic();
> cpumask_copy(&callmap, cpu_online_mask);
> cpumask_clear_cpu(smp_processor_id(), &callmap);
> if (!cpumask_empty(&callmap))
> send_ipi(&callmap, BFIN_IPI_CPU_STOP);
>
> - preempt_enable();
> + put_online_cpus_atomic();
>
> return;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Regards,
--Bob
^ permalink raw reply
* [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
From: Mark Rutland @ 2013-01-28 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016c01cdfb30$64f80430$2ee80c90$@samsung.com>
On Fri, Jan 25, 2013 at 07:15:48PM +0000, Kukjin Kim wrote:
> Tomasz Figa wrote:
>
> [...]
>
> > > Well, the number of CPU types does not grow rapidly. It will be much
> > > less than one per SoC -- so keeping the list up to date shouldn't be
> > > that much effort.
> > >
> > > For ARM1176JZF-S, it could make sense for the comatible list to be
> > >
> > > "arm,arm1176jzf-s", "arm,arm1176"
> > >
> > > ...since the differences between 1176 variants are software probeable
> > > (i.e., whether there is an FPU or not). AFAIK the J, Z apply to all
> > > ARM1176, and the -S (synthesisable RTL) is nothing to do with software.
> > > The kernel probably only really needs to know "arm,arm1176".
> >
> > OK. So the conclusion is that I should change the cpus node to following:
> >
> > cpus {
> > cpu {
>
> cpu at 0 { ?
As the CPU has no MPIDR, and thus doesn't have a reg property, there's no reason
to have a unit address. Just "cpu" should be fine.
>
> > compatible = "arm,arm1176jzf-s", "arm,arm1176";
> > };
> > };
> >
> > Am I right?
> >
> I think so :-)
>
> - Kukjin
>
As Dave pointed out, the "jzf-s" portion might be superfluous. It's worth
having the "arm,arm1176", though.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 10/26] mfd: ab8500-debugfs: Wake-up device on debugfs IRQ
From: Lee Jones @ 2013-01-28 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235309.GP1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:55:50PM +0000, Lee Jones wrote:
> > Ensure the device wakes up if the debugfs IRQ fires if we're
> > in suspend mode.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/mfd/ab8500-debugfs.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> Please squash this one with the previous one.
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
* [PATCH 13/26] mfd: ab8500-debugfs: Formated access AB8500 registers from debugfs entry
From: Lee Jones @ 2013-01-28 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235318.GQ1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:55:53PM +0000, Lee Jones wrote:
> > +static ssize_t hwreg_common_write(char *b, struct hwreg_cfg *cfg,
> > + struct device *dev)
> > +{
> > + uint write, val = 0;
> > + struct hwreg_cfg loc = {
> > + .bank = 0, /* default: invalid phys addr */
> > + .addr = 0, /* default: invalid phys addr */
> > + .fmt = 0, /* default: 32bit access, hex output */
> > + .mask = 0xFFFFFFFF, /* default: no mask */
> > + .shift = 0, /* default: no bit shift */
> > + };
> > +
> > + /* read or write ? */
> > + if (!strncmp(b, "read ", 5)) {
> > + write = 0;
> > + b += 5;
> > + } else if (!strncmp(b, "write ", 6)) {
> > + write = 1;
> > + b += 6;
> > + } else
> > + return -EINVAL;
> > +
> > + /* OPTIONS -l|-w|-b -s -m -o */
> > + while ((*b == ' ') || (*b == '-')) {
> > + if (*(b-1) != ' ') {
> > + b++;
> > + continue;
> > + }
> > + if ((!strncmp(b, "-d ", 3)) ||
> > + (!strncmp(b, "-dec ", 5))) {
> > + b += (*(b+2) == ' ') ? 3 : 5;
> > + loc.fmt |= (1<<0);
> > + } else if ((!strncmp(b, "-h ", 3)) ||
> > + (!strncmp(b, "-hex ", 5))) {
> > + b += (*(b+2) == ' ') ? 3 : 5;
> > + loc.fmt &= ~(1<<0);
> > + } else if ((!strncmp(b, "-m ", 3)) ||
> > + (!strncmp(b, "-mask ", 6))) {
> > + b += (*(b+2) == ' ') ? 3 : 6;
> > + if (strval_len(b) == 0)
> > + return -EINVAL;
> > + loc.mask = simple_strtoul(b, &b, 0);
> > + } else if ((!strncmp(b, "-s ", 3)) ||
> > + (!strncmp(b, "-shift ", 7))) {
> > + b += (*(b+2) == ' ') ? 3 : 7;
> > + if (strval_len(b) == 0)
> > + return -EINVAL;
> > + loc.shift = simple_strtol(b, &b, 0);
> > + } else {
> > + return -EINVAL;
> > + }
> > + }
> > + /* get arg BANK and ADDRESS */
> > + if (strval_len(b) == 0)
> > + return -EINVAL;
> > + loc.bank = simple_strtoul(b, &b, 0);
> > + while (*b == ' ')
> > + b++;
> > + if (strval_len(b) == 0)
> > + return -EINVAL;
> > + loc.addr = simple_strtoul(b, &b, 0);
> > +
> > + if (write) {
> > + while (*b == ' ')
> > + b++;
> > + if (strval_len(b) == 0)
> > + return -EINVAL;
> > + val = simple_strtoul(b, &b, 0);
> > + }
> > +
> > + /* args are ok, update target cfg (mainly for read) */
> > + *cfg = loc;
> > +
> > +#if ABB_HWREG_DEBUG
> > + pr_warn("HWREG request: %s, %s, addr=0x%08X, mask=0x%X, shift=%d
> > + value=0x%X\n", (write) ? "write" : "read",
> > + REG_FMT_DEC(cfg) ? "decimal" : "hexa",
> > + cfg->addr, cfg->mask, cfg->shift, val);
> > +#endif
> > +
> > + if (write) {
> if (!write)
> return 0;
>
> for a more readable code.
I'll fixup.
> > + u8 regvalue;
> > + int ret = abx500_get_register_interruptible(dev,
> > + (u8)cfg->bank, (u8)cfg->addr, ®value);
> > + if (ret < 0) {
> > + dev_err(dev, "abx500_get_reg fail %d, %d\n",
> > + ret, __LINE__);
> > + return -EINVAL;
> > + }
> > +
> > + if (cfg->shift >= 0) {
> > + regvalue &= ~(cfg->mask << (cfg->shift));
> > + val = (val & cfg->mask) << (cfg->shift);
> > + } else {
> > + regvalue &= ~(cfg->mask >> (-cfg->shift));
> > + val = (val & cfg->mask) >> (-cfg->shift);
> > + }
> > + val = val | regvalue;
> > +
> > + ret = abx500_set_register_interruptible(dev,
> > + (u8)cfg->bank, (u8)cfg->addr, (u8)val);
> > + if (ret < 0) {
> > + pr_err("abx500_set_reg failed %d, %d", ret, __LINE__);
> > + return -EINVAL;
> > + }
> > +
> > + }
> > + return 0;
> > +}
> I think this is a pretty big routine, that could be split into a command
> parsing part and the actual register write one.
I've made a note to address this as the _end_ of the big push. I'd
really like to avoid any unnecessary conflicts.
--
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 14/26] mfd: ab8500-debugfs: Fix introduced compiler time warnings
From: Lee Jones @ 2013-01-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235327.GR1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:55:54PM +0000, Lee Jones wrote:
> > From: Philippe Langlais <philippe.langlais@stericsson.com>
> >
> > Some simple fixes regarding pre-processor usage.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
> > ---
> > drivers/mfd/ab8500-debugfs.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> Here again, please squash this one with the previous one.
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
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Peter Ujfalusi @ 2013-01-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126054024.GB29243@avionic-0098.adnet.avionic-design.de>
hi Thierry,
On 01/26/2013 06:40 AM, Thierry Reding wrote:
>> + * @pwm: PWM device
>> + *
>> + * It returns nonzero if accessing the PWM can sleep.
>> + */
>> +int pwm_cansleep(struct pwm_device *pwm)
>
> I actually liked pwm_can_sleep() better. I find it to be more consistent
> with the naming of other function names. It would furthermore match the
> field name.
I was looking at the GPIO API to suggest this name change, but you are right
we should be consistent with the PWM API here.
Sorry Florian.
>
>> +{
>> + return pwm->chip->can_sleep;
>> +}
>> +EXPORT_SYMBOL_GPL(pwm_cansleep);
>
> Would it make sense to check for NULL pointers here? I guess that
> passing NULL into the function could be considered a programming error
> and an oops would be okay, but in that case there's no point in making
> the function return an int. Also see my next comment.
While it is unlikely to happen it is better to be safe, something like this
will do:
return pwm ? pwm->chip->can_sleep : 0;
>
>> +
>> #ifdef CONFIG_DEBUG_FS
>> static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
>> {
>> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
>> index 70655a2..e2cb5c7 100644
>> --- a/include/linux/pwm.h
>> +++ b/include/linux/pwm.h
>> @@ -146,6 +146,8 @@ struct pwm_ops {
>> * @base: number of first PWM controlled by this chip
>> * @npwm: number of PWMs controlled by this chip
>> * @pwms: array of PWM devices allocated by the framework
>> + * @can_sleep: flag must be set iff config()/enable()/disable() methods sleep,
>> + * as they must while accessing PWM chips over I2C or SPI
>> */
>> struct pwm_chip {
>> struct device *dev;
>> @@ -159,6 +161,7 @@ struct pwm_chip {
>> struct pwm_device * (*of_xlate)(struct pwm_chip *pc,
>> const struct of_phandle_args *args);
>> unsigned int of_pwm_n_cells;
>> + unsigned int can_sleep:1;
>
> What's the reason for making this a bitfield? Couldn't we just use a
> bool instead?
I have also overlooked this. In my version I had the can_sleep as bool also.
--
P?ter
^ permalink raw reply
* [PATCH 25/26] mfd: ab8500-gpadc: Reduce conversion timeout
From: Lee Jones @ 2013-01-28 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127235339.GS1174@sortiz-mobl>
On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> Hi Lee,
>
> On Tue, Jan 15, 2013 at 12:56:05PM +0000, Lee Jones wrote:
> > @@ -598,8 +601,6 @@ static int ab8500_gpadc_runtime_resume(struct device *dev)
> >
> > static int ab8500_gpadc_runtime_idle(struct device *dev)
> > {
> > - struct ab8500_gpadc *gpadc = dev_get_drvdata(dev);
> > -
> Unrelated change, please remove that part.
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
* [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