headers
Rob Savoye | 1 Apr 2007 01:09

Re: Flash video works on X0

MBurns wrote:

> I wonder if the Watch & Listen activity (that uses Helix) would be able to
> help out here. I know there is a gecko plug-in being worked on that could
> play videos in embedded html pages. Since Helix supports flash 4.0 and
> 8.0video playback, I'm wondering if there is any tie in we can make
> use with for Gnash. Or am I just walking off on a tangent?

  Gnash supports Flash v7 and some v8, so I'm not sure if helix would
help any. Gnash is also an NSAPI (geeko) plugin.

> Per the emails today, have you tried this with build 368 and seen any
> difference/improvements/problems?

  I just reflashed my X0, and I'm testing the default package first,
then I'll try my recent builds. So far it works, but I have to try it
with all the test cases. Then I'll try my build that supports video.

	- rob -
Permalink | Reply | 0 comments |
headers
Jordan Crouse | 1 Apr 2007 03:01
Picon
Favicon

Re: Power Mangement Interfaces

On 31/03/07 11:57 -0700, David Brownell wrote:
> The other part is the platform code.  On embedded hardware that's usually
> just calling device_init_wakeup() before registering the platform devices,
> and supporting enable_irq_wake().  On x86 that gets messy; ACPI is there,
> and PCI initialization can't set device_init_wakeup() because of conflicts
> with how PPC initializes PCI.

enable_irq_wake() looks like it integrates very well with the AT91, since
it seems that there is a 1:1 mapping of interrupts to wakeup sources.  The
story is much more muddled for x86 - there is no direct mapping of interrupts
to wakeup sources, and the PIC has nothing to do with handling wake events.

On the Geode, we have 17 possible wake sources, all of which are ORed
together to form the SCI interrupt. Some of the events, like the RTC,
UART, and USB wakeup sources are associated with devices that have their
own interrupts, but there is no correlation between the RTC interrupt, 
for example, and enabling it as a wakeup source.  It seems overly complex
to try to map these to individual interrupts, and certainly seems wasteful
to get the PIC involved in something it just doesn't understand.

> As in "echo enabled > /sys/devices/.../power/wakeup" (to get the default),
> or "echo disabled > ..." to disable it.  For PCs, with ACPI, that involves
> two patches I just posted to the RTC list (and CC'd Len on), and replacing
> the ancient/legacy/ACPI-only /proc/acpi/alarm interface.

The link is here for the interested:

http://groups.google.com/group/rtc-linux/browse_thread/thread/ae7fe3436e01e7fa

This looks very good, and is pretty close to what I was proposing.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Brownell | 1 Apr 2007 05:01

Re: Power Mangement Interfaces

On Saturday 31 March 2007 6:01 pm, Jordan Crouse wrote:
> On 31/03/07 11:57 -0700, David Brownell wrote:
> > The other part is the platform code.  On embedded hardware that's usually
> > just calling device_init_wakeup() before registering the platform devices,
> > and supporting enable_irq_wake().  On x86 that gets messy; ACPI is there,
> > and PCI initialization can't set device_init_wakeup() because of conflicts
> > with how PPC initializes PCI.
> 
> enable_irq_wake() looks like it integrates very well with the AT91, since
> it seems that there is a 1:1 mapping of interrupts to wakeup sources. 

The same is true for every embedded CPU I've had reason to look at.

> The 
> story is much more muddled for x86 - there is no direct mapping of interrupts
> to wakeup sources, and the PIC has nothing to do with handling wake events.

Right.  Plus there often seems to be an assumption that some "embedded
(micro)controller" (EC) manages system bringup/wakeup/runtime.

> On the Geode, we have 17 possible wake sources, all of which are ORed

What are those?  You mentioned four before.  (RTC alarm, two GPIOs,
and the power button.)  I'd guess various PCI devices can also issue
wakeups.  (And if USB is one of them, up to 126 USB devices hooked
up to each USB host controller!)

> together to form the SCI interrupt. Some of the events, like the RTC,
> UART, and USB wakeup sources are associated with devices that have their
> own interrupts, but there is no correlation between the RTC interrupt,
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Watlington | 1 Apr 2007 05:18
Favicon

MPP port selection


The choice of port for the MPP server (953) was unfortunate.
It is also used by BIND9's remote control interface (rndc).

Can we get this changed ASAP ?
How about a less useful service, like gopher or timed ?
Or a non-priviledged port ?

And while we are at it, can we use a less common address for the
ANYCAST ?   Something like  172.31.252.252.   I don't want to have
routing conflicts with some ISP assigning 192.168.x.x to the WAN.

wad
Permalink | Reply | 2 comments |
headers
Dan Williams | 1 Apr 2007 06:46
Picon
Favicon

Re: MPP port selection

On Sat, 2007-03-31 at 21:07 -0700, Luis Carlos Cobo Rus wrote:
> Hi John,
> 
> there's nothing special about the port or anycast IP, we only need
> them to be consistent between MPPs and clients.

Somebody figure it out and let me know :)

