Re: Super Fast Boot of Embedded Linux: 300 ms from boot loader to shell

2011-04-14 Thread Matthieu CASTET
Hi,

Marco Stornelli a écrit :
 Il 13/04/2011 16:53, Constantine Shulyupin ha scritto:
 Thank you Marco for your feedback. I've added summary of used
 optimization method:
 • Reduction of kernel and filesystem size
 • Kernel features: naked boot, initrd without compression
 • Optimization of NAND flash interface in boot loader
 • Boot time was measured with utility tstamp
 • You can find more detailed list of methods at http://elinux.org/Boot_Time
 • Techniques for improving embedded Linux startup time, presentation:
 http://www.makelinux.com/emb/fastboot/MontaVista

 Actually, detailed implementations of optimization methods are
 described in numerous documents.
 
 I really know. I was talking about *your* optimization method, but if I 
 well understand you've just applied a list of well known methods.

Not to say such case are not interesting : loading a linux kernel with only a
serial driver, a ramdisk and a shell as init doesn't reflect reality.

In real product what you want if fast user interaction (sound, mounting big
filesystem with user data, lcd display, ...)


Matthieu
--
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: Super Fast Boot of Embedded Linux: 300 ms from boot loader to shell

2011-04-14 Thread Robert Schwebel
On Thu, Apr 14, 2011 at 09:43:35AM +0200, Matthieu CASTET wrote:
 Not to say such case are not interesting : loading a linux kernel with
 only a serial driver, a ramdisk and a shell as init doesn't reflect
 reality.

 In real product what you want if fast user interaction (sound,
 mounting big filesystem with user data, lcd display, ...)

Well, it depends on the application. In the automotive box I've shown
the barebox based boot optimizations for in my ELC-E talk, the task is
to get CAN communication running in  200 ms. For that kind of
application it's useful to be in userspace as fast as possible, just in
order to have one socket-can application running, and everything else
comes later.

rsc
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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: [PWM v9 1/3] PWM: Implement a generic PWM framework

2011-04-14 Thread Grant Likely
Hi Bill,

Comments below...

[cc'ing Greg  Kay regarding the use of device class (comment near the bottom)]

On Thu, Mar 31, 2011 at 9:59 PM, Bill Gatliff b...@billgatliff.com wrote:
 Updates the existing PWM-related functions to support multiple
 and/or hotplugged PWM devices, and adds a sysfs interface.
 Moves the code to drivers/pwm.

 For now, this new code can exist alongside the current PWM
 implementations; the existing implementations will be migrated
 to this new framework as time permits.  Eventually, the current
 PWM implementation will be deprecated and then expunged.

 Signed-off-by: Bill Gatliff b...@billgatliff.com
 ---
  Documentation/pwm.txt   |  276 ++
  MAINTAINERS             |    8 +
  drivers/Kconfig         |    2 +
  drivers/Makefile        |    2 +
  drivers/pwm/Kconfig     |   10 +
  drivers/pwm/Makefile    |    4 +
  drivers/pwm/pwm.c       |  580 
 +++
  include/linux/pwm/pwm.h |  140 
  8 files changed, 1022 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/pwm.txt
  create mode 100644 drivers/pwm/Kconfig
  create mode 100644 drivers/pwm/Makefile
  create mode 100644 drivers/pwm/pwm.c
  create mode 100644 include/linux/pwm/pwm.h

 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
 new file mode 100644
 index 000..6a0c95d
 --- /dev/null
 +++ b/Documentation/pwm.txt
 @@ -0,0 +1,276 @@
 +                       Generic PWM Device API
 +
 +                          February 7, 2011
 +                            Bill Gatliff
 +                        b...@billgatliff.com
 +
 +
 +
 +The code in drivers/pwm and include/linux/pwm/ implements an API for
 +applications involving pulse-width-modulation signals.  This document
 +describes how the API implementation facilitates both PWM-generating
 +devices, and users of those devices.

Good documentation!

 +
 +
 +Motivation
 +
 +The primary goals for implementing the generic PWM API are to
 +consolidate the various PWM implementations within a consistent and
 +redundancy-reducing framework, and to facilitate the use of
 +hotpluggable PWM devices.
 +
 +Previous PWM-related implementations within the Linux kernel achieved
 +their consistency via cut-and-paste, but did not need to (and didn't)
 +facilitate more than one PWM-generating device within the system---
 +hotplug or otherwise.  The Generic PWM Device API might be most
 +appropriately viewed as an update to those implementations, rather
 +than a complete rewrite.
 +
 +
 +Challenges
 +
 +One of the difficulties in implementing a generic PWM framework is the
 +fact that pulse-width-modulation applications involve real-world
 +signals, which often must be carefully managed to prevent destruction
 +of hardware that is linked to those signals.  A DC motor that
 +experiences a brief interruption in the PWM signal controlling it
 +might destructively overheat; it could suddenly change speed, losing
 +synchronization with a sensor; it could even suddenly change direction
 +or torque, breaking the mechanical device connected to it.
 +
 +(A generic PWM device framework is not directly responsible for
 +preventing the above scenarios: that responsibility lies with the
 +hardware designer, and the application and driver authors.  But it
 +must to the greatest extent possible make it easy to avoid such
 +problems).
 +
 +A generic PWM device framework must accommodate the substantial
 +differences between available PWM-generating hardware devices, without
 +becoming sub-optimal for any of them.
 +
 +Finally, a generic PWM device framework must be relatively
 +lightweight, computationally speaking.  Some PWM users demand
 +high-speed outputs, plus the ability to regulate those outputs
 +quickly.  A device framework must be able to keep up with such
 +hardware, while still leaving time to do real work.
 +
 +The Generic PWM Device API is an attempt to meet all of the above
 +requirements.  At its initial publication, the API was already in use
 +managing small DC motors, sensors and solenoids through a
 +custom-designed, optically-isolated H-bridge driver.
 +
 +
 +Functional Overview
 +
 +The Generic PWM Device API framework is implemented in
 +include/linux/pwm/pwm.h and drivers/pwm/pwm.c.  The functions therein
 +use information from pwm_device and pwm_config structures to invoke
 +services in PWM peripheral device drivers.  Consult
 +drivers/pwm/atmel-pwmc.c for an example driver for the Atmel PWMC
 +peripheral.
 +
 +There are two classes of adopters of the PWM framework:
 +
 +  Users -- those wishing to employ the API merely to produce PWM
 +  signals; once they have identified the appropriate physical output
 +  on the platform in question, they don't care about the details of
 +  the underlying hardware
 +
 +  Driver authors -- those wishing to bind devices that can generate
 +  PWM signals to the Generic PWM Device API, so that the services of
 +  those devices become available to users. 

Re: [PWM v9 1/3] PWM: Implement a generic PWM framework

2011-04-14 Thread Greg KH
On Thu, Apr 14, 2011 at 01:49:27PM -0600, Grant Likely wrote:
  +static struct class pwm_class = {
  +       .name           = pwm,
  +       .owner          = THIS_MODULE,
  +       .dev_attrs      = pwm_dev_attrs,
  +};
 
 From my understanding, class is deprecated.  I believe you should be
 using bus_type directly now.  Check with Greg and Kay.

Yes, that is correct, please don't create new classes if at all
possible.  And this code looks like it is fine to use a bus_type.

thanks,

greg k-h
--
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