On Fri, Oct 18, 2013 at 04:20:09PM -0500, Rob Herring wrote:
> On 10/18/2013 02:32 PM, Michael Bohan wrote:
> > My preference is probably straight libfdt calls, but if others
> > think that unpacking is a better solution, I'm able to go that
> > route as well. My onl
On Fri, Oct 18, 2013 at 07:38:04PM +0100, Mark Rutland wrote:
Hi Mark,
> On Fri, Oct 18, 2013 at 01:44:07AM +0100, Guenter Roeck wrote:
> > On 10/17/2013 04:51 PM, Michael Bohan wrote:
> > > On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> > >> O
On Fri, Oct 18, 2013 at 09:30:32AM -0700, David Daney wrote:
> On 10/18/2013 08:57 AM, Rob Herring wrote:
> [...]
> >
> >Unflattening is definitely the right
> >direction to go here.
> >
>
> I wonder if that is really true.
>
> The device tree in question is very short lived, and used to control
On Thu, Oct 17, 2013 at 05:44:07PM -0700, Guenter Roeck wrote:
> On 10/17/2013 04:51 PM, Michael Bohan wrote:
> >On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> >>Still, what prevents you from unflattening it and just using the
> >>normal device tree f
On Wed, Oct 16, 2013 at 09:54:27PM -0700, Guenter Roeck wrote:
> On 10/16/2013 05:27 PM, Michael Bohan wrote:
> >My motivation is actually to use the fdt format as a firmware.
> >I have a requirement to express driver metadata that's loadable
> >from the filesystem. This
On Wed, Oct 16, 2013 at 04:39:03PM -0700, David Daney wrote:
> On 10/16/2013 04:27 PM, Michael Bohan wrote:
> >Ever since the following commit, libfdt has been available for
> >usage in the kernel:
> >
> > commit ab25383983fb8d7786696f5371e75e79c3e9a405
&
to modules so that they may be used
from device drivers.
Change-Id: I7f540b7cf860c4be414e32ce183be5268b2ae6af
Signed-off-by: Michael Bohan
---
lib/fdt.c |6 ++
lib/fdt_ro.c | 28
lib/fdt_rw.c | 13 +
lib/fdt_sw.c |9 +
lib
On 4/18/2013 2:40 AM, Thomas Gleixner wrote:
On Wed, 10 Apr 2013, Michael Bohan wrote:
When switching to a new cpu_base in switch_hrtimer_base(), we
briefly enable preemption by unlocking the cpu_base lock in two
places. During this interval it's possible for the running thread
to be sw
Here are a couple of hrtimer bug fixes related to preemption.
Michael Bohan (2):
hrtimer: Consider preemption when migrating hrtimer cpu_bases
hrtimer: Prevent enqueue of hrtimer on dead CPU
kernel/hrtimer.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
--
The Qualcomm
mer_base().
Another possibility is to disable preemption across the whole of
switch_hrtimer_base. This looks suboptimal since preemption
would be disabled while waiting for lock(s).
Signed-off-by: Michael Bohan
---
kernel/hrtimer.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
prevent this scenario, verify that the CPU corresponding to
the new cpu_base is indeed online before selecting it in
hrtimer_switch_base(). If it's not online, fallback to using the
base of the current CPU.
Signed-off-by: Michael Bohan
---
kernel/hrtimer.c |3 ++-
1 files changed, 2
Commit-ID: 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0
Gitweb: http://git.kernel.org/tip/84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0
Author: Michael Bohan
AuthorDate: Tue, 19 Mar 2013 19:19:25 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 26 Mar 2013 21:34:57 +0100
hrtimer: Don&#
se() ...
... raw_spin_lock_init(&cpu_base->lock)
raw_spin_unlock(&cpu_base->lock) ...
Signed-off-by: Michael Bohan
---
kernel/hrtimer.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtime
13 matches
Mail list logo
