Re: MFD device driver on top of UART/RS232

2015-11-16 Thread Sascha Hauer 
Hi Andrey,

+Cc NeilBrown 

On Mon, Nov 16, 2015 at 07:24:58PM +0300, Andrey Vostrikov wrote:
> Hi,
> 
> I have an embedded system with microcontroller connected via
> UART/RS232 port. This microcontroller implements several low-level
> functions that need to be exposed as device drivers in other
> subsystems (watchdog, LEDs, HWMON, firmware read/write).
> 
> I checked many drivers implemented in the kernel, searched through
> mail list archives and it looks like there are three different ways to
> solve this task:
> A) most of the devices that are connected using UART have user space
> program that configures and manages it (either directly or with help
> of dedicated line discipline, SLIP, SL-CAN, etc)
> B) serio - mostly used for input devices
> C) direct use of UART port taking control from serial_core.
> 
> The best match I have found so far is MFD driver for Atmel
> Microcontroller on iPaq h3xxx (drivers/mfd/ipaq-micro.c) that follows
> concept "C)"

There's also D) TTY slave device support: https://lkml.org/lkml/2015/3/18/40

Unfortunately this hasn't made it to mainline yet and it seems the
parties lost interest after some lengthy discussion of device tree phandles
vs. subnodes, but I think this is what you're looking for.

Sascha

-- 
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: [GIT PULL] Generic PWM Device API

2011-02-28 Thread Sascha Hauer 
On Sun, Feb 27, 2011 at 09:38:38PM -0600, Bill Gatliff wrote:
 Andrew, Linus:
 
 
 The git repository described in the following pull request implements
 a generic PWM device driver API.  This API is intended to eventually
 supercede the existing PWM device drivers, but during a migration
 period will coexist peacefully with them.

Sorry for the late answer, but it took some time to read the patches
again.

Is it a good idea to have to APIs for the same thing in the kernel?
The old API has users whereas the new API has none. How can we migrate
from one API to the other when for example the backlight pwm driver
depends on the old API, SoC level drivers implement the old API, but
the atmel pwm driver is only available for the new API?

Sascha


-- 
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 v3: 1/3] PWM: Implement a generic PWM framework

2011-02-16 Thread Sascha Hauer 
On Mon, Feb 14, 2011 at 10:56:57AM -0600, Bill Gatliff wrote:
 Sascha:
 
 
 Keep the great comments coming!  My replies inlined below.
 
 On Mon, Feb 14, 2011 at 2:03 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
  The gpio framework does this with 'export', and it does exactly what you
  need: Make sure that a gpio is not used by both the kernel and
  userspace. Unlike the pwm api this does not give the impression that a
  gpio is owned by a specific process.
 
 The gpio framework doesn't provide a way for applications to know that
 a pin is already exported and in use by another process, either.
 Unless you stipulate that the only way to know that a pin ISN'T
 already in use by another process is that it isn't already exported.
 But the check-then-export procedure is a test-then-act, which is
 non-atomic.  So two applications can attempt to export the pin for
 themselves, and both risk actually thinking that they got it.

The discussion started with me saying that the requesting process may
die and the kernel has no way to clean up the requested resources (pwm).
You responded that you want to make sure that there is no resource
conflict between the kernel and userspace. Now we are at two userspace
processes again. We are drawing circles.

What should a userspace process do if it finds the pwm requested by
another process (which may be already dead)? Free it and request it
again when -f is supplied? I think that if you want resource management
then you have to implement a /dev interface. I don't think that's
necessary though.

 
 [Actually, I take the above back; prior to clicking send I checked
 export_store in gpiolib.c, and it looks like the export will fail for
 one application if two attempt to export simultaneously.  That leaves
 just the namespace question.]
 
 In my implementation, a process merely reads from the request
 attribute; if the pid it gets back is its own, then it knows that it
 now has the (albeit advisory) lock on the device.  That's atomic (or
 at least it's supposed to be, there may be bugs left in my code :) ).
 Maybe the whole concept I have implemented is flawed, and I'm willing
 to accept a failed experiment if that's what it really is.  Sounds
 like you might think that it actually is.

