On Tue, Oct 16, 2012 at 12:01:06PM +0100, Russell King wrote:
> The MCR TCRTLR bit can only be changed when ECB is set in the EFR.
> Unfortunately, several places were trying to alter this bit while ECB
> was clear:
>
> - serial_omap_configure_xonxoff() was attempting to clear the bit after
> ex
Hi,
During the merge window, a series of patches from various people went in,
allegedly fixing various problems with the OMAP serial driver.
Unfortunately, there was not a full understanding of the issues I brought
up here back in April, and so the "fixes", while being individually
correct, resul
On Sat, Oct 13, 2012 at 11:50:45AM +0100, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Sat, Oct 13, 2012 at 04:46:18AM +, Paul Walmsley wrote:
> >>
> >> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
> >>
On Sat, Oct 13, 2012 at 04:46:18AM +, Paul Walmsley wrote:
>
> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
> started crashing during boot with omap2plus_defconfig:
>
> [3.875122] mmcblk0: mmc
On Fri, Oct 12, 2012 at 10:59:22AM -0700, Kevin Hilman wrote:
> Russell King - ARM Linux writes:
>
> > On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
> >> Sourav writes:
> >> > diff --git a/drivers/tty/serial/omap-serial.c
> >> > b/
On Fri, Oct 12, 2012 at 05:29:55PM +, Poddar, Sourav wrote:
> Hi Russell,
>
> From: Russell King - ARM Linux [li...@arm.linux.org.uk]
> Sent: Friday, October 12, 2012 10:12 PM
> To: Kevin Hilman
> Cc: Poddar, Sourav; Paul Walmsley;
On Fri, Oct 12, 2012 at 09:35:54AM -0700, Kevin Hilman wrote:
> Sourav writes:
> > diff --git a/drivers/tty/serial/omap-serial.c
> > b/drivers/tty/serial/omap-serial.c
> > index 6ede6fd..3fbc7f7 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -14
On Fri, Oct 12, 2012 at 09:24:52AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [121012 08:56]:
> > As of today, I've rebased my serial changes as far forward as I dare at
> > the moment (to the commit before removal of DMA), and then merged it
> > into th
For those who don't bother looking at my kautobuild boot tests on the OMAP
boards I have, here's the errors which get spat out at boot time. Note
that some of these I've reported in the past, and one of them is missing
a newline character at the end of its string.
twd: can't register interrupt 45
On Fri, Oct 12, 2012 at 12:58:13PM +0200, Daniel Mack wrote:
> The .direction field of the config passed to dmaengine_slave_config()
> must be set in order to make the generic code store the configured bus
> width.
NAK. The direction field is deprecated, and should not be used anymore.
--
To unsu
On Thu, Oct 11, 2012 at 03:51:00PM +0530, Sourav wrote:
> True. I missed that point while doing the testing. Sorry for that.
> I further looked into it and saw some two options in my minicom
> settings(Hardware Flow Control/ Software Flow Control) Which I am
> thinking are the ones used to ena
On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote:
>
> Hi Kevin,
> On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote:
>> Hi Sourav,
>>
>> Sourav writes:
>>
>> [...]
>>
>>> Boot Tested this patch series against v3.6 tag(applied cleanly) on
>>> panda board and
>>> PM tested(hitting off
On Sun, Oct 07, 2012 at 04:00:37PM +0800, Axel Lin wrote:
> config OMAP_DEBUG_LEDS
> - def_bool y if NEW_LEDS
> + default y if LEDS_CLASS
> depends on OMAP_DEBUG_DEVICES
This change is wrong. You're making this config entry untyped.
--
To unsubscribe from this list: send the line "
On Sat, Oct 06, 2012 at 04:49:56PM +0100, Alan Cox wrote:
> On Sat, 06 Oct 2012 13:45:47 +0100
> Russell King wrote:
>
> > This allows drivers (such as OMAP serial) to allocate and free their
> > transmit buffers in a sane manner, rather than working around the
> > buffer allocation provided by s
On Sat, Oct 06, 2012 at 11:32:16AM -0400, Nicolas Pitre wrote:
> On Sat, 6 Oct 2012, Tony Lindgren wrote:
> > * Marc Zyngier [121006 03:19]:
> >
> > > If so, that indicates some side effect of the safe_svcmode_maskall macro,
> > > and I suspect the "movs pc, lr" bit.
> > >
> > > Can you try the
Another issue:
serial_omap_set_termios()
{
...
/* FIFOs and DMA Settings */
/* FCR can be changed only when the
* baud clock is not running
* DLL_REG and DLH_REG set to 0.
*/
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_ou
Another potential bug - in serial_omap_set_termios() there is this:
if (up->use_dma) {
serial_out(up, UART_TI752_TLR, 0);
up->scr |= UART_FCR_TRIGGER_4;
} else {
/* Set receive FIFO threshold to 1 byte */
up->fcr &= ~O
On Sat, Oct 06, 2012 at 01:38:03PM +0100, Russell King - ARM Linux wrote:
> Hi,
>
> This series of patches fixes multiple flow control issues with the OMAP
> serial driver, and prepares the driver for DMA engine conversion. We
> require hardware assisted flow control to work p
Hi,
This series of patches fixes multiple flow control issues with the OMAP
serial driver, and prepares the driver for DMA engine conversion. We
require hardware assisted flow control to work properly for DMA support
otherwise we have no way to properly pause the transmitter.
This is generated a
On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
> Just bisected this down in linux-next for breaking booting of
> my omap2420 ARMv6 based n8x0..
>
> > --- a/arch/arm/kernel/head.S
> > +++ b/arch/arm/kernel/head.S
> > @@ -83,8 +83,12 @@ ENTRY(stext)
> > THUMB(.thumb
On Fri, Sep 28, 2012 at 07:10:08PM +0530, Lokesh Vutla wrote:
> omap_reserve() is a stub for omap1. So creating a
> stub locally in mach-omap1. And moving the definition
> to mach-omap2.
> This helps in moving plat/omap_secure.h local to
> mach-omap2
>
> Signed-off-by: Lokesh Vutla
> Acked-by : S
On Fri, Sep 28, 2012 at 08:05:38AM -0700, Tony Lindgren wrote:
> * Shilimkar, Santosh [120928 08:02]:
> > On Fri, Sep 28, 2012 at 8:25 PM, Tony Lindgren wrote:
> > >
> > > * Lokesh Vutla [120928 06:41]:
> > > > Move plat/dma.h header to platform_data/dma-omap.h as
> > > > part of the single zIma
On Thu, Sep 27, 2012 at 07:34:07PM +0530, Kishon Vijay Abraham I wrote:
> +static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
> +{
> + u32 val;
> + unsigned long rate;
> + struct clk *sys_clk;
> +
> + sys_clk = clk_get(NULL, "sys_clkin");
> + if (IS_ERR(sys_clk)) {
>
On Tue, Sep 25, 2012 at 02:12:43PM +0300, Felipe Balbi wrote:
> I don't see any aggressive attitude towards what you suggested,
> actually. Mailing list archives are available to check, but the one
> cursing around was always yourself and THAT deserves an apology.
Total rubbish. No apology, becau
On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
> that's most likely, of course. But should we cause a regression to
> beagleboard XM because of that ? Also, if you look into chapter 9 of the
> runtime_pm documentation, starting on line 822 you'll see documentation
> suggests the use
On Tue, Sep 25, 2012 at 01:37:03PM +0300, Felipe Balbi wrote:
> On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote:
> > Because you are accusing me of potentially breaking your beagleboard
> > for merely suggesting further investigation and a better commit mess
Right, let's get this thread back onto a constructive footing and try
to understand the problems here.
On Tue, Sep 25, 2012 at 03:26:06PM +0530, Poddar, Sourav wrote:
> The issue was observed at serial init itself in the N800 board and the
> log does not show up much.
> http://www.pwsan.com/omap/t
On Tue, Sep 25, 2012 at 12:48:16PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
> > > On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russel
On Tue, Sep 25, 2012 at 12:32:37PM +0300, Tero Kristo wrote:
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index ba49029..ca54aec 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -1475,10 +1477,16 @@ int pwrd
On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
> On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
> > > On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wro
On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
> On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
> > How is this happening? I think that needs proper investigation - or if
> > it's had more investigation, then the results needs to be
On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote:
> From: Yegor Yefremov
>
> FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
> of consistent DMA memory (da8xx frame buffer driver).
Okay, so the patch description says "This needs to be 12 on this platform
On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote:
> Hi Greg,
>
> Ping on this?
>
> On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar wrote:
> > Greg's tty-next is not booting on 2420 based N800. The failure is
> > observed at serial init itself. The reason might be that n800 tries to
On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote:
> How should I change the patch to make it proper? SA is broken anyway:
No it isn't. This is what it produces _today_, and has done for the last
5-10 years without modification
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP i
On Mon, Sep 24, 2012 at 09:05:11PM +0200, Yegor Yefremov wrote:
> On Mon, Sep 24, 2012 at 7:18 PM, Tony Lindgren wrote:
> > * yegorsli...@googlemail.com [120703 07:26]:
> >> From: Yegor Yefremov
> >>
> >> FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
> >> of consistent DMA memo
On Fri, Sep 21, 2012 at 02:34:46PM -0400, Matt Porter wrote:
> On Fri, Sep 21, 2012 at 10:42:05AM +0100, Russell King wrote:
> > Here's the pertinant question: "is it platform data?" Looking at the
> > file, it appears to be internal data structures and register definitions
> > for the driver itse
On Fri, Sep 21, 2012 at 10:45:29PM +0530, S, Venkatraman wrote:
> On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter wrote:
> > The EDMA DMAC has a hardware limitation that prevents supporting
> > scatter gather lists with any number of segments. Since the EDMA
> > DMA Engine driver sets the maximum seg
On Fri, Sep 21, 2012 at 09:33:42AM +, Hebbar, Gururaja wrote:
> On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote:
> > On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> > > Move mach-davinci/dma.c to common/edma.c so it can be used
> > > b
On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx atm) as well. This just moves
> the private EDMA API but does not support OMAP.
>
> Signed-off-by: Matt Porter
> ---
> arch/arm/Kconfig
On Wed, Sep 19, 2012 at 06:19:06AM +0800, Mitch Bradley wrote:
> Is there ever a point when old architectures leave the Linux tree, or
> will people have to see grep hits from them until the end of time?
That depends on use and the burden of keeping them in the tree. I'm
not aware of much activit
On Tue, Sep 18, 2012 at 03:20:08PM +, Arnd Bergmann wrote:
> On Tuesday 18 September 2012, Matt Porter wrote:
> > FWIW, I'm already basing the EDMA dmaengine support for OMAP (specifically
> > for AM335x) on using these helpers since AM335x only boots from DT.
>
> I suspect the same thing will
This feature can be used during audio operation to disable all audio
> > related interrupts.
> >
> > Signed-off-by: Peter Ujfalusi
> > CC: Nicolas Ferre
> > CC: Barry Song
> > CC: Srinidhi Kasagar
> > CC: Russell King - ARM Linux
> > CC: Vista S
On Mon, Sep 17, 2012 at 08:43:57AM +0530, Vinod Koul wrote:
> On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote:
> > - /* FIXME: not supported by platform private API */
> > - return -EINVAL;
> > + /* Pause/Resume only allowed with cyclic mode */
> > + if (!c->cyclic)
On Mon, Sep 17, 2012 at 11:59:27AM +, Arnd Bergmann wrote:
> On Monday 17 September 2012, Vinod Koul wrote:
> > On Fri, 2012-09-14 at 17:41 -0500, Jon Hunter wrote:
> > > +/**
> > > + * dma_request_slave_channel - try to allocate an exclusive slave
> > > channel
> > > + * @dev: pointer to
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
> 3. Supporting legacy devices not using DMA Engine
>
>These devices present a problem, as there may not be a uniform way to
> easily
>support them with regard to device tree. Ideally, these should be migrated
>to DMA engine.
On Fri, Sep 14, 2012 at 12:28:28PM +0300, Peter Ujfalusi wrote:
> I'm not sure about which flags should ASoC set for the two case we are going
> to have. I think it should be something like this:
>
> unsigned long flags = DMA_CTRL_ACK;
>
> if (!substream->runtime->no_period_wakeup)
> flags
On Thu, Sep 13, 2012 at 05:27:09PM +0200, Lars-Peter Clausen wrote:
> Hm... Do you think it would work as well if we implement this by setting the
> callback for the descriptor to NULL? If the callback is NULL there is
> nothing to at the end of a transfer/period and the dma engine driver may
> cho
On Thu, Sep 13, 2012 at 06:31:35PM +0530, Shilimkar, Santosh wrote:
> In the series, there is patch "[PATCH 3/6]" which adds an
> API which let you operate on a specific level.
Which is introduced but as far as I can see, is never used in the patch
set. Therefore, it shouldn't be introduced.
We'
On Thu, Sep 13, 2012 at 12:39:49PM +0100, Dave Martin wrote:
> We could introduce something like CONFIG_ARM_HAVE_CACHEFLUSH_LOUIS, and
> do:
>
>
> #ifndef MULTI_CACHE
> #ifdef CONFIG_HAVE_ARM_CACHEFLUSH_LOUIS
> #define __cpuc_flush_kern_cache_louis __glue(_CACHE,_flush_kern_cache_louis)
> #else
>
On Thu, Sep 13, 2012 at 11:20:46AM +0100, Lorenzo Pieralisi wrote:
> +/*
> + * Flush caches up to Level of Unification Inner Shareable
> + */
> +#ifdef MULTI_CACHE
> +#define flush_cache_louis() cpu_cache.flush_kern_cache_louis()
> +#else
> +#define flush_cache_louis() __cpuc_flush_kern_all()
>
On Wed, Sep 12, 2012 at 11:44:29AM -0700, Stephen Boyd wrote:
> On 09/12/12 05:05, Russell King - ARM Linux wrote:
> > NAK. Using a different function which doesn't have the warning isn't a
> > subsitute for fixing the problem properly. What you're doing is paperin
On Wed, Sep 12, 2012 at 08:49:16PM +0530, Gupta, Ramesh wrote:
> Thanks to the RMK's suggestions.
I should've made clear the distinction between _range and _area.
A _range function takes start and end. An _area function takes a start
and size. So...
> -static void flush_iopgd_range(u32 *first,
On Wed, Sep 12, 2012 at 06:50:00PM +0530, R, Sricharan wrote:
> Hi,
> On Wed, Sep 12, 2012 at 6:27 PM, Shilimkar, Santosh
> wrote:
> > On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy wrote:
> >>
> >> On 9/12/2012 1:50 AM, R Sricharan wrote:
> >>>
> >>> Even if CONFIG_DMA_ADDR_64BIT_T is enable
On Wed, Sep 12, 2012 at 02:50:10PM +0300, Roger Quadros wrote:
> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>
> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
> [ 28.832946] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/1763
> [ 28.
On Wed, Sep 12, 2012 at 02:47:07PM +0300, Peter Ujfalusi wrote:
> 2. Pause/Resume
>OMAP DMA engine backend does not support pausing and resuming
>an in-progress transfer. It is unclear from the specs what
>effect clearing the enable bit has on the DMA position of a
>destination syn
On Thu, Jul 05, 2012 at 10:50:24AM +0530, Gupta, Ramesh wrote:
> static void flush_iopgd_range(u32 *first, u32 *last)
> {
> - /* FIXME: L2 cache should be taken care of if it exists */
> - do {
> - asm("mcrp15, 0, %0, c7, c10, 1 @ flush_pgd"
> - : : "r"
On Thu, Jul 05, 2012 at 10:50:17AM +0530, Gupta, Ramesh wrote:
> + * flush_iommu_mem(start, end)
> + *
> + * Clean and invalidate the specified virtual address range.
> + * This is to support the non coherent iommu drivers.
> + * The iommu driver need to call this ap
On Mon, Jul 30, 2012 at 05:44:44PM +0100, Russell King - ARM Linux wrote:
> Okay, so last night's build run shows some new warnings...
>
> drivers/regulator/twl-regulator.c: In function 'twlreg_probe':
> drivers/regulator/twl-regulator.c:1151: warning: assignment
On Tue, Sep 04, 2012 at 04:26:28PM +0300, Peter Ujfalusi wrote:
> Hi Takashi,
>
> On 09/04/2012 04:14 PM, Takashi Iwai wrote:
> >> Ok, it might have been helpful in the conversion process, but for the final
> >> patch it would be nice if you could replace
> >>
> >> struct snd_pcm_runtime *runtime
On Mon, Sep 03, 2012 at 10:25:49PM +0200, Lars-Peter Clausen wrote:
> On 09/03/2012 06:59 PM, Liam Girdwood wrote:
> > Use a dedicated member to store dmaengine data so that drivers can
> > use private data for their own purposes.
> >
>
> The idea was that we'll eventually get to a point where we
The following series of three patches is an attempt to convert the OMAP
ASoC backend to use the DMA engine support.
I'll bring your attention to the comments in patch 3 which highlight
some of the features lost in this process. Some questions need
answering there (in particular the one concerning
On Mon, Sep 03, 2012 at 06:13:33PM +0800, Wei Yongjun wrote:
> @@ -130,6 +132,7 @@ static int __init omap2_gpio_dev_init(struct omap_hwmod
> *oh, void *unused)
>
> pdev = omap_device_build(name, id - 1, oh, pdata,
> sizeof(*pdata), NULL, 0, false);
> + kfr
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote:
> Hi Russell & Tony,
>
> AM335X EVM (based on AM33XX device) only supports DT boot mode and
> doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during
> baseport submission we had aligned that, we won't create separa
On Wed, Aug 29, 2012 at 02:26:15PM +0530, Rajendra Nayak wrote:
> Moving to Common clk framework for OMAP would mean we no longer use
> internal lookup mechanism like omap_clk_get_by_name().
> get rid of all its usage mostly from hwmod and omap_device
> code.
>
> Also use IS_ERR_OR_NULL() for erro
On Fri, Aug 24, 2012 at 02:10:38PM +0200, Peter Meerwald wrote:
> with Linux 3.6-rc3:
>
> CONFIG_DMA_OMAP=m
> CONFIG_DMA_ENGINE=y
> CONFIG_DMA_VIRTUAL_CHANNELS=m
> CONFIG_MMC_OMAP_HS=y
> CONFIG_SPI_OMAP24XX=y
> CONFIG_MTD_NAND_OMAP2=y
>
> LD init/built-in.o
> drivers/built-in.o: In functio
On Fri, Aug 24, 2012 at 03:51:26PM +0530, Shilimkar, Santosh wrote:
> On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux
> wrote:
> >
> > On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote:
> > > the commit just sets CONFIG_DMA_OMAP=y
On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote:
> the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in
> omap2plus_defconfig; this does not help people updating the kernel while
> keeping the config, nor does it help people in configuring the kernel
>
> there is a de
On Mon, Aug 13, 2012 at 05:22:40PM +0300, Peter Ujfalusi wrote:
> + fck_src = clk_get(mcbsp->dev, src);
> + if (IS_ERR_OR_NULL(fck_src)) {
I know the same error is in the original code, but let's stop propagating
it. IS_ERR() only here please.
--
To unsubscribe from this list: send the li
Found this with the cubox, which wants to obtain large blocks of
RAM for the GPU and VPU devices at boot time. I don't believe
any other platforms care where the memory comes from, so I think
this is safe.
However, OMAP and iMX folk should check this patch - thanks.
8<===
From: Russell King
Sub
On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote:
> Other issue i found, using this patch, that on multi-core ARM systems,
> almost 99% of times, IRQ's are handled by CPU0,
> even if CPU0 was really busy and other CPU's were free. I am yet to
> understand a good reason why.
That is
On Thu, Aug 02, 2012 at 01:04:37PM +, Hiremath, Vaibhav wrote:
> On Wed, Aug 01, 2012 at 19:44:14, Russell King - ARM Linux wrote:
> > On Wed, Aug 01, 2012 at 05:50:16PM +0530, Vaibhav Hiremath wrote:
> > > The clk_get() api will not work, unless we pass both the arguments
On Thu, Aug 02, 2012 at 12:55:42PM +, Hiremath, Vaibhav wrote:
> On Wed, Aug 01, 2012 at 19:12:59, Cousson, Benoit wrote:
> > Mmm, I don't know, but even if this is right, shouldn't we avoid such
> > usage. It might be better to be explicit than assuming that the IP will
> > always have an uniq
On Wed, Aug 01, 2012 at 05:50:16PM +0530, Vaibhav Hiremath wrote:
> The clk_get() api will not work, unless we pass both the arguments (dev,
> con_id) properly. Now expecting driver to always label con_id with "fck"
> is undesirable, as the same driver can be reused on multiple platforms,
> which c
On Tue, Jul 31, 2012 at 01:21:24AM -0700, Saravana Kannan wrote:
> I have heard this idea about removing the clk_prepare/unprepare API too
> many times and it makes me uncomfortable. I would really prefer we (the
> community) take this discussion to the end and put an end to it. We
> either a
On Mon, Jul 30, 2012 at 05:31:23PM -0700, Turquette, Mike wrote:
> On Mon, Jul 30, 2012 at 4:02 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote:
> >> On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley wrote:
> >>
On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote:
> On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley wrote:
> > So if we make a change like this one, it seems like we would basically
> > expect it to break once we start doing anything meaningful with
> > clk_prepare(), like using clk_
On Mon, Jul 30, 2012 at 06:40:43PM +0100, Mark Brown wrote:
> On Mon, Jul 30, 2012 at 05:44:44PM +0100, Russell King - ARM Linux wrote:
>
> > -#define TWLRES_OF_MATCH(comp, label) TWL_OF_MATCH(comp, TWLRES, label)
> > - TWLRES_OF_MATCH("ti,twl6030-clk32kg", CLK
Okay, so last night's build run shows some new warnings...
drivers/regulator/twl-regulator.c: In function 'twlreg_probe':
drivers/regulator/twl-regulator.c:1151: warning: assignment discards qualifiers
from pointer target type
drivers/regulator/twl-regulator.c:1160: warning: assignment discards q
On Mon, Jul 30, 2012 at 05:19:06PM +0200, Javier Martinez Canillas wrote:
> On Mon, Jul 30, 2012 at 4:46 PM, S, Venkatraman wrote:
> > On Mon, Jul 30, 2012 at 8:14 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh
On Mon, Jul 30, 2012 at 09:40:27AM +0200, Shilimkar, Santosh wrote:
> IMHO, we should merge the OMAP DMA engine support which is now sufficiently
> tested and has been in linux-next for some time. Polling mode and ASOC
> related issues can be then debugged directly on mainline.
> For the time being
On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh wrote:
> On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
> wrote:
> > So I take that as you wanting exactly what is in linux-next merged without
> > any further changes?
>
> Just one patch[1] on top
On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
> Yes, I forgot it, sorry for that.
>
> Please let me know if I need to resubmit the patch cc'ing stable.
I can just add it to the commit.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
On Mon, Jul 30, 2012 at 09:40:27AM +0200, Shilimkar, Santosh wrote:
> On Mon, Jul 30, 2012 at 7:51 AM, S, Venkatraman wrote:
> > On Sat, Jul 28, 2012 at 1:40 PM, Shilimkar, Santosh
> > wrote:
> >> On Fri, Jul 27, 2012 at 6:50 PM, Russell King - ARM Linux
> >>
On Sat, Jul 28, 2012 at 04:26:28PM +0200, Javier Martinez Canillas wrote:
> On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon wrote:
> > Acked-by: Will Deacon
> >
> > The next question is: who's putting this into the patch system?
> >
> > Will
>
> Hi,
>
> I just put the patch with Will's Acked-by on
On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> > We support booting a kernel on systems with or without SMP support, even
> > with a SMP kernel. When the kernel is booted on such
On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
> > Hi Javier,
> >
> > On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> > > On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Lin
On Fri, Jul 27, 2012 at 06:08:13PM +0200, Shilimkar, Santosh wrote:
> On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
> wrote:
> > On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
> >> Just a quick reminder that I'm still on holida
On Fri, Jul 27, 2012 at 10:20:32AM -0500, Jon Hunter wrote:
> Hi Russell,
>
> On 07/27/2012 08:42 AM, Russell King - ARM Linux wrote:
> > On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
> >> Just a quick reminder that I'm still on hol
On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
> Just a quick reminder that I'm still on holiday, and at this point there
> are over 2500 messages from the mailing lists which are sitting unread
> since I left the UK. As I mentioned before I left th
On Fri, Jul 06, 2012 at 05:43:38PM +0200, Guennadi Liakhovetski wrote:
> Hi Arnd
>
> On Fri, 6 Jul 2012, Arnd Bergmann wrote:
> > How would the individual driver know the size of the filter_arg?
>
> In exactly the same way as most dmaengine drivers do it today: they don't
> touch filter_arg unti
On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
> I like this idea, but why don't we extend it to also cover the non-DT
> case? I.e., why don't we add the above callback (call it "match" or
> "filter" or anything else) to dmaengine operations and inside (the
> extended) dm
On Wed, Jul 04, 2012 at 11:47:35AM +, N, Mugunthan V wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Wednesday, July 04, 2012 3:12 PM
> > To: N, Mugunthan V
> > Cc: linux-omap@
On Wed, Jul 04, 2012 at 03:24:33PM +0530, Santosh Shilimkar wrote:
> ARM arch timers stop in low power state and hence can not wakeup CPUs in
> deeper idle states when used as cloc event devices. Marking these clock event
> devices with C3_STOP so that during lowpower states, the tick is managed by
On Thu, Jun 07, 2012 at 04:22:17PM +, N, Mugunthan V wrote:
> While converting platform device registry to Hwmod for CPSW Ethernet
> driver which is present in AM335X (OMAP2+), I am not finding a way
> to specify dma_mask and coherent_dma_mask.
> Is there a way to specify dma_mask and coherent_
On Mon, Jul 02, 2012 at 11:52:27AM +0300, Ohad Ben-Cohen wrote:
> Simplify the unregister/free interfaces, and make them easier
> to understand and use, by moving to a symmetric and consistent
> alloc() -> register() -> unregister() -> free() flow.
The naming in the driver model is:
alloc() -> ad
On Thu, Jun 28, 2012 at 10:06:23AM +0300, Pantelis Antoniou wrote:
> Err,
>
> There was a patch been sent in response that did exactly as you asked.
>
> http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/00433.html
>
> Regards
Obviously it was missed, and no one bothered to re-send it. Yes,
On Mon, Jun 25, 2012 at 10:08:13PM +0530, Vinod Koul wrote:
> Hi Russell,
>
> What is the status of the virtual dma and the series you have posted
> previously. Is it ready for merge?
>
> I would be away for 10days starting coming Thursday. So please let me
> know
I have no idea.
I've just reba
On Mon, Jun 25, 2012 at 09:07:58AM +0300, Tomi Valkeinen wrote:
> On Fri, 2012-06-22 at 19:18 +0530, Rajendra Nayak wrote:
> > In preparation of OMAP moving to Common Clk Framework(CCF) add clk_prepare()
> > and clk_unprepare() for the omapdss clocks.
>
> You used clk_prepare and clk_unprepare ins
On Fri, Jun 22, 2012 at 05:11:56PM +0100, Mark Brown wrote:
> On Fri, Jun 22, 2012 at 02:17:51PM +0100, Russell King - ARM Linux wrote:
>
> > I suspect the key difference is I run the uImage kernels on the SDP4430
> > without a DT blob. I suspect it's the DT conve
On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> It seems the same patch has been there for a while.
>
> http://thread.gmane.org/gmane.linux.kernel/1303115
Bah, why doesn't stuff like this get resent if nothing has happened for
a while?
--
To unsubscribe from this list: send the line
501 - 600 of 2180 matches
Mail list logo
