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.
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
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
2009/11/17 Artem Bityutskiy dedeki...@gmail.com:
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
Artem Bityutskiy dedeki...@gmail.com writes:
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
2009/11/17 Artem Bityutskiy dedeki...@gmail.com:
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
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. If a
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 on
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 GPIO, and
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 first.
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).
But
Artem Bityutskiy wrote:
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
2009/11/17 Artem Bityutskiy dedeki...@gmail.com:
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
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 of
David VomLehn dvoml...@cisco.com 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
On Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
David VomLehn dvoml...@cisco.com 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
On Tue, 2009-11-17 at 16:28 -0800, Eric W. Biederman wrote:
David VomLehn dvoml...@cisco.com 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
14 matches
Mail list logo
