Re: MFD device driver on top of UART/RS232
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
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
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 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 i
Re: [PWM v3: 1/3] PWM: Implement a generic PWM framework
On Fri, Feb 11, 2011 at 12:22:27PM -0600, Bill Gatliff wrote: > Sascha: > > > > The objective of the sysfs request attribute is to prevent > simultaneous uses of a channel in both kernel and user spaces. Same > as with GPIO pins. 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. > > > There is no need for introducing ioctl like interfaces in the kernel. > > You should create the appropriate callbacks instead which is both easier > > to read and easier to implement. > > I disagree. > > The problem with implementing callbacks to do the job of these > configuration flags is trying to come up with an approach that lets > users set multiple parameters at the same time. To achieve what I am > doing with these flags using callbacks, I would need a > pwm_set_period_and_duty_ns(), pwm_set_period_and_duty_and_polarity(), > pwm_set_duty_and_polarity(), and so on. A single pwm_set(int period_ns, int duty_ns, int polarity) would do. 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. > > I'm thinking mostly about DC motor control applications, where you > vary both the period and the duty cycle based on the speed of the > motor. The two values have to change at the same time. > > You might argue that all I need to add, therefore, is a > pwm_set_duty_and_period_ns(). You would be right--- and I can > certainly do that at the API level. But I still want one > configuration entry point into the driver code itself, which means I > still need flags somewhere. > > Why do I want one entry point into drivers? Because at the same time > users want to change single or multiple parameters in one go, the > hardware may prevent doing so simply because it doesn't work that way. So you are prososing an API which does not abstract from the hardware capabilities and does not provide a way to query the hardware capabilities. This means your motor control application will work with one pwm in the background while throwing stack traces with another pwm. Honestly, putting a 'this call might or might not be possible' into API level does not seem to be a good idea to me. How about making all calls to the pwm non atomic? 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
Hi Bill,
Thanks for still working on this.
On Thu, Feb 10, 2011 at 09:53:49AM -0600, Bill Gatliff wrote:
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> new file mode 100644
> index 000..153d455
> --- /dev/null
> +++ b/drivers/pwm/Kconfig
> @@ -0,0 +1,11 @@
> +#
> +# PWM infrastructure and devices
> +#
> +
> +menuconfig GENERIC_PWM
> + tristate "PWM Support"
> + default n
default n is the default and can be removed.
> + help
> + Enables PWM device support implemented via a generic
> + framework. If unsure, say N.
> +
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> new file mode 100644
> index 000..7baa201
> --- /dev/null
> +++ b/drivers/pwm/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Makefile for pwm devices
> +#
> +obj-$(CONFIG_GENERIC_PWM) := pwm.o
> diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c
> new file mode 100644
> index 000..2cad7cd
> --- /dev/null
> +++ b/drivers/pwm/pwm.c
> @@ -0,0 +1,619 @@
> +/*
> + * PWM API implementation
> + *
> + * Copyright (C) 2011 Bill Gatliff
> + * Copyright (C) 2011 Arun Murthy
> + *
> + * This program is free software; you may redistribute and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> + * USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
I can't see anything from platform_device.h being used here.
> +#include
> +
> +static const char *REQUEST_SYSFS = "sysfs";
> +static LIST_HEAD(pwm_device_list);
This is unused.
> +static DEFINE_MUTEX(device_list_mutex);
> +static struct class pwm_class;
> +static struct workqueue_struct *pwm_handler_workqueue;
This is used but never initialized.
> +
> +static int pwm_match_name(struct device *dev, void *name)
> +{
> + return !strcmp(name, dev_name(dev));
> +}
> +
> +static struct pwm_device *__pwm_request(struct pwm_device *p, const char
> *label)
> +{
I think this function should return int.
> + int ret;
> +
> + ret = test_and_set_bit(FLAG_REQUESTED, &p->flags);
> + if (ret) {
> + p = ERR_PTR(-EBUSY);
> + goto done;
> + }
> +
> + p->label = label;
> + p->pid = current->pid;
> +
> + if (p->ops->request) {
> + ret = p->ops->request(p);
> + if (ret) {
> + p = ERR_PTR(ret);
> + clear_bit(FLAG_REQUESTED, &p->flags);
> + goto done;
> + }
> + }
> +
> +done:
> + return p;
> +}
> +
> +static struct pwm_device *__pwm_request_byname(const char *name,
> +const char *label)
> +{
> + struct device *d;
> + struct pwm_device *p;
> +
> + d = class_find_device(&pwm_class, NULL, (char*)name, pwm_match_name);
> + if (!d) {
> + p = ERR_PTR(-EINVAL);
> + goto done;
> + }
> + if (IS_ERR(d)) {
> + p = (struct pwm_device *)d;
> + goto done;
> + }
class_find_device does not return error pointers. Luckily we can get rid
of this horrible cast here.
> +
> + p = __pwm_request(dev_get_drvdata(d), label);
> +
> +done:
> + return p;
> +}
> +
> +struct pwm_device *pwm_request_byname(const char *name, const char *label)
> +{
> + struct pwm_device *p;
> +
> + mutex_lock(&device_list_mutex);
> + p = __pwm_request_byname(name, label);
> + mutex_unlock(&device_list_mutex);
> + return p;
> +}
> +EXPORT_SYMBOL(pwm_request_byname);
> +
> +struct pwm_device *pwm_request(const char *bus_id, int id, const char *label)
> +{
> + char name[256];
> + int ret;
> +
> + if (id == -1)
> + ret = scnprintf(name, sizeof name, "%s", bus_id);
> + else
> + ret = scnprintf(name, sizeof name, "%s:%d", bus_id, id);
> + if (ret <= 0 || ret >= sizeof name)
> + return ERR_PTR(-EINVAL);
> +
> + return pwm_request_byname(name, label);
> +}
> +EXPORT_SYMBOL(pwm_request);
> +
> +void pwm_release(struct pwm_device *p)
> +{
> + mutex_lock(&device_list_mutex);
> +
> + if (!test_and_clear_bit(FLAG_REQUESTED, &p->flags)) {
> + BUG();
> + goto done;
> + }
> +
> + pwm_stop(p);
> + pwm_unsynchronize(p, NULL);
> + pwm_set_handler(p, NULL, NULL);
> +
> + p->label = NULL;
> + p->pid = -1;
> +
> + if (p->ops->release)
> + p->ops->releas
Re: New fast(?)-boot results on ARM
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
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 >> [
Re: New fast(?)-boot results on ARM
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
Re: flicker free booting
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
