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>
|--- |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>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/79c625a1/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>
rchives/dri-devel/attachments/20161128/9986efbd/attachment.html>
Am 28.11.2016 um 21:58 schrieb Volker Armin Hemmann:
> 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]
-
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161128/37665e1d/attachment-0001.html>
Hi Laurent,
[fixing Stephen's email address]
On Mon, Nov 28, 2016 at 10:04 PM, Laurent Pinchart
wrote:
> Hi Mike,
>
> On Monday 28 Nov 2016 13:56:11 Michael Turquette wrote:
>> On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart wrote:
>> > On Friday 25 Nov 2016 10:56:53 Andy Yan wrote:
>> >> On 2
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
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
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 28 19:40:00 [kernel] [ 144.213054] checking generic (c000
30)
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors
on HiKey.
Investigating further, it seems some of the register state
in the regmap cache is somehow getting lost. Using the logic
in __adv7511_power_on/off() which syncs and dirtys
In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.
This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
From: Archit Taneja
On some adv7511 implementations, we can get some spurious
disconnect signals which can cause monitor probing to fail.
This patch enables HPD (hot plug detect) interrupt support
which allows the monitor to be properly re-initialized when
the spurious disconnect signal goes awa
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.
Thus this patch replaces drm_helper_hpd_irq_event() with
drm_kms_helper_hotpl
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.
Digging deeper, I found this was due to the fact that
IRQs were disabled as we were running in IRQ context from
the HPD signal.
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 that Laurant had concerns about, I
broke into two patches,
Hi:
On 2016å¹´11æ26æ¥ 03:26, Laurent Pinchart wrote:
> Hi Philipp,
>
> 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 Philipp Zabel wrote:
Am Donnerstag, den 24.11.2016, 23:16 +020
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>
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>
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>
Signed-off-by: Jean-Francois Moine
---
.../bindings/display/sunxi/sun8i-de2.txt | 121 +
1 file changed, 121 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
diff --git a/Documentation/devicetree/bindings/display/sunxi
Hi Dave,
Some fixes and cleanup, mainly around fbdev emulation. It also adds a
new module parameter which allows to specify the color depth/bpp for
the fbdev emulation (like the IMX DRM driver).
There have been some fixes in that driver which are not yet in
drm-next, but it seems to merge cleanly
Two warnings are produced by gcc (tested with gcc 6.2.1):
drivers/gpu/drm/i915/intel_csr.c: In function âcsr_load_work_fnâ:
drivers/gpu/drm/i915/intel_csr.c:400:5: error: âfwâ is used
uninitialized in this function [-Werror=uninitialized]
if (fw)
^
and
In file included from drive
On 2016-11-16 17:35, Stefan Agner wrote:
> The separate file fsl_dcu_drm_fbdev.c only initialized fbdev
> emulation which is a one-line operation. There is not much more
> code on sight which justifies a separate file, hence call the
> initialization helper directly from the drv file.
Both applied
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
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 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 Mon, 2016-11-28 at 09:57 -0700, Jason Gunthorpe wrote:
> On Sun, Nov 27, 2016 at 04:02:16PM +0200, Haggai Eran wrote:
> > I think blocking mmu notifiers against something that is basically
> > controlled by user-space can be problematic. This can block things
> > like
> > memory reclaim. If you
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
From: Srinivas Kandagatla
This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.
Cc: David Airlie
Cc: Archit Taneja
Cc: Laurent Pinchart
Cc: Wolfram Sang
Cc: Srinivas Kandagatla
Cc: "Ville Syrjälä"
Cc: Boris Brezillon
Cc: Andy
This patch adds support to Audio for both adv7511 and adv7533
bridge chips.
This patch was originally from [1] by Lars-Peter Clausen
and was adapted by Archit Taneja and
Srinivas Kandagatla .
Then I heavily reworked it to use the hdmi-codec driver. And also
folded in some audio packet initializ
Once again, resending the adv7511 hdmi bridge audio support for
review and consideration for merging.
(I feel a bit like I'm yelling into the void here, am I missing
anyone from the CC list here, or somehow submitting this
improperly?)
I've taken the core audio work done by Lars-Peter Clausen, a
On 2016-11-16 07:38, Fabio Estevam wrote:
> devm_ioremap_resource() performs NULL check for the 'res' argument,
> so remove the unneeded check.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers
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
On Wed, Nov 23, 2016 at 09:09:28AM +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
> > On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
> > wrote:
> > > This is RFC patch for adding a connector link-status property
> > > and making it atomic by adding it to t
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
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 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
Hi,
On Fri, Jun 24, 2016 at 10:13:33AM +0800, Shunqian Zheng wrote:
> From: Simon Xue
>
> This patch makes it possible to compile the rockchip-iommu driver on
> ARM64, so that it can be used with 64-bit SoCs equipped with this type
> of IOMMU.
>
> Signed-off-by: Simon Xue
> Signed-off-by: Shun
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 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
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
Hi Laurent,
On 28-11-2016 14:24, Laurent Pinchart wrote:
> 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
On Mon, Nov 28, 2016 at 04:55:23PM -0500, Serguei Sagalovitch wrote:
> >We haven't touch this in a long time and perhaps it changed, but there
> >definitely was a call back in the PeerDirect API to allow the GPU to
> >invalidate the mapping. That's what we don't want.
> I assume that you are talk
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(
Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
engine, DE2.
This patch adds a DRM video driver for this device.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/sun8i/Kconfig | 1
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 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: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
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 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_pages" is called then the
> memory is pinned.
We haven
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,
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 +++
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
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.
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
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
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
Op 28-11-16 om 13:20 schreef 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.c |
+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 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 tilcdc rev1 on da850 SoCs is 800x600 at 60. Due to
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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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 +++
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
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
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
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
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/
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.
Hi All,
On 28-11-2016 11:45, Laurent Pinchart wrote:
> 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 +020
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
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, 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
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
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
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 +++
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
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
On 11/28/2016 11:02 AM, Laurent Pinchart wrote:
> 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 No
1 - 100 of 137 matches
Mail list logo
