On Thu, 02 Feb 2017, Shuah Khan wrote:
> Change drm_helper_probe_single_connector_modes() to print an error to
> report connector disconnected status instead of a debug message.
>
> When this condition occurs, application doesn't know the real error and
> reports it as driver lacking support for m
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> Jani Nikula writes:
>
> > On Tue, 31 Jan 2017, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >>> Despite all the careful planing of the kernel, a link may become
> >>> insufficient to handle the currently-set mode. At this poi
https://bugs.freedesktop.org/show_bug.cgi?id=99637
Matt Whitlock changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99637
Michel Dänzer changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=99549
--- Comment #1 from Marek Olšák ---
Try to disable post processing in drirc.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedes
On Wed, Feb 01, 2017 at 12:50:48PM -0800, Eric Anholt wrote:
> Gabriel Krisman Bertazi writes:
>
> > Instead of receiving the num_crts as a parameter, we can read it
> > directly from the mode_config structure. I audited the drivers that
> > invoke this helper and I believe all of them (but one,
https://bugs.freedesktop.org/show_bug.cgi?id=99637
--- Comment #4 from Nayan Deshmukh ---
(In reply to Michel Dänzer from comment #3)
> This report should remain open until the fix lands on the 17.0 branch.
I will nominate the patch for the 17.0 branch.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #10 from Samuel Pitoiset ---
Which version of Total War: Warhammer?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
[SNIP]
OTOH the people running the kernel aren't always the same people
building it, so the downside is that this would potentially delay
getting X86_PAT enabled.
And exactly for this reason I would rather like to keep the warning.
Regards,
Christi
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing d
https://bugs.freedesktop.org/show_bug.cgi?id=99444
--- Comment #15 from Samuel Pitoiset ---
(In reply to Józef Kucia from comment #13)
> (In reply to Samuel Pitoiset from comment #12)
> > Well yeah, it's definitely unrelated to Mesa/RadeonSI. The app should check
> > if NV_register_combiners is s
On Thu, Feb 02, 2017 at 09:36:32AM +, Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
> module reference and may live
The platform driver name is currently "meson" which can lead to some
confusion, this patch renames it to "meson-drm" and removes the owner
attribute.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/
This patchset is a simple fixup to rename the confusion possible
module and driver name "meson" to a more explicit "meson-drm" name.
Neil Armstrong (2):
drm: meson: rename module name to meson-drm
drm: meson: rename driver name to meson-drm
drivers/gpu/drm/meson/Makefile| 6 +++---
drive
The module is currently names "meson.ko" which can lead to some
confusion, this patches renames it "meson-drm.ko"
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gp
On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:02 PM, Ville Syrjälä wrote:
> > On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> >> than 340Mhz
Hi Dave,
this is the Etnaviv feature pull request for 4.11.
It includes code cleanups from Bhumika and Liviu, a significant shader
performance fix and additions to the cmdstream validator from Wladimir
and the addition of a cmdbuf suballocator by myself.
The suballocator improves performance on a
On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
> > On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> >> Geminilake platform has a native HDMI 2.0 controller, and is
> >> capable of driving
Regards
Shashank
On 2/2/2017 3:21 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:02 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for
On 02/01/2017 01:17 PM, Andrzej Hajda wrote:
Hi Archit,
Sorry for spamming, forgot to add the list.
This quite big patchset adds support for 4K Ultra HD modes in SiI8620 MHL
bridge.
To support it full MHL3 protocol and its sub-protocols should be implemented.
Patchset contains also various f
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #8 from fin4...@hotmail.com ---
Alex, thanks for the new firmware. Still Bios recognition errors at boot, but
otherwise ok.
[3.461112] [drm] BIOS signature incorrect 20 7
[3.461117] amdgpu :01:00.0: Invalid PCI ROM header
On Thu, Feb 02, 2017 at 03:46:55PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/2/2017 3:21 PM, Ville Syrjälä wrote:
> > On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 2/1/2017 10:02 PM, Ville Syrjälä wrote:
From: Stefan Christ
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
th
From: Xinliang Liu
This patch add a config to support to create multi buffer for cma fbdev.
Such as double buffer and triple buffer.
Cma fbdev is convient to add a legency fbdev. And still many Android
devices use fbdev now and at least double buffer is needed for these
Android devices, so that
Hi,
This is a respin of the previous serie called "Support fast framebuffer
panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been
removed, and the comments that were made at that time fixed (hopefully).
Let me know what you think,
Maxime
Changes from v1:
- Added drm_fb_helpe
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #9 from fin4...@hotmail.com ---
After updating the firmware I still have powerplay erros:
[3.574222] amdgpu: [powerplay] [AVFS] Something is broken. See log!
[3.577052] amdgpu: [powerplay] Can't find requested voltage id in
vd
Regards
Shashank
On 2/2/2017 3:58 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 03:46:55PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/2/2017 3:21 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:02
On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> The platform driver name is currently "meson" which can lead to some
> confusion, this patch renames it to "meson-drm" and removes the owner
> attribute.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_drv.c
Regards
Shashank
On 2/2/2017 3:32 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
Geminilake platform has a native HDMI
On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> disposable private objects") introduced a regression for the kernel
> running as Xen dom0: when switching to graphics mode a GPU HANG
> occurred.
>
> Reason seem
On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
>> The platform driver name is currently "meson" which can lead to some
>> confusion, this patch renames it to "meson-drm" and removes the owner
>> attribute.
>>
>> Signed-off-by: Neil Arm
On Thu, Feb 02, 2017 at 11:48:21AM +0100, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> > disposable private objects") introduced a regression for the kernel
> > running as Xen dom0:
On Wed, 01 Feb 2017, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides the
> symbolic names for the various regist
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 100 +
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
Sure, Thanks for the information, will add that in V2.
Regards
Shashank
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Thursday, February 2, 2017 4:55 PM
To: Sharma, Shashank ;
dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
ville.sy
On Thu, Feb 02, 2017 at 11:50:59AM +0100, Neil Armstrong wrote:
> On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> > On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> >> The platform driver name is currently "meson" which can lead to some
> >> confusion, this patch renames it to "meso
On 02/02/2017 09:47, Juergen Gross wrote:
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption sim
On Thu, Feb 02, 2017 at 12:11:29PM +, Tvrtko Ursulin wrote:
>
> On 02/02/2017 09:47, Juergen Gross wrote:
> >Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> >disposable private objects") introduced a regression for the kernel
> >running as Xen dom0: when switching to gr
On Thu, Feb 02, 2017 at 04:15:21PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/2/2017 3:32 PM, Ville Syrjälä wrote:
> > On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
Dear Thierry,
2017년 02월 01일 23:44에 Thierry Reding 이(가) 쓴 글:
> On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote:
>>
>>
>> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
>>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
Thierry Reding writes:
> [ Unknown signatu
https://bugs.freedesktop.org/show_bug.cgi?id=97861
--- Comment #4 from Elia Argentieri ---
Same problem on R7 370 except that my monitor shows a black screen and reports
"frequency not supported".
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, Jan 04, 2017 at 08:42:25PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that framebuffers can be used even before calling
> drm_framebuffer_init() we can start to plumb them into more places,
> instead of passing individual pieces for fb metadata.
>
> Signed-
Am Donnerstag, den 02.02.2017, 11:44 + schrieb Chris Wilson:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the
On Wed, Jan 04, 2017 at 08:42:26PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's try to keep the alignment requirements in one place, and so
> towards that end let's move the AUX_DIST alignment handling into
> intel_surf_alignment() alongside the main surface alignme
On Wed, Jan 04, 2017 at 08:42:27PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> To make life easier let's allow skl_plane_stride() to be called for the
> AUX surface even when there is no AUX surface. Avoids special cases in
> the callers.
>
> Signed-off-by: Ville Syrjäl
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #19 from Jean-François Fortin Tam ---
What would be the equivalent in the systemd/journalctl world? Apparently Fedora
25 doesn't generate Xorg.log files anymore, the last modification timestamp on
that one file is october 10th 2016...
On Tue, Jan 31, 2017 at 10:51:06PM +0100, Thierry Reding wrote:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> [...]
> > As is, I'm stuck out here with my panel driver I submitted on December
> > 14th completely ignored, and no other developer will look at it because
> > their rev
On Thu, Feb 2, 2017 at 6:44 AM, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficie
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #10 from Steven A. Falco ---
Thanks for the information on building a new kernel. I'll give that a try.
I'm running Fedora 25, but I think I can follow your Debian instructions.
--
You are receiving this mail because:
You are watc
On Wed, Jan 04, 2017 at 08:42:28PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Based on empirical evidence the display engine (at least) always
> treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions
> change based on the pixel format. Let's adjust our
On Thu, Feb 02, 2017 at 02:33:54PM +0100, Lucas Stach wrote:
> Am Donnerstag, den 02.02.2017, 11:44 + schrieb Chris Wilson:
> > @@ -192,6 +188,8 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> > *mmu,
> > list_del_init(&m->scan_node);
> > }
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=99549
--- Comment #2 from LoneVVolf ---
After seeing marek reply I experimented a bit with PP_DEBUG and post processing
filters.
Half of the error messages comes from pp_jimenezmlaa filter , the other half
from pp_jimenezmlaa_color .
disabling those f
On Tue, 31 Jan 2017, Thierry Reding wrote:
> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> I would love for drm-panel to be moved under -misc.
>
> Like that's going to magically motivate people to spend their time
> reviewing other patches. The only thing that group maintainershi
Hi Dave, here's Maarten's backport of the vma fixes for v4.10.
BR,
Jani.
The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637:
Linux 4.10-rc6 (2017-01-29 14:25:17 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-intel
tags/topic/
Gabriel Krisman Bertazi writes:
> Scheduling the output_poll_work before calling bind_all to create the
> crtcs can race the fbdev initialization with the components
> initialization (i.e. crtc initialization). One side effect is that we
> may call drm_fbdev_cma_init with a zeroed num_crtc value
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #11 from Alex Deucher ---
(In reply to fin4478 from comment #8)
> Alex, thanks for the new firmware. Still Bios recognition errors at boot,
> but otherwise ok.
>
> [3.461112] [drm] BIOS signature incorrect 20 7
> [3.461117] a
On Wed, Jan 04, 2017 at 08:42:29PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_fill_fb_info() should pass the correct plane index to
> _intel_compute_tile_offset() once we start to care about the AUX
> surface.
>
> Signed-off-by: Ville Syrjälä
This changes how x
https://bugs.freedesktop.org/show_bug.cgi?id=99549
--- Comment #3 from Marek Olšák ---
That's up to you. I'm not so into fixing the postprocessing, because the
options shouldn't be put into drirc, because the filters change what the OpenGL
spec specifies.
--
You are receiving this mail because:
On Wed, Jan 04, 2017 at 08:42:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DRM_UT_CORE generates way too much noise usually, so having the
> framebuffer init failures use DRM_UT_CORE is a pain when trying to
> find out the reason why you failed in creating a framebuf
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to
Hi,
I'm currently trying to mmap the memory of an OpenGL texture I've
created by
doing the following:
std::vector image_attribs = {
EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
EGL_DRM_BUFFE
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #20 from Alex Deucher ---
(In reply to Jean-François Fortin Tam from comment #19)
> What would be the equivalent in the systemd/journalctl world? Apparently
> Fedora 25 doesn't generate Xorg.log files anymore, the last modification
>
On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
> Hi,
>
> I'm currently trying to mmap the memory of an OpenGL texture I've created by
> doing the following:
>
> std::vector image_attribs = {
> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
> EGL_
On Thu, Feb 02, 2017 at 05:30:34PM +0200, Jani Nikula wrote:
> On Tue, 31 Jan 2017, Thierry Reding wrote:
> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> >> I would love for drm-panel to be moved under -misc.
> >
> > Like that's going to magically motivate people to spend their
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch since the
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
wrote:
> This series is a folow-up on
> https://patchwork.kernel.org/patch/9501787/
>
> The first patch makes changes to atomic helpers to allow for drives with
> ASYNC flip support to use them.
> Patch 2 is to use this in AMDGPU/DC.
> Patch 3 is
Hi Dave,
Just a couple of small fixes for 4.10
The following changes since commit 52b679f60e2a68af88411f12318675a2424a0e14:
Merge tag 'drm-misc-fixes-2017-01-31' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-02-01 08:45:27
+1000)
are available in the git repository at:
Daniel Vetter writes:
> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
>> Jani Nikula writes:
>>
>> > On Tue, 31 Jan 2017, Eric Anholt wrote:
>> >> Martin Peres writes:
>> >>
>> >>> Despite all the careful planing of the kernel, a link may become
>> >>> insufficient to handle th
On Tue, Jan 31, 2017 at 01:05:20PM +0100, Andrzej Hajda wrote:
> On 31.01.2017 09:54, Thierry Reding wrote:
> > On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote:
> >>
> >> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
> >>> Dear Thierry,
> >>>
> >>> Could you please review this patch?
> >> Th
On Thu, Feb 02, 2017 at 10:58:43AM +0530, Sharma, Shashank wrote:
> Thanks for the review Thierry. My comments inline.
>
> Regards
> Shashank
> On 2/1/2017 9:40 PM, Thierry Reding wrote:
> > On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> > > This patch does following:
> > > - A
On Thu, Feb 02, 2017 at 02:26:40PM -0200, Gabriel Krisman Bertazi wrote:
> Instead of receiving the num_crts as a parameter, we can read it
> directly from the mode_config structure. I audited the drivers that
> invoke this helper and I believe all of them initialize the mode_config
> struct accor
On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima
wrote:
> - The image is displaced even when using the same timing values in
> the datasheet.
Managed to fix this framebuffer displacement problem. Will submit a patch soon.
___
dri-devel mailing list
d
On Thu, Feb 02, 2017 at 11:08:22AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:02 PM, Thierry Reding wrote:
> > On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> > > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> > > than 340
vmwgfx part: Reviewed-by: Sinclair Yeh
On Thu, Feb 02, 2017 at 11:44:33AM +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36aab92fa2091dd54ea983752aa40e427e83d113
commit: e4563f6ba71792c77aeccb2092cc23149b44e642 [1066/1073] drm: Rely on
mode_config data for fb_helper initialization
config: i386-randconfig-x007-201705 (attached as .config)
compiler: gcc
Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
disabled because it didn't update the prototype for drm_fb_helper_init
in that case.
Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initializati
On Thu, Feb 02, 2017 at 05:39:00PM -0200, Gabriel Krisman Bertazi wrote:
> Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
> initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
> disabled because it didn't update the prototype for drm_fb_helper_init
> in that case.
On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>> doing the following:
>>
>> std::vector image_attribs = {
>> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
>> EGL_H
I'm going to need to cool down for a bit. Let's resume this on Monday,
maybe we can get back to being constructive after the weekend.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://li
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #21 from Jean-François Fortin Tam ---
Created attachment 129304
--> https://bugs.freedesktop.org/attachment.cgi?id=129304&action=edit
journalctl output at the time of a deadlock on F25 - X GDM session output only
Hi Alex and thanks
https://bugs.freedesktop.org/show_bug.cgi?id=93341
Jean-François Fortin Tam changed:
What|Removed |Added
Attachment #128278|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #23 from Jean-François Fortin Tam ---
Created attachment 129306
--> https://bugs.freedesktop.org/attachment.cgi?id=129306&action=edit
Xorg log
Xorg.0.log file found in ~/.local/share/xorg as "Xorg.0.log.old"
As you can see it says
On Thu, Feb 02, 2017 at 06:04:00PM -0200, Breno Lima wrote:
> Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel, which can be supported by the simple panel driver.
>
> Data-sheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Signe
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 0f01216949002d20b9dc6d300c82df5ffa59e9a7
commit: e4563f6ba71792c77aeccb2092cc23149b44e642 [1076/1086] drm: Rely on
mode_config data for fb_helper initialization
config: i386-randconfig-x0-02030244 (attached as .config)
compi
On Thu, Feb 2, 2017 at 8:46 PM, Volker Vogelhuber
wrote:
> On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>>> doing the following:
>>>
>>> std::vector image_attribs = {
>>> EGL_WIDTH,
On Thu, Jan 26, 2017 at 05:03:54PM -0500, Rob Clark wrote:
> On Thu, Jan 26, 2017 at 4:09 PM, Rob Herring wrote:
> > On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote:
> >> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote:
> >>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote:
> So, cle
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
Hi Thierry,
On Thu, Feb 2, 2017 at 6:18 PM, Thierry Reding wrote:
> Shawn, Fabio, anyone want to give this a Tested-by? I take it that this,
> in combination with Fabio's patch to fix the displacement would make the
> SabreSD display work properly?
Yes, that is correct. It also needs the other
From: Fabio Estevam
Currently the framebuffer content is displayed with incorrect offsets
in both the vertical and horizontal directions.
The fbdev version of the driver does not show this problem. Breno Lima
dumped the eLCDIF controller registers on both the drm and fbdev drivers
and noticed th
Allows using atomic flip helpers for drivers
using ASYNC flip.
Remove ASYNC_FLIP restriction in helpers and
caches the page flip flags in drm_crtc_state
to be used in the low level drivers.
v2:
Resending the patch since the original was broken.
v3:
Save flag in crtc_state instead of plane_state
v2:
Update code after flip_flags moved from plane_state
to crtc_state
v5:
Rename to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/nouveau/nv50_display.c | 84 --
1 file changed, 10 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/dr
This series is a folow-up on
https://patchwork.kernel.org/patch/9501787/
The first patch makes changes to atomic helpers to allow for drives with ASYNC
flip support to use them.
Patch 2 is to use this in AMDGPU/DC.
Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the
hel
v2:
Modify for movig pflip flags to crtc_state
v4:
Fix identation.
v5:
Rename field to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 +
2 files change
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #12 from Steven A. Falco ---
Created attachment 253891
--> https://bugzilla.kernel.org/attachment.cgi?id=253891&action=edit
New dmesg file
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #14 from Steven A. Falco ---
One other error message I just noticed:
[5.538117] amdgpu: [powerplay] Can't find requested voltage id in
vdd_dep_on_sclk table!
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=193651
--- Comment #13 from Steven A. Falco ---
I successfully built a custom kernel. It appears to be working well. Thanks
for the help!
I included a new dmesg.log file because I still see messages like:
[9.719278] amdgpu: [powerplay]
Introduced in 028715ee
Move the dereference after the null check.
---
intel/intel_decode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 803d202..2721ffd 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3899
Hi Linus,
Another fixes pull for v4.10, it's a bit big due to the backport of the
VMA fixes for i915 that should fix the oops on shutdown problems that you've
worked around.
There are also two drm core connector registration fixes, a bunch of nouveau
regression fixes and two AMD fixes.
Dave.
Th
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric Anholt wrote:
Martin Peres writes:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set
1 - 100 of 123 matches
Mail list logo
