Re: [PATCH] sched_clock: add data pointer argument to read callback
Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote: >> Russell King - ARM Linux <li...@arm.linux.org.uk> writes: >> >> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote: >> >> This passes a data pointer specified in the sched_clock_register() >> >> call to the read callback allowing simpler implementations thereof. >> >> >> >> In this patch, existing uses of this interface are simply updated >> >> with a null pointer. >> > >> > This is a bad description. It tells us what the patch is doing, >> > (which we can see by reading the patch) but not _why_. Please include >> > information on why the change is necessary - describe what you are >> > trying to achieve. >> >> Currently most of the callbacks use a global variable to store the >> address of a counter register. This has several downsides: >> >> - Loading the address of a global variable can be more expensive than >> keeping a pointer next to the function pointer. >> >> - It makes it impossible to have multiple instances of a driver call >> sched_clock_register() since the caller can't know which clock will >> win in the end. >> >> - Many of the existing callbacks are practically identical and could be >> replaced with a common generic function if it had a pointer argument. >> >> If I've missed something that makes this a stupid idea, please tell. > > So my next question is whether you intend to pass an iomem pointer > through this, or a some kind of structure, or both. It matters, > because iomem pointers have a __iomem attribute to keep sparse > happy. Having to force that attribute on and off pointers is frowned > upon, as it defeats the purpose of the sparse static checker. So this is an instance where tools like sparse get in the way of doing the simplest, most efficient, and obviously correct thing. Who wins in such cases? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sched_clock: add data pointer argument to read callback
Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote: >> This passes a data pointer specified in the sched_clock_register() >> call to the read callback allowing simpler implementations thereof. >> >> In this patch, existing uses of this interface are simply updated >> with a null pointer. > > This is a bad description. It tells us what the patch is doing, > (which we can see by reading the patch) but not _why_. Please include > information on why the change is necessary - describe what you are > trying to achieve. Currently most of the callbacks use a global variable to store the address of a counter register. This has several downsides: - Loading the address of a global variable can be more expensive than keeping a pointer next to the function pointer. - It makes it impossible to have multiple instances of a driver call sched_clock_register() since the caller can't know which clock will win in the end. - Many of the existing callbacks are practically identical and could be replaced with a common generic function if it had a pointer argument. If I've missed something that makes this a stupid idea, please tell. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RGB LED control (was Re: advanced LED controllers)
Geert Uytterhoeven ge...@linux-m68k.org writes: Hi Pavel, On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek pa...@ucw.cz wrote: Ok, so I played with RGB LED a bit, and we have quite a gap in documentation: what 50% brightness means is non-trivial and very important in case we want to do smooth blinking and color transitions. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 3646ec8..649d7a6 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -8,6 +8,11 @@ Description: non-zero brightness settings. The value is between 0 and /sys/class/leds/led/max_brightness. + If LED supports continuous brightness settings, 50% brightness + should correspond to 50% brightness perceived by human, in a similar + manner pixel brightness on monitor does (not 50% PWM). How many drivers do it right? How many don't? For those that don't, perhaps we handle the conversion between perceived and pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate the need for conversion? Some LED controllers do the right thing in hardware, so any adjustment done in the core needs to be optional. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. When the source register is not lr the name ret is a misnomer since only the bx lr instruction is predicted as a function return. The bx instruction with other source registers uses the normal prediction mechanisms, leaving the return stack alone, and should not be used for function returns. Any code currently using another register to return from a function should probably be modified to use lr instead, unless there are special reasons for doing otherwise. If code jumping to an address in a non-lr register is not a return, using the ret name will make for some rather confusing reading. I would suggest either using a more neutral name than ret or adding an alias to be used for non-return jumps so as to make the intent clearer. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote: Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. When the source register is not lr the name ret is a misnomer since only the bx lr instruction is predicted as a function return. The bx instruction with other source registers uses the normal prediction mechanisms, leaving the return stack alone, and should not be used for function returns. Any code currently using another register to return from a function should probably be modified to use lr instead, unless there are special reasons for doing otherwise. If code jumping to an address in a non-lr register is not a return, using the ret name will make for some rather confusing reading. I would suggest either using a more neutral name than ret or adding an alias to be used for non-return jumps so as to make the intent clearer. If you read the patch, the branches which are changed are those which do indeed return in some way. There are those which do this having moved lr to a different register. The patch is huge, and it wasn't obvious (to me) from the diff context what the non-lr jumps were doing. As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Will Deacon will.dea...@arm.com writes: Hi Mans, On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. Funnily enough, that's not actually true (and is more or less what prompted this patch after discussion with Russell). There are cores out there that don't predict mov pc, lr at all (let alone do anything with the return stack). Even ones where the TRM says they do? I suppose the only way to know for sure is to measure it. discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. I'm led to believe that some predictors require lr in order to update the return stack, whilst others don't. That part is all horribly micro-architectural, so the current patch is doing the right thing by sticking to the ARM ARM but enabling us to hook into other registers later on if we choose. Agreed. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@landley.net writes: On 09/25/2013 10:52:44 AM, Måns Rullgård wrote: Rob Landley r...@landley.net writes: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Since when is assembling the instructions correctly, as specified in the arch ref, and not in some other random way a gnuism? If you require current gnome and drop support for older versions (and implicitly all other desktops), people start writing stuff that depends on systemd. It doesn't matter if the feature you abandoned support for the past 10 years of everthing else for wasn't itself provided by systemd. Are you saying current binutils depends on gnome and/or systemd? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@landley.net writes: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Since when is assembling the instructions correctly, as specified in the arch ref, and not in some other random way a gnuism? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. So you prefer I come up with the reversion patches locally and _not_ send them upstream? This is a silly attitude. What you're effectively saying is that we are never allowed to use any future ARM instructions in any Linux kernel because that might break your precious assembler. I've got news for you. We're *not* going to listen to that argument. END OF DISCUSSION (everything else is just a waste of time.) I fully agree. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Rob Landley r...@landley.net writes: On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Um, my toolchain is using the last gplv2 snapshot of binutils out of git, which is just past 2.17 and can build armv7 (but not armv8). Binutils 2.12-2.22 is quite the jump. (11 years.) I'd except some thought to have gone into that? Possibly a mention of it? I seriously doubt that 2.12 still works at all (I doubt it can even be built on a modern system). In my experience, binutils older than 2.19 or so rarely works properly for ARM. What value is there in maintaining compatibility with a truly ancient binutils version anyway? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
Catalin Marinas catalin.mari...@arm.com writes: On Thu, Nov 15, 2012 at 12:41:43PM +, Siarhei Siamashka wrote: BTW, I always wondered about what could be preventing TI and the other silicon vendors from using something like an SMC API based on asymmetric cryptography? My understanding is that for OMAP4 GP chips, ROM code switches to non-secure mode before passing control to the bootloader and there is simply no way to workaround bugs like this. AFAIK, there are some SMCs to the OMAP secure firmware that allow such bits to be set (see omap4_l2x0_set_debug() for example). I'm not sure they are documented. The trouble with OMAP is that the secure ROM API only allows access to a tiny subset of the registers we'd need. In part this can be explained by the important OMAP customers all using the HS chips with full access to secure mode. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Sat, Oct 13, 2012 at 04:46:18AM +, Paul Walmsley wrote: After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 (ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig: [3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB [3.915954] mmcblk0: p1 [4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [4.093719] Modules linked in: [4.096954] CPU: 0Not tainted (3.6.0-02232-g759e00b #570) [4.103149] PC is at vfp_reload_hw+0x1c/0x44 [4.107666] LR is at __und_usr_fault_32+0x0/0x8 It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 (ARM: 6203/1: Make VFPv3 usable on ARMv6). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so the kernel dies with an undefined instruction exception. The kernel didn't crash before commit 846a136 because the save and restore code only touched d0-d15, present on all VFP. Fix to save and restore the d16-d31 registers only if they are present. No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers - and it communicates this information to userspace. If this bit is clear, and the VFP only has 16 double registers, then _that_ is a bug. That bit will be clear on VFPv2 (because it's not v3), and this has only 16 D registers. The high D registers are present if (vfpv3 !vfpv3d16). Pre-calculating this to avoid doing it in the context save/restore code is probably a good idea. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Paul Walmsley p...@pwsan.com writes: Hi Kevin, thanks for the suggestion, On Tue, 8 May 2012, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Thu, 19 Apr 2012, Igor Grinberg wrote: IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Just tested this on a 3517EVM and the same problem is there too. Does adding nohlt on the cmdline make a difference? The AM35x has known wakeup limitations, and nohlt would at least avoid WFI to see if it's the wakeup problems that are the root cause here. Adding 'nohlt' allows it to go a little farther in the boot, but still hangs. Log below. (Without 'nohlt', it hangs right after calling ip_auto_config+0x0/0xf70 @ 1) - Paul [6.250946] calling net_secret_init+0x0/0x1c @ 1 [6.255981] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [6.263092] calling tcp_congestion_default+0x0/0xc @ 1 [6.268646] initcall tcp_congestion_default+0x0/0xc returned 0 after 29 usecs [6.276184] calling ip_auto_config+0x0/0xf70 @ 1 [6.325500] mmc0: new high speed SDHC card at address b368 [6.334686] mmcblk0: mmc0:b368 USD 3.75 GiB [6.347686] mmcblk0: p1 p2 p3 [ 18.374359] initcall ip_auto_config+0x0/0xf70 returned -19 after 11809741 use cs [ 18.382141] calling initialize_hashrnd+0x0/0x1c @ 1 [ 18.387420] initcall initialize_hashrnd+0x0/0x1c returned 0 after 59 usecs [ 18.397949] async_waiting @ 1 [ 18.401184] async_continuing @ 1 after 119 usec (hangs) Are you still trying nfsroot? Since ip_auto_config failed, it will have no way of mounting the nfsroot and stop there. Do you know why ip setup failed? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: [7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs [7.077880] calling gpio_keys_init+0x0/0xc @ 1 [7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs [7.091278] calling rtc_hctosys+0x0/0x110 @ 1 [7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs [7.111297] calling net_secret_init+0x0/0x1c @ 1 [7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [7.123443] calling tcp_congestion_default+0x0/0xc @ 1 [7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs [7.136444] calling ip_auto_config+0x0/0xf70 @ 1 Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? I did a little digging... Firstly, only the am3571evm board registers the davinci_emac platform device. On a Craneboard or a CM-T3517 there will simply be no network device for IP autoconfig to use (unless you magically have DT working). Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Tony Lindgren t...@atomide.com writes: * Måns Rullgård m...@mansr.com [120419 08:31]: Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: [7.069885] initcall scsi_complete_async_scans+0x0/0x10c returned 0 after 29 usecs [7.077880] calling gpio_keys_init+0x0/0xc @ 1 [7.084167] initcall gpio_keys_init+0x0/0xc returned 0 after 1400 usecs [7.091278] calling rtc_hctosys+0x0/0x110 @ 1 [7.096038] /home/paul/linux/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [7.104217] initcall rtc_hctosys+0x0/0x110 returned -19 after 7987 usecs [7.111297] calling net_secret_init+0x0/0x1c @ 1 [7.116333] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [7.123443] calling tcp_congestion_default+0x0/0xc @ 1 [7.128997] initcall tcp_congestion_default+0x0/0xc returned 0 after 0 usecs [7.136444] calling ip_auto_config+0x0/0xf70 @ 1 Is anyone else seeing this? I've tried various configurations and can confirm this hang. I still haven't got my hands on bisecting this. There is nothing special about CM-T3517, IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Anyway, can anybody try nfsroot on other AM35xx based board with EMAC supported? I did a little digging... Firstly, only the am3571evm board registers the davinci_emac platform device. On a Craneboard or a CM-T3517 there will simply be no network device for IP autoconfig to use (unless you magically have DT working). Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). This clock problem was recently fixed in the linux-omap tree. I should have made sure my tree was fully up to date before poking around. With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. Just to check, is this with the bad muxing removed in fixes branch? Without that there can be all kinds of weird issues if some uart pins are used for non-uart functionality: bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads)? Same problem on linux-omap master. If I simply drop the msleep() calls (and use CONFIG_PREEMPT), it progresses a bit further. With a static IP config provided, ip_auto_config() returns and it hangs somewhere else. With ip=dhcp it sends out a DHCP request but gets stuck waiting for the reply. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Mark A. Greer mgr...@animalcreek.com writes: On Thu, Apr 19, 2012 at 04:04:42PM +0100, Måns Rullgård wrote: Igor Grinberg grinb...@compulab.co.il writes: On 04/19/12 05:07, Paul Walmsley wrote: Hi, just wanted to mention this on the list to see if anyone else was seeing it. I'm using a Compulab CM-T3517 and attempting to use nfsroot, and the boot hangs. Here are the last few lines when booting with initcall_debug: I did a little digging... Secondly, the clock configuration for davinci_emac on am35xx is broken. omap3xxx_clk_init() registers two clocks for dev_id davinci_emac, one with con_id emac_clk, one with phy_clk. When davinci_emac_probe() then does a clk_get(dev, NULL), this fails since there is no matching con_id. Likewise for davinci_mdio_probe(). This is fixed by 59269b94483eabeacbc9a535944b3dafac92a303 (ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases) from Ilya Yanok ya...@emcraft.com. Its in the current mainline kernel. Yeah, I noticed after I'd already figured out why it was failing. Oh well, it was a good exercise. With a little hacking, I got the platform device registered and the clocks matching as (I think) they should. It now detects the correct PHY, so that's something. However, the IP config is still getting stuck. For reasons I don't know, the msleep(1) call in ic_open_devs() never returns. That's as far as I got. I tried the current mainline on my am3517 evm and it hangs as well. I'm not surprised, the am35xx has some serious issues ATM. I submitted a set of patches to fix a lot of them but they need to be reworked. I'm working on that now. Until then, don't expect much to work well. If it does seem to work well, you got lucky. If you want to get running quickly, try the ***HACK*** below. Current mainline boot with it applied, CONFIG_TI_DAVINCI_EMAC=y, boots on my am3517 evm with both an MMC-mounted NFS-mounted rootfs. Mark -- diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 703bd10..187f5cb 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -705,7 +705,6 @@ static int __init omap3_pm_init(void) struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm; int ret; - if (!cpu_is_omap34xx()) return -ENODEV; if (!omap3_has_io_chain_ctrl()) That does indeed make it boot. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
stephane eranian eran...@googlemail.com writes: Same result for me on CPU1: top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07 Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie Cpu(s): 30.7%us, 2.7%sy, 0.0%ni, 66.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem:940232k total, 228984k used, 711248k free,82244k buffers Swap: 524240k total,0k used, 524240k free,91400k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 3968 eranian 20 0 644 160 128 R 100 0.0 0:21.98 1 noploop 3969 eranian 20 0 2184 1056 804 R3 0.1 0:00.53 0 top 82 root 20 0 000 S1 0.0 0:01.35 0 kworker/0:1 With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result. So it must be coming from somewhere else, as you suggested. If the processor was spending time processing interrupts, then this would be accounted for in as sys time. But that's not what I observe here. It's either idle or user. That line, leads me to believe that the processor can only run my program for 30% of the time. The rest is spent idling even though my program is non-blocking. How could that be possible? Power-saving? In top, press 1 to see the statistics for the CPUs separately. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes: Hi guys, On Sat, Jan 21, 2012 at 09:16:57AM +, stephane eranian wrote: On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei ming@canonical.com wrote: On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. This was with the Linaro tilt-3.2 kernel from git://git.linaro.org/landing-teams/working/ti/kernel.git, commit 73e2c29f209d281f7cd10b52b53b087e74f1. Maybe one of the many patches it has on top of 3.2 is to blame. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes: On Fri, Jan 27, 2012 at 01:47:01PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. This was with the Linaro tilt-3.2 kernel from git://git.linaro.org/landing-teams/working/ti/kernel.git, commit 73e2c29f209d281f7cd10b52b53b087e74f1. Maybe one of the many patches it has on top of 3.2 is to blame. Perhaps, or (more likely) the interrupt affinity for the CTI isn't working properly and the interrupt is always delivered to CPU0. I'll keep this in mind in case we get any more reports like this. It works whichever CPU I pin it to (i.e. taskset 2 also works). FWIW, my /proc/interrupts looks like this when perf is running: CPU0 CPU1 29: 252381271409121 GIC twd 33:4586197 0 GIC arm-pmu 34: 04744550 GIC arm-pmu 39: 0 0 GIC TWL6030-PIH 41: 0 0 GIC l3-dbg-irq 42: 0 0 GIC l3-app-irq 43: 0 0 GIC prcm 44:141 0 GIC DMA [...] -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Catalin Marinas catalin.mari...@arm.com writes: On Tue, Jan 17, 2012 at 12:27:25PM +, Aneesh V wrote: But I thought enabling L2$ again in kernel is the cleaner solution. Why? It gets enabled via SCTLR.M together with L1. Not if the L2EN bit of the auxiliary control register was cleared, and u-boot messes with this bit. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: It looks like snd-soc-rx51 only works as built-in, not as a module
Felipe Contreras felipe.contre...@gmail.com writes: On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote: On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: That should not be required, the modules should be loadable in any order. Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. That is compltelely orthogonal to what you were saying above about the ordering of module loading. Not really, because if both are compiled as modules, snd_soc_tlv320aic3x will always be loaded first (automatically by udev). Which is relevant because...? To repeat, the ordering of module loading is totally ortogonal as any ordering of modules is supported. You appear to be totally ignoring what I am writing here. One thing how things _should_ be, and another is how things actually _are_. Right now snd-soc-rx51 doesn't work if it's loaded before snd_soc_tlv320aic3x. Period. That means that *right now*, snd-soc-rx51 works fine with udev, because snd_soc_tlv320aic3x will be loaded at boot time. Now, if snd-soc-rx51 is converted and loaded automatically by udev as well, the issues might appear again. The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices. Well, if that's the case then there's a real issue. There doesn't seem to be a MODULE_DEPENDS(), or anything like that. A MODULE_DEPENDS() would also be irrelevant here. Ok. snd-soc-rx51 seems to depend on snd_soc_tlv320aic3x through codec_dai_name, and codec_name, and so on. I don't know how this dependency is supposed to work out. All the drivers should load via the normal driver instantiation mechainsms and when they're all there they'll get matched together. Ok, I hope so. Does this patch change anything? http://article.gmane.org/gmane.linux.alsa.devel/89052 -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Thu, Dec 29, 2011 at 10:22:31PM +, M?ns Rullg?rd wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices. I posted patches doing the conversion a long time ago (September?). It seems they got lost somewhere. Most of them have been converted, In which tree? I haven't seen anything of the kind. but the rx51 wasn't. RX51 was done in my patch... -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] It looks like snd-soc-rx51 only works as built-in, not as a module
Måns Rullgård m...@mansr.com writes: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Thu, Dec 29, 2011 at 10:22:31PM +, M?ns Rullg?rd wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices. I posted patches doing the conversion a long time ago (September?). It seems they got lost somewhere. Most of them have been converted, In which tree? I haven't seen anything of the kind. but the rx51 wasn't. RX51 was done in my patch... That would be this one: http://article.gmane.org/gmane.linux.alsa.devel/89052 -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: It looks like snd-soc-rx51 only works as built-in, not as a module
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: On Thu, Dec 29, 2011 at 11:27 PM, Mark Brown On Thu, Dec 29, 2011 at 11:25:50PM +0200, Felipe Contreras wrote: On Thu, Dec 29, 2011 at 8:37 PM, Mark Brown On Sat, Dec 10, 2011 at 05:59:57PM +0200, Felipe Contreras wrote: It was not working for me, but it seems the problem was related to mdev/udev; snd_soc_tlv320aic3x has to be loaded before snd-soc-rx51. That should not be required, the modules should be loadable in any order. Are you sure? I recall having a similar discussion with Rusell King, and the conclusion is that certain modules are supposed to be loaded by udev at boot time, and it seems snd_soc_tlv320aic3x is one of them. I'm absolutely positive. ASoC supports loading the modules in any order. udev is supposed to load anything autoloadable at boot time, including I2C devices, but that's orthogonal to the order in which things actually get loaded - udev can randomly reorder things if it feels like it. Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. That is compltelely orthogonal to what you were saying above about the ordering of module loading. The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices. I posted patches doing the conversion a long time ago (September?). It seems they got lost somewhere. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with undefined instruction
Sebastian Reichel s...@debian.org writes:
Hi,
I'm currently trying to get a mainline based kernel running on my pandaboard.
The problem is, that it's crashing very early during the init phase because of
undefined instruction exceptions:
[1.867980] udevd (56): undefined instruction: pc=401e6ed4
[1.874603] Code: 9cd0 fffe e92d 4ff0 (ed2d)
[1.977752] modprobe (69): undefined instruction: pc=400c6ed4
[1.977783] Code: 9cd0 fffe e92d 4ff0 (ed2d)
[1.978240] init (1): undefined instruction: pc=40149ed4
[1.978240] Code: 9cd0 fffe e92d 4ff0 (ed2d)
[2.005706] Kernel panic - not syncing: Attempted to kill init!
Exactly the same userland boots fine with the original 2.6.35 kernel, so it's
probably not the userland's fault. But I searched for the byte combination
anyway and found it in libc.so:
32ecc: 9cd0ldr r4, [sp, #832] ; 0x340
32ece: fffe e92d vtbl.8 d30, {d14-d15}, d29
00032ed0 _IO_vfprintf:
32ed0: e92d 4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
32ed4: ed2d 8b02 vpush {d8}
Your userland appears to be built with Thumb2. Make sure CONFIG_THUMB
is enabled in your kernel.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with undefined instruction
Santosh Shilimkar santosh.shilim...@ti.com writes:
On 4/30/2011 10:14 PM, Måns Rullgård wrote:
Sebastian Reichels...@debian.org writes:
[..]
32ecc: 9cd0ldr r4, [sp, #832] ; 0x340
32ece: fffe e92d vtbl.8 d30, {d14-d15}, d29
00032ed0_IO_vfprintf:
32ed0: e92d 4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
32ed4: ed2d 8b02 vpush {d8}
Your userland appears to be built with Thumb2. Make sure CONFIG_THUMB
is enabled in your kernel.
Oh yes. The config has CONFIG_ARM_THUMB=y but THUMB2 isn't enabled.
Sorry, I meant CONFIG_ARM_THUMB and that is indeed enabled. Must be
something else.
CONFIG_THUMB2_KERNEL=y should fix the problem.
No, that builds the kernel in Thumb2 mode and you probably don't want
that.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4: IRQ line of CortexA9 performance monitor
Ming Lei tom.leim...@gmail.com writes: Hi, From chapter 17 of Interrupt controller, OMAP4 TRM, I can't find what is the interrupt line of CortexA9 performance monitor in omap4. Seems without this information, we can't use perf on omap4. Any suggestions or ideas about it? The PMU interrupt is routed through the CTI, which needs to be properly configured. Unfortunately, the CTI is not documented in the public TRM, and nobody has seen fit to submit a patch suitable for upstream. Some dirty hacks have been posted, though. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
David Brownell davi...@pacbell.net writes: So to recapitulate ... you're agreeing with me on my key point -- that ARM1156, a V6T2 core with Thumb2 support (used in fact to introduce Thumb2), should work for some in-kernel Thumb2 usage, degree TBD, but obviously the v7 cores are more capable (with SIMD support in T2, etc). The ARM1156 implements the full Thumb2 instruction set, exactly the same as in v7 except for ThumbEE and features new to v7 in general. But the updated reason you gave for not allowing V6T2 is that it's an uncommon architecture (one core, not widely manufactured today) ... not impossibility. The architecture being uncommon is not in my opinion cause to make life harder than necessary for whomever might some day want to add support for it. Does the patch solve any real problem today? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
Jonghun Han jonghun79@gmail.com writes: Tomi Valkeinen wrote: 2010/11/30 Tomi Valkeinen tomi.valkei...@nokia.com: On Tue, 2010-11-30 at 12:29 +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Paul Mundt [mailto:let...@linux-sh.org] Sent: Tuesday, November 30, 2010 12:10 PM To: Ville Syrj?l? Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux- fb...@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: snip OMAP has user writeable shadow registers and hidden real registers for display controller. The shadow registers are latched to real registers on VFP, but only if GO bit has been set. The GO bit is cleared by the HW when latching has been done. If the GO bit is set, we cannot touch the shadow registers because we don't know when the VFP will happen. That's why there's additionally a SW cache for the config, so that we don't need to block when the GO bit is up and the user wants to change the config. The driver flushes the SW config to real registers in VSYNC interrupt handler. Does the driver flush the config to real register directly not a shadow register in VSYNC ISR? Does it mean display controller use the config flushed to the real register from the VSYNC ? The hardware latches the shadow registers to the active registers at start of VFP. I don't know OMAP in detail. But as I know other SoCs also work like it. Can Go bit is cleared by SW? No. And does each overlay(FB) have its own Go bit? No. There is one GO bit per video output, i.e. one each for LCD and TV. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
Hiremath, Vaibhav hvaib...@ti.com writes:
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@nokia.com]
Sent: Wednesday, November 24, 2010 10:01 PM
To: Hiremath, Vaibhav
Cc: Tomi Valkeinen; linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, November 24, 2010 2:28 PM
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
Hi,
snip
Changing it to WAITFORGO would alter the behaviour. Sometimes it would
not wait at all, sometimes it could wait for multiple vsyncs.
[Hiremath, Vaibhav] I am quite not sure, whether it makes sense from
application point of view to wait for vsync if config is not changed. What
could be the use-case for such requirement, where application won't change
anything but still would like to wait on vsync?
And as far as wait on multiple vsync is concerned, it does make sense to
coat WAITFORVSYNC ioctl makes sure that your change got applied to HW.
I am not aware of other architectures, but I believe this is something
OMAP specific stuff. And for other platforms, WAITFORVSYNC means changes
applied to HW (why does apps care about whether it is vsync or anything
else?).
WAITFORVSYNC waits for the next vsync (or actually vblank in many
cases).
[Hiremath, Vaibhav] Please note that this doesn't include VFP
(vertical front porch), since you are going to get VSYNC only after
VFP.
That's it. I don't see any point in trying to shoehorn
other functionality into it.
If you want to standardise WAITFORGO type of stuff then just add
another standard ioctl for it.
[Hiremath, Vaibhav] I still believe we should not only look at the
name of IOCTL (WAITFORVSYNC) and define what it should do, it may
change based on your platform/HW to get the desired functionality
out of it.
It is impossible to know what every user expects from it. A user may
very well be using WAITFORVSYNC for timing purposes. If it then were
to sometimes wait more than one vsync, it would be useless.
In OMAP there is chance of miss-match between user application and
Display HW if user uses FBIO_WAITFORVSYNC ioctl in multi-buffer
use-case.
while (1) {
Update/Create the next buffer
FBIO_PAN
FBIO_WAITFORVSYNC //assuming HW-SW stay in sync (which is not)
}
There is definitely an issue with above use-case which has been
un-doubtfully conformed now.
The bug could still be argued to be in the application.
At least in case of OMAP, WAITFORVSYNC is useless in multiple
buffering use-case, application has to use WAITFORGO.
Why does it take so long for the changes to reach the hardware? Once
written to the registers, the values are latched at the next vsync, so
the delay is higher up the stack. Is there any way it could be
eliminated? This would not only fix the bug under discussion here,
but also reduce the latency of page flipping.
As far as WAITFORGO is concerned, I think GO bit concept is
something OMAP notion/term and doesn't make sense to standardize
it. Atleast I am not aware of any other architecture having GO bit.
Naming is minor detail. Feel free to suggest a better one.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] omap4: l2x0: Construct the AUXCTRL value using defines
Kevin Hilman khil...@deeprootsystems.com writes: Santosh Shilimkar santosh.shilim...@ti.com writes: This patch removes the hardcoded value of auxctrl value and construct it using bitfields Bit 25 is reserved and is always set to 1. Same value of this bit is retained in this patch Is this OMAP specific, or is this ARM generic? The bit fields are generic PL310. It has to be set from OMAP code due to the ROM call. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] omap4: l2x0: Enable early BRESP bit
Santosh Shilimkar santosh.shilim...@ti.com writes: The AXI protocol specifies that the write response can only be sent back to an AXI master when the last write data has been accepted. This optimization enables the PL310 to send the write response of certain write transactions as soon as the store buffer accepts the write address. This behavior is not compatible with the AXI protocol and is disabled by default. You enable this optimization by setting the Early BRESP Enable bit in the Auxiliary Control Register (bit [30]). Did you measure the performance difference this makes, if any? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: enable L2 prefetching
Nishanth Menon n...@ti.com writes: From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it, even though it damages writes a bit. (rebased to k.org) Usually the prefetch is used at both levels together L1 + L2, however, to enable the CP15 prefetch engines, these are under security, and on GP devices, we cannot enable it(e.g. on PandaBoard). However, just enabling PL310 prefetch seems to provide performance improvement, as shown in the data below (from Ubuntu) and would be a great thing to pull in. What this does is enable automatic next line prefetching. With this enabled, whenever the PL310 receives a cachable read request, it automatically prefetches the following cache line as well. A larger offset can be programmed in secure mode, but the TI ROM authors neglected to include this. Testing with FFmpeg showed a speedup of 10% with this patch in some cases. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH D 01/11] OMAP: Add clk_get_parent() for OMAP2/3
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Sat, Jan 31, 2009 at 03:07:06PM +, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: Great, thanks. However, I'd forgotten that one of my patches completely removes clk_get_parent() since it's unused by any code in OMAP at present. What was the reasoning behind making this work? It is needed for the omapfb/dss driver to set an optimal rate for dpll4_m4_ck. I assume this isn't merged yet? Where can I see what it's doing? The new DSS driver by Tomi Valkeinen uses it. Patches have been posted to the linux-omap list. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH D 01/11] OMAP: Add clk_get_parent() for OMAP2/3
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Sat, Jan 31, 2009 at 03:39:07PM +, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Sat, Jan 31, 2009 at 03:07:06PM +, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: Great, thanks. However, I'd forgotten that one of my patches completely removes clk_get_parent() since it's unused by any code in OMAP at present. What was the reasoning behind making this work? It is needed for the omapfb/dss driver to set an optimal rate for dpll4_m4_ck. I assume this isn't merged yet? Where can I see what it's doing? The new DSS driver by Tomi Valkeinen uses it. Patches have been posted to the linux-omap list. Can't find them. Found the DSS patches posted on the 12th but they don't use clk_get_parent(). So, I repeat. Where can I see where this function is used? I have the patches applied in my git tree: http://git.mansr.com/?p=linux-omap;a=blob;f=arch/arm/plat-omap/dss/dispc.c;h=e6954637b113c66cb6a0ee8c7c4c3993d170b4a3;hb=HEAD#l1494 -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmci-omap regressions
Ladislav Michl la...@linux-mips.org writes: Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and 2.6.22-omap1 showed that [...] Doing the same modification in current git doesn't help. Moreover removing omap.ko and inserting again behaves differently than inserting for first time: # modprobe omap mmci-omap mmci-omap.0: command timeout (CMD8) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD55) mmci-omap mmci-omap.0: command timeout (CMD55) mmci-omap mmci-omap.0: command timeout (CMD55) mmci-omap mmci-omap.0: command timeout (CMD55) mmc0: error -22 whilst initialising MMC card # rmmod omap # modprobe omap mmci-omap: probe of mmci-omap.0 failed with error -16 I'll happily send any requested debug informations and test any patches I'm getting the same error on Nokia 770. Anything I can do to help? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate()
Tony Lindgren [EMAIL PROTECTED] writes: * Paul Walmsley [EMAIL PROTECTED] [081205 15:52]: On Tue, 21 Oct 2008, Mans Rullgard wrote: Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. Signed-off-by: Mans Rullgard [EMAIL PROTECTED] Acked-by: Paul Walmsley [EMAIL PROTECTED] Måns, sorry this took so long, these two patches slipped through the cracks here. Pushing both to l-o tree today. Paul, I take it you will queue these up for mainline via your clock series? Måns, I heard you have some display patches? How about queuing up those on the fbdev list? It looks like Tomi's driver is shaping up nicely, so it's probably not worthwhile spending any significant time on the current driver. If anyone is interested, everything I have is in my git tree. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setting dss1_alwon_fck
Tomi Valkeinen [EMAIL PROTECTED] writes: Hi, Mans Rullgard has the patches mentioned below in his kernel tree at http://git.mansr.com/?p=linux-omap;a=summary . I currently have those patches and use the following sequence to set the dss1_alwon_fck clock: /* get the rate of the parent of dpll4_m4_ck, which is dpll4_ck */ prate = clk_get_rate(clk_get_parent(dispc.dpll4_m4_ck)); /* calculate divisor so that wanted dss1_alwon_fck is prate / div * 2. * x2 because dss1_alwon_fck comes from dpll4_m4x2_ck */ div = ...; /* set the rate */ clk_set_rate(dispc.dpll4_m4_ck, prate / div); Is this the correct way to set dss1_alwon_fck? It's the only way I could find. I'd prefer if the mucking about with get_parent() could be avoided, but Paul (I think) told me there was no other way, at least not then. Maybe it has changed since. I'd also prefer to not do those divisor calculations. However, I could think of no other way to get the desired result, since clock_set_rate() isn't aware of the cascaded dividers. Are the patches below needed, or can dss1_alwon_fck be set some other way? At the time I wrote them, they were necessary. If later changes to the clock subsystem have made them obsolete, all the better. I don't recall seeing anything like that going in, though. commit e2de5e5578fbaa9b4b75074796da0608fc93e6ae Author: Mans Rullgard [EMAIL PROTECTED] Date: Tue Jul 22 01:58:18 2008 +0100 ARM: OMAP: add clk_get_parent() for OMAP2/3 Signed-off-by: Mans Rullgard [EMAIL PROTECTED] :100644 100644 577be44... 28aec36... M arch/arm/mach-omap2/clock.c :100644 100644 49245f7... 4aa69d5... M arch/arm/mach-omap2/clock.h :100644 100644 54cc6e1... ed7af21... M arch/arm/mach-omap2/clock24xx.c :100644 100644 04dedec... 08c8c46... M arch/arm/mach-omap2/clock34xx.c commit 2b7b958dc79e51127d7a4ecf88ce12dbc6c31426 Author: Mans Rullgard [EMAIL PROTECTED] Date: Tue Jul 22 01:31:11 2008 +0100 ARM: OMAP: make dpll4_m4_ck programmable with clk_set_rate() Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. :100644 100644 161da12... 876eb13... M arch/arm/mach-omap2/clock34xx.h I'll send the patches as replies to this mail for easier reference. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hans Verkuil [EMAIL PROTECTED] writes: On Monday 06 October 2008 08:06:30 Shah, Hardik wrote: 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with the defined color on the video pipelines to be replaced with the pixels on the graphics pipelines. I believe similar feature must be available on almost all next generation of video hardware. We can add new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF ioctl is used for setting up the buffer parameters on per buffer basis. So IMHO this ioctl is not a natural fit for the above functionality. Please provide your comments on same. Do I understand correctly that if the color in the *video* streams matches the colorkey, then it is replaced by the color in the *framebuffer* (aka menu/overlay)? Usually it is the other way around: if the framebuffer (menu) has chromakey pixels, then those pixels are replaced by pixels from the video stream. That's what the current API does. The OMAP3 hardware supports both type of keying, but not simultaneously. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: Fix 34xx/35xx revision check
Mans Rullgard [EMAIL PROTECTED] writes:
The 35xx TRM lists incorrect values for the VERSION field of the
CONTROL_IDCODE register. The correct values are those listed in
the 34xx TRM.
Correct message on boot verified on ES2.1 and ES3.0.
Signed-off-by: Mans Rullgard [EMAIL PROTECTED]
---
arch/arm/mach-omap2/id.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index ab7a6e9..9f72ae6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -162,14 +162,15 @@ void __init omap34xx_check_revision(void)
/*
* Detection for 34xx ES2.0 and above can be done with just
* hawkeye and rev. See TRM 1.5.2 Device Identification.
- * Note that rev cannot be used directly as ES1.0 uses value 0.
+ * The 35xx TRM lists incorrect values for the revision number.
+ * Correct values are documented in the 34xx TRM.
*/
idcode = read_tap_reg(OMAP_TAP_IDCODE);
hawkeye = (idcode 12) 0x;
rev = (idcode 28) 0xff;
if (hawkeye == 0xb7ae)
- system_rev = 0x34300034 | ((1 + rev) 12);
+ system_rev = 0x34300034 | (rev 12);
out:
switch (system_rev) {
Forget this. A fix was already in the tree, but not merged to my
branch.
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP support in mainline?
Felipe Balbi [EMAIL PROTECTED] writes:
On Wed, Sep 17, 2008 at 03:23:49PM +0200, ext Koen Kooi wrote:
Op 17 sep 2008, om 14:24 heeft Steve Sakoman het volgende geschreven:
On Wed, Sep 17, 2008 at 12:16 AM, Koen Kooi [EMAIL PROTECTED]
wrote:
And they aren't working too well with current l-o git either with MUSB
being
broken. There's a patch to fix client mode, but host mode still isn't
working.
Host mode musb is working just fine on Overo with the set
transceiver patch. Not sure why you are having trouble with Beagle
(and can't check since I don't have my Beagle board with me at the
moment)
I should clarify: OTG mode with a host cable doesn't work in .27rc, it does
work in 2.6.26. I haven't tried specifying pure hostmode, only OTG.
I would try it on the evm as well, but that is having serious irq issues
with .27rc, pressing a key on the keypad triggers an irq overrun, ethernet
gives an oops on boot when trying to register and irq etc,etc. 2.6.27 is
looking really, really bad on omap3 at the moment.
Yeah, we lost some musb history when it went to mainline. I didn't test
this patch yet cuz I've been quite busy at work, but it should make
beagle work. Could you tell me if makes it work ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 9d2dcb1..f7fe91e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -215,12 +215,14 @@ void musb_platform_set_mode(struct musb *musb, u8
musb_mode)
int __init musb_platform_init(struct musb *musb)
{
+ struct otg_transceiver *xceiv = otg_get_transceiver();
u32 l;
#if defined(CONFIG_ARCH_OMAP2430)
omap_cfg_reg(AE5_2430_USB0HS_STP);
#endif
+ memcpy(musb-xceiv, xceiv, sizeof(*xceiv));
Does this even compile? It doesn't match my patch, which is simply a
diff between the original l-o tree and what went upstream, and there
that last line looks like this:
+ musb-xceiv = *xceiv;
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB EHCI: Support final revision of USB board
Gadiyar, Anand [EMAIL PROTECTED] writes: On Saturday 23 August 2008, Tony Lindgren wrote: I'll get the ehci-omap code in better shape and submit separately to the linux-usb list. Given that we've not yet seen patches splitting out the board-specific bits into arch/arm/mach-omap2, I can't imagine those fixes being ready for the 2.6.28 merge window. (Hint for TI folk: why not write the code that way in the first place, avoiding all the delays inherent in writing code you *know* is unsuitable for merging to mainline?) Well, there are only a limited number of hours in a day. :) In my experience, writing code properly to begin with takes less time than writing it badly first, and cleaning it up later. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PREVIEW] New display subsystem for OMAP2/3
Tomi Valkeinen [EMAIL PROTECTED] writes: On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote: Tomi Valkeinen [EMAIL PROTECTED] writes: On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote: Koen Kooi [EMAIL PROTECTED] writes: What I don't like about the patch posted is its size. I'm sure the transition could be done in a sequence of smaller patches. At the very least, it should be possible to move existing functionality to the new architecture, then add the new parts afterwards. I also see little value in keeping the old model around, as is done in the patch. I don't like the size either. However, I have no idea how the old driver could be transformed to include this functionality with a reasonable effort. The implementations are quite different. Any suggestions how I could approach this task? Only thing that comes to my mind is that there are very similar low level functions in both DSS1 and DSS2 (for dispc and rfbi), that I could remove from the old place and move to arch/arm/plat-omap/dss/, but that doesn't take us very far. Are the patches you posted your latest version of the code? Do you have this code in a public git repo? I'd like to take a closer look at what you've done. They are not the very latest, but they are recent enough. Unfortunately I don't have them on a public git. Nokia is still a bit lacking in that area =). They should apply to linux-omap kernel from last Thursday (I think the commit id is mentioned in the series file). I don't like working on old code. It inevitably leads to wasting time re-doing things that have already been done in the latest version. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
Daniel Stone wrote: On Mon, Sep 08, 2008 at 09:02:56PM +0100, ext Måns Rullgård wrote: arun c [EMAIL PROTECTED] writes: + while (dispc_read_reg(DISPC_CONTROL) (1 5)) + continue; + MOD_REG_FLD(DISPC_CONTROL, 1 5, 1 5); + return height * screen_width * bpp / 8; } This looks good. However, the same thing is needed in omap_dispc_enable_plane() as well. Placing the loop+set in a function (go_lcd()?) would make sense. Preferably something with a slightly more generic name, so it could also fire GODIGITAL for digital out, when support for that exists. I agree; didn't think of that at first. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
arun c [EMAIL PROTECTED] writes: A shadow register change has no direct effect on the display configuration until the GOLCD (DISPC_CONTROL[5]) is set. Signed-off-by: Arun C [EMAIL PROTECTED] --- drivers/video/omap/dispc.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c index 82ba030..2e7af85 100644 --- a/drivers/video/omap/dispc.c +++ b/drivers/video/omap/dispc.c @@ -436,6 +436,11 @@ static inline int _setup_plane(int plane, int channel_out, dispc_write_reg(ri_reg[plane], (screen_width - width) * bpp / 8 + 1); + /* Wait untill GOLCD bit is cleared and set it */ Nit: until (one l) + while (dispc_read_reg(DISPC_CONTROL) (1 5)) + continue; + MOD_REG_FLD(DISPC_CONTROL, 1 5, 1 5); + return height * screen_width * bpp / 8; } This looks good. However, the same thing is needed in omap_dispc_enable_plane() as well. Placing the loop+set in a function (go_lcd()?) would make sense. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb broken, was [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
David Brownell [EMAIL PROTECTED] writes: On Saturday 06 September 2008, Steve Sakoman wrote: On Fri, Sep 5, 2008 at 10:52 AM, Tony Lindgren [EMAIL PROTECTED] wrote: * Steve Sakoman [EMAIL PROTECTED] [080905 10:24]: Hmm, is the musb broken now? It is on Overo if I base my patches against current top of tree (a376251519ced5831ed07ed234430725230ed93a) Doesn't crash, just quietly doesn't work. I hear from Beagle folk that musb doesn't work there either. ... A while back I tried a patch making the rc3-omap code match mainline (more or less) on Beagle, and it failed ... so I've been tracking down various RC3 issues. I don't have all of them yet, but various used to work (on DaVinci and TUSB6010) scenarios -- plugging/unplugging the B side of a cable (Beagle == host), reboot with cable connected (Beagle == peripheral) are being trouble. There's also a notification issue with CDC Ethernet ... if the usb0 interface (Beagle == peripheral) is brought up before the host gets connected, the host can't talk to it. I just sent that patch in: http://marc.info/?l=linux-usbm=122076214105934w=2 That explains what I've been seeing. I've applied it to my tree, but not tested yet. Mans has a patch in his git: http://git.mansr.com/?p=linux-omap;a=commitdiff;h=1e5bc41773bb981b3a89bd762becf98c72be5e4c Neither of us understand musb details enough to propose this as *the* fix, but it seems likely to be the issue. Missing that should probably make trouble, yes. I've also had to revert the usb: musb: pass configuration specifics via pdata commits: ffd60d49c70b31d26430a1098edf0eef5e4dfac8 in linux-omap ca6d1b1333bc2e61e37982de1f28d8604c232414 in mainline I suspect there are simply some tables missing for the Beagle board, but I haven't a clue what should go in them. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb broken, was [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
Steve Sakoman [EMAIL PROTECTED] writes: On Sun, Sep 7, 2008 at 10:37 AM, David Brownell [EMAIL PROTECTED] wrote: On Sunday 07 September 2008, Måns Rullgård wrote: I've also had to revert the usb: musb: pass configuration specifics via pdata commits: ffd60d49c70b31d26430a1098edf0eef5e4dfac8 in linux-omap ca6d1b1333bc2e61e37982de1f28d8604c232414 in mainline I suspect there are simply some tables missing for the Beagle board, but I haven't a clue what should go in them. Odd, that's in the RC3 code and it works for me. I don't need to revert those commits on Overo and it works as well as it ever has which means that I get disconnects/reconnects of all devices at random intervals. I am using musb in host mode, whereas I think Mans is in device/gadget mode. Maybe it started working again. I know for sure it broke gadget mode on the Beagle when it first hit linux-omap, and I haven't tried it since. Perhaps I should give it another go. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
