This is a DRM based driver for the Atmel LCDC IP.
There exist today a framebuffer based driver and
this is a re-implmentation of the same on top of DRM.
The rewrite was based on the original fbdev driver
but the driver has also seen inspiration from
the atmel-hlcdc_dc driver and others.
The drive
Hi,
today i accidently found a regression on the Raspberry Pi 3 with
arm64/defconfig (bcm2835_defconfig and multi_v7_defconfig are not affected) in
current 4.18.
Symptoms: Raspberry Pi 3 boots to serial console, but vc4 won't probe (no vc4
in the kernel messages) and the display stays black
I
On 2018-08-13 22:52, Rob Herring wrote:
> On Mon, Aug 13, 2018 at 8:25 AM Peter Rosin wrote:
>>
>> On 2018-08-13 15:59, jacopo mondi wrote:
>>> Hi Peter,
>>>
>>> On Fri, Aug 10, 2018 at 03:03:58PM +0200, Peter Rosin wrote:
This enables more flexible devicetrees. You can e.g. have two output
>
Hi Nicholas.
On Mon, Aug 13, 2018 at 05:54:48PM +0200, Nicolas Ferre wrote:
> On 12/08/2018 at 20:41, Sam Ravnborg wrote:
> >New DRM based driver for at91sam9 SOC's that uses the
> >Atmel LCDC IP core.
>
> I'm delighted to see this work: Thanks a lot Sam!
Glad to hear.
I was a bit worried that th
The LCDC IP used by some Atmel SOC's have a
multifunction device that include two sub-devices:
- pwm
- display controller
This binding describe the multi function device
that act as root for the sub-devices
The Atmel SOC's are at91sam9 etc.
The compatible name is intentionally
prefixed with -mfd
On Wed, Aug 08, 2018 at 10:23:27AM +0200, Daniel Vetter wrote:
> On Wed, Aug 08, 2018 at 06:53:17AM +0300, Haneen Mohammed wrote:
> > On Tue, Aug 07, 2018 at 06:33:36PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 06, 2018 at 06:58:29AM +0300, Haneen Mohammed wrote:
> > > > This patch compute CRC
On 12/08/2018 at 21:55, Sam Ravnborg wrote:
The at91sam9263 has a few interesting "GPU" features:
- 2D memory addressing
Data sheet says:
The LCDC can be configured to work on a frame buffer
larger than the actual screen size. By changing the
values in a few registers,
The LCDC IP used by some Atmel SOC's have a
multifunction device that include two sub-devices:
- pwm
- display controller
This mfd device provide a regmap that can be used by the
sub-devices to safely access the registers.
The mfd device also support the clock used by the
LCDC IP + a b
Use vendor name for directory, adding a suitable place
for more atmel DRM drivers.
Signed-off-by: Sam Ravnborg
Cc: Boris Brezillon
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/gpu/drm/Makefile
The LCDC IP used by some Atmel SOC's have a
multifunction device that include two sub-devices:
- pwm
- display controller
This binding describe the lcdc display controller and
refer back to the mfd device that this must be a child node of.
Signed-off-by: Sam Ravnborg
Cc: Boris Brezillon
---
..
在 2018-07-24二的 14:37 +0200，Maxime Ripard写道：
> On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote:
> > Hi Maxime,
> >
> > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard
> > napisal(a):
> > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote:
> > > > This series
New DRM based driver for at91sam9 SOC's that uses the
Atmel LCDC IP core.
This is first version of a patch set that adds
drivers for the Atmel LCDC IP core.
Posted for review as the basics works now.
The LCDC IP core contains two devices:
- a PWM often used for backlight
- a LCD display controlle
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
suspend_state can be removed from vmw_private as
it will not be used anymore.
Signed-off-by: Ajit Negi
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +++---
drivers/gpu/drm
The LCDC IP used by some Atmel SOC's have a
multifunction device that include two sub-devices:
- pwm
- display controller
This driver add support for the pwm sub-device
exposing a single PWM device that can be used
for backlight.
The driver is based on the pwm-atmel-hlcdc driver.
Signed-off-by:
在 2018-08-13一的 13:49 +0200，Andrzej Hajda写道：
> On 25.07.2018 05:56, Icenowy Zheng wrote:
> > Currently dw_hdmi_setup is only run when the dw-hdmi bridge is
> > enabled,
> > with the mode set last time.
> >
> > When the bridge is enabled before any mode is set (this may happen
> > when
> > booting),
On Friday, 10 August 2018 02:12:11 MSK Dmitry Osipenko wrote:
> From time to time new bugs are popping up, causing some host1x client to
> fail its initialization. Currently a single clients initialization failure
> causes whole host1x device registration to fail, as a result a single DRM
> sub-dev
On 2018-08-13 15:59, jacopo mondi wrote:
> Hi Peter,
>
> On Fri, Aug 10, 2018 at 03:03:58PM +0200, Peter Rosin wrote:
>> This enables more flexible devicetrees. You can e.g. have two output
>> nodes where one is not enabled, without the ordering affecting things.
>>
>> Prior to this patch the acti
On Wed, 2018-08-08 at 20:57 +0200, Stefan Agner wrote:
> On 08.08.2018 18:08, Leonard Crestez wrote:
> > The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
> > immediately reenabled in mxsfb_enable_controller.
> >
> > Avoid this by moving the handling of axi clk one level up t
On 12/08/2018 at 20:41, Sam Ravnborg wrote:
New DRM based driver for at91sam9 SOC's that uses the
Atmel LCDC IP core.
I'm delighted to see this work: Thanks a lot Sam!
This is first version of a patch set that adds
drivers for the Atmel LCDC IP core.
Posted for review as the basics works now.
The at91sam9263 has a few interesting "GPU" features:
- 2D memory addressing
Data sheet says:
The LCDC can be configured to work on a frame buffer
larger than the actual screen size. By changing the
values in a few registers, it is easy to move the
displayed area
Hi Laurent,
On Mon, Aug 13, 2018 at 10:46 PM, Liviu Dudau wrote:
> On Thu, Aug 02, 2018 at 03:25:24PM +0530, Souptick Joarder wrote:
>> On Wed, Aug 1, 2018 at 12:11 AM, Souptick Joarder
>> wrote:
>> > On Tue, Jul 31, 2018 at 4:04 PM, Liviu Dudau wrote:
>> >> Hi Souptick,
>> >>
>> >> On Tue, Ju
The LCDC IP used by some Atmel SOC's have a
multifunction device that include two sub-devices:
- pwm
- display controller
This binding describe the pwm binding and refer back to
the mfd device that this must be a child node of.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Boris Brezillon
Am 14.08.2018 um 05:05 schrieb Huang Rui:
On Tue, Aug 14, 2018 at 10:26:43AM +0800, Zhang, Jerry wrote:
On 08/13/2018 05:58 PM, Huang Rui wrote:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle lis
On Tue, Aug 14, 2018 at 1:43 PM, Icenowy Zheng wrote:
> 在 2018-07-24二的 14:37 +0200，Maxime Ripard写道：
>> On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote:
>> > Hi Maxime,
>> >
>> > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard
>> > napisal(a):
>> > > On Tue, Jul 10, 2018
On Mon, Aug 13, 2018 at 12:49:13PM +0200, Maarten Lankhorst wrote:
> Op 05-06-18 om 11:07 schreef Lowry Li:
> > On Mon, Jun 04, 2018 at 02:49:26PM +0100, Emil Velikov wrote:
> >> On 1 June 2018 at 13:41, Lowry Li wrote:
> >>> Pixel blend modes represent the alpha blending equation
> >>> selection,
On Tue, Aug 14, 2018 at 10:26:43AM +0800, Zhang, Jerry wrote:
> On 08/13/2018 05:58 PM, Huang Rui wrote:
> > I continue to work for bulk moving that based on the proposal by Christian.
> >
> > Background:
> > amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move
> > all of
> >
On Tue, Aug 14, 2018 at 10:22:34AM +0800, Zhang, Jerry (Junwei) wrote:
> On 08/13/2018 06:16 PM, Christian König wrote:
> >Am 13.08.2018 um 11:58 schrieb Huang Rui:
> >>From: Christian König
> >>
> >>Add bulk move pos to store the pointer of first and last buffer object.
> >>The list in between wi
On 08/13/2018 05:58 PM, Huang Rui wrote:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end
On Tue, Aug 14, 2018 at 10:02:00AM +0800, Zhou, David(ChunMing) wrote:
>
>
> On 2018年08月13日 18:16, Christian König wrote:
> > Am 13.08.2018 um 11:58 schrieb Huang Rui:
> >> From: Christian König
> >>
> >> Add bulk move pos to store the pointer of first and last buffer object.
> >> The list in be
On 08/13/2018 06:16 PM, Christian König wrote:
Am 13.08.2018 um 11:58 schrieb Huang Rui:
From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
On 2018年08月13日 18:16, Christian König wrote:
Am 13.08.2018 um 11:58 schrieb Huang Rui:
From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #4 from Sylvain BERTRAND ---
Sure, but there are very few commits. Basically, it's almost directly the
commits related to the handle table:
87fdbfb62fb3de6759d465d07cc13f922084694e stable commit
879d7c0298d1d4bc52d71d599cc07cafb46458
msm_drm.h file Generated using make headers_install.
Generated from
tree - git://people.freedesktop.org/~airlied/linux
branch - drm-next
commit - 6d08b06e67cd117f6992c46611dfb4ce267cd71e
Remove freedreno/msm/msm_drm.h to maintain only
one copy of msm_drm.h and change freedreno Makefile
and meson.
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #3 from Bas Nieuwenhuizen ---
Even if you cannot get a backtrace, can you bisect to show the exact commit
which causes the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Jul 31, 2018 at 01:11:15AM +0200, Giulio Benetti wrote:
> Add documentation for S070WV95-CT16 panel
>
> Signed-off-by: Giulio Benetti
> ---
> .../bindings/display/panel/cdtech,s070wv95-ct16.txt | 12
> 1 file changed, 12 insertions(+)
> create mode 100644
> Documentation/
On Tue, Jul 31, 2018 at 01:11:17AM +0200, Giulio Benetti wrote:
> Add documentation for S043WQ26H-CT7 panel
>
> Signed-off-by: Giulio Benetti
> ---
> .../bindings/display/panel/cdtech,s043wq26h-ct7.txt | 12
> 1 file changed, 12 insertions(+)
> create mode 100644
> Documentation/
On Tue, Jul 31, 2018 at 01:11:13AM +0200, Giulio Benetti wrote:
> This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited
>
> Website: www.cdtech-lcd.com
>
> Signed-off-by: Giulio Benetti
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 in
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 6a77c1ba182d156a8b0b4057e23e8a01d9f451a7
commit: d49f1308cd52389f3ba64b0cd98c7a50ed83932a [62/85] drm/amdgpu:add VCN
booting with firmware loaded by PSP
reproduce:
# apt-get install sparse
git checkout
On Mon, Aug 13, 2018 at 08:18:08PM +0200, Sam Ravnborg wrote:
> Hi Nicholas.
>
> On Mon, Aug 13, 2018 at 05:54:48PM +0200, Nicolas Ferre wrote:
> > On 12/08/2018 at 20:41, Sam Ravnborg wrote:
> > >New DRM based driver for at91sam9 SOC's that uses the
> > >Atmel LCDC IP core.
> >
> > I'm delighted
From: Sean Paul
This patch adds a 70ms mystery delay to the bridge driver in enable.
By experimentation, it seems like it can go anywhere up until we
initiate semi-auto link training. If we don't have the delay, link
training fails.
I tried to root cause this as best I could, but neither the dat
From: Sean Paul
prepare() is the old-timey way to say pre_enable(). It should be called
before modeset. This fixes an issue where the panel on cheza must have
the regulator always-on/boot-on for it to work.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
driv
From: Sean Paul
Instead of just waiting 20ms for training to complete, actually poll the
status to ensure training is finished.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 +++-
1 file changed, 11 inserti
From: Sean Paul
Instead of just waiting and hoping, actually poll for the pll lock to be
acquired. As a bonus, this should be significantly faster than the
sleep.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 10 +
From: Sean Paul
Order registers by offset and rename bits & masks to match the
datasheet. This makes the driver a bit easier to grok and
cross-reference with the datasheet.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c
From: Sean Paul
We noticed the bridge/panel on our devices stopped working if the
regulator wasn't always-on/boot-on. In an attempt to fix that, I came up
with the following patches. I've sent some of them up to the list
already, but none have landed, so I'll concatonate them in this series
going
From: Sean Paul
This was hand-rolled in the first version, and will surely be useful as
we expand the driver to support more varied use cases.
Changes in v2:
- Change subject prefix s/panel/bridge/
- Downgrade warning in poll function to error message
- Fix DP_EDP_CONFIGURATION_SET write value (
From: Sean Paul
The panel datasheet specifies a 500ms delay after power-down before
re-enabling.
Changes in v2:
- None
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
When debugfs is disabled, but coredump is turned on, the adreno driver fails to
build:
drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:4: error: 'struct msm_gpu_funcs' has
no member named 'show'
.show = adreno_show,
^~~~
drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:11: note: (near initialization f
The function prototype recently changed, but the patch missed the
second prototype that is used when CONFIG_DEV_COREDUMP is disabled:
drivers/gpu/drm/msm/msm_gpu.c: In function 'recover_worker':
drivers/gpu/drm/msm/msm_gpu.c:461:34: error: passing argument 2 of
'msm_gpu_crashstate_capture' from i
On Mon, Aug 13, 2018 at 8:25 AM Peter Rosin wrote:
>
> On 2018-08-13 15:59, jacopo mondi wrote:
> > Hi Peter,
> >
> > On Fri, Aug 10, 2018 at 03:03:58PM +0200, Peter Rosin wrote:
> >> This enables more flexible devicetrees. You can e.g. have two output
> >> nodes where one is not enabled, without
Hi Souptick,
On Monday, 13 August 2018 21:51:31 EEST Souptick Joarder wrote:
> On Mon, Aug 13, 2018 at 10:46 PM, Liviu Dudau wrote:
> > On Thu, Aug 02, 2018 at 03:25:24PM +0530, Souptick Joarder wrote:
> >> On Wed, Aug 1, 2018 at 12:11 AM, Souptick Joarder wrote:
> >>> On Tue, Jul 31, 2018 at 4:0
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #20 from Jordan L ---
Hi Brad,
Would you happen to have a *full* dmesg and Xorg.0 log of the latest? Generally
that error message shouldn't cause a hang, just that one connector the bios is
reporting isn't mapped/supported properly.
Hi,
On Mon, Aug 13, 2018 at 02:12:44PM +0300, Tomi Valkeinen wrote:
> On 06/08/18 23:36, Laurent Pinchart wrote:
>
> > The series is based on top of the previously submitted "[PATCH v2 00/21]
> > omapdrm: Rework the HPD-related operations" patch series. For convenience
> > I've
> > pushed it to
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --
Does what it says on the label, a lot of these calls are already handled
somewhere else and don't appear to be here for a legitimate reason
anymore.
Lyude Paul (3):
drm/nouveau: Remove useless poll_enable() call in
switcheroo_set_state()
drm/nouveau: Remove useless poll_disable() call in
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 1 -
1 file changed, 1 deleti
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga
https://bugzilla.kernel.org/show_bug.cgi?id=200809
Bug ID: 200809
Summary: lightdm/Xorg freezes on startup everytime
Product: Drivers
Version: 2.5
Kernel Version: 4.18.0-rc8
Hardware: x86-64
OS: Linux
Tree: Ma
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector probi
Latest version of https://patchwork.freedesktop.org/series/46815/ , with
one small change re: ilia
Lyude Paul (5):
drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement
drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()
drm/nouveau: Fix deadlock with fb_helper wit
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_en
I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
drm_fb_helper_hotplug_event()
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
Signed-off-
On Mon, 2018-08-13 at 15:11 -0400, Ilia Mirkin wrote:
> On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> > +bool
> > +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> > +{
> > + bool hotplug;
> > +
> > + if (!fbcon)
> > + return false;
> > +
> > +
On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> +bool
> +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> +{
> + bool hotplug;
> +
> + if (!fbcon)
> + return false;
> +
> + mutex_lock(&fbcon->hotplug_lock);
> + hotplug = fbcon->hotplug_w
I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
drm_fb_helper_hotplug_event()
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector probi
Latest version of https://patchwork.freedesktop.org/series/46815/ with
some significant improvements:
- I finally figured out a clean way to do this entirely with runtime PM
helpers, no avoiding grabbing refs required!
- Since this new method removes the need for a lot of the other changes
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_en
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
Signed-off-
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding
https://bugs.freedesktop.org/show_bug.cgi?id=107561
Bug ID: 107561
Summary: [amdgpu] / rx550 / half the fps after thaw
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #2 from Sylvain BERTRAND ---
I did a lot of testing and dumped cores (libsegfault.so or catchsegv do not
work with steam/dota2), the issue is actually random: sometimes it works, most
of the time it crashes or hangs the vulkan dota2
On Thu, Aug 02, 2018 at 03:25:24PM +0530, Souptick Joarder wrote:
> On Wed, Aug 1, 2018 at 12:11 AM, Souptick Joarder
> wrote:
> > On Tue, Jul 31, 2018 at 4:04 PM, Liviu Dudau wrote:
> >> Hi Souptick,
> >>
> >> On Tue, Jul 31, 2018 at 12:31:37AM +0530, Souptick Joarder wrote:
> >>> convert drm_a
Attached.
If the general idea in the patch is OK I can think of a test (and maybe
add to libdrm amdgpu tests) to actually simulate this scenario with 2 forked
concurrent processes working on same entity's job queue when one is
dying while the other keeps pushing to the same queue. For now I o
https://bugs.freedesktop.org/show_bug.cgi?id=97025
--- Comment #30 from Fermulator ---
note, experiencing the same (or at least similar) issues -- my story is bug'd
here:
* https://bugs.freedesktop.org/show_bug.cgi?id=107560
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107560
--- Comment #1 from Fermulator ---
Created attachment 141068
--> https://bugs.freedesktop.org/attachment.cgi?id=141068&action=edit
full stack trace after the issue eventually
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=107560
Bug ID: 107560
Summary: radeon (amdgpu) GDM flip queue failed invalid
argument, DisplayPort issues
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
Track whenever an virtual output (crtc) is enabled or disabled.
On atomic updates check for both framebuffer being present and crtc
being enabled to figure whenever the output is active or not.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virt
On Mon, Aug 13, 2018 at 4:49 PM Alex Deucher wrote:
>
> On Sun, Aug 12, 2018 at 3:55 AM Christian König
> wrote:
> > Adding Harry as well.
> > Am 11.08.2018 um 17:54 schrieb Arnd Bergmann:
> > >
> > > Fixes: bf2e2e2e0ea9 ("drm/amd/display: Limit DCN to x86 arch")
> > > Fixes: 4841203102a3 ("drm/a
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Ch
This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
- Now control node will print all the available sources if
implemented by driver along with current source.
- Setting of sorce will fail if provided source is not supported
- cleanup o
This patch implements "verify_crc_source" callback function for
Virtual KMS drm driver.
Cc: dri-devel@lists.freedesktop.org
Cc: Haneen Mohammed
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/vkms/vkms_crc.c | 36
drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
dr
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.
Suggested-by: Ville Syrjälä
Signed-off-by: Mahesh Kumar
Cc:
On Sun, Aug 12, 2018 at 3:55 AM Christian König
wrote:
>
> Adding Harry as well.
>
> Am 11.08.2018 um 17:54 schrieb Arnd Bergmann:
> > Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
> > and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many
> > functions
https://bugs.freedesktop.org/show_bug.cgi?id=106287
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=101978
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=106224
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=103915
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=106875
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=101384
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=101675
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=104602
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=100069
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=100400
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
Hi Peter,
On Fri, Aug 10, 2018 at 03:03:58PM +0200, Peter Rosin wrote:
> This enables more flexible devicetrees. You can e.g. have two output
> nodes where one is not enabled, without the ordering affecting things.
>
> Prior to this patch the active node had to have endpoint id zero.
>
> Signed-
On Tue, Aug 07, 2018 at 08:12:28PM -0700, Jeykumar Sankaran wrote:
> cleans up left out scalar config definitions from headers
>
> changes in v2:
> - none
> changes in v3:
> - none
>
> Change-Id: Id824dd5075c666f97b964573c97215bb786eac75
Please strip Change-Id before sending patches.
https://bugs.freedesktop.org/show_bug.cgi?id=107454
--- Comment #1 from Gert Wollny ---
Can you retry with
R600_DEBUG=nosb blender?
For me it seems to mostly fix ESM (when comparing to VSM)
--
You are receiving this mail because:
You are the assignee for the bug.
On 08/13/2018 02:28 PM, Thomas Zimmermann wrote:
Hi
Am 13.08.2018 um 12:33 schrieb Christian König:
Yes, please! I had it on my TODO list to clean that up for an eternity.
On top of these patches, I have a patch set that provides a single
init/release interface for TTM global data. I'll post i
1 - 100 of 132 matches
Mail list logo
