On Wed, 2011-06-15 at 14:23 +0300, Tomi Valkeinen wrote:
> On Thu, 2011-06-09 at 16:56 +0300, Tomi Valkeinen wrote:
> > Add missing DSS optional clocks to HWMOD data for OMAP4xxx.
> >
> > Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset.
> >
> > Cc: Benoit Cousson
> > Signed
On Tue, 2011-06-21 at 10:18 +0530, Tushar Behera wrote:
> Hi,
>
> On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote:
> > On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> >> Currently display support for omap2 is selected by default and
> >> it gets built for all the configurations.
>
On Monday 20 June 2011 06:34 PM, Tomi Valkeinen wrote:
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
In certain board files, there are references to vram related functions
which are defined in drivers/video/omap2/vram.c. Because of this direct
dependency, CONFIG_FB_OMAP2 should be a bu
Hi,
On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote:
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
Currently display support for omap2 is selected by default and
it gets built for all the configurations.
Instead of it being a built-in feature, it's compilation should
depend on
Russell King - ARM Linux writes:
> On Mon, Jun 20, 2011 at 02:09:39PM -0700, Kevin Hilman wrote:
>> Sanjeev Premi writes:
>>
>> > Fix the section mismatch warning:
>> >
>> > WARNING: vmlinux.o(.text+0x21118): Section mismatch
>> > in reference from the function pm_dbg_init() to the
>> > f
Hi,
On Mon, Jun 20, 2011 at 03:06:01PM -0700, Kevin Hilman wrote:
> Samuel Ortiz writes:
>
> > Hi Felipe,
> >
> > On Mon, Jun 20, 2011 at 04:28:52PM +0300, Felipe Balbi wrote:
> >> Hi,
> >>
> >> On Mon, Jun 20, 2011 at 03:26:26PM +0200, Samuel Ortiz wrote:
> >> > On Mon, Jun 06, 2011 at 07:12:1
Samuel Ortiz writes:
> Hi Felipe,
>
> On Mon, Jun 20, 2011 at 04:28:52PM +0300, Felipe Balbi wrote:
>> Hi,
>>
>> On Mon, Jun 20, 2011 at 03:26:26PM +0200, Samuel Ortiz wrote:
>> > On Mon, Jun 06, 2011 at 07:12:19PM +0530, Keshava Munegowda wrote:
>> > > From: Keshava Munegowda
>> > >
>> > > Oo
On Mon, Jun 20, 2011 at 02:09:39PM -0700, Kevin Hilman wrote:
> Sanjeev Premi writes:
>
> > Fix the section mismatch warning:
> >
> > WARNING: vmlinux.o(.text+0x21118): Section mismatch
> > in reference from the function pm_dbg_init() to the
> > function .init.text:pwrdms_setup()
> > The
Sanjeev Premi writes:
> Fix the section mismatch warning:
>
> WARNING: vmlinux.o(.text+0x21118): Section mismatch
> in reference from the function pm_dbg_init() to the
> function .init.text:pwrdms_setup()
> The function pm_dbg_init() references
> the function __init pwrdms_setup().
>
[...]
>
> A quick test of this series on 3430/n900 shows that it prevents PER
> retention. I see CM_FCLKEN_PER=c000 (debounce clock for GPIO banks
> 3 & 4 are still enabled.)
>
> Can you retest with debounce enabled on one of the GPIOs for one of your
> platforms?
With one of the module debo
On Monday, June 20, 2011, Alan Stern wrote:
> On Sun, 19 Jun 2011, Rafael J. Wysocki wrote:
>
> > In the meantime I rethought the __pm_runtime_disable() part of my previous
> > patch and I now think it's not necessary to complicate it any more. Of
> > course,
> > we need not check if runtime res
This patch, which should be applied on top of Felipe's
"input: keypad: lm8323: convert to threaded IRQ" patch, fixes the issue
of the Nokia N810 keypad stopping responding if multiple key events
occur
in quick succession.
Signed-off-by: Leigh Brown
---
drivers/input/keyboard/lm8323.c |2 +
On Monday 20 June 2011 09:05 PM, Kevin Hilman wrote:
shubhrajy...@ti.com writes:
From: Shubhrajyoti D
Currently the OMAP4 doesnot hit device off still the
driver may have support for it.Adding support for the
same.
Signed-off-by: Shubhrajyoti D
Please Cc linux-omap as this change to the hwmo
On 6/20/2011 8:31 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 08:24:33PM +0530, Santosh Shilimkar wrote:
I am away from my board now. Will test this change.
btw, the online-active race is still open even with this patch close
and should be fixed.
I have yet to see any evidence
On Mon, Jun 20, 2011 at 08:24:33PM +0530, Santosh Shilimkar wrote:
> I am away from my board now. Will test this change.
> btw, the online-active race is still open even with this patch close
> and should be fixed.
I have yet to see any evidence of that race - I've been running your
test loop for
Hi Felipe,
On Mon, Jun 20, 2011 at 04:28:52PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jun 20, 2011 at 03:26:26PM +0200, Samuel Ortiz wrote:
> > On Mon, Jun 06, 2011 at 07:12:19PM +0530, Keshava Munegowda wrote:
> > > From: Keshava Munegowda
> > >
> > > Oops are produced during initializati
On 6/20/2011 7:53 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 12:40:19PM +0100, Russell King - ARM Linux wrote:
Ok. So loops_per_jiffy must be too small. My guess is you're using an
older kernel without 71c696b1 (calibrate: extract fall-back calculation
into own helper).
Righ
On Sun, 19 Jun 2011, Rafael J. Wysocki wrote:
> In the meantime I rethought the __pm_runtime_disable() part of my previous
> patch and I now think it's not necessary to complicate it any more. Of
> course,
> we need not check if runtime resume is pending in __device_suspend(), because
> we've do
>> Are you using some extra patches? I have a custom board based
>> on am3517 SoC and I have much more errors during booting as I
>> can see from your boot log. I have no problems booting
>> 2.6.32/37 though. Any idea?
> [sp] You may want to follow this thread:
> http://marc.info/?t=129864
On Mon, Jun 20, 2011 at 12:40:19PM +0100, Russell King - ARM Linux wrote:
> Ok. So loops_per_jiffy must be too small. My guess is you're using an
> older kernel without 71c696b1 (calibrate: extract fall-back calculation
> into own helper).
Right, this commit above helps show the problem - and it
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Yegor Yefremov
> Sent: Monday, June 20, 2011 7:02 PM
> To: Daniel Mack
> Cc: Gadiyar, Anand; Tony Lindgren;
> linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead
Am 17.06.2011 17:11, schrieb Daniel Mack:
> On Fri, Jun 17, 2011 at 4:03 PM, Gadiyar, Anand wrote:
>>> console=ttyS2,115200 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
>>
>> Here is your problem. We now use the OMAP-serial driver for the UARTs.
>
> Which breaks backward-compatibility with boo
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Friday, June 17, 2011 1:47 PM
> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Cc: K, Mythri P
> Subject: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the H
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Friday, June 17, 2011 1:47 PM
> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Cc: K, Mythri P
> Subject: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean u
Hi,
On Mon, Jun 20, 2011 at 03:26:26PM +0200, Samuel Ortiz wrote:
> On Mon, Jun 06, 2011 at 07:12:19PM +0530, Keshava Munegowda wrote:
> > From: Keshava Munegowda
> >
> > Oops are produced during initialization of ehci and ohci
> > drivers. This is because the run time pm apis are used by
> > th
Hi Keshava,
On Mon, Jun 06, 2011 at 07:12:19PM +0530, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> Oops are produced during initialization of ehci and ohci
> drivers. This is because the run time pm apis are used by
> the driver but the corresponding hwmod structures and
> initializati
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> Currently display support for omap2 is selected by default and
> it gets built for all the configurations.
>
> Instead of it being a built-in feature, it's compilation should
> depend on the config option CONFIG_FB_OMAP2.
No, I don't think
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote:
> In certain board files, there are references to vram related functions
> which are defined in drivers/video/omap2/vram.c. Because of this direct
> dependency, CONFIG_FB_OMAP2 should be a built-in feature.
arch/arm/plat-omap/include/plat/vra
Hi Paul,
> On Fri, 6 May 2011, Jean Pihet wrote:
>
>> I checked the patch against the master branch of both Tony's and
>> Linus's trees, it applies and compiles OK.
>> Is that OK to you?
>
> If it applies cleanly against Linus's current tree, then yes, that's fine.
Do you know what happened to thi
On Mon, Jun 20, 2011 at 05:57:01PM +0530, Santosh Shilimkar wrote:
> On 6/20/2011 5:49 PM, Russell King - ARM Linux wrote:
>> On Mon, Jun 20, 2011 at 05:21:48PM +0530, Santosh Shilimkar wrote:
>>> On 6/20/2011 5:10 PM, Russell King - ARM Linux wrote:
>
> [...]
>
>>>
>>> Any pointers on the other qu
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Friday, June 17, 2011 1:47 PM
> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Cc: K, Mythri P
> Subject: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific
On 6/20/2011 5:49 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 05:21:48PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 5:10 PM, Russell King - ARM Linux wrote:
[...]
Any pointers on the other question about "why we need to enable
interrupts before the CPU is ready?"
To ensu
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Monday, June 20, 2011 5:51 PM
> To: Premi, Sanjeev
> Cc: Tushar Behera; linux-ker...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org;
> linux-fb...@vger.kernel.org; linux-omap@vger.kerne
On Mon, Jun 20, 2011 at 05:37:07PM +0530, Premi, Sanjeev wrote:
> [sp] Instead of changing the omap2plus_defconfig, shouldn't the
> board specific file be fixed instead?
The board specific configuration files in the mainline kernel are
deprecated and are gradually being removed.
--
To unsubsc
On Mon, Jun 20, 2011 at 05:21:48PM +0530, Santosh Shilimkar wrote:
> On 6/20/2011 5:10 PM, Russell King - ARM Linux wrote:
>> On Mon, Jun 20, 2011 at 04:55:43PM +0530, Santosh Shilimkar wrote:
>>> On 6/20/2011 4:43 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:17:58PM +0530, S
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tushar Behera
> Sent: Monday, June 20, 2011 4:16 PM
> To: linux-ker...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org;
> linux-fb...@vger.kernel.org; linux-omap
On 6/20/2011 5:10 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:55:43PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 4:43 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:17:58PM +0530, Santosh Shilimkar wrote:
Yes. It's because of interrupt and the CPU active-on
On 6/20/2011 4:15 PM, Santosh Shilimkar wrote:
On 6/20/2011 4:05 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux
wrote
On Mon, Jun 20, 2011 at 04:55:43PM +0530, Santosh Shilimkar wrote:
> On 6/20/2011 4:43 PM, Russell King - ARM Linux wrote:
>> On Mon, Jun 20, 2011 at 04:17:58PM +0530, Santosh Shilimkar wrote:
>>> Yes. It's because of interrupt and the CPU active-online
>>> race.
>>
>> I don't see that as a conclus
On 6/20/2011 4:43 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 04:17:58PM +0530, Santosh Shilimkar wrote:
Yes. It's because of interrupt and the CPU active-online
race.
I don't see that as a conclusion from this dump.
Here is the chash log..
[ 21.025451] CPU1: Booted seconda
On Mon, Jun 20, 2011 at 04:17:58PM +0530, Santosh Shilimkar wrote:
> Yes. It's because of interrupt and the CPU active-online
> race.
I don't see that as a conclusion from this dump.
> Here is the chash log..
> [ 21.025451] CPU1: Booted secondary processor
> [ 21.025451] CPU1: Unknown IPI mes
On 6/20/2011 4:14 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
No it doesn't work. I still get the crash. The important point
here is not to enable interrupts before CPU is marked
as online and active.
What is the crash (in full please)
Currently display support for omap2 is selected by default and
it gets built for all the configurations.
Instead of it being a built-in feature, it's compilation should
depend on the config option CONFIG_FB_OMAP2.
Cc: Paul Mundt
Cc: Tomi Valkeinen
Cc: Tony Lindgren
Signed-off-by: Tushar Behera
In certain board files, there are references to vram related functions
which are defined in drivers/video/omap2/vram.c. Because of this direct
dependency, CONFIG_FB_OMAP2 should be a built-in feature.
As per the current architecture, CONFIG_FB_OMAP2 is dependent on
CONFIG_OMAP2_DSS. Hence CONFIG_O
Currently drivers/video/omap2 is built by default with every configuration
of the kernel. Current patchset makes the omap2 video support conditional
on appropriate config option.
[Patch 2/2] was first generated, but that resulted in a build error.
[Patch 1/2] was created to fix that build error
On 6/20/2011 4:05 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 02:53:59PM +0530, San
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
> No it doesn't work. I still get the crash. The important point
> here is not to enable interrupts before CPU is marked
> as online and active.
What is the crash (in full please)?
Do we know what interrupt is causing it?
--
To un
On Mon, Jun 20, 2011 at 03:58:03PM +0530, Santosh Shilimkar wrote:
> On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
>> On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux wrote:
>>> On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
The current ARM CPU hot
On 6/20/2011 3:44 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
The current ARM CPU hotplug code suffers from couple of race conditions
in CPU online path with sche
On 6/20/2011 3:20 PM, Russell King - ARM Linux wrote:
On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
The current ARM CPU hotplug code suffers from couple of race conditions
in CPU online path with scheduler.
The ARM CPU hotplug code doesn't wait for hot-plugged CPU to be mark
* Russell King - ARM Linux [110620 02:51]:
> On Mon, Jun 20, 2011 at 02:23:34AM -0700, Tony Lindgren wrote:
> > These will be needed when dmtimer platform init code gets split
> > for omap1 and omap2+. These will also be needed for separate
> > sys_timer init and driver init for the rest of the ha
On Mon, Jun 20, 2011 at 10:50:53AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
> > The current ARM CPU hotplug code suffers from couple of race conditions
> > in CPU online path with scheduler.
> > The ARM CPU hotplug code doesn't wait
* Russell King - ARM Linux [110620 02:50]:
> On Mon, Jun 20, 2011 at 02:23:28AM -0700, Tony Lindgren wrote:
> > void __init gic_init_irq(void)
> > {
> > - void __iomem *gic_cpu_base;
> > -
> > /* Static mapping, never released */
> > gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE,
On Mon, Jun 20, 2011 at 02:23:34AM -0700, Tony Lindgren wrote:
> These will be needed when dmtimer platform init code gets split
> for omap1 and omap2+. These will also be needed for separate
> sys_timer init and driver init for the rest of the hardware timers
> in the following patches. No functio
On Mon, Jun 20, 2011 at 02:23:28AM -0700, Tony Lindgren wrote:
> void __init gic_init_irq(void)
> {
> - void __iomem *gic_cpu_base;
> -
> /* Static mapping, never released */
> gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
> BUG_ON(!gic_dist_base_addr);
>
>
On Mon, Jun 20, 2011 at 02:53:59PM +0530, Santosh Shilimkar wrote:
> The current ARM CPU hotplug code suffers from couple of race conditions
> in CPU online path with scheduler.
> The ARM CPU hotplug code doesn't wait for hot-plugged CPU to be marked
> active as part of cpu_notify() by the CPU whic
* Santosh Shilimkar [110620 02:35]:
> On 6/20/2011 2:53 PM, Tony Lindgren wrote:
> >This removes the support for setting the wake-up timer for debugging.
> >
> >Later on we can reserve gptimer1 for PM code only and have similar
> >functionality.
> >
> >Signed-off-by: Tony Lindgren
> >Reviewed-by:
On Sun, Jun 05, 2011 at 02:19:15PM +0530, Avinash.H.M. wrote:
> On Fri, May 20, 2011 at 09:16:24PM +0530, Avinash.H.M wrote:
> > The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
> > special sequence to reset the module. The sequence is
> > - Disable the I2C.
> > - Write
On 6/20/2011 2:53 PM, Tony Lindgren wrote:
This removes the support for setting the wake-up timer for debugging.
Later on we can reserve gptimer1 for PM code only and have similar
functionality.
Signed-off-by: Tony Lindgren
Reviewed-by: Kevin Hilman
---
Kevin cleaned up this with a better pat
The current ARM CPU hotplug code suffers from couple of race conditions
in CPU online path with scheduler.
The ARM CPU hotplug code doesn't wait for hot-plugged CPU to be marked
active as part of cpu_notify() by the CPU which brought it up before
enabling interrupts.
So we end up in with couple of
We can keep everything sys_timer and gptimer.c related code in
timer.c as the code will be very minimal.
Later on we can also remove timer-mpu.c, as it can be called from
omap4_timer_init function.
This allows us to get rid of confusing existing files. We currently
have timer-gp.c, timer-mpu.c, a
This is no longer needed as we now just set the desired
.timer in MACHINE_START. We can now also remove timer-gp.h.
Signed-off-by: Tony Lindgren
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap2/board-4430sdp.c|4
arch/arm/mach-omap2/board-devkit8000.c |4
arch/arm
Use dmtimer macros for clocksource. As with the clockevent,
this allows us to initialize the rest of dmtimer code later on.
Note that eventually we will be initializing the timesource
from init_early so sched_clock will work properly for
CONFIG_PRINTK_TIME.
Signed-off-by: Tony Lindgren
Reviewed-
There's no need to initialize the dmtimer framework early.
Just mark the clocksource and timesource as reserved, and
initialize dmtimer with an arch_initcall.
Signed-off-by: Tony Lindgren
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap1/timer32k.c|4
arch/arm/mach-omap2/ti
This removes the support for setting the wake-up timer for debugging.
Later on we can reserve gptimer1 for PM code only and have similar
functionality.
Signed-off-by: Tony Lindgren
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c | 28
arch/arm/mach-o
This patch makes timer-gp.c to use only a subset of dmtimer
functions without the need to initialize dmtimer code early.
Also note that now with the inline functions, timer_set_next_event
becomes more efficient in the lines of assembly code.
Signed-off-by: Tony Lindgren
Reviewed-by: Kevin Hilman
This will allow us to share the code between system timer and
dmtimer device driver code without having to initialize all the
dmtimers early. This change will also make the timer_set_next_event
more efficient as the inline functions will optimize the code
better for the timer reprogramming.
Signed
These will be needed when dmtimer platform init code gets split
for omap1 and omap2+. These will also be needed for separate
sys_timer init and driver init for the rest of the hardware timers
in the following patches. No functional changes.
Signed-off-by: Tony Lindgren
Reviewed-by: Kevin Hilman
This is needed for the following patches so we can initialize the
rest of the hardware timers later on.
As with the init_irq calls, there's no need to do cpu_is_omap calls
during the timer init as we only care about the major omap generation.
This means that we can initialize the sys_timer with th
This allows us to remove cpu_is_omap calls from init_irq functions.
There should not be any need for cpu_is_omap calls as at this point.
During the timer init we only care about SoC generation, and not about
subrevisions.
The main reason for the patch is that we want to initialize only
minimal oma
Hi all,
Here's an updated version of the init_irq and init_timer patches
against v3.0-rc3. This series sets up separate omap[123]_init_irq
functions and omap[1234]_timer sys_timer so we can get rid of
cpu_is_omap calls in the init_irq and init_timer.
This series also changes the dmtimer hardware
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Arno Steffen
> Sent: Monday, June 20, 2011 12:24 PM
> To: linux-omap@vger.kernel.org
> Subject: Omap3 -> AM37xx change cpu-frequency
>
> Currently I am using 2.6.33 on an
Hi,
On Sun, Jun 19, 2011 at 11:01:43PM +0100, Leigh Brown wrote:
> On Sun, 19 Jun 2011 22:56:06 +0300, Felipe Balbi wrote:
> >Hi,
> >
> >On Sun, Jun 19, 2011 at 07:00:13PM +, Leigh Brown wrote:
> >>Many thanks for trying to assist me with my problem. To recap,
> >
> >yeah, no problem ;-)
> >
>
73 matches
Mail list logo
