On 23 April 2015 at 12:25, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
And you can't detect whether you're running in secure mode or not.
If not, you get an undefined instruction exception, which you could trap.
This may not be convenient, but can't detect is an overstatement.
On 23 April 2015 at 10:33, Rajendra Nayak rna...@codeaurora.org wrote:
Most users of PM clocks do the exact same thing in runtime callbacks.
Provide default callbacks and cleanup the existing users (keystone/davinci
/omap1/sh)
Rajendra Nayak (5):
PM / clock_ops: Provide default runtime ops
On 22/04/2015 at 19:04:52 -0500, Nishanth Menon wrote :
I fully agree that your patch doesn't change the behaviour for the other
cases you presented and further clean up is to be done in a separate set
of patches.
Sure,
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
On 04/23/2015 04:19 PM, Ulf Hansson wrote:
On 23 April 2015 at 12:43, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late
On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:
Most users of PM clocks do the exact same thing in runtime callbacks.
Provide default callbacks and cleanup the existing users (keystone/davinci
/omap1/sh)
Rajendra Nayak (5):
PM / clock_ops: Provide default runtime ops to
On 04/24/2015 12:54 PM, Suman Anna wrote:
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding
On 04/24/2015 11:21 AM, Jack Mitchell wrote:
I've been fighting for a week with trying to get the IPU booted over
remoteproc on an OMAP4470. I feel like I've got most of the way there
we do not have support for OMAP4470 on git.kernel.org.
If you are interested in TI vendor kernel support,
On 4/23/2015 4:56 PM, Tony Lindgren wrote:
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...
Let's fix the issue by adding inline functions
Hi Jack,
On 24/04/15 19:34, Nishanth Menon wrote:
On 04/24/2015 11:21 AM, Jack Mitchell wrote:
I've been fighting for a week with trying to get the IPU booted over
remoteproc on an OMAP4470. I feel like I've got most of the way there
we do not have support for OMAP4470 on git.kernel.org.
On Fri, Apr 24, 2015 at 4:41 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:
Most users of PM clocks do the exact same thing in runtime callbacks.
Provide default callbacks and cleanup the existing users (keystone/davinci
/omap1/sh)
On 04/24/2015 02:56 AM, Tony Lindgren wrote:
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...
Let's fix the issue by adding inline
* Rajendra Nayak rna...@codeaurora.org [150423 01:34]:
USE_PM_CLK_RUNTIME_OPS is introduced so we don't repeat the same code
to do runtime_suspend and runtime_resume across users of PM clocks.
Use it to remove the boilerplate code.
Signed-off-by: Rajendra Nayak rna...@codeaurora.org
Hi,
On Fri, Apr 24, 2015 at 11:48:31AM +0200, Uwe Kleine-König wrote:
Instead of (partly) open coding it use the core function. As a side
effect the timeout-sec devicetree property is used now.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
On 04/24/2015 02:54 AM, Tony Lindgren wrote:
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old
On 4/23/2015 4:54 PM, Tony Lindgren wrote:
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can just
remove all old code
On Fri, Apr 24, 2015 at 11:48:33AM +0200, Uwe Kleine-König wrote:
Instead of using an over-long expression involving the ?: operator use
an if and intead of an else branch rely on the fact that the data
structure was allocated using devm_kzalloc. This also allows to put the
used helper
On 4/24/2015 7:41 AM, Rafael J. Wysocki wrote:
On Thursday, April 23, 2015 02:03:08 PM Rajendra Nayak wrote:
Most users of PM clocks do the exact same thing in runtime callbacks.
Provide default callbacks and cleanup the existing users (keystone/davinci
/omap1/sh)
Rajendra Nayak (5):
PM /
On Fri, Apr 24, 2015 at 10:20:50PM +0200, Uwe Kleine-König wrote:
ti,hwmods doesn't belong into the compatible section but is a property
on it's own. Also reformat the section of required properties to match the
usual style of dt binding documents.
Signed-off-by: Uwe Kleine-König
I've been fighting for a week with trying to get the IPU booted over
remoteproc on an OMAP4470. I feel like I've got most of the way there
but I don't get a response from the first kick after boot. Has anyone
ever had the IPU booted on mainline? Dmesg from remoteproce boot is as
below:
[
On Thu, Apr 23, 2015 at 04:56:22PM -0700, Tony Lindgren wrote:
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to `omap2_gpio_prepare_for_idle'
...
Let's fix the issue
On Thu, Apr 23, 2015 at 04:54:17PM -0700, Tony Lindgren wrote:
At some point with all the GPIO clean-up we've broken the
MPUIO interrupts. Those are just a little bit different from
the GPIO interrupts, so we can fix it up just by setting
different irqchip functions for it. And then we can
* Felipe Balbi ba...@ti.com [150424 09:14]:
On Thu, Apr 23, 2015 at 04:56:22PM -0700, Tony Lindgren wrote:
We currently get all kinds of errors building the omap gpio driver
as a module starting with:
undefined reference to `omap2_gpio_resume_after_idle'
undefined reference to
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:
On Fri, Apr 24, 2015 at 11:48:32AM +0200, Uwe Kleine-König wrote:
This way only a single allocation is needed (per device). Also this
stops making use of watchdog_{set,get}_drvdata.
And this is better because ... ?
Nothing against it, just feels like this commit log needs a little more
Hello Felipe,
On Fri, Apr 24, 2015 at 09:44:48AM -0500, Felipe Balbi wrote:
On Fri, Apr 24, 2015 at 11:48:32AM +0200, Uwe Kleine-König wrote:
This way only a single allocation is needed (per device). Also this
stops making use of watchdog_{set,get}_drvdata.
And this is better because ...
On Fri, Apr 24, 2015 at 09:42:59AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Apr 24, 2015 at 11:48:31AM +0200, Uwe Kleine-König wrote:
Instead of (partly) open coding it use the core function. As a side
effect the timeout-sec devicetree property is used now.
Signed-off-by: Uwe
On 24/04/15 19:34, Nishanth Menon wrote:
On 04/24/2015 11:21 AM, Jack Mitchell wrote:
I've been fighting for a week with trying to get the IPU booted over
remoteproc on an OMAP4470. I feel like I've got most of the way there
we do not have support for OMAP4470 on git.kernel.org.
If you are
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-{0x0300, DEBUG SOURCE,},
-{0x0, HOST
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few
On 04/24/2015 02:38 PM, Nishanth Menon wrote:
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-
Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]:
Add lane-polarity property to endpoint nodes. This essentially tells that
the order of the differential signal wires is inverted.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart
On 24/04/15 19:34, Nishanth Menon wrote:
On 04/24/2015 11:21 AM, Jack Mitchell wrote:
I've been fighting for a week with trying to get the IPU booted over
remoteproc on an OMAP4470. I feel like I've got most of the way there
we do not have support for OMAP4470 on git.kernel.org.
If you are
Hi Benoit,
On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote:
Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]:
Add lane-polarity property to endpoint nodes. This essentially tells that
the order of the differential signal wires is inverted.
Sakari Ailus sakari.ai...@iki.fi wrote on Fri [2015-Apr-24 22:49:33 +0300]:
Hi Benoit,
On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote:
Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36
+0200]:
Add lane-polarity property to endpoint nodes. This
On 04/24/2015 02:54 PM, Suman Anna wrote:
On 04/24/2015 02:38 PM, Nishanth Menon wrote:
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data
ti,hwmods doesn't belong into the compatible section but is a property
on it's own. Also reformat the section of required properties to match the
usual style of dt binding documents.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Hello Felipe,
what about this patch before the
36 matches
Mail list logo
