On Tuesday 16 July 2013 03:57 PM, Grygorii Strashko wrote:
Hi Rajendra,
On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device
On Tuesday 16 July 2013 12:53 AM, Suman Anna wrote:
On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
Hi,
On 07/11/2013 09:32 AM, Tony
Hi Rajendra,
On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first
On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It
On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300,
On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
* Kevin Hilman khil...@linaro.org [130710 01:29]:
Felipe Balbi ba...@ti.com writes:
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does in one condition. If
* Rajendra Nayak rna...@ti.com [130710 23:25]:
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
After that having DEBUG_LL and cmdline
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is similar to
On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130710 23:25]:
On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod
Hi,
On Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being
On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
Hi,
On 07/11/2013 09:32 AM, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130710 09:18]:
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on
Felipe Balbi ba...@ti.com writes:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now initialized to 0
instead
of -1 for the serial driver?
You meant initialized to -1, right? There's an additional check for
* Kevin Hilman khil...@linaro.org [130710 01:29]:
Felipe Balbi ba...@ti.com writes:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now initialized to 0
instead
of -1 for the serial driver?
You meant
On 07/09/2013 10:41 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes
Hi,
On Wed, Jul 10, 2013 at 03:16:54PM +0300, Grygorii Strashko wrote:
Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then
* Tony Lindgren t...@atomide.com [130710 05:17]:
* Kevin Hilman khil...@linaro.org [130710 01:29]:
If the problem is omap-serial.c idling things while earlycon is
running, then omap-serial.c should be fixed.
If this is the case, then delaying the idling in omap-serial.c
should take care of
* Kevin Hilman khil...@linaro.org [130710 01:29]:
Felipe Balbi ba...@ti.com writes:
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does in one condition. If context hasn't been saved before. And that
can
Hi,
On Wed, Jul 10, 2013 at 07:26:34AM -0700, Tony Lindgren wrote:
* Kevin Hilman khil...@linaro.org [130710 01:29]:
Felipe Balbi ba...@ti.com writes:
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does
Hi,
On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
-runtime_resume() from being called on first pm_runtime_get*() done
during probe.
This is
Hi,
On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now initialized to 0
instead
of -1 for the
On Tuesday 09 July 2013 12:12 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get
Hi,
On Tue, Jul 09, 2013 at 12:49:10PM +0530, Rajendra Nayak wrote:
Right, but calling serial_omap_restore_context() even when the context
is not lost, should not ideally cause an issue.
it does in one condition. If context hasn't been saved before. And that
can happen in the case of
Hi,
On 07/09/2013 09:42 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now
Hi,
On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 06:37]:
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 01:17]:
I just checked the behavior on my AM335x-EVM.
* Tony Lindgren t...@atomide.com [130708 04:32]:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 06:37]:
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 01:17]:
On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 06:37]:
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 01:17]:
I just
* Rajendra Nayak rna...@ti.com [130708 05:48]:
On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 06:37]:
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
* Bedia,
On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130708 05:48]:
On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 06:37]:
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
Hi Tony,
On Fri, Jul 05,
On Monday 08 July 2013 06:50 PM, Rajendra Nayak wrote:
On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130708 05:48]:
On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 06:37]:
On Fri, Jul 05, 2013 at
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now initialized to 0
instead
of -1 for the serial driver?
You meant initialized to -1, right? There's an additional check for
timeout being 0. Unless i
am missing
On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
I wonder if this is because the timeouts get now initialized to 0
instead
of -1 for the serial driver?
You meant initialized to -1, right? There's an additional check
On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
On 04/07/13 16:14, Mark Jackson wrote:
On 04/07/13 14:25, Mark Jackson wrote:
Our custom AM335x board has been booting just fine under 3.10.0-rc4.
I've just done a git pull to update to 3.10 (now that it's released)
and the board now
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 01:17]:
On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
On 04/07/13 16:14, Mark Jackson wrote:
On 04/07/13 14:25, Mark Jackson wrote:
Our custom AM335x board has been booting just fine under 3.10.0-rc4.
I've just done a git pull to
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 01:17]:
I just checked the behavior on my AM335x-EVM. Current mainline boots fine
provided I don't use earlyprintk. The offending patch [1] in this case is
the one
that
On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
Hi Tony,
On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
* Bedia, Vaibhav vaibhav.be...@ti.com [130705 01:17]:
I just checked the behavior on my AM335x-EVM. Current mainline boots fine
provided I don't use earlyprintk.
On 04/07/13 14:25, Mark Jackson wrote:
Our custom AM335x board has been booting just fine under 3.10.0-rc4.
I've just done a git pull to update to 3.10 (now that it's released)
and the board now hangs.
Before I start trying to bisect the issue, does anyone have an clues ?
Okay ... I've
On 04/07/13 16:14, Mark Jackson wrote:
On 04/07/13 14:25, Mark Jackson wrote:
Our custom AM335x board has been booting just fine under 3.10.0-rc4.
I've just done a git pull to update to 3.10 (now that it's released)
and the board now hangs.
Before I start trying to bisect the issue, does
42 matches
Mail list logo
