Re: [PATCH 0/6] Generic PWM API implementation
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. Since *everything* boils down to one or more signal lines, your argument leads directly to Linux having no native hardware interface except GPIOs. Not ... practical. ;) The difference being that PWMs cannot do input, and has additional capabilities (can be programmed with a signal; not just on/off/tristate) If you want to combine PWM with something else ... timers would be a better target. They're both fundamentally about periodic phenomena. And quite a lot of timers support PWM output modes... (A generic interface to hardware timers is lacking, too.) What is the reason for bringing in an entirely new framework instead of extending the GPIO API or gpiolib? I'm not too excited about having two entirely different frameworks for what basically boils down to numbered signal pins. You seem to mis-understand what PWM is all about, then. The whole point of a PWM is to set up a periodic activity that will run without CPU intervention. GPIOs, on the other hand, are packaged for manual bit twiddling. While it's possible to create low-speed implementations of serial protocols using GPIOs (like 2-wire/I2C, one-wire, and various SPI variants), those are explicitly the high-overhead (and low performance) substitutes, to be used only when native hardware isn't available (or is broken etc). For example you won't often get 40 Mbit/sec SPI if you are bitbanging over GPIOs ... and if you do, it won't leave much CPU horsepower for much of anything else. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
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 applications where that jitter is enough to preclude using this kind of PWM. I get the feeling that some of the Linux folk seeing this PWM thing are not very cognizant of such issues ... they've not had to use PWM to do anything where the jitter matters. (Not that I have; but I know that such apps are a motivation for most of the PWM hardware on microcontrollers. A few PWMs plus some sensors, hall effect or QEI or whatever; then you get a motor controller.) - Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 things so much simpler. Really, what is the problem providing this trivial panic-note capability, where user-space can give the kernel a small buffer, and ask the kernel to print this buffer at the oops/panic time. Very simple and elegant, and just solves the problem. Why perversions with time-stamps, separate storages are needed? IOW, you suggest a complicated approach, and demand explaining why we do not go for it. Simply because it is unnecessarily complex. I don't think it's a complicated approach we are talking of a system log like syslog with a temporal information, nothing more. 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-levelling. This is not that simple. And then I have match oops to the userspace environment prints, using I guess timestamps, which is also about complications in userspace. This patch solves the problem gracefully, and I'd rather demand you to point what is the technical problem with the patches. Simply because I think that we should avoid to include in the kernel things we can do in a simply way at user space level. If it is much easier to have in the kernel, then this argument does not work, IMHO. I think this patch is well done but it's one of the patches that are solutions for embedded only, but it's only my opinion. Also IMHO, but having embedded-only things is not bad at all. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 environment stuff to go together, at once. This makes things so much simpler. Really, what is the problem providing this trivial panic-note capability, where user-space can give the kernel a small buffer, and ask the kernel to print this buffer at the oops/panic time. Very simple and elegant, and just solves the problem. Why perversions with time-stamps, separate storages are needed? IOW, you suggest a complicated approach, and demand explaining why we do not go for it. Simply because it is unnecessarily complex. I don't think it's a complicated approach we are talking of a system log like syslog with a temporal information, nothing more. 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-levelling. This is not that simple. And then I have match oops to the userspace environment prints, using I guess timestamps, which is also about complications in userspace. This patch solves the problem gracefully, and I'd rather demand you to point what is the technical problem with the patches. Simply because I think that we should avoid to include in the kernel things we can do in a simply way at user space level. If it is much easier to have in the kernel, then this argument does not work, IMHO. I think this patch is well done but it's one of the patches that are solutions for embedded only, but it's only my opinion. Also IMHO, but having embedded-only things is not bad at all. 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. Eric -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Generic PWM API implementation
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 GPIO driver supports the PWM function, great. If not, then it returns -EINVAL. Heck, I'll even got a driver right now that I'd use it with. I'm more than happy to help code it up even. I think the appropriate thing to do in such cases is to reimplement the GPIO driver at its lowest level to provide both GPIO API and PWM API interfaces. In my way of thinking, such hardware is a kind of multi-function device and it should be treated that way. No need to expose that multi-functionality to the user unless necessary. The odd case to me is the concept of timed GPIO, as in the Android kernels. I see the timing capability as a convenience feature that could be realized by adding timers to the GPIO interface (as they did), or by having a one-shot PWM channel. I'm not really comfortable with either as an interface concept, however, because it just doesn't... feel right. :) b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Generic PWM API implementation
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 AA25 please! No, I don't know who SCL1 is nor where AA25 is. I'll be waiting. :) b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Generic PWM API implementation
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 doesn't fit into a GPIO framework. Since *everything* boils down to one or more signal lines, your argument leads directly to Linux having no native hardware interface except GPIOs. Not ... practical. ;) Wait. Isn't that what Ubicom's chips do? :) If you want to combine PWM with something else ... timers would be a better target. They're both fundamentally about periodic phenomena. And quite a lot of timers support PWM output modes... (A generic interface to hardware timers is lacking, too.) True, and I have code (not yet published) to support a couple of timer/counter peripherals under the PWM interface. So for that functionality at least, I don't think a more generic or standalone API is necessary. I don't know how to define a generic interface for the counter a.k.a. input capture behavior of such devices, though. Still an unsolved problem, but I don't think it will be a part of the PWM API. It's a different metaphor. GPIOs, on the other hand, are packaged for manual bit twiddling. While it's possible to create low-speed implementations of serial protocols using GPIOs (like 2-wire/I2C, one-wire, and various SPI variants), those are explicitly the high-overhead (and low performance) substitutes, to be used only when native hardware isn't available (or is broken etc). And when using GPIO to generate I2C or SPI signals, you don't do it through the GPIO interface--- you do it through the I2C or SPI interface, and a driver behind that API talks to the GPIO API or to a different driver if you change your mind. Same idea for the PWM API. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
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. Very, very good point. The jitter can be quite low (100's of usecs) on a 200 MHz ARM9 chip, in fact, but you'll eat your battery alive if it's a portable device. And the jitter will also destroy your waveform at high or low duty cycles. There are lots of applications where that jitter is enough to preclude using this kind of PWM. I get the feeling that some of the Linux folk seeing this PWM thing are not very cognizant of such issues ... they've not had to use PWM to do anything where the jitter matters. (Not that I have; but I know that such apps are a motivation for most of the PWM hardware on microcontrollers. A few PWMs plus some sensors, hall effect or QEI or whatever; then you get a motor controller.) For some definitions of motor controller. :) You might even be able to use a GPIO-as-PWM signal to feed an R/C servo positioner, but the jitter there will be very visual when it occurs. Dimming control of LEDs and incandescent lamps can be very forgiving of jitter, but I was thinking more along the lines of make this LED blink faster or slower when I came up with the implementation. b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Generic PWM API implementation
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 Grant talks about wanting such things, and if he can deliver it, more power to him. 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 AA25 please! No, I don't know who SCL1 is nor where AA25 is. I'll be waiting. What? You're saying that I've got to take three other connections at the same time? And cut these other two calls? No, I only wanted to make that one call ... :) -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 handling wear-levelling. This is not that simple. And then I have match oops to the userspace environment prints, using I guess timestamps, which is also about complications in userspace. Indeed my suggestion was to use a persistent ram, not difficult to use. This patch solves the problem gracefully, and I'd rather demand you to point what is the technical problem with the patches. Simply because I think that we should avoid to include in the kernel things we can do in a simply way at user space level. If it is much easier to have in the kernel, then this argument does not work, IMHO. I think this patch is well done but it's one of the patches that are solutions for embedded only, but it's only my opinion. Also IMHO, but having embedded-only things is not bad at all. In the past other patches are not accepted in main line for this, maybe you'll be luckier. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 the wheel--if I can use something already present, I will. However, I'm not clear about how much of the problem I'm addressing will be solved by using a kdump hook. If I understand correctly, you'd still need a pseudo-file somewhere to actually get the data from user space to kernel space. *Then* you could use a kdump hook to transfer the data to flash or some memory area that will be retained across boots. Is this the approach to which you were referring? If so, I have a couple more questions: 1. In what ways would this be better than, say, a panic_notifier? 2. Where would you suggest tying in? (Particularly since not all architectures currently support kdump) Eric David VL -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 works. I'm a big fan of avoiding reinvention of the wheel--if I can use something already present, I will. However, I'm not clear about how much of the problem I'm addressing will be solved by using a kdump hook. If I understand correctly, you'd still need a pseudo-file somewhere to actually get the data from user space to kernel space. *Then* you could use a kdump hook to transfer the data to flash or some memory area that will be retained across boots. Is this the approach to which you were referring? If so, I have a couple more questions: 1. In what ways would this be better than, say, a panic_notifier? A couple of ways. - You are doing the work in a known good kernel instead of the kernel that just paniced for some unknown reason. - All of the control logic is in user space (not the kernel) so you can potentially do something as simple as date logfile to get the date. 2. Where would you suggest tying in? (Particularly since not all architectures currently support kdump) No changes are needed kernel side. You just need an appropriate kernel and initrd for your purpose. All of the interesting architectures support kexec, and if an architecture doesn't it isn't hard to add. The architecture specific part is very simple. A pain to debug initially but very simple. Eric -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 user space support. All in a hook that is already present and already works. ... 1. In what ways would this be better than, say, a panic_notifier? A couple of ways. - You are doing the work in a known good kernel instead of the kernel that just paniced for some unknown reason. - All of the control logic is in user space (not the kernel) so you can potentially do something as simple as date logfile to get the date. I think I see better what you're suggesting--passing the info to a kdump kernel and having it do whatever it wants. I don't think I want to do this, but I haven't used any of the kexec() stuff, so I may be missing the point. Some more context: My application is an embedded one, and one of the big things I need to do after a failure is to bring up a fully functional kernel ASAP. Once I have that kernel, I process all of the crash data in user space concurrently with running my main application. Because I'm embedded, I'm very limited in how much crash data I can save over a reboot, how much I can store, and how much I can send to a central collection point. This is good, since it doesn't take up a lot of resources, but core dumps are out of the question. As I understand kdump, I would also need to have a second kernel in memory to do the kdump work. It wouldn't need to be as big is the kernel that failed, but it would still require a significant amount of memory. On an embedded system, the idle memory may be a luxury we can't afford. I think this makes a kdump-based solution difficult, but if it can meet my requirements, I'd much rather use it (I've been following kdump since it's inception quite a few years ago, but it hasn't seemed a good match for embedded Linux). Does this still sound like a good match? 2. Where would you suggest tying in? (Particularly since not all architectures currently support kdump) No changes are needed kernel side. You just need an appropriate kernel and initrd for your purpose. I think I must still be missing something. I have dynamic data that I want to preserve as I reboot from a failed kernel to a fresh new kernel. By the time the fresh kernel starts init, the dynamic data (IP addresses, MAC addresses) has been re-written with new values. This is why I'm trying to preserve, but I may be running without disk or flash. This patch doesn't preserve the data, but it gets it into the kernel so that it can be preserved. At present, I'm preserving the data in a panic_notifier function, but I am not wedded to that. At present, the data will be copied to a section of memory retained across boots, but I know others will want to write to flash. All of the interesting architectures support kexec, and if an architecture doesn't it isn't hard to add. The architecture specific part is very simple. A pain to debug initially but very simple. I use MIPS processors, and it looks like it is supported. So long as it's stable, I'm happy to use it. Eric David VL -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
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 support. All in a hook that is already present and already works. I'm a big fan of avoiding reinvention of the wheel--if I can use something already present, I will. However, I'm not clear about how much of the problem I'm addressing will be solved by using a kdump hook. If I understand correctly, you'd still need a pseudo-file somewhere to actually get the data from user space to kernel space. *Then* you could use a kdump hook to transfer the data to flash or some memory area that will be retained across boots. Is this the approach to which you were referring? If so, I have a couple more questions: 1. In what ways would this be better than, say, a panic_notifier? A couple of ways. - You are doing the work in a known good kernel instead of the kernel that just paniced for some unknown reason. - All of the control logic is in user space (not the kernel) so you can potentially do something as simple as date logfile to get the date. 2. Where would you suggest tying in? (Particularly since not all architectures currently support kdump) No changes are needed kernel side. You just need an appropriate kernel and initrd for your purpose. All of the interesting architectures support kexec, and if an architecture doesn't it isn't hard to add. The architecture specific part is very simple. A pain to debug initially but very simple. As much as I like kexec, it loses on memory footprint by about 100x. It's not appropriate for all use cases, especially things like consumer-grade wireless access points and phones. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
