On Sunday 19 August 2007, Robin Getz wrote:
> On Sun 19 Aug 2007 17:54, David Brownell pondered:
> > On Saturday 18 August 2007, Robin Getz wrote:
> >
> > > I don't see how early/late makes the problem easier/worse to debug. No
> > > matter when you do it - the driver refuses to install (or at
On Sun 19 Aug 2007 17:54, David Brownell pondered:
> On Saturday 18 August 2007, Robin Getz wrote:
>
> > I don't see how early/late makes the problem easier/worse to debug. No
> > matter when you do it - the driver refuses to install (or at least
> > should).
>
> If you arrange to *reliably*
On Saturday 18 August 2007, Robin Getz wrote:
> I don't see how early/late makes the problem easier/worse to debug. No matter
> when you do it - the driver refuses to install (or at least should).
If you arrange to *reliably* detect the pinmux/setup problems by
the time the system starts
On Saturday 18 August 2007, Robin Getz wrote:
I don't see how early/late makes the problem easier/worse to debug. No matter
when you do it - the driver refuses to install (or at least should).
If you arrange to *reliably* detect the pinmux/setup problems by
the time the system starts init
On Sun 19 Aug 2007 17:54, David Brownell pondered:
On Saturday 18 August 2007, Robin Getz wrote:
I don't see how early/late makes the problem easier/worse to debug. No
matter when you do it - the driver refuses to install (or at least
should).
If you arrange to *reliably* detect the
On Sunday 19 August 2007, Robin Getz wrote:
On Sun 19 Aug 2007 17:54, David Brownell pondered:
On Saturday 18 August 2007, Robin Getz wrote:
I don't see how early/late makes the problem easier/worse to debug. No
matter when you do it - the driver refuses to install (or at least
On Fri 17 Aug 2007 18:34, David Brownell pondered:
> On Friday 17 August 2007, Robin Getz wrote:
> > On Fri 17 Aug 2007 14:24, David Brownell pondered:
> > > Just for the record, this is an unusual way to use these calls.
> >
> > That is part of the natural evolution of the kernel isn't it - per
On Fri 17 Aug 2007 18:34, David Brownell pondered:
On Friday 17 August 2007, Robin Getz wrote:
On Fri 17 Aug 2007 14:24, David Brownell pondered:
Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per
James's
On Friday 17 August 2007, Robin Getz wrote:
> On Fri 17 Aug 2007 14:24, David Brownell pondered:
> > Just for the record, this is an unusual way to use these calls.
>
> That is part of the natural evolution of the kernel isn't it - per James's
> keynote at OLS - you release something, and see
>-Original Message-
>From: David Brownell [mailto:[EMAIL PROTECTED]
>
>On Friday 17 August 2007, Hennerich, Michael wrote:
>> What Mike wants to point out is that a external IRQ is first a GPIO
and
>> needs to be configured like an INPUT GPIO and then a specific bit
needs
>> to be set
On Fri 17 Aug 2007 14:24, David Brownell pondered:
> Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how people [ab]use it until
it either grows, evolves,
On Friday 17 August 2007, Hennerich, Michael wrote:
> What Mike wants to point out is that a external IRQ is first a GPIO and
> needs to be configured like an INPUT GPIO and then a specific bit needs
> to be set unmask it as IRQ.
>
> So why not use the GPIO infrastructure to setup this pin as
On Friday 17 August 2007, Mike Frysinger wrote:
> as Michael pointed out, in the Blackfin world we tend to keep things
> very dynamic as we have dev systems which allow for dropping in of
> optional cards at will, so doing this in the bootloader is way too
> inflexible.
That's the tradeoff:
>-Original Message-
>From: David Brownell [mailto:[EMAIL PROTECTED]
>
>On Friday 17 August 2007, Mike Frysinger wrote:
>> On 8/17/07, David Brownell <[EMAIL PROTECTED]> wrote:
>> > ...
>> > Just for the record, this is an unusual way to use these calls.
>> >
>> > Other platforms
On 8/17/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> as Michael pointed out, in the Blackfin world we tend to keep things
> very dynamic as we have dev systems which allow for dropping in of
> optional cards at will, so doing this in the bootloader is way too
> inflexible.
oh, and another
On 8/17/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Friday 17 August 2007, Mike Frysinger wrote:
> > On 8/17/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > > ...
> > > Just for the record, this is an unusual way to use these calls.
> > >
> > > Other platforms completely decouple these
On Friday 17 August 2007, Mike Frysinger wrote:
> On 8/17/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > ...
> > Just for the record, this is an unusual way to use these calls.
> >
> > Other platforms completely decouple these issues from the
> > IRQ infrastructure ... doing the pinmux and gpio
On 8/17/07, David Brownell <[EMAIL PROTECTED]> wrote:
> Again, the patch descriptions need work. This changes the
> IRQ code (to add those labels). $SUBJECT doesn't mention IRQs,
> neither does the description ...
>
>
> On Tuesday 07 August 2007, Bryan Wu wrote:
> > ---
Again, the patch descriptions need work. This changes the
IRQ code (to add those labels). $SUBJECT doesn't mention IRQs,
neither does the description ...
On Tuesday 07 August 2007, Bryan Wu wrote:
> --- a/arch/blackfin/mach-common/ints-priority-dc.c
> +++
Again, the patch descriptions need work. This changes the
IRQ code (to add those labels). $SUBJECT doesn't mention IRQs,
neither does the description ...
On Tuesday 07 August 2007, Bryan Wu wrote:
--- a/arch/blackfin/mach-common/ints-priority-dc.c
+++
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
Again, the patch descriptions need work. This changes the
IRQ code (to add those labels). $SUBJECT doesn't mention IRQs,
neither does the description ...
On Tuesday 07 August 2007, Bryan Wu wrote:
---
On Friday 17 August 2007, Mike Frysinger wrote:
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
...
Just for the record, this is an unusual way to use these calls.
Other platforms completely decouple these issues from the
IRQ infrastructure ... doing the pinmux and gpio claiming
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
On Friday 17 August 2007, Mike Frysinger wrote:
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
...
Just for the record, this is an unusual way to use these calls.
Other platforms completely decouple these issues from the
On 8/17/07, Mike Frysinger [EMAIL PROTECTED] wrote:
as Michael pointed out, in the Blackfin world we tend to keep things
very dynamic as we have dev systems which allow for dropping in of
optional cards at will, so doing this in the bootloader is way too
inflexible.
oh, and another [smallish]
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
On Friday 17 August 2007, Mike Frysinger wrote:
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
...
Just for the record, this is an unusual way to use these calls.
Other platforms completely decouple these
On Friday 17 August 2007, Mike Frysinger wrote:
as Michael pointed out, in the Blackfin world we tend to keep things
very dynamic as we have dev systems which allow for dropping in of
optional cards at will, so doing this in the bootloader is way too
inflexible.
That's the tradeoff:
On Friday 17 August 2007, Hennerich, Michael wrote:
What Mike wants to point out is that a external IRQ is first a GPIO and
needs to be configured like an INPUT GPIO and then a specific bit needs
to be set unmask it as IRQ.
So why not use the GPIO infrastructure to setup this pin as GPIO?
On Fri 17 Aug 2007 14:24, David Brownell pondered:
Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how people [ab]use it until
it either grows, evolves, or
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
On Friday 17 August 2007, Hennerich, Michael wrote:
What Mike wants to point out is that a external IRQ is first a GPIO
and
needs to be configured like an INPUT GPIO and then a specific bit
needs
to be set unmask it as
On Friday 17 August 2007, Robin Getz wrote:
On Fri 17 Aug 2007 14:24, David Brownell pondered:
Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how
From: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/mach-common/ints-priority-dc.c |4 ++--
arch/blackfin/mach-common/ints-priority-sc.c |8
2 files changed, 6
From: Michael Hennerich [EMAIL PROTECTED]
Signed-off-by: Michael Hennerich [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
---
arch/blackfin/mach-common/ints-priority-dc.c |4 ++--
arch/blackfin/mach-common/ints-priority-sc.c |8
2 files changed, 6 insertions(+), 6
32 matches
Mail list logo
