On Friday 19 April 2013 06:19 AM, Jon Hunter wrote:
>
> On 04/18/2013 07:34 PM, Jon Hunter wrote:
>>
>> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>>
>> ...
>>
Why not just init context right here if bank->loses_context &&
!bank->context_val
On 04/18/2013 07:34 PM, Jon Hunter wrote:
>
> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>
> ...
>
>>> Why not just init context right here if bank->loses_context &&
>>> !bank->context_valid?
>
> I really like this idea a lot. It can really clean-u
On 04/18/2013 06:10 PM, Jon Hunter wrote:
> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
...
>> Why not just init context right here if bank->loses_context &&
>> !bank->context_valid?
I really like this idea a lot. It can really clean-up the code
and really make it much more readable. Before we
On 04/18/2013 06:24 PM, Jon Hunter wrote:
>
> On 04/18/2013 05:48 PM, Christoph Fritz wrote:
>> On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote:
>>> On 04/18/2013 03:23 PM, Christoph Fritz wrote:
>>
>>
OMAP3_EVM # md 0x6E60 7
6e60: 1800 00141400 00141400 0f010f01
On 04/18/2013 05:48 PM, Christoph Fritz wrote:
> On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote:
>> On 04/18/2013 03:23 PM, Christoph Fritz wrote:
>
>
>>> OMAP3_EVM # md 0x6E60 7
>>> 6e60: 1800 00141400 00141400 0f010f01
>>> 6e70: 010c1414 1f0f0a80 08
Hi Kevin,
On 04/18/2013 04:34 PM, Kevin Hilman wrote:
> Hi Jon,
>
> Jon Hunter writes:
>
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio context being performed without e
On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote:
> On 04/18/2013 03:23 PM, Christoph Fritz wrote:
> > OMAP3_EVM # md 0x6E60 7
> > 6e60: 1800 00141400 00141400 0f010f01
> > 6e70: 010c1414 1f0f0a80 0870 p...
>
> I don't see any other
Hi Aaro,
On Tue, Apr 09, 2013 at 10:51:25PM +0300, Aaro Koskinen wrote:
> Tahvo is a multi-function device on Nokia 770, implementing USB
> transceiver and charge/battery control.
>
> It's so close to Retu that a single driver can support both.
>
> Signed-off-by: Aaro Koskinen
> Cc: Samuel Orti
On 04/18/2013 03:23 PM, Christoph Fritz wrote:
> Hi Jon
>
> On Thu, 2013-04-18 at 14:39 -0500, Jon Hunter wrote:
>> On 04/18/2013 02:03 PM, Christoph Fritz wrote:
>
>> I had put the complete size in here so ...
>>
>> + reg = <0 0 0x100>;
>
> Thanks.
>
>>
>>> + n
Sourav Poddar writes:
> On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only
>>> one making
>>> use of it. Now serial core/driver takes care of the case when
>>> "no_console_suspend"
>
Sourav Poddar writes:
> Hi Kevin,
> On Thursday 18 April 2013 11:26 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> The patch adapt the serial core/driver to take care of the case when
>>> "no_console_suspend"
>>> is used in the bootargs. The patch will remove dependency to set od->flag
Hi Jon,
Jon Hunter writes:
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In other words, the context r
Hi Jon
On Thu, 2013-04-18 at 14:39 -0500, Jon Hunter wrote:
> On 04/18/2013 02:03 PM, Christoph Fritz wrote:
> I had put the complete size in here so ...
>
> + reg = <0 0 0x100>;
Thanks.
>
> > + nand-bus-width = <16>;
> > + ti,nand-ecc-opt = "bch8
* Roger Quadros [130415 01:53]:
> Provide the RESET and Power regulators for the USB PHY,
> the USB Host port mode and the PHY device.
>
> The USB PHY needs AUXCLK3 to operate. Provide this information
> as well.
>
> Also provide pin multiplexer information for the USB host
> pins.
>
> This pat
On 04/18/2013 02:03 PM, Christoph Fritz wrote:
> Hi
>
> I'm trying to setup nand support for an omap3 board for linux-next
> (next-20130417). This is my approach so far:
>
>
> +&gpmc {
> + ranges = <0 0 0x3000 0x100>;
> + nand@0,0 {
> + reg = <0 0 0xff>;
Hi Kevin,
On Thursday 18 April 2013 11:53 PM, Kevin Hilman wrote:
Hi Sourav,
Sourav Poddar writes:
Hi,
This patch series contains fixes and cleanups around the issue that
the console UART should not idled on suspend while using "no_console_suspend"
in bootargs.
The direction of the series
Hi Kevin,
On Thursday 18 April 2013 11:41 PM, Kevin Hilman wrote:
Sourav Poddar writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using "no_console_suspend" in the bootargs.
We can get rid of the previous implementatio
Hi Kevin,
On Thursday 18 April 2013 11:39 PM, Kevin Hilman wrote:
Sourav Poddar writes:
Since the omap serial driver is now adapted to handle the
case where you dont need to cut the clock on suspend while
using "no_console_suspend" in the bootargs.
We can get rid of the previous implementatio
On Thursday 18 April 2013 11:35 PM, Kevin Hilman wrote:
Sourav Poddar writes:
Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only one
making
use of it. Now serial core/driver takes care of the case when
"no_console_suspend"
is used in the bootargs and you need to keep
Hi
I'm trying to setup nand support for an omap3 board for linux-next
(next-20130417). This is my approach so far:
+&gpmc {
+ ranges = <0 0 0x3000 0x100>;
+ nand@0,0 {
+ reg = <0 0 0xff>; /* <- ? not sure about that */
+ nand-bus-width = <16
On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d.
On 04/18/2013 01:21 PM, Anna, Suman wrote:
> Jon,
>
>>
>> On 04/17/2013 07:04 PM, Jon Hunter wrote:
>>>
>>> On 04/17/2013 06:23 PM, Suman Anna wrote:
Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
Hi Sourav,
Sourav Poddar writes:
> Hi,
>
> This patch series contains fixes and cleanups around the issue that
> the console UART should not idled on suspend while using "no_console_suspend"
> in bootargs.
>
The direction of the series is right, thanks for the updated approach.
I had a comple
Jon,
>
> On 04/17/2013 07:04 PM, Jon Hunter wrote:
> >
> > On 04/17/2013 06:23 PM, Suman Anna wrote:
> >> Some instances of the DMTIMER peripheral on OMAP4+ devices have the
> >> ability to interrupt the on-chip image processor unit (IPU) subsystem
> >> (a common name for the dual Cortex-M3 subsy
Hi Kevin,
On Thursday 18 April 2013 11:26 PM, Kevin Hilman wrote:
Sourav Poddar writes:
The patch adapt the serial core/driver to take care of the case when
"no_console_suspend"
is used in the bootargs. The patch will remove dependency to set od->flags to
"OMAP_DEVICE_NO_IDLE_ON_SUSPEND" in s
Sourav Poddar writes:
> Since the omap serial driver is now adapted to handle the
> case where you dont need to cut the clock on suspend while
> using "no_console_suspend" in the bootargs.
>
> We can get rid of the previous implementation of setting the od->flags to
> "OMAP_DEVICE_NO_IDLE_ON_SUSP
Sourav Poddar writes:
> Since the omap serial driver is now adapted to handle the
> case where you dont need to cut the clock on suspend while
> using "no_console_suspend" in the bootargs.
>
> We can get rid of the previous implementation of setting the od->flags to
> "OMAP_DEVICE_NO_IDLE_ON_SUSP
Sourav Poddar writes:
> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since UART was the only
> one making
> use of it. Now serial core/driver takes care of the case when
> "no_console_suspend"
> is used in the bootargs and you need to keep the clock enable for console
> even while suspe
Sourav Poddar writes:
> The patch adapt the serial core/driver to take care of the case when
> "no_console_suspend"
> is used in the bootargs. The patch will remove dependency to set od->flags to
> "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" in serial.c(non dt case) and
> omap_device.c(dt case).
>
> Prepa
Fix the following error by moving the function to be within
the smc91x related ifdef as that's the only user:
arch/arm/mach-omap2/board-h4.c:238: warning: ‘is_gpmc_muxed’ defined but not
used
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-h4.c |4 ++--
1 file changed, 2 inserti
Commit 8a6201b9 (ARM: OMAP2+: Fix unmet direct dependencies for zoom
for 8250 serial) fixed unmet direct dependencies for 8250, but failed
to do the same for omap serial. This can cause the following warning:
warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has
unmet direct dependencies
Fix the following by removing the unused variable:
arch/arm/mach-omap2/board-am3517crane.c: In function ‘am3517_crane_init’:
arch/arm/mach-omap2/board-am3517crane.c:113: warning: unused variable ‘ret’
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-am3517crane.c |2 --
1 file cha
Few trivial fixes for randconfig found issues.
Regards,
Tony
---
Tony Lindgren (3):
ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP
ARM: OMAP2+: Fix unused variable warning for am3517 crane
ARM: OMAP2+: Fix is_gpmc_muxed warning for H4
arch/arm/configs/omap2plus_
On Thu, 2013-04-18 at 17:37 +0300, Tomi Valkeinen wrote:
> > But here with linux-next (in contrast to 3.9-rc) removing all regulator
> > dependencies from drivers/video/omap2/dss/dpi.c does not make the trick.
> > The display stays dark :-( ...
>
> That's with your DT hacked kernel, right? Not the
On 04/18/2013 03:22 AM, Santosh Shilimkar wrote:
> On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio context being perfor
On 04/15/2013 07:40 PM, Mark Brown wrote:
On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote:
On 04/15/2013 06:50 PM, Mark Brown wrote:
In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.
I've still
On 15/04/13 18:34, Mugunthan V N wrote:
> On 4/15/2013 10:58 PM, Mark Jackson wrote:
>> On 15/04/13 18:07, Mugunthan V N wrote:
>>> On 4/15/2013 12:46 AM, Mark Jackson wrote:
>>
>>
>>
Notice that at the end, the nfs link appears to come back "ok", but
the "ps" command never complete
On 2013-04-18 13:13, Christoph Fritz wrote:
> On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote:
>> On 2013-04-18 12:09, Tomi Valkeinen wrote:
>>> On 2013-04-18 11:37, Christoph Fritz wrote:
>>
With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my
Hi,
On Thu, Apr 18, 2013 at 05:37:48PM +0530, Sourav Poddar wrote:
> Hi Felipe,
> On Thursday 18 April 2013 09:28 AM, Felipe Balbi wrote:
> >Hi,
> >
> >On Wed, Apr 17, 2013 at 05:04:24PM +0530, Sourav Poddar wrote:
> >>@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops
>
On 04/16/2013 10:07 PM, Mike Turquette wrote:
Quoting Andrii Tseglytskyi (2013-04-16 05:40:44)
On 04/16/2013 12:53 AM, Kevin Hilman wrote:
In addition to Mike's comments (which I completely agree with), it would
be very helfpul to see how this is actually used. e.g, how the
regulators are chai
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring wrote:
> On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
>> On 04/09/2013 12:16 AM, Stephen Warren wrote:
>>> On 04/08/2013 04:05 PM, Rob Herring wrote:
On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
> According to
> Docume
Hi Felipe,
On Thursday 18 April 2013 09:28 AM, Felipe Balbi wrote:
Hi,
On Wed, Apr 17, 2013 at 05:04:24PM +0530, Sourav Poddar wrote:
@@ -1632,6 +1650,8 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(serial_omap_suspend, serial_omap_resume)
On Tuesday 02 April 2013 06:10 PM, Vivek Gautam wrote:
Hi,
On Tue, Apr 2, 2013 at 5:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Apr 02, 2013 at 04:04:01PM +0530, Vivek Gautam wrote:
On Mon, Apr 01, 2013 at 07:24:00PM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on
Rev. Ax/Bx boards have reversed polarity for USBHOST_PWR_ENable
signal when compared to Rev. C boards.
We create a new dts file for Ax/Bx boards.
Also update model and compatible flags for Rev. C board.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm-ab.d
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 61 +
1 files
On 04/16/2013 10:18 PM, Kevin Hilman wrote:
Andrii Tseglytskyi writes:
Hi Kevin,
On 04/16/2013 12:53 AM, Kevin Hilman wrote:
Andrii Tseglytskyi writes:
From: "Andrii.Tseglytskyi"
Following patch series introduces the Adaptive Body-Bias
LDO driver, which handles LDOs voltage during OPP c
Hi Paul,
>>> _enable_wakeup() and _disable_wakeup() are expected to program the
>>> OCP_SYSCONFIG.ENAWAKEUP bit.
>>
>> These functions were originally intended to take care of everything needed
>> for the IP block to wake up the chip, including the PRCM WKEN programming.
>> ENAWAKEUP is simply
Hi Russell,
On Thursday 18 April 2013 04:20 PM, Russell King - ARM Linux wrote:
On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote:
Since "uart_console" definition is now moved to serial core
haeder file . Serial drivers need not define them.
This needs to be part of patch 1. Having
On Wed, Apr 17, 2013 at 05:04:23PM +0530, Sourav Poddar wrote:
> Since "uart_console" definition is now moved to serial core
> haeder file . Serial drivers need not define them.
This needs to be part of patch 1. Having it separate may provoke compiler
warnings.
--
To unsubscribe from this list: s
On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote:
> On 2013-04-18 12:09, Tomi Valkeinen wrote:
> > On 2013-04-18 11:37, Christoph Fritz wrote:
>
> >> With linux-next this patch breaks compiling here because DPI now depends
> >> on DSI - but my omap3 board here doesn't use DSI at all:
> >>
>
On 04/17/2013 10:16 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
(..)
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 03bd60d..0c48f6b 100644
> --- a/arch/arm/boot/dts
On 2013-04-18 12:09, Tomi Valkeinen wrote:
> On 2013-04-18 11:37, Christoph Fritz wrote:
>> With linux-next this patch breaks compiling here because DPI now depends
>> on DSI - but my omap3 board here doesn't use DSI at all:
>>
>> drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
>> dr
On 2013-04-18 11:37, Christoph Fritz wrote:
> Hi Tomi
>
> On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
>> Tomi Valkeinen (38):
>> OMAPDSS: add fields to panels' platform data
>> OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev
>> OMAPDSS: HDMI: remove HDMI cl
On 04/18/2013 12:33 AM, Jon Hunter wrote:
>
> On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
>> On 04/17/2013 11:27 PM, Jon Hunter wrote:
>>>
>>> On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
The GPMC DT probe function use for_each_node_by_name() to search
child device
Hi Tomi
On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
> Tomi Valkeinen (38):
> OMAPDSS: add fields to panels' platform data
> OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev
> OMAPDSS: HDMI: remove HDMI clk divisors from dssdev
> OMAPDSS: DPI: remove om
On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
> Commit a2797be (gpio/omap: force restore if context loss is not
> detectable) broke gpio support for OMAP when booting with device-tree
> because a restore of the gpio context being performed without ever
> initialising the gpio context. In ot
56 matches
Mail list logo