On Friday 26 October 2012, Tony Lindgren wrote:
Here's a patch for that. It's against what I have queued up in
omap-for-v3.8/cleanup-headers. Does that look OK to you?
Hi Tony,
thanks for the quick follow-up. Using the absolute #include statements
again looks good, but now there is another
On Fri, Oct 26, 2012 at 03:38:49PM -0700, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121026 10:57]:
* Arnd Bergmann a...@arndb.de [121026 10:30]:
Well, once CONFIG_MULTIPLATFORM gets enabled, the mach/*.h files are
not visible to drivers any more, but they are still
On Saturday 27 October 2012 04:31 AM, Paul Walmsley wrote:
Hi Felipe
just two quick comments
On Thu, 25 Oct 2012, Felipe Balbi wrote:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple
On Saturday 27 October 2012 03:09 AM, Jon Hunter wrote:
On 10/26/2012 03:01 PM, Felipe Balbi wrote:
Hi,
On Fri, Oct 26, 2012 at 03:19:13PM +0200, Tim Niemeyer wrote:
Adds support for configuring the omap-gpio driver use autosuspend for
runtime power management. This can reduce the latency in
Hi Vaibhav,
On Friday 26 October 2012 09:13:20 Hiremath, Vaibhav wrote:
On Thu, Oct 25, 2012 at 19:30:58, Valkeinen, Tomi wrote:
On 2012-03-09 10:03, Hiremath, Vaibhav wrote:
On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote:
On Wednesday 07 March 2012 14:31:16 Archit Taneja
From: Constantine Shulyupin co...@makelinux.com
Tested SD (MMC) and Ethernet smsc95xx on linux-3.7-rc2
Signed-off-by: Constantine Shulyupin co...@makelinux.com
--
kernel size is 2.3 MiB
---
arch/arm/configs/omap4_panda_defconfig | 115
1 file changed, 115
Hi,
On Saturday 27 October 2012 01:29 AM, Felipe Balbi wrote:
Hi,
On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121025 23:55]:
On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121024 23:24]:
Hi,
On
On Saturday 27 October 2012 01:46 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121026 13:07]:
On Fri, Oct 26, 2012 at 10:21:41AM -0700, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [121026 00:48]:
On Friday 26 October 2012, Felipe Balbi wrote:
+static void
On Saturday 27 October 2012 05:33 PM, Constantine Shulyupin wrote:
From: Constantine Shulyupin co...@makelinux.com
Tested SD (MMC) and Ethernet smsc95xx on linux-3.7-rc2
Signed-off-by: Constantine Shulyupin co...@makelinux.com
--
kernel size is 2.3 MiB
---
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 79 +
1 file changed, 79
In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
information to create the devices that is attached to ocp2scp.
Signed-off-by:
This patch series allows ocp2scp driver to create its child devices
from the platform data.
In omap platforms, usb phy is connected to ocp2scp and usb phy is needed
for MUSB to be functional. When ocp2scp driver was added, it had only dt
support which means it wont create usb phy devices for
On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
The original idea of using the hole in the i2c_msg structure is from
David Brownell, who was apparently familiar with such practice, so I
assumed it was OK.
On Sat, 27 Oct 2012, Santosh Shilimkar wrote:
Another alternative, which I will recommend to just make use of the
read*/wrire* instead __raw versions. The barriers are taken care
already and driver point of view, it is transparent.
Those barriers will disappear if
On Fri, Oct 26, 2012 at 12:52 AM, Jon Hunter jon-hun...@ti.com wrote:
Subject: [PATCH] gpio/omap: fix clearing of debounce settings on gpio
free/reset
When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that
On Fri, Oct 26, 2012 at 9:26 PM, Jon Hunter jon-hun...@ti.com wrote:
This change was originally titled gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset. The title has been updated slightly to
reflect (what should be) the final fix.
When a GPIO is freed or shutdown,
* Arnd Bergmann a...@arndb.de [121027 01:11]:
On Friday 26 October 2012, Tony Lindgren wrote:
Here's a patch for that. It's against what I have queued up in
omap-for-v3.8/cleanup-headers. Does that look OK to you?
Hi Tony,
thanks for the quick follow-up. Using the absolute #include
* Russell King - ARM Linux li...@arm.linux.org.uk [121027 02:03]:
Rather than moving all the files from plat-omap/include/plat into plat-omap
and then having all these totally disgusting relative includes, why don't
you add to these makefiles:
ccflags +=
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
The original idea of using the hole in the i2c_msg structure is from
David Brownell, who was
On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
You are wrong. Assumption that pointers are aligned to 32bit boundary
is simply not true. In particular, on m68k alignment is 16bit, i.e. there
struct foo {
char x;
void *p;
}; will have 1 byte occupied by x, followed by
On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
You are wrong. Assumption that pointers are aligned to 32bit boundary
is simply not true. In particular, on m68k alignment is 16bit, i.e. there
struct foo {
char x;
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
The original idea of using the hole in the i2c_msg structure is from
David Brownell, who was
From: Constantine Shulyupin co...@makelinux.com
Problem:
- FDT is supported only by generic OMAP board initialization in
arch/arm/mach-omap2/board-generic.c and lacks some configurations, which are
not yet configured in FDT (USB for example).
Solution:
- arch/arm/mach-omap2/board-omap4panda.c
Hi
On Thu, 25 Oct 2012, Felipe Balbi wrote:
this is important in cases where client driver
wants to know how many bytes were actually
transferred.
There is one trick here: if transfer is completed,
meaning I2C_CNT reaches zero, then ARDY will be
asserted to let SW know that it can
Hi Al,
On Sat, 27 Oct 2012 18:10:36 +0100, Al Viro wrote:
On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
You are wrong. Assumption that pointers are aligned to 32bit boundary
is simply not true. In particular, on m68k
On Wed, Oct 03, 2012 at 09:31:02AM -0700, Tony Lindgren wrote:
Actually we can also drop #include mach/hardware.h too,
it's now empty for mach-omap2. I've updated Tim's patch below
for you guys to queue via the ASoC fixes. It's against the
current linux next.
Applied. Tim, you should send
On Saturday 27 October 2012 09:29 PM, Paul Walmsley wrote:
On Sat, 27 Oct 2012, Santosh Shilimkar wrote:
Another alternative, which I will recommend to just make use of the
read*/wrire* instead __raw versions. The barriers are taken care
already and driver point of view, it is transparent.
28 matches
Mail list logo
