On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart
wrote:
> On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote:
>> Where do you take care of those potential offsets today ? Or do you
>> simply ignore the offsets and map the entire page ?
>
> Here http://marc.info/?l=linux-omap&m=130693502326513&w
On Wed, 08 Jun 2011 11:32:47 -0700
Kevin Hilman wrote:
> > I traced breakage to commit 638080c ("OMAP2+ / PM: move runtime
> > PM implementation to use device power domains").
> >
> > Reventing that and and 2064af9 ("PM: Revert "driver core: platform_bus:
> > allow runtime override of dev_pm_ops"
Hi Kevin,
On Thu, Jun 9, 2011 at 7:50 AM, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> [...]
>
>> you need to separate the system suspend handling from runtime PM.
>
> /me risks getting yelled at again and jumps back in ;)
=)
>> Each of them requires a different approach, because the
On Thu, Jun 9, 2011 at 2:09 AM, Jon Hunter wrote:
> Hi Govindraj,
>
> On 6/8/2011 6:23 AM, Govindraj.R wrote:
>
> [snip]
>
>> +
>> +#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is msecs */
>
> [snip]
>
>> @@ -1295,18 +1381,36 @@ static int serial_omap_probe(struct
>> platform_device *pde
On 08.06.2011 23:57, Igor Grinberg wrote:
> On 06/07/11 14:15, Alexander Holler wrote:
>
>> Am 07.06.2011 11:50, schrieb Igor Grinberg:
>>> On 06/07/11 11:01, Alexander Holler wrote:
>>>
Am 31.05.2011 12:29, schrieb Tony Lindgren:
> * Alexander Holler [110405 06:38]:
>> Without msec
"Rafael J. Wysocki" writes:
[...]
> you need to separate the system suspend handling from runtime PM.
/me risks getting yelled at again and jumps back in ;)
> Each of them requires a different approach, because the goal is really
> different in both cases (basically, runtime PM triggers when t
On Thu 09 Jun 2011 at 00:13:30 Russell King - ARM Linux wrote:
>
> I stand by my answer to your patches quoted above from a technical
> point of view; we should not be mapping SDRAM using device mappings.
>
> That ioremap() inside dma_declare_coherent_memory() needs to die,
Then how about your a
On Wed, Jun 08 2011, Ohad Ben-Cohen wrote:
> This should ease finding similarities with different platforms,
> with the intention of solving problems once in a generic framework
> which everyone can use.
>
> Compile-tested for MSM8X60.
>
> Signed-off-by: Ohad Ben-Cohen
> ---
> arch/arm/mach-msm/
On Wed, Jun 08 2011, Roedel, Joerg wrote:
> Great, thanks. I'll apply the patches as soon as the relevant ACKs come
> in. Looking at the MAINTAINERS file David Brown needs to ACK the MSM
> patch and David Woodhouse the VT-d patch.
>
> David B., David W., is this direction ok for both of you?
I th
On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
> On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
> > Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
> > > On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
> > > > void __init oma
On 06/07/11 14:15, Alexander Holler wrote:
> Am 07.06.2011 11:50, schrieb Igor Grinberg:
>> On 06/07/11 11:01, Alexander Holler wrote:
>>
>>> Am 31.05.2011 12:29, schrieb Tony Lindgren:
* Alexander Holler [110405 06:38]:
> Without msecure beeing high it isn't possible to set (or start)
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
> Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
> > On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
> > > void __init omap1_camera_init(void *info)
> > > {
> > >
> > > struct platform_device *
"Menon, Nishanth" writes:
> On Wed, Jun 8, 2011 at 13:51, Kevin Hilman wrote:
> [..]
>>> the issue is as follows:
>>> currently we dont do voltage transitions. when we do that
>>> eventually(and my current code has an forked implementation of dvfs,
>>> the following steps happen):
>>> late_initc
On 6/8/2011 9:55 AM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote:
On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
The issue is that there is only one modulemode for the whole DSS.
Potentially only the d
Hi Govindraj,
On 6/8/2011 6:23 AM, Govindraj.R wrote:
[snip]
+
+#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is msecs */
[snip]
@@ -1295,18 +1381,36 @@ static int serial_omap_probe(struct platform_device
*pdev)
up->uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
Thanks!
On Wed, Jun 8, 2011 at 4:08 PM, Herbert Xu wrote:
> On Thu, Jun 02, 2011 at 09:10:02PM +0300, Dmitry Kasatkin wrote:
>> Hi,
>>
>> Recently we got crashes few times after some other patches to 2.6.32 kernel.
>> This patch set greatly prevents race condition situations.
>> No crashes are no
On Wed, Jun 8, 2011 at 8:47 PM, Chris Wright wrote:
> You may want to further restrict to x86 and ia64
> And I think you'll need to fixup arch/ia64/Kconfig
>
> BTW, I think EXPERIMENTAL can be dropped by now.
Sounds all good, thanks a lot !
--
To unsubscribe from this list: send the line "unsubsc
On Wed, Jun 8, 2011 at 13:51, Kevin Hilman wrote:
[..]
>> the issue is as follows:
>> currently we dont do voltage transitions. when we do that
>> eventually(and my current code has an forked implementation of dvfs,
>> the following steps happen):
>> late_initcall(omap2_common_pm_late_init);
>> do
"Menon, Nishanth" writes:
> On Tue, Jun 7, 2011 at 16:49, Kevin Hilman wrote:
>> Nishanth Menon writes:
>>
>>> Since we do module_init, cpufreq initializes before power late_init
>>> where many of the required data structures are registered.
>>
>> What exactly are the dependencies here? The on
Jarkko Nikula writes:
> While debugging another issue I noticed that McBSP2 clock on Nokia N900
> doesn't get disabled in 3.0-rc2 after calling
> pm_runtime_put_sync(mcbsp->dev) and the fclk usecount remains active if
> the pm_runtime_get_sync(mcbsp->dev) was ever called activating it.
>
> I beli
* Ohad Ben-Cohen (o...@wizery.com) wrote:
> +
> +config DMAR
> + bool "Support for DMA Remapping Devices (EXPERIMENTAL)"
> + depends on PCI_MSI && ACPI && EXPERIMENTAL
You may want to further restrict to x86 and ia64
And I think you'll need to fixup arch/ia64/Kconfig
BTW, I think EXPERIME
Hi Ohad,
Thanks for the patch.
On Wednesday 08 June 2011 08:43:55 Ohad Ben-Cohen wrote:
> iovmm is erroneously using sg_dma_len with unmapped (DMA API-wise)
> SG entries, and will break if CONFIG_NEED_SG_DMA_LENGTH is enabled.
>
> Fix that by using sg->length instead.
>
> Reported-by: Russell K
When multiple wakeup sources are defined in a system,
there is a small window, when more than one source
can trigger wakeup interrupt.
In the current implementation, the do-while() loop
can handle all wakeup sources that are recorded when
probing the status register in prcm_interrupt_handler().
W
On Tue, Jun 07, 2011 at 05:08:27PM -0700, Kevin Hilman wrote:
> Grant,
>
> Here's a small set of OMAP GPIO fixes for v3.0-rc.
>
> Thanks,
>
> Kevin
Merged, thanks.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
* Roedel, Joerg wrote:
> (Cc'ing Ingo)
>
> On Wed, Jun 08, 2011 at 04:34:18AM -0400, Ohad Ben-Cohen wrote:
> > Create a dedicated iommu drivers folder, put the base iommu code there,
> > and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
> > intel-iommu).
> >
> > Putting a
Hi
While debugging another issue I noticed that McBSP2 clock on Nokia N900
doesn't get disabled in 3.0-rc2 after calling
pm_runtime_put_sync(mcbsp->dev) and the fclk usecount remains active if
the pm_runtime_get_sync(mcbsp->dev) was ever called activating it.
I believe this affects other drivers
On Wed, Jun 08, 2011 at 09:11:16AM -0400, Ohad Ben-Cohen wrote:
> On Wed, Jun 8, 2011 at 4:05 PM, Matthew Wilcox wrote:
> > You've missed at least parisc, ia64, alpha, sparc, powerpc and sh which
> > have IOMMUs.
>
> None of these seem to call register_iommu.
>
> > Not that they necessarily all
On Wed, Jun 8, 2011 at 4:05 PM, Matthew Wilcox wrote:
> You've missed at least parisc, ia64, alpha, sparc, powerpc and sh which
> have IOMMUs.
None of these seem to call register_iommu.
> Not that they necessarily all need to be moved across in
> one patchset, but saying "all iommu drivers" is c
On Thu, Jun 02, 2011 at 09:10:02PM +0300, Dmitry Kasatkin wrote:
> Hi,
>
> Recently we got crashes few times after some other patches to 2.6.32 kernel.
> This patch set greatly prevents race condition situations.
> No crashes are noticed any more.
> Now the driver should be ok for multi core as we
On Wed, Jun 08, 2011 at 11:34:18AM +0300, Ohad Ben-Cohen wrote:
> Create a dedicated iommu drivers folder, put the base iommu code there,
> and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
> intel-iommu).
>
> Putting all iommu drivers together will ease finding similarities
Prior to this patch the uart_clock was cut using prepare/resume calls since
these funcs are no more available with runtime changes use has_async_wake
flag to keep clock active during bootup otherwise uart port will disabled
during boot-up and cannot be enabled back. Also based on this flag we can
d
Move the erratum handling mechanism from serial.c to driver file
and utilise the same func. in driver file.
Acked-by: Alan Cox
Signed-off-by: Govindraj.R
---
drivers/tty/serial/omap-serial.c | 57 ++---
1 files changed, 52 insertions(+), 5 deletions(-)
diff --
Use resume idle call from prcm_irq to enable uart_port from low power states.
Add api to check pad wakeup status which will we used from uart_resume func.
to enable back uart port if a wakeup event occurred.
UART_Resume func. can be removed once we have irq_chaining functionality
available.
Signe
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The auto suspend delay that will be passed
Cleanup serial.c file in preparation to addition of runtime api's in omap-serial
file. Remove all clock handling mechanism as this will be taken care with
pm runtime api's in omap-serial.c file itself.
1.) Remove omap-device enable and disable. We can can use get_sync/put_sync
api's
2.) Remove co
The pad values here are same as the default pad values updated in
serial.c file.
Avoid structure duplication and use default pads.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/board-3430sdp.c | 100 +--
1 files changed, 1 insertions(+), 99 deletions(-)
dif
Adapts omap-serial driver to use pm_runtime api's.
1.) Populate reg values to uart port which can be used for context restore.
2.) Moving context_restore func to driver from serial.c
3.) Adding port_enable/disable func to enable/disable given uart port.
enable port using get_sync and disable u
In preparation to UART runtime conversion. Remove certain uart specific calls
from sram_idle path in pm24xx/34xx files.
These func calls will no more be used with upcoming uart runtime design.
1.) Removing console lock holding :- Now can be handled with omap-serial file
itself.
2.) omap_uart_c
>From OMAP4430 ES2.0 onwards if uart is configured in dma mode we need to set
uart tx threshold value using the new register UART_TX_DMA_THRESHOLD, this
register can used if UART_MDR3 bit(2) is set. We have to ensure
tx_threshold + tx_trigger <= 63 from es2.0 onwards. By default we are using
tx_tri
From: Jon Hunter
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
The secound timeou
Add default mux data for all uarts if mux info is not passed from
board file to avoid breaking any board support.
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c | 127 +-
1 files changed, 126 insertions(+), 1 deletions(-)
diff --git a/arch/a
Converting uart driver to adapt to pm runtime api's.
Code re-org + cleanup.
Moving some functionality from serial.c to omap-serial.c
Changes involves:
1.) Cleaning up certain uart calls from sram_idle func.
2.) Removed all types of uart clock handling code from serial.c
3.) Using
Acquire console lock before enabling and writing to console-uart
to avoid any recursive prints from console write.
for ex:
--> printk
--> uart_console_write
--> get_sync
--> printk from omap_device enable
--> uart_console write
Use RPM_SU
Hi Tony,
On Monday 30 May 2011 14:47:07 Laurent Pinchart wrote:
> Hi everybody,
>
> Here are two OMAP3 IOMMU fixes required to support big and/or unaligned
> memory buffers.
>
> Laurent Pinchart (2):
> omap3: iovmm: Work around sg_alloc_table size limitation in IOMMU
> omap3: iovmm: Support
Hi Ohad,
On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote:
> On Tue, Jun 7, 2011 at 2:26 PM, Laurent Pinchart wrote:
> >> Right now we have a BUG_ON if pa is unaligned, but that can be changed
> >> if needed (do we want it to handle offsets ?).
> >
> > At least for the OMAP3 ISP we need to,
On Wed, Jun 8, 2011 at 12:17 PM, David Woodhouse wrote:
> At least iova.o wants to go with it. That's one of the parts that is a
> candidate for harmonisation across IOMMU implementations, either by
> removing it or by having others use it too. It's how we allocate virtual
> I/O address space.
>
>
Hi Russell,
On Monday 06 June 2011 20:00:52 Russell King - ARM Linux wrote:
> On Mon, Jun 06, 2011 at 06:54:10PM +0200, Laurent Pinchart wrote:
> > Of course not, but if the scatterlist is only touched by kernel code, it
> > doesn't need to be contiguous in memory. It could be allocated with
> > v
On Wed, Jun 08, 2011 at 05:17:38AM -0400, David Woodhouse wrote:
> On Wed, 2011-06-08 at 11:34 +0300, Ohad Ben-Cohen wrote:
> > --- a/drivers/pci/Makefile
> > +++ b/drivers/pci/Makefile
> > @@ -30,7 +30,7 @@ obj-$(CONFIG_PCI_MSI) += msi.o
> > obj-$(CONFIG_HT_IRQ) += htirq.o
> >
> > # Build Inte
(Cc'ing Ingo)
On Wed, Jun 08, 2011 at 04:34:18AM -0400, Ohad Ben-Cohen wrote:
> Create a dedicated iommu drivers folder, put the base iommu code there,
> and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
> intel-iommu).
>
> Putting all iommu drivers together will ease findin
On Wed, 2011-06-08 at 11:34 +0300, Ohad Ben-Cohen wrote:
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_PCI_MSI) += msi.o
> obj-$(CONFIG_HT_IRQ) += htirq.o
>
> # Build Intel IOMMU support
> -obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o
> +obj-$(C
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested for MSM8X60.
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-msm/Kconfig | 12
arch/a
Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.
Grouping the various iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
differen
Create a dedicated iommu drivers folder, put the base iommu code there,
and move the existing IOMMU API users as well (msm-iommu, amd_iommu and
intel-iommu).
Putting all iommu drivers together will ease finding similarities
between different platforms, with the intention of solving problems once,
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
has to move from drivers/pci/pci.h to include/linux/pci.h. This
This should ease finding similarities with different platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Compile-tested on x86_64.
Signed-off-by: Ohad Ben-Cohen
---
arch/x86/Kconfig | 28
On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote:
> On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
> > On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
> >> The issue is that there is only one modulemode for the whole DSS.
> >> Potentially only the dss_hwmod should have it. But then
Hi Tony,
On Tuesday 31 May 2011 10:57:02 Tony Lindgren wrote:
> Sure, but that's the only option we have to merge any new code.
So this patch will be not taken (even if without this patch OMAP4 McBSP is
broken), unless we move the McBSP code out from plat-omap?
I have discussed with Jarkko, and
Hi,
On Tue, 2011-06-07 at 17:09 +0200, ext Sebastian Reichel wrote:
> On Tue, May 17, 2011 at 11:39:13AM +0300, Carlos Chinea wrote:
> > We are still committed to these patches. We are aiming to release a new
> > version in 3 weeks max, sooner if we can.
> >
> > I am very sorry for the delay and
58 matches
Mail list logo