There are two things I really don't like about this. First is reading
a sysfs entry should not alter the system state. Second is the kernel
should only grant resources it can claim back when the process dies.

 
 The namespace for PWMs is more complex than with GPIO pins, though,
 and I'm not sure I would ever be comfortable with integer enumerations
 of PWM devices; hardware usually dictates that specific functions are
 tied to specific PWM devices, regardless of the order in which said
 devices are registered in the system across kernel builds and/or
 releases.
 
 The complexity of the namespace for PWM devices makes it convenient
 for users to have a reference to the names of available devices.  The
 entries in /sys/class/pwm provide this list.
 
 What I'm getting to is this.  I think we need to have a list of PWM
 devices present in a system available under /sys/class/pwm at all
 times, not just when those devices have been exported to users.  If
 you accept that, and you also accept the need for a mechanism for
 applications to provide notification that they are now exerting
 control over a PWM device, how would you prefer the interface for that
 mechanism look?
 
 My answer to that question is the current code.  I'd love to hear other 
 answers!
 
  A single pwm_set(int period_ns, int duty_ns, int polarity) would do.
 
 ... except when you want to change only one of those three parameters.
  Which is all you would be able to do if you provide period_ns,
 duty_ns, and polarity attributes to userspace.

A pwm user can store the actual values for period_ns/duty_ns in his
private data and can leave the values constant it does not want to
change. I consider a sysfs driver a pwm being a pwm user also.

 
 But then look at it from the backend.  Are you going to force driver
 authors to implement a multitude of functions for the different
 permutations of arguments?

What multitude of arguments are you talking about? With my proposed
version of pwm_set() a driver only has to parse three arguments.

 That would be redundant work, which I
 decided to put into the PWM API itself so that it wouldn't appear over
 and over again in driver code.
 
  Arguably this function is by definition non atomic because it will
  always take effect during the next period and not in the current one.
  If it takes effect during the current period it means that the current
  period will be interrupted which renders your pwm useless for motors.
 
 Agreed.  But some hardware, like the Atmel PWMC, have double-buffered
 registers.  So they do the handoff at the end of the period
 themselves.  Other hardware, like GPIO pins, force you do to the
 handoff manually.  But the PWM API looks the same to users in both
 cases

Re: New fast(?)-boot results on ARM

2009-08-20 Thread Sascha Hauer 
On Wed, Aug 19, 2009 at 06:20:13PM +0200, Dirk Behme wrote:

 Yes, correct. The copying itself is between 'copy' and 'done' so it
 takes about 0.4s.

 What's the size of the uncompressed kernel copied here?

 The image is about 2.8MB, but I copied the whole partition of 3MB
 because with raw images you can't detect the image size.

 With 3MB copied in ~0.4s you get ~8MB/s. This really depends on your HW, 
 but I would think with standard NOR flashes you should be able to do at 
 least two (three?) times better. Have you already checked the memory (NOR 
 flash) timings configured in your SoC?

It's NAND flash, so there's not much timing to optimize. What's
interesting about this is that the kernel NAND driver is much slower
than the one in U-Boot. Looking at it it turned out that the kernel
driver uses interrupts to wait for the controller to get ready.
Switching this to polling nearly doubles the NAND performance. UBI
mounts much faster now and this cuts off another few seconds from the
boot process :)

Sascha


-- 
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: New fast(?)-boot results on ARM

