https://bugs.freedesktop.org/show_bug.cgi?id=63865
--- Comment #10 from Christian Heinz ---
Created attachment 78765
--> https://bugs.freedesktop.org/attachment.cgi?id=78765&action=edit
AMD E-450 APU video BIOS
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=63865
--- Comment #9 from Christian Heinz ---
(In reply to comment #8)
> It looks like you are using a bogus unposted vbios image. I think you'll
> need to bisect. If I had to guess, I'd say it's related to some change in
> how the pci rom images are
On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote:
> This patch modifies the driver to perform two stage parsing of video
> timings from device tree, to get timing information as struct videomode,
> which contains more data than struct fb_videomode.
>
> Thanks to this change, information
https://bugzilla.kernel.org/show_bug.cgi?id=50941
JP Pozzi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This patch modifies the driver to perform two stage parsing of video
timings from device tree, to get timing information as struct videomode,
which contains more data than struct fb_videomode.
Thanks to this change, information about polarity of control signals
(VSYNC, HSYNC, VDEN, VCLK) can be re
The FIMD block present on S3C6400/S3C6410 SoCs is compatible with this
driver, so it can be supported by it as well.
This patch adds appropriate device IDs and driver data to enable this
driver for S3C64xx SoCs.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
Some platforms that can be supported this driver has additional clock
source selection bits in VIDCON0 register that allows to select which
clock should be used to drive the pixel clock: bus clock or special
clock.
Since this driver assumes that special clock always drives the pixel
clock, this pa
Some platforms that can be supported with this driver have PRTCON
register instead of SHADOWCON, which requires slightly different
handling.
This patch factors out all register shadow control code from the driver
and adds a function to control register shadowing appropriately,
depending on driver
This patch adds pointer to driver data to fimd_context structure, to
remove the need to call drm_fimd_get_driver_data() each time access to
driver data is necessary.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Much of the code in Exynos DRM subsystem is generic enough to use
it for older (non-Exynos) Samsung SoCs as well, after minor modifications.
This series starts adding support for previous SoCs to Exynos DRM by
introducing S3C64xx support to exynos_drm_fimd driver.
Adding support for remaining SoC
From: Dave Airlie
Port over the mgag200 fix to cirrus as it suffers the same issue.
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it mak
From: Dave Airlie
Port over the mgag200 fix to ast as it suffers the same issue.
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it makes
From: Dave Airlie
On F19 testing, it was noticed we get a lot of errors in dmesg
about being unable to reserve the buffer when plymouth starts,
this is due to the buffer being in the process of migrating,
so it makes sense we can't reserve it.
In order to deal with it, this adds delayed updates
This stores up dirty updates to the fbdev until the next update after
the buffer has finished moving, otherwise you'd see a lot of failed
to reserve bo during bootup with plymouth was starting.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedeskto
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/047df5dd/attachment-0001.html>
Hi Linus,
The 3.10 pull request for dma-buf framework updates: small one, could
you please pull?
Thanks and best regards,
~Sumit.
The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f:
Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700)
are available
Hi !
Yes, I'm a newbie, so to introduce myself. I have some programming
knowledge from long ago and have dealt with databases, C,
Assembler, Pascal and others.
I've noticed lately, as I'm sure as you all have, about the dramatic
increase in GPU processing capability. Cuda, openGL, openCL etc.
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/fb4b704a/attachment.html>
On Thu, May 2, 2013 at 10:41 AM, Daniel Vetter wrote:
> On Thu, May 2, 2013 at 2:02 AM, Borislav Petkov wrote:
>> Hi,
>>
>> I'm seeing this when booting latest Linus tree + tip/master in kvm.
>> Config is attached. Looks like it cannot find root fs and panics and
>> calls the panic notifier which
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Laurent Bonnaud changed:
What|Removed |Added
CC||Laurent.Bonnaud at inpg.fr
--- Comm
On Thu, May 2, 2013 at 2:02 AM, Borislav Petkov wrote:
> Hi,
>
> I'm seeing this when booting latest Linus tree + tip/master in kvm.
> Config is attached. Looks like it cannot find root fs and panics and
> calls the panic notifier which screams in drm_crtc.c because not all
> modeset locks are tak
On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote:
> On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 6be940e..2e44733 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/2c3c9291/attachment.html>
no old libraries).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/8e992416/attachment.html>
sts.freedesktop.org/archives/dri-devel/attachments/20130501/77edf240/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/7624f36c/attachment.html>
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/1dbe4161/attachment.html>
From: Alex Deucher
The code was mis-handling variable sizes arrays.
Reported-by: Sylvain BERTRAND
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/g
ion/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/ca132d1f/attachment.pgp>
Since we ask the dmabuf owner to map the dma-buf into our device
address space, but for udl at present that is the CPU address space,
since we don't DMA directly from the mapped buffer.
However if we don't set a dma mask on the usb device, the mapping
ends up using swiotlb on machines that have it
From: Dave Airlie
Sometimes that extra semicolon can really be hard to spot.
Cc: Imre Deak
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i
https://bugzilla.kernel.org/show_bug.cgi?id=50941
JP Pozzi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
desktop.org/archives/dri-devel/attachments/20130501/aedfe730/attachment.html>
On Tue, Apr 30, 2013 at 7:22 PM, Sylvain BERTRAND wrote:
> Hi,
>
> In radeon_atombios.c file, radeon_atombios_parse_power_table_6
> function, the power state is selected using the state array index:
>
> power_state = (union pplib_power_state *)&state_array->states[i];
>
> The state array has varia
On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote:
> This patch modifies the driver to perform two stage parsing of video
> timings from device tree, to get timing information as struct videomode,
> which contains more data than struct fb_videomode.
>
> Thanks to this change, information
us on the targets/components that truly matter for the scons/autotools
users.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/51edd7d7/attachment.html>
On Wed, Apr 24, 2013 at 11:35 PM, Laura Abbott wrote:
> Hi all,
>
> I've been looking at a better way to do custom dma allocation algorithms in
> a similar style to Ion heaps. Most drivers/clients have come up with a
> series of semi-standard ways to get memory (CMA, memblock_reserve,
> discontigu
https://bugs.freedesktop.org/show_bug.cgi?id=61747
--- Comment #12 from Chris Rankin ---
Created attachment 78735
--> https://bugs.freedesktop.org/attachment.cgi?id=78735&action=edit
dmesg output showing GPU lockup
No, it doesn't appear to. I compiled this version of Mesa after recompiling
lib
This patch modifies the driver to perform two stage parsing of video
timings from device tree, to get timing information as struct videomode,
which contains more data than struct fb_videomode.
Thanks to this change, information about polarity of control signals
(VSYNC, HSYNC, VDEN, VCLK) can be re
The FIMD block present on S3C6400/S3C6410 SoCs is compatible with this
driver, so it can be supported by it as well.
This patch adds appropriate device IDs and driver data to enable this
driver for S3C64xx SoCs.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
Some platforms that can be supported this driver has additional clock
source selection bits in VIDCON0 register that allows to select which
clock should be used to drive the pixel clock: bus clock or special
clock.
Since this driver assumes that special clock always drives the pixel
clock, this pa
Some platforms that can be supported with this driver have PRTCON
register instead of SHADOWCON, which requires slightly different
handling.
This patch factors out all register shadow control code from the driver
and adds a function to control register shadowing appropriately,
depending on driver
This patch adds pointer to driver data to fimd_context structure, to
remove the need to call drm_fimd_get_driver_data() each time access to
driver data is necessary.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Much of the code in Exynos DRM subsystem is generic enough to use
it for older (non-Exynos) Samsung SoCs as well, after minor modifications.
This series starts adding support for previous SoCs to Exynos DRM by
introducing S3C64xx support to exynos_drm_fimd driver.
Adding support for remaining SoC
From: Alex Deucher
The code was mis-handling variable sizes arrays.
Reported-by: Sylvain BERTRAND
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
On Wed, May 1, 2013 at 6:30 AM, Dave Airlie wrote:
> Since we ask the dmabuf owner to map the dma-buf into our device
> address space, but for udl at present that is the CPU address space,
> since we don't DMA directly from the mapped buffer.
>
> However if we don't set a dma mask on the usb devic
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+)
Add missing calls, and fix a leak from forgetting to call the unpin function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 3b6dc88..9750bb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/dri
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_gem.h | 1 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 9 -
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
ind
Changes since v1:
- Fixup compiler warning in unpin function.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 ++
drivers/gpu/drm/radeon/radeon_prime.c | 18 +-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --g
This allows importing bo's to own device to work without requiring that the
buffer is pinned in GART.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
d
Prevents buffers from being pinned forever.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 13 +++--
include/drm/drmP.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Laurent Bonnaud changed:
What|Removed |Added
CC||laurent.bonn...@inpg.fr
--- Comment
On Wed, May 1, 2013 at 6:37 AM, Stephen Rothwell
wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from the drm tree and commit
> 72419203cab9 ("dr
On Tue, Apr 30, 2013 at 7:22 PM, Sylvain BERTRAND wrote:
> Hi,
>
> In radeon_atombios.c file, radeon_atombios_parse_power_table_6
> function, the power state is selected using the state array index:
>
> power_state = (union pplib_power_state *)&state_array->states[i];
>
> The state array has varia
https://bugs.freedesktop.org/show_bug.cgi?id=64124
--- Comment #1 from Alan Swanson ---
Created attachment 78730
--> https://bugs.freedesktop.org/attachment.cgi?id=78730&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=64124
Priority: medium
Bug ID: 64124
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] aruba crash with 32bit applications on 64bit
kernel
Severity: normal
Classificat
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #4 from Michel Dänzer ---
(In reply to comment #3)
> FWIW, I made patches which remove radeon drivers from the scons build 2
> years ago and some people weren't very happy about it.
At the time, the make based build system didn't sup
On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote:
> On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 6be940e..2e44733 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Jerome Glisse changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #3 from Marek Olšák ---
FWIW, I made patches which remove radeon drivers from the scons build 2 years
ago and some people weren't very happy about it. I think we shouldn't support 2
build systems for Linux-only drivers.
--
You are r
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #9 from Michel D?nzer 2013-05-01 07:49:06
---
(In reply to comment #8)
> According to powertop it saves about 0.5W or a little bit more.
That's just from not enabling backing store? Not bad, considering backing store
is basicall
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #8 from Nick 2013-05-01 07:32:39 ---
According to powertop it saves about 0.5W or a little bit more. Not a
break-thru but still useful. Thanks!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/3ad58474/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64096
--- Comment #2 from vincent ---
Created attachment 78720
--> https://bugs.freedesktop.org/attachment.cgi?id=78720&action=edit
Disable bank_swizzle
Hi,
there is a bug that makes mesa change bank_swizzle if they are provided by
backend,
can you
>> Except in the cases where it doesn't do what you want, and possibly in
>> the future where it does less of what you want. You've started on a
>> slippery slope, and I'm stopping you before you make things worse.
>>
>> You are going to have to get SoC kernel drivers to add an ioctl that
>> you ca
https://bugs.freedesktop.org/show_bug.cgi?id=48694
--- Comment #2 from José Fonseca ---
I'm fine droping radeon from scons build.
Neither of the two build systems (scons / autotools) will go away any time
soon, so instead of trying to build evertyhing with both, it makes more sense
to focus on t
Hi Linus,
The 3.10 pull request for dma-buf framework updates: small one, could
you please pull?
Thanks and best regards,
~Sumit.
The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f:
Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700)
are available
https://bugs.freedesktop.org/show_bug.cgi?id=38856
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
ebugMessageInsertARB during my application.
If you need any more information, please ask.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-dev
On Wed, Apr 24, 2013 at 11:35 PM, Laura Abbott wrote:
> Hi all,
>
> I've been looking at a better way to do custom dma allocation algorithms in
> a similar style to Ion heaps. Most drivers/clients have come up with a
> series of semi-standard ways to get memory (CMA, memblock_reserve,
> discontigu
On Wed, May 1, 2013 at 6:30 AM, Dave Airlie wrote:
> Since we ask the dmabuf owner to map the dma-buf into our device
> address space, but for udl at present that is the CPU address space,
> since we don't DMA directly from the mapped buffer.
>
> However if we don't set a dma mask on the usb devic
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
1 file changed, 2 insertions(+)
Add missing calls, and fix a leak from forgetting to call the unpin function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 3b6dc88..9750bb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/dri
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_gem.h | 1 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 9 -
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
ind
Changes since v1:
- Fixup compiler warning in unpin function.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 ++
drivers/gpu/drm/radeon/radeon_prime.c | 18 +-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --g
This allows importing bo's to own device to work without requiring that the
buffer is pinned in GART.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
d
Prevents buffers from being pinned forever.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 13 +++--
include/drm/drmP.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/g
Hi,
In radeon_atombios.c file, radeon_atombios_parse_power_table_6
function, the power state is selected using the state array index:
power_state = (union pplib_power_state *)&state_array->states[i];
The state array has variable sized states which size should be
computed as said in the atombios.
On Wed, May 1, 2013 at 6:37 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
> Make data/link N value power of two") from the drm tree and commit
> 72419203cab9 ("drm
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #9 from Michel Dänzer 2013-05-01 07:49:06 ---
(In reply to comment #8)
> According to powertop it saves about 0.5W or a little bit more.
That's just from not enabling backing store? Not bad, considering backing store
is basically
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #8 from Nick 2013-05-01 07:32:39 ---
According to powertop it saves about 0.5W or a little bit more. Not a
break-thru but still useful. Thanks!
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
86 matches
Mail list logo
