On Tue, 2012-05-22 at 04:26 +, Mohammed, Afzal wrote:
Tony, Artem, how should the conflict between omap mtd trees be handled
for patch series ?
You merge the 2 trees and work on top of that? Or you wait for 3.5-r1
when everything is merged and work on top of that?
--
Best Regards,
Artem
Hi Afzal
On Thu, 10 May 2012, Mohammed, Afzal wrote:
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
(attribution lost)
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break
Hi Artem,
On Tue, May 22, 2012 at 11:44:43, Artem Bityutskiy wrote:
You merge the 2 trees and work on top of that? Or you wait for 3.5-r1
when everything is merged and work on top of that?
I will merge 2 trees do
Tony, are you ok with that ?
Regards
Afzal
Hello,
On Mon, May 21, 2012 at 6:14 PM, Menon, Nishanth n...@ti.com wrote:
On Mon, May 21, 2012 at 9:51 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
On Mon, May 21, 2012 at 08:36:35AM -0500, ext Nishanth Menon wrote:
Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin
On Mon, May 21, 2012 at 12:01:06PM -0700, Tony Lindgren wrote:
The FS (Full Speed) USB controller is available on 2420 and 2430,
but not being used.
Out of the 2420 based boards only Nokia N8X0 are seeing active
development and they have external HS (High Speed) TUSB controller.
On omap
On Mon, May 21, 2012 at 12:01:02PM -0700, Tony Lindgren wrote:
We should not select ARCH_OMAP_OTG as the hardware does not
have the legacy FS (Full Speed) USB interface.
Cc: linux-...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Cc: Kyungmin Park
On Mon, May 21, 2012 at 12:01:09PM -0700, Tony Lindgren wrote:
As the FS USB code is not being actively used for omap2+
there's no point keeping it around for omap2+.
Let's make the FS USB platform init code omap1 only so
we can remove the last user of omap_read/write for omap2+,
and
On Mon, May 21, 2012 at 12:01:11PM -0700, Tony Lindgren wrote:
There are no active users of this code for omap2 as
the boards in use have either TUSB or MUSB controller.
While at it, also fix warnings related to uninitialized
dc_clk and hhc_clk.
Cc: linux-...@vger.kernel.org
Cc: Felipe
On Mon, 2012-05-21 at 21:47 -0500, Ricardo Neri wrote:
genirq requires that the IRQ requests that do not provided a handler to
use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line
is reenabled while the interrupt is still asserted. While this situation may
not happen
Hi Michal,
On Tue, May 22, 2012 at 8:51 AM, Michal Simek mon...@monstr.eu wrote:
Simple enabling RSC_VDEV in rproc_handle_rsc doesn't work.
Sure - you'll need to actually plug the vrings allocation code there,
too (i.e. this requires some coding, it's not a 1-liner).
BTW: I am using kernel
For some reason one of the dev_err invocations is using a wrong
device so fix that.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/remoteproc/omap_remoteproc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
Hi Ohad and Michal
yes I can share my patch, remoteproc has evolved and my patch is not
aligned on latest version of remote proc (especially since remoteproc:
remove the single rpmsg vdev limitation).
Ohad, for alignment I can take the latest branch of kernel.org
(remoteproc) branch
Hi Ludovic,
On Tue, May 22, 2012 at 12:14 PM, frq09524 ludovic.ba...@stericsson.com wrote:
Ohad, for alignment I can take the latest branch of kernel.org (remoteproc)
branch for-next?
Sure, it's pretty much updated sans a few simple changes.
Thanks,
Ohad.
--
To unsubscribe from this list:
On Mon, May 21, 2012 at 8:24 AM, Corentin Chary
corentin.ch...@gmail.com wrote:
In all these files, the .power field was never correctly initialized.
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
drivers/gpu/drm/i915/intel_panel.c | 1 +
Hi Florian,
Here are the OMAP DSS changes for 3.5.
I really tried this time to send the pull request early, but here I am
again, sending it when the merge window has already opened... A few
late-found bugs caused some unnecessary delays.
I'm using github this time instead of gitorious, as
Hi Paul,
On Tue, May 22, 2012 at 12:17:30, Paul Walmsley wrote:
Hi Afzal
On Thu, 10 May 2012, Mohammed, Afzal wrote:
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
(attribution lost)
Hmm, second time, normally I try to delete as much as possible contents from
the original mail
When an rproc instance is registered, remoteproc asynchronously
loads its firmware in order to tell which vdevs it supports.
Later on those vdevs are registered, and when probed, their drivers
usually trigger powering on of the remote processor.
OTOH, non-standard scenarios might involve early
hi Ohad
In my previous patch, to find the correct subdevice that match with
physical memory, I used pa member of rproc_mem_entry.
but today in these 2 resources: fw_rsc_trace, fw_rsc_vdev_vring, pa
menber has been removed.
for fw_rsc_trace it's not a problem, because use rproc_da_to_va and
From: Wenbiao Wang ww...@ti.com
Voltage Processor state machine transition to disable need to
occur from IDLE state. When we transition OPP in a functioning
system, the call sequence for an OPP transition is as follows:
omap_sr_disable
- sr class 3 disable
- vp disable
On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote:
On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote:
On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
Cousson, Benoitb-cous...@ti.com writes:
On 4/24/2012 4:46 PM, Tero Kristo wrote:
On Mon, 2012-04-23 at 10:52 -0500,
On 5/22/2012 4:20 PM, Tero Kristo wrote:
On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote:
On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote:
On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
Cousson, Benoitb-cous...@ti.com writes:
On 4/24/2012 4:46 PM, Tero Kristo wrote:
Hi Benoit,
On 05/21/2012 11:58 AM, Cousson, Benoit wrote:
Hi Jon,
On 5/16/2012 1:35 AM, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Currently, the dmtimer determines whether an timer can support an
external
clock source (sys_altclk) for driving the timer by the IP version. Only
On 5/22/2012 5:04 PM, Jon Hunter wrote:
...
In fact, if the alt clock is there the alt_clk alias will be there and
thus you can use the clk_get(dev, alt_clk) to figure out if the clock
is there or not.
Ok, I can do this and did think about it, but then wondered why it had
been done this way
* Felipe Balbi ba...@ti.com [120522 00:15]:
On Mon, May 21, 2012 at 12:01:11PM -0700, Tony Lindgren wrote:
There are no active users of this code for omap2 as
the boards in use have either TUSB or MUSB controller.
While at it, also fix warnings related to uninitialized
dc_clk and
* Felipe Balbi ba...@ti.com [120522 00:14]:
On Mon, May 21, 2012 at 12:01:09PM -0700, Tony Lindgren wrote:
As the FS USB code is not being actively used for omap2+
there's no point keeping it around for omap2+.
Let's make the FS USB platform init code omap1 only so
we can remove the
* Paul Walmsley p...@pwsan.com [120521 23:51]:
Next, I'd suggest implementing the code to allow GPMC timing configuration
from raw register data (the second method above). This is hackish but for
some boards, this is all we'll have. This will also presumably require
some extra DT
* Mohammed, Afzal af...@ti.com [120522 00:05]:
Hi Artem,
On Tue, May 22, 2012 at 11:44:43, Artem Bityutskiy wrote:
You merge the 2 trees and work on top of that? Or you wait for 3.5-r1
when everything is merged and work on top of that?
I will merge 2 trees do
Tony, are you ok with
This is a very simple few-liner patchset, which allows to optionally
enable write-through caching for OMAP DSS framebuffer. The problem with
the current writecombine cacheability attribute is that it only speeds
up writes. Uncached reads are slow, even though the use of NEON mitigates
this problem
Needed for remapping pages with write-through cacheable
attribute. May be useful for framebuffers.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
arch/arm/include/asm/pgtable.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
Write-through cached framebuffer eliminates the need for using shadow
framebuffer in xf86-video-fbdev DDX. At the very least this reduces
memory footprint, but the performance is also the same or better
when moving windows or scrolling on ARM11 and Cortex-A8 hardware.
Benchmark with
From: Jon Hunter jon-hun...@ti.com
OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the
omap_dm_timer_request() function fails to allocate a dmtimer because the call
to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply
because the clock data for the
From: Jon Hunter jon-hun...@ti.com
The function omap2_clk_set_parent is just a wrapper for the
omap_clksel_set_parent() function. Now we have moved the
omap_clksel_set_parent() function into the plat-omap directory for all OMAP
devices to use, we should just use this function directly and we can
From: Jon Hunter jon-hun...@ti.com
The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a con-id string to search for the appropriate functional clock.
Currently, we define a clock alias for each
From: Jon Hunter jon-hun...@ti.com
Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
From: Jon Hunter jon-hun...@ti.com
OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's parent. Now OMAP1
can use the clock framework
On Tue, May 22, 2012 at 10:54 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
And at least for ARM11 and Cortex-A8 processors, the performance of
write-through cache is really good. Cortex-A9 is another story, because
all pages marked as Write-Through are supposedly treated as
Hi Tony, Paul,
On 05/17/2012 11:48 AM, Paul Walmsley wrote:
On Thu, 17 May 2012, Jon Hunter wrote:
Yes that's right. What is your preference here, the options are ...
1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the
omap2_xxx API names to omap_xxx.
2. Add the functions
On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary corentin.ch...@gmail.com wrote:
In all these files, the .power field was never correctly initialized.
...
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -342,6 +342,7 @@ int
On 05/22/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.
On 05/22/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's
On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote:
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote:
Rafael,
Keerthy j-keer...@ti.com writes:
From: J Keerthy j-keer...@ti.com
AVS(Adaptive Voltage Scaling) is a power management technique which
controls
41 matches
Mail list logo
