https://bugs.freedesktop.org/show_bug.cgi?id=97059
--- Comment #14 from Fabian Maurer ---
The opengl calls blender make are faulty, since a trace doesn't render properly
on windows with proprietary AMD drivers either.
Though I still want to ask, could we get rid of the random contents? Under
win
On Fri, Mar 17, 2017 at 7:58 AM, Lucas Stach wrote:
> Am Freitag, den 17.03.2017, 14:42 + schrieb Russell King - ARM
> Linux:
>> On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
>> > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
>> > > Hi Gustavo,
>> > >
>> > >
On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring wrote:
> On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote:
>> The Allwinner Timings Controller has two, mutually exclusive, channels.
>> When the binding has been introduced, it was assumed that there would be
>> only a single user per chan
On Fri, Mar 17, 2017 at 03:58:27PM +0100, Lucas Stach wrote:
> Am Freitag, den 17.03.2017, 14:42 + schrieb Russell King - ARM
> Linux:
> > On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
> > > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
> > > > Hi Gustavo,
> >
On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
> This is a modesetting driver for the pl111 CLCD display controller
> found on various ARM platforms such as the Versatile Express. The
> driver has only been tested on the bcm911360_entphn platform so far,
> with PRIME-based buffer shar
On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
> Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
> > Hi Gustavo,
> >
> > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> > [...]
> > > I was thinking on some function that would iterate over all fences in
>
From: Mario Kleiner
commit ff683df7bf34f90766a50c7e7454e219aef2710e upstream.
In the display resume path, move the calls to drm_vblank_on()
after the point when the display engine is running again.
Since changes were made to drm_update_vblank_count() in Linux 4.4+
to emulate hw vblank counters
On March 16, 2017 5:41:24 PM Emil Velikov wrote:
On 17 March 2017 at 00:21, Dylan Baker wrote:
Hi Emil,
Quoting Emil Velikov (2017-03-16 16:35:33)
While I can see you're impressed by Meson, I would kindly urge you to
not use it here. As you look closely you can see that one could
trivially i
Hello,
I am writing a para-virtualized DRM driver for Xen hypervisor
and it now works with DRM CMA helpers, but I would also like
to make it work with non-contigous memory: virtual machine
that the driver runs in can't guarantee that CMA is actually
physically contigous (that is not a problem beca
commit bb74fc1bf3072bd3ab4ed5f43afd287a63baf2d7 upstream.
drm_vblank_offdelay can have three different types of values:
< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wan
On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand
wrote:
> On March 16, 2017 5:41:24 PM Emil Velikov
> wrote:
>
>> On 17 March 2017 at 00:21, Dylan Baker wrote:
>>
>>> Hi Emil,
>>>
>>> Quoting Emil Velikov (2017-03-16 16:35:33)
>>>
While I can see you're impressed by Meson, I would kindly ur
https://bugs.freedesktop.org/show_bug.cgi?id=97059
Michel Dänzer changed:
What|Removed |Added
CC||dark.shad...@web.de
--- Comment #13 from
This never got set in the ioctl. Properly set a return value of 0 on
success.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 64c652b..8bd90ce 10064
The current model of Ion heap registration is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_cl
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233..5a8
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can b
Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig
To: Sumit Semwal
To: Riley Andrews
Cc: rom...@google.com
To: a...@android.com
To: Riley Andrews
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Greg Kroah-Hartman
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-me...@vger.kernel.org
Cc:
ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two
identical interfaces. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c | 1 -
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/uapi/ion.h | 10 --
3 files
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h | 12 +
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging/androi
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
drivers/base/dma-contiguous.c | 5 +++--
include/linux/cma.h | 4 +++-
mm/cma.c
The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.
Signed-off-by: Laura Abbott
---
drivers/stagi
With the expansion of dma-buf and the move for Ion to be come just an
allocator, the import mechanism is mostly useless. There isn't a kernel
component to Ion anymore and handles are private to Ion. Remove this
interface.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Signed-off-by: Laura Abbott
---
drivers/staging/android/
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 117 --
1 file changed, 117 deletions(-)
diff --git a/drivers/stag
Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c
The reference counting of dma_map calls was removed. Remove the
associated counter field as well.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion_priv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_priv.h
b/drivers/staging/android/ion/ion
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include
Ion is now moving towards a unified interfact. This makes the custom
ioctl interface unneeded. Remove it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/compat_ion.c | 40
drivers/staging/android/ion/ion-ioctl.c | 11 -
drivers/staging/andr
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
Hi,
This is v2 of the series to do some serious Ion clean up in preparation for
moving out of staging. I got good feedback last time so this series mostly
attempts to address that feedback and do more still more cleanup. Highlights:
- All calls to DMA APIs should now be with a real actual proper
Russell King - ARM Linux writes:
> On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
>> This is a modesetting driver for the pl111 CLCD display controller
>> found on various ARM platforms such as the Versatile Express. The
>> driver has only been tested on the bcm911360_entphn platfor
Colin King writes:
> From: Colin Ian King
>
> The pointer plane is always null on the error path at label 'fail'
> hence the check if it is non-null is redundant. We can therefore
> remove the check and the destruction of plane as well as the fail
> error path and instead just return an -ENOMEM
Philipp Zabel writes:
> Use platform_register_drivers instead of open coding the iteration over
> component platform drivers in the vc4_drv module.
Reviewed and applied. Thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri
The logic was all right in the end, the name was just backwards.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 3bad8bad32a2..deba62008fd0
The DPHY spec requires a much larger T_INIT than I was specifying
before. In the absence of clear specs from the slave of what their
timing is, just use the value that the firmware was using.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 12 +++-
1 file changed, 11 inse
h;
+
+out_config:
+ drm_mode_config_cleanup(dev);
+finish:
+ return ret;
+}
+
+static const struct file_operations drm_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release = drm_release,
+ .unlocked_ioctl = drm_ioctl,
+ .mmap = drm_gem_cma_mmap,
+ .poll = d
This is a resurrection of Tom Cooksey's old CLCD DRM driver, which I
needed in order to do dmabuf buffer sharing from VC4 to the CLCD
display on the bcm911360_entphn platform. With a couple of hacks to
the X Server, I've got it (sometimes) running glxgears on vc4 and
displaying on CLCD.
The panel
We'd like to reuse these register definitions for the DRM CLCD driver,
but there's a bunch of fbdev-specific code in the current header.
Signed-off-by: Eric Anholt
---
include/linux/amba/clcd-regs.h | 76 ++
include/linux/amba/clcd.h | 68 +---
On Fri, Mar 17, 2017 at 5:15 AM, Dylan Baker wrote:
> Quoting Marek Olšák (2017-03-16 18:53:59)
>> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker wrote:
>> > Quoting Marek Olšák (2017-03-16 15:36:26)
>> >> Is there a way not to use ninja with meson, because ninja redirects
>> >> all stderr output
On Fri, Mar 17, 2017 at 08:20:27PM +, Chris Wilson wrote:
> Order the update to vblank->enabled after the timestamp is primed so
> that a concurrent unlocked reader will only see the vblank->enabled with
> the current timestamp.
>
> v2: vblank->enable is guarded by dev->vbl_lock not
> dev->vbl
https://bugs.freedesktop.org/show_bug.cgi?id=99841
--- Comment #19 from Peter Mattern ---
The patch is fixing the problem on an ATI system as well here (Radeon HD 7480D
/ APU A4-5300, Arch Linux, kernel 4.10.{1-3}).
Is there any way to track when it will be included in mainline?
--
You are rec
Since we cannot enable the vblank if !dev->irq_enabled, we assert that
checking for both !vblank->enabled and !dev->irq_enabled is tautological
and only need the former. The only time it may differ is when racing
with drm_irq_uninstall(), but that will then disable the vblank and
wakeup the waiters
Move the repeated (a - b) <= (1 << 23) to its own function.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
ind
Bypass all the spinlocks and return the last timestamp and counter from
the last vblank if the driver delcares that it is accurate (and stable
across on/off), and the vblank is currently enabled.
This is dependent upon the both the hardware and driver to provide the
proper barriers to facilitate r
Order the update to vblank->enabled after the timestamp is primed so
that a concurrent unlocked reader will only see the vblank->enabled with
the current timestamp.
v2: vblank->enable is guarded by dev->vbl_lock not
dev->vblank_time_lock, update the READ_ONCE accordingly.
Do not add a READ_ONCE(v
On 2017-03-17 03:55 AM, Shirish S wrote:
update_plane() and disable_plane() functions
assoiciated with setting plane are called
without any check, causing kernel panic.
This patch adds the required check to avoid it.
Change-Id: I0d6792608b33e674c217388aa57c4b7d680d9bc7
Signed-off-by: Shirish S
On Fri, Mar 17, 2017 at 11:49:32AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 11:47:49PM +, Chris Wilson wrote:
> > Bypass all the spinlocks and return the last timestamp and counter from
> > the last vblank if the driver delcares that it is accurate (and stable
> > across on/off), a
Ville Syrjälä writes:
> On Fri, Mar 17, 2017 at 05:57:52PM +0100, Daniel Vetter wrote:
>> On Fri, Mar 17, 2017 at 01:08:43PM +0200, Ville Syrjälä wrote:
>> > On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote:
>> > > On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
>> > > wrote:
>> > > > On
[+ Lionel]
On 16 March 2017 at 16:46, Eric Engestrom wrote:
> On Thursday, 2017-03-16 00:08:59 +, Eric Engestrom wrote:
>> According to the kernel documentation:
>> Returns non-zero if @v was not @u, and zero otherwise.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100077
>>
On Fri, Mar 17, 2017 at 10:37 AM, Colin King wrote:
> From: Colin Ian King
>
> The outer loop is redundant and can be removed as it is doing nothing
> useful. Also remove some commented out code that is not being used.
>
> Detected by CoverityScan, CID#1402073
>
> Signed-off-by: Colin Ian King
Use the dma_fence_match_context helper to check if all backing fences
are from our own context, in which case we don't have to wait.
Signed-off-by: Philipp Zabel
Cc: Rob Clark
Cc: Gustavo Padovan
---
Not sure if this can be handled exactly the same as for etnaviv. This depends on
d5b72a2123df (
Am 17.03.2017 um 17:34 schrieb Philipp Zabel:
Add a helper to check if all fences in a fence array are from a given
context. For convenience, the function can also handle being given a
non-array fence.
Signed-off-by: Philipp Zabel
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fenc
In the same spirit of the fix for QXL in commit 861078381ba5 ("drm: qxl:
Don't alloc fbdev if emulation is not supported"), prevent the Oops in
the unbind path of Bochs if fbdev emulation is disabled.
[ 112.176009] Oops: 0002 [#1] SMP
[ 112.176009] Modules linked in: bochs_drm
[ 112.176009] CPU
Hi Philipp,
Thanks for your patch!
On 17 March 2017 at 22:04, Philipp Zabel wrote:
> Loosely based on commit f0a42bb5423a ("drm/msm: submit support for
> in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have
> a flags field yet, so we have to extend the structure and trust that
Hi Philipp,
thanks for the patch!
On 17 March 2017 at 22:04, Philipp Zabel wrote:
> Add a helper to check if all fences in a fence array are from a given
> context. For convenience, the function can also handle being given a
> non-array fence.
>
> Signed-off-by: Philipp Zabel
> ---
Looks good
On 03/10/2017 12:53 AM, Sumit Semwal wrote:
> Hi Laura,
>
> Thanks for the patch.
>
> On 3 March 2017 at 03:14, Laura Abbott wrote:
>>
>> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
>> useful to have an explicit name attached to each region. Store the name
>> in each
Hi Philipp,
2017-03-17 Philipp Zabel :
> Loosely based on commit f0a42bb5423a ("drm/msm: submit support for
> in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have
> a flags field yet, so we have to extend the structure and trust that
> drm_ioctl will clear the flags for us if an
Hi Philipp,
2017-03-17 Philipp Zabel :
> Add a helper to check if all fences in a fence array are from a given
> context. For convenience, the function can also handle being given a
> non-array fence.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/dma-buf/dma-fence-array.c | 26 +
On Fri, Mar 17, 2017 at 05:57:52PM +0100, Daniel Vetter wrote:
> On Fri, Mar 17, 2017 at 01:08:43PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote:
> > > On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
> > > wrote:
> > > > On Fri, Mar 17, 2017 at 01:25:08P
Use platform_register_drivers instead of open coding the iteration over
component platform drivers in the vc4_drv module.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/vc4/vc4_drv.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4
Use platform_register_drivers instead of open coding the iteration over
component platform drivers in the mtk_drm_drv and mtk_hdmi modules.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 27 ---
drivers/gpu/drm/mediatek/mtk_hdmi.c| 27 --
On Fri, Mar 17, 2017 at 01:08:43PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote:
> > On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
> > wrote:
> > > On Fri, Mar 17, 2017 at 01:25:08PM +0530, Shirish S wrote:
> > >> update_plane() and disable_plane() funct
Op 16-03-17 om 21:15 schreef Daniel Vetter:
> On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst
> wrote:
>> Op 16-03-17 om 16:52 schreef Daniel Vetter:
>>> The vblank code really wants to look at crtc->state without having to
>>> take a ww_mutex. One option might be to take one of the vblank lock
Add a helper to check if all fences in a fence array are from a given
context. For convenience, the function can also handle being given a
non-array fence.
Signed-off-by: Philipp Zabel
---
drivers/dma-buf/dma-fence-array.c | 26 ++
include/linux/dma-fence-array.h | 2 +
Based on commit 4cd0945901a6 ("drm/msm: submit support for out-fences").
We increment the minor driver version so userspace can detect explicit
fence support.
Signed-off-by: Philipp Zabel
Reviewed-by: Gustavo Padovan
---
v2: Dropped unnecessary braces
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c
Loosely based on commit f0a42bb5423a ("drm/msm: submit support for
in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have
a flags field yet, so we have to extend the structure and trust that
drm_ioctl will clear the flags for us if an older userspace only submits
part of the struct.
The next patch will need the dma_fence to create the sync_file in
etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested.
Signed-off-by: Philipp Zabel
Reviewed-by: Gustavo Padovan
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |
On 03/16/2017 06:01 PM, Archit Taneja wrote:
>
>
> On 3/7/2017 10:12 PM, Neil Armstrong wrote:
>> Add documentation for added Bus Formats to describe RGB and YUS formats used
>
> s/YUS/YUV
Thanks again
>
>> as input to the Synopsys DesignWare HDMI TX Controller.
>>
>> Signed-off-by: Neil
On 03/16/2017 06:06 PM, Archit Taneja wrote:
>
>
> On 3/7/2017 10:12 PM, Neil Armstrong wrote:
>> In order to describe the RGB and YUB bus formats used to feed the
>
> s/YUB/YUV
Thanks for pointing me this !
Neil
>
>> Synopsys DesignWare HDMI TX Controller, add missing formats to the
>> list
https://bugs.freedesktop.org/show_bug.cgi?id=100258
Tomi Sarvela changed:
What|Removed |Added
OS|All |Linux (All)
QA Contact|
https://bugs.freedesktop.org/show_bug.cgi?id=100258
Bug ID: 100258
Summary: [BAT][SKL] Serial console hung in kms_flip when
running IGT
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Statu
> @@ -264,8 +267,10 @@ int omap_drm_irq_install(struct drm_device *dev)
> priv->irq_mask |= omap_underflow_irqs[i];
> }
>
> - for (i = 0; i < num_mgrs; ++i)
> + for (i = 0; i < num_mgrs; ++i) {
> priv->irq_mask |= dispc_mgr_get_sync_lost_irq(i);
>
On Sun 2017-03-05 01:43:00, Sebastian Reichel wrote:
> From: Tony Lindgren
>
> Things are a bit whacked right now for panel-dsi-cm:
>
> 1. We're missing call to of_get_display_timing() and
>videomode_from_timing()
>
> 2. We need to call dsicm_probe_of() after we initialize the
>default
Hi!
> The N950's display requires two regulators.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 55
> +++--
> 1 file changed, 52 insertions(+), 3 deletions(-)
> @@ -590,25 +594,43 @@ static int dsicm_power_on(struct panel_dr
Am Freitag, den 17.03.2017, 14:42 + schrieb Russell King - ARM
Linux:
> On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote:
> > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
> > > Hi Gustavo,
> > >
> > > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> >
From: Colin Ian King
The outer loop is redundant and can be removed as it is doing nothing
useful. Also remove some commented out code that is not being used.
Detected by CoverityScan, CID#1402073
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 27 +++
Am Freitag, den 17.03.2017, 15:09 +0100 schrieb Philipp Zabel:
> On Fri, 2017-03-17 at 10:55 -0300, Gustavo Padovan wrote:
> > 2017-03-16 Rob Clark :
> >
> > > On Wed, Mar 8, 2017 at 9:37 AM, Gustavo Padovan
> > > wrote:
> > > >> diff --git a/include/uapi/drm/etnaviv_drm.h
> > > >> b/include/ua
On Thu, Mar 16, 2017 at 6:08 PM, Sean Paul wrote:
> This series pulls out the power-sequencing code from panel-simple into a
> panel-common helper library. This allows drivers that cannot leverage
> panel-simple to share some code.
>
> I've converted the 2 sharp mipi drivers, and Chris Zhong's dri
Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel:
> Hi Gustavo,
>
> On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> [...]
> > I was thinking on some function that would iterate over all fences in
> > the fence_array and check their context. The if we find our own gpu
>
On Fri, Mar 17, 2017 at 10:33:15AM +, Brian Starkey wrote:
> Hi Ville,
>
> On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
> >> On 3/16/2017 5:55 PM, Brian Starkey wrote:
> >> > On Thu, Mar 16, 2017 at 05:14:07
On Fri, 2017-03-17 at 10:55 -0300, Gustavo Padovan wrote:
> 2017-03-16 Rob Clark :
>
> > On Wed, Mar 8, 2017 at 9:37 AM, Gustavo Padovan wrote:
> > >> diff --git a/include/uapi/drm/etnaviv_drm.h
> > >> b/include/uapi/drm/etnaviv_drm.h
> > >> index 2584c1cca42f6..e9c388a1d8ebe 100644
> > >> --- a
On Fri, 2017-03-17 at 11:00 -0300, Gustavo Padovan wrote:
> 2017-03-16 Philipp Zabel :
>
> > Hi Gustavo,
> >
> > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> > [...]
> > > I was thinking on some function that would iterate over all fences in
> > > the fence_array and check their co
2017-03-16 Philipp Zabel :
> Hi Gustavo,
>
> On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote:
> [...]
> > I was thinking on some function that would iterate over all fences in
> > the fence_array and check their context. The if we find our own gpu
> > context in there we fail the submit.
2017-03-16 Rob Clark :
> On Wed, Mar 8, 2017 at 9:37 AM, Gustavo Padovan wrote:
> >> diff --git a/include/uapi/drm/etnaviv_drm.h
> >> b/include/uapi/drm/etnaviv_drm.h
> >> index 2584c1cca42f6..e9c388a1d8ebe 100644
> >> --- a/include/uapi/drm/etnaviv_drm.h
> >> +++ b/include/uapi/drm/etnaviv_drm.
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #10 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
The issue became even more prevelant when upgrading from kernel 4.10.2 to
4.10.3.
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=100242
--- Comment #4 from Christian König ---
The maximum size for allocations in VRAM on radeon are usually 256MB minus
pinned system resources like GART.
The game tries to allocate something which is 256MB in size, so that won't fit.
Either the dr
https://bugs.freedesktop.org/show_bug.cgi?id=100242
--- Comment #3 from tnmailingli...@gmail.com ---
I retested the game with mesa 12.0.6 and xserver-xorg-video-radeon 1:7.7.1 (the
current versions for default Lubuntu 16.10) and noticed that while the game
doesn't crash, it still produces buffer a
On Fri, Mar 17, 2017 at 10:19:51AM +, Chris Wilson wrote:
> On Fri, Mar 17, 2017 at 11:47:51AM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 16, 2017 at 11:47:48PM +, Chris Wilson wrote:
> > > @@ -360,7 +358,7 @@ static void vblank_disable_fn(unsigned long arg)
> > > unsigned long irqflags;
On Fri, Mar 17, 2017 at 07:19:27PM +0900, Michel Dänzer wrote:
> On 17/03/17 07:01 PM, Ville Syrjälä wrote:
> > On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote:
> >> On 16/03/17 07:09 PM, Ville Syrjälä wrote:
> >>> On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel Dänzer wrote:
>
On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote:
> On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
> wrote:
> > On Fri, Mar 17, 2017 at 01:25:08PM +0530, Shirish S wrote:
> >> update_plane() and disable_plane() functions
> >> assoiciated with setting plane are called
> >> without any chec
Hi Ville,
On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
On 3/16/2017 5:55 PM, Brian Starkey wrote:
> On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank wrote:
>> On 3/16/2017 4:37 PM, Local user for Liviu
On Fri, Mar 17, 2017 at 11:47:51AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 11:47:48PM +, Chris Wilson wrote:
> > @@ -360,7 +358,7 @@ static void vblank_disable_fn(unsigned long arg)
> > unsigned long irqflags;
> >
> > spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > -
On 17/03/17 07:01 PM, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote:
>> On 16/03/17 07:09 PM, Ville Syrjälä wrote:
>>> On Thu, Mar 16, 2017 at 06:55:53PM +0900, Michel Dänzer wrote:
From: Michel Dänzer
Otherwise this can also prevent modesets e
On Thu, Mar 16, 2017 at 07:36:56PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 07:05:12PM +0200, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/16/2017 5:55 PM, Brian Starkey wrote:
> > > Hi,
> > >
> > > On Thu, Mar 16, 2017 at 05:14:07PM +0200, Sharma Shashank w
On Fri, Mar 17, 2017 at 3:26 PM, Ville Syrjälä
wrote:
> On Fri, Mar 17, 2017 at 01:25:08PM +0530, Shirish S wrote:
>> update_plane() and disable_plane() functions
>> assoiciated with setting plane are called
>> without any check, causing kernel panic.
>
> Why are you registering a plane without th
On 03/16/2017 10:57 PM, Dylan Baker wrote:
> Quoting Ilia Mirkin (2017-03-16 14:32:09)
>> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote:
>>> Why bother, and why would we want this?
>>> │~
>>>
>>> First it's written in python, which
1 - 100 of 109 matches
Mail list logo
