https://bugzilla.kernel.org/show_bug.cgi?id=177041
Bug ID: 177041
Summary: When browsing Google Map's Satellite view in Chrome
or Firefox the screen freezes and goes black,
occasionally control is returned to user
Product:
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c682bc..6191baf
Thanks to Paulo Zanoni for indirectly pointing this out.
Looks like we never actually added any code for checking whether or not
we actually wrote watermark levels properly. Let's fix that.
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i9
Helper we're going to be using for implementing verification of the wm
levels in skl_verify_wm_level().
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 14 ++
2 files c
There's not much of a reason this should have the locations to read out
the hardware state hardcoded, so allow the caller to specify the
location and add this function to intel_drv.h. As well, we're going to
need this function to be reusable for the next patch.
Signed-off-by: Lyude
Cc: Maarten La
Finally, add some debugging output for ddb changes in the atomic debug
output. This makes it a lot easier to spot bugs from incorrect ddb
allocations.
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 57
Now that we've make skl_wm_levels make a little more sense, we can
remove all of the redundant wm information. Up until now we'd been
storing two copies of all of the skl watermarks: one being the
skl_pipe_wm structs, the other being the global wm struct in
drm_i915_private containing the raw regis
This function is a wreck, let's help it get it's life back together and
cleanup all of the copy pasta here.
(adding Maarten's reviewed-by since this is just a split-up version of one
of the previous patches)
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zano
Having skl_wm_level contain all of the watermarks for each plane is
annoying since it prevents us from having any sort of object to
represent a single watermark level, something we take advantage of in
the next commit to cut down on all of the copy paste code in here.
Changes since v1:
- Style nit
Next part of cleaning up the watermark code for skl. This is easy, since
it seems that we never actually needed to keep track of the linetime in
the skl_wm_values struct anyway.
Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
First part of cleaning up all of the skl watermark code. This moves the
structures for storing the ddb allocations of each pipe into
intel_crtc_state, along with moving the structures for storing the
current ddb allocations active on hardware into intel_crtc.
Changes since v1:
- Don't replace allo
While it (mostly) works, the code for handling watermarks on Skylake has been
kind of ugly for a while. As well a lot of it isn't that friendly to atomic
transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
full cleanup, it's a good start. As well, we add a couple of featu
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/c5873c1b/attachment.html>
as scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/d9e9b343/attachment.html>
On Thu, Oct 06, 2016 at 02:49:34PM +0100, Emil Velikov wrote:
> On 28 September 2016 at 15:27, wrote:
> > From: Ville Syrjälä
> >
> > Devices can have multiple planes, so allow the user to choose between
> > them.
> >
> > Signed-off-by: Ville Syrjälä
> In the long term I'm wondering if we d
ing this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/ff02ba99/attachment.html>
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/8bd4a744/attachment.html>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/95848ce1/attachment-0001.html>
Hi Emil,
On Thu, 06 Oct 2016, Emil Velikov wrote:
> On 6 October 2016 at 10:37, Peter Griffin wrote:
>
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
>
> "This option is selected by
On Thu, Sep 29, 2016 at 11:29 AM, Bibby Hsieh
wrote:
>
> Clean the interrupt status before enable interrupt
> and set the vblank_disable_allowed to fix the issue.
For the series:
Reviewed-by: Daniel Kurtz
>
> Bibby Hsieh (2):
> drm/mediatek: set vblank_disable_allowed to true
> drm/mediat
ot;
Identifier "Radeon"
Driver "radeon"
Option "SwapBufferWait" "0"
Option "DRI" "3"
EndSection
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/50fdf37f/attachment.html>
On 14 September 2016 at 15:19, Robert Bragg wrote:
> In particular this tries to capture for posterity some of the early
> challenges we had with using the core perf infrastructure in case we
> ever want to revisit adapting perf for device metrics.
>
> Cc: Chris Wilson
> Signed-off-by: Robert Bra
On 14 September 2016 at 15:19, Robert Bragg wrote:
> This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
> and 'sampler balance' metric sets for Haswell.
>
> The code is auto generated from an XML description of metric sets,
> currently maintained in gputop, ref:
>
> https://
On 14 September 2016 at 15:19, Robert Bragg wrote:
> The minimal sampling period is now configurable via a
> dev.i915.oa_min_timer_exponent sysctl parameter.
>
> Following the precedent set by perf, the default is the minimum that
> won't (on its own) exceed the default kernel.perf_event_max_sampl
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Consistent with the kernel.perf_event_paranoid sysctl option that can
> allow non-root users to access system wide cpu metrics, this can
> optionally allow non-root users to access system wide OA counter metrics
> from Gen graphics hardware.
>
>
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Each metric set is given a sysfs entry like:
>
> /sys/class/drm/card0/metrics//id
>
> This allows userspace to enumerate the specific sets that are available
> for the current system. The 'id' file contains an unsigned integer that
> can be used
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via the
> i915 perf interface.
>
> Cc: Ch
Hi folks,
I'm seeing a repeatable crash on my HP EliteBook 840 G2/2216 when
booting it while in a docking station connected to two external
DisplayPort monitors, undocking, and then either logging out or
shutting down -- regardless of whether I've redocked it beforehand or
not. Both logout and shu
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Adds a static OA unit, MUX + B Counter configuration for basic render
> metrics on Haswell. This is auto generated from an XML
> description of metric sets, currently maintained in gputop, ref:
>
> https://github.com/rib/gputop
> > gputop-da
On 14 September 2016 at 15:19, Robert Bragg wrote:
> OACONTROL changes quite a bit for gen8, with some bits split out into a
> per-context OACTXCONTROL register. Rename now before adding more gen7 OA
> registers
>
> Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
On 14 September 2016 at 16:32, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system cal
Hi Andrzej,
Thank you for the patch.
On Friday 07 Oct 2016 09:02:42 Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it d
Hi Andrzej,
Thank you for the patch.
On Friday 07 Oct 2016 09:02:41 Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
> via I2C bus.
>
> Signed-off-by: Andrzej Hajda
> Acked-by: Rob Herring
> ---
> .../bindings/video/bridge/sil-sii8620.txt
On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel
wrote:
> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that
> both GF 100 and NV50 are affected by the same issue, and that a related issue
> has been solved already for Tegra in commit 9d0394c6bed5
> ("drm/nouveau/instmem/g
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/90517f4e/attachment.html>
Hi Maxime,
Thank you for the patch.
On Friday 30 Sep 2016 16:37:06 Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on either
> DACs or resistor ladders.
A resistor ladder is a DAC :-)
> Those might or might not have an i2c bus routed to the VGA connector in
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/2aa1d46c/attachment.html>
ly freezing while closing
fullscreen, that's the killer one.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/6a63f794/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/21e7ee11/attachment.html>
Rob,
how do you know which devices are concerned when listing the constraints ?
Does combine_capabilities is done from each allocation or can it be cached ?
Regards,
Benjmain
2016-10-06 18:54 GMT+02:00 Rob Clark :
> so there is discussion about a "central userspace allocator" (ie. more
> like a
ent was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/1be7c935/attachment-0001.html>
from Mike Lothian ---
Out of interest which compositor are you using?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161
the bug is.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/47f09768/attachment.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/86eb9c75/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/33a79b51/attachment.html>
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/d8eee132/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161007/3703cbe6/attachment.html>
ou are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/0691f115/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/ed8e80c7/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/8f05f10d/attachment.html>
Hi
This has discussion has gone a little quiet
Was there any agreement about what needed doing to get this working
for i965/amdgpu?
Regards
Mike
On Mon, 26 Sep 2016 at 09:04 Daniel Vetter wrote:
>
> On Mon, Sep 26, 2016 at 09:48:37AM +0900, Michel Dänzer wrote:
> > On 23/09/16 09:09 PM, Dani
ves/dri-devel/attachments/20161007/59bcd7f1/attachment.html>
Hi Archit,
On Friday 07 Oct 2016 10:27:31 Archit Taneja wrote:
> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> > On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
> >> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> >>> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
> On
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161007/a3e80adc/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/81fbf841/attachment.html>
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/49c9839d/attachment-0001.gz>
ple" here is supposed to mean that it's an unconfigurable RGB to
> >>>>VGA DAC. This isn't supposed to follow the simple-panel model, where
> >>>>you add the "simple-panel" string in the compatible node, along with
> >>>>you chip specific compatible string.
> >>>
> >>>I agree with Maxime, I don't like the word "simple". My preference would
> >>>be "vga-dac" for a lack of a better qualifier than "simple" to describe
> >>>the fact that the device requires no configuration. My only concern with
> >>>"vga-dac" is that we would restrict usage of that compatible string for a
> >>>subset of VGA DACs, with more complex devices not being compatible with
> >>>"vga-dac" even though they are VGA DACs. That's a problem I can live with
> >>>though.
> >>
> >>While we're bikeshedding (feel free to ignore my input on this), I
> >>think Maxime's initial "dumb" qualifier was better than "simple".
> >
> >I think I agree.
> >
> >>I think "passive" also gets the point across better than "simple", which
> >>we've already established as something else in drm.
> >
> >To my electrical engineer's ear, passive refers to a component or combination
> >of components that is not capable of power gain. The resistors ladder VGA DAC
> >that Maxime is trying to support is a passive system, but the ADV7123 VGA DAC
> >that equally requires no configuration is an active component.
>
> If no one has any more objections within the next day, I'll pull in
> Maxime's v5 RGB to VGA bridge driver, and change the compatible to
> "dumb-vga-dac".
That works for me. You'll probably want to update the Kconfig and file
name to match though.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/cac9efa7/attachment-0001.sig>
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/6ea12fe3/attachment.sig>
x and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/265db26f/attachment.sig>
nel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/a94a036f/attachment.sig>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/36a9c4bb/attachment.html>
drm_atomic_state has a complicated single owner model that tracks the
single reference from allocation through to destruction on another
thread - or perhaps on a local error path. We can simplify this tracking
by using reference counting (at a cost of a few more atomics). This is
even more benefici
probably should keep the discussion on github (USAGE.md was updated a
bit more and merged into https://github.com/cubanismo/allocator so
look there for the latest)..
but briefly:
1) my expectation is if the user is implementing some use-case, it
knows what devices and APIs are involved, otherwise
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/ea01852f/attachment.sig>
On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> Hi Sean,
>
> On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
>> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
>>> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> On Mon, Oct
We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
resources allocated with 'ida_simple_get()'.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/drm_connector.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interfac
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
via I2C bus.
Signed-off-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/video/bridge/sil-sii8620.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/dev
This header adds definitions specific to MHL protocol.
Signed-off-by: Andrzej Hajda
---
v4: file moved to include/drm/bridge
---
include/drm/bridge/mhl.h | 292 +++
1 file changed, 292 insertions(+)
create mode 100644 include/drm/bridge/mhl.h
diff --
Hi Archit,
In the 4th iteration the only change is relocation of mhl.h file to
include/drm/bridge.
Regards
Andrzej
Andrzej Hajda (3):
video: add header file for Mobile High-Definition Link (MHL) interface
dt-bindings: add Silicon Image SiI8620 bridge bindings
drm/bridge: add Silicon Imag
vel/attachments/20161007/14275b59/attachment.html>
/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43764 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/f5197011/attachment-0001.gz>
43764 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/69fdaa41/attachment-0001.gz>
https://bugzilla.kernel.org/show_bug.cgi?id=153911
--- Comment #2 from be11f157cd19c4a2ba1e9c70a38b1a74 at protonmail.com ---
I apologize for exaggerating the bug. It is not as severe as I described
previously but more than a inconvenience. Here's the output of a dmesg from
kernel 4.8:
[18530.25
vel/attachments/20161007/e610838f/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161007/ae65fed5/attachment.html>
07.10.2016, 00:06, "Chen-Yu Tsai" :
> Sinlinx SinA31s comes with an optional 7" 1024x600 LCD panel with
> capacitive touch panel that bolts on to the board.
>
> Enable the display using a panel with close timings. This patch is more
> of a proof of concept. The LCD panel has no markings whatsoeve
Sinlinx SinA31s comes with an optional 7" 1024x600 LCD panel with
capacitive touch panel that bolts on to the board.
Enable the display using a panel with close timings. This patch is more
of a proof of concept. The LCD panel has no markings whatsoever, and
the timings are not exactly the same, an
The LCD0 controller on the A31 can do RGB output up to 8 bits per
channel. Add the pins for RGB888 output.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6
The A31 has 2 parallel display pipelines, which can be intermixed.
However the driver currently only supports one of them.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 152 ++
arch/arm/boot/dts/sun6i-a31s.dtsi | 8 ++
2 files changed,
The pinmux setting nodes for the A31 were added out of alphabetical
order. Sort them.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 82
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b
The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
also has new display enhancement blocks, such as the DRC (Dynamic Range
Controller), the DEU (Display Enhancement Unit), and the CMU (Color
Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels.
The A31s displa
The A31 TCON has mux controls for how TCON outputs are routed to the
HDMI and MIPI DSI blocks.
Since the A31s does not have MIPI DSI, it only has a mux for the HDMI
controller input.
This patch only adds support for the compatible strings. Actual support
for the mux controls should be added with
In commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate") the
driver was rounding the requested clock rate and then checking the
result against the original requested rate.
This does not work well for a number of reasons:
- The pixel clock does not have enough resolution to be able to
We already have some differences between the 2 supported SoCs.
More will be added as we support other SoCs. To avoid bloating
the probe function with even more conditionals, move the quirks
to a separate data structure that's tied to the compatible string.
Signed-off-by: Chen-Yu Tsai
---
drivers
The A31 and A31s also have the DRC as part of the display pipeline.
As we know virtually nothing about them, just add compatible strings
for both SoCs to the stub driver.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
drivers/gpu/drm/sun4i/s
Hi everyone,
This series adds support for the first display pipeline found on the
A31 and A31s SoCs, with output through the RGB LCD interface.
This has been tested on the Sinlinx SinA31s development board, with
its included 7" LCD panel (see last patch), and the Merrii Hummingbird
A31 developmen
Hi Sean,
On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> > On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
> >> On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> >>> On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> >>
88 matches
Mail list logo
