Hi Tony,
On Wednesday 17 October 2012 03:27 AM, Tony Lindgren wrote:
* Afzal Mohammedaf...@ti.com [121015 05:15]:
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
gpio/omap: save and restore debounce registers
GPIO debounce registers need to be saved and restored for proper functioning
of
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no
On Tue, Oct 16, 2012 at 8:26 PM, Tony Lindgren t...@atomide.com wrote:
Hmm looking at it repeats the same code over again. Can you
rather add some wl12xx_board_init() helper function to mach-omap2/devices.c
to do it?
Nice, see below. Note that I can only compile test this now, which may
be ok
Hi,
I'm currently building 3.7rc1 kernels meant to run on beagleboards (omap3),
pandaboards (omap4) and beaglebones (am335x). At the moment I'm only testing it
on beaglebone and I noticed a problem with the different cpufreq drivers
getting in eachothers way.
I patched in cpufreq-cpu0 support
This is the third version of the series. Changes to v2 are:
* rebased on 3.7-rc1 to resolve conflicts
* add omap_vrfb_supported() so that cpu_is_* check can be removed from omapfb
As Kevin Hilman pointed out, the context restore is not functional. I didn't
touch that, as it's not functional with
This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.
The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.
The vrfb driver will parse those resources and use them to access
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
Now that VRFB driver handles its registers independently, we can remove
the VRFB related code from OMAP's sdrc.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/sdrc.c | 16
Add an exported function omap_vrfb_supported() which returns true if the
vrfb driver has been loaded succesfully. This can be used to decide if
VRFB can be used or not.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/vrfb.c | 16
Replace cpu_is_*() check with omap_vrfb_supported().
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
Hi Tony,
I have pushed this vrfb series and the omapdss version series to:
git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version
git://gitorious.org/linux-omap-dss2/linux.git 3.8/vrfb-conversion
If they look ok to you and we don't get any other comments, I think
these branches can be
Hi,
This series contains minor cleanups and fixes for omapdss.
Tomi
Tomi Valkeinen (9):
OMAPDSS: DSI: fix dsi_get_dsidev_from_id()
OMAPDSS: fix registering the vsync isr in apply
OMAPDSS: DISPC: constify function parameters
OMAPDSS: combine LCD related config into one func
OMAPDSS:
If dsi_get_dsidev_from_id() is called with a DSI module id that does not
exist on the board, the function will crash as omap_dss_get_output()
will return NULL.
This happens on omap3 boards when dumping DSI clocks, as the dumping
code will try to get the dsidev for DSI modules 0 and 1, but omap3
When we enable an output we don't check if we need to register the vsync
isr. This causes us to miss vsync interrupts until somebody changes the
configuration of an overlay or an overlay manager.
Add the registration to dss_mgr_enable to fix the problem.
Signed-off-by: Tomi Valkeinen
Dispc has a bunch of functions used to configure output related
parameters:
- dispc_mgr_set_io_pad_mode
- dispc_mgr_enable_stallmode
- dispc_mgr_enable_fifohandcheck
- dispc_mgr_set_clock_div
- dispc_mgr_set_tft_data_lines
- dispc_lcd_enable_signal_polarity
- dispc_mgr_set_lcd_type_tft
These are
dss_mgr_set_device and dss_mgr_unset_device are declared in dss.h, but
the functions do not exist. Remove the declarations.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h
dispc_ovl_setup() uses struct omap_overlay to get the caps for the
overlay. We can change the code to get the caps directly from dss
features, thus removing the dependency to struct omap_overlay.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |4 ++--
dispc.c's functions to enable LCD and DIGIT outputs can be cleaned up a
bit by using common functions to set the enable bit and to check if the
output is enabled.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c | 27 ++-
1 file
Add function that returns the sync lost irq mask for the given channel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |5 +
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c
We currently have a single function to enable and disable the manager
output for LCD and DIGIT. The functions are a bit complex, as handling
both enable and disable require some extra steps to ensure that the
output is enabled or disabled properly without errors before exiting the
function.
The
Hi Ohad,
On 10/17/12 11:10, Ohad Ben-Cohen wrote:
On Tue, Oct 16, 2012 at 8:26 PM, Tony Lindgren t...@atomide.com wrote:
Hmm looking at it repeats the same code over again. Can you
rather add some wl12xx_board_init() helper function to mach-omap2/devices.c
to do it?
Nice, see below. Note
When building omap_l3_noc/smx drivers as modules, the following
warning appears:
CC [M] drivers/bus/omap_l3_smx.o
drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage
class
drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration
of
(Looping Arnd and Olof)
On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
When building omap_l3_noc/smx drivers as modules, the following
warning appears:
CC [M] drivers/bus/omap_l3_smx.o
drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage
class
Hi,
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
[...]
The problem I see is that even though we properly return IRQ_WAKE_THREAD
and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
the thread is
Hi,
On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote:
We currently have a single function to enable and disable the manager
output for LCD and DIGIT. The functions are a bit complex, as handling
both enable and disable require some extra steps to ensure that the
output is enabled or
On 10/16/2012 04:26 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121016 14:00]:
Hi Tony,
On 10/16/2012 12:48 PM, Tony Lindgren wrote:
* Richard Cochran richardcoch...@gmail.com [121015 12:18]:
From: hvaib...@ti.com hvaib...@ti.com
With recent changes in omap gpmc driver code,
Hi Afzal,
On 17.10.2012 07:42, Afzal Mohammed wrote:
On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
I certainly don't think it is easier, rather tougher, cleaner
as well. One thing that worried me was, if we pursue the
auxdata path (a last resort option) and later if it is
Hi guys,
this series is actually *REALLY* far from ready, but I wanted
to ask if I should continue down this track because it really
looks (to me at least) that OMAP's PM layer took a few uneecessary
shortcuts.
I'm trying to understand the reasoning behind that, so bear with
me for a while.
At
device drivers should be smart enough to provide
-suspend/-resume callbacks when needed and they
should take care of doing whatever needs to be
done in order to allow a device to be suspended.
Calling pm_runtime_* from system suspend isn't
the right way to achieve that, as it creates a
situation
current omap_device PM implementation defines
omap-specific *_noirq methods but uses the
generic versions for all other PM methods.
As it turns out, if a device decides to implement
non-runtime PM callbacks, we might fall into a
situation where the hwmod is still idled which
will generate an
during system-wide (static) suspend, we also
want to save our context and restore it when
waking up.
Let's introduce new suspend/resume methods so
that we can survive a suspend-to-ram transition.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 60
OMAP I2C driver will re-enable IRQs right after
masking them during suspend.
That's not what we want. We want to keep IRQs
masked until our resume method is called.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 2 insertions(+), 8
current implementation doesn't take care about
drivers which don't provide *_noirq methods and we
could fall into a situation where we would suspend/resume
devices even though they haven't asked for it.
One such case happened with the I2C driver which
was getting suspended during suspend_noirq()
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-host.c
Hi,
On Wed, Oct 17, 2012 at 06:43:41PM +0300, Felipe Balbi wrote:
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-host.c
* Daniel Mack zon...@gmail.com [121017 08:15]:
Hi Afzal,
On 17.10.2012 07:42, Afzal Mohammed wrote:
On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
I certainly don't think it is easier, rather tougher, cleaner
as well. One thing that worried me was, if we pursue the
auxdata
Hi,
On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote:
Hi Kalle,
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the i2c bus irq gets
* Jon Hunter jon-hun...@ti.com [121017 07:43]:
On 10/16/2012 04:26 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [121016 14:00]:
Hi Tony,
On 10/16/2012 12:48 PM, Tony Lindgren wrote:
* Richard Cochran richardcoch...@gmail.com [121015 12:18]:
From: hvaib...@ti.com
On Tue, Oct 16, 2012 at 8:53 PM, Sebastien Guiriec s-guir...@ti.com wrote:
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch takes advantage of defer probe feature
and pin control in order
* Paul Walmsley p...@pwsan.com [121016 17:48]:
Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents
into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in
cleaning out arch/arm/plat-omap/, as his upstreams request.
Signed-off-by: Paul Walmsley p...@pwsan.com
This series adds device-tree support for the timers on OMAP2+ devices
including AM33xx.
Testing:
1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430
Panda and AM335x Beagle Bone with/without ...
a). device-tree present
b). CONFIG_OMAP_32K_TIMER set
c). kernel
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Please note that for OMAP2/3 devices, there is only one
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for
Currently OMAP timers can be requested by requesting any available or by a
numerical device ID. If a specific timer is required because it has a particular
capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
then the user needs to know the device ID of the timer with this
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
Some OMAP3 boards, such as the OMAP3 beagle board, only use GP devices and for
GP devices there is a 12th timer
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called
On 10/17/2012 01:01 PM, Jon Hunter wrote:
This series adds device-tree support for the timers on OMAP2+ devices
including AM33xx.
Testing:
1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430
Panda and AM335x Beagle Bone with/without ...
a). device-tree
* Tony Lindgren t...@atomide.com [121015 17:09]:
* Tony Lindgren t...@atomide.com [121009 17:21]:
* Péter Ujfalusi peter.ujfal...@ti.com [121009 02:03]:
On 10/08/2012 07:35 PM, Tony Lindgren wrote:
- omap-dma.c and omap-pcm.c can test the arch locally as
omap1 and omap2 cannot
Paul,
Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where it came from is here:
http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
Thanks,
Richard
- Forwarded message from Richard Cochran
Benoit,
Would you please take this bugfix for 3.7-rc2? The suggestion to
mail you came from Toni Lindgren. The context where it came from
is here:
http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
Thanks,
Richard
- Forwarded message from Richard Cochran
* Tomi Valkeinen tomi.valkei...@ti.com [121017 03:27]:
Hi Tony,
I have pushed this vrfb series and the omapdss version series to:
git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version
I used this branch up to commit 35f70935c64ae229ebd1fc65398ec68d4d803712,
but left out the x86
Hi!
This adds product names (that most users know) to Kconfig and board
comments.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 346fd26..da08226 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@
This series adds device-tree support for the 32kHz counter on OMAP2+ devices,
which is used as the default kernel clock-source for OMAP devices.
Boot tested on OMAP2420 H4, OMAP3430 Beagle Board and OMAP4430 Panda Board
with and without device-tree present.
Based and dependent upon OMAP2+ series
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/counter32k.txt| 15 +++
arch/arm/boot/dts/omap2420.dtsi
For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
However, this is not the only possible clock-source the kernel can use for OMAP
devices.
When booting with device-tree, if the 32kHz counter is the desired clock-source
for the kernel, then parse the device-tree blob
From: Vaibhav Hiremath hvaib...@ti.com
Add dmtimer clock aliases for AM33XX devices so that the parent clock for
the dmtimer can be set correctly by the dmtimer driver. Without these clock
aliases the dmtimer driver will fail to find the parent clocks for the dmtimer.
Verified that DMTIMERs can
Hi,
Some minor comments:
On Wed, Oct 17, 2012 at 08:33:08PM +0200, Pavel Machek wrote:
This adds product names (that most users know) to Kconfig and board
comments.
Good idea. :-)
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/arch/arm/mach-omap2/Kconfig
People,
This is not aimed at anyone specifically - but it is aimed at everyone
who reviews patches to make them aware of this issue, and to modify their
behaviour.
I'm geting sick and tired of telling people about this. I've just
floated the idea of removing IS_ERR_OR_NULL from the kernel tree
Hi Mark,
* Peter Ujfalusi peter.ujfal...@ti.com [121004 01:27]:
Hello Mark, Tony,
Change since v1:
- Fixed the second patch to keep the omap_mcpdm_open_stream() - after a coffee
The mcpdm driver no longer needs to include any plat/*.h file, clearing the
way
for the single kernel image.
Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the write to the SYSCONFIG register is programming the
same value that is already stored in the register.
Writes to the
cc Rajendra
Hi Jon
On Wed, 17 Oct 2012, Jon Hunter wrote:
Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the write to the SYSCONFIG register is programming the
* Felipe Balbi ba...@ti.com [121017 08:54]:
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.
Thanks, looks like I can't
On 10/17/2012 03:25 PM, Paul Walmsley wrote:
cc Rajendra
Hi Jon
On Wed, 17 Oct 2012, Jon Hunter wrote:
Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the
On 17/10/12 20:41 +0100, Russell King - ARM Linux wrote:
People,
This is not aimed at anyone specifically - but it is aimed at everyone
who reviews patches to make them aware of this issue, and to modify their
behaviour.
I'm geting sick and tired of telling people about this. I've just
On Wed, 17 Oct 2012, Jon Hunter wrote:
Are you looking to go one step further and only update the sysconfig on
enabling when the context has been lost? That would require more
changes.
Yes that's exactly it. That would avoid adding a special case for what
should be the common case. From a
This adds product names (that most users know) to Kconfig and board
comments.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 346fd26..f03f19a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
gpio/omap: save and restore debounce registers
GPIO debounce
On Wed, Oct 17, 2012 at 11:03:00PM +0200, Pavel Machek wrote:
This adds product names (that most users know) to Kconfig and board
comments.
Signed-off-by: Pavel Machek pa...@ucw.cz
Reviewed-by: Aaro Koskinen aaro.koski...@iki.fi
A.
diff --git a/arch/arm/mach-omap2/Kconfig
On 10/17/2012 03:58 PM, Paul Walmsley wrote:
On Wed, 17 Oct 2012, Jon Hunter wrote:
Are you looking to go one step further and only update the sysconfig on
enabling when the context has been lost? That would require more
changes.
Yes that's exactly it. That would avoid adding a special
On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote:
So, what to do? It can and has been used sensibly, so I don't think removing
it is the best option.
Well, the first thing that needs to be done is a full review of every user
and fixes applied.
The second thing is that we need eyes
Hi Tony,
On 10/16/2012 06:00 PM, Tony Lindgren wrote:
Hi all,
Here's a quick status update on the removal of remaining
#include plat/*.h files. Most files are now fixed up, and
we only have the following remaining:
cpu.h wrapper only left, will be removed as soon as drivers are
* Jon Hunter jon-hun...@ti.com [121017 14:53]:
Hi Tony,
On 10/16/2012 06:00 PM, Tony Lindgren wrote:
Hi all,
Here's a quick status update on the removal of remaining
#include plat/*.h files. Most files are now fixed up, and
we only have the following remaining:
cpu.h
Hi Arnd Olof,
Here are the fixes ready to pull, there's at least one more fix in works
but it still requires minor changes. The two top commits are recent as
Jon Hunter noticed an issue freeing resources in his fix and I did a
new branch to swap in the fixed patch.
Regards,
Tony
The
Felipe Balbi ba...@ti.com writes:
On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
[...]
The problem I see is that even though we properly return
Hi Richard
On Wed, 17 Oct 2012, Richard Cochran wrote:
Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where it came from is here:
http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
This patch appears
* Paul Walmsley p...@pwsan.com [121017 16:39]:
Hi Richard
On Wed, 17 Oct 2012, Richard Cochran wrote:
Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where it came from is here:
On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote:
On probe this patch does pm_runtime_enable, however this doesn't mean
the device is turned ON or resumed or kept ON all the time.
In fact it's the other way around; pm_runtime_enable turns off the
power (if it's ON).
On 16 October 2012 12:22, Tony Lindgren t...@atomide.com wrote:
* Omar Ramirez Luna omar.l...@linaro.org [121011 18:07]:
These patches are needed for remoteproc to work on OMAP4.
Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
On Wed, Oct 17, 2012 at 3:02 PM, Tony Lindgren t...@atomide.com wrote:
Hi Arnd Olof,
Here are the fixes ready to pull, there's at least one more fix in works
but it still requires minor changes. The two top commits are recent as
Jon Hunter noticed an issue freeing resources in his fix and I
Hi Wim,
When you have the opportunity, could you take a look at this patch, and
the subsequent patch 6/7, and ack them if you're okay with them?
We'd like to merge thse as part of a larger cleanup series through the
arm-soc tree. They like cleanup patches to arrive at the beginning of the
On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [121017 16:39]:
Hi Richard
On Wed, 17 Oct 2012, Richard Cochran wrote:
Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where
On Thu, 18 Oct 2012, Richard Cochran wrote:
So there has been this cpsw driver since v3.4-rc1~177^2~5
df82859 netdev: driver: ethernet: Add TI CPSW driver
and four people signed off on it, so it must have been working at one
point.
The signoffs just mean that those people are
On Thu, Oct 18, 2012 at 1:51 AM, Omar Ramirez Luna omar.l...@linaro.org wrote:
On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote:
On probe this patch does pm_runtime_enable, however this doesn't mean
the device is turned ON or resumed or kept ON all the time.
In fact
Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
Changes from previous tests
---
Kernel configs have been reorganized and updated. AM335x Beaglebone and
OMAP4460 Pandaboard-ES boards
Hi Daniel,
On Wednesday 17 October 2012 08:43 PM, Daniel Mack wrote:
On 17.10.2012 07:42, Afzal Mohammed wrote:
I doubt whether auxdata would help here, it seems using
compatible field alone would help in deciding relevant
custom timing routine. Whether we want this kind of
peripheral
Jon,
On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit
On Fri, Sep 21, 2012 at 21:19:11, AnilKumar, Chimata wrote:
Add tsl2550 ambient light sensor DT data to am335x-evm.dts. In AM335x
EVM tsl2550 ambient light sensor is connected to I2C2 bus. So this patch
adds child node inside i2c2 node with i2c slave address.
TAOS tsl2550 sensor with
On Thursday 18 October 2012 02:07 AM, Jon Hunter wrote:
Ok, thanks. Yes, only updating the register when the cache value changed
would not work due to the possibility of context being lost. So
Rajendra's change makes sense. However, I think there is room to
optimise this.
With this change, on
Hi,
On Wed, Oct 17, 2012 at 01:34:04PM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121017 08:54]:
In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.
Move USB platform_data to linux/platform_data/omap-usb.h
On Wed, Oct 17, 2012 at 04:06:54PM -0700, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
+ peterz, tglx
Felipe Balbi ba...@ti.com writes:
92 matches
Mail list logo