2009-08-19 Thread Sascha Hauer 
On Tue, Aug 18, 2009 at 05:31:42PM +0200, Dirk Behme wrote:
 Sascha Hauer wrote:
 On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
 Hi,

 On Thu, Aug 13, 2009 at 05:33:26PM +0200, Robert Schwebel wrote:
 On Thu, Aug 13, 2009 at 08:28:26AM -0700, Arjan van de Ven wrote:
 That's bad :-) So there is no room for improvement any more in our
 ARM boot sequences ...
 on x86 we're doing pretty well ;-)
 On i.MX27 (400 MHz ARM926EJ-S) we currently need 7 s, measured from
 power-on through the kernel up to starting init. This is with

 - no delay in u-boot-v2
 - rootfs on NAND (UBIFS)
 - quiet
 - precalculated loops-per-jiffy
 - zImage kernel instead of uImage
 Here's a little video of our demo system booting:
 http://www.youtube.com/watch?v=xDbUnNsj0cI

 As you can see there, it needs about 15 s from the release of the reset 
 button
 up to the moment where the application shows it's Qt 4.5.2 based GUI (which 
 is
 when we fade over from the initial framebuffer to the final one, in order to
 hide the qt application startup noise).

 And below is the boot log (after turning quiet off again). The numbers are
 the timestamp and the delta to the last timestamp, measured on the 
 controlling
 PC by looking at the serial console output. The ptx_ts script starts when 
 the
 regexp was found, so the numbers start basically in the moment when 
 u-boot-v2
 has initialized the system up to the point where we can see something.

 Result:

 - 2.4 s up from u-boot to the end of Uncompressing Linux
 - 300 ms until ubifs initialization starts
 - 3.7 s for ubifs, until mounted root

 So we basically have 7 s for the kernel. The rest is userspace, which hasn't
 seen much optimization yet, other than trying to start the GUI application 
 as
 early as possible, while doing all other init stuff in parallel. Adding 
 quiet
 brings us another 300 ms.

 That's factor 70 away from the 110 ms boot time Tim has talked about some 
 days
 ago (and he measured on an ARM cpu which had almost half the speed of this
 one), and I'm wondering what we can do to improve the boot time.

 Robert

 r...@thebe:~$ microcom | ptx_ts U-Boot 2.0.0-rc9
 [ 13.522625]   0.043189
 [ 13.546627]   0.024002 OSELAS(R)-phyCORE-trunk 
 (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
 [ 13.558613]   0.011986
 [ 13.690643]   0.132030_ ___    _
 [ 13.690731]   0.88  _ __ | |__  _   _ / ___/ _ \|  _ \| |
 [ 13.698595]   0.007864 | '_ \| '_ \| | | | |  | | | | |_) |  _|
 [ 13.698654]   0.59 | |_) | | | | |_| | |__| |_| |  _ | |___
 [ 13.702581]   0.003927 | .__/|_| |_|\__, |\\___/|_| \_\_|
 [ 13.706573]   0.003992 |_|  |___/
 [ 13.706622]   0.49
 [ 13.725043]   0.018421
 [ 14.742608]   1.017565

 I made some changes suggested in this thread:

 - enable MMU in the bootloader
 - use assembler optimized memcpy/memset in the bootloader
 - start an uncompressed image
 - disable IP autoconfiguration in the Kernel
 - use lpj= command line parameter
 - use static device nodes instead of udev
 - skip some init scripts
 - made the kernel smaller (I do not have both configs handy, so I do not
   know what exactly I changed)

 Already looks much better:

 [  0.05]   0.05 U-Boot 2.0.0-rc10-00241-g3f10fe9-dirty (Aug 18 
 2009 - 13:29:25)
 [  0.26]   0.21
 [  0.41]   0.15 Board: Phytec phyCORE-i.MX27
 [  0.54]   0.13 cfi_probe: cfi_flash base: 0xc000 size: 
 0x0200
 [  0.67]   0.13 NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 
 (ST Micro NAND 64MiB 1,8V 8-bit)
 [  0.80]   0.13 im...@imxfb0: i.MX Framebuffer driver
 [  0.92]   0.12 dma_alloc: 0xa6f56e40 0x1000
 [  0.000105]   0.13 dma_alloc: 0xa6f57088 0x1000
 [  0.000118]   0.13 dev_protect: currently broken
 [  0.000129]   0.11 Using environment in NOR Flash
 [  0.000141]   0.12 initialising PLLs
 [  0.128972]   0.128831 Malloc space: 0xa6f0 - 0xa7f0 (size 16 MB)
 [  0.128995]   0.23 Stack space : 0xa6ef8000 - 0xa6f0 (size 32 kB)
 [  0.129008]   0.13 running /env/bin/init...
 [  0.224963]   0.095955
 [  0.224984]   0.21 Hit any key to stop autoboot:  0
 [  0.224999]   0.15 copy
 [  0.592964]   0.367965 done
 [  0.652010]   0.059046 Linux version 2.6.31-rc4-4-g05786f8-dirty 
 (s...@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #206 PREEMPT 
 Tue Aug 18 14:08:51 CEST 2009

 So, this are ~0.6 s in boot loader and kernel copy until kernel starts, 
 correct?

Yes, correct. The copying itself is between 'copy' and 'done' so it
takes about 0.4s.


 What's the size of the uncompressed kernel copied here?

The image is about 2.8MB, but I copied the whole partition of 3MB
because with raw images you can't detect the image size.


 Btw.: I tried to summarize some hints given in this thread in

 http://elinux.org/Boot_Time#Boot_time_check_list

Nice work!

Regards
  Sascha

-- 
Pengutronix e.K

Re: New fast(?)-boot results on ARM

2009-08-18 Thread Sascha Hauer 
On Fri, Aug 14, 2009 at 07:02:28PM +0200, Robert Schwebel wrote:
 Hi,
 
 On Thu, Aug 13, 2009 at 05:33:26PM +0200, Robert Schwebel wrote:
  On Thu, Aug 13, 2009 at 08:28:26AM -0700, Arjan van de Ven wrote:
That's bad :-) So there is no room for improvement any more in our
ARM boot sequences ...
  
   on x86 we're doing pretty well ;-)
 
  On i.MX27 (400 MHz ARM926EJ-S) we currently need 7 s, measured from
  power-on through the kernel up to starting init. This is with
 
  - no delay in u-boot-v2
  - rootfs on NAND (UBIFS)
  - quiet
  - precalculated loops-per-jiffy
  - zImage kernel instead of uImage
 
 Here's a little video of our demo system booting:
 http://www.youtube.com/watch?v=xDbUnNsj0cI
 
 As you can see there, it needs about 15 s from the release of the reset button
 up to the moment where the application shows it's Qt 4.5.2 based GUI (which is
 when we fade over from the initial framebuffer to the final one, in order to
 hide the qt application startup noise).
 
 And below is the boot log (after turning quiet off again). The numbers are
 the timestamp and the delta to the last timestamp, measured on the controlling
 PC by looking at the serial console output. The ptx_ts script starts when the
 regexp was found, so the numbers start basically in the moment when u-boot-v2
 has initialized the system up to the point where we can see something.
 
 Result:
 
 - 2.4 s up from u-boot to the end of Uncompressing Linux
 - 300 ms until ubifs initialization starts
 - 3.7 s for ubifs, until mounted root
 
 So we basically have 7 s for the kernel. The rest is userspace, which hasn't
 seen much optimization yet, other than trying to start the GUI application as
 early as possible, while doing all other init stuff in parallel. Adding 
 quiet
 brings us another 300 ms.
 
 That's factor 70 away from the 110 ms boot time Tim has talked about some days
 ago (and he measured on an ARM cpu which had almost half the speed of this
 one), and I'm wondering what we can do to improve the boot time.
 
 Robert
 
 r...@thebe:~$ microcom | ptx_ts U-Boot 2.0.0-rc9
 [ 13.522625]   0.043189
 [ 13.546627]   0.024002 OSELAS(R)-phyCORE-trunk 
 (PTXdist-1.99.svn/2009-08-06T08:37:25+0200)
 [ 13.558613]   0.011986
 [ 13.690643]   0.132030_ ___    _
 [ 13.690731]   0.88  _ __ | |__  _   _ / ___/ _ \|  _ \| |
 [ 13.698595]   0.007864 | '_ \| '_ \| | | | |  | | | | |_) |  _|
 [ 13.698654]   0.59 | |_) | | | | |_| | |__| |_| |  _ | |___
 [ 13.702581]   0.003927 | .__/|_| |_|\__, |\\___/|_| \_\_|
 [ 13.706573]   0.003992 |_|  |___/
 [ 13.706622]   0.49
 [ 13.725043]   0.018421
 [ 14.742608]   1.017565

