Emil Velikov wrote:
> FTR, only the installed headers (~50) need the extern C guard.
> None of that is not a blocker for this patch, so I've just pushed it to
> master.
Thanks Emil. I'll see what I can do about the other ones.
- Tobias
> Thanks!
> Emil
>
__
https://bugs.freedesktop.org/show_bug.cgi?id=100593
--- Comment #4 from Gašper Sedej ---
Hi. I also found some "shader color corruptions" on r9 270.
I am using ubuntu 16.04 + kernel 4.11 + oibaf-ppa
Having issues with unigine (valley/heaven), The long dark and compiz window
shadow.
Screenshots
/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick
(https://www.imagemagick.org)
arch/x86/inclu
Thierry/Rob,
On Tue, Feb 7, 2017 at 10:48 PM, Fabio Estevam wrote:
> On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote:
>
>> Except I have no way of knowing whether: a) you omitted a supply
>> because you don't (yet) care, b) the panel has a single supply and you
>> are using power-supply or c)
On 5 April 2017 at 17:23, Tobias Jakobi wrote:
> Hello Eric,
>
>
> Eric Engestrom wrote:
>> On Wednesday, 2017-04-05 16:22:24 +0200, Tobias Jakobi wrote:
>>> Add the usual extern "C" when compiling in C++ mode.
>>
>> Thanks, but why specifically this header? The other exynos/*.h headers
>> also la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marek Olšák (1):
configure.ac: bump version for release
Samuel Pitoiset (1):
amdgpu: allow to query GPU sensor related information
git tag: libdrm-2.4.79
https://dri.freedesktop.org/libdrm/libdrm-2.4.79.tar.bz2
MD5: 84ba6e8e6c97d268493
On 7 April 2017 at 13:06, Philipp Zabel wrote:
> Import the etnaviv header changes from kernel commits 9ad59fea162c
> ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
> ("drm/etnaviv: submit support for out-fences") for fence fd support.
>
> The drm_etnaviv_gem_submit structure was e
https://bugs.freedesktop.org/show_bug.cgi?id=92432
Chris Wilson changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
On 7 April 2017 at 13:06, Philipp Zabel wrote:
> Add etna_cmd_stream_flush2 with in-fence fd and out-fence fd support for
> explicit fencing.
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Eric Engestrom
> Reviewed-by: Christian Gmeiner
> ---
> v2: renamed etna_cmd_stream_flush_explicit to etn
/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick
(https://www.imagemagick.org)
arch/x86/inclu
Hi Laura,
Couple of trivial nitpicks below.
On 3 April 2017 at 19:57, Laura Abbott wrote:
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -1,5 +1,5 @@
> /*
> - * drivers/staging/android/ion/ion.h
> + * drivers/staging/android/ion/ion_priv.h
Does not mat
On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
> Am 08.04.2017 um 18:26 schrieb Chris Wilson:
> >Reserve 0 for general use a token meaning that the fence doesn't belong
> >to an ordered timeline (fence context).
>
> NAK, we kept context allocation cheap to avoid exactly that.
Ho
Am 08.04.2017 um 18:26 schrieb Chris Wilson:
Reserve 0 for general use a token meaning that the fence doesn't belong
to an ordered timeline (fence context).
NAK, we kept context allocation cheap to avoid exactly that.
Please elaborate further why it should be necessary now.
Regards,
Christian
Hi Shashank,
On 7 April 2017 at 17:39, Shashank Sharma wrote:
> + u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;
>
> for (i = 0; i < len; i++) {
> struct drm_display_mode *mode;
> mode = drm_display_mode_from_vic_index(connecto
https://bugzilla.kernel.org/show_bug.cgi?id=195295
Eugene Shalygin (eugene.shaly...@gmail.com) changed:
What|Removed |Added
Regression|No |Yes
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=195295
Bug ID: 195295
Summary: USB device insertion turns on discrete Radeon GPU
Product: Drivers
Version: 2.5
Kernel Version: 4.10.8
Hardware: x86-64
OS: Linux
Tree
drm-tip/drm-tip boot: 112 boots: 4 failed, 107 passed with 1 offline
(v4.11-rc5-1802-g102e51aa6d5b)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g102e51aa6d5b/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
https://bugs.freedesktop.org/show_bug.cgi?id=71789
--- Comment #37 from Marek Olšák ---
You can try "git am -3 ...". If that doesn't help, then I don't know.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
On Sat, Apr 8, 2017 at 7:41 AM, Ong, Hean Loong
wrote:
> Hi Daniel
>
> Thanks for the time and patience for reviewing my changes. I would ensure
> that subsequent patches will not have the same mail problems.
>
> I have some question on the validation methods. Since my drivers are
> processing t
Reserve 0 for general use a token meaning that the fence doesn't belong
to an ordered timeline (fence context).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Joonas Lahtinen
Cc: "Christian König"
Cc: Alex Deucher
---
drivers/dma-buf/dma-fence.c | 4 +++-
include/linux
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ur
2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special context (0 / DMA_FENCE_NO_CONTEXT) to
mean unordered.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc:
2017-03-29 20:55 GMT+09:00 Tobias Jakobi :
> Hello Daniel,
>
> I'm not getting any response from the Exynos DRM maintainer concerning
> this patch. Since this is just a simple cleanup, and Andrzej has already
> review, could you perhaps merge it through drm-misc?
>
Sorry for late. Confirmed just n
2017-03-29 20:56 GMT+09:00 Tobias Jakobi :
> Hello Daniel,
>
> same question here. Patch doesn't introduce any functional changes (just
> adds code documentation), so can you merge it through drm-misc?
>
Sorry for late. Confirmed just now. I will check it on next Monday.
Thanks,
Inki Dae
> With
2017-04-07 20:40 GMT+09:00 Tobias Jakobi :
> Hello Inki,
>
>
> Inki Dae wrote:
>> Hello Tobias,
>>
>>
>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:
This patch removes unnecessary descriptions on
exynos_drm_crtc structure and adds one descripti
/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick
(https://www.imagemagick.org)
arch/x86/inclu
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings
(v4.11-rc5-1802-g102e51aa6d5b)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g102e51aa6d5b/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1802-g102e51aa6d5b
Git Commit: 10
https://bugs.freedesktop.org/show_bug.cgi?id=71789
--- Comment #36 from richard ---
wheezy only have mesa 8 available, but videoplayback would be very nice please.
don't know how to change colour depth as there is no xorg.conf.
thank you very much
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=71789
--- Comment #35 from richard ---
Hello ,
how can i apply this patch?
I am using Powermac G5 7,3 with Radeon9650, Debian Wheezy, kernel 3.2.6
it gives
dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode'
[1.137001] radeonfb: Found O
On 04/08/2017 12:11 PM, Hans Verkuil wrote:
> Hi Tomi,
>
> On 05/10/2016 01:36 PM, Tomi Valkeinen wrote:
>> Hi Hans,
>>
>> On 29/04/16 12:39, Hans Verkuil wrote:
>>> From: Hans Verkuil
>>>
>>> As long as there is a valid physical address in the EDID and the omap
>>> CEC support is enabled, then w
On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
> Hi,
>
> This is v3 of the series to do some serious Ion cleanup in preparation for
> moving out of staging. I didn't hear much on v2 so I'm going to assume
> people are okay with the series as is. I know there were still some open
> q
https://bugs.freedesktop.org/show_bug.cgi?id=100618
at...@t-online.de changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=100618
at...@t-online.de changed:
What|Removed |Added
Summary|Dead Island |Dead Island crash after
https://bugs.freedesktop.org/show_bug.cgi?id=100618
Bug ID: 100618
Summary: Dead Island
Product: Mesa
Version: 17.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority:
Hi Tomi,
On 05/10/2016 01:36 PM, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 29/04/16 12:39, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> As long as there is a valid physical address in the EDID and the omap
>> CEC support is enabled, then we keep ls_oe_gpio on to ensure the CEC
>> signal is pass
https://bugs.freedesktop.org/show_bug.cgi?id=100593
tarp...@gmx.de changed:
What|Removed |Added
Attachment #130714|0 |1
is obsolete|
Hey,
Op 07-04-17 om 17:56 schreef Tony Lindgren:
> Hi,
>
> Looks like current next now oopses at least for omapdrm
> when starting X. Reverting commit d20afeb3e2f9 ("Merge
> remote-tracking branch 'drm-misc/for-linux-next'") makes
> things work again.
>
> Any ideas what might be causing the oops b
37 matches
Mail list logo
