https://bugs.freedesktop.org/show_bug.cgi?id=107377
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from Lakshmi ---
Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit :
> https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2
-> Forbidden
You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this
server.
> PGP:
Hi Linus,
Just a couple of fixes PRs for rc1,
One MAINTAINERS address change, two panels fixes, and set of amdgpu
fixes (build fixes, display fixes and some others).
Thanks
Dave.
drm-next-2018-08-24:
amdgpu and panel/misc fixes.
The following changes since commit
https://bugs.freedesktop.org/show_bug.cgi?id=107627
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107668
--- Comment #1 from Naheem Zaffar ---
Created attachment 141266
--> https://bugs.freedesktop.org/attachment.cgi?id=141266=edit
Dmesg output with amdgpu.dc=0
Taken when booting with Vanilla Mainline kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107668
Bug ID: 107668
Summary: Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd
Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
Product: DRI
Version: XOrg git
Hardware:
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #8 from Christopher ---
Created attachment 141264
--> https://bugs.freedesktop.org/attachment.cgi?id=141264=edit
dmsg output running on xorg
--
You are receiving this mail because:
You are the assignee for the
On 08/23/2018 01:47 AM, Christian König wrote:
Am 22.08.2018 um 22:57 schrieb Jiandi An:
On 08/22/2018 02:09 PM, Christian König wrote:
Am 22.08.2018 um 20:57 schrieb Jiandi An:
Framebuffer memory needs to be accessed decrypted. Ensure the
memory encryption mask is not set for the ttm
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #7 from Christopher ---
Hello,
I am getting similar issues with regards to fence wait timeouts. However I
have narrowed it further to it ONLY happening when gnome is running on xorg.
I have over the past month or so rebuilt my
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #6 from Christopher ---
Created attachment 141263
--> https://bugs.freedesktop.org/attachment.cgi?id=141263=edit
dmsg output running on wayland
--
You are receiving this mail because:
You are the assignee for the
Benjamin Gaignard (2):
tests/modetest: Add atomic support
tests/util: Add support for stm module
Christian König (7):
amdgpu: stop using the hash table for fd_tab
amdgpu: add handle table implementation v2
amdgpu: use handle table for KMS handles
amdgpu: use
It looks like that when we moved over to using
drm_connector_for_each_possible_encoder() in nouveau, that one rather
important part of this function got dropped by accident:
/* Right v here */
for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
https://bugs.freedesktop.org/show_bug.cgi?id=105046
--- Comment #17 from Michael Zapf ---
Just installed openSUSE with kernel 4.18; the issue seems to be fixed! Let me
check with my office PC (in about a week) before declaring it resolved.
--
You are receiving this mail because:
You are the
On Sun, 19 Aug 2018, Ville Syrjälä wrote:
> On Fri, Aug 17, 2018 at 03:19:37PM -0400, Mikulas Patocka wrote:
> > On Sun Ultra 5, it happens that the dot clock is not set up properly for
> > some videomodes. For example, if we set the videomode "r1024x768x60" in
> > the firmware, Linux would
On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart
wrote:
> On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote:
>> On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote:
>> > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote:
>> >> Possibly slightly out of topic, but we're
Hi Dave,
One more patch snuck in between my PR and today.
drm-misc-next-fixes-2018-08-23-1:
- Add quirk to Lenovo B50-80 to use 6 bpc instead of 8 (Feng)
Cc: Kai-Heng Feng
Cheers, Sean
The following changes since commit 4acd8d01a2393f2145ad1db10b2d5c764582a98d:
MAINTAINERS: drm-misc:
Hi John,
On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote:
> On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote:
> > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote:
> >> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote:
> >>> On Mon, Aug 20, 2018 at
https://bugs.freedesktop.org/show_bug.cgi?id=107666
Bug ID: 107666
Summary: st_sampler_view.c:546 assert
Product: Mesa
Version: 18.2
Hardware: Other
OS: All
Status: NEW
Severity: normal
Thanks for the review.
And yes it just removes the bitfields in PPS since the packing of the
bitfields and memory allocations are heavily dependent on HW.
So we cant have them in DRM level.
I will make sure to add this in version history and also add
Suggested-by: jani.nik...@linux.intel.com
On Fri, Aug 17, 2018 at 12:31:51PM -0700, Srivatsa, Anusha wrote:
> This patch needs to now incorporate the newly added slice_row_per_frame
> parameter in PPS_16.
Nope, the slice_row_per_frame and slice_per_line are only required to configure
PPS
on the source side. They are not DSC spec
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
>
> v4 (From Manasi)
> * Add the DSC_MUX_WORD_SIZE constants (Manasi)
>
> v3 (From Manasi)
> * Remove the
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> According to Display Stream compression spec 1.2, the picture
> parameter set metadata is sent from source to sink device
> using the DP Secondary data packet. An infoframe is formed
> for the PPS SDP header and PPS SDP payload bytes.
> This patch
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #29 from Andrey Grodzovsky ---
(In reply to Jan Jurzitza from comment #28)
> (In reply to Andrey Grodzovsky from comment #25)
>
> Still same issue happening here on both projects built from git. One issue
> here which doesn't seem
https://bugs.freedesktop.org/show_bug.cgi?id=104284
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #18 from Lakshmi ---
No
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #28 from Jan Jurzitza ---
(In reply to Andrey Grodzovsky from comment #25)
Still same issue happening here on both projects built from git. One issue here
which doesn't seem completely related:
Aug 23 20:41:20 archlinux kernel:
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #18 from madc...@atlas.cz ---
Created attachment 141261
--> https://bugs.freedesktop.org/attachment.cgi?id=141261=edit
dmesg log of the crash in Unigine Superposition
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #17 from madc...@atlas.cz ---
I just ran a few tests with git/svn versions of LLVM 8.0 and mesa 18.3 and the
problem is still there. I attached a dmesg log of the crash in Unigine
Superposition. Just FTR the crash with LLVM 8.0/mesa
On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
>
> Signed-off-by: Hans Verkuil
> Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
>
On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote:
>
> yeah, that's the clear way to fix this imo. We only depend on guest
> life cycle to access guest memory properly. Here's proposed fix, will
> verify and integrate it later.
Thanks, this looks sane to me,
Linus
On Thu, Aug 23, 2018 at 08:25:46PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > > On Wed, Aug
On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote:
> On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote:
>> Hi John,
>>
>> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote:
>> > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
>> > > Hey Noralf, all,
>> > >
>> > >
On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > The previous patch added tile_w and tile_h, which represent the
> > horizontal and vertical sizes of a tile.
> >
> > This one uses that to plumb through drm
On Thu, Aug 23, 2018 at 10:24 AM, Ville Syrjälä
wrote:
> On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote:
>> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
>> > Hey Noralf, all,
>> > I've been digging for a bit on the regression that this patch has
>> > tripped on the HiKey
On Thu, Aug 23, 2018 at 12:46 AM, Laurent Pinchart
wrote:
> Hi John,
>
> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote:
>> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
>> > Hey Noralf, all,
>> >
>> > I've been digging for a bit on the regression that this patch has
>> >
>>
Currently, vkms needs VBlank to work well. This patch adds another
operation model that make vkms works without VBlank support. In this
scenario, vblank signaling is faked by calling drm_send_vblank_event()
in vkms_crtc_atomic_flush(); this approach works due to the
drm_vblank_get() == 0
[Changing subject/recipients, to avoid hijacking the thread]
Hi Dan,
On Wed, 22 Aug 2018 at 17:29, Daniel Stone wrote:
>
> Hi,
>
> On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote:
> > On 22 August 2018 at 12:44, Daniel Vetter wrote:
> > > I think it's time to brainstorm a bit about the
On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > > wrote:
> > > > On
On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote:
> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
> > Hey Noralf, all,
> > I've been digging for a bit on the regression that this patch has
> > tripped on the HiKey board as reported here:
> > https://lkml.org/lkml/2018/8/16/81
On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > wrote:
> > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > >> On Wed, Aug 22,
On Thu, Aug 23, 2018 at 6:49 PM, Noralf Trønnes wrote:
>
> Den 23.08.2018 09.37, skrev Daniel Vetter:
>>
>> On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote:
>>>
>>> On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz
On 06/05/2018 11:25 PM, Sergei Shtylyov wrote:
> Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git'
> repo.
> The purpose of these patches is to add the R-Car V3H (R8A77980) support to the
> R-Car LVDS driver.
>
> [1/2] dt-bindings: display: renesas: lvds: document
Den 23.08.2018 09.37, skrev Daniel Vetter:
On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote:
On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote:
On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
Hey Noralf, all,
I've
As for today etnaviv device doesn't setup dma_mask.
The etnaviv device is a virtual device not represented in DT
so missing dma_mask isn't setup by generic plaform code
(by of_dma_configure function).
Missing dma_mask causes fails in some dma cache ops functions.
For example it causes fails on
On Thu, 2018-08-23 at 14:00 +0200, Karol Herbst wrote:
> Patches 1-5 are Reviewed-by: Karol Herbst
>
> I think it might be worth to test those patches on a system without
> any backlight devices just to verify we don't break things, but the
> code looked good already, so maybe we don't really
On Thu, Aug 23, 2018 at 02:48:31PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to
On Thu, Aug 23, 2018 at 02:48:30PM +0530, Sharat Masetty wrote:
> devfreq framework requires the drivers to provide busy time estimations.
It would help if you added an article to this sentence, i.e: "The devfreq
framework..."
> The GPU driver relies on the hardware performance counteres for
On Thu, Aug 23, 2018 at 02:48:29PM +0530, Sharat Masetty wrote:
> Add a simple function to read 64 registers in the GMU domain
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git
On Thu, Aug 23, 2018 at 02:48:28PM +0530, Sharat Masetty wrote:
> Call the devfreq_remove_device() API to remove the GPU devfreq instance
> during GPU driver cleanup.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff
Hi Alex,
On Thu, Aug 23, 2018 at 04:11:17PM +0100, Alexandru Gheorghe wrote:
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problems is that drm_crtc_state has a bool field called
On Wed, Aug 22, 2018 at 04:18:19PM +0100, Alexandru Gheorghe wrote:
> When we want to writeback to memory in NV12 format we need to program
> the RGB2YUV coefficients. Currently, we don't program the coefficients
> and NV12 doesn't work at all.
>
> This patchset fixes that by programming a sane
Hi Matthew,
On Thu, Aug 23, 2018 at 07:34:45AM -0700, Matthew Wilcox wrote:
On Wed, Aug 22, 2018 at 04:57:33PM +0100, Brian Starkey wrote:
On Wed, Aug 22, 2018 at 05:11:55PM +0200, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 4:59 PM, Eric Engestrom
> wrote:
> > On Tuesday, 2018-08-21
On Thu, Aug 23, 2018 at 02:48:27PM +0530, Sharat Masetty wrote:
> Devfreq turns on and starts recommending power level as soon as it is
> initialized. The GPU is still not powered on by the time the devfreq
> init happens and this leads to problems on GPU's where register access
> is needed to
On Thu, Aug 23, 2018 at 02:48:26PM +0530, Sharat Masetty wrote:
> This patch series starts off with a few bug fixes in devfreq code, followed by
> refactoring the devfreq code needed for supporting different chipsets, and
> ends with adding devfreq support for A6x.
Just an aside, I'm a sucker for
As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).
The AFBC modifiers can be found in [3].
AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or
AFBC is a flexible, proprietary, lossless compression protocol and
format, with a number of defined DRM format modifiers. To facilitate
consistency and compatibility between different AFBC producers and
consumers, document the expectations for usage of the AFBC DRM format
modifiers in a new .rst
Some formats have a non-integer number of bytes per pixel, which can't
be handled with the existing 'cpp' field in drm_format_info. To handle
these formats, add a 'bpp' field, which is only used if cpp[0] == 0.
This updates all the users of format->cpp in the core DRM code,
converting them to use
Hi,
This is the second round of RFC for adding a bunch of new YUV formats
for Mali/AFBC. I've included a proper AFBC documentation file too, for
posterity.
Some of the new formats don't have an integer number of
bytes-per-pixel, so I've added a bpp field to drm_format_info
(patch 1), keen to
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problems is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if
On Thursday, 2018-08-23 14:37:28 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Earlier commit reworked our sysfs handling to use realpath.
> Sadly that backfired since the Firefox sandboxing mechanism rejects
> that. Despite the files/folders being in the allowed list, of the
> sandboxing
On 2018-08-23 2:52 p.m., Emil Velikov wrote:
> On Thu, 23 Aug 2018 at 11:38, Michel Dänzer wrote:
>> On 2018-08-23 12:04 p.m., Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> Earlier commit reworked our sysfs handling to use realpath.
>>> Sadly that backfired since the Firefox sandboxing
On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> wrote:
> > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
> >> > On Wed,
On Tue, Aug 14, 2018 at 10:01:45AM -0400, Sean Paul wrote:
> On Tue, Aug 14, 2018 at 10:00:33AM -0400, Sean Paul wrote:
> > On Tue, Aug 14, 2018 at 04:59:31PM +0530, spa...@codeaurora.org wrote:
> > > On 2018-08-14 03:00, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > This patch adds a
https://bugs.freedesktop.org/show_bug.cgi?id=105913
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #2 from Lakshmi ---
On Thu, Aug 23, 2018 at 04:30:19PM +0800, Lowry Li wrote:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Adds a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to
Hi Heiko,
On 08/21/2018 04:05 PM, Heiko Stuebner wrote:
> The Rockchip DSI driver was separate till now, not using the common
> bridge driver that was introduced a bit later. So this series migrates
> over to use that common bridge driver and then also adds support for
> dual-dsi to both the
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #10 from Michel Dänzer ---
Thanks for testing the patches. Looks like there's still an issue with DC.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi, Colin
I has posted the same patch about a month ago. but it seems to be ignored.:-(
https://lore.kernel.org/patchwork/patch/971652/
Thanks,
zhong jiang
On 2018/8/21 18:54, Colin King wrote:
> From: Colin Ian King
>
> Array vexpress_muxfpga_match is missing an end of array sentinel,
> add
Ping, Anyone has any objections a about the patch?
Best wishes,
zhong jiang
On 2018/8/17 10:24, zhong jiang wrote:
> for_each_available_child_of_node will get and put the node properly,
> the following of_node_put will lead to the double put. So just
> remove it.
>
> Signed-off-by: zhong jiang
From: Emil Velikov
Earlier commit reworked our sysfs handling to use realpath.
Sadly that backfired since the Firefox sandboxing mechanism rejects
that. Despite the files/folders being in the allowed list, of the
sandboxing mechanism.
Oddly enough, the Chromium sandboxing doesn't complain about
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #9 from Przemek ---
Created attachment 141248
--> https://bugs.freedesktop.org/attachment.cgi?id=141248=edit
pstore kernel oops message with applied patches
(In reply to Przemek from comment #7)
> Repo is git fetched to the
On Thu, 23 Aug 2018 at 11:38, Michel Dänzer wrote:
>
> On 2018-08-23 12:04 p.m., Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Earlier commit reworked our sysfs handling to use realpath.
> > Sadly that backfired since the Firefox sandboxing mechanism rejects
> > that. Despite the
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #8 from Przemek ---
compiling with gcc 8.2.0-r2.
--
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=107595
--- Comment #7 from Przemek ---
The patches (all three) applies fine, but I cannot compile kernel due to:
"drivers/gpu/drm/amd/amdgpu/kv_dpm.c: In function ‘kv_dpm_process_interrupt’:
drivers/gpu/drm/amd/amdgpu/kv_dpm.c:3210:24: error:
Patches 1-5 are Reviewed-by: Karol Herbst
I think it might be worth to test those patches on a system without
any backlight devices just to verify we don't break things, but the
code looked good already, so maybe we don't really need to test.
On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
Hi Linus,
Please pull fbdev changes for v4.19. There are mostly small fixes and
cleanups for fb drivers (the biggest updates are for udlfb and pxafb
drivers). This PR also adds deferred console takeover support to the
console code and efifb driver. Please see the signed tag description
for
Am 23.08.2018 um 11:58 schrieb zhoucm1:
On 2018年08月23日 17:15, Christian König wrote:
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an
integer payload
identifying a point in a timeline. Such timeline
On Tue, Aug 21, 2018 at 12:54 PM Colin King wrote:
> From: Colin Ian King
>
> Array vexpress_muxfpga_match is missing an end of array sentinel,
> add it.
>
> Detected by Coccinelle: ("vexpress_muxfpga_match is not NULL
> terminated at line")
>
> Fixes: ca454bd42dc2 ("drm/pl111: Support the
https://bugs.freedesktop.org/show_bug.cgi?id=107595
--- Comment #6 from Michel Dänzer ---
Does https://patchwork.freedesktop.org/series/48613/ (in particular the first
patch) help?
--
You are receiving this mail because:
You are the assignee for the
On 2018-08-23 12:04 p.m., Emil Velikov wrote:
> From: Emil Velikov
>
> Earlier commit reworked our sysfs handling to use realpath.
> Sadly that backfired since the Firefox sandboxing mechanism rejects
> that. Despite the files/folders being in the allowed list, of the
> sandboxing mechanism.
From: Emil Velikov
Earlier commit reworked our sysfs handling to use realpath.
Sadly that backfired since the Firefox sandboxing mechanism rejects
that. Despite the files/folders being in the allowed list, of the
sandboxing mechanism.
Oddly enough, the Chromium sandboxing doesn't complain about
On 2018年08月23日 17:15, Christian König wrote:
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer
payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
On 22.08.2018 04:59, Inki Dae wrote:
>
> 2018년 08월 21일 20:21에 Andrzej Hajda 이(가) 쓴 글:
>> On 21.08.2018 07:27, Inki Dae wrote:
>>> 2018년 08월 20일 18:00에 Andrzej Hajda 이(가) 쓴 글:
On 17.08.2018 03:56, Inki Dae wrote:
> 2018년 08월 13일 20:17에 Andrzej Hajda 이(가) 쓴 글:
>> On 07.08.2018 10:53,
On 2018年08月23日 17:08, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 04:25:42PM +0800, Chunming Zhou wrote:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer payload
identifying a point in a timeline. Such timeline semaphores support the
following
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if needed.
The driver code then tries to set this new frequency on the GPU by
sending an Out Of Band(OOB) request.
Devfreq turns on and starts recommending power level as soon as it is
initialized. The GPU is still not powered on by the time the devfreq
init happens and this leads to problems on GPU's where register access
is needed to get/set power levels. So we start suspended and only restart
devfreq when
Add a simple function to read 64 registers in the GMU domain
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index
devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counteres for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
Call the devfreq_remove_device() API to remove the GPU devfreq instance
during GPU driver cleanup.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index
This patch series starts off with a few bug fixes in devfreq code, followed by
refactoring the devfreq code needed for supporting different chipsets, and
ends with adding devfreq support for A6x.
Sharat Masetty (5):
drm/msm: suspend devfreq on init
drm/msm: unregister devfreq upon clean up
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an integer payload
identifying a point in a timeline. Such timeline semaphores support the
following operations:
* Host query - A host operation that allows
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
stub fence will be used by timeline syncobj as well.
Mhm, I'm leaning a bit towards renaming it but "null" fence or "stub"
fence doesn't make a large difference to me.
Point is that it is a fence which is always signaled right from the
On Thu, Aug 23, 2018 at 04:25:42PM +0800, Chunming Zhou wrote:
> VK_KHR_timeline_semaphore:
> This extension introduces a new type of semaphore that has an integer payload
> identifying a point in a timeline. Such timeline semaphores support the
> following operations:
>* Host query - A host
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
we can place a fence to a timeline point after expanded.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 16 +---
On Thu, Aug 23, 2018 at 11:02 AM, Christian König
wrote:
> Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
>>
>> That is certainly totally nonsense. dma_fence_enable_sw_signaling()
>> is the function who is calling this callback.
>>
>> Signed-off-by: Chunming Zhou
>> Cc: Jason Ekstrand
>
>
> For
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
we can fetch timeline point fence after expanded.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 6 --
drivers/gpu/drm/v3d/v3d_gem.c | 4 ++--
Am 23.08.2018 um 10:25 schrieb Chunming Zhou:
That is certainly totally nonsense. dma_fence_enable_sw_signaling()
is the function who is calling this callback.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
For this one: Reviewed-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c |
Am Freitag, den 17.08.2018, 08:42 +0200 schrieb Christoph Hellwig:
> On Tue, Aug 14, 2018 at 05:12:25PM +0300, Eugeniy Paltsev wrote:
> > Hi Lucas, Christoph,
> >
> > After switching ARC to generic dma_noncoherent cache ops
> > etnaviv driver start failing on dma maping functions because of
> >
On 23/08/2018 08:07, Zhenyu Wang wrote:
> On 2018.08.22 20:20:46 +0200, Paolo Bonzini wrote:
>> On 22/08/2018 18:44, Linus Torvalds wrote:
>>> An example of something that *isn't* right, is the i915 kvm interface,
>>> which does
>>>
>>> use_mm(kvm->mm);
>>>
>>> on an mm that was
Hi,
This serie aims at adding the support for pixel blend modes represent the
alpha blending equation selection in the driver. It also introduces to use
it in the malidp driver.
Let me know what you think,
Lowry
Changes for v5:
- Adds comments in drm_blend.h.
- Removes setting default value
1 - 100 of 135 matches
Mail list logo
