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
looks
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.kerne
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
---
Hello Felipe,
what about this patch before the previously sent patch 1?
Best
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 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_tar
On 04/24/2015 02:38 PM, Nishanth Menon wrote:
> On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna 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 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 wrote on Thu [2015-Mar-26 00:57:36
> > +0200]:
> > > Add lane-polarity property to endpoint nodes. This essentially tells that
> > > the order
Hi Benoit,
On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote:
> Sakari Ailus 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: Sak
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 i
Sakari Ailus 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
> Acked-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/m
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna 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, "H
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 i
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 becaus
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
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: Uw
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, ple
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 decodi
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:
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:
[ 47
* Felipe Balbi [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 `omap2_gpi
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
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
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
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 / cl
* Rajendra Nayak [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
> Reviewed-by: Kevin Hilman
> Acked-by: Santo
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 t
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 function
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 code
On Fri, Apr 24, 2015 at 4:41 PM, 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)
>>
>> Rajen
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 vari
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
verbos
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
> ---
> Documentation/devicetree/bindings/watchdog/omap-wdt
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/23/2015 04:19 PM, Ulf Hansson wrote:
> On 23 April 2015 at 12:43, wrote:
>> From: Grygorii Strashko
>>
>> The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
>> as result mmc_rescan() could be scheduled and executed at
>> late hibernation restore stages when MMC device is suspend
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 Belloni, Free
On 23 April 2015 at 12:25, Russell King - ARM Linux
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.
Matthijs
--
To unsubscrib
On 23 April 2015 at 10:33, 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 users
> ar
36 matches
Mail list logo
