On Tue, 2009-11-17 at 16:28 -0800, Eric W. Biederman wrote:
> David VomLehn writes:
>
> > On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> > ...
> >> Why not use the kdump hook? If you handle a kernel panic that way
> >> you get enhanced reliability and full user space suppor
On Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
> David VomLehn writes:
>
> > On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> > ...
> >> Why not use the kdump hook? If you handle a kernel panic that way
> >> you get enhanced reliability and full user space
David VomLehn writes:
> On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
> ...
>> Why not use the kdump hook? If you handle a kernel panic that way
>> you get enhanced reliability and full user space support. All in a hook
>> that is already present and already works.
>
> I'm
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
> Why not use the kdump hook? If you handle a kernel panic that way
> you get enhanced reliability and full user space support. All in a hook
> that is already present and already works.
I'm a big fan of avoiding reinvention
Artem Bityutskiy wrote:
> On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
>> 2009/11/17 Artem Bityutskiy :
>
> We need to store this information of NAND flash. Implementing logs on
> NAND flash is about handling bad blocks, choosing format of records, and
> may be even handling wear-level
On Tuesday 17 November 2009, Bill Gatliff wrote:
> David Brownell wrote:
> >
> > It'd be purely for pinmux.
> >
>
> Ugh. That would be a tough interface to design.
True. That's part of why I object to wanting to combine
it with GPIOs ... or, combine everything else with GPIOs
too (like PWMs)
David Brownell wrote:
> Worth highlighting that this is necessarily a "low quality"
> PWM ... in the sense that it's got lots of jitter because
> of needing CPU intervention in IRQ context, so it's subject
> to delays from both IRQs being blocked and from other timer
> driven activities firing firs
David Brownell wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>
>> I'm concerned about the approach taken here. As I understand it, the
>> PWM signals are very similar to GPIOs in that each PWM device controls
>> an external signal line, just like GPIO lines.
>>
>
> PWM is not GP
David Brownell wrote:
>
> It'd be purely for pinmux.
>
Ugh. That would be a tough interface to design. It makes me think of
an old-time telephone switchboard, with an undefined number of wires and
an equally-undefined number of plugs to insert them into.
"Good morning, Mabel! Give me SCL1 o
Grant Likely wrote:
>
> Common code is a big gain in and of itself.
I completely agree! Which is why I used the GPIO API in my PWM
pseudo-device, along with an hrtimer.
> What I would like to see is the PWM functions added to the GPIO API.
> GPIO drivers can then either implement them or not. I
Artem Bityutskiy writes:
> On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
>> 2009/11/17 Artem Bityutskiy :
>> > Take a look at my mails where I describe different complications we have
>> > in our system. We really want to have an OOPS/panic + our environment
>> > stuff to go together,
Grant Likely wrote:
> Hi Bill
>
> On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff wrote:
>
>> This series implements a Generic PWM Device API, including reference
>> implementations for the Atmel PWMC device, an LED device, and an LED
>> trigger. It is based on linux-2.6.27.
>>
> [...]
>
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
> 2009/11/17 Artem Bityutskiy :
> > Take a look at my mails where I describe different complications we have
> > in our system. We really want to have an OOPS/panic + our environment
> > stuff to go together, at once. This makes things so mu
2009/11/17 Artem Bityutskiy :
> Take a look at my mails where I describe different complications we have
> in our system. We really want to have an OOPS/panic + our environment
> stuff to go together, at once. This makes things so much simpler.
>
> Really, what is the problem providing this trivial
A pair of nit-picks.
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
> @@ -0,0 +1,293 @@
> +/*
> + * panic-note.c
No need to type file name there.
> + *
> + * Allow a blob to be registered with the kernel that will be printed if
> + * the kernel panics.
> + *
>
Hi Marko,
On Sat, 2009-11-14 at 09:28 +0100, Marco Stornelli wrote:
> I think in general the procedure should be: at startup or event (for
> example acquired IP address from DHCP) user applications write in flash
> (better in persistent ram) a log with a tag or a timestamp or something
> like this
Worth highlighting that this is necessarily a "low quality"
PWM ... in the sense that it's got lots of jitter because
of needing CPU intervention in IRQ context, so it's subject
to delays from both IRQs being blocked and from other timer
driven activities firing first.
There are lots of applicatio
On Friday 13 November 2009, Grant Likely wrote:
> Right now, I don't
> see a fundamental difference is between GPIO and PWM pin management.
> It is essentially the same problem, and in many cases PWM pins can
> also be used as GPIOs.
Pin management for a given SoC is going to be r
On Friday 13 November 2009, Grant Likely wrote:
> I'm concerned about the approach taken here. As I understand it, the
> PWM signals are very similar to GPIOs in that each PWM device controls
> an external signal line, just like GPIO lines.
PWM is not GPIO, and doesn't fit into a GPIO framework.
19 matches
Mail list logo