I made some changes suggested in this thread:

- enable MMU in the bootloader
- use assembler optimized memcpy/memset in the bootloader
- start an uncompressed image
- disable IP autoconfiguration in the Kernel
- use lpj= command line parameter
- use static device nodes instead of udev
- skip some init scripts
- made the kernel smaller (I do not have both configs handy, so I do not
  know what exactly I changed)

Already looks much better:

[  0.05]   0.05 U-Boot 2.0.0-rc10-00241-g3f10fe9-dirty (Aug 18 2009 - 
13:29:25)
[  0.26]   0.21
[  0.41]   0.15 Board: Phytec phyCORE-i.MX27
[  0.54]   0.13 cfi_probe: cfi_flash base: 0xc000 size: 0x0200
[  0.67]   0.13 NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST 
Micro NAND 64MiB 1,8V 8-bit)
[  0.80]   0.13 im...@imxfb0: i.MX Framebuffer driver
[  0.92]   0.12 dma_alloc: 0xa6f56e40 0x1000
[  0.000105]   0.13 dma_alloc: 0xa6f57088 0x1000
[  0.000118]   0.13 dev_protect: currently broken
[  0.000129]   0.11 Using environment in NOR Flash
[  0.000141]   0.12 initialising PLLs
[  0.128972]   0.128831 Malloc space: 0xa6f0 - 0xa7f0 (size 16 MB)
[  0.128995]   0.23 Stack space : 0xa6ef8000 - 0xa6f0 (size 32 kB)
[  0.129008]   0.13 running /env/bin/init...
[  0.224963]   0.095955
[  0.224984]   0.21 Hit any key to stop autoboot:  0
[  0.224999]   0.15 copy
[  0.592964]   0.367965 done
[  0.652010]   0.059046 Linux version 2.6.31-rc4-4-g05786f8-dirty 
(s...@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #206 PREEMPT Tue 
Aug 18 14:08:51 CEST 2009
[  0.652030]   0.20 CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), 
cr=00053177
[  0.652044]   0.14 CPU: VIVT data cache, VIVT instruction cache
[  0.652057]   0.13 Machine: phyCORE-i.MX27
[  0.652069]   0.12 Memory policy: ECC disabled, Data cache writeback
[  0.652082]   0.13 Built 1 zonelists in Zone order, mobility grouping 
on.  Total pages: 32512
[  0.706012]   0.053930 Kernel command line: console=ttymxc0,115200 
earlyprintk lpj=995328 mt9v022.sensor_type=color 
ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0::: ubi.mtd=7 
root=ubi0:root rootfstype=ubifs