Dan

> On 3/31/07, John Watlington <wad <at> laptop.org> wrote:
> >
> > The choice of port for the MPP server (953) was unfortunate.
> > It is also used by BIND9's remote control interface (rndc).
> >
> > Can we get this changed ASAP ?
> > How about a less useful service, like gopher or timed ?
> > Or a non-priviledged port ?
> >
> > And while we are at it, can we use a less common address for the
> > ANYCAST ?   Something like  172.31.252.252.   I don't want to have
> > routing conflicts with some ISP assigning 192.168.x.x to the WAN.
> >
> > wad
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel <at> laptop.org
> > http://mailman.laptop.org/mailman/listinfo/devel
(Continue reading)

Permalink | Reply | 0 comments |
headers
MARTIN WOODHOUSE | 1 Apr 2007 08:12
Gravatar

Test 'hello'

Dear All
 
Just 'hello' --- I am just trying to see whether I can reach this group, which I have just joined(inexpertly, since I cannot yet program for LINUX.   Borland C for MSDOS, yes; but Linux, no).
 
Best wishes, therefore,
 
Martin
 
Dr. Martin C. Woodhouse
_______________________________________________
Devel mailing list
Devel <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/devel
Permalink | Reply | 0 comments |
headers
Jordan Crouse | 1 Apr 2007 18:56
Picon
Favicon

Re: Power Mangement Interfaces

A few of your comments made me wonder if I haven't been clear enough -
despite this being an x86 platform, we are not using ACPI for power 
management, for a variety of reasons, including the fact that we have
our own open source firmware and a very specific hardware platform
So, for better or worse, we are implementing a new power management
manger.  Here is the code: 

http://dev.laptop.org/git.do?p=olpc-2.6;a=blob;h=e6e19ac32a881be962db7190f2cb460e9f60a9da;hb=powermgmt;f=arch/i386/kernel/olpc-pm.c

On 31/03/07 20:01 -0700, David Brownell wrote:
> > The 
> > story is much more muddled for x86 - there is no direct mapping of interrupts
> > to wakeup sources, and the PIC has nothing to do with handling wake events.
> 
> Right.  Plus there often seems to be an assumption that some "embedded
> (micro)controller" (EC) manages system bringup/wakeup/runtime.

Or, the southbridge, or in the case of the OLPC platform, both.

> 
> > On the Geode, we have 17 possible wake sources, all of which are ORed
> 
> What are those?  You mentioned four before.  (RTC alarm, two GPIOs,
> and the power button.)  I'd guess various PCI devices can also issue
> wakeups.  (And if USB is one of them, up to 126 USB devices hooked
> up to each USB host controller!)

The silicon can handle wakeups from RTC, a sleep button, a power button, 
8 GPIO groups, the USB controller (covering any and all USB events),
UART1, UART2, SMbus and the PIC.

