https://bugs.freedesktop.org/show_bug.cgi?id=109007
Daniel Drake changed:
What|Removed |Added
CC||mar...@gmail.com
--- Comment #1 from
On 11.12.2018 00:45, Inki Dae wrote:
> Hi Andrzej,
>
> 18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글:
>> Hi Inki,
>>
>> On 10.12.2018 03:25, Inki Dae wrote:
>>> Hi Andrzej,
>>>
>>> 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글:
Hi Inki,
This small patchset adds dynamic zpos support for
https://bugs.freedesktop.org/show_bug.cgi?id=109007
Bug ID: 109007
Summary: radeonsi cache format changed, causes mesa crash on
startup
Product: Mesa
Version: git
Hardware: Other
OS: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=108671
coolo...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hey Dave,
Mostly just initial support for Turing TU104/TU106 chipsets. Support
for TU102 is missing as I don't yet have HW, but it should be trivial
to add in later in the merge window (in theory).
It's a bit of a rough first pass that'll get improved in future
releases as a finish figuring out
https://bugs.freedesktop.org/show_bug.cgi?id=108671
--- Comment #13 from coolo...@gmail.com ---
Seems fixed on 4.20rc5
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=109001
--- Comment #5 from L.S.S. ---
I'm not sure about the freeze you experienced. I'm having similar issues on
latest Manjaro (4.18-4.19) that after wakeup, there are intermittent screen
freezes for a few seconds every 2-3 minutes. Aside from the
Hey Dave,
Single fix for a Tegra regression.
Thanks,
Ben.
The following changes since commit 4a07c0a59fa372b069d879971ba4d9e341979cf:
drm/nouveau/secboot/acr: fix memory leak (2018-10-11 09:54:10 +1000)
are available in the Git repository at:
git://github.com/skeggsb/linux linux-4.20
https://bugzilla.kernel.org/show_bug.cgi?id=201957
Bug ID: 201957
Summary: amdgpu: ring gfx timeout
Product: Drivers
Version: 2.5
Kernel Version: 4.19.8, 4.20-rc5
Hardware: Intel
OS: Linux
Tree: Mainline
https://bugs.freedesktop.org/show_bug.cgi?id=109006
Bug ID: 109006
Summary: Hotplugging DP1.2 monitor(s) causes machine to hang
waiting for page flip
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> or
> not. Makes it possible to send multiple messages in one go with
> stop+start generated between the messages (as opposed nothing or
>
I don't think adding cb to sched job would work as soon as their lifetime is
different with fence.
Unless you make the sched job reference, otherwise we will get trouble sooner
or later.
-David
> -Original Message-
> From: amd-gfx On Behalf Of
> Andrey Grodzovsky
> Sent: Tuesday,
On Mon, Dec 10, 2018 at 05:26:22PM +0100, Thierry Reding wrote:
> On Mon, Dec 10, 2018 at 02:25:59PM +, Mark Brown wrote:
> > This has been broken for a considerable time now with no response from
> > Ben - is there some other path we can use to get the fix merged?
> I suppose we could go
On Mon, Dec 10, 2018 at 3:56 PM Arnd Bergmann wrote:
>
> The new a200 GPU MMU support fails to build on arm64 because
> of a conflicting macro name:
>
> drivers/gpu/drm/msm/msm_gpummu.c:17: error: "VA_START" redefined [-Werror]
> #define VA_START SZ_16M
>
> In file included from
Hi Andrzej,
18. 12. 10. 오후 4:35에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
>
> On 10.12.2018 03:25, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 18. 12. 6. 오후 6:38에 Andrzej Hajda 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> This small patchset adds dynamic zpos support for DECON and FIMD.
>> This patch will allow user space
Daniel Vetter writes:
> lkml and Linus gained a CoC, and it's serious this time. Which means
> my no 1 reason for declining to officially step up as drm maintainer
> is gone, and I didn't find any new good excuse.
>
> I chatted with a few people in private already, and the biggest
> concern is
https://bugs.freedesktop.org/show_bug.cgi?id=108992
--- Comment #2 from Brian Schott ---
I have the same issue with a 2700U in a Dell Inspiron 7375. All of the 4.20 RC
versions that I have tried show the same problem. The system is able to boot
with a 4.19 kernel.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=108919
--- Comment #8 from Timothy Arceri ---
(In reply to Alexander Walker from comment #7)
> (In reply to Timothy Arceri from comment #5)
> > Can somebody try to get an apitrace of the issue [1]? Thanks.
> >
> > [1]
On Mon, 2018-12-10 at 23:29 +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT
> > bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a
In this usage, the two are completely equivalent, but the
completion documents better what is going on, and we generally
try to avoid semaphores these days.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/host1x/cdma.c | 6 +++---
drivers/gpu/host1x/cdma.h | 4 ++--
2 files changed, 5
On Mon, Dec 10, 2018 at 11:29:06PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote:
>
> Hi all,
>
> Just a small cleanup motivated by the last patch. After this series atomic
> drivers do no longer need the drm_crtc_helper.h header, and none of them
> use it. Except for the 2 that support both atomic and legacy kms in the
>
On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> The Write_Status_Update_Request I2C transaction requires the MOT bit to
> be set, Change the logical AND to OR to fix what looks like a typo.
It's not a type. We're just preserving MOT. What makes you think it
should always be
Neil Armstrong writes:
> This patchset adds :
> - Optional reset properties in the midgard bindings
> - Mali T820 Node in Amlogic Meson GXM DTSI
>
> Christian Hewitt (1):
> arm64: dts: meson-gxm: Add Mali-T820 node
>
> Neil Armstrong (1):
> dt-bindings: gpu: mali-midgard: Add resets property
The Write_Status_Update_Request I2C transaction requires the MOT bit to
be set, Change the logical AND to OR to fix what looks like a typo.
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
I2C_WRITE
The new a200 GPU MMU support fails to build on arm64 because
of a conflicting macro name:
drivers/gpu/drm/msm/msm_gpummu.c:17: error: "VA_START" redefined [-Werror]
#define VA_START SZ_16M
In file included from arch/arm64/include/asm/pgtable-hwdef.h:19,
from
https://bugs.freedesktop.org/show_bug.cgi?id=108979
--- Comment #4 from emm...@linuxmail.org ---
Created attachment 142773
--> https://bugs.freedesktop.org/attachment.cgi?id=142773=edit
Popupping grahpical glitch highligted
I have highlighted with a red circle the glitch, that glitch appear in
On Mon, 2018-12-10 at 18:39 +0200, Ville Syrjälä wrote:
> On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We aren't supposed to force a stop+start between every i2c msg
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #18 from quirin.blae...@freenet.de ---
Bug is still alive: v4.19.7
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
On Mon, Dec 10, 2018 at 5:30 AM Daniel Vetter wrote:
>
> lkml and Linus gained a CoC, and it's serious this time. Which means
> my no 1 reason for declining to officially step up as drm maintainer
> is gone, and I didn't find any new good excuse.
>
> I chatted with a few people in private
https://bugs.freedesktop.org/show_bug.cgi?id=108919
--- Comment #7 from Alexander Walker ---
(In reply to Timothy Arceri from comment #5)
> Can somebody try to get an apitrace of the issue [1]? Thanks.
>
> [1] https://github.com/apitrace/apitrace/wiki/Steam
Never used that tool before but I
https://bugs.freedesktop.org/show_bug.cgi?id=108919
--- Comment #6 from Alexander Walker ---
Created attachment 142771
--> https://bugs.freedesktop.org/attachment.cgi?id=142771=edit
Apitrace
--
You are receiving this mail because:
You are the assignee for the
From: Christoph Hellwig
Date: Mon, 10 Dec 2018 20:22:28 +0100
> On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
>> From: Christoph Hellwig
>> Date: Mon, 10 Dec 2018 17:32:56 +0100
>>
>> > Dave, can you pick the series up through the sparc tree? I could also
>> > merge it through
On Mon, Dec 10, 2018 at 07:19:30PM +, Robin Murphy wrote:
> On 08/12/2018 17:36, Christoph Hellwig wrote:
>> There is no need to have an additional kernel mapping for a contiguous
>> allocation if the device already is DMA coherent, so skip it.
>
> FWIW, the "need" was that it kept the code in
On Mon, Dec 10, 2018 at 10:10:39AM -0800, David Miller wrote:
> From: Christoph Hellwig
> Date: Mon, 10 Dec 2018 17:32:56 +0100
>
> > Dave, can you pick the series up through the sparc tree? I could also
> > merge it through the dma-mapping tree, but given that there is no
> > dependency on it
On 08/12/2018 17:36, Christoph Hellwig wrote:
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
FWIW, the "need" was that it kept the code in this path simple and the
mapping behaviour consistent with the
On Sat, Dec 08, 2018 at 07:52:04PM -0300, Ezequiel Garcia wrote:
> > #ifdef CONFIG_DMA_API_DEBUG
> > @@ -773,7 +791,7 @@ static void *__dma_alloc(struct device *dev, size_t
> > size, dma_addr_t *handle,
> >
> > if (cma)
> > buf->allocator = _allocator;
> > - else if
When unregistering fbdev using unregister_framebuffer(), any bound
console will unbind automatically. This is working fine if this is the
only framebuffer, resulting in a switch to the dummy console. However if
there is a fb0 and I unregister fb1 having a bound console, I eventually
get a crash.
https://bugs.freedesktop.org/show_bug.cgi?id=108985
Fabian Maurer changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #5 from Fabian Maurer
From: Christoph Hellwig
Date: Mon, 10 Dec 2018 17:32:56 +0100
> Dave, can you pick the series up through the sparc tree? I could also
> merge it through the dma-mapping tree, but given that there is no
> dependency on it the sparc tree seem like the better fit.
I thought that some of this is a
On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We aren't supposed to force a stop+start between every i2c msg
> > when performing multi message transfers. This should eg. cause
> > the
On Mon, Dec 10, 2018 at 11:30:01AM +0100, Daniel Vetter wrote:
> lkml and Linus gained a CoC, and it's serious this time. Which means
> my no 1 reason for declining to officially step up as drm maintainer
> is gone, and I didn't find any new good excuse.
>
> I chatted with a few people in private
https://bugs.freedesktop.org/show_bug.cgi?id=109001
--- Comment #4 from Julio ---
(In reply to Michel Dänzer from comment #3)
> The Xorg log file doesn't have any messages corresponding to those in dmesg.
> Was it really captured after reproducing the problem?
>
> Does
>
From: Thierry Reding
Most of the CEC support code already lives in the "output" library code.
Move registration and unregistration to the library code as well to make
use of the same code with HDMI on Tegra210 and later via the SOR.
Signed-off-by: Thierry Reding
---
Dave, can you pick the series up through the sparc tree? I could also
merge it through the dma-mapping tree, but given that there is no
dependency on it the sparc tree seem like the better fit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > I do not see any scheduler guys Cced and it would be really great to get
> > > their opinion here.
> > >
> > > On
On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > OK, no real objections to the thing. Just so long we're all on the same
> > page as to what it does and doesn't do ;-)
>
> I am not really sure whether there are other potential users besides
> this one and whether the check as
On Mon, Dec 10, 2018 at 02:25:59PM +, Mark Brown wrote:
> On Mon, Dec 10, 2018 at 10:00:08AM +, Guillaume Tucker wrote:
> > On 08/12/2018 00:08, Lyude Paul wrote:
> > > uh
> > > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call
> > > nouveau_drm_device_init()"
> >
>
This has been observed using latest next-20181207.
> > > >
> > > > Does anybody know what exactly is going on and how exactly one
> > > > may get
> > > > graphics working again as before?
> > >
> > > So this is something t
On Mon, Dec 10, 2018 at 11:03:53AM +0100, Daniel Vetter wrote:
> The correct way for legacy drivers to update properties that need to
> do a full modeset, is to do a full modeset.
>
> Note that we don't need to call the drm_mode_config_internal helper
> because we're not changing any of the
On Mon 10-12-18 16:22:53, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> > On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > > I do not see any scheduler guys Cced and it would be
On Mon, Dec 10, 2018 at 05:34:21PM +0530, Sharat Masetty wrote:
> We are not really checking the state of the adreno_gpu_state_get()
> function at the callers and in addition the state capture is mostly a
> best effort service, so make the function return void.
Reviewed-by: Jordan Crouse
>
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote:
>
> It's not a core function, and the matching atomic functions are also
> not in the core. Plus the suspend/resume helper is also already there.
>
> Needs a tiny bit of open-coding, but less midlayer beats that I think.
>
> Cc: Sam Bobroff
>
On Mon, Dec 10, 2018 at 05:34:22PM +0530, Sharat Masetty wrote:
> The gpu crashstate's base objects registers pointer can be NULL if the
> target implementation decides to capture the register dump on its own.
> This patch simply checks for NULL before dereferencing.
>
> Signed-off-by: Sharat
https://bugs.freedesktop.org/show_bug.cgi?id=109001
--- Comment #3 from Michel Dänzer ---
The Xorg log file doesn't have any messages corresponding to those in dmesg.
Was it really captured after reproducing the problem?
Does
https://bugs.freedesktop.org/show_bug.cgi?id=109001
Michel Dänzer changed:
What|Removed |Added
Attachment #142770|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=109001
--- Comment #2 from Julio ---
Created attachment 142770
--> https://bugs.freedesktop.org/attachment.cgi?id=142770=edit
Xorg Log
--
You are receiving this mail because:
You are the assignee for the
On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > I do not see any scheduler guys Cced and it would be really great to get
> > their opinion here.
> >
> > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > In some special cases
https://bugs.freedesktop.org/show_bug.cgi?id=109001
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com,
https://bugs.freedesktop.org/show_bug.cgi?id=109001
Julio changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=105018
Julio changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> I do not see any scheduler guys Cced and it would be really great to get
> their opinion here.
>
> On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock,
https://bugs.freedesktop.org/show_bug.cgi?id=109001
Bug ID: 109001
Summary: Freezes when waking up after screen goes blank.
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Mon, Dec 10, 2018 at 10:00:08AM +, Guillaume Tucker wrote:
> On 08/12/2018 00:08, Lyude Paul wrote:
> > uh
> > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call
> > nouveau_drm_device_init()"
>
> Yes here's the fix from Thierry:
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=108992
chris changed:
What|Removed |Added
Summary|Regression: Lenovo e585 |Regression: Lenovo e585
I do not see any scheduler guys Cced and it would be really great to get
their opinion here.
On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the
tree: git://people.freedesktop.org/~agd5f/linux.git amd-18.30
head: 656ec78b706b16480ab37fc0751de0c3a709aa6e
commit: 656ec78b706b16480ab37fc0751de0c3a709aa6e [1/1] drm/amdgpu/vcn: Update
vcn.cur_state during suspend
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian
https://bugs.freedesktop.org/show_bug.cgi?id=108981
MirceaKitsune changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108981
--- Comment #2 from MirceaKitsune ---
It seems further debugging might not be needed: As of kernel 4.19.7 the issue
appears to go away, I'm able to boot with amdgpu normally like before. The last
kernel I still saw the problem with is 4.19.5.
Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
a écrit :
>
> Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> a écrit :
> >
> > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty much everyone needs) in
> > > the drm_crtc_helper.h file
On 06/12/18 22:26, Laurent Pinchart wrote:
> Hello,
>
> This small patch series improves the ti-tfp410 driver with three new features,
> in patch 2/5 to 5/5. Patch 1/5 has been previously posted by Stefan, and I've
> included it here to support patch 5/5 that needs to store other polarity
>
On Mon 10-12-18 11:36:38, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu
The Amlogic ARM Mali Midgard requires reset controls to power on and
software reset the GPU, adds these as optional in the bindings.
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
This patchset adds :
- Optional reset properties in the midgard bindings
- Mali T820 Node in Amlogic Meson GXM DTSI
Christian Hewitt (1):
arm64: dts: meson-gxm: Add Mali-T820 node
Neil Armstrong (1):
dt-bindings: gpu: mali-midgard: Add resets property
.../bindings/gpu/arm,mali-midgard.txt
From: Christian Hewitt
The Amlogic Meson GXM SoC embeds an ARM Mali T820 GPU.
This patch adds the node with all the needed properties to power
on the GPU.
This has been tested with the work-in-progress PanFrost project
aiming support for ARM Mali Midgard and later GPUs.
Signed-off-by:
On Mon, Dec 10, 2018 at 11:03:57AM +0100, Daniel Vetter wrote:
> Doesn't do anything with atomic.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
>
Am Freitag, den 07.12.2018, 20:11 +0100 schrieb Christian König:
> The fence seqno is now 64bit, fixes build warning.
>
> Signed-off-by: Christian König
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Mon, 2018-12-10 at 09:26 +, Colin King wrote:
Reviewed-by: Thomas Hellstrom
I'll take this in the next pull request unless I'm told otherwise.
/Thomas
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message, fix this.
>
> Signed-off-by: Colin Ian King
> ---
>
Hi Geert,
On Monday, 10 December 2018 14:30:22 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 6:36 PM Geert Uytterhoeven wrote:
> > On Sun, Nov 25, 2018 at 3:40 PM Laurent Pinchart wrote:
> >> Add the backlight device for the LVDS1 output, in preparation for panel
> >> support.
> >>
> >>
Hi Laurent,
On Tue, Dec 4, 2018 at 6:36 PM Geert Uytterhoeven wrote:
> On Sun, Nov 25, 2018 at 3:40 PM Laurent Pinchart
> wrote:
> > Add the backlight device for the LVDS1 output, in preparation for panel
> > support.
> >
> > Signed-off-by: Laurent Pinchart
>
> Reviewed-by: Geert Uytterhoeven
On 10/12/2018 11:11, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers.
The omap_dss_device type and output_type fields differ mostly for
historical reasons. The output_type field is required for all devices
but the display at the end of the pipeline, and must be set to
OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for
all devices but the internal
The gpu crashstate's base objects registers pointer can be NULL if the
target implementation decides to capture the register dump on its own.
This patch simply checks for NULL before dereferencing.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 15 ++-
1
We are not really checking the state of the adreno_gpu_state_get()
function at the callers and in addition the state capture is mostly a
best effort service, so make the function return void.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 +---
On Wed, Dec 05, 2018 at 06:08:38PM -0800, Randy Dunlap wrote:
> On 12/5/18 2:25 AM, james qian wang (Arm Technology China) wrote:
> > Signed-off-by: James (Qian) Wang
> > ---
> > Documentation/gpu/drivers.rst| 1 +
> > Documentation/gpu/komeda-kms.rst | 483 +++
https://bugs.freedesktop.org/show_bug.cgi?id=108981
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
FIMD has fixed hardware window order. To implement dynamic zpos
normalized_zpos of active plane has to be connected to window number, and
remaining windows have to be disabled.
v2: fixed pixel format setting
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 46
DECON has fixed hardware window order. To implement dynamic zpos
normalized_zpos of active plane has to be connected to window number, and
remaining windows have to be disabled.
v2: fixed pixel format setting
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45
Hardware window disabling is performed in multiple places. Creating
helper for it simplifies the code and prepares it for further improvements.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 23 +++
1 file changed, 11 insertions(+), 12
Hi Inki,
This small patchset adds dynamic zpos support for DECON and FIMD.
It was tested on tm2 and trats2.
The patchset is rebased on current exynos-drm-next.
v2:
I have forgot to update *win_set_pixfmt to set pixel format on correct window,
fixed.
Regards
Andrzej
Andrzej Hajda (3):
https://bugs.freedesktop.org/show_bug.cgi?id=108994
--- Comment #1 from Michel Dänzer ---
Please provide the actual command line you used, and its full output.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Le lun. 10 déc. 2018 à 11:24, Thierry Reding
a écrit :
>
> On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > Having the probe helper stuff (which pretty much everyone needs) in
> > the drm_crtc_helper.h file (which atomic drivers should never need) is
> > confusing. Split them
On Mon, Dec 10, 2018 at 11:21:47AM +0100, Thierry Reding wrote:
> On Sat, Dec 08, 2018 at 02:54:45PM +, Marcel Ziswiler wrote:
> > Hi Thierry et al.
> >
> > I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> > Tegra124") graphics on Apalis TK1 is broken. During boot it fails
Patches #1 and #3 are Reviewed-by: Christian König
Patch #2 is Acked-by: Christian König because
I can't judge if adding the counter in the thread structure is actually
a good idea.
In patch #4 I honestly don't understand at all how this stuff works, so
no-comment from my side on this.
On 2018-12-07 11:01 a.m., Chunming Zhou wrote:
> Signed-off-by: Chunming Zhou
> ---
> include/drm-uapi/drm.h | 33 ++
> lib/igt_syncobj.c| 204 +++
> lib/igt_syncobj.h| 19 +
> tests/gem_ctx_bad_exec | Bin 0 -> 1284384 bytes
Please run
git rm
Am 10.12.18 um 11:30 schrieb Daniel Vetter:
lkml and Linus gained a CoC, and it's serious this time. Which means
my no 1 reason for declining to officially step up as drm maintainer
is gone, and I didn't find any new good excuse.
I chatted with a few people in private already, and the biggest
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them.
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return
1 - 100 of 187 matches
Mail list logo
