On Tue, Aug 20, 2024 at 12:09 AM Vignesh Raman
wrote:
>
> Set the timeout of all drm-ci jobs to 1h30m since
> some jobs takes more than 1 hour to complete.
>
> Signed-off-by: Vignesh Raman
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/ci/test.yml | 5 -
> 1 file cha
lso clarify the intended semantics of
> other memory categories.
>
> v2:
> * Also mark drm-memory- as deprecated.
> * Add some more text describing memory categories. (Alex)
>
> v3:
> * Semantics of the amdgpu drm-memory is actually as drm-resident.
>
> Signed-
From: Rob Clark
Simplify the exec path (removing a legacy optimization) and convert to
drm_exec. One drm_exec patch to allow passing in the expected # of GEM
objects to avoid re-allocation.
I'd be a bit happier if I could avoid the extra objects table allocation
in drm_exec in the first
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers
On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote:
>
> On Tue, Nov 28, 2023 at 9:17 AM Christian König
> wrote:
> >
> > Am 17.11.23 um 20:56 schrieb Alex Deucher:
> > > Add shared stats. Useful for seeing shared memory.
> > >
> > > Signed-off-by: Alex Deucher
> > > ---
> > > drivers/gpu/drm/
On Thu, Nov 30, 2023 at 5:13 AM Christian König
wrote:
>
> Am 28.11.23 um 18:52 schrieb Rob Clark:
> > On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote:
> >> On Tue, Nov 28, 2023 at 9:17 AM Christian König
> >> wrote:
> >>> Am 17.11.23 um 20:56 sch
On Thu, Dec 7, 2023 at 10:02 AM Alex Deucher wrote:
>
> Show buffers as shared if they are shared via dma-buf as well
> (e.g., shared with v4l or some other subsystem).
>
> Signed-off-by: Alex Deucher
> Cc: Rob Clark
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm
On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov
wrote:
>
> On 03/08/2021 12:06, Thomas Zimmermann wrote:
> > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> > don't benefit from using it.
> >
> > DRM IRQ call
On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov
wrote:
>
> On 03/08/2021 12:06, Thomas Zimmermann wrote:
> > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> > IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> > don't benefit from using it.
> >
> > DRM IRQ call
On Sat, Aug 7, 2021 at 11:40 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 07.08.21 um 19:08 schrieb Rob Clark:
> > On Tue, Aug 3, 2021 at 2:37 AM Dmitry Baryshkov
> > wrote:
> >>
> >> On 03/08/2021 12:06, Thomas Zimmermann wrote:
> >>> Drop
I stumbled across this thread when I ran into the same issue, while
working out how to move drm/msm to use scheduler's retire +
timeout/recovery (and get rid of our own mirror list of in-flight
jobs). We already have hw error detection enabled, and it can signal
quite fast, so assuming the first j
On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote:
>
> On Mon, Nov 08, 2021 at 03:39:17PM -0800, Rob Clark wrote:
> > I stumbled across this thread when I ran into the same issue, while
> > working out how to move drm/msm to use scheduler's retire +
> > timeout/rec
On Wed, Nov 10, 2021 at 1:50 AM Daniel Vetter wrote:
>
> On Tue, Nov 09, 2021 at 08:17:01AM -0800, Rob Clark wrote:
> > On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote:
> > >
> > > On Mon, Nov 08, 2021 at 03:39:17PM -0800, Rob Clark wrote:
> > > > I s
From: Rob Clark
Simplify the exec path (removing a legacy optimization) and convert to
drm_exec. One drm_exec patch to allow passing in the expected # of GEM
objects to avoid re-allocation.
I'd be a bit happier if I could avoid the extra objects table allocation
in drm_exec in the first
From: Rob Clark
In cases where the # is known ahead of time, it is silly to do the table
resize dance.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
drivers
On Mon, Oct 30, 2023 at 1:05 AM Christian König
wrote:
>
> Am 27.10.23 um 18:58 schrieb Rob Clark:
> > From: Rob Clark
> >
> > In cases where the # is known ahead of time, it is silly to do the table
> > resize dance.
>
> Ah, yes that was my initial implem
On Mon, Oct 30, 2023 at 9:01 AM Christian König
wrote:
>
> Am 30.10.23 um 14:38 schrieb Rob Clark:
> > On Mon, Oct 30, 2023 at 1:05 AM Christian König
> > wrote:
> >> Am 27.10.23 um 18:58 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
>
On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
wrote:
>
> From: Shashank Sharma
>
> This patch adds a new sysfs event, which will indicate
> the userland about a GPU reset, and can also provide
> some information like:
> - process ID of the process involved with the GPU reset
> - process name of
On Thu, Mar 10, 2022 at 1:55 AM Christian König
wrote:
>
>
>
> Am 09.03.22 um 19:12 schrieb Rob Clark:
> > On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
> > wrote:
> >> From: Shashank Sharma
> >>
> >> This patch adds a new sysfs event, whic
On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank
wrote:
>
>
>
> On 3/10/2022 4:24 PM, Rob Clark wrote:
> > On Thu, Mar 10, 2022 at 1:55 AM Christian König
> > wrote:
> >>
> >>
> >>
> >> Am 09.03.22 um 19:12 schrieb Rob Clark:
> &
On Thu, Mar 10, 2022 at 8:27 AM Andrey Grodzovsky
wrote:
>
>
> On 2022-03-10 11:21, Sharma, Shashank wrote:
> >
> >
> > On 3/10/2022 4:24 PM, Rob Clark wrote:
> >> On Thu, Mar 10, 2022 at 1:55 AM Christian König
> >> wrote:
> >>>
On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank
wrote:
>
>
>
> On 3/10/2022 6:10 PM, Rob Clark wrote:
> > On Thu, Mar 10, 2022 at 8:21 AM Sharma, Shashank
> > wrote:
> >>
> >>
> >>
> >> On 3/10/2022 4:24 PM, Rob Clark wrote:
> &
On Thu, Mar 10, 2022 at 11:14 AM Sharma, Shashank
wrote:
>
>
>
> On 3/10/2022 7:33 PM, Abhinav Kumar wrote:
> >
> >
> > On 3/10/2022 9:40 AM, Rob Clark wrote:
> >> On Thu, Mar 10, 2022 at 9:19 AM Sharma, Shashank
> >> wrote:
> >>
On Thu, Mar 10, 2022 at 11:44 AM Sharma, Shashank
wrote:
>
>
>
> On 3/10/2022 8:35 PM, Rob Clark wrote:
> > On Thu, Mar 10, 2022 at 11:14 AM Sharma, Shashank
> > wrote:
> >>
> >>
> >>
> >> On 3/10/2022 7:33 PM, Abhinav Kumar wr
On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote:
>
> On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote:
> >
[snip]
> > With new UAPI comes the demand of userspace proof, not hand-waving. You
> > would not be proposing this new interface if you didn't have use cases
> > in mind, even just on
On Wed, Mar 16, 2022 at 8:48 AM Alex Deucher wrote:
>
> On Wed, Mar 16, 2022 at 11:35 AM Rob Clark wrote:
> >
> > On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote:
> > >
> > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen
> > > wrote:
>
On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
wrote:
>
> From: Shashank Sharma
>
> This patch adds a new sysfs event, which will indicate
> the userland about a GPU reset, and can also provide
> some information like:
> - process ID of the process involved with the GPU reset
> - process name of
On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote:
>
> On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote:
> > Am 16.03.22 um 16:36 schrieb Rob Clark:
> > > [SNIP]
> > > just one point of clarification.. in the msm and i915 case it is
> > >
On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote:
>
> On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote:
> > Am 16.03.22 um 16:36 schrieb Rob Clark:
> > > [SNIP]
> > > just one point of clarification.. in the msm and i915 case it is
> > >
On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote:
>
> On Thu, Mar 17, 2022 at 08:40:51AM -0700, Rob Clark wrote:
> > On Thu, Mar 17, 2022 at 2:29 AM Daniel Vetter wrote:
> > >
> > > On Thu, Mar 17, 2022 at 08:03:27AM +0100, Christian König wrote:
> >
On Fri, Mar 18, 2022 at 12:42 AM Christian König
wrote:
>
> Am 17.03.22 um 18:31 schrieb Rob Clark:
> > On Thu, Mar 17, 2022 at 10:27 AM Daniel Vetter wrote:
> >> [SNIP]
> >>> (At some point, I'd like to use scheduler for the replay, and actually
> >&
On Mon, Mar 21, 2022 at 2:30 AM Christian König
wrote:
>
> Am 18.03.22 um 16:12 schrieb Rob Clark:
> > On Fri, Mar 18, 2022 at 12:42 AM Christian König
> > wrote:
> >> Am 17.03.22 um 18:31 schrieb Rob Clark:
> >>> On Thu, Mar 17, 2022 at 10:27 AM Daniel V
On Wed, Mar 23, 2022 at 8:14 AM Daniel Vetter wrote:
>
> On Wed, 23 Mar 2022 at 15:07, Daniel Stone wrote:
> >
> > Hi,
> >
> > On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote:
> > > On Mon, Mar 21, 2022 at 2:30 AM Christian König
> > > wrote
On Tue, Jun 28, 2022 at 5:51 AM Dmitry Osipenko
wrote:
>
> On 6/28/22 15:31, Robin Murphy wrote:
> > ->8-
> > [ 68.295951] ==
> > [ 68.295956] WARNING: possible circular locking dependency detected
> > [ 68.295963] 5.19.0-rc3+ #400
From: Rob Clark
If userspace calls the AMDGPU_CS ioctl from multiple threads, because
the vm is global to the drm_file, you can end up with multiple threads
racing in amdgpu_vm_clear_freed(). So the freed list should be
protected with the status_lock, similar to other vm lists.
Fixes
On Mon, Feb 6, 2023 at 2:15 AM Christian König wrote:
>
> Am 03.02.23 um 19:10 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If userspace calls the AMDGPU_CS ioctl from multiple threads, because
> > the vm is global to the drm_file, you can end up with
On Mon, Feb 6, 2023 at 8:05 AM Christian König wrote:
>
> Am 06.02.23 um 16:52 schrieb Rob Clark:
> > On Mon, Feb 6, 2023 at 2:15 AM Christian König
> > wrote:
> >> Am 03.02.23 um 19:10 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> &g
On Mon, Feb 27, 2023 at 12:40 PM André Almeida wrote:
>
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Signed-off-by: André Almeida
> ---
> Documentation/gpu/drm-uapi.rst | 51 ++
> 1 file changed, 51 i
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start
From: Rob Clark
v2: Rebase on drm-misc-next
Signed-off-by: Rob Clark
Reviewed-by: Christian König
Acked-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 32 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
From: Rob Clark
Fixes undefined symbol when PROC_FS is not enabled.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202305251510.u0r2as7k-...@intel.com/
Fixes: 376c25f8ca47 ("drm/amdgpu: Switch to fdinfo helper")
Signed-off-by: Rob Clark
---
drivers/g
From: Rob Clark
Some of the fields that are handled by drm_show_fdinfo() crept back in
when rebasing the patch. Remove them again.
Fixes: 376c25f8ca47 ("drm/amdgpu: Switch to fdinfo helper")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 3 ---
1 file
On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko
wrote:
>
> On 11/17/22 18:09, Christian König wrote:
> > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
> >> [SNIP]
> >>> drm_sched_entity_flush() should be called from the flush callback from
> >>> the file_operations structure of panfrost. See amdgp
On Wed, Dec 28, 2022 at 8:27 AM Rob Clark wrote:
>
> On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko
> wrote:
> >
> > On 11/17/22 18:09, Christian König wrote:
> > > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
> > >> [SNIP]
> > >>>
On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
>
> On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> wrote:
> >
> > Introduce a common DRM SHMEM shrinker framework that allows to reduce
> > code duplication among DRM drivers by replacing theirs custom shrinker
> > implementations with the gene
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker driv
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_cont
()
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker
>
> Rearrange the dm_pp_get_clock_levels_by_type_with_voltage calls to make
> sure they happen outside of kernel_fpu_begin/end.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Harry Wentland
Tested-by: Rob Clark
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c | 8 ++--
> 1 file changed, 6 in
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
>
> On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > pre-merge CI.
>
> Thanks for the suggestion! I implemented something like this for Mesa:
>
> https://gitlab.freedesk
On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
>
> Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI onl
On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote:
>
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > > On
On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote:
>
> On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote:
> >
> > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne
> > wrote:
> > >
> > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> >
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote:
>
> On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote:
>
> On 2020-04-06 6:34 p.m., Rob Clark wrote:
> >
> > The ideal thing would be to be able to click any jobs that we want to
> > run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> >
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote:
>
> On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> >
> > We could also do stuff like reducing the amount of tests we run on each
> > commit, and punt some testing to a per-weekend test-run or someting
> > like that. We don't *need* to know ab
On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote:
>
> + dri-devel
>
> On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
>>
>> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc passing
>> it to user space
>> instead of unused DRM driver name descriptor.
>>
>> Change-Id: I809f6
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 10 ++
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/drm_gem.c | 8
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 4
On Mon, Dec 12, 2016 at 11:10 PM, Cheng, Tony wrote:
> We need to treat most of resource that don't map well as global. One example
> is pixel pll. We have 6 display pipes but only 2 or 3 plls in CI/VI, as a
> result we are limited in number of HDMI or DVI we can drive at the same
> time. Also t
On Mon, Feb 19, 2018 at 2:33 PM, Pavel Machek wrote:
> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
>> >
>> >
>> > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
>> > >
>> > > Fix double ;;'s in code.
>> > >
>> > > Signed-off-
71 matches
Mail list logo
