On 8 December 2016 at 12:02, Harry Wentland wrote:
> We propose to use the Display Core (DC) driver for display support on
> AMD's upcoming GPU (referred to by uGPU in the rest of the doc). In order to
> avoid a flag day the plan is to only support uGPU initially and transition
> to older ASICs gr
the DC code?
Can you show me you understand that upstream code is no longer 100% in
your control and things can happen to it that you might not expect and
you need to deal with it?
Dave.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/2a86bb11/attachment.html>
ll there be some CI infrastructure used to maintain and to
watch for Linux code that breaks assumptions in the DC code?
Can you show me you understand that upstream code is no longer 100% in
your control and things can happen to it that you might not expect and
you need to deal with it?
Dave.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/e22b9f1e/attachment-0001.html>
h your internally developed stuff?
If the code is upstream will it be tested in the kernel by some QA
group, or will there be some CI infrastructure used to maintain and to
watch for Linux code that breaks assumptions in the DC code?
Can you show me you understand that upstream code is no longer 100% in
your control and things can happen to it that you might not expect and
you need to deal with it?
Dave.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/24f7d0f8/attachment.html>
>
>>This code needs rewriting, not cleaning, not polishing, it needs to be
>>split into its constituent parts, and reintegrated in a form more
>>Linux process friendly.
>
>
> Can we say "restructuring" just for consistency with Daniel's message (the
> HW-dependent bits don't need to be rewritten bu
On Sun, Dec 11, 2016 at 04:05:21PM -0500, Alex Deucher wrote:
> On Sun, Dec 11, 2016 at 12:12 PM, Chris Wilson
> wrote:
> > On Tue, Nov 15, 2016 at 10:43:34PM +0100, Daniel Vetter wrote:
> >> On Tue, Nov 15, 2016 at 03:46:42PM +, Chris Wilson wrote:
> >> > Joonas complained that writing ww_mu
On Mon, Dec 12, 2016 at 12:57:40PM +1000, Dave Airlie wrote:
> 4) Why can't we put this in staging?
> People have also mentioned staging, Daniel has called it a dead end,
> I'd have considered staging for this code base, and I still might.
> However staging has rules, and the main one is code in st
On Wed, Dec 07, 2016 at 09:02:13PM -0500, Harry Wentland wrote:
> Current version of DC:
>
> *
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display?h=amd-staging-4.7
>
> Once Alex pulls in the latest patches:
>
> *
> https://cgit.freedesktop.org/~agd5f/linux/tree/driv
mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/405626a3/attachment.html>
On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
> From: Swati Dhingra
>
> Currently, we don't have a stable ABI which can be used for the purpose of
> providing output debug/loggging/crc and other such data from DRM.
> The ABI in current use (filesystems, ioctls, et al.) have their own
>
Hi,
On 11/29/2016 10:34 AM, John Stultz wrote:
> Wanted to send out v2 of this patch set improving the EDID
> probing on the adv7511 used on HiKey.
>
> The first three patches are fixups that are hopefully straight
> forward, integrating feedback I got from Laurant.
>
> One of the previous patches
Op 09-12-16 om 21:59 schreef Daniel Vetter:
> On Fri, Dec 09, 2016 at 03:19:44PM +0100, Daniel Vetter wrote:
>> This was somehow lost between v3 and the merged version in Maarten's
>> patch merged as:
>>
>> commit f2d580b9a8149735cbc4b59c4a8df60173658140
>> Author: Maarten Lankhorst
>> Date: Wed
On Mon, Dec 12, 2016 at 09:46:59AM +0100, Maarten Lankhorst wrote:
> Op 09-12-16 om 21:59 schreef Daniel Vetter:
> > On Fri, Dec 09, 2016 at 03:19:44PM +0100, Daniel Vetter wrote:
> >> This was somehow lost between v3 and the merged version in Maarten's
> >> patch merged as:
> >>
> >> commit f2d580
On Sun, Dec 11, 2016 at 07:53:42PM +, Chris Wilson wrote:
> On Sun, Dec 11, 2016 at 08:20:19PM +0100, Daniel Vetter wrote:
> > Looping twice when we can do it once is silly. Also use a consistent
> > style. Note that there's a good race with the connector list walking,
> > since that is no long
Hi Wladimir,
Am Samstag, den 10.12.2016, 18:05 +0100 schrieb Wladimir J. van der
Laan:
> > So the MMU fault is somehow specific to what I'm doing. Interesting.
>
> I think I found the issue: the MMU "flush and sync" is not good enough in some
> cases.
>
> What the Vivante kernel driver does, for
On Mon, Dec 12, 2016 at 07:54:54AM +, Bridgman, John wrote:
> Yep, good point. We have tended to stay a bit behind bleeding edge because
> our primary tasks so far have been:
>
>
> 1. Support enterprise distros (with old kernels) via the hybrid driver
> (AMDGPU-PRO), where the closer to upst
On Mon, Dec 12, 2016 at 10:27:27AM +0100, Daniel Vetter wrote:
> On Mon, Dec 12, 2016 at 07:54:54AM +, Bridgman, John wrote:
> > Yep, good point. We have tended to stay a bit behind bleeding edge because
> > our primary tasks so far have been:
> >
> >
> > 1. Support enterprise distros (with
On Sat, Dec 10, 2016 at 10:52:52PM +0100, Daniel Vetter wrote:
> No one looks at the major/minor versions except the unique/busid
> stuff. If we protect that with the master_mutex (since it also affects
> the unique of each master, oh well) we can mark these two IOCTL with
> DRM_UNLOCKED.
>
> Whil
On Sat, Dec 10, 2016 at 10:52:53PM +0100, Daniel Vetter wrote:
> It only updates per-file feature flags. And all the ioctl which change
> behaviour depending upon these flags (they're all kms features) do
> _not_ hold the BKL. Therefor this is pure cargo-cult and can be
> removed.
>
> Note that th
On Sat, Dec 10, 2016 at 10:52:54PM +0100, Daniel Vetter wrote:
> With the last round of changes all ioctls called by modern drivers now
> have their own locking. Everything else is only allowed for legacy
> drivers and hence the lack of locking doesn't matter.
>
> One exception is nouveau, due to
On Mon, 12 Dec 2016 10:38:45 +0100,
Arnaud Pouliquen wrote:
>
>
>
> On 12/11/2016 07:09 AM, Takashi Sakamoto wrote:
> > On Dec 9 2016 01:37, Arnaud Pouliquen wrote:
> >> Add user interface to provide channel mapping.
> >> In a first step this control is read only.
> >>
> >> As TLV type, the cont
> The current etnaviv code gets around this stop->irq->start dance by
> spacing out the command streams, which seems to be enough to get around
> the FE MMU flush failure. This may not work correctly at the end of the
> address range. I'll take a look at this.
In my case it seems not a command bu
Hi Daniel,
On Tuesday 27 Sep 2016 23:05:20 Daniel Kurtz wrote:
> On Mon, Sep 19, 2016 at 8:27 PM, Laurent Pinchart wrote:
> > The vblank interrupt is disabled after one occurrence, preventing the
> > atomic update event from being processed twice. However, this also
> > prevents the software frame
Op 08-12-16 om 16:43 schreef Daniel Vetter:
> On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote:
>> The current api doesn't take into account that whenever properties like
>> rotation or z-pos change we have to wait for vblank. To make sure
>> that we wait correctly, err on the side
Hi Tomi,
On Tuesday 27 Sep 2016 15:24:47 Tomi Valkeinen wrote:
> On 19/09/16 15:27, Laurent Pinchart wrote:
> > The vblank interrupt is disabled after one occurrence, preventing the
> > atomic update event from being processed twice. However, this also
> > prevents the software frame counter from
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.
Only moving and chang
omap_crtc_vblank_irq(crtc);
> }
>
Did you look at the code you have above =).
I think the bottom change is a good one. Just remove pipe2vbl().
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/c53352e9/attachment.sig>
patch help with the issue?
Best regards,
Jyri
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-tilcdc-Send-pendig-vblank-event-before-recovery-.patch
Type: text/x-patch
Size: 1489 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/b3f8c50b/attachment.bin>
goto done;
>
------ next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/ec688820/attachment-0001.sig>
For a long time, we've known DRM_MM_SEARCH_HIGH/CREATE_TOP to be slow and
broken (both not returning the right hole nor the right alignment). This
series ends by fixing that but takes a quick detour through adding a set
of testcases to catch the broken behaviour and hopefully keep the working
set,
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i91
First we introduce a smattering of infrastructure for writing selftests.
The idea is that we have a test module that exercises a particular
portion of the exported API, and that module provides a set of tests
that can either be run as an ensemble via kselftest or individually via
an igt harness (in
Check that after applying the driver's color adjustment, eviction
scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 198 +++
2 files changed, 199 insertions(+
If we remember that node_list is a circular list containing the fake
head_node, we can use a simple list_next_entry() and skip the NULL check
for the allocated check against the head_node.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
1 file changed, 2 insertion
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 188 +++
2 files changed, 189 insertions(+)
A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe()
for walking the list of nodes safe against removal.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 19 ---
2 files changed, 20 insertions(+), 8 deletions(
Reuse drm_mm_insert_node() with a temporary node to exercise
drm_mm_replace_node(). We use the previous test in order to exercise the
various lists following replacement.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/align64
Testcase: igt/gem_exec_alignment
Signed-of
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing struct drm_mm alignment computations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/lib/drm_pr
Simple first test to just exercise initialisation of struct drm_mm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 2 +
drivers/gpu/drm/selftests/test-drm_mm.c | 83
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm
Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and
validation checking using BUG_ON. Ideally these paths should all be
exercised by CI selftests (with the asserts enabled).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 45 +++--
Check that if we request top-down allocation with a particular alignment
from drm_mm_insert_node() that the start of the node matches our
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 92 ++
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 597648c7a645..5
Check that we add arbitrary blocks to the eviction scanner in order to
find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 252 +++
2 fil
Compute the minimal required hole during scan and only evict those nodes
that overlap. This enables us to reduce the number of nodes we need to
evict to the bare minimum.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 60 +++--
drivers/gpu/d
Exercise drm_mm_reserve_node(), check that we can't reserve an already
occupied range and that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 132
Check that we can request alignment to any power-of-two or prime using a
plain drm_mm_node_insert(), and also handle a reasonable selection of
primes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_mm.c | 104
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
Check that after applying the driver's color adjustment, restricted
eviction scanning find a suitable hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 205 +++
2 files changed, 206 i
Using mm->color_adjust makes the eviction scanner much tricker since we
don't know the actual neighbours of the target hole until after it is
created (after scanning is complete). To work out whether we need to
evict the neighbours because they impact upon the hole, we have to then
check the hole a
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 97
2 files cha
The scan state occupies a large proportion of the struct drm_mm and is
rarely used and only contains temporary state. That makes it suitable to
moving to its struct and onto the stack of the callers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 128 ++
To test whether there are any nodes allocated within the range manager,
we merely have to ask whether the node_list is empty.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 19 +--
include/drm/drm_mm.h | 14 +-
2 files changed, 14 insertions(+), 19 del
The range restriction should be applied after the color adjustment, or
else we may inadvertently apply the color adjustment to the restricted
hole (and not against its neighbours).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 15 +--
1 file changed, 9 insertions(+), 6 d
For power-of-two alignments, we can avoid the 64bit divide and do a
simple bitwise add instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 9 -
include/drm/drm_mm.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers
Exercise drm_mm_insert_node(), check that we can't overfill a range and
that the lists are correct after reserving/removing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 209 +++
2 fil
Since we mandate a strict reverse-order of drm_mm_scan_remove_block()
after drm_mm_scan_add_block() we can further simplify the list
manipulations when generating the temporary scan-hole.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 22 +-
include/drm/drm_mm.h
Doing the check is trivial (low cost in comparison to overall eviction)
and helps simplify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 53 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 10 ++-
include/drm/drm_mm.h
Hi,
On 05-12-16 14:23, Hans de Goede wrote:
> Hi,
>
> On 05-12-16 11:59, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 05-12-16 08:46, Thierry Reding wrote:
On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote:
> The pr
Check that after applying the driver's color adjustment, fitting of the
node and its alignment are still correct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 183 +++
2 files changed,
Mark up the pointers as constant through the API where appropriate.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c| 20 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 2 +-
include/drm/drm_mm.h
Check that we add arbitrary blocks to a restrited eviction scanner in
order to find the first minimal hole that matches our request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 189 ++
For testing, we want a reproducible PRNG, a plain linear congruent
generator is suitable for our very limited selftests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig| 5 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/lib/drm_rand.c | 51 +
Acknowledging that we were building up the hole was more useful to me
when reading the code, than knowing the relationship between this node
and the previous node.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
dif
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
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 89
2 files
2016-12-12 12:26 GMT+01:00 Jyri Sarha :
> On 12/05/16 19:07, Bartosz Golaszewski wrote:
>> 2016-12-05 12:01 GMT+01:00 Bartosz Golaszewski > baylibre.com>:
>>> Hi Jyri,
>>>
>>> I pulled your recent tilcdc pull request on top of v4.9 and Sekhar's
>>> davinci branch (+ vga dac DT)[1].
>>>
>>> I'm gett
Hi Daniel,
2016-12-09 Daniel Vetter :
> Just prep work to polish and consolidate all the dma-buf related
> documenation.
>
> Unfortunately I didn't discover a way to both integrate this new file
> into the overall toc while keeping it at the current place. Work
> around that by moving it into th
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
v9: Have intel_display_cr
2016-12-09 Daniel Vetter :
> This was missed when adding a dma_fence_get call. While at it also
> remove the kerneldoc for the static inline helper - no point
> documenting internals down to every detail.
>
> Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when
> creating sync_f
Am 12.12.2016 um 12:53 schrieb Chris Wilson:
> In places (e.g. i915.ko), the alignment is exported to userspace as u64
> and there now exists hardware for which we can indeed utilize a u64
> alignment. As such, we need to keep 64bit integers throughout when
> handling alignment.
>
> Testcase: igt/d
On Mon, 12 Dec 2016 13:12:16 +0100,
Takashi Sakamoto wrote:
>
> On Dec 12 2016 18:54, Takashi Iwai wrote:
> +enum hdmi_codec_cea_spk_placement {
> +FL = (1 << 0),/* Front Left */
> +FC = (1 << 1),/* Front Center */
> +
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 -> v3
THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.
For now use the dumb-vga-dac driver to support it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
1 file changed, 1 insertion(+)
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
---
arch/arm/boot/dts/da850-lcdk.dts | 67 +
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
http://processors.wiki.ti.com/index.ph
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
---
.../bindings/display/bridge/ti,ths8135.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree
On 10 December 2016 at 21:52, Daniel Vetter wrote:
> No one looks at the major/minor versions except the unique/busid
> stuff. If we protect that with the master_mutex (since it also affects
> the unique of each master, oh well) we can mark these two IOCTL with
> DRM_UNLOCKED.
>
> While doing this
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/f72d39bb/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/c42f02d0/attachment-0001.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/a98c3dbd/attachment.html>
t;
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/9d919df0/attachment.html>
On 11 December 2016 at 18:03, Grazvydas Ignotas wrote:
> Just tell the compiler that drm_event will alias the char buffer,
> so that it has no excuse to warn or generate bad code.
>
Afacit this patch [1] from Thierry should correctly address the issue, correct ?
I've been meaning to parse through
On 11 December 2016 at 18:03, Grazvydas Ignotas wrote:
> xf86drm.c:3601:21: warning: comparison between signed and unsigned integer
> expressions [-Wsign-compare]
> while (expected < sizeof(match)) {
> ^
>
Pushed to master.
Thanks !
Emil
On 10 December 2016 at 05:52, Jonathan Gray wrote:
> When constructing a path to a device node the minor number retrieved
> from fstat needs to have the offset of the node type subtracted from it.
> Control and render node types have the same major as the primary node
> but each has their own bloc
On 10 December 2016 at 05:52, Jonathan Gray wrote:
> When iterating over all the device nodes if drmProcessPciDevice()
> returned an error for any node the function would return an error,
> ignoring any valid nodes.
>
> The result of this on OpenBSD where drmProcessPciDevice() results in
> device
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/958e30e4/attachment.html>
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> The range restriction should be applied after the color adjustment, or
> else we may inadvertently apply the color adjustment to the restricted
> hole (and not against its neighbours).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lah
On Fri, Dec 9, 2016 at 9:49 PM, Caesar Wang wrote:
> Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host
> device, that will cause the panel hang on the startup display.
> The root cause we use the fast link mode during enter and exit the psr,
> this issue is gone if switching
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Monday, December 12, 2016 4:27 AM
> To: Bridgman, John
> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-devel at lists.freedesktop.org; amd-
> gfx at lists.freedesktop.org;
On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta wrote:
> On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
>> From: Swati Dhingra
>>
>> Currently, we don't have a stable ABI which can be used for the purpose of
>> providing output debug/loggging/crc and other such data from DRM.
>> The ABI i
Thierry ---
Correct, and this is no longer needed.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161212/529cd99a/attachment-0
On 12/12/16 15:28, Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
>> Of Daniel Vetter
>> Sent: Monday, December 12, 2016 4:27 AM
>> To: Bridgman, John
>> Cc: Grodzovsky, Andrey; Cheng, Tony; dri-devel at lists.fre
On Wed, Dec 07, 2016 at 11:42:43AM +0100, Bartosz Golaszewski wrote:
> THS8135 is a configurable video DAC. Add DT bindings for this chip and
> use the dumb-vga-dac driver for now as no configuration is required to
> make it work.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> .../bindings/displ
Hello,
On Monday 12 Dec 2016 10:45:47 Rob Herring wrote:
> On Wed, Dec 07, 2016 at 11:42:43AM +0100, Bartosz Golaszewski wrote:
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required to
> > make it work.
>
> -Original Message-
> From: Luke A. Guest [mailto:laguest at archeia.com]
> Sent: Monday, December 12, 2016 11:17 AM
> To: Deucher, Alexander; 'Daniel Vetter'; Bridgman, John
> Cc: Grodzovsky, Andrey; Cheng, Tony; amd-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org
> Su
On 12 December 2016 at 15:07, Jonathan Gray wrote:
> On Mon, Dec 12, 2016 at 02:10:31PM +, Emil Velikov wrote:
>> On 10 December 2016 at 05:52, Jonathan Gray wrote:
>> > When constructing a path to a device node the minor number retrieved
>> > from fstat needs to have the offset of the node t
Hello,
On Fri, Dec 09, 2016 at 02:01:40PM -0800, Andrew Morton wrote:
> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes rasmusvillemoes.dk> wrote:
>
> > TL;DR: these patches save 250 KB of memory, with more low-hanging
> > fruit ready to pick.
> >
> > While browsing through the lib/idr.c co
Hello, Matthew.
On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote:
> I know the preload followed by preload_end looks wrong. I don't
> think it's broken though. If we get preempted, then the worst
> situation is that we'll end up with the memory we preallocated being
> allocated to
On Mon, Dec 12, 2016 at 12:40 AM, Archit Taneja
wrote:
> Hi,
>
> On 11/29/2016 10:34 AM, John Stultz wrote:
>>
>> Wanted to send out v2 of this patch set improving the EDID
>> probing on the adv7511 used on HiKey.
>>
>> The first three patches are fixups that are hopefully straight
>> forward, in
1 - 100 of 136 matches
Mail list logo
