Hi Linus,
Nothing too major this round, small set of mali-dp fixes, single meson
fix and a bunch of amdgpu fixes (one makes non-4k page sizes not be a
bad experience).
Thanks,
Dave.
drm-fixes-2018-06-29:
amdgpu, mali_dp and meson fixes
The following changes since commit
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #10 from Dave Airlie ---
https://patchwork.freedesktop.org/series/45627/
should fix the second breakage, after Roland's fix for the first one.
--
You are receiving this mail because:
You are the assignee for the
Hi Bartlomiej,
After merging the fbdev tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "dummycon_unregister_output_notifier" [drivers/video/fbdev/core/fb.ko]
undefined!
ERROR: "dummycon_register_output_notifier" [drivers/video/fbdev/core/fb.ko]
undefined!
Caused
https://bugs.freedesktop.org/show_bug.cgi?id=107066
--- Comment #4 from Lyude Paul ---
Still looking into this and have made a tiny bit of progress. A couple of
things to note:
- I've reproduced this with two monitors, but it's far more likely to occur
with three. So, just use three
- Whenever
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #5 from dwagner ---
Interesting: With amd-staging-drm-next, I see the same crash at
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c?h=amd-staging-drm-next#n921
with the same backtrace with
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #22 from Andrey Grodzovsky ---
(In reply to dwagner from comment #21)
> (I meant to write "I guess those register values are NOT retained over a
> reboot, right?")
Yes, my assumption was that at least some times you still have SSH
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #9 from Roland Scheidegger ---
(In reply to ubizjak from comment #7)
> Please configure the build with:
>
> CXXFLAGS="-Wp,-D_GLIBCXX_ASSERTIONS" ./autogen.sh
That didn't do anything neither. However I figured out the problem more
https://bugs.freedesktop.org/show_bug.cgi?id=106263
erhar...@mailbox.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #21 from dwagner ---
(I meant to write "I guess those register values are NOT retained over a
reboot, right?")
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #20 from dwagner ---
(In reply to Andrey Grodzovsky from comment #19)
> No need to recompile, just need to see what is the content of SDMA ring
> buffer when the hang occurs.
>
> Clone and build our register analyzer from here -
>
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #4 from dwagner ---
(In reply to Andrey Grodzovsky from comment #3)
> Can you use addr2line or gdb with 'list' command to give the line number
> matching
> amdgpu_vm_cpu_set_ptes+0x76/0xf0 ?
That would have been easy had I used my
https://bugs.freedesktop.org/show_bug.cgi?id=104300
--- Comment #2 from Harry Wentland ---
Toni, would you be able to post your dmesg log when this happens?
It looks like in Mariusz's case the DP monitor somehow reports as disconnected
when we resume. I wonder if there are issues in our DP
Hi Bartlomiej,
On Thu, 2018-06-28 at 15:50 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, June 28, 2018 11:03:48 AM Hans de Goede wrote:
> > Hi All,
> >
> > Here is v5 of my patch-set, to delay fbcon taking over the console
> > (and
> > binding to fbdev devices) until there actually is
https://bugs.freedesktop.org/show_bug.cgi?id=106276
--- Comment #2 from Harry Wentland ---
I'm a bit confused. You mention this happens after starting X, and also mention
you don't use Xorg. Can you clarify?
What kernel are you using?
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #19 from Andrey Grodzovsky ---
Can you use addr2line or gdb with 'list' command to give the line number
matching (In reply to dwagner from comment #18)
> The good news: So far no crashes during normal uptime with
>
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #3 from Andrey Grodzovsky ---
Can you use addr2line or gdb with 'list' command to give the line number
matching
amdgpu_vm_cpu_set_ptes+0x76/0xf0 ?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107066
--- Comment #3 from Lyude Paul ---
(In reply to Alex Deucher from comment #2)
> What display types are you trying to use? Using dongles?
On my home setup (which this was also seen with), nothing special. Just two
1080p DVI displays and one
https://bugs.freedesktop.org/show_bug.cgi?id=107066
--- Comment #2 from Alex Deucher ---
What display types are you trying to use? Using dongles?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=107066
Alex Deucher changed:
What|Removed |Added
Attachment #140384|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #18 from dwagner ---
The good news: So far no crashes during normal uptime with
amdgpu.vm_update_mode=3
The bad news: System crashes immediately upon S3 resume (with messages quite
different from the ones I saw with earlier
https://bugs.freedesktop.org/show_bug.cgi?id=107066
--- Comment #1 from Lyude Paul ---
Additionally I should note: disabling dc with amdgpu.dc=0 does workaround the
problem
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=107066
Bug ID: 107066
Summary: [Regression] Tonga can't bring up > 1 display since DC
enablement
Product: DRI
Version: DRI git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #2 from dwagner ---
(Just for reference: This bug report is for a different kind of S3-resume-crash
than reported in https://bugs.freedesktop.org/show_bug.cgi?id=103277 )
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #26 from dwagner ---
(In reply to Harry Wentland from comment #25)
> Is this fixed on recent kernels? If so, can we close this one?
The fix seems to be included in 4.17.2.
Remaining issue mentioned above: System will still crash
From: Ville Syrjälä
We only ever drive the panel with the fixed mode, hence we don't
want to advertize any modes that have a different vertical refresh rate.
We tried to allow a second lower clocked mode to used for eDP but
that was reverted in commit d93fa1b47b8f ("Revert "drm/i915/edp:
Allow
From: Ville Syrjälä
We want to use fixed_mode->vrefresh during mode validation, so first
make sure it's set correctly.
And we'll do the same for the downclock mode for consistency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_panel.c | 9 +
1 file changed, 9
From: Ville Syrjälä
Remove the local lvds fixed mode pointer from the sdvo encoder
structure and instead utilize intel_panel like everyone else.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sdvo.c | 40 ---
1 file changed, 21 insertions(+),
From: Ville Syrjälä
SDVO encoders can have multiple different types of outputs hanging off
them. Currently the code tries to muck around with various is_foo
flags in the encoder to figure out which type its driving. That doesn't
work with atomic and other stuff, so let's nuke those flags and
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #1 from dwagner ---
Created attachment 140383
--> https://bugs.freedesktop.org/attachment.cgi?id=140383=edit
dmesg of the system boot and before and at the crash at S3 resume
--
You are receiving this mail because:
You are the
From: Ville Syrjälä
Update mode->vrefresh before mode validation. This allows the
validation code to consult mode->vrefresh safely.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_probe_helper.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Ignore the vrefresh in the mode the user passed in and instead
calculate the value based on the actual timings. This way we can
actually trust mode->vrefresh to some degree.
Or should we compare the user's idea of vrefresh with the one
we get from the timings and return an
https://bugs.freedesktop.org/show_bug.cgi?id=107065
Bug ID: 107065
Summary: "BUG: unable to handle kernel paging request at
2000" at amdgpu_vm_cpu_set_ptes at S3
resume
Product: DRI
Version: DRI git
Currently, there is nothing in amdgpu that actually uses these structs
other than amdgpu_acpi.c. Additionally, since we're about to start
saving the correct ACPI handle to use for calling ATIF in this struct
this saves us from having to handle making sure that the acpi_handle
(and by proxy, the
Reviewed-by: Jim Qu
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index
The handles for ACPI methods like ATPX and ATIF will live under the
integrated GPU's namespace on systems with more then one GPU. ATPX is
already detected regardless of the namespace it lives in, and it will
always be in the same namespace as ATIF. So we can make things easier on
ourselves by just
The other day I was testing one of the HP laptops at my office with an
i915/amdgpu hybrid setup and noticed that hotplugging was non-functional
on almost all of the display outputs. I eventually discovered that all
of the external outputs were connected to the amdgpu device instead of
i915, and
Next version of https://patchwork.freedesktop.org/series/45371/
Notable changes:
- Added explanation on why ATIF handle sometimes lives in a different
namespace (thanks Alex!)
Lyude Paul (4):
drm/amdgpu: Make struct amdgpu_atif private to amdgpu_acpi.c
drm/amdgpu:
https://bugs.freedesktop.org/show_bug.cgi?id=106928
ubiz...@gmail.com changed:
What|Removed |Added
Attachment #140354|0 |1
is obsolete|
On Thu, Jun 28, 2018 at 06:48:50AM +0200, Jernej Škrabec wrote:
> Dne četrtek, 28. junij 2018 ob 04:06:52 CEST je Chen-Yu Tsai napisal(a):
> > On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> wrote:
> > > Current "old" method to find engine worked pretty well for DE2. However,
> > > it doesn't
On Thu, Jun 28, 2018 at 7:36 PM, Ville Syrjälä
wrote:
> On Thu, Jun 28, 2018 at 07:05:10PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > All the plane->fb/old_fb/crtc dance of __setplane_internal() is
>> >
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #7 from ubiz...@gmail.com ---
(In reply to Roland Scheidegger from comment #6)
> At a quick try I can't reproduce this on my HD 5750. Albeit I tried
> chromium, and probably not the same version.
> The replay doesn't assert neither,
On Thu, Jun 28, 2018 at 04:45:50PM +0300, Jyri Sarha wrote:
> On 28/06/18 16:13, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use drm_connector_has_possible_encoder() for checking
> > whether the encoder has an associated connector.
> >
> > v2: Replace the
On Thu, Jun 28, 2018 at 07:05:10PM +0200, Daniel Vetter wrote:
> On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > All the plane->fb/old_fb/crtc dance of __setplane_internal() is
> > pointless on atomic drivers. So let's just introduce a simpler
> >
Lucas Stach writes:
> Am Mittwoch, den 27.06.2018, 10:25 -0700 schrieb Eric Anholt:
>> > Lucas Stach writes:
>>
>> > When the hangcheck handler was replaced by the DRM scheduler timeout
>> > handling we dropped the forward progress check, as this might allow
>> > clients to hog the GPU for a
On Thu, Jun 28, 2018 at 06:56:40PM +0200, Daniel Vetter wrote:
> On Thu, Jun 28, 2018 at 04:13:09PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a convenience macro for iterating connector->encoder_ids[].
> > Isolates the users from the implementation details.
> >
> > Note
On Mon, Jun 18, 2018 at 01:01:49PM +0200, Thomas Zimmermann wrote:
> This patch set replaces functions named {un,reference} by their
> {put,get} counterparts. Affected data types are struct drm_connector,
> struct drm_gem_object, and struct drm_device.
>
> With the reference-counting functions
Hi Rob,
On 28 June 2018 at 13:52, Robert Foss wrote:
> Hey Emil,
>
> On 2018-06-25 19:36, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> Currently we dynamically allocate 16 pointers and reallocate more as
>> needed.
>>
>> Instead, allocate the maximum number (256) on stack - the number is
On Thu, Jun 28, 2018 at 04:54:56PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> All the plane->fb/old_fb/crtc dance of __setplane_internal() is
> pointless on atomic drivers. So let's just introduce a simpler
> version that skips all that.
>
> Ideally we could also skip the
On Thu, Jun 28, 2018 at 04:13:09PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a convenience macro for iterating connector->encoder_ids[].
> Isolates the users from the implementation details.
>
> Note that we don't seem to pass the file_priv down to drm_encoder_find()
> because
On Thu, Jun 28, 2018 at 10:19:41AM -0400, Alex Deucher wrote:
> On Thu, Jun 28, 2018 at 9:42 AM, Bjorn Helgaas wrote:
> > On Mon, Jun 25, 2018 at 04:06:02PM -0500, Alex Deucher wrote:
> >> So drivers can use them. This can be used to replace
> >> duplicate code in the drm subsystem.
> >>
> >>
On Thu, Jun 28, 2018 at 04:54:55PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull all the error checking out from __set_plane_internal() to a helper
> function. We'll have another user of this soon.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
>
On 28 June 2018 at 11:19, Eric Engestrom wrote:
> On Monday, 2018-06-25 17:40:02 +, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Making the output a little bit easier to parse by human beings.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> tests/drmdevice.c | 78
Hi Eric,
On 28 June 2018 at 11:21, Eric Engestrom wrote:
>> @@ -2992,16 +2992,37 @@ static int drmParseSubsystemType(int maj, int min)
>> #endif
>> }
>>
>> +static char *
>> +get_real_pci_path(int maj, int min)
>> +{
>> +char path[PATH_MAX + 1];
>> +char *real_path = malloc(PATH_MAX);
Nice catch!
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
While fairly close, the host1x and platform are two separate things.
Signed-off-by: Emil Velikov
---
tests/drmdevice.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Making the output a little bit easier to parse by human beings.
Signed-off-by: Emil Velikov
---
tests/drmdevice.c | 78 +++
1 file changed, 39
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Add a few printf statements, which should make the output easier to
parse.
Signed-off-by: Emil Velikov
---
tests/drmdevice.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
It's mildly useful program, to ship it when the user wants the "tests"
installed. Obviously the "tests" in the name is a misnomer.
Signed-off-by: Emil Velikov
---
tests/Makefile.am | 9
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
The GPU almost exclusively lives on the PCI bus, so we expose it as a
normal PCI one.
This allows any existing drmDevice users to work without any changes.
One could wonder why a separate
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Introduce a helper which gets the real sysfs path for the given pci
device.
In other words, instead opening the /sys/dev/char/*/device symlink, we
opt for the actual /sys/devices/pci*/*/
It
On Thu, Jun 28, 2018 at 9:13 AM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Instead of using the .best_encoder() hook to figure out whether a given
> connector+crtc combo will work, let's instead do what userspace does and
> just iterate over all the encoders for the connector, and then
HI,
On 28-06-18 15:50, Bartlomiej Zolnierkiewicz wrote:
On Thursday, June 28, 2018 11:03:48 AM Hans de Goede wrote:
Hi All,
Here is v5 of my patch-set, to delay fbcon taking over the console (and
binding to fbdev devices) until there actually is some text output to the
console. This is
On Thu, Jun 28, 2018 at 9:42 AM, Bjorn Helgaas wrote:
> On Mon, Jun 25, 2018 at 04:06:02PM -0500, Alex Deucher wrote:
>> So drivers can use them. This can be used to replace
>> duplicate code in the drm subsystem.
>>
>> Signed-off-by: Alex Deucher
>
> Acked-by: Bjorn Helgaas
>
> Thanks a lot
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 28/06/18 16:13, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use drm_connector_has_possible_encoder() for checking
> whether the encoder has an associated connector.
>
> v2: Replace the drm_for_each_connector_encoder_ids() loop
> with a simple drm_connector_has_possible_encoder() call
From: Ville Syrjälä
Everything (apart from the actual ->set_config() call)
__drm_mode_set_config_internal() does is now useless on
atomic drivers. So let's just skip all the foreplay.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 15 ++-
1 file changed, 10
From: Ville Syrjälä
All the plane->fb/old_fb/crtc dance of __setplane_internal() is
pointless on atomic drivers. So let's just introduce a simpler
version that skips all that.
Ideally we could also skip the __setplane_check() as
drm_atomic_plane_check() already checks for everything, but the
From: Ville Syrjälä
Pull all the error checking out from __set_plane_internal() to a helper
function. We'll have another user of this soon.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 80 +++--
1 file changed, 49 insertions(+), 31
On Thursday, June 28, 2018 11:03:48 AM Hans de Goede wrote:
> Hi All,
>
> Here is v5 of my patch-set, to delay fbcon taking over the console (and
> binding to fbdev devices) until there actually is some text output to the
> console. This is intended for use with the "quiet" cmdline option, in
>
On Thu, Jun 28, 2018 at 04:13:06PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Changes from the previous version mainly involve Danoie's suggestion
Can't type today either: "Daniel's"
> of hiding the drm_encoder_find() in the iterator macro. I also polished
> the msm and tilcdc cases
On Mon, Jun 25, 2018 at 04:06:02PM -0500, Alex Deucher wrote:
> So drivers can use them. This can be used to replace
> duplicate code in the drm subsystem.
>
> Signed-off-by: Alex Deucher
Acked-by: Bjorn Helgaas
Thanks a lot for doing this!
If you haven't applied these yet, please
s/pci:
The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.
This doesn't even remotely describe the actual Versatile
Express hardware. Exploit the SiI9022 bridge by
Update the Versatile Express defconfig to match the
Kconfig changes in the kernel.
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Signed-off-by: Linus Walleij
---
ChangeLog v1->v3:
- Rebased
---
arch/arm/configs/vexpress_defconfig | 12
1 file changed, 12 deletions(-)
diff --git
This updates the Versatile defconfig to use the new P111 DRM
driver that is merged in the DRM subsystem.
We deactivate the old CLCD driver and activate the Pl111 DRM
driver and the SiI9022 HDMI bridge.
We activate DMA memory allocation using CMA so that the special
graphics memory for the
On Wed, Jun 27, 2018 at 11:25:06PM +0200, Enric Balletbo i Serra wrote:
> From: Gustavo Padovan
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and
From: Ville Syrjälä
Use drm_connector_has_possible_encoder() for checking
whether the encoder has an associated connector.
v2: Replace the drm_for_each_connector_encoder_ids() loop
with a simple drm_connector_has_possible_encoder() call
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Signed-off-by:
From: Ville Syrjälä
Use drm_connector_has_possible_encoder() for checking
whether the encoder has an associated connector.
v2: Replace the drm_for_each_connector_encoder_ids() loop
with a simple drm_connector_has_possible_encoder() call
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc:
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc:
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc:
From: Ville Syrjälä
With the fb-helper no longer relying on the non-atomic .best_encoder()
we can eliminate the hook from the MST encoder.
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Reviewed-by: Daniel Vetter
Reviewed-by: Alex Deucher
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Use drm_connector_for_each_possible_encoder() for iterating
connector->encoder_ids[]. A bit more convenient not having
to deal with the implementation details.
v2: Replace drm_for_each_connector_encoder_ids() with
drm_connector_for_each_possible_encoder() (Daniel)
Cc:
From: Ville Syrjälä
Add a small helper for checking whether a connector and
encoder are associated with each other.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 23 +++
include/drm/drm_connector.h | 3 +++
2 files changed, 26 insertions(+)
diff
From: Ville Syrjälä
Changes from the previous version mainly involve Danoie's suggestion
of hiding the drm_encoder_find() in the iterator macro. I also polished
the msm and tilcdc cases a bit more with another small helper.
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: Ben Skeggs
Cc:
From: Ville Syrjälä
Instead of using the .best_encoder() hook to figure out whether a given
connector+crtc combo will work, let's instead do what userspace does and
just iterate over all the encoders for the connector, and then check
each crtc against each encoder's possible_crtcs bitmask.
v2:
From: Ville Syrjälä
Add a convenience macro for iterating connector->encoder_ids[].
Isolates the users from the implementation details.
Note that we don't seem to pass the file_priv down to drm_encoder_find()
because encoders apparently don't get leased. No idea why
drm_encoder_finc() even
Hey Emil,
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Currently we dynamically allocate 16 pointers and reallocate more as
needed.
Instead, allocate the maximum number (256) on stack - the number is
small enough and is unlikely to change in the foreseeable future.
This
On Thu, Jun 28, 2018 at 2:22 AM, Jim Qu wrote:
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
>
> In currect HDA audio driver, it will set all
On 22.06.2018 01:17, Eric Anholt wrote:
> This allows panels or bridges that need to send DSI commands during
> pre_enable() to successfully send them. We delay DISP0 (aka the
> actual display) enabling until after pre_enable so that pixels aren't
> streaming before then.
>
> v2: Just clear out
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Don't the duplicate (nearly) identical code across the two call sites.
It improves legibility and the diff stat seems nice.
Signed-off-by: Emil Velikov
---
xf86drm.c | 159
[ The bot has a bug where it doesn't copy the error messages so I just
guess what the issue is. - dan ]
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Ramalingam-C/drm-i915-Implement-HDCP2-2/20180627-174219
base:
On Thu, Jun 28, 2018 at 10:07 AM, Daniel Vetter wrote:
> On Thu, Jun 28, 2018 at 12:24:35AM +0300, Haneen Mohammed wrote:
>> Implement the .set_crc_source() callback.
>> Compute CRC using crc32 on the visible part of the framebuffer.
>> Use work_struct to compute and add CRC at the end of a
https://bugzilla.kernel.org/show_bug.cgi?id=199621
--- Comment #7 from Matthew Trescott (matthewtresc...@gmail.com) ---
I should note that that xrandr command, if run while the display is on, will
turn it off. It seems to act as a sort of toggle.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #17 from Andrey Grodzovsky ---
(In reply to Alex Deucher from comment #16)
> (In reply to Andrey Grodzovsky from comment #15)
> > I think it just means systems with large VRAM so it will require large BAR
> > for mapping. But I am
On Thursday, 2018-06-28 11:21:26 +0100, Eric Engestrom wrote:
> On Monday, 2018-06-25 17:39:14 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Introduce a helper which gets the real sysfs path for the given pci
> > device.
> >
> > In other words, instead opening the
On Monday, 2018-06-25 17:39:14 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Introduce a helper which gets the real sysfs path for the given pci
> device.
>
> In other words, instead opening the /sys/dev/char/*/device symlink, we
> opt for the actual /sys/devices/pci*/*/
>
> It folds
On Monday, 2018-06-25 17:40:02 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Making the output a little bit easier to parse by human beings.
>
> Signed-off-by: Emil Velikov
> ---
> tests/drmdevice.c | 78 +++
> 1 file changed, 39
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Currently we match the opened drmDevice fd with each drmDevice we
process.
Move that after all the devices are processed and folded, via the
drm_device_has_rdev(). This makes the code easier to
Feel free to add my r-b to this patch.
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Currently one can open() any /dev node. If it's unknown
drmParseSubsystemType() will return an error.
Track that and bail as needed.
Signed-off-by: Emil Velikov
---
xf86drm.c | 2 ++
1
This series has been:
Tested-by: Robert Foss
On 2018-06-25 19:36, Emil Velikov wrote:
From: Emil Velikov
Currently one can open() any /dev node. If it's unknown
drmParseSubsystemType() will return an error.
Track that and bail as needed.
Signed-off-by: Emil Velikov
---
xf86drm.c | 2 ++
On 06/22/2018 10:11 PM, Christian König wrote:
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf
On 06/22/2018 10:11 PM, Christian König wrote:
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by:
1 - 100 of 157 matches
Mail list logo
