On Thu, 2018-09-06 at 17:43 -0400, Lyude Paul wrote:
> Since we're about to use this in nouveau_backlight.c. Same thing as
> DRM_WARN_ONCE, DRM_INFO_ONCE, etc...
Can you redefine this in terms of the patches I submitted
instead?
https://lore.kernel.org/patchwork/patch/979598/
Hopefully this answers some questions.
Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all
chips) and MC_ARB_RAMCFG (GFX6-8 only), and those vary with each chip.
Some 32bpp 1D tiling layouts are compatible across all chips (1D
display tiling is the same as SW_256B_D if Bpp == 4).
This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.
Depending on the variant, the PCB attached to the panel module either
Hi,
This is v2 of my sun4i-drm LCD color dithering series. v1 was from back
in April [1]. Most of the driver code is unchanged.
Changes since v1:
- Explicitly list properties from the simple-panel binding that apply
to the Bananapi 7" panel
- Moved an incorrectly squashed change from
From: Jonathan Liu
The hardware supports dithering on TCON channel 0 which is used for LCD
panels.
Dithering is a method of approximating a color from a mixture of other
colors when the required color isn't available. It reduces color
banding artifacts that can be observed when displaying
Dithering is only supported for TCON channel 0. Throughout the datasheet
all the names associated with these register are prefixed "TCON0",
instead of "TCON". The only exception is the control register
"TCON_FRM_CTL_REG".
Rename the macros to reflect this.
Signed-off-by: Chen-Yu Tsai
---
The BPI-M1+ has an FPC connector for connecting an RGB (parallel) or
LVDS LCD panel. One of the compatible panels is a 7" 800x480 RGB panel
from Bananapi. The backlight can be controlled by driving a PWM signal
from the SoC at different duty cycles. The LCD enable pin does not seem
to do anything,
On the A20, as well as many other Allwinner SoCs, the PD pingroup has
the LCD0 RGB output functions.
Add a pinmux setting for RGB888 output from LCD0, so boards and tablets
with parallel RGB LCD panels may reference it.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20.dtsi | 11
sun4i_tcon0_mode_set_cpu() currently accepts struct mipi_dsi_device *
as its second parameter. This is derived from drm_encoder.
The DSI encoder is tied to the CPU interface mode of the TCON as a
special case. In theory, if hardware were available, we could also
support normal CPU interface
Hi, Bibby:
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds hdmi dirver suppot for both MT2701 and MT7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai
> ---
>
Hi Linus,
Seems to have been overly quiet this week so I expect next week will
be more stuff, just one pull request with i915 fixes in it.
i915: (from Rodrigo's pull)
"The critical fix here on display side is the DP MST regression one.
But this pull also include fixes for DP SST, small VDSC
Hi, Bibby:
On Wed, 2018-09-05 at 16:31 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> Different IC has different phy setting of HDMI.
> This patch separaes the phy hardware relate part for mt8173.
I guess 'separae' is 'separate'. Am I right?
Regards,
CK
>
> Signed-off-by: chunhui dai
>
Hi,
2018년 08월 27일 09:38에 Inki Dae 이(가) 쓴 글:
>
>
> 2018년 08월 10일 22:28에 Marek Szyprowski 이(가) 쓴 글:
>> From: Andrzej Pietrasiewicz
>>
>> Add modifier for tiled formats used by graphics modules found in Samsung
>> Exynos5250/542x/5433 SoCs. This is a simple tiled layout using tiles
>> of 16x16
On 26.07.2018 06:36, Stefan Agner wrote:
> If the GPIO subsystem is not ready make sure to return -EPROBE_DEFER
> instead of silently continuing without HPD.
>
> Reported-by: Marcel Ziswiler
> Signed-off-by: Stefan Agner
I think this did not get merged yet, any chance to get it in?
--
Stefan
>
> On Wed, Sep 05, 2018 at 04:38:48PM -0700, Deepak Rawat wrote:
> > From: Lukasz Spintzyk
> >
> > FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions
> > on the plane in framebuffer coordinates of the framebuffer attached to
> > the plane.
> >
> > The layout of blob data is
The "initialized" member is going away. suspend/resume still works (even
if bochsfb_create is forced to fail).
Signed-off-by: Peter Wu
---
drivers/gpu/drm/bochs/bochs_drv.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
Clarify the relation between drm_fb_helper_fbdev_setup/teardown. Clarify
requirements for the new generic fbdev emulation API and log some more
details in case the driver does something wrong. Fix related typos.
Cc: Noralf Trønnes
Signed-off-by: Peter Wu
---
drivers/gpu/drm/drm_fb_helper.c |
The drm_get_pci_dev API is deprecated, replace it by drm_dev_register.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/bochs/bochs.h | 2 +-
drivers/gpu/drm/bochs/bochs_drv.c | 34 +--
drivers/gpu/drm/bochs/bochs_hw.c | 2 +-
3 files changed, 30 insertions(+), 8
Currently unloading bochs_drm (after unbinding the vtconsole) results in
a warning about a leaked connector:
[drm:drm_mode_config_cleanup] *ERROR* connector Virtual-3 leaked!
While investigating a potential fix I noticed that a lot of open-coded
functionality is already implemented
Hi,
These series tries to improve the bochs driver and update documentation based on
my brief experience with the fb-helper API. Thank you Daniel and Gerd for your
previous feedback and helpful suggestions.
Patch 2 was previously posted and is unmodified except for acked-by + rebase on
On Thu, Sep 6, 2018 at 6:33 PM, Deucher, Alexander
wrote:
>> -Original Message-
>> From: Daniel Vetter
>> Sent: Wednesday, September 5, 2018 9:48 AM
>> To: Li, Sun peng (Leo)
>> Cc: DRI Development ; Intel Graphics
>> Development ; Daniel Vetter
>> ; Deucher, Alexander
>> ; Wentland,
> > drivers/gpu/drm/drm_atomic_helper.c | 4
> > include/drm/drm_damage_helper.h | 10 ++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index be83e2763c18..e06d2d5d582f 100644
> > ---
> > #include
> >
> > /**
> > @@ -75,6 +76,11 @@
> > * While kernel does not error for overlapped damage clips, it is
> discouraged.
> > */
> >
> > +static int convert_fixed_to_32(int fixed)
> > +{
> > + return ((fixed >> 15) & 1) + (fixed >> 16);
> > +}
> > +
> > /**
> > *
Since we're about to use this in nouveau_backlight.c. Same thing as
DRM_WARN_ONCE, DRM_INFO_ONCE, etc...
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
Currently module unloading is broken in nouveau due to a rather annoying
race condition resulting from nouveau_backlight.c having gone a bit
stale over time:
[ 1960.791143]
==
[ 1960.791394] BUG: KASAN: use-after-free in
Remember, ida IDs start at 0, not 1!
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
Still no functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
Refactor for Ben, hopefully this time this should apply to his tree.
Next version of https://patchwork.freedesktop.org/series/48596/
No changes otherwise.
Lyude Paul (6):
drm/nouveau: Check backlight IDs are >= 0, not > 0
drm/nouveau: Add NV_PRINTK_ONCE and variants
drm/nouveau: Move
There's literally no difference between any of the backlight init
functions besides the backlight properties they set and the backlight
callbacks that they set, so move all of the duplicated backlight init
code out of there and into nouveau_backlight_init().
This gets rid of a lot of copy pasta!
More consistent with the rest of the codebase, no functional changes
here.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.h | 4 ++--
3
On Thu, Sep 6, 2018 at 6:01 PM, Steven Rostedt wrote:
> On Thu, 6 Sep 2018 09:58:04 -0600
> Jonathan Corbet wrote:
>
>> Thanks,
>>
>> jon (who is increasingly inclined to apply this patch)
>
> As Colin Kaepernick now says... "Just do it!"
>
> ;-)
+1
But I'm biased, I'm part of the party that
> >
> > +FB_DAMAGE_CLIPS
> > +~~~
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> > + :doc: overview
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> > + :export:
>
> You forgot to include your nice kerneldoc from the header. Please run
>
> $
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #37 from Francisco Pina Martins ---
Confirming that the issue seems to be solved with mainline linux-4.19-rc[1,2].
--
You are receiving this mail because:
You are the assignee for the
Got something, sort of obvious for a human, impossible for bisect to know,
which explains why this bisection was a failure:
testing a commit in the middle of a series of commits which are to be taken as
a whole to be consistent for normal operations of the kernel, is wrong. That,
bisect cannot
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #18 from Sylvain BERTRAND ---
Got something, sort of obvious for a human, impossible for bisect to know,
which explains why this bisection was a failure:
testing a commit in the middle of a series of commits which are to be taken as
The hotplug detection routine of drm_helper_hpd_irq_event() can detect
changing of status of connector, but it can not detect changing of edid.
Following scenario requires detection of changing of edid.
1) plug display device to a connector
2) system suspend
3) unplug 1)'s display device and
In order to use a detected edid on drm helper functions, it moves
a detected edid member to drm_connector structure from intel_connector
structure.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_dp.c | 18 +-
drivers/gpu/drm/i915/intel_drv.h | 1 -
On 06.09.2018 04:07, Linus Walleij wrote:
> On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote:
>> On 05.09.2018 00:44, Laurent Pinchart wrote:
>
>> Good point! I actually really don't like that we use the same flags here
>> but from a different perspective. Especially since the flags defines
>>
On Thu, Sep 06, 2018 at 06:59:33PM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-09-06 18:51:37)
> > On Thu, Sep 06, 2018 at 06:38:52PM +0100, Chris Wilson wrote:
> > > Quoting Emil Velikov (2018-09-06 16:14:07)
> > > > From: Emil Velikov
> > > >
> > > > They're used internally and
https://bugs.freedesktop.org/show_bug.cgi?id=107693
--- Comment #7 from gloriouseggr...@gmail.com ---
this patch was for wine btw, not mesa, but maybe it can be used to find what
wine was providing that allowed the game to start
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=107693
--- Comment #6 from gloriouseggr...@gmail.com ---
Unsure if this helps or not, but before mesa's profiles were updated I was able
to get the game running using this patch:
https://bugzilla.kernel.org/show_bug.cgi?id=201035
--- Comment #1 from Kevin Brace (kevinbr...@gmx.com) ---
Created attachment 278351
--> https://bugzilla.kernel.org/attachment.cgi?id=278351=edit
kern.log for VIA Embedded EPIA-M830 mainboard
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=201035
Kevin Brace (kevinbr...@gmx.com) changed:
What|Removed |Added
URL|
https://bugzilla.kernel.org/show_bug.cgi?id=201035
Bug ID: 201035
Summary: I2C bus probing crash on OpenChrome DRM
Product: Drivers
Version: 2.5
Kernel Version: 4.19 rc1
Hardware: x86-64
OS: Linux
Tree:
https://bugs.freedesktop.org/show_bug.cgi?id=105018
ecomer changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
From: kbuild test robot
pm_runtime_get_sync returns < 0 as error. Unecessary IS_ERR_VALUE at line 164
Generated by: scripts/coccinelle/api/pm_runtime.cocci
Fixes: eaeb9010bb4b ("drm/nouveau/debugfs: Wake up GPU before doing any
reclocking")
CC: Karol Herbst
Signed-off-by: kbuild test robot
Quoting Lucas De Marchi (2018-09-06 18:51:37)
> On Thu, Sep 06, 2018 at 06:38:52PM +0100, Chris Wilson wrote:
> > Quoting Emil Velikov (2018-09-06 16:14:07)
> > > From: Emil Velikov
> > >
> > > They're used internally and never meant to be part of the API.
> > > Add the drm_private notation,
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #9 from Christian König ---
(In reply to Michel Dänzer from comment #7)
> Hmm, 'fork' sounded suspicious, and indeed AFAICT this test uses the same
> amdgpu_context_handle (and by extension the same DRM file descriptor) in
>
On Thu, Sep 06, 2018 at 06:38:52PM +0100, Chris Wilson wrote:
> Quoting Emil Velikov (2018-09-06 16:14:07)
> > From: Emil Velikov
> >
> > They're used internally and never meant to be part of the API.
> > Add the drm_private notation, which should resolve that.
> >
> > Cc: Eric Engestrom
> >
On Thu, Sep 06, 2018 at 04:14:07PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> They're used internally and never meant to be part of the API.
> Add the drm_private notation, which should resolve that.
>
> Cc: Eric Engestrom
> Cc: Lucas De Marchi
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
Quoting Emil Velikov (2018-09-06 16:14:07)
> From: Emil Velikov
>
> They're used internally and never meant to be part of the API.
> Add the drm_private notation, which should resolve that.
>
> Cc: Eric Engestrom
> Cc: Lucas De Marchi
> Cc: Chris Wilson
> Cc: Rodrigo Vivi
> Fixes:
On 06.09.2018 09:54, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Thursday, 6 September 2018 19:48:51 EEST Stefan Agner wrote:
>> On 06.09.2018 05:25, Laurent Pinchart wrote:
>> > On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote:
>> >> On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner
> > > +int phy_configure(struct phy *phy, enum phy_mode mode,
> > > + union phy_configure_opts *opts)
> > > +{
> > > + int ret;
> > > +
> > > + if (!phy)
> > > + return -EINVAL;
> > > +
> > > + if (!phy->ops->configure)
> > > + return 0;
> >
> > Shouldn't you report an
Hi Stefan,
On Thursday, 6 September 2018 19:48:51 EEST Stefan Agner wrote:
> On 06.09.2018 05:25, Laurent Pinchart wrote:
> > On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote:
> >> On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote:
> >> > On 05.09.2018 00:44, Laurent Pinchart
Hi Maxime,
On Thursday, 6 September 2018 17:48:07 EEST Maxime Ripard wrote:
> On Wed, Sep 05, 2018 at 04:39:46PM +0300, Laurent Pinchart wrote:
> > On Wednesday, 5 September 2018 12:16:33 EEST Maxime Ripard wrote:
> >> The phy framework is only allowing to configure the power state of the
> >>
On 06.09.2018 05:25, Laurent Pinchart wrote:
> Hi Linus,
>
> On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote:
>> On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote:
>> > On 05.09.2018 00:44, Laurent Pinchart wrote:
>> >
>> > Good point! I actually really don't like that we use the
> -Original Message-
> From: Daniel Vetter
> Sent: Wednesday, September 5, 2018 9:48 AM
> To: Li, Sun peng (Leo)
> Cc: DRI Development ; Intel Graphics
> Development ; Daniel Vetter
> ; Deucher, Alexander
> ; Wentland, Harry
> ; Grodzovsky, Andrey
> ; Cheng, Tony ; S,
> Shirish
>
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #17 from Sylvain BERTRAND ---
On Thu, Sep 06, 2018 at 02:22:18PM +, bugzilla-dae...@freedesktop.org
wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
>
> --- Comment #16 from Michel Dänzer ---
> "this commit" being
On Thu, Sep 06, 2018 at 02:22:18PM +, bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
>
> --- Comment #16 from Michel Dänzer ---
> "this commit" being 019cddc88f9e4ae0de2c76802f7137210c2101aa (the I2C merge),
> which has two parents. Both of those
https://bugs.freedesktop.org/show_bug.cgi?id=97220
--- Comment #7 from Paul Menzel ---
(In reply to kenneth johansson from comment #6)
> I have no idea what a tiled display is.
I believe it means, that there are actually two panels.
> If I use the Intel display port I get or more correctly
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #8 from Michel Dänzer ---
BTW, any IGT patches containing amdgpu specific code should probably be Cc'd to
the amd-gfx mailing list for review.
--
You are receiving this mail because:
You are the assignee for the
On Thursday, 2018-09-06 15:53:33 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Set/export the NM variable since it may not be set already.
>
> Fixes: 4f08bfe96da ("*-symbol-check: Don't hard-code nm executable")
> Cc: Heiko Becker
> Cc: Eric Engestrom
> Signed-off-by: Emil Velikov
>
On Wed, Sep 05, 2018 at 07:08:26PM -0700, Jeykumar Sankaran wrote:
> Connector states were passed around RM to update the custom
> topology connector property with chosen topology data. Now that
> we got rid of both custom properties and topology names, this
> change cleans up the mechanism to
On Thursday, 2018-09-06 16:01:15 +0100, Emil Velikov wrote:
> On 6 September 2018 at 14:40, Eric Engestrom wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> > .gitlab-ci.yml | 129 ++---
> > 1 file changed, 47 insertions(+), 82 deletions(-)
> >
> >
On Thu, 6 Sep 2018 09:58:04 -0600
Jonathan Corbet wrote:
> Thanks,
>
> jon (who is increasingly inclined to apply this patch)
As Colin Kaepernick now says... "Just do it!"
;-)
-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, 4 Sep 2018 09:59:08 -0400
Steven Rostedt wrote:
> On Tue, 4 Sep 2018 13:30:30 +0200
> Pavel Machek wrote:
>
> > I'd say this is still quite valueable, and it might be worth fixing,
> > rather then removing completely.
>
> I agree. Perhaps we should have a 00-DESCRIPTION file in each
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #7 from Michel Dänzer ---
(In reply to Martin Peres from comment #4)
> However, if it is scheduler bug, I would assume this issue to be
> reproducible on any AMD GPU. Can you try running
> igt@amdgpu/amd_cs_nop@sync-fork-gfx0 in a
On 4 April 2018 at 16:41, Eric Engestrom wrote:
> --- /dev/null
> +++ b/symbols-check
> @@ -0,0 +1,79 @@
> +#!/bin/sh
> +set -eu
> +set -o pipefail
> +
We could drop the execute bit, shebang and set. Pretty much all of it
is handled by the callers (modulo pipefail)
> +if [ -z "$LIB" ]; then
> +
On 4 April 2018 at 16:41, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> amdgpu/Makefile.am | 1 +
> amdgpu/amdgpu-symbol-check | 19 ++-
> 2 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
> index
On Thu, Sep 06, 2018 at 12:38:46PM +0200, Daniel Vetter wrote:
> On Thu, Sep 06, 2018 at 11:01:17AM +0100, Daniel Stone wrote:
> > GitLab CI already captures all the stdout/stderr output from the build
> > process as the log. However, some other important information is hidden
> > in other log
https://bugs.freedesktop.org/show_bug.cgi?id=107781
Alex Findler changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #6 from Chris Wilson ---
Since it just happened again with drm-tip 60edf94611d2 that includes 4823e5da2e
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4782/fi-kbl-8809g/igt@amdgpu_amd_cs_...@sync-fork-gfx0.html
you are in luck.
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #5 from Martin Peres ---
(In reply to Lucas Stach from comment #3)
> We've just fixed a bug in the scheduler timeout handling, which might lead
> to the timeout worker being armed for the wrong job.
>
> Does this issue still occur
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #4 from Martin Peres ---
(In reply to Michel Dänzer from comment #2)
> (In reply to Martin Peres from comment #0)
> > [ 358.292609] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0
> > timeout, signaled seq=137, emitted
https://bugs.freedesktop.org/show_bug.cgi?id=107762
--- Comment #3 from Lucas Stach ---
We've just fixed a bug in the scheduler timeout handling, which might lead to
the timeout worker being armed for the wrong job.
Does this issue still occur on a recent kernel with
From: Emil Velikov
They're used internally and never meant to be part of the API.
Add the drm_private notation, which should resolve that.
Cc: Eric Engestrom
Cc: Lucas De Marchi
Cc: Chris Wilson
Cc: Rodrigo Vivi
Fixes: 4e81d4f9c9b ("intel: add generic functions to check PCI ID")
https://bugs.freedesktop.org/show_bug.cgi?id=107762
Michel Dänzer changed:
What|Removed |Added
CC||ckoenig.leichtzumerken@gmai
HI all,
On 6 September 2018 at 07:10, Lucas De Marchi wrote:
> On Wed, Sep 5, 2018 at 7:00 PM Rodrigo Vivi wrote:
>>
>> well it builds for me.
>>
>> but any idea what might be wrong here on gitlab ci?
>
FWIW gitlab gives you the test target and command used. It might be a
bit hard to find
On 6 September 2018 at 14:40, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> .gitlab-ci.yml | 129 ++---
> 1 file changed, 47 insertions(+), 82 deletions(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index
From: Emil Velikov
It will make bugs like the one fixed with previous patch dead obvious.
Cc: Eric Engestrom
Signed-off-by: Emil Velikov
---
amdgpu/amdgpu-symbol-check | 2 ++
etnaviv/etnaviv-symbol-check | 2 ++
exynos/exynos-symbol-check | 2 ++
From: Emil Velikov
Set/export the NM variable since it may not be set already.
Fixes: 4f08bfe96da ("*-symbol-check: Don't hard-code nm executable")
Cc: Heiko Becker
Cc: Eric Engestrom
Signed-off-by: Emil Velikov
---
amdgpu/Makefile.am| 1 +
etnaviv/Makefile.am | 1 +
Hi Kishon,
On Thu, Sep 06, 2018 at 02:57:58PM +0530, Kishon Vijay Abraham I wrote:
> On Wednesday 05 September 2018 02:46 PM, Maxime Ripard wrote:
> > The phy framework is only allowing to configure the power state of the PHY
> > using the init and power_on hooks, and their power_off and exit
> >
On Wed, Sep 05, 2018 at 04:39:46PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> On Wednesday, 5 September 2018 12:16:33 EEST Maxime Ripard wrote:
> > The phy framework is only allowing to configure the power state of the PHY
> > using the init and power_on hooks,
On 6 September 2018 at 14:52, Eric Engestrom wrote:
> And add them to the list of exported function to fix the tests.
>
> Fixes: 4e81d4f9c9b7fd6510cf "intel: add generic functions to check PCI ID"
> Cc: Lucas De Marchi
> Cc: Rodrigo Vivi
> Signed-off-by: Eric Engestrom
> ---
> Lucas, I'm
https://bugs.freedesktop.org/show_bug.cgi?id=107762
Martin Peres changed:
What|Removed |Added
Priority|medium |high
--- Comment #1 from Martin Peres
On Thu, Sep 06, 2018 at 04:12:39PM +0200, Daniel Vetter wrote:
> On Thu, Sep 06, 2018 at 03:02:32PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 05, 2018 at 04:38:50PM -0700, Deepak Rawat wrote:
> > > Plane damage is irrelevant when full modeset happens so clear the damage
> > > blob property(If
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #16 from Michel Dänzer ---
(In reply to Sylvain BERTRAND from comment #15)
> Not consistent? Could you be more specific?
You wrote:
(In reply to Sylvain BERTRAND from comment #6)
>- this commit is failing.
>- the
On Thu, Sep 06, 2018 at 03:02:32PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 05, 2018 at 04:38:50PM -0700, Deepak Rawat wrote:
> > Plane damage is irrelevant when full modeset happens so clear the damage
> > blob property(If set by user-space). With damage blob cleared damage
> > helper iterator
And add them to the list of exported function to fix the tests.
Fixes: 4e81d4f9c9b7fd6510cf "intel: add generic functions to check PCI ID"
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Signed-off-by: Eric Engestrom
---
Lucas, I'm assuming you meant to export those functions (and macros,
like
On 6 September 2018 at 12:02, Eric Engestrom wrote:
> On Thursday, 2018-09-06 11:01:17 +0100, Daniel Stone wrote:
>> GitLab CI already captures all the stdout/stderr output from the build
>> process as the log. However, some other important information is hidden
>> in other log files.
>>
>> Taken
Signed-off-by: Eric Engestrom
---
.gitlab-ci.yml | 129 ++---
1 file changed, 47 insertions(+), 82 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index eee6abfcdd7de2839660..1dc434a5d359b3b077e7 100644
--- a/.gitlab-ci.yml
+++
On 6 September 2018 at 10:40, Heiko Stuebner wrote:
> Am Mittwoch, 5. September 2018, 20:15:09 CEST schrieb Daniel Vetter:
>> - drmP.h is now fully split up.
>> - vkms is happening (and will gain its own todo and docs under a new
>> vkms.rst file real soon)
>> - legacy cruft is completely
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #37 from markusr...@gmail.com ---
(In reply to markusraat from comment #36)
> (In reply to markusraat from comment #35)
> > It might be that kernel option apci=ht ( also apci=off ) solve the problem.
> > It is taking more time to
On Thu, Sep 06, 2018 at 10:04:53AM +, bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
>
> --- Comment #14 from Michel Dänzer ---
> That's not consistent with the merge commit you identified earlier. So I'm
> afraid it's likely that you incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #15 from Sylvain BERTRAND ---
On Thu, Sep 06, 2018 at 10:04:53AM +, bugzilla-dae...@freedesktop.org
wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
>
> --- Comment #14 from Michel Dänzer ---
> That's not
On 31/08/18 15:13, Linus Walleij wrote:
This addresses a v4.19-rc1 regression in the PL111 DRM driver
in drivers/gpu/pl111/*
The driver uses the CMA KMS helpers and will thus at some
point call down to dma_alloc_attrs() to allocate a chunk
of contigous DMA memory for the framebuffer.
It
Hi Linus,
On Thursday, 6 September 2018 14:07:41 EEST Linus Walleij wrote:
> On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote:
> > On 05.09.2018 00:44, Laurent Pinchart wrote:
> >
> > Good point! I actually really don't like that we use the same flags here
> > but from a different perspective.
On Thu, Sep 06, 2018 at 02:30:24PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 05, 2018 at 04:46:01PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > I ran across this last week when I was trying to get this function to
> > work. It's useful to have the scale values in the log upon failure.
>
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #30 from L.Y. Sim ---
I have this issue on a 3840x1600 Acer XR382CQK with an RX560 with Kernel
4.18.5-1 on Manjaro.
When I set the refresh rate to 75Hz, severe artifacts and flickering appear.
Both
echo high >
On Wed, Sep 05, 2018 at 04:38:50PM -0700, Deepak Rawat wrote:
> Plane damage is irrelevant when full modeset happens so clear the damage
> blob property(If set by user-space). With damage blob cleared damage
> helper iterator will return full plane src as damage clip.
>
> Signed-off-by: Deepak
1 - 100 of 170 matches
Mail list logo
