On 06/24/2017 03:20 AM, Eric Anholt wrote:
Boris Brezillon writes:
On Thu, 22 Jun 2017 13:47:43 +0530
Archit Taneja wrote:
On 06/22/2017 01:20 PM, Benjamin Gaignard wrote:
2017-06-20 19:31 GMT+02:00 Eric Anholt :
Archit Taneja writes:
On 06/16/2017 08:13 PM, Eric Anholt wrote:
Arc
Dave,
A single important fix for a context creation memory leak.
The following changes since commit 1929e6610bddf0cc44f0859fc72d4016cba0c1fa:
drm/vmwgfx: Bump driver minor and date (2017-06-07 14:46:15 +0200)
are available in the git repository at:
git://people.freedesktop.org/~thomash/lin
Hi Hans,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12-rc7 next-20170626]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/staging-vboxvideo-Add
On Mon, Jun 26, 2017 at 06:38:29PM +0900, Michel Dänzer wrote:
> On 24/06/17 02:39 AM, John Brooks wrote:
> > There is no need for page faults to force BOs into visible VRAM if it's
> > full, and the time it takes to do so is great enough to cause noticeable
> > stuttering. Add GTT as a possible pl
On 27/06/17 11:58 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This syncs the amdgpu_drm header with my drm-next branch as of
> 6d61e70ccc21606ffb8a0a03bd3aba24f659502b.
>
> It brings over the VM and semaphore API changes.
>
> Generated using make headers_install.
> Generated from git://peopl
Ignore this, all kinds of patches from wrong tree stuff going on here.
Dave.
On 27 June 2017 at 07:19, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds the corresponding code for libdrm to use the new
> kernel interfaces for semaphores.
>
> This will be used by radv to implement shared sema
From: Dave Airlie
This syncs the amdgpu_drm header with my drm-next branch as of
6d61e70ccc21606ffb8a0a03bd3aba24f659502b.
It brings over the VM and semaphore API changes.
Generated using make headers_install.
Generated from git://people.freedesktop.org/~airlied/linux drm-next commit
6d61e70cc
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/display/panel/samsung,s6e63j0x03.txt | 24 ++
1 file changed, 24 insertions(+)
create
The display-timing and delay are included in the panel driver. So it
should be removed in dts.
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/bo
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun
Hi all,
The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).
Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explici
Tomi,
* Tomi Valkeinen [170428 04:15]:
> On 14/04/17 13:25, Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > The CEC pin was always pulled up, making it impossible to use it.
...
> Tony, can you queue this? It's safe to apply separately from the rest of
> the HDMI CEC work.
So the dts chang
Hi Jyri,
Thanks for the ack. However, I'm reworking this patch set to use the
include/linux/io-64-nonatomic* headers which will explicitly devolve
into two 32-bit transfers. It's not clear whether this is appropriate
for the tilcdc driver as it was never setup to use 32-bit transfers
(unlike the o
On 6/26/2017 2:43 PM, Arnd Bergmann wrote:
This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.
I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the s
On Tue 20-06-17 11:25:24, Daniel Vetter wrote:
> On Tue, Jun 20, 2017 at 11:22:06AM +0200, Lucas Stach wrote:
> > Am Dienstag, den 20.06.2017, 11:06 +0200 schrieb Daniel Vetter:
> > > On Tue, Jun 06, 2017 at 09:17:06AM +0200, Lucas Stach wrote:
> > > > GPU buffers can be quite large, so userspace i
After detecting an IRQ storm, hotplug detection will switch from
irq-based detection to poll-based detection. After a short delay or
when resetting storm detection from debugfs, detection will switch
back to being irq-based.
However, it may occur that polling does not have enough time to detect
th
On 2017-06-26 11:35, Daniel Vetter wrote:
> On Thu, Jun 22, 2017 at 08:06:23AM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts sho
On 06/26/2017 02:47 AM, Christoph Hellwig wrote:
On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:
I think we still need to do it. For example we have a bunch new "funky"
cases.
I have no plan to do away with the selection - I just want a better
interface than the curre
https://bugs.freedesktop.org/show_bug.cgi?id=93715
--- Comment #5 from Dieter Nützel ---
Yes,
it works correctly with current mesa-git and a RX580 (Polaris 20), now.
Hello Gert,
will try with my old 6670 HD (Turks XT) when I find more time to switch it back
in.
But good progress so far.
--
Y
On Mon, Jun 26, 2017 at 11:27 AM, Michel Dänzer wrote:
> On 25/06/17 03:00 AM, Christian König wrote:
>> Am 23.06.2017 um 19:39 schrieb John Brooks:
>>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by
>>> userspace,
>>> it should only be treated as a hint to initially place a BO so
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #3 from Sebastian Parborg ---
I've narrowed it down to this commit:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=56a28ace35c513ba22d754192127c359c28ed7e5
It seems like that is the one that breaks it.
--
You are receiving this
On Mon, Jun 26, 2017 at 06:44:30PM +0900, Michel Dänzer wrote:
> On 24/06/17 02:39 AM, John Brooks wrote:
> > The BO move throttling code is designed to allow VRAM to fill quickly if it
> > is relatively empty. However, this does not take into account situations
> > where the visible VRAM is smalle
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Ricardo changed:
What|Removed |Added
Assignee|humberto.i.perez.rodriguez@ |dri-devel@lists.freedesktop
From: Dave Airlie
This adds the corresponding code for libdrm to use the new
kernel interfaces for semaphores.
This will be used by radv to implement shared semaphores.
TODO: Version checks.
Signed-off-by: Dave Airlie
---
amdgpu/amdgpu.h | 28 +
amdgpu/amdgpu_cs.c | 1
ping?
Dave.
On 17 June 2017 at 11:06, Dave Airlie wrote:
> From: Dave Airlie
>
> These ioctls are now in drm next so add the first set of libdrm APIs.
>
> Signed-off-by: Dave Airlie
> ---
> include/drm/drm.h | 26 ++
> xf86drm.c | 81
>
> +u64 ioread64(void __iomem *addr)
> +{
> + u64 low, high;
> +
> + low = ioread32(addr);
> + high = ioread32(addr + sizeof(u32));
> + return low | (high << 32);
> +}
> +u64 ioread64be(void __iomem *addr)
> +{
> + u64 low, high;
> +
> + low = ioread32be(addr + si
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #10 from Julien Isorce ---
It could be that drm.debug=0x01 will tell you if the error comes from one of
the two "case:" here
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/drm_plane.c?h=amd-staging-4.9#n796
.
If it is
From: Deepak Rawat
The hash table created during vmw_cmdbuf_res_man_create was
never freed. This causes memory leak in context creation.
Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.
Tested for memory leak by running piglit overnight and kernel
memory is not inflated which
>
> I'm traveling and cannot make progress this week. The merge window is
> also real close so this series will therefore probably miss it unless
> something unexpected happens...
Don't worry you missed the merge window for drm already, we don't merge
things after -rc6. Please remember the Linus m
On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> Problem : While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immediately following an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to th
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #9 from omegap...@startmail.com ---
As nothings happened on this ticket for a few months, I've reached the task
again. I can confirm DisplayPort-0 remains connected according to xrandr when
its off, prior to the problem happening.
I'
Hi Laurent,
On Wed, Jun 21, 2017 at 11:04 AM, Laurent Pinchart
wrote:
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -158,6 +157,11 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc
> *rcrtc,
> best_diff);
> }
>
> +stati
On Sat, Jun 24, 2017 at 04:10:54PM +1000, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
> adapter
On R-Car H3 ES2.0, DU channels 0 and 3 are served by two separate
pipelines from the same VSP. Support this in the DU driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 3 ++
drivers/gpu/drm/rcar-du/rcar_du_kms.c
The sink pointer is used to configure routing inside the VSP, and as
such must point to the next VSP entity in the pipeline. The WPF being a
pipeline terminal sink, its output route can't be configured. The
routing configuration code already handles this correctly without
referring to the sink poin
When the VSP1 is used in a DRM pipeline the driver doesn't register the
media device. Links between entities are not exposed to userspace, but
are still used internally for the sole purpose of setting up internal
source to sink pointers through the link setup handler.
Instead of going through this
On Gen3 SoCs DPAD0 routing is configured through the last CRTC group,
unlike on Gen2 where it is configured through the first CRTC group. Fix
the driver accordingly.
Fixes: 2427b3037710 ("drm: rcar-du: Add R8A7795 device support")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_
In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU
channels that need to be configured independently. Extend the VSP-DU API
with a pipeline index to identify which pipeline the caller wants to
operate on.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c
The R-Car H3 ES2.0 VSP-DL instance has two LIF entities and can drive
two display pipelines at the same time. Refactor the VSP DRM code to
support that by introducing a vsp_drm_pipeline object that models one
display pipeline.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_
The H3 ES1.x exhibits dot clock duty cycle stability issues. We can work
around them by configuring the DPLL to twice the desired frequency,
coupled with a /2 post-divider. This isn't needed on other SoCs and
breaks HDMI output on M3-W for a currently unknown reason, so restrict
the workaround to H
The VSP supports both header and headerless display lists. The latter is
easier to use when the VSP feeds data directly to the DU in continuous
mode, and the driver thus uses headerless display lists for DU operation
and header display lists otherwise.
Headerless display lists are only available o
New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL,
as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for
them in the VSP device info table.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drv.c | 24
drivers/
The VSP2-DL instance (present in the H3 ES2.0 and M3-N SoCs) has two LIF
instances. Adapt the driver infrastructure to support multiple LIFs.
Support for multiple display pipelines will be added separately.
The change to the entity routing table removes the ability to connect
the LIF output to the
The Blend/ROP Sub Unit (BRS) is a stripped-down version of the BRU found
in several VSP2 instances. Compared to a regular BRU, it supports two
inputs only, and thus has no ROP unit.
Add support for the BRS by modeling it as a new entity type, but reuse
the vsp1_bru object underneath. Chaining the
The internal VSP entity source and sink pointers are stored as
media_entity pointers, which are then cast to a vsp1_entity. As all
sources and sinks are vsp1_entity instances, we can store the
vsp1_entity pointers directly.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm
When the display start interrupt occurs, we know that the hardware has
finished loading the active display list. The driver then proceeds to
recycle the list, assuming it won't be needed anymore.
This assumption holds true for headerless display lists, as the VSP
doesn't reload the list for the ne
2.0 Salvator-X: Enable DU support in DT"
patch series
For convenience, a branch merging this series with all dependencies is
available from
git://linuxtv.org/pinchartl/media.git drm/next/h3-es2/merged
with the DT and driver series split in two branches respectively tagged
drm-h3-es2-
The display list headers are filled using information from the display
list only. Lower the display list manager spinlock contention by filling
the headers without holding the lock.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_dl.c | 6 --
1 file changed, 4 insertions
https://bugs.freedesktop.org/show_bug.cgi?id=100393
--- Comment #10 from Giovanni ongaro ---
Mika your last patch works even for cemu 1.8.0 i have only one question when is
the VENDOR override worth and what are you forcing as vendor and render?
--
You are receiving this mail because:
You are t
On 06/23/2017 11:25 PM, Rob Herring wrote:
> On Mon, Jun 19, 2017 at 06:28:01PM +0200, Philippe CORNU wrote:
>> This patch adds documentation of device tree bindings for the
>> Synopsys DesignWare MIPI DSI host DRM bridge driver.
>
> You missed Archit's comment on v3. Bindings are for h/w, not d
On Tue, Jun 13, 2017 at 5:05 PM, Mark Brown wrote:
> On Tue, Jun 13, 2017 at 02:59:49PM -0700, John Stultz wrote:
>> ALSA SoC needs to know connected DAI ID for probing. Using
>> the new audio-card-graph approach, ports/endpoints are used
>> to describe how the links are connected. Unfortunately,
Hi,
On 26-06-17 18:24, Daniel Vetter wrote:
On Mon, Jun 26, 2017 at 06:06:19PM +0200, Hans de Goede wrote:
Hi,
On 23-06-17 11:31, Daniel Vetter wrote:
On Thu, Jun 22, 2017 at 11:11:37AM +0200, Hans de Goede wrote:
This commit adds the vboxvideo drm/kms driver for the virtual graphics
card us
There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
calling drm_crtc_vblank_off(), which is best done by shutting down
the entire display engine with drm_atomic_helper_shutdown.
- Releasing
Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
disabling the dsiplay at least in most cases. So drop the
drm_vblank_cleanup code since it's not really doing anything, it looks
all cargo-culted.
v2: Appease gcc be
On Wed, Jun 21, 2017 at 12:31:27PM +0300, Laurent Pinchart wrote:
> The M3-W HDMI TX controller seems to be compatible for the H3. No
> extension to the DT bindings are needed, add an SoC-specific compatible
> string in case differences between the IP versions are found later and
> require model-sp
Hi,
On 22-06-17 14:03, Dan Carpenter wrote:
> This is obviously much better and easier to review. I ended up
> reviewing it like I would normal code instead of staging code. My main
> thing is could you please re-write the module init error handling so
> that each function does its own error ha
On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.
This patch causes a regression
Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> We increment the minor driver version so userspace can detect perfmon
> support.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
> 1 file changed, 1 inserti
Please add a short description, stating that the perfmon registers are
debug regs.
Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 ++
> 1 file changed, 10
Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> As done by Vivante kernel driver.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=99349
--- Comment #15 from Elia Argentieri ---
Now it works! I also had to set MESA_GLSL_CACHE_DISABLE to make it work, maybe
it was picking the old shader. Thank you very much.
--
You are receiving this mail because:
You are the assignee for the bug
Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> With 'sync points' we can sample the reqeustes perform signals
> before and/or after the submited command buffer.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 112
> ++
Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> Results in less code as there is no need to set every struct
> member to 0/NULL.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
> 1 file changed, 1 inserti
Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> In order to support performance counters in a sane way we need to
> provide
> a method to sync the GPU with the CPU. The GPU can process multpile
> command
> buffers/events per irq. With the help of a 'sync point' we can
> trigger
Am 23.06.2017 um 19:05 schrieb Alex Deucher:
On Fri, Jun 23, 2017 at 12:43 PM, Christian König
wrote:
Am 23.06.2017 um 18:34 schrieb Alex Deucher:
From: Vijendar Mukunda
asic_type information is passed to ACP DMA Driver as platform data.
We need this to determine whether the asic is Carrizo
Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> All performance monitor requests will be validated during this phase.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 68
> +++-
> 1 file changed, 66 insertion
Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> Check if the selected domain and signal combination exists.
>
> Signed-off-by: Christian Gmeiner
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 15 +++
> drivers/gpu/drm/etnaviv/etna
Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number
> of struct etnaviv_perfmon elements gets stored.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 13 -
Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> Sadly we can not read any registers via command stream so we need
> to extend the drm_etnaviv_gem_submit struct with performance monitor
> requests. Those requests gets process before and/or after the actual
> submitted command st
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #2 from Vedran Miletić ---
Michel, I missed this reply, sorry! I will test ASAP.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
With the below fixed,
Reviewed-by: Thomas Hellstrom
On 06/23/2017 04:10 PM, Sean Paul wrote:
On Wed, Jun 21, 2017 at 10:28:48AM +0200, Daniel Vetter wrote:
Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
dis
https://bugs.freedesktop.org/show_bug.cgi?id=98238
Gregor Münch changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #68 from siyia (eutychio...@gmail.com) ---
Probably some mistake in the documentation, otherwise i doesnt make sense,
unless the use some magic lol, by the way with kernel 4.11.6 the problem got
worse, now also the desktop enviroment i
Hi, Daniel,
On 06/21/2017 03:30 PM, Daniel Vetter wrote:
On Thu, Apr 6, 2017 at 10:02 PM, Daniel Vetter wrote:
Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Sebastian Parborg changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|A
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #2 from Sebastian Parborg ---
Created attachment 132253
--> https://bugs.freedesktop.org/attachment.cgi?id=132253&action=edit
blender after matcap
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Bug ID: 101596
Summary: Blender renders black UI elements
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Prior
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #1 from Sebastian Parborg ---
Created attachment 132252
--> https://bugs.freedesktop.org/attachment.cgi?id=132252&action=edit
Blender before matcap
--
You are receiving this mail because:
You are the assignee for the bug.
On 23 June 2017 at 17:45, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
> - Add LINEAR and Yf modifiers to list (Ville)
> - Combine i8xx and i965 into one list of formats (
On Wed, 2017-06-21 at 21:19 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote:
> > On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
> > > This patch checks encoder level support for HDMI YCBCR outputs.
> > > HDMI output m
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #14 from Luke A. Guest ---
Added https://bugs.freedesktop.org/show_bug.cgi?id=101594
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=101594
Bug ID: 101594
Summary: Blender doesn't detect OpenCL with Clover
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Am 23.06.2017 um 19:39 schrieb John Brooks:
Allow specifying a limit on visible VRAM via a module parameter. This is
helpful for testing performance under visible VRAM pressure.
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dr
https://bugs.freedesktop.org/show_bug.cgi?id=99553
--- Comment #13 from Luke A. Guest ---
Doesn't seem to be.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
On Thu, Jun 08, 2017 at 05:14:35PM +0200, Noralf Trønnes wrote:
> This adds support for the Pervasive Displays RePaper branded displays.
> The controller code is taken from the userspace driver available
> through repaper.org. Only the V231 film is supported since the others
> are EOL.
>
> Signed-
On 24/06/17 02:39 AM, John Brooks wrote:
> Allow specifying a limit on visible VRAM via a module parameter. This is
> helpful for testing performance under visible VRAM pressure.
>
> Signed-off-by: John Brooks
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:
> I think we still need to do it. For example we have a bunch new "funky"
> cases.
I have no plan to do away with the selection - I just want a better
interface than the current one.
___
keep cu_ao_mask unchanged for backward compatibility.
Change-Id: I9f497aadd309977468e246fea333b392c0150276
Signed-off-by: Flora Cui
---
This patch should be landed after the kmd patch upsteam. right?
amdgpu/amdgpu.h | 2 ++
amdgpu/amdgpu_gpu_info.c | 1 +
include/drm/amdgpu_drm.h | 3 ++
On 24/06/17 02:39 AM, John Brooks wrote:
> The BO move throttling code is designed to allow VRAM to fill quickly if it
> is relatively empty. However, this does not take into account situations
> where the visible VRAM is smaller than total VRAM, and total VRAM may not
> be close to full but the vi
On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes wrote:
> Drm has no monochrome or greyscale support so add a conversion
> from the common format XR24.
>
> Also reorder includes into the common order.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/tinydrm/core/tinydrm-helpers
On 24/06/17 02:39 AM, John Brooks wrote:
> There is no need for page faults to force BOs into visible VRAM if it's
> full, and the time it takes to do so is great enough to cause noticeable
> stuttering. Add GTT as a possible placement so that if visible VRAM is
> full, page faults move BOs to GTT
On Thu, Jun 22, 2017 at 08:06:23AM +0200, Peter Rosin wrote:
> Hi!
>
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt
On Thu, Jun 22, 2017 at 12:22:10PM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_fb_helper.c | 151
> +---
> 1 file changed,
On Thu, Jun 22, 2017 at 08:06:24AM +0200, Peter Rosin wrote:
> I think the gamma_store can end up invalid on error. But the way I read
> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> this pesky legacy fbdev stuff be any better?
>
> Signed-off-by: Peter Rosin
> ---
> dr
On 25/06/17 03:00 AM, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by
>> userspace,
>> it should only be treated as a hint to initially place a BO somewhere CPU
>> accessible, rather than having a permanent effe
Op 14-06-17 om 15:44 schreef Ville Syrjälä:
> On Wed, Jun 14, 2017 at 11:08:42AM +0200, Maarten Lankhorst wrote:
>> The nonblocking modeset tests were failing on systems with a DP output,
>> because lijnk training could occur during the modeset.
>>
>> With normal modesets we're protected by the con
On Thu, Jun 22, 2017 at 08:06:26AM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_fb_helper.c | 154
>
> 1 file changed,
On Thu, Jun 22, 2017 at 08:06:25AM +0200, Peter Rosin wrote:
> drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is
> now always kept up to date by drm_fb_helper_setcmap.
>
> Signed-off-by: Peter Rosin
Also note that this is for kgdb support only and so likely very buggy
(since n
On Fri, Jun 23, 2017 at 02:00:13PM -0600, Jonathan Corbet wrote:
> The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
> using "+" signs where "|" needs to be. That, in turn, causes the PDF build
> to fail.
>
> Fixes: def23aa7e9821a3dfe3fb7b139dd0229a89fdeb0
I fixed the c
https://bugs.freedesktop.org/show_bug.cgi?id=101484
--- Comment #11 from Michel Dänzer ---
It could be either a compiler bug, or a Mesa bug which only manifests itself
with certain compiler options.
--
You are receiving this mail because:
You are the assignee for the bug.___
1 - 100 of 111 matches
Mail list logo