Re: flicker free booting

2009-08-03 Thread Sascha Hauer 
On Fri, Jul 31, 2009 at 01:42:35PM -0500, Bill Gatliff wrote:
 Robert Schwebel wrote:
   
 The question I've been looking at is: do sub-second boot times make
 all this a moot point? After all, if you can bring up your graphics
 driver in a fraction of a second and use *it* to display a splash
 screen, it seems like it would meet your need to give almost immediate
 feedback to users that the system is alive.
 

 Yup, that would be cool.

 However, on flash-based systems in the ARM926 / 200...400 MHz class
 (which is still quite common) the boot time up to the point where the
 penguin appears is still about 3...4 s [1] which is too long. So I
 suspect until systems become faster, we'll have no other choice than
 such as scenario.
   

 Could your bootloader pre-initialize the graphics hardware to the same  
 mode that the Linux driver will ultimately select, and then throw up a  
 static graphic?  That would give you some output until the driver itself  
 comes online.

I implemented exactly this for the i.MX framebuffer last week. It works
by looking at the controllers physical screen start address, ioremapping
this address and copying the content to the newly allocated framebuffer.
Currently the driver still reinitilializes the controller with exactly
the same values. We could skip this initialization step depending on a
imxfb.preinitialized=1 command line parameter and read back
resolution/depth from the device in order to fill the fb_info struct.

This approach works good, I just wonder how acceptable it is for
mainline.

The downside of this approach is that we have to add
mem=${physical_mem - 1MB} to the command line.

Sascha

-- 
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