Re: [PATCH 0/6] twl4030: Various fixes for charing-from-USB
On Mon, Apr 30, 2012 at 09:30:02AM +1000, NeilBrown wrote: > > > Following are a collection of patches that I've need using for a while > > > to make sure the charge-from-usb on my GTA04 works. > > > Hopefully I've included the right people in the recipient list :-) > > > > You missed the power supply maintainers - ./scripts/get_maintainer.pl > > is usually good at finding the right people, although their > > MAINTAINERS entry could be better I guess.. > > > > > > I guess you mean: > > POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS > M:Anton Vorontsov > M:David Woodhouse > T:git git://git.infradead.org/battery-2.6.git > S:Maintained > F:include/linux/power_supply.h > F:drivers/power/power_supply* > > > get_maintainer.pl didn't find them. The F: line seems to say they aren't > interested in individual drivers... This is a 'bug', of course. :-) Thanks for the report. This is what I've just applied: - - - - MAINTAINERS: Fix 'F' entry for the power supply class For some reason the maintainers file only specifies power supply core files. We're surely interested in individual drivers as well, so fix the entry. Reported-by: NeilBrown Signed-off-by: Anton Vorontsov --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index bb76fc4..3766f6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5290,7 +5290,7 @@ M:David Woodhouse T: git git://git.infradead.org/battery-2.6.git S: Maintained F: include/linux/power_supply.h -F: drivers/power/power_supply* +F: drivers/power/ PNP SUPPORT M: Adam Belay -- 1.7.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] twl4030: Various fixes for charing-from-USB
On Sat, May 05, 2012 at 03:49:10AM -0700, Anton Vorontsov wrote: > On Mon, Apr 30, 2012 at 09:30:02AM +1000, NeilBrown wrote: > > > > Following are a collection of patches that I've need using for a while > > > > to make sure the charge-from-usb on my GTA04 works. > > > > Hopefully I've included the right people in the recipient list :-) > > > > > > You missed the power supply maintainers - ./scripts/get_maintainer.pl > > > is usually good at finding the right people, although their > > > MAINTAINERS entry could be better I guess.. > > > > > > > > > > I guess you mean: > > > > POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS > > M: Anton Vorontsov > > M: David Woodhouse > > T: git git://git.infradead.org/battery-2.6.git > > S: Maintained > > F: include/linux/power_supply.h > > F: drivers/power/power_supply* > > > > > > get_maintainer.pl didn't find them. The F: line seems to say they aren't > > interested in individual drivers... > > This is a 'bug', of course. :-) Thanks for the report. > > This is what I've just applied: > > - - - - > MAINTAINERS: Fix 'F' entry for the power supply class > > For some reason the maintainers file only specifies power > supply core files. > > We're surely interested in individual drivers as well, so fix > the entry. > > Reported-by: NeilBrown Oh, Grazvydas Ignotas noticed this too. I added Reported-by: Grazvydas Ignotas as well. Just to be precise. ;-) Thanks folks, -- Anton Vorontsov Email: cbouatmai...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 5 May 2012 00:53, Arnd Bergmann wrote:
> On Friday 04 May 2012, Jassi Brar wrote:
>> I see this requires a client driver to specify a particular req_line on a
>> particular dma controller. I am not sure if this is most optimal.
>>
>> I think such client->req_line map should be provided to the dmac controller
>> driver via its dt node in some format. The dmac driver could then populate
>> a dma_chan, or similar, only for that req_line and not for the unused one
>> which otherwise could also have served the same client.
>>
>> Ideally the I2C driver should simply ask, say, a channel for TX and another
>> for RX, everything else should already be setup via dmac's dt nodes.
>
> If I understand you correctly, you think we can generalize the dma-request
> data in a way that we don't need to pass a specific dma engine phandle.
> I very much doubt this is possible, given how different the requirements
> are for each of the engines we support. You really need to pass a specific
> phandle so that we can find the code that can interpret the data in a
> meaningful way.
>
Hmm... there ought to be a way by which a client is handed a random 'token'
via its dt node and similarly the dmac informed which channel (and with what
capabilities) to allocate should it see a request coming with that token.
That way dmac and client drivers using DT could do away with the filter_fn.
Roughly speaking (I am not very well versed with DT syntax)
Client Node:-
mmc1: mmc@13002000 {
...
dma_tx = <891> //some platform-wide unique value
dma_rx = <927> //some platform-wide unique value
...
};
Say the PL330 chapter of SoC's trm specifies that "channel_id" for
MMC1_TX is 7 and MMC1_RX is 8 on second instance of PL330.
DMAC's Node:-
pdma2: pdma@1080 {
...
dma_map = <891, 7>, //Map mmc1_tx onto i/f 7
<927, 8>, //Map mmc1_rx onto i/f 8
<487, 9>, // Map other dma clients
...
};
The dma_map could also encode features like duplex, priority etc
depending on the needs of the client and capability of the dmac.
(The "channel_id" could very well be an composite value specifying
more than one parameter basically a value private to the dmac driver)
As a positive side effect, the dmac controller could populate channels only
for which some client exists on the machine.
Also the decision to map a client onto one of two or more supporting dmacs
is made here - token 927 wouldn't appear in dma_map of pdma1 even
if it also could do RX for MMC1.
The solution seems so simple that I am already cringing at the thought
of having overlooked something fundamental. Please clarify :)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpio/omap: fix incorrect initialization of omap_gpio_mod_init
I've noticed that current mainline enables _all_ possible GPIO interrupts, this patch fixes that problem. Also Grant doesn't seem to be on CC so might not be able to pick this up. On Mon, Apr 30, 2012 at 10:20 AM, Tarun Kanti DebBarma wrote: > Initialization of irqenable, irqstatus registers is the common > operation done in this function for all OMAP platforms, viz. OMAP1, > OMAP2+. The latter _gpio_rmw()'s which supposedly got introduced > wrongly to take care of OMAP2+ platforms were overwriting initially > programmed OMAP1 value breaking functionality on OMAP1. > Somehow incorrect assumption was made that each _gpio_rmw()'s were > mutually exclusive. On close observation it is found that the first > _gpio_rmw() which is supposedly done to take care of OMAP1 platform > is generic enough and takes care of OMAP2+ platform as well. > Therefore remove the latter _gpio_rmw() to irqenable as they are > redundant now. > > Writing to ctrl and debounce_en registers for OMAP2+ platforms are > modified to match the original(pre-cleanup) code where the registers > are initialized with 0. In the cleanup series since we are using > _gpio_rmw(reg, 0, 1), instead of __raw_writel(), we are just reading > and writing the same values to ctrl and debounce_en. This is not an > issue for debounce_en register because it has 0x0 as the default value. > But in the case of ctrl register the default value is 0x2 (GATINGRATIO > = 0x1) so that we end up writing 0x2 instead of intended 0 value. > Therefore changing back to __raw_writel() as this is sufficient for > this case besides simpler to understand. > > Also, change irqstatus initalization logic that avoids comparison > with bool, besides making it fit in a single line. > > Cc: sta...@vger.kernel.org > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: Santosh Shilimkar > Cc: Grant Likely > Reported-by: Janusz Krzysztofik > Signed-off-by: Tarun Kanti DebBarma > --- > v2: > Avoid irqstatus initialization sequence change. > Use __raw_writel() to update debounce_en and ctrl registers. > Update changelog to elaborate how redundant _gpio_rmw() got added. > > drivers/gpio/gpio-omap.c | 9 +++-- > 1 files changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > index 59a4af1..9b71f04 100644 > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -957,18 +957,15 @@ static void omap_gpio_mod_init(struct gpio_bank *bank) > } > > _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->irqenable_inv); > - _gpio_rmw(base, bank->regs->irqstatus, l, > - bank->regs->irqenable_inv == false); > - _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->debounce_en != > 0); > - _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->ctrl != 0); > + _gpio_rmw(base, bank->regs->irqstatus, l, !bank->regs->irqenable_inv); > if (bank->regs->debounce_en) > - _gpio_rmw(base, bank->regs->debounce_en, 0, 1); > + __raw_writel(0, base + bank->regs->debounce_en); > > /* Save OE default value (0x) in the context */ > bank->context.oe = __raw_readl(bank->base + bank->regs->direction); > /* Initialize interface clk ungated, module enabled */ > if (bank->regs->ctrl) > - _gpio_rmw(base, bank->regs->ctrl, 0, 1); > + __raw_writel(0, base + bank->regs->ctrl); > } > > static __devinit void > -- > 1.7.0.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: remove incorrect irq_chip ack field
Each irq_chip for the main interrupt controller has offsets set for irq masking registers, which added to respective base results in a pointer to appropriate hardware register. However this is not correct for INTC_CONTROL as there is only one INTC_CONTROL register. This does not cause problems because generic ack code is never called, but remove this assignment to avoid confusion. Signed-off-by: Grazvydas Ignotas --- arch/arm/mach-omap2/irq.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c index 65f0d25..c11e8a8 100644 --- a/arch/arm/mach-omap2/irq.c +++ b/arch/arm/mach-omap2/irq.c @@ -149,7 +149,6 @@ omap_alloc_gc(void __iomem *base, unsigned int irq_start, unsigned int num) ct->chip.irq_mask = irq_gc_mask_disable_reg; ct->chip.irq_unmask = irq_gc_unmask_enable_reg; - ct->regs.ack = INTC_CONTROL; ct->regs.enable = INTC_MIR_CLEAR0; ct->regs.disable = INTC_MIR_SET0; irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE, -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hello Afzal
a few comments
On Wed, 2 May 2012, Afzal Mohammed wrote:
> Add gpmc hwmod and associated interconnect data
>
> Signed-off-by: Afzal Mohammed
Did you notice the warning that this patch generates on boot?
omap_hwmod: gpmc: cannot be enabled for reset (3)
The HWMOD_NO_IDLEST hwmod flag is needed, since there is no GPMC IDLEST
bit.
...
Also, the OMAP2xxx GPMC hwmod data is missing. It can be combined
with this patch.
...
Also:
> +static struct omap_hwmod omap3xxx_gpmc_hwmod = {
> + .name = "gpmc",
> + .class = &omap3xxx_gpmc_hwmod_class,
> + .clkdm_name = "l3_init_clkdm",
> + .mpu_irqs = omap3xxx_gpmc_irqs,
> + .main_clk = "gpmc_fck",
> + .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> +};
Is there some reason why you are setting the HWMOD_INIT_NO_RESET flag
here? Seems to me that the kernel should not rely on the bootloader GPMC
configuration, but should use a configuration from the board file or DT.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/39] ARM: OMAP3: hwmod data: add gpmc
Hello Afzal, On Tue, 1 May 2012, Afzal Mohammed wrote: > Add gpmc hwmod and associated interconnect data > > Signed-off-by: Afzal Mohammed The comments from http://marc.info/?l=linux-omap&m=133626998315039&w=2 also apply to this patch. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 14/39] ARM: OMAP2xxx: hwmod data: add gpmc
Hello Afzal, On Tue, 1 May 2012, Afzal Mohammed wrote: > Add gpmc hwmod and associated interconnect data > > Signed-off-by: Afzal Mohammed The comments from http://marc.info/?l=linux-omap&m=133626998315039&w=2 also apply to this patch. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alan, On 04/20/12 14:57, Felipe Balbi wrote: > On Thu, Apr 19, 2012 at 11:01:16AM -0400, Alan Stern wrote: >> On Thu, 19 Apr 2012, Igor Grinberg wrote: >> >>> ping >>> >>> Alan, Felipe, >>> Can this go into 3.5? >> >> It's okay with me. >> >> Acked-by: Alan Stern > > Also fine from my side: > > Acked-by: Felipe Balbi > >>> The dependency patch has already reached Samuel's tree, >>> what would be the best way to apply this one? >>> Should I ask Samuel to apply this one also (after having your acks) >>> via his tree, to reduce possible merge failures/conflicts? >> >> Sure, go ahead. Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) and I'd like this to go into 3.5. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? Thanks >> >>> On 03/27/12 16:08, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata->reset_gpio_port[0])) - gpio_set_value(pdata->reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata->reset_gpio_port[0], 1); if (gpio_is_valid(pdata->reset_gpio_port[1])) - gpio_set_value(pdata->reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata->reset_gpio_port[1], 1); } return 0; >> > - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPphlAAAoJEBDE8YO64EfaejYP/0cjyLNgGzxeWJy9X5Q34C8S UIvAb6bHQrYxIqpdZ8vctPI1vnXgHvaWAdUg24Y5IWY+TPCvr6NWv5PGfMe7zAD6 YHF6T7Yakn1C9geuPMCUNR0KRdd4EEN5YSXEu+ILr/xa7Bp2IzFvtThD8rqLeLWi 8z411WT/eCpGdk2Y6WPw41AWW1YyfEaFwPz49w6siypyw032tB32zIghaYzy2C8W QtAUAbpBSw627tHRVPeVAqfQIK6plLoyCP9ql1FtaDbx/BwYlgALJv/1NrAgqtCe 8Kd6vfkEfZiUhsG2uO4cx9QwY2gKTu285mpMQe0824rWUSFd8s/JS3HdYhPxIZOb HKjcYT4T9N0ZSJyPx0SqCOvP5wLPySSc2g37PdOis7+awH2a0HGIsoZJgXTkWbR/ giLmvaOvKoTjsSsPRCUBKuU4eRPlK2k7tm4eobo/7VAJnhrD0IGAWn4vH981PE1h eM4b9TwAxC4s2xUdxe/v5e+zF0wqtBvfWjultQw9OvKskZfroPspdzhuzhrt86P6 Ecedu+moMNG00zFuoEgPZYY7h/de+8gPFp+jZfuWNDQSLwDmRpZINLcAB2VEnY8G YrTN6lmaH00Fy8EVAqOhh7wnIB192myVo6axiGKwSbus3E91YboKYoTLEjArJEF7 DE5AB9sKxnZQpzihpwAt =OFXi -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
