Hi!
> It is very rare to find a current system which is both sufficiently
> resource constrained to want to compile out power management support
> and sufficiently power insensitive to be able to tolerate doing so.
Ok, how much memory do we talk about here?
Lots of embedded systems are AC powere
> Il 06/01/2011 19:22, Luck, Tony ha scritto:
> >> Errata corrige: maybe I used the wrong term, I meant "volatile" instead
> >> of "temporary" information, i.e. I'd like to save this info to re-read
> >> it later but I don't want to store it in flash, a simple log, run-time
> >> information for deb
> On 07/01/2011 22:59, Tony Luck wrote:
> > On Fri, Jan 7, 2011 at 12:30 PM, Marco Stornelli
> > wrote:
> >> constraint). About the errors: pramfs does not maintain file data in the
> >> page caches for normal file I/O, so no writeback, the read/write
> >> operation are done with direct io and the
Hi!
> +But the disk-based fs over non-volatile RAM block driver approach has
> +some drawbacks:
> +
> +1. Complexity of disk-based fs: disk-based filesystems such as ext2/ext3/ext4
> + were designed for optimum performance on spinning disk media, so they
> + implement features such as block gr
>
> 11.02.2010, ? 23:58, Pavel Machek ???(?):
>
> > On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
> >> Pavel Machek wrote:
> >>>> +static void
> >>>> +gpio_pwm_work (struct work_struct *work)
> >>>> +{
> >
> >> +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device
> >> +is stopped before it is released by the API.
> >>
> >
> > free is normally used for something else. Rename to open/close?
> ... or request/release?
Works for me.
> >> +pwm_start(), pwm_stop() -- Turns the PW
On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
> Pavel Machek wrote:
> >> +static void
> >> +gpio_pwm_work (struct work_struct *work)
> >> +{
> >> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> >> +
> >> + if (gp-&g
> +static void
> +gpio_pwm_work (struct work_struct *work)
> +{
> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> +
> + if (gp->active)
> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> + else
> + gpio_direction_output(gp->gpio, g
Hi!
> +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 t
Hi!1
>>> Yes, but in that case you might as well just purchase a coulomb
>>> counter with a built-in accumulator and an I2C/SPI/microwire interface
>>> save yourself some PCB space and cost (maybe)
Hardware is already given.
>> Well, Pavel attempts to implement a "poor man's Coulomb counter" or
On Mon 2009-12-14 12:12:47, Mark Brown wrote:
> On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:
>
> > > actual charger hardware. My main concern here is that battery
> > > performance monitoring has no pressing need to be in kernel and that
> > > p
Hi!
> > > I'm not sure how familiar you are with the issues surrounding trying to
> > > do a voltage to charge mapping for a battery but it's much more complex
> > > than a simple table if you want to get it accurate. There's a lot
> > > of
>
> > Well... current zaurus kernels use _huge_ table t
On Mon 2009-12-14 11:50:24, Mark Brown wrote:
> On Sun, Dec 13, 2009 at 02:19:22PM +0100, Pavel Machek wrote:
>
> > ...but then there are all the systems that rely on /proc/apm
> > emulation, like openembedded popular on sharp zaurus...
>
> OpenEmbedded is a meta-distrib
that internal resistance depends on charge left. Nasty
but probably can be ignored. Then it depends on temperature. Does
anyone have better idea how?
Then... I need a way to measure internal resistance. I know it is in
200mOhm to 400mOhm range, on my device. Is there easy way to measure
it more ac
> One of the things we're facing is Android, which has
> its userspace in plain Java JNI at the end of this link:
> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s
> ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34
> 1faa094c71922946fdab;hb=HEAD
>
>
On Sun 2009-06-28 19:33:02, Marco Stornelli wrote:
> Pavel Machek wrote:
> >>>>> Ah now the write protection is a "needed feature", in your previous
> >>>>> comment you talked about why not use ext2/3...
> >>>>>
> >>&
> >> > Ah now the write protection is a "needed feature", in your previous
> >> > comment you talked about why not use ext2/3...
> >> >
> >> > Marco
> >> >
> >>
> >> Just for your information I tried the same test with pc in a virtual
> >> machine with 32MB of RAM:
> >>
> >> Version 1.03e
> >>> If it loses power when doing atomic rename (to replace config files,
> >>> for example), it's likely that the whole /pramfs/configs/ directory
> >>> will be corrupt, because the rename is writing to the directory inode,
> >>> so you lose access to all names in that directory?
> >>>
> >>> Tha
On Wed 2009-06-24 19:38:37, Marco wrote:
> >>> Pavel Machek wrote:
> >>>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> >>>>> Pavel Machek wrote:
> >>>>>>> block of fast non-volatile RAM that need to access data on it using a
&g
On Wed 2009-06-24 18:49:11, Marco wrote:
> >> Pavel Machek wrote:
> >>> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> >>>> Pavel Machek wrote:
> >>>>>> block of fast non-volatile RAM that need to access data on it using a
> >>>
On Tue 2009-06-23 20:07:23, Marco wrote:
> Pavel Machek wrote:
> > On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> >> Pavel Machek wrote:
> >>>> block of fast non-volatile RAM that need to access data on it using a
> >>>> standard filesytem interface
On Mon 2009-06-22 23:57:53, Pavel Machek wrote:
> On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> > Pavel Machek wrote:
> > >> block of fast non-volatile RAM that need to access data on it using a
> > >> standard filesytem interface."
> > >
> > &
On Mon 2009-06-22 14:50:01, Tim Bird wrote:
> Pavel Machek wrote:
> >> block of fast non-volatile RAM that need to access data on it using a
> >> standard filesytem interface."
> >
> > Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are
>
On Mon 2009-06-22 11:55:04, Tim Bird wrote:
> Pavel Machek wrote:
> > On Mon 2009-06-22 10:31:28, Tim Bird wrote:
> >> Pavel Machek wrote:
> >>> I did not see that in the changelog. If it is not general purpose
> >>> filesystem, it is lot less interes
On Mon 2009-06-22 20:07:06, Marco wrote:
> Pavel Machek wrote:
> > On Mon 2009-06-22 10:31:28, Tim Bird wrote:
> >> Pavel Machek wrote:
> >>>>> How do you handle hard-links, then?
> >>>> Indeed hard-links are not supported :) Due to the design of
On Mon 2009-06-22 10:31:28, Tim Bird wrote:
> Pavel Machek wrote:
> >>> How do you handle hard-links, then?
> >> Indeed hard-links are not supported :) Due to the design of this fs
> >> there are some limitations explained in the documentation as not
> >>
> > How do you handle hard-links, then?
>
> Indeed hard-links are not supported :) Due to the design of this fs
> there are some limitations explained in the documentation as not
> hard-link, only private memory mapping and so on. However this
> limitations don't limit the fs itself because you mu
> >> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
> >>performance on spinning disk media, so they implement features such
> >>as block groups, which attempts to group inode data into a contiguous
> >>set of data blocks to minimize disk seeking when accessing fi
> > Why is an entire filesystem needed, instead of simply a block driver
> > if the ramdisk driver cannot be used?
> >
>
> >From documentation:
>
> "A relatively straight-forward solution is to write a simple block
> driver for the non-volatile RAM, and mount over it any disk-based
> filesystem
Hi!
> Parallelization to improve boot times has been successful enough that race
> conditions now exist between the init_post() open of /dev/console and
> initialization of the console device. When this occurs, opening /dev/console
> fails and any applications inherited from init have no standard
30 matches
Mail list logo
