On Mon, Apr 07, 2014 at 11:20:14PM +0100, Damien Lespiau wrote:
On Mon, Apr 07, 2014 at 01:59:17PM -0700, Ben Widawsky wrote:
Cool. This explains the bad DERRMR values I was seeing in in error
states. I'm honestly didn't check if we actually need an SRM for BDW
still, but I'll assume you
On Tue, Apr 08, 2014 at 04:32:02AM +, Gupta, Sourab wrote:
Hi Rodrigo,
In this patch, while freeing the purgeable stolen object, the memory
node also has to be freed, so as to make space for new object. We need
to call drm_mm_remove_node while freeing obj.
The below modification patch
On Mon, Apr 07, 2014 at 02:58:34PM -0700, Ben Widawsky wrote:
Blocking important fixes for a test case is harmful to customers of our
software. I won't argue past that. If you won't take it as is, add it to the
JIRA task like you said. I'll carry this one around with my dynamic page table
On Tue, 2014-04-08 at 06:45 +, Chris Wilson wrote:
On Tue, Apr 08, 2014 at 04:32:02AM +, Gupta, Sourab wrote:
Hi Rodrigo,
In this patch, while freeing the purgeable stolen object, the memory
node also has to be freed, so as to make space for new object. We need
to call
On Mon, Apr 7, 2014 at 11:58 PM, Ben Widawsky b...@bwidawsk.net wrote:
Blocking important fixes for a test case is harmful to customers of our
software. I won't argue past that. If you won't take it as is, add it to the
JIRA task like you said. I'll carry this one around with my dynamic page
On Mon, 07 Apr 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Apr 7, 2014 at 4:35 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 7, 2014 at 5:37 AM, Jani Nikula jani.nik...@intel.com wrote:
To support bare address requests used by the drm dp helpers.
Signed-off-by: Jani Nikula
On Tue, Apr 08, 2014 at 07:24:23AM +0100, Chris Wilson wrote:
On Mon, Apr 07, 2014 at 11:20:14PM +0100, Damien Lespiau wrote:
On Mon, Apr 07, 2014 at 01:59:17PM -0700, Ben Widawsky wrote:
Cool. This explains the bad DERRMR values I was seeing in in error
states. I'm honestly didn't check
On Tue, 08 Apr 2014, Daniel J Blueman dan...@quora.org wrote:
Ville et al,
It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
another commit in 3.13.7) broke modes which require DVI-D dual-link,
eg 2560x1440 with my panel.
I don't see these modelines in 3.13.7 or later (eg
On 8 April 2014 15:14, Jani Nikula jani.nik...@linux.intel.com wrote:
On Tue, 08 Apr 2014, Daniel J Blueman dan...@quora.org wrote:
Ville et al,
It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
another commit in 3.13.7) broke modes which require DVI-D dual-link,
eg 2560x1440
On Tue, Apr 8, 2014 at 9:32 AM, Daniel J Blueman dan...@quora.org wrote:
I am using a dual-link DVI-D to DVI-D cable to this monitor, since I
previously couldn't get 2560x1440 via HDMI.
If it isn't this commit, then it may be another commit in 3.13.7,
albeit it feels less likely.
Before we
On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula jani.nik...@intel.com wrote:
Before the conversion to dp aux helpers there was a switch case [1] that
ended up in msg_bytes = 3 for address only start/stop messages
(MODE_I2C_START or MODE_I2C_STOP bit set [2]). With Alex's series in,
but without my
Hi Daniel, dear intel-experts,
again I had the chance to test the latest intel-drm-nightly of the
3.14.0 kernel on the Siemens S6010 with its dreadful nso2501 DVO.
Unfortunately, there are still a couple of issues here, and I also want
to report on some progress and some workarounds.
1) Panning
On Tue, Apr 08, 2014 at 01:22:44AM +0100, Damien Lespiau wrote:
It is now clear that this interrupt is for the primary plane and not
something global to the pipe. It also matches what the spec calls it.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Ville Syrjälä
haswell_write_eld() is also used on broadwell, so let's not explicitely
mention Haswell. The rest of the function has plenty of debug output
which will print the function name, so we know where we are anyway.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote:
Hi Daniel, dear intel-experts,
again I had the chance to test the latest intel-drm-nightly of the
3.14.0 kernel on the Siemens S6010 with its dreadful nso2501 DVO.
Unfortunately, there are still a couple of issues here, and I
On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter
rich...@rus.uni-stuttgart.de wrote:
3) Suspend to RAM: Whether with or without the quirk, s2ram is
non-functioning, but *almost* functioning. The problem on the S6010 is
again the ns2501. Unfortunately, I do not know which of the intel
functions
Am 08.04.2014 13:52, schrieb Daniel Vetter:
On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter
Hm, my X30 also locks up here on resume. What hack do you apply to
make the ns2501 driver get through resume? I don't care about black
screen, but I just wonder whether my X30 has the same issue - atm it
On Tue, 08 Apr 2014, Damien Lespiau damien.lesp...@intel.com wrote:
haswell_write_eld() is also used on broadwell, so let's not explicitely
mention Haswell. The rest of the function has plenty of debug output
which will print the function name, so we know where we are anyway.
Signed-off-by:
Am 08.04.2014 13:37, schrieb Ville Syrjälä:
On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote:
I saw the watermark issue on my S6010 too. I have no good explanation
for it since low value in the register means the watermark is actually
high.
I know )-:
So it's a mystery why
On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote:
On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote:
From: Deepak S deepa...@intel.com
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.
v2: updated commit
On 4/8/2014 6:13 PM, Ville Syrjälä wrote:
On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote:
On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote:
From: Deepak S deepa...@intel.com
We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into
On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula jani.nik...@intel.com wrote:
Before the conversion to dp aux helpers there was a switch case [1] that
ended up in msg_bytes = 3 for address only start/stop messages
(MODE_I2C_START
On Tue, Apr 8, 2014 at 9:09 AM, Christian König deathsim...@vodafone.de wrote:
Am 08.04.2014 15:04, schrieb Alex Deucher:
On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula jani.nik...@intel.com
wrote:
Before the conversion to
Am 08.04.2014 15:04, schrieb Alex Deucher:
On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula jani.nik...@intel.com wrote:
Before the conversion to dp aux helpers there was a switch case [1] that
ended up in msg_bytes = 3 for
On Tue, Apr 08, 2014 at 02:17:10PM +0200, Thomas Richter wrote:
Am 08.04.2014 13:37, schrieb Ville Syrjälä:
On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote:
I saw the watermark issue on my S6010 too. I have no good explanation
for it since low value in the register means
Rodrigo Vivi rodrigo.v...@gmail.com writes:
From: Mika Kuoppala mika.kuopp...@linux.intel.com
Piglit runner and QA are both looking at the dmesg for
DRM_ERRORs with test cases.
Add flag to stop_rings debugfs interface to prevent DRM_ERROR
output when default context banning is being
On Tue, Apr 8, 2014 at 2:05 PM, Thomas Richter
rich...@rus.uni-stuttgart.de wrote:
Am 08.04.2014 13:52, schrieb Daniel Vetter:
On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter
Hm, my X30 also locks up here on resume. What hack do you apply to
make the ns2501 driver get through resume? I don't
On Wed, Mar 26, 2014 at 09:25:12AM +0530, akash.g...@intel.com wrote:
From: Akash Goel akash.g...@intel.com
This patch adds a new drm crtc property for varying the size of
the horizontal vertical borers of the output/display window.
This will control the output of Panel fitter.
v2: Added
Some platforms need additional power domains to be on in addition to the
device D0 state to access the panel registers.
Suggested by Daniel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76987
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 +-
When enabling RPM on VLV, GT power save enabling becomes relatively
frequent, so optimize it a bit.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 66 +
1 file changed, 41 insertions(+), 25 deletions(-)
diff --git
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1e83ae4..02f1b39 100644
---
On Tue, Apr 08, 2014 at 05:31:06PM +0100, Damien Lespiau wrote:
On Mon, Apr 07, 2014 at 04:06:34AM +, Goel, Akash wrote:
Hi Ville,
Please could you review this patch.
You need a pass of checkpatch.pl in here. Not sure what happened with
the coding style.
Ignore this, I was looking
Since the state capture happens from a deferred work, we may drop the
last power domain/RPM reference since the error got triggered (from an
interrupt handler for example). I hit this by writing to the i915_wedged
debugfs file.
Signed-off-by: Imre Deak imre.d...@intel.com
---
Needed by the next patch adding RPM suspend/resume support to VLV.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 192
drivers/gpu/drm/i915/i915_drv.h | 62 +
2 files changed, 254 insertions(+)
diff --git
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d94e10a..84d4298 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++
Adds a function to set the training pattern for Displayport. This is
functionality required to establish more fine-grained control over
the Displayport interface, both for operational reliability and
compliance testing.
Signed-off-by: Todd Previte tprev...@gmail.com
---
This patch set lays the initial groundwork for updating the Displayport link
policy maker
in the i915 driver. These first 5 patches add modular functions that have been
split out
from the larger, monolithic ones present in the driver. The purpose of this
work is the
following:
1)
Adds a function to check the link status across all lanes for Displayport.
This is functionality required to establish more fine-grained control over
the Displayport interface, both for operational reliability and
compliance testing.
Signed-off-by: Todd Previte tprev...@gmail.com
---
Adds a function to execute a single iteration of the clock recovery
sequence for Displayport. This is functionality required to establish
more fine-grained control over the Displayport interface, both for
operational reliability and compliance testing.
Signed-off-by: Todd Previte
Adds a function to enable and disable scrambling directly for the main link.
This is functionality required to establish more fine-grained control over
the Displayport interface, both for operational reliability and
compliance testing.
Signed-off-by: Todd Previte tprev...@gmail.com
---
Adds a function to execute a single iteration of the channel equalization
sequence for Displayport. This is functionality required to establish more
fine-grained control over the Displayport interface, both for operational
reliability and compliance testing.
Signed-off-by: Todd Previte
On Mon, Apr 07, 2014 at 06:21:08PM -0300, Paulo Zanoni wrote:
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We may have use for vblank interrupts during plane enabling/disabling, so
don't call drm_vblank_off() until planes are
On Mon, Apr 07, 2014 at 04:06:34AM +, Goel, Akash wrote:
Hi Ville,
Please could you review this patch.
You need a pass of checkpatch.pl in here. Not sure what happened with
the coding style.
--
Damien
___
Intel-gfx mailing list
On Mon, Apr 07, 2014 at 05:27:41PM -0300, Paulo Zanoni wrote:
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Rather than have a wait_for_vblank() in the primary plane enable/disable
funcs, move the wait_for_vblank() to happen
These will be needed by the upcoming VLV RPM helpers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_reg.h | 10 --
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
For simplicity take the init power domain, which puts the device into D0
and turns on all display power wells.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
drivers/gpu/drm/i915/i915_sysfs.c | 4
2 files changed, 19
This adds the required helpers for saving/restoring HW context when
going to D3 (and possibly to S0ix afterwards) state on VLV and then
enables RPM.
Since we depend on the RC6 power context mechanism to save some state
this also touches generic RPM parts, so that RPM is only enabled after
the
Not clearing this flag causes spurious interrupts at least in D3 state,
so before enabling RPM we need to fix this. We were already setting this
flag when enabling interrupts, only clearing it was missing.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1
This will be needed by the VLV RPM helpers too.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 32
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16 ++--
3 files changed, 35
The parsing was incorrect for ILK and VLV.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a0527a1..869a4e3 100644
On VLV we depend on RC6 saving the GT render and media HW context before
going to D3 state, so disable RPM if RC6 is not enabled.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 29 -
2
At least on some platforms we depend on RC6 being enabled for RPM, so
disable RPM until the delayed RC6 enabling completes. For simplicity
don't differentiate between platforms, those that don't have this
dependency will enable RC6 only rarely during driver init and system
resume.
Signed-off-by:
Needed by the VLV S0ix context save/restore helpers.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Add runtime PM support for VLV, but leave it disabled. The next patch
enables it.
The suspend/resume sequence used is based on [1] and [2]. In practice we
depend on the GT RC6 mechanism to save the HW context depending on the
render and media power wells. By the time we run the runtime suspend
Hi
2014-04-08 14:47 GMT-03:00 Todd Previte tprev...@gmail.com:
Adds a function to set the training pattern for Displayport. This is
functionality required to establish more fine-grained control over
the Displayport interface, both for operational reliability and
compliance testing.
Just a
On Mon, Apr 07, 2014 at 10:13:13PM -0700, Jesse Barnes wrote:
On Mon, 7 Apr 2014 23:25:20 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Jesse's BIOS fb reconstruction code actually relies on the -ENOSPC
return value to detect overlapping framebuffers (which the bios uses
always when
On 08.04.2014 18:10, Daniel Vetter wrote:
On Tue, Apr 8, 2014 at 2:05 PM, Thomas Richter
Also, from the linux suspend mechanism, /usr/lib/pm-utils/sleep.d/99video is
just useless or breaks more than it helps. I just removed it. It tries some
weird workarounds that are not beneficial, and the
This is based on the not yet merged dri3 branch,
it simply adds a log message to avoid user confusion.
Adel Gadllah (1):
dri3: Print log message
src/uxa/intel_dri3.c | 2 +-
src/uxa/intel_driver.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
--
1.9.0
Whe currently only print a direct rendering: DRI2 Enabled which seems to
confuse people so add a DRI3 enabled message as well when successfully
initalizing dri3.
Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
Reviewed-by: Keith Packard kei...@keithp.com
---
src/uxa/intel_dri3.c | 2 +-
From: Brad Volkin bradley.d.vol...@intel.com
The command parser in newer kernels will reject it and setting this
bit is not required for the actual test case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76670
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
Hi Daniel, we've merged the kernel change for this but not the test. I'm
assuming we still want the test case.
Brad
On Thu, Mar 27, 2014 at 11:44:45AM -0700, Volkin, Bradley D wrote:
From: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Brad Volkin bradley.d.vol...@intel.com
---
v2:
- make it actually compile, I managed to send the wrong version as v1
somehow
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 --
drivers/gpu/drm/i915/i915_sysfs.c | 4
2 files changed, 20 insertions(+), 2 deletions(-)
diff
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 31
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 9
Create and attach the drm property to set aspect ratio. If there is no user
specified value, then PAR_NONE/Automatic option is set by default. User can
select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would
come into effect with a mode set.
Signed-off-by: Vandana Kannan
From: Brad Volkin bradley.d.vol...@intel.com
These are additional registers needed for performance monitoring and
ARB_draw_indirect extensions in mesa.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76719
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Brad Volkin
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space
driver/middleware.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.
As every BSD ring is powerful, it is enough to
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bdda3b5..d5b1dd3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++
This is the patch set that tries to add the support of dual BSD rings on BDW
GT3. Based on hardware spec, the BDW GT3 has two independent BSD rings, which
can be used to process the video commands. To be simpler, it is transparent
to user-space driver/middleware. In such case the kernel driver
Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4 +--
drivers/gpu/drm/i915/i915_drv.h |
The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c |1 +
1 file changed, 1
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
Ville et al,
On 8 April 2014 16:02, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, Apr 8, 2014 at 9:32 AM, Daniel J Blueman dan...@quora.org wrote:
I am using a dual-link DVI-D to DVI-D cable to this monitor, since I
previously couldn't get 2560x1440 via HDMI.
If it isn't this commit,
On Tue, Apr 8, 2014 at 5:32 PM, Daniel J Blueman dan...@quora.org wrote:
On 8 April 2014 15:14, Jani Nikula jani.nik...@linux.intel.com wrote:
On Tue, 08 Apr 2014, Daniel J Blueman dan...@quora.org wrote:
Ville et al,
It looks like commit e3ea8fa6beaf55fee64bf816f3b8a80ad733b2c2 (or
another
On Tue, Apr 08, 2014 at 07:50:39AM +0100, Chris Wilson wrote:
On Mon, Apr 07, 2014 at 02:58:34PM -0700, Ben Widawsky wrote:
Blocking important fixes for a test case is harmful to customers of our
software. I won't argue past that. If you won't take it as is, add it to the
JIRA task like you
On Tue, Apr 08, 2014 at 08:53:15AM +0200, Daniel Vetter wrote:
On Mon, Apr 7, 2014 at 11:58 PM, Ben Widawsky b...@bwidawsk.net wrote:
Blocking important fixes for a test case is harmful to customers of our
software. I won't argue past that. If you won't take it as is, add it to the
JIRA
On Tue, Apr 08, 2014 at 06:22:52PM +0530, S, Deepak wrote:
On 4/8/2014 6:13 PM, Ville Syrjälä wrote:
On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote:
On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote:
From: Deepak S deepa...@intel.com
We need do forcewake before
On 4/9/2014 9:43 AM, Ben Widawsky wrote:
On Tue, Apr 08, 2014 at 06:22:52PM +0530, S, Deepak wrote:
On 4/8/2014 6:13 PM, Ville Syrjälä wrote:
On Mon, Apr 07, 2014 at 02:36:20PM -0700, Ben Widawsky wrote:
On Mon, Apr 07, 2014 at 05:01:46PM -0300, Rodrigo Vivi wrote:
From: Deepak S
78 matches
Mail list logo
