Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

2012-06-14 Thread Jon Hunter
On 06/14/2012 10:17 AM, Guennadi Liakhovetski wrote: > Hi all > > Sorry for jumping in so late in the game. But I think, the model, to which > this discussion is slowly converging, is not very well suitable for the > shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and > the

Re: [PATCHv2 08/12] ARM: OMAP4: hwmod data: add SL2IF hardreset line

2012-06-14 Thread Paul Walmsley
On Thu, 14 Jun 2012, Cousson, Benoit wrote: > Yep, but for that I'd rather add a flag than a information that is a > duplication of the parent data. Great, send a patch. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.ke

Re: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver

2012-06-14 Thread Stephen Warren
On 06/11/2012 07:58 AM, Tony Lindgren wrote: > Add one-register-per-pin type device tree based pinctrl driver. > > Currently this driver only works on omap2+ series of processors, > where there is either an 8 or 16-bit padconf register for each pin. > Support for other similar pinmux controllers c

Re: [PATCHv2 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer

2012-06-14 Thread Paul Walmsley
On Thu, 14 Jun 2012, Cousson, Benoit wrote: > On 6/14/2012 8:04 PM, Paul Walmsley wrote: > > On Thu, 14 Jun 2012, Cousson, Benoit wrote: (attribution lost) > > > > Furthermore, the PRCM will never request target idle for this IP block > > > > while the kernel is running, due to the sleep depende

Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

2012-06-14 Thread Paul Walmsley
On Thu, 14 Jun 2012, Jon Hunter wrote: > What does make this a bit more difficult is the function > gpmc_round_ns_to_ticks(). It appears to convert nanoseconds to ticks and > back to nanoseconds. I am guessing to account for some rounding error. I > am curious what impact this function is having o

Re: Please help! AM35xx mm/slab.c BUG

2012-06-14 Thread CF Adad
Hi Jean-Philippe, Thanks for the notes. I agree whole-heartedly with the idea that we're having a hardware issue. I'm just trying to eliminate any other software-related issues if I can. Since I'm really just a software engineer, I have to leave the hardware work to the hardware folks. All I ca

Re: [PATCH 04/29] ARM: omap: clk: use clk_prepare_enable and clk_disable_unprepare

2012-06-14 Thread Rajendra Nayak
On Friday 15 June 2012 12:41 AM, Mike Turquette wrote: On 20120614-18:16, Rajendra Nayak wrote: As we move to Common clk framework use clk_prepare_enable() instead of clk_enable() and similarly clk_disable_unprepare() instead of clk_disable() Based on initial changes from Mike turquette

RE: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

2012-06-14 Thread Mohammed, Afzal
Hi Tony, On Thu, Jun 14, 2012 at 22:23:37, Tony Lindgren wrote: > Sounds like the tusb6010 non-ns tick value is the only remaining > issue. t.clk_activation = gpmc_ticks_to_ns(1); was used so that gpmc_cs_set_timings would do gpmc_ns_to_ticks over it & hence effectively 1 tick would get progra

RE: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

2012-06-14 Thread Mohammed, Afzal
Hi Tony, On Fri, Jun 15, 2012 at 11:12:46, Mohammed, Afzal wrote: > But I am unable to find reason for failure upon using > gpmc_ticks_to_ns(1), which seems to me right thing to be used. > Let me try to invoke tusb6010 functions in beagle board, > observe timings so that at least I will get an id

RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

2012-06-14 Thread Mohammed, Afzal
Hi Jon, On Thu, Jun 14, 2012 at 23:23:48, Hunter, Jon wrote: > On 06/14/2012 12:40 AM, Mohammed, Afzal wrote: > > During gpmc driver probe, it will configure all the connected peripherals, > > if configuration details are not present at that point of time, gpmc driver > > will cry out saying that

<    1   2   3