for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/8818c190/attachment-0001.html>
+Qiang, who is working on it.
On 2016å¹´11æ27æ¥ 22:07, Christian König wrote:
> Am 27.11.2016 um 15:02 schrieb Haggai Eran:
>> On 11/25/2016 9:32 PM, Jason Gunthorpe wrote:
>>> On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote:
>>>
> Like you say below we have to handle shor
On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann
wrote:
> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote:
>> grep "card0" dmesg:
>> [5.298617] device: 'card0': device_add
>> [5.298946] PM: Adding info for No Bus:card0
>> [6.436178] device: 'card0': device_add
>> [6.436488] P
On su, 2016-11-27 at 17:09 +, Chris Wilson wrote:
> Remove the ugly sparse casts by using the helper u64_to_user_ptr()
> instead.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
On Sun, Nov 27, 2016 at 03:32:39PM +0100, Christian König wrote:
> Am 27.11.2016 um 12:16 schrieb Chris Wilson:
> > start is being used as both a macro parameter and as a member of struct
> > drm_mm_node (node->start). This causes a conflict as cpp then tries to
> > replace node->start with the pa
On Sun, Nov 27, 2016 at 02:08:34PM +, Chris Wilson wrote:
> A set of test cases to capture some annoying bugs and to ensure that
> correct behaviour does not regress whilst fixing those!
>
> Signed-off-by: Chris Wilson
Adding kselftest mailing list and cc.
-Daniel
> ---
> drivers/gpu/drm/K
On 28/11/16 03:55 PM, Daniel Vetter wrote:
> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann
> wrote:
>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote:
>>> grep "card0" dmesg:
>>> [5.298617] device: 'card0': device_add
>>> [5.298946] PM: Adding info for No Bus:card0
>>> [6.436
On Sun, Nov 27, 2016 at 05:09:10PM +, Chris Wilson wrote:
> smatch correctly warns:
>
> drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn:
> should '1 << i' be a 64 bit type?
> drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn:
> should '1 << i' be a
On Fri, Nov 25, 2016 at 03:32:29PM +, Chris Wilson wrote:
> We are told not to set plane_state->fb directly, but use
> drm_atomic_set_fb_for_plane() instead. Using the helper, means one less
> piece of code that needs fixing should the interface change...
>
> Signed-off-by: Chris Wilson
Revi
in general yet.
--
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/20161128/49162430/attachment.html>
On Wed, Nov 23, 2016 at 02:04:15PM +, Chris Wilson wrote:
> The fb_helper->connector_count is modified when a new connector is
> constructed following a hotplug event (e.g. DP-MST). This causes trouble
> for drm_setup_crtcs() and friends that assume that fb_helper is
> constant:
>
> [ 1250.872
sound quite odd, as the it really should
be bytes, not pixels... Bad bindings again, which we just have to use.
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/20161128/12541df9/attachment.sig>
On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> We can simplify the code greatly if both legacy and atomic paths updated
> the references as they assigned the framebuffer to the planes. Long
> before framebuffer reference counting was added, the code had to keep
> the old_fb around
On Do, 2016-11-24 at 04:57 +0200, Michael S. Tsirkin wrote:
> sparse produces these warnings:
>
> drivers/gpu/drm/virtio/virtgpu_fb.c:340:27: warning: incorrect type in
> assignment (different address spaces)
> drivers/gpu/drm/virtio/virtgpu_fb.c:340:27:expected char [noderef]
> *screen_base
>
On Wed, Nov 23, 2016 at 02:04:16PM +, Chris Wilson wrote:
> drm_fb_helper_probe_connector_modes() is always called before
> drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
> small bit of code compaction.
>
> Signed-off-by: Chris Wilson
This drops drm_modeset_lock_all() ar
On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote:
> Though we only walk the kernel_fb_helper_list inside a panic (or single
> thread debugging), we still need to protect the list manipulation on
> creating/removing a framebuffer device in order to prevent list
> corruption.
>
> Signed-
virtio uses normal ram as backing storage for the framebuffer, so we
should assign the address to new screen_buffer (added by commit
17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base.
Reported-by: Michael S. Tsirkin
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_
On Fri, Nov 25, 2016 at 05:03:09PM +0100, Neil Armstrong wrote:
> The Amlogic Meson Display controller is composed of several components :
>
> DMC|---VPU (Video Processing
> Unit)|--HHI--|
>| vd1 ___ __ |
On su, 2016-11-27 at 17:09 +, Chris Wilson wrote:
> smatch correctly warns:
>
> drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn:
> should '1 << i' be a 64 bit type?
> drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn:
> should '1 << i' be a 64 bit
Hi Neil,
Thank you for the patch.
On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/meson/meson-drm.txt | 134 +
> 1 file changed, 134 insertions(+)
> create mode 100644
> Documentation/devicetree/binding
L:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/a8f32219/attachment.html>
On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote:
> > Though we only walk the kernel_fb_helper_list inside a panic (or single
> > thread debugging), we still need to protect the list manipulation on
> > creating/removing a
On 11/28/2016 06:37 AM, Kuninori Morimoto wrote:
>
> Hi
>
>> The newly added sound driver depends on SND_SOC_HDMI_CODEC, which in
>> turn only makes sense when ASoC is enabled, as shown by this warning:
>>
>> warning: (DRM_MSM && DRM_STI && DRM_MEDIATEK_HDMI && DRM_I2C_NXP_TDA998X &&
>> DRM_DW_H
On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state
> > *plane_state
On su, 2016-11-27 at 19:05 +, Chris Wilson wrote:
> 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.
>
> Testc
Hi Neil,
On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
> > On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
> >> Signed-off-by: Neil Armstrong
> >> ---
> >>
> >> .../bindings/display/meson/meson-drm.txt | 134 +++
Hi Neil,
On Monday 28 Nov 2016 10:56:30 Neil Armstrong wrote:
> On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
> > On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
> >> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
> >>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
> Signed-off
On Mon, 28 Nov 2016, Ali Gholami Rudi wrote:
> In linux-4.8.11, I get the following in my dmesg (and a
> 20-second delay):
Please file a bug at [1].
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
Am 27.11.2016 um 20:05 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
2016-11-28 8:58 GMT+01:00 Sekhar Nori :
> On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote:
>> On 28/11/16 07:24, Sekhar Nori wrote:
>>> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
It has been determined that the maximum resolution supported correctly
by tilcd
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/20710619/attachment-0001.html>
..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/d5c276f8/attachment.html>
The DT binding for tildc is not consistent with the driver code: there
are two options - 'max-width' and 'max-pixelclock' specified in the
documentation which are parsed as 'ti,max-width' and
'ti'max-pixelclock' respectively.
Make the driver code consistent with the binding.
Signed-off-by: Bartos
Hi Andy,
(CC'ing Kieran Bingham)
On Monday 28 Nov 2016 19:34:59 Andy Yan wrote:
> On 2016å¹´11æ26æ¥ 03:26, Laurent Pinchart wrote:
> > On Friday 25 Nov 2016 17:08:13 Philipp Zabel wrote:
> >> Am Freitag, den 25.11.2016, 17:45 +0200 schrieb Laurent Pinchart:
> >>> On Friday 25 Nov 2016 10:56:55
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
Bartosz
Due to memory throughput constraints any display mode for which the
pixel clock rate exceeds the recommended value of 37500 KHz must be
filtered out.
Specify the max-pixelclock property for the display node for
da850-lcdk.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts
Add the dumb-vga-dac 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
---
arch/arm/boot/dts/da850-lcdk.dts | 58
arch/arm/boo
From: Nicolai Hähnle
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
kernel/locking/mutex.c | 10 --
1 file ch
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
Check the current owner's context once against our stamp. If our stamp is
lower, we continue to spin optimistically instead of backing off.
This is correct with respect to deadlock detection because while the
(owner, ww_ctx) pair may re-appear if the owner task manages to u
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
On Mon, Nov 28, 2016 at 01:42:26PM +0100, Maarten Lankhorst wrote:
> > + ww_mutex_lock(&resv->lock.base, NULL);
> Yuck, can we rename base to __NEVER_TOUCH_DIRECTLY_OUTSIDE_LOCKING_CORE?
> It's harder to get them confused like that, even with a null context it's
> illegal to call mutex_lock/unl
Am 28.11.2016 um 13:20 schrieb Nicolai Hähnle:
> From: Nicolai Hähnle
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Nicolai Hähnle
> ---
> drivers/gpu/drm/vgem/vgem_fence.
On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1253,7 +1253,7
On Mon, Nov 28, 2016 at 08:38:21AM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote:
> > > Though we only walk the kernel_fb_helper_list inside a panic (or single
> > > thread debugging), we
On Tue, Nov 22, 2016 at 04:49:51PM +0200, Jyri Sarha wrote:
> Move "ti,tfp410.txt" from display/ti to display/bridge before adding
> generic (non omapdrm/dss specific) implementation and new features.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 41
The Lenono P70's HDMI connector is listed twice, both as DP and as
DVI connector. Ignore the DVI entry, making all ports show up as
DP ports, like on the non-broken P50 model.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_bios.c | 11 +++
1 file changed, 11 insertions(
Hi Jose,
On Monday 28 Nov 2016 12:09:59 Jose Abreu wrote:
> On 28-11-2016 11:45, Laurent Pinchart wrote:
> > On Monday 28 Nov 2016 19:34:59 Andy Yan wrote:
> >> On 2016å¹´11æ26æ¥ 03:26, Laurent Pinchart wrote:
> >>> On Friday 25 Nov 2016 17:08:13 Philipp Zabel wrote:
> Am Freitag, den 25.1
On Tue, Nov 22, 2016 at 04:49:52PM +0200, Jyri Sarha wrote:
> Add very basic ti-tfp410 DVI transmitter driver. The only feature
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector driver. How
On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > > --- a/drivers/gpu/drm/drm_ato
On 2016-11-27 09:02 AM, Haggai Eran wrote
> On PeerDirect, we have some kind of a middle-ground solution for pinning
> GPU memory. We create a non-ODP MR pointing to VRAM but rely on
> user-space and the GPU not to migrate it. If they do, the MR gets
> destroyed immediately. This should work on leg
On Mon, Nov 28, 2016 at 08:26:07AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:15PM +, Chris Wilson wrote:
> > +#define drm_fb_helper_for_each_connector(fbh, i__) \
> > + for (({lockdep_assert_held(&(fbh)->dev->mode_config.mutex); 1;}), \
> > +i__ = 0; i__ < (fbh)->con
Now that we wait for DRM panels to be available before registering the
DRM device (returning -EPROBE_DEFER if the panel has not been probed
yet), we no longer need to put the fbdev creation code in
->output_poll_changed().
This removes the 10 secs delay between DRM dev registration and fbdev
creat
On Mon, Nov 28, 2016 at 09:05:21AM +0100, Gerd Hoffmann wrote:
> virtio uses normal ram as backing storage for the framebuffer, so we
> should assign the address to new screen_buffer (added by commit
> 17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base.
>
> Reported-by: Michael S. Ts
On Mon, Nov 28, 2016 at 02:44:15PM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> > > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 25, 2016 at 03:32
On Mon, Nov 28, 2016 at 04:01:07PM +0100, Boris Brezillon wrote:
> Now that we wait for DRM panels to be available before registering the
> DRM device (returning -EPROBE_DEFER if the panel has not been probed
> yet), we no longer need to put the fbdev creation code in
> ->output_poll_changed().
>
On Thu, Nov 24, 2016 at 08:01:10PM +0200, Jani Nikula wrote:
> On Thu, 24 Nov 2016, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > drm_atomic_crtc_needs_modeset() doesn't change the passed in
> > crtc state, so pass it as const.
> >
> > Signed-off-by: Ville Syrjälä
>
On Tue, Nov 08, 2016 at 12:43:55PM +0100, Andrzej Hajda wrote:
> On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > CEA-861 specifies that the vertical front porch may vary by one or two
> > lines for specific VICs. Up to now we've only considered a mode
On Tue, Nov 22, 2016 at 7:50 PM, Archit Taneja
wrote:
> On 11/23/2016 01:16 AM, John Stultz wrote:
>> On Tue, Nov 22, 2016 at 9:38 AM, Laurent Pinchart
>> wrote:
>>> On Tuesday 22 Nov 2016 09:25:22 John Stultz wrote:
On Tue, Nov 22, 2016 at 12:14 AM, Laurent Pinchart wrote:
> On Monday
Hi Jose,
On Monday 28 Nov 2016 15:25:18 Jose Abreu wrote:
> On 28-11-2016 14:24, Laurent Pinchart wrote:
> > On Monday 28 Nov 2016 12:09:59 Jose Abreu wrote:
> >> On 28-11-2016 11:45, Laurent Pinchart wrote:
> >>> On Monday 28 Nov 2016 19:34:59 Andy Yan wrote:
> On 2016å¹´11æ26æ¥ 03:26, La
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/7ef2d38c/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/b51e3163/attachment.html>
All, here is initial kernel support for the Adreno A5XX family of
GPUs found on the QTI Snapdragon 820 and 821 among others.
This stack turns on the A5XX hardware and initializes the GPMU
(Graphics Power Management Unit) which is a microcontroller
to assist with more independent power management.
When the GPU hardware init function fails (like say, ME_INIT timed
out) return error instead of blindly continuing on. This gives us
a small chance of saving the system before it goes boom.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 -
drive
Most 5XX targets have GPMU (Graphics Power Management Unit) that
handles a lot of the heavy lifting for power management including
thermal and limits management and dynamic power collapse. While
the GPMU itself is optional, it is usually nessesary to hit
aggressive power targets.
The GPMU firmware
The adreno code inherited a silly workaround from downstream
from the bad old days before decent clock control. grp_clk[0]
(named 'src_clk') doesn't actually exist - it was used as a proxy
for whatever the core clock actually was (usually 'core_clk').
All targets should be able to correctly reques
Add helper functions for TYPE4 and TYPE7 ME opcodes that replace
TYPE0 and TYPE3 starting with the A5XX targets.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno
Disable the interrupt during the init sequence to avoid having
interrupts fired for errors and other things that we are not
ready to handle while initializing.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 3 +++
Add some new functions to manipulate GPU registers. gpu_read64 and
gpu_write64 can read/write a 64 bit value to two 32 bit registers.
For 4XX and older these are normally perfcounter registers, but
future targets will use 64 bit addressing so there will be many
more spots where a 64 bit read and w
The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
only render to buffers that are marked as secure and inaccessible
to the kernel and user through a series of hardware protections. In
practice secure mode is used to draw things like a UI on a secure
video frame.
In order to switc
There are very few register accesses in the common code. Cut down
the list of common registers to just those that are used. This
saves const space and saves us the effort of maintaining registers
for A3XX and A4XX that don't exist or are unused.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/
Add support for the A5XX family of Adreno GPUs.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 823 +
drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 37 ++
drivers/gpu/drm/msm/adreno/adr
Add an interface to trigger the remote processor to reinitialize the GPU
zap shader on power-up.
Signed-off-by: Jordan Crouse
---
drivers/firmware/qcom_scm-32.c | 5 +
drivers/firmware/qcom_scm-64.c | 15 +++
drivers/firmware/qcom_scm.c| 6 ++
drivers/firmware/qcom_scm.
In order to switch the GPU out of secure mode on most systems we
need to load a zap shader into memory and get it authenticated
and into the secure world. All the bits and pieces to do
the load are scattered throughout the kernel, but we need to
bring everything together.
Add a semi-custom loader
On Thu, Nov 24, 2016 at 08:51:35AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 11:28:21PM -0800, Manasi Navare wrote:
> > This is RFC patch for adding a connector link-status property
> > and making it atomic by adding it to the drm_connector_state.
> > This is to make sure its wired prop
Add a new generic function to write a "64" bit value. This isn't
actually a 64 bit operation, it just writes the upper and lower
32 bit of a 64 bit value to a specified LO and HI register. If
a particular target doesn't support one of the registers it can
mark that register as SKIP and writes/read
AMD graphics card back to the dealer. Should I do that?
Or may I hope for a fix soon?
--
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/20161128/392ee648/attachment.html>
On 2016-11-28 01:20 PM, Logan Gunthorpe wrote:
>
> On 28/11/16 09:57 AM, Jason Gunthorpe wrote:
>>> On PeerDirect, we have some kind of a middle-ground solution for pinning
>>> GPU memory. We create a non-ODP MR pointing to VRAM but rely on
>>> user-space and the GPU not to migrate it. If they do,
On 2016-11-28 04:36 PM, Logan Gunthorpe wrote:
> On 28/11/16 12:35 PM, Serguei Sagalovitch wrote:
>> As soon as PeerDirect mapping is called then GPU must not "move" the
>> such memory. It is by PeerDirect design. It is similar how it is works
>> with system memory and RDMA MR: when "get_user_pag
Hi Laurent, all,
On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart
wrote:
> Hi Andy,
>
> On Friday 25 Nov 2016 10:56:53 Andy Yan wrote:
>> On 2016å¹´11æ25æ¥ 07:26, Laurent Pinchart wrote:
>> > On Friday 25 Nov 2016 00:16:00 Vladimir Zapolskiy wrote:
>> >> On 11/25/2016 12:07 AM, Fabio Estevam
From: Derek Foreman
There was a small window where a userspace program could submit
a pageflip after receiving a pageflip completion event yet still
receive EBUSY.
Signed-off-by: Derek Foreman
Signed-off-by: Eric Anholt
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8 +++
-
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/37665e1d/attachment-0001.html>
rchives/dri-devel/attachments/20161128/9986efbd/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/2e433572/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/79c625a1/attachment.html>
|--- |FIXED
--
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/20161128/73da53fc/attachment.html>
fix should be apart from these 2 patches.
CQP works perfectly with vanilla mesa, it is broken by patch 1.
--
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/20161128/9d6bcb32/attachment.html>
On Mon, 2016-11-28 at 09:48 -0500, Serguei Sagalovitch wrote:
> On 2016-11-27 09:02 AM, Haggai Eran wrote
> >
> > On PeerDirect, we have some kind of a middle-ground solution for
> > pinning
> > GPU memory. We create a non-ODP MR pointing to VRAM but rely on
> > user-space and the GPU not to migra
Hi,
In linux-4.8.11, I get the following in my dmesg (and a
20-second delay):
[1.932295] Linux agpgart interface v0.103
[1.932448] [drm] Initialized drm 1.1.0 20060810
[1.932799] pci :00:00.0: Intel 965GME/GLE Chipset
[1.932902] pci :00:00.0: detected gtt size: 524288K tot
On Mon, Nov 28, 2016 at 8:14 AM, Michel Dänzer wrote:
> On 28/11/16 03:55 PM, Daniel Vetter wrote:
>> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann
>> wrote:
>>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov
>>> wrote:
grep "card0" dmesg:
[5.298617] device: 'card0': device_ad
Hi
> The newly added sound driver depends on SND_SOC_HDMI_CODEC, which in
> turn only makes sense when ASoC is enabled, as shown by this warning:
>
> warning: (DRM_MSM && DRM_STI && DRM_MEDIATEK_HDMI && DRM_I2C_NXP_TDA998X &&
> DRM_DW_HDMI_I2S_AUDIO) selects SND_SOC_HDMI_CODEC which has unmet d
On Mon, Nov 28, 2016 at 06:19:40PM +, Haggai Eran wrote:
> > > GPU memory. We create a non-ODP MR pointing to VRAM but rely on
> > > user-space and the GPU not to migrate it. If they do, the MR gets
> > > destroyed immediately.
> > That sounds horrible. How can that possibly work? What if the M
Am 28.11.2016 um 21:05 schrieb Volker Armin Hemmann:
> Hello,
>
> I got a XFX RX-470P4LDB6.
>
> Booting with modprobe.blacklist=amdgpu gives me a working system.
>
> Loading the module results in this mess:
>
> Nov 28 19:40:00 [kernel] [ 144.213021] [drm] amdgpu kernel modesetting
> enabled.
> Nov
1 - 100 of 137 matches
Mail list logo
