Re: [PATCH v3 3/4] net: davinci_mdio: drop pinctrl_pm_select_default_state from probe
On Wed, Apr 30, 2014 at 2:23 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: The default pinctrl state is set by Drivers core now before calling the driver's probe. Hence, it's safe to drop pinctrl_pm_select_default_state() call from Davinci mdio driver probe. Cc: Florian Fainelli f.faine...@gmail.com Cc: Linus Walleij linus.wall...@linaro.org Acked-and-tested-by: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
On Tue, Mar 18, 2014 at 10:45 AM, Alexander Holler hol...@ahsoftware.de wrote: But I don't need any rush here, I'm just unable to understand why the -rc phase isn't used for bug fixing as I believe that's what this phase is for. Right now it is mostly a practical issue to me, as I applied the patch to the devel (for-next) branch, then committed new development on top of it. If I send it for fixes now the same patch will come in two ways as I really do not like to rebase my tree at this point. So I'd prefer to keep this for next and then have it tagged for stable as v3.14 is released, if that is OK? It's as simple as sending a mail to Greg once it's upstream. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
On Mon, Mar 17, 2014 at 2:29 PM, Sekhar Nori nsek...@ti.com wrote: One thing to note is that this driver is used by keystone too and all its users are DT-only. Although I do not see any in-kernel DT GPIO users even there. I can confirm the patch does not break my gpiolib based test module (test with and without DT), but then it did not have an issue even before. Is that a Tested-by tag? :-) If you're also convinced that fix is safe I'll push it as a fix to v3.14-rcN if for nothing else so for getting Mr. Holler to stop poking me in the chest. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
On Mon, Mar 17, 2014 at 3:11 PM, Alexander Holler hol...@ahsoftware.de wrote: Thanks, maybe someone could add a Cc: sta...@vger.kernel.org OK if it goes in as fix I'll add this. to get the fix back into 3.14 if it has go through -next. It's already in linux-next. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.03.2014 11:15, schrieb Linus Walleij: On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler hol...@ahsoftware.de wrote: The driver missed an of_xlate function to translate gpio numbers as found in the DT to the correct chip and number. While there I've set #gpio_cells to a fixed value of 2. I've used gpio-pxa.c as template for those changes and tested my changes successfully on a da850 board using entries for gpio-leds in a DT. So I didn't reinvent the wheel but just copied and tested stuff. Thanks to Grygorii Strashko for the hint to the existing code in gpio-pxa. Signed-off-by: Alexander Holler hol...@ahsoftware.de Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com This v2 version applied, thanks! Thanks, but actually that should have been a fix for 3.14 with which the OF functionality for davinci gpio gets introduced. I assum with the patch in for-next, 3.14 will appear with that functionality broken and it will become a candidate for -stable. I just get the impression that DT support for DaVinci in v3.14 is so risky and unstable that noone except those implementing it (i.e. you) is really using it, is that correct? In that case it is hardly a fix that we need to rush out to the entire world. But if you have bug reports from DaVinci developers doing advanced DT stuff and scratching their heads, then we can push this to fixes. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
On Fri, Mar 14, 2014 at 1:38 PM, Alexander Holler hol...@ahsoftware.de wrote: In that case it is hardly a fix that we need to rush out to the entire world. And I thought the reason for -rc is actually to fix bugs. But I never understood the magical ways and timings patches make their way into mainline. ;) OK so it works like this: early in the -rc cycle we fix any bugs, documentation or whatever. At this point it's *regressions* so the fix need to fix something that broke in the merge window (or an earlier merge window). If it is a new feature that never worked in the first place I would not call that a regression. There are no existing users out there that can experience regressions from a previously working system. So this is why I'm a bit conservative. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RESEND][PATCH v4] gpio: davinci: reuse for keystone soc
On Thu, Feb 13, 2014 at 4:58 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: The similar GPIO HW block is used by keystone SoCs as in Davinci SoCs. Hence, reuse Davinci GPIO driver for Keystone taking into account that Keystone contains ARM GIC IRQ controller which is implemented using IRQ Chip. Documentation: http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Applied! Santosh hunted me down in person so it really happened this time... Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/5] gpio: remove obsolete tnetv107x driver
On Wed, Feb 26, 2014 at 8:43 PM, Arnd Bergmann a...@arndb.de wrote: The tnetv107x platform is getting removed, so this driver won't be needed any more. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: linux-g...@vger.kernel.org Can I have an ACK from some Sekhar to apply this to the GPIO tree, so we are all aligned? Or do you want my ACK to take this through ARM SoC? In that case Acked-by... Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] gpio: davinci: fix gpio selection for OF
On Wed, Mar 5, 2014 at 6:06 AM, Alexander Holler hol...@ahsoftware.de wrote: The driver missed an of_xlate function to translate gpio numbers as found in the DT to the correct chip and number. While there I've set #gpio_cells to a fixed value of 2. I've used gpio-pxa.c as template for those changes and tested my changes successfully on a da850 board using entries for gpio-leds in a DT. So I didn't reinvent the wheel but just copied and tested stuff. Thanks to Grygorii Strashko for the hint of the existing code in gpio-pxa. Signed-off-by: Alexander Holler hol...@ahsoftware.de Grygorii, can I have your review tag on this patch so I can apply it? Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/5] gpio: remove obsolete tnetv107x driver
On Wed, Mar 5, 2014 at 9:52 AM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Feb 26, 2014 at 8:43 PM, Arnd Bergmann a...@arndb.de wrote: The tnetv107x platform is getting removed, so this driver won't be needed any more. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: linux-g...@vger.kernel.org Can I have an ACK from some Sekhar to apply this to the GPIO tree, so we are all aligned? Bah I found the ACK on patch 0, sorry about the fuzz. Patch applied. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] gpio: davinci: reuse for keystone soc
On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: The similar GPIO HW block is used by keystone SoCs as in Davinci SoCs. Hence, reuse Davinci GPIO driver for Keystone taking into account that Keystone contains ARM GIC IRQ controller which is implemented using IRQ Chip. Documentation: http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- Changes in v4: - rebased on top of v3.14 + [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup() Are you taking this through ARM SoC or is this something I should be merging? Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
On Thu, Jan 9, 2014 at 6:28 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
irq needs to be signed for the error handling to work.
Fixes: 6075a8b2b6c3 ('gpio: davinci: don't create irq_domain in case of
unbanked irqs')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 7629b4f12b7f..b0e98d379217 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -423,7 +423,7 @@ static const struct irq_domain_ops davinci_gpio_irq_ops =
{
static int davinci_gpio_irq_setup(struct platform_device *pdev)
{
- unsignedgpio, irq, bank;
+ unsignedgpio, bank;
struct clk *clk;
u32 binten = 0;
unsignedngpio, bank_irq;
@@ -433,6 +433,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
struct davinci_gpio_platform_data *pdata = dev-platform_data;
struct davinci_gpio_regs __iomem *g;
struct irq_domain *irq_domain = NULL;
+ int irq;
ngpio = pdata-ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
Acked-by: Linus Walleij linus.wall...@linaro.org
This merge window the DaVinci GPIO changes are queued by the DaVinci
maintainers (this patch does not even apply to my tree) so DaVinci guys:
please pick up this patch.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch
On Mon, Dec 16, 2013 at 5:39 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: On Monday 16 December 2013 10:09 AM, Santosh Shilimkar wrote: The $subject series (2 patches) don't seems to be on your branch. Ofcourse Linus needs to ack them before they can be considered. I have couple of comments as well so refresh of the series would be needed. Linus, Can you also please look at them. I'm looking, sorry for the delay. Busy before christmas. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/2] gpio: davinci: reuse for keystone arch
On Wed, Dec 18, 2013 at 11:07 AM, Grygorii Strashko grygorii.stras...@ti.com wrote: This series is intended to update Davinci GPIO driver and reuse it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci. Keystone GPIO IP: supports: - up to 32 GPIO lines; - only unbanked irqs; See Documentation: Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf This series based on: https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio Changes in v2: - minor comments applied, no functional changes v1: https://lkml.org/lkml/2013/12/12/366 Acked-by: Linus Walleij linus.wall...@linaro.org For this v2 series. Expecting this to go in through the DaVinci tree! Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 6/6] ARM: davinci: da850 evm: add GPIO pinumux entries DT node
On Sun, Dec 15, 2013 at 2:13 PM, Sekhar Nori nsek...@ti.com wrote:
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
From: KV Sujith sujit...@ti.com
+
+ gpio_pins: pinmux_gpio_pins {
+ pinctrl-single,bits =
+ /* GPIO2_4 GPIO2_6 */
+ 0x18 0x8080 0xf0f0
+ /* GPIO2_8 GPIO2_15 */
+ 0x14 0x8008 0xf00f
+ /* GPIO3_12 GPIO3_13 */
+ 0x1C 0x8800 0xff00
+ /* GPIO4_0 GPIO4_1 */
+ 0x28 0x8800 0xff00
+ /* GPIO6_9 GPIO6_10 GPIO6_13 */
+ 0x34 0x08800800 0x0ff00f00
+ ;
+ };
};
Shouldn't these pinmux entries be part of actual device
node which needs them to be muxed this way?
The usual way to do it is to set up as states for the device,
or as a hog (on the pin controller itself).
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7] gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*
On Wed, Dec 11, 2013 at 6:52 PM, Prabhakar Lad
prabhakar.cse...@gmail.com wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch replaces the __raw_readl/writel with
{readl|writel}_relaxed(), Altough the code runs on ARMv5
based SOCs, changing this will help copying the code
for other uses.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
This patch is part of series [1] rest of the patches
are Acked/reviewed so posting this patch independently
and marking it as v7.
[1] http://www.spinics.net/lists/devicetree/msg13037.html
drivers/gpio/gpio-davinci.c | 36 ++--
Acked-by: Linus Walleij linus.wall...@linaro.org
Should I take this into the GPIO tree, or should it go
in through the DaVinci tree?
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 0/9] gpio: davinci: reuse for keystone arch
On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: [1] Depends on patch: [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio https://lkml.org/lkml/2013/11/8/22 [2] and depends on series from Prabhakar Lad: [PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement https://www.mail-archive.com/devicetree@vger.kernel.org/msg05970.html So this needs to go through the same tree as these patches. And I suggested that Sekhar queue them and either take them directly up to ARM SoC or send me a pull request to take it through the GPIO tree. I'm going to go in and review these now... Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API
On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack) from chained IRQ handler directly. Because, Davinci GPIO block is used by different SoCs, which, in turn, have different Main IRQ controllers (Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce diffrent set of IRQ chip callbacks. As result, call of gpio_irq_handler() on Keysone will simply cause crash the system, because ARM-GIC implements .irq_eoi() instead of .irq_ack(). Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as they are intended to handle exact such cases. Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 4/9] gpio: davinci: make IRQ initialization soc specific
On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: The Davinci GPIO IRQs initialization may need to be performed in a different way depending on SoC which use it. For example: - Davinci dm365 has AINTC irq controller, implemented using Generic IRQ chip, SPARSE_IRQ off; - Davinci da850 has cp-intc controller, implemented using IRQ chip; SPARSE_IRQ off; - Kestone has arm-gic controller, implemented using IRQ chip; SPARSE_IRQ on; Now this is a pretty big patch ... The big question that enters my mind is *why* is the da850 and dm365 not using SPARSE_IRQ? As it happens I'm on an ARM32 crusade to get everyone and its dog to use, among other things, SPARSE_IRQ. I would feel *much* *much* better if there was first a patch to the DaVinci tree to turn on SPARSE_IRQ for this subarch, and then this patch may look a bit different, maybe smaller I take it? Is this totally unattainable? Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 2/6] This patch converts the davinci gpio driver to use irqdomain support.
On Thu, Nov 21, 2013 at 7:15 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com [grygorii.stras...@ti.com: - switch to use one irq-domain per all GPIO banks - keep irq_create_mapping() call in gpio_to_irq_banked() as it simply transformed to irq_find_mapping() if IRQ mapping exist already] Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 5/9] gpio: davinci: reuse for Keystone SoC
On Tue, Nov 26, 2013 at 8:40 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: The similar GPIO HW block is used by keystone SoCs as in Davinci SoCs. Hence, reuse Davinci GPIO driver for Keystone. Documentation: http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com This is really nice, and we want to reuse stuff. Just waiting for some comments on the previous patch... Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 3/6] gpio: davinci: remove unused variable intc_irq_num
On Thu, Nov 21, 2013 at 7:15 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com As the davinci-gpio driver is migrated to use irqdomain there is no need to pass the irq base for the gpio driver. This patch removes this variable from davinci_gpio_platform_data and also the refrences from the machine file. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Acked-by: Linus Walleij linus.wall...@linaro.org *Very* nice patch! Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 4/6] gpio: davinci: add OF support
On Tue, Nov 26, 2013 at 6:12 PM, Sekhar Nori nsek...@ti.com wrote: On Tuesday 26 November 2013 06:03 PM, Grygorii Strashko wrote: Actually, the same was proposed by Linus, but we've tried avoid such huge rework - by switching to one irq_domain per all banks for example. I didn't really read that proposal from Linus so if two people independently suggested the same thing, there must be something worth considering there :) From a GPIO POV it's not such a big deal really, this approach is fine and the important thing is that we progress toward a more standard driver... it's more a question for the DT people IMO. I really like the current patch set. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement
On Thu, Nov 21, 2013 at 7:15 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series does the following 1 Ports the driver to use irqdomain. 2 Adds dt binding support for gpio-davinci. 3 Adds DA850 dt support goio. Changes for v6: 1: GPIO driver now migrated to irq domain legacy. 2: Fixed review comments pointed by Grygorii. 3: Included Ack's. This series is looking nice, I assume that Sekhar will take this through the DaVinci tree once he's happy with it. I think I've ACKed all relevant patches, else tell me. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] gpio: Remove duplicate include of errno.h
On Tue, Nov 19, 2013 at 1:32 PM, Vishwanathrao Badarkhe, Manish manish...@ti.com wrote: From: Vishwanathrao Badarkhe, Manish manish...@ti.com Currently, code include errno.h twice. Remove one inclusion of errno.h Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com Patch applied, thanks! Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 3/7] gpio: davinci: use irqdomain
On Tue, Nov 19, 2013 at 5:22 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: On 11/19/2013 01:06 AM, Linus Walleij wrote: The problem that appear is if someone is using platform data-provided IRQs off the irq_chip without calling gpio_to_irq() on the GPIO line first. This has been determined to be legal to do, so preferably create the map when registering the lines. Ok, I understand. It may fail in case if someone will define/calculate IRQ number for device manually in board code, like: dev_irq = (DA850_N_CP_INTC_IRQ + gpioN) Usually people just hardcode the IRQ value or use some #define, like they have often also done with GPIO numbers ... Also, looks like It is possible to fail if Main/arch IRQ controller code doesn't make call of irq_alloc_descs() during init, so allocated_irqs will be empty. If you use irq_domain_add_simple() the irqdomain core will actually attempt to do this. But if you use a linear domain, you have to create these irqdescs as you go. The simplest way to do this is to call irq_create_mapping() on all IRQs, because that call will also allocate some descriptor. Before recommending that, I've checked Davinci platform code and didn't find any risk places - BUT, Seems my findings need to be confirmed by Sekhar. It's no big deal, but I just want you to be aware that this may cause a problem at some point. I think you should try to keep the 5 irqdomains, but whatever gives the simplest code is usually the right answer, and divide-and-conquer (split down the problem) is usually a good idea. How the GPIO block(s) are represented in the device tree is another totally separate issue about hardware description, do not let the device tree model your driver structure. Thanks for you comments, but looks like I have to be more specific :) How irq_find_host() will look for proper IRQ domain in our case? And will it work at all, taking into account that all (5) IRQ domains will have the same value of of_node property? of_irq_to_resource() |-irq_of_parse_and_map() |-irq_create_of_mapping() |-irq_find_host(irq_data-np) where np will point on GPIO node. As result my question is about what do DT core frameworks allow or not allow to do? And according to that implementation of driver can be changed. Hm, I'm not like a super-expert on the interrupt core, but maybe you need to create subnodes inside the top node to represent this, then use of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev); to populate them from the main node. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio
On Tue, Nov 12, 2013 at 7:18 AM, Sekhar Nori nsek...@ti.com wrote: On Friday 08 November 2013 12:15 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch fixes a check for offset in gpio_to_irq_unbanked() and also assigns gpio_irq, gpio_unbanked of chips[0] to appropriate values which is used in gpio_to_irq_unbanked() function. Reported-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com You should note explicitly that this patch fixes broken unbanked IRQ support. You mostly just described what you are doing. I will fixup while committing. So you're carrying this patch Sekhar? Thanks: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 2/7] gpio: davinci: use readl/writel instead of __raw_*
On Fri, Nov 8, 2013 at 11:11 AM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch replaces the __raw_readl/writel with readl and writel, Although the code runs on ARMv5 based SOCs, changing this will help copying the code for other uses. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 3/7] gpio: davinci: use irqdomain
On Fri, Nov 8, 2013 at 11:11 AM, Prabhakar Lad
prabhakar.cse...@gmail.com wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch converts the davinci gpio driver to use irqdomain
support.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
(...)
@@ -282,8 +283,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
desc-irq_data.chip-irq_ack(desc-irq_data);
while (1) {
u32 status;
- int n;
- int res;
+ int bit;
Why is this an int? I think u8 would suffice.
/* now demux them to the right lowlevel handler */
- n = d-irq_base;
- if (irq 1) {
- n += 16;
- status = 16;
- }
-
while (status) {
- res = ffs(status);
- n += res;
- generic_handle_irq(n - 1);
- status = res;
+ bit = __ffs(status);
+ status = ~(1 bit);
+ generic_handle_irq(irq_find_mapping(d-irq_domain,
+ bit));
This is a nice hunk of the patch.
I would use linux/bitops.h and do:
status = ~BIT(bit);
@@ -313,10 +307,7 @@ static int gpio_to_irq_banked(struct gpio_chip *chip,
unsigned offset)
{
struct davinci_gpio_controller *d = chip2controller(chip);
- if (d-irq_base = 0)
- return d-irq_base + offset;
- else
- return -ENODEV;
+ return irq_create_mapping(d-irq_domain, offset);
}
I think we recently established that map creating cannot be done
in gpio_to_irq* functions as that will not work properly if you request
an IRQ from device tree without first obtaining the IRQ from the GPIO
number with this function.
Instead call irq_create_mapping() on *all* used IRQ lines in the
probe function and use irq_find_mapping() here too.
+ for (gpio = 0, bank = 0; gpio ngpio; bank++, bank_irq++, gpio +=
16) {
/* disabled by default, enabled only as needed */
g = gpio2regs(gpio);
writel(~0, g-clr_falling);
@@ -467,14 +483,6 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
*/
irq_set_handler_data(bank_irq, chips[gpio / 32]);
So for example here you could call iurq_create_mapping();
Also: please write a patch that marks the IRQ lines.
Call gpio_lock_as_irq(*gpio_chip, offset); in the
irqchip startup/shutdown functions. (Can be a separate
patch.)
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 5/7] gpio: davinci: add OF support
On Fri, Nov 8, 2013 at 11:11 AM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: From: KV Sujith sujit...@ti.com This patch adds OF parser support for davinci gpio driver and also appropriate documentation in gpio-davinci.txt located at Documentation/devicetree/bindings/gpio/. Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com [prabhakar.cse...@gmail.com: simplified the OF code, removed unnecessary DT property and also simplified the commit message] Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com I like this patch now! Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 3/7] gpio: davinci: use irqdomain
On Mon, Nov 18, 2013 at 3:34 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
On 11/18/2013 03:11 PM, Linus Walleij wrote:
I think we recently established that map creating cannot be done
in gpio_to_irq* functions as that will not work properly if you request
an IRQ from device tree without first obtaining the IRQ from the GPIO
number with this function.
Why? Could you point on corresponding thread, pls?
All that contain this:
gpio: interrupt consistency check for OF GPIO IRQs
http://marc.info/?l=linux-kernelw=2r=1s=interrupt+consistencyq=b
Current call tree is:
irq_create_of_mapping()
|-hwirq = omain-ops-xlate()
|-irq_create_mapping(domain, hwirq)
OK that works for the pure device-tree scenario so mostly
this is OK.
The problem that appear is if someone is using platform data-provided
IRQs off the irq_chip without calling gpio_to_irq() on the GPIO line
first. This has been determined to be legal to do, so preferably
create the map when registering the lines.
Also: please write a patch that marks the IRQ lines.
Call gpio_lock_as_irq(*gpio_chip, offset); in the
irqchip startup/shutdown functions. (Can be a separate
patch.)
It seems, some misunderstanding is here. So I'd like to clarify few points
and would be very appreciate for your comments:
1) This patch itself will work unless we switch to DT (as in the following
patch)
Sure but this does not seem to have much to do
with my request to use gpio_lock_as_irq().
2) After this patch the following object structure will be created during
Davinci GPIO driver initialization (DA850 has 144 IRQ lines):
- gpio_chip0(0..31)
|- irq_domain1
- gpio_chip1(32..63)
|- irq_domain2
- gpio_chip2(64..95)
|- irq_domain3
- gpio_chip3(96..127)
|- irq_domain4
- gpio_chip4(128..143)
|- irq_domain5
OK that's nice.
3) But in case of DT only one GPIO controller node will be created
Example:
gpio: gpio@1e26000 {
compatible = ti,dm6441-gpio;
gpio-controller;
reg = 0x226000 0x1000;
interrupt-parent = intc;
interrupts = 42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH
46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH
48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH
50 IRQ_TYPE_EDGE_BOTH;
interrupt-controller;
#interrupt-cells = 2;
ti,ngpio = 144;
ti,davinci-gpio-unbanked = 0;
}
Yep...
4) As result, to make GPIO bindings/mappings work - we'll need to implement
.of_xlate() callback per GPIO chip, which will provide us with valid valid
gpio_chip and offset of gpio inside chip
(It was discussed before and supposed to be done as next step).
Yeah.. this is usually a bit tricky.
For example, gpio_chip3 and offset=15 should be selected:
devA {
gpios = gpio 111 GPIO_ACTIVE_HIGH;
}
5) What should be done to make GPIO IRQ bindings/mappings work?
Example:
devB {
interrupt-parent = gpio;
interrupts = 111 IRQ_TYPE_EDGE_BOTH;
}
Should we implement one IRQ domain per all GPIO chips (per GPIO controller)?
I don't know, I cannot really see where the problem is.
The IRQ domain is for translationg hardware numbers such as bit offsets
into Linux IRQ numbers and nothing else, so I'd suggest that as long as
the thing you are translating/mapping is something simple like a bit
index you're doing the right thing.
If it becomes something complex where that index is not just a bit
but an index into an array of registers at various locations it is
abusing the irqdomain.
So I think you should create one irqdomain per GPIO instance
or bank or whatever you want to call it: like if there is this one
register with 32 bits, then it gets its own IRQdomain.
I think you should try to keep the 5 irqdomains, but whatever
gives the simplest code is usually the right answer, and
divide-and-conquer (split down the problem) is usually a good
idea.
How the GPIO block(s) are represented in the device tree is
another totally separate issue about hardware description,
do not let the device tree model your driver structure.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 1/6] gpio: davinci: Fixed a check for unbanked gpio
On Wed, Nov 6, 2013 at 10:33 AM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: On Tue, Nov 5, 2013 at 6:09 PM, Linus Walleij linus.wall...@linaro.org wrote: On Sat, Nov 2, 2013 at 4:39 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch fixes the check for the offset in gpio_to_irq_unbanked() function. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Is this a regression that should go in right now? Yes it needs too. But on top of *what* exactly? This does not apply to my gpio tree devel branch and not even on the mainline kernel. Is this something that should go on top of the davinci GPIO patch set that is still being elaborated on? Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 1/6] gpio: davinci: Fixed a check for unbanked gpio
On Sat, Nov 2, 2013 at 4:39 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch fixes the check for the offset in gpio_to_irq_unbanked() function. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Is this a regression that should go in right now? Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 1/3] gpio: davinci: add OF support
On Fri, Oct 4, 2013 at 6:03 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: This patch adds OF parser support for davinci gpio driver and also appropriate documentation in gpio-davinci.txt located at Documentation/devicetree/bindings/gpio/. Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org ^Don't trust this guy. [prabhakar.cse...@gmail.com: simplified the OF code and also the commit message] Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/gpio/gpio-davinci.txt | 34 +++ drivers/gpio/gpio-davinci.c| 60 +++- 2 files changed, 91 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt new file mode 100644 index 000..87abd3b --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -0,0 +1,34 @@ +Davinci GPIO controller bindings + +Required Properties: +- compatible: should be ti,dm6441-gpio + +- reg: Physical base address of the controller and the size of memory mapped + registers. + +- gpio-controller : Marks the device node as a gpio controller. + +- interrupts: Array of GPIO interrupt number. + +- ngpio: The number of GPIO pins supported. + +- ti,davinci-gpio-irq-base: Base from where GPIO interrupt numbering starts. What is this? If I have ever ACKed this I have been drunk. I take it back. This base is a Linux-specific thing and has no place in the device tree, and shall not be there. You have to find some way to avoid this, what do you think some other OS should do with this value... All IRQs in Linux are assumed to be dynamically assigned numbers nowadays, with a property like this you can never switch on SPARSE_IRQ for the DaVinci. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 1/3] gpio: davinci: add OF support
On Fri, Oct 11, 2013 at 4:59 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: On 10/11/13, Linus Walleij linus.wall...@linaro.org wrote: On Fri, Oct 4, 2013 at 6:03 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: +- ti,davinci-gpio-irq-base: Base from where GPIO interrupt numbering starts. What is this? If I have ever ACKed this I have been drunk. I take it back. here is the ACK https://patchwork.kernel.org/patch/2721181/ And as suspected that version of the patch did not contain this strange node property. Don't keep my ACK on patches if you change basic stuff like that, they need to be re-acked, this runs the risk of abusing my trust amongst other subsystem maintainers who might go and merge this because aha the GPIO maintainer thinks that this is OK. This base is a Linux-specific thing and has no place in the device tree, and shall not be there. You have to find some way to avoid this, what do you think some other OS should do with this value... All IRQs in Linux are assumed to be dynamically assigned numbers nowadays, with a property like this you can never switch on SPARSE_IRQ for the DaVinci. Can you point to any alternative solution if you have any ? First convert this GPIO driver to use an irqdomain to map HW IRQs to Linux IRQs, and grab a few IRQ descriptors dynamically off the irq descriptor heap. Example: commit a6c45b99a658521291cfb66ecf035cc58b38f206 pinctrl/coh901: use irqdomain, allocate irqdescs Then on a longer term convert DaVinci to use dynamically allocated IRQs for all interrupt controllers, and move it over to SPARSE_IRQ so you know this works. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 1/3] gpio: davinci: add OF support
On Fri, Oct 11, 2013 at 6:18 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: On 10/11/13, Linus Walleij linus.wall...@linaro.org wrote: On Fri, Oct 11, 2013 at 4:59 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: On 10/11/13, Linus Walleij linus.wall...@linaro.org wrote: On Fri, Oct 4, 2013 at 6:03 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: +- ti,davinci-gpio-irq-base: Base from where GPIO interrupt numbering starts. What is this? If I have ever ACKed this I have been drunk. I take it back. here is the ACK https://patchwork.kernel.org/patch/2721181/ And as suspected that version of the patch did not contain this strange node property. The property did exist in the patch 'intc_irq_num', I just renamed it and gave a proper description to it. Hm yeah you're right ... I didn't understand what it was actually doing until I saw the revised documentation, I though it was stating the number of (hardware) IRQs, but it was stating the Linux-internal offset. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support
On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja gururaja.heb...@ti.com wrote: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Chris Ball c...@laptop.org Cc: linux-...@vger.kernel.org Cc: linux-o...@vger.kernel.org This is perfectly correct. Acked-by: Linus Walleij linus.wall...@linaro.org As the PM code seems to be similar across platforms I have had loose plans to move this to the device core as well, but right now I'm too busy with other things, and it can surely be refactored later. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 01/11] ARM: davinci: GPIO: Add platform data structure
On Wed, May 22, 2013 at 9:10 AM, Philip Avinash avinashphi...@ti.com wrote: From: KV Sujith sujit...@ti.com Add struct davinci_gpio_platform_data davinci gpio module. Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com Usually I squash such patches into the first patch making use of it, but the spirit is good so: Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 04/11] ARM: davinci: da8xx: creation of gpio platform device
On Wed, May 22, 2013 at 9:10 AM, Philip Avinash avinashphi...@ti.com wrote: From: KV Sujith sujit...@ti.com gpio controller resource information being associated with davinci_soc_info structure and not created any device. Hence davinci gpio didn't fall under proper device model. This patch creates gpio davinci as a platform device for da8xx platforms. - Add Memory and IRQ resources for DA8xx. - Register GPIO platform driver for DA8xx. - Add da8xx_register_gpio API to create platform device for da8xx platforms. Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 06/11] ARM: davinci: da8xx: gpio device creation
On Wed, May 22, 2013 at 9:10 AM, Philip Avinash avinashphi...@ti.com wrote: Create davinci gpio device and remove references in davinci_soc_info structure. Also rearrange header file inclusion in group basis. Signed-off-by: Philip Avinash avinashphi...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 05/11] ARM: davinci: creation of gpio platform device for dm platforms
On Wed, May 22, 2013 at 9:10 AM, Philip Avinash avinashphi...@ti.com wrote: gpio controller resource information being associated with davinci_soc_info structure and not created any device. Hence davinci gpio didn't fall under proper device model. This patch creates gpio davinci as a platform device for dm platforms. Also add daivinci_register_gpio API to create platform device for dm* platforms. Signed-off-by: Philip Avinash avinashphi...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 07/11] ARM: davinci: create davinci gpio device for dm platforms
On Wed, May 22, 2013 at 9:10 AM, Philip Avinash avinashphi...@ti.com wrote: Signed-off-by: Philip Avinash avinashphi...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/3] pinctrl: pinctrl-single: Add full fledge support to configure multiple pins of different modules
On Tue, May 21, 2013 at 4:07 PM, Manjunathappa, Prakash prakash...@ti.com wrote: Based function-mask and submask preoperties patch allocates and registers pins. Patch is fixes the issue reported and discussed here: http://www.spinics.net/lists/arm-kernel/msg235213.html I'd like Tony to ACK this, and Haojian to have a look at it before applying. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
On Tue, Feb 5, 2013 at 7:36 AM, Vishwanathrao Badarkhe, Manish
manish...@ti.com wrote:
I made following changes, in order to update dip-p pointer with
correct value:
- if (!dpi-p) {
+ if (IS_ERR_OR_NULL(dpi-p)) {
dpi-p = devm_pinctrl_get(dev);
- if (IS_ERR_OR_NULL(dpi-p)) {
- int ret = PTR_ERR(dpi-p);
-
- dev_dbg(dev, no pinctrl handle\n);
- /* Only return deferrals */
- if (ret == -EPROBE_DEFER)
- return ret;
- return 0;
- }
+ ret = PTR_ERR(dpi-p);
+ dev_dbg(dev, no pinctrl handle\n);
+ /* Only return deferrals */
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ return 0;
This is based on some old code that I wrote ages ago. Check the
pinctrl tree or linux-next for the latest core pin grabbing code.
Use that instead.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy cy...@ti.com wrote: On 02/04/2013 04:11 PM, Linus Walleij wrote: Cyril, just stack up the cookies and take a sweep over them to see which ones are baked when the NAPI poll comes in - problem solved. You're assuming that cookies complete in order. That is not necessarily true. So put them on a wait list? Surely you will have a list of pending cookies and pick from the front of the queue if there isn't a hole on queue position 0. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
want from the API. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: For IRQ mode, use the completion callback to push each cookie to NAPI, and thus let the IRQ drive the traffic. The whole purpose of NAPI is to avoid taking interrupts for completion of transfers. Anything that generates interrupts when NAPI is in polling mode is defeating the point. So what I was trying to get across is that when you're in polling mode you do not set DMA_PREP_INTERRUPT on your transfers, just throw the obtained struct dma_async_tx_descriptor on some list and then when polling use dma_async_is_tx_complete() on the channel and the cookie inside the descriptor. I was trying to describe that you can move from IRQ mode to polling mode and back again by selectively choosing to set/not set the DMA_PREP_INTERRUPT flag. If polling is all you want you never set it. Then there is the fact that the transfer needs to have been flagged complete and it is indeed something that needs to be set in some bytes somewhere. By something. But it doesn't have to be an interrupt from the DMA controller. In such cases we use dma_async_is_tx_complete() with channel and cookies as parameter. This will call down into the driver chan-device-device_tx_status() and there we can actually poll the hardware to see if the transfer happens to be complete, and if it is flag it complete. Which is likely what we want. No interrupts, only function calls as far as I can see. (I bet Russell will poke a hole in my reasoning, but it's worth a try.) Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 6:14 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote: So put them on a wait list? Surely you will have a list of pending cookies and pick from the front of the queue if there isn't a hole on queue position 0. Not quite. The key is the cookie system DMA engine employs to indicate when a cookie is complete. Cookies between the issued sequence and completed sequence are defined to be in progress, everything else is defined to be completed. This means that if completed sequence is 1, and issued sequence is 5, then cookies with values 2, 3, 4, 5 are in progress. You can't mark sequence 4 as being complete until 2 and 3 have completed. Yes that is true. DMA transfers on a certain channel are defined as progressing linearly per-cookie. I wonder if that is a problem in this case though (actually it seems the reverse, this helps in Cyril's case.) If we need out-of-order completion, then that's a problem for the DMA engine API, because you'd need to radically change the way completion is marked. True. I wonder if this usecase is ever going to be applicable however. It could maybe be useful in some instances of memcpy() I could dream up, whereas for device transfers it seems unlikely to me. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote: Based on our experience with fitting multiple subsystems on top of this DMA-Engine driver, I must say that the DMA-Engine interface has proven to be a less than ideal fit for the network driver use case. The first problem is that the DMA-Engine interface expects to push completed traffic up into the upper layer as a part of its callback. This doesn't fit cleanly with NAPI, which expects to pull completed traffic from below in the NAPI poll. We've somehow kludged together a solution around this, but it isn't very elegant. I cannot understand the actual technical problem from the above paragraphs though. dmaengine doesn't have a concept of pushing nor polling, it basically copies streams of words from A to B, where A/B can be a device or a buffer, nothing else. The thing you're looking for sounds more like an adapter on top of dmaengine, which can surely be constructed, some drivers/dma/dmaengine-napi.c or whatever. The second problem is one of binding fixed DMA resources to fixed users. AFAICT, the stock DMA-Engine mechanism works best when one DMA resource is as good as any other. The filter function picks a channel for whatever reason. That reason can be, well whatever. Some engines have a clever mechanism to select resources on the other end. Then for tying devices to channels we have the dmaengine DT branch: http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt This stuff didn't go into v3.8 but you can *sure* expect it to be in v3.9. Or are you referring to a multi-engine scenario? Say if there is engine A and B and depending on circumstances A or B may be preferred in some order (and permutations of this problem). That is currently identified as a shortcoming that we need help to address. To get over this problem, we've added support for named channels, and drivers specifically request for a DMA resource by name. Again, this is less than ideal. Jon Hunter has been working on a mechanism to look up DMA channels from struct device *, dev_name() or a device tree node for example. Just like we do with clocks or regulators. Look at this patch from the dmaengine_dt branch: http://git.infradead.org/users/vkoul/slave-dma.git/commitdiff/528499a7037ebec0636d928f88cd783c618df3c5 Looks up an optionally named channel for a certain device. It currently only supports device tree, but you are free to patch in whatever mechanism you need there. Static tables in platform data works too. Just nobody did it. So go ahead and hack on dma_request_slave_channel(). (I would just branch of the DT branch.) We found that virtio devices offer a more elegant solution to this problem. First, the virtqueue interface is a much better fit into NAPI (callback -- napi schedule, napi poll -- get_buf), and this eliminates the need for aforementioned kludges in the code. Second, the virtio device infrastructure nicely uses the device model to solve the problem of binding DMA users to specific DMA resources. Not that I understand the polling issue, but it sounds to me like what Jon is doing is similar. Surely the way to look up resources cannot be paramount in this discussion, I think the real problem must be your specific networking usecase, so we need to drill into that. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote: On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote: Based on our experience with fitting multiple subsystems on top of this DMA-Engine driver, I must say that the DMA-Engine interface has proven to be a less than ideal fit for the network driver use case. The first problem is that the DMA-Engine interface expects to push completed traffic up into the upper layer as a part of its callback. This doesn't fit cleanly with NAPI, which expects to pull completed traffic from below in the NAPI poll. We've somehow kludged together a solution around this, but it isn't very elegant. I cannot understand the actual technical problem from the above paragraphs though. dmaengine doesn't have a concept of pushing nor polling, it basically copies streams of words from A to B, where A/B can be a device or a buffer, nothing else. The thing you're looking for sounds more like an adapter on top of dmaengine, which can surely be constructed, some drivers/dma/dmaengine-napi.c or whatever. Broadly speaking what NAPI wants is to never get any callbacks from the hardware (or DMAs). It wants to wake up periodically, take a look at what packets have been read by the hardware and process them. The goal is to have the DMAs sitting and running without disturbing the processor at all after the first packet has been handled. OK we should definately be able to encompass that in dmaengine quite easily. So I think the above concerns are moot. The callback we can set on cookies is entirely optional, and it's even implemented by each DMA engine, and some may not even support it but *require* polling, and then it won't even be implemented by the driver. Which probably stems from the original design of the dmaengine API, which was for TCP networking acceleration, mainly. Cyril, just stack up the cookies and take a sweep over them to see which ones are baked when the NAPI poll comes in - problem solved. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish manish...@ti.com wrote: Currently, I2C driver gets probed before pinctrl driver. To achieve I2C pin muxing via pinctrl driver before I2C probe get called, register pinctrl driver in arch_initcall. Also, add module_exit to unregister pinctrl driver. Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com So your I2C driver is not returning -EPROBE_DEFER if it cannot find its pins? Hm, well I can live with this, if Tony ACKs it. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 3/3] ARM: davinci: da850: add NAND driver entries
On Wed, Jan 9, 2013 at 1:47 PM, Sekhar Nori nsek...@ti.com wrote:
On 1/8/2013 1:50 PM, Kumar, Anil wrote:
+pmx_core{
+ pinctrl-names = default;
+ pinctrl-0 =
+ nand_cs3_pins
+ ;
This means that the NAND pins are configured even if NAND is not
probed. Right? This can be moved into the nand_cs3 node to avoid that.
And then when used with Linus Walleij's patch drivers/pinctrl: grab
default handles from device core which should be accepted soon, the
pins will be automatically setup when the NAND gets probed.
That is correct, I am waiting for Greg's ACK on the core grab patch
(maybe it's higher up in my mailbox) and some indication from Stephen
Warren that it doesn't break the Tegra, and I'll put it into linux-next.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 01/11] clk: davinci - add main PLL clock driver
On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri m-kariche...@ti.com wrote: This is the driver for the main PLL clock hardware found on DM SoCs. This driver borrowed code from arch/arm/mach-davinci/clock.c and implemented the driver as per common clock provider API. The main PLL hardware typically has a multiplier, a pre-divider and a post-divider. Some of the SoCs has the divider fixed meaning they can not be configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used to tell the driver if a hardware has these dividers present or not. Driver is configured through the struct clk_pll_data that has the SoC specific clock data. Signed-off-by: Murali Karicheri m-kariche...@ti.com This looks good to me. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 02/11] clk: davinci - add PSC clock driver
On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri m-kariche...@ti.com wrote:
This is the driver for the Power Sleep Controller (PSC) hardware
found on DM SoCs as well Keystone SoCs (c6x). This driver borrowed
code from arch/arm/mach-davinci/psc.c and implemented the driver
as per common clock provider API. The PSC module is responsible for
enabling/disabling the Power Domain and Clock domain for different IPs
present in the SoC. The driver is configured through the clock data
passed to the driver through struct clk_psc_data.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Here is some pedantic stuff if you're really bored:
diff --git a/drivers/clk/davinci/clk-psc.c b/drivers/clk/davinci/clk-psc.c
(...)
+ ptcmd = 1 domain;
ptcmd = BIT(domain);
+ pdctl = readl(psc_base + PDCTL + 4 * domain);
+ pdctl |= 0x100;
pdctl |= BIT(8); /* and here a comment explaing what on earth that means */
+ } else {
+ ptcmd = 1 domain;
ptcmd = BIT(domain);
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri m-kariche...@ti.com wrote: This is the common clk driver initialization functions for DaVinci SoCs and other SoCs that uses similar hardware architecture. clock.h also defines struct types for clock definitions in a SoC and clock data type for configuring clk-mux. The initialization functions are used by clock initialization code in a specific platform/SoC. Signed-off-by: Murali Karicheri m-kariche...@ti.com This is looking good. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 04/11] clk: davinci - add pll divider clock driver
On Thu, Oct 25, 2012 at 6:11 PM, Murali Karicheri m-kariche...@ti.com wrote: pll dividers are present in the pll controller of DaVinci and Other SoCs that re-uses the same hardware IP. This has a enable bit for bypass the divider or enable the driver. This is a sub class of the clk-divider clock checks the enable bit to calculare the rate and invoke the recalculate() function of the clk-divider if enabled. Signed-off-by: Murali Karicheri m-kariche...@ti.com Looking good, Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ARM: config: sort select statements alphanumerically
On Fri, Oct 12, 2012 at 3:26 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: As suggested by Andrew Morton: This is a pet peeve of mine. Any time there's a long list of items (header file inclusions, kconfig entries, array initalisers, etc) and someone wants to add a new item, they *always* go and stick it at the end of the list. Guys, don't do this. Either put the new item into a randomly-chosen position or, probably better, alphanumerically sort the list. lets sort all our select statements alphanumerically. This commit was created by the following perl: I applied this and tried to configure the Nomadik defconfig, and I get this, sadly: make -f Makefile ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KBUILD_OUTPUT=/var/linus/linux/build-nomadik nhk8815_defconfig make[1]: Entering directory `/var/linus/linux' GEN /var/linus/linux/build-nomadik/Makefile arch/arm/mach-footbridge/Kconfig:29: syntax error arch/arm/mach-footbridge/Kconfig:28: unknown option Saying arch/arm/mach-footbridge/Kconfig:31: syntax error arch/arm/mach-footbridge/Kconfig:30: unknown option The arch/arm/mach-footbridge/Kconfig:31: unknown option There arch/arm/mach-footbridge/Kconfig:32: unknown option prototypes arch/arm/mach-footbridge/Kconfig:35: syntax error arch/arm/mach-footbridge/Kconfig:34: unknown option http arch/arm/mach-footbridge/Kconfig:37: syntax error arch/arm/mach-footbridge/Kconfig:36: unknown option If arch/arm/mach-footbridge/Kconfig:37: unknown option Server arch/arm/mach-pxa/Kconfig:18: syntax error arch/arm/mach-pxa/Kconfig:3: missing end statement for this entry arch/arm/mach-pxa/Kconfig:3: missing end statement for this entry arch/arm/Kconfig:245: missing end statement for this entry arch/arm/mach-pxa/Kconfig:17: invalid statement arch/arm/mach-pxa/Kconfig:632: unexpected end statement arch/arm/mach-pxa/Kconfig:634: syntax error arch/arm/mach-pxa/Kconfig:633: unexpected option select arch/arm/mach-pxa/Kconfig:634: unexpected option select arch/arm/mach-pxa/Kconfig:733: unexpected end statement arch/arm/Kconfig:1416: unexpected end statement make[3]: *** [nhk8815_defconfig] Error 1 make[2]: *** [nhk8815_defconfig] Error 2 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/var/linus/linux' make: *** [config-base] Error 2make -f Makefile ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KBUILD_OUTPUT=/var/linus/linux/build-nomadik nhk8815_defconfig make[1]: Entering directory `/var/linus/linux' GEN /var/linus/linux/build-nomadik/Makefile arch/arm/mach-footbridge/Kconfig:29: syntax error arch/arm/mach-footbridge/Kconfig:28: unknown option Saying arch/arm/mach-footbridge/Kconfig:31: syntax error arch/arm/mach-footbridge/Kconfig:30: unknown option The arch/arm/mach-footbridge/Kconfig:31: unknown option There arch/arm/mach-footbridge/Kconfig:32: unknown option prototypes arch/arm/mach-footbridge/Kconfig:35: syntax error arch/arm/mach-footbridge/Kconfig:34: unknown option http arch/arm/mach-footbridge/Kconfig:37: syntax error arch/arm/mach-footbridge/Kconfig:36: unknown option If arch/arm/mach-footbridge/Kconfig:37: unknown option Server arch/arm/mach-pxa/Kconfig:18: syntax error arch/arm/mach-pxa/Kconfig:3: missing end statement for this entry arch/arm/mach-pxa/Kconfig:3: missing end statement for this entry arch/arm/Kconfig:245: missing end statement for this entry arch/arm/mach-pxa/Kconfig:17: invalid statement arch/arm/mach-pxa/Kconfig:632: unexpected end statement arch/arm/mach-pxa/Kconfig:634: syntax error arch/arm/mach-pxa/Kconfig:633: unexpected option select arch/arm/mach-pxa/Kconfig:634: unexpected option select arch/arm/mach-pxa/Kconfig:733: unexpected end statement arch/arm/Kconfig:1416: unexpected end statement make[3]: *** [nhk8815_defconfig] Error 1 make[2]: *** [nhk8815_defconfig] Error 2 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/var/linus/linux' make: *** [config-base] Error 2 Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ARM: config: sort select statements alphanumerically
On Fri, Oct 12, 2012 at 4:48 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Instead, here's the updated script: Works like a charm, the result compiles and boots nicely. Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver
On Wed, Sep 26, 2012 at 8:07 PM, Murali Karicheri m-kariche...@ti.com wrote:
+struct clk_davinci_pll_data {
+ /* physical addresses set by platform code */
+ u32 phy_pllm;
+ /* if PLL has a prediv register this should be non zero */
+ u32 phy_prediv;
+ /* if PLL has a postdiv register this should be non zero */
+ u32 phy_postdiv;
+ /* mapped addresses. should be initialized by */
+ void __iomem *pllm;
+ void __iomem *prediv;
+ void __iomem *postdiv;
+ u32 pllm_mask;
+ u32 prediv_mask;
+ u32 postdiv_mask;
+ u32 num;
+ /* framework flags */
+ u32 flags;
+ /* pll flags */
+ u32 pll_flags;
+ /* use this value for prediv */
+ u32 fixed_prediv;
+ /* multiply PLLM by this factor. By default most SOC set this to zero
+* that translates to a multiplier of 1 and incrementer of 1.
+* To override default, set this factor
+*/
+ u32 pllm_multiplier;
+};
+
No, that's not what I meant.
I meant like this:
/**
* struct clk_davinci_pll_data - struct holding the PLL data
* phy_pllm: physical addresses set by platform code
* phy_prediv: ...
(...)
*/
struct clk_davinci_pll_data {
u32 phy_pllm;
u32 phy_prediv;
(...)
};
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v1 01/12] clk: davinci - add Main PLL clock driver
On Tue, Sep 25, 2012 at 12:20 AM, Murali Karicheri m-kariche...@ti.com wrote:
+struct clk_davinci_pll_data {
+ /* physical addresses set by platform code */
+ u32 phy_pllm;
+ /* if PLL has a prediv register this should be non zero */
+ u32 phy_prediv;
+ /* if PLL has a postdiv register this should be non zero */
+ u32 phy_postdiv;
+ /* mapped addresses. should be initialized by */
+ void __iomem *pllm;
+ void __iomem *prediv;
+ void __iomem *postdiv;
+ u32 pllm_mask;
+ u32 prediv_mask;
+ u32 postdiv_mask;
+ u32 num;
+ /* framework flags */
+ u32 flags;
+ /* pll flags */
+ u32 pll_flags;
+ u32 fixed_prediv; /* use this value for prediv */
+ u32 pllm_multiplier;/* multiply PLLM by this factor. By default
+* most SOC set this to zero that translates
+* to a multiplier of 1 and incrementer of 1.
+* To override default, set this factor */
+};
OMG this commenting style hurt my eyes ;-)
Please use good old kerneldoc above the struct instead.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] ARM: davinci: convert sched_clock() to use common infrastructure
On Fri, Dec 23, 2011 at 6:57 PM, Sekhar Nori nsek...@ti.com wrote: Convert davinci to use the common sched_clock() infrastructure for extending 32bit counters to full 64-bit nanoseconds. Eventually clocksource timer should be initialized from init_early so there would be no need to use a dummy clocksource read at start. Tested-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com This will collide with Marc Zyngiers runtime-selectable sched_clock() patches merged to linux-next recently, it probably won't even compile. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] asm-generic/gpio.h: merge basic gpiolib wrappers
On Fri, Oct 28, 2011 at 2:42 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Oct 28, 2011 at 02:15:00PM +0200, Mike Frysinger wrote: it's interesting you highlight davinci. if i'm reading things correctly, the current davinci code is broken today and my v2 proposed patch actually fixes it. That looks like an error in patch 5f3fcf9649dbb010ccac41259d04147775ec8fc2 (ARM: 7040/1: mach-davinci: break out GPIO driver specifics) which does this: -#define __ARM_GPIOLIB_COMPLEX Linus, can you send a fix? OK I'm onto it. Sorry for the mess! Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] mach-davinci: fix cache flush build error
On Wed, Aug 3, 2011 at 7:19 PM, Nori, Sekhar nsek...@ti.com wrote: This isn't the only thing that prevents building the TNET variant with the rest of the DaVinci variants. If you enable DM365 and TNETV107x together, you get errors: Looks like it needs some KConfig patch to disallow such combinations then? Considering this, Linus's patch looks fair to me. If there are no objections, I will queue for v3.1-rc Thanks! Linus, in future can you please CC me and/or Kevin on DaVinci patches? Yeah, sorry. Will do better. Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration
On Mon, Jul 11, 2011 at 11:39 PM, Dan Williams dan.j.willi...@intel.com wrote:
On Mon, Jul 11, 2011 at 2:28 AM, Linus Walleij linus.wall...@linaro.org
wrote:
...and I suspect the slave device drivers that use TI DMA are not
expected to ever work with other dmaengines? Likely the case, but
just wondering out loud.
Typically the OMAP/TI drivers are one-to-one with this specific DMA
controller, but they *can* support controllers without stride options, and
notice that striding will only be used for the display driver IIRC,
pseudo-code:
ret = dmaengine_device_control(chan, TI_DMA_STRIDE_CONFIG,
(unsigned long) my_stride_config);
if (ret) {
/*
* OK no striding on this DMA engine, fall back to something else,
* such as creating an SGlist which emulates the striding with one
* sglist element per stride.
*/
}
By injecting an error in the stride config path this can even be
properly tested. So it will become an optional acceleration.
Thanks,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration
On Tue, Jul 12, 2011 at 6:17 AM, Jassi Brar jassisinghb...@gmail.com wrote:
1) Striding, in one form or other, is supported by other DMACs as well.
The number will only increase in future.
Are we to add VENDOR_DMA_STRIDE_CONFIG for each case ?
If we are sure about this and striding will work in a similar way on all
then let's have the enum named DMA_STRIDE_CONFIG and move the
passed-in struct to linux/dmaengine.h) then?
Would that be:
struct dma_stride_config {
u32 read_bytes;
u32 skip_bytes;
};
Or something more complex?
2) As Dan noted, client drivers are going to have ifdef hackery in
order to be common
to other SoCs.
Don't think so, why? This is a runtime config entirely, and I just illustrated
in mail to Dan how that can be handled by falling back to a sglist I believe?
We can *maybe* even put the fallback code into dmaengine, so that an
emulated sglist in place for the DMAengine is done automatically of the
DMA controller does not support striding.
3) TI may not have just one DMAC IP used in all the SoCs. So if you want
vendor specific defines anyway, please atleast also add DMAC version to it.
Something like
DMA_SLAVE_CONFIG,
FSLDMA_EXTERNAL_START,
+ TI_DMA_v1_STRIDE_CONFIG,
Yep unless we make it generic DMA_STRIDE_CONFIG simply, this makes
a lot of sense.
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration
On Tue, Jul 12, 2011 at 12:56 PM, Raju, Sundaram sunda...@ti.com wrote: [Me] [Jassi] 3) TI may not have just one DMAC IP used in all the SoCs. So if you want vendor specific defines anyway, please atleast also add DMAC version to it. Something like DMA_SLAVE_CONFIG, FSLDMA_EXTERNAL_START, + TI_DMA_v1_STRIDE_CONFIG, Yep unless we make it generic DMA_STRIDE_CONFIG simply, this makes a lot of sense. Okay, I can add one cmd for the EDMAC in DaVinci series of SoCs and one for SDMAC in OMAP series of SoCs. Wait, that's two different silicon blocks right? Then you already have proof that this spans more than one DMAC and then you can just go for a generic DMA_STRIDE_CONFIG from day one. That both are TI does not matter, if they are totally unrelated implementations. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] dmaengine: add dma_ctrl_cmd to pass buffer stride configuration
2011/7/10 Sundaram Raju sunda...@ti.com: Added new dma_ctrl_cmd TI_DMA_STRIDE_CONFIG to pass the TI DMA controller specific configurations on how a buffer must be walked through and how data is picked for transfer based on a specified pattern over the channel. The configuration passed is specific to the TI DMA controller used. Signed-off-by: Sundaram Raju sunda...@ti.com This is exactly how I think we should do this. Acked-by: Linus Walleij linus.wall...@linaro.org Thanks, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC] dmaengine: add new api for preparing simple slave transfer
2011/7/7 Raju, Sundaram sunda...@ti.com:
| Just put some enumerator in enum dma_ctrl_cmd in
| dmaengine.h such as SDMA_TEXAS_STRIDE_CONFIG and call
| like this:
|
| /* However that config struct needs to look, basically */
| static struct sdma_ti_stride_cgf = {
| take = M,
| skip = N,
| };
|
| ret = chan-device-device_control(chan, SDMA_TEXAS_STRIDE_CONFIG,
| sdma_ti_stride_cfg);
|
| Or something like this.
I think this is better option than your 2b. This requires just an addition of
one more enum in the dma_ctrl_cmd. What do you think about this?
If Dan and you are okay with this I will send a small patch for this asap.
I think this is the best way to solve it atleast. It's clear what is
being done, and it's easy for a client trying to create such a slave
transfer to back out if it turns out that the DMAC in use does not
support this striding.
Send a patch out and I'll Ack it, FWIW.
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 08/12] gpio: add ti-ssp gpio driver
2010/11/3 David Brownell davi...@pacbell.net: That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) Incidentally the ARM PrimeCell PL022 is called SSP, Synchronous Serial Port and is not multifunction at all. Just to add to the confusion... Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 08/12] gpio: add ti-ssp gpio driver
2010/11/3 David Brownell davi...@pacbell.net:
--- On Wed, 11/3/10, Linus Walleij linus.ml.wall...@gmail.com wrote:
Incidentally the ARM PrimeCell PL022 is called SSP,
Synchronous Serial Port and is not multifunction at all.
ISTR coming across that IP module; are you sure
that it only supports a single serial protocol,
instead of just a small variety (multi)?
Unless the hardware only supports one protocol,
my point holds.
Yeah well:
/**
* enum ssp_interface - interfaces allowed for this SSP Controller
* @SSP_INTERFACE_MOTOROLA_SPI: Motorola Interface
* @SSP_INTERFACE_TI_SYNC_SERIAL: Texas Instrument Synchronous Serial
* interface
* @SSP_INTERFACE_NATIONAL_MICROWIRE: National Semiconductor Microwire
* interface
* @SSP_INTERFACE_UNIDIRECTIONAL: Unidirectional interface (STn8810
* STn8815 only)
*/
enum ssp_interface {
SSP_INTERFACE_MOTOROLA_SPI,
SSP_INTERFACE_TI_SYNC_SERIAL,
SSP_INTERFACE_NATIONAL_MICROWIRE,
SSP_INTERFACE_UNIDIRECTIONAL
};
If that is what you mean then yes. All of the protols are
SPI type though.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 01/12] misc: add driver for sequencer serial port
2010/10/26 Cyril Chemparathy cy...@ti.com: TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port device. It has a built-in programmable execution engine that can be programmed to operate as almost any serial bus (I2C, SPI, EasyScale, and others). This patch adds a driver for this controller device. The driver does not expose a user-land interface. Protocol drivers built on top of this layer are expected to remain in-kernel. Why is this thing in drivers/misc? drivers/mfd is IMHO the apropriate place for a driver like this, and the subdrivers should be migrated to use mfd cells and platform drivers for the subdevices. All functions and abstractions you create here look suspiciously lot like other MFD devices. But please, beat me up if I'm wrong! Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 01/12] misc: add driver for sequencer serial port
2010/10/28 Cyril Chemparathy cy...@ti.com: On 10/28/2010 11:49 AM, Linus Walleij wrote: Why is this thing in drivers/misc? drivers/mfd is IMHO the apropriate place for a driver like this, (...) Alan had raised the same concern earlier, and my response was: [Cyril] Unlike MFDs, this device doesn't have cells with differing functionality. Instead it has functionally identical ports that can operate in a variety of modes. That said, does this still fit in with other MFD drivers? If so, I don't see a problem with moving it there. I don't see a problem with moving this into MFD, but this won't be able to use any of the functionality provided by mfd-core. I think they do have differing functionality, though not in their essence (hardware), they do get a clearly defined role at run-time. Sam will tell, but since you have subdrivers in other subsystems MFD fits best IMHO. What about the platform data passed into the MFD driver defines what type of functionality will be assigned to each physical block, from that you create the array of MFD cells to be spawn and spawn it off. Then you have platform_driver:s in each subsystem attaching to said cells. Shouldn't be too hard. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 1/3] ARM: add CPPI 4.1 DMA support
2010/5/15 Sergei Shtylyov sshtyl...@ru.mvista.com: Add support for Texas Instuments Communication Port Programming Interface 4.1 (CPPI 4.1) used on OMAP-L1x/DA8xx and AM35x. Sorry for late feedback ... +++ linux-davinci/arch/arm/common/cppi41.c Can you migrate this driver to drivers/dma/cppi41.c and use the DMAengine interface like so many DMA drivers we have created recently, or is there some very special characteristics about this DMA controller meriting it to be placed in arch/arm/*? Note: we have the support for PL08x found in ARM reference designs queued for drivers/dma/amba-pl08x.c, not arch/arm/common/*. The rationale about this is to lower the churn in arch/arm/* and put drivers into the proper subsystems, and in this case there is an appropriate subsystem to be used. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