OLPC really only cares about 4 of those, because our only sleep state
is ~S3, and the PIC, smbus, UARTs and USB are off in S3.  We also only
have the power button, and all the rest of the wakeup sources come from
the GPIOs.

> > This looks very good, and is pretty close to what I was proposing.  
> > Replace the acpi_*_event() calls with a generic pm_ infrastructure, and
> 
> Inside ACPI ... why?

I'm not saying inside ACPI - I'm saying at the driver level.  Something
like this (where name could be a string like ACPI does, but it would be
more portable if it was a #define'ed value).

pm_set_event(name) {
   pm_ops->set_event(name, 1);
}

pm_clear_event(name) {
   pm_ops->set_event(name, state);
}

And then each subsystem that defines a struct pm_ops adds a set_event() that
does the right thing.

In OLPC's case  we would do something like this:

olpc_pm_set_event(name, state) {
	switch(name) {
		case PM_WAKEUP_RTC:
			pm1_wakeup |= (1 << 9);
			break;

			...
	}
}

And so forth.  Like the AT91, we enable the wakeup events prior to
suspending. I'm willing to bet that other PM methods like ACPI
could pick this up pretty quickly too. 

> > add hooks to the pm_ops for each individual PM system to handle the wakeups
> > in whatever way they see fit, and we're there.  It would be slightly more
> > complex for AT91 and friends to match this (since they have the advantage
> > of a 1:1 mapping right now), but in the long run, I think everybody would
> > benefit.
> 
> I guess I don't see why this isn't already sufficiently generic ...
> 
> As a rule, all those embedded drivers are platform-specific and have
> no need for more than a few enable_irq_wake() calls, in addition to
> whatever controller setup and clock management they do.  Since they
> can't be very portable, they don't need to generalize such stuff.

enable_irq_wake() just doesn't work for x86, unfortunately.  It seems
to me to be more logical to move the wakeup intelligence to the PM subsystem,
and then let that code distribute it to where it is needed.  In the case
of x86, the logic would stay in the PM method, for other processors, it 
might involve a call to the interrupt mapper.

> And for PCI based things, pci_enable_wake() encapsulates everything
> that needs doing.  Not that ACPI actually *does* anything yet!  But
> the stuff that writing /proc/acpi/wakeup enables should happen in that
> routine ... and eventually PCI runtime wake events should work too.
> (So:  no drivers would ever call ACPI directly, and they already have
> the generic call that ACPI should hook.)
> 
> That seems to cover most drivers in Linux, without a need for any
> new generic PM infrastructure.  Did I overlook something important?

No, I don't think so - we're very close on agreeing here.  I just don't know
if enable_irq_wake() is the best way to provide the generic call.  Moving
it into the PM infrastructure seems the best way to handle everybody
equally, regardless of the relative intelligence or stupidity of their 
hardware implementation.

> > The only other issue then, is how we could define and manage wakeup events
> > for events that aren't associated with specific devices, like power button
> > and lid events.  We'll need some way to control those somewhere in sysfs -
> > if not in /sys/power/wakeup like I had proposed, then somewhere under the
> > platform or system hierarchy .
> 
> I see /sys/devices/acpi_system:00/button_power:00 on this system; and
> /sys/devices/acpi_system:00/device:00/PNP0C0D:00 has path \_SB_.LID_ ...
> such device nodes already exist, even though they're not really hooked
> up to anything much.  Notably, their "wakeup" state is not initialized.
> 
> And while it seems that the three USB controllers on this system show up
> as /sys/devices/acpi_system:00/device:00/PNP0A03:00/device:{01,02,03} I
> have no idea which one is /sys/devices/pci0000:00/0000:00:02.2 versus
> 0000:00:02.1 or 0000:00:02.0 ... I know that USB0 is device:01 and so
> on (by reading "path"), but associating one with a PCI device seems to
> involve pure guesswork.

I guess we'll probably have to do something similar for our OLPC PM code
- but thats the sort of platform specific fragmentation thing I was trying
to avoid.

Jordan

--

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>
Permalink | Reply | 1 comment |
headers
Jens Axboe | 1 Apr 2007 21:09
Picon

suspend/resume timings

Hi,

I took a look at the time spent doing a suspend and resume cycle. In
general things go pretty fast, most devices handle it really quickly.
USB is a bit slow (~100 msec), but I ignored that since apparently there
are already people working on fixing USB suspend (functionality, speed
of course comes second).

The slowest parts are the keyboard and mouse. psmouse takes ~570 msec to
resume alone, and the keyboard is no speed daemon at ~269 msecs. Looking
at the psmouse first, by far the majority of the time is spend resetting
the device (drivers/input/mouse/olpc.c:olpc_reconnect() ->
psmouse_reset()). A quick test works fine for me without the reset, but
that may not be a sound approach. Perhaps deferring a reset to IFF
olpc_get_model() fails would be more safe?

I'll be playing some more with the timings and testing over the next
week, do let me know if there's something more urgent in suspend/resume
area that needs attention.

The kernel used was current olpc-2.6.

diff --git a/drivers/input/mouse/olpc.c b/drivers/input/mouse/olpc.c
index 5f813f5..d2df132 100644
--- a/drivers/input/mouse/olpc.c
+++ b/drivers/input/mouse/olpc.c
 <at>  <at>  -351,12 +351,19  <at>  <at>  static int olpc_poll(struct psmouse *psmouse)
 static int olpc_reconnect(struct psmouse *psmouse)
 {
 	struct olpc_data *priv = psmouse->private;
+	struct olpc_model_info *info;
 	int mode;

-	psmouse_reset(psmouse);
-
-	if (!(priv->i = olpc_get_model(psmouse)))
-		return -1;
+	/*
+	 * defer reset to if olpc_get_model() fails, it's quite a time eater
+	 */
+	priv->i = olpc_get_model(psmouse);
+	if (!priv->i) {
+		psmouse_reset(psmouse);
+		priv->i = olpc_get_model(psmouse);
+		if (!priv->i)
+			return -1;
+	}

 	mode = olpc_find_mode(psmouse);
 	if (mode < 0)

--

-- 
Jens Axboe
Permalink | Reply | 7 comments |
headers
Jim Gettys | 1 Apr 2007 21:19
Favicon
Gravatar

Re: suspend/resume timings


The keyboard is left powered up during suspend: we shouldn't need to
reset it at all (except on power up).  This is so you can touch a key or
the keypad and get the CPU back instanty.
                             - Jim

On Sun, 2007-04-01 at 21:09 +0200, Jens Axboe wrote:
> Hi,
> 
> I took a look at the time spent doing a suspend and resume cycle. In
> general things go pretty fast, most devices handle it really quickly.
> USB is a bit slow (~100 msec), but I ignored that since apparently there
> are already people working on fixing USB suspend (functionality, speed
> of course comes second).
> 
> The slowest parts are the keyboard and mouse. psmouse takes ~570 msec to
> resume alone, and the keyboard is no speed daemon at ~269 msecs. Looking
> at the psmouse first, by far the majority of the time is spend resetting
> the device (drivers/input/mouse/olpc.c:olpc_reconnect() ->
> psmouse_reset()). A quick test works fine for me without the reset, but
> that may not be a sound approach. Perhaps deferring a reset to IFF
> olpc_get_model() fails would be more safe?
> 
> I'll be playing some more with the timings and testing over the next
> week, do let me know if there's something more urgent in suspend/resume
> area that needs attention.
> 
> The kernel used was current olpc-2.6.
> 
> diff --git a/drivers/input/mouse/olpc.c b/drivers/input/mouse/olpc.c
> index 5f813f5..d2df132 100644
> --- a/drivers/input/mouse/olpc.c
> +++ b/drivers/input/mouse/olpc.c
>  <at>  <at>  -351,12 +351,19  <at>  <at>  static int olpc_poll(struct psmouse *psmouse)
>  static int olpc_reconnect(struct psmouse *psmouse)
>  {
>  	struct olpc_data *priv = psmouse->private;
> +	struct olpc_model_info *info;
>  	int mode;
>  
> -	psmouse_reset(psmouse);
> -
> -	if (!(priv->i = olpc_get_model(psmouse)))
> -		return -1;
> +	/*
> +	 * defer reset to if olpc_get_model() fails, it's quite a time eater
> +	 */
> +	priv->i = olpc_get_model(psmouse);
> +	if (!priv->i) {
> +		psmouse_reset(psmouse);
> +		priv->i = olpc_get_model(psmouse);
> +		if (!priv->i)
> +			return -1;
> +	}
>  
>  	mode = olpc_find_mode(psmouse);
>  	if (mode < 0)
> 
--

-- 
Jim Gettys
One Laptop Per Child
Permalink | Reply | 2 comments |
headers
Jens Axboe | 1 Apr 2007 21:58
Picon

shrinking memory consumptions

Hi,

Looking over the (rarely used) block/scsi bits, we can free up ~150kb of
kernel memory by reducing the memory tied down in memory pools. These
are pre-allocated and basically only ever used in OOM conditions, and
for some no longer valid reason they are sized way to aggressively. We
only really need 1 backup, this patch plays it safe and allocates 2.

I'll push this patch locally upstream as well, perhaps we can use it
meanwhile. 150kb is quite a bit of memory, when all you have is 128MiB
:-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4c2471e..d812123 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
 <at>  <at>  -867,7 +867,7  <at>  <at>  static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 		goto bad4;
 	}

-	cc->bs = bioset_create(MIN_IOS, MIN_IOS, 4);
+	cc->bs = bioset_create(MIN_IOS, MIN_IOS);
 	if (!cc->bs) {
 		ti->error = "Cannot allocate crypt bioset";
 		goto bad_bs;
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
index 4eb73d3..8bdc8a8 100644
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
 <at>  <at>  -60,7 +60,7  <at>  <at>  static int resize_pool(unsigned int new_ios)
 		if (!_io_pool)
 			return -ENOMEM;

-		_bios = bioset_create(16, 16, 4);
+		_bios = bioset_create(16, 16);
 		if (!_bios) {
 			mempool_destroy(_io_pool);
 			_io_pool = NULL;
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 3668b17..11a98df 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
 <at>  <at>  -1012,7 +1012,7  <at>  <at>  static struct mapped_device *alloc_dev(int minor)
 	if (!md->tio_pool)
 		goto bad3;

-	md->bs = bioset_create(16, 16, 4);
+	md->bs = bioset_create(16, 16);
 	if (!md->bs)
 		goto bad_no_bioset;

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9f7482d..05d79af 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
 <at>  <at>  -31,7 +31,7  <at>  <at> 

 
 #define SG_MEMPOOL_NR		ARRAY_SIZE(scsi_sg_pools)
-#define SG_MEMPOOL_SIZE		32
+#define SG_MEMPOOL_SIZE		2

 struct scsi_host_sg_pool {
 	size_t		size;
diff --git a/fs/bio.c b/fs/bio.c
index 7618bcb..693940d 100644
--- a/fs/bio.c
+++ b/fs/bio.c
 <at>  <at>  -28,7 +28,7  <at>  <at> 
 #include <linux/blktrace_api.h>
 #include <scsi/sg.h>		/* for struct sg_iovec */

-#define BIO_POOL_SIZE 256
+#define BIO_POOL_SIZE 2

 static struct kmem_cache *bio_slab __read_mostly;

 <at>  <at>  -38,7 +38,7  <at>  <at>  static struct kmem_cache *bio_slab __read_mostly;
  * a small number of entries is fine, not going to be performance critical.
  * basically we just need to survive
  */
-#define BIO_SPLIT_ENTRIES 8	
+#define BIO_SPLIT_ENTRIES 2
 mempool_t *bio_split_pool __read_mostly;

 struct biovec_slab {
 <at>  <at>  -1120,7 +1120,7  <at>  <at>  struct bio_pair *bio_split(struct bio *bi, mempool_t *pool, int first_sectors)
  * create memory pools for biovec's in a bio_set.
  * use the global biovec slabs created for general use.
  */
-static int biovec_create_pools(struct bio_set *bs, int pool_entries, int scale)
+static int biovec_create_pools(struct bio_set *bs, int pool_entries)
 {
 	int i;

 <at>  <at>  -1128,9 +1128,6  <at>  <at>  static int biovec_create_pools(struct bio_set *bs, int pool_entries, int scale)
 		struct biovec_slab *bp = bvec_slabs + i;
 		mempool_t **bvp = bs->bvec_pools + i;

-		if (pool_entries > 1 && i >= scale)
-			pool_entries >>= 1;
-
 		*bvp = mempool_create_slab_pool(pool_entries, bp->slab);
 		if (!*bvp)
 			return -ENOMEM;
 <at>  <at>  -1161,7 +1158,7  <at>  <at>  void bioset_free(struct bio_set *bs)
 	kfree(bs);
 }

-struct bio_set *bioset_create(int bio_pool_size, int bvec_pool_size, int scale)
+struct bio_set *bioset_create(int bio_pool_size, int bvec_pool_size)
 {
 	struct bio_set *bs = kzalloc(sizeof(*bs), GFP_KERNEL);

 <at>  <at>  -1172,7 +1169,7  <at>  <at>  struct bio_set *bioset_create(int bio_pool_size, int bvec_pool_size, int scale)
 	if (!bs->bio_pool)
 		goto bad;

-	if (!biovec_create_pools(bs, bvec_pool_size, scale))
+	if (!biovec_create_pools(bs, bvec_pool_size))
 		return bs;

 bad:
 <at>  <at>  -1196,38 +1193,12  <at>  <at>  static void __init biovec_init_slabs(void)

 static int __init init_bio(void)
 {
-	int megabytes, bvec_pool_entries;
-	int scale = BIOVEC_NR_POOLS;
-
 	bio_slab = kmem_cache_create("bio", sizeof(struct bio), 0,
 				SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);

 	biovec_init_slabs();

-	megabytes = nr_free_pages() >> (20 - PAGE_SHIFT);
-
-	/*
-	 * find out where to start scaling
-	 */
-	if (megabytes <= 16)
-		scale = 0;
-	else if (megabytes <= 32)
-		scale = 1;
-	else if (megabytes <= 64)
-		scale = 2;
-	else if (megabytes <= 96)
-		scale = 3;
-	else if (megabytes <= 128)
-		scale = 4;
-
-	/*
-	 * Limit number of entries reserved -- mempools are only used when
-	 * the system is completely unable to allocate memory, so we only
-	 * need enough to make progress.
-	 */
-	bvec_pool_entries = 1 + scale;
-
-	fs_bio_set = bioset_create(BIO_POOL_SIZE, bvec_pool_entries, scale);
+	fs_bio_set = bioset_create(BIO_POOL_SIZE, 2);
 	if (!fs_bio_set)
 		panic("bio: can't allocate bios\n");

diff --git a/include/linux/bio.h b/include/linux/bio.h
index 08daf32..4d85262 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
 <at>  <at>  -276,7 +276,7  <at>  <at>  extern struct bio_pair *bio_split(struct bio *bi, mempool_t *pool,
 extern mempool_t *bio_split_pool;
 extern void bio_pair_release(struct bio_pair *dbio);

-extern struct bio_set *bioset_create(int, int, int);
+extern struct bio_set *bioset_create(int, int);
 extern void bioset_free(struct bio_set *);

 extern struct bio *bio_alloc(gfp_t, int);

--

-- 
Jens Axboe
Permalink | Reply | 32 comments |

Gmane