An early iteration for refactoring the RCAR-DU so that the group and CRTC state
is only changed during rcar_du_atomic_commit_tail.
Currnently, various parts of the group and crtc are adjusted and state is
stored globaly. Introduce a private object state for the groups so that we can
track per-stat
The rcar_du_crtc functions have a heavy reliance on the rcar_du_group
structure, in many cases just to access the DU device context.
To better separate the groups out of the CRTC handling code, give the
rcar_du_crtc its own pointer to the device and remove the indirection
through the group pointer
The group can now be handled independently from the CRTC tracking its
own state.
Introduce an rcar_du_group_atomic_check() call which will iterate the
CRTCs to determine the per-state use-count of the group.
This use count then allows us to determine if the group should be
configured or disabled
Refactoring of the group control code will soon require more iteration
over the available groups. Simplify this process by introducing a group
iteration helper.
Signed-off-by: Kieran Bingham
---
I'm not yet sure if the second patch which utilises this helper will make it to
the final cut.
Will
On 03/11, Ville Syrjälä wrote:
> On Sun, Mar 10, 2019 at 05:35:05PM -0300, Rodrigo Siqueira wrote:
> > On 03/01, Ville Syrjälä wrote:
> > > On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> > > > Em sex, 1 de mar de 2019 às 12:26, Ville Syrjälä
> > > > escreveu:
> > > > >
> > > > >
https://bugs.freedesktop.org/show_bug.cgi?id=110130
Bug ID: 110130
Summary: ring gfx timeout when playing warcraft 3
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Fri, Mar 15, 2019 at 06:22:44PM +0800, Chen-Yu Tsai wrote:
> On Fri, Mar 15, 2019 at 5:16 PM Maxime Ripard
> wrote:
> >
> > On Fri, Mar 15, 2019 at 05:09:22PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Mar 15, 2019 at 5:02 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, Mar 15, 2019 at 1
On 15/03/2019 13:30, Peter Ujfalusi wrote:
>
>
> On 28/02/2019 12.31, Tomi Valkeinen wrote:
>> On 28/02/2019 12:27, Tomi Valkeinen wrote:
>>> Hi Laurent,
>>>
>>> On 11/02/2019 11:46, Laurent Pinchart wrote:
>>>
+ /* Get the sampling edge from the endpoint. */
+ of_property_read_u32(ep
From: Christian König
Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.
v2: rebase and cleanup
v3: fix garbage collection parameters
v4: add unorder point check, print a warn calltrace
Signed-off-by: Christian König
---
drivers/
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAI
From: Christian König
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's no
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8a0732088640..4d8db87048d3 100644
--- a/drivers/gpu/drm/amd/amdgp
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check
Signed-off-by: Chunming Zhou
Cc: Daniel Rakos
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
v4: add timeout for find fence
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal
operation,
so add check condition for that.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_
we need to import/export timeline point.
v2: unify to one transfer ioctl
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 74 ++
include/uapi/drm/drm.h | 10 +++
syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
v3: fix checking for timeline syncobj
Signed-off-by: Chunming Zhou
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Christian König
Cc: Chris Wilson
On 15/03/2019 14.07, Tomi Valkeinen wrote:
>> If the pclk-sample is not defined in DT, it will default to 0 which
>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
>>
>> But all the boards where I can find schematics with tfp410 have their
>> EDGE/HTPLG pin pulled up and according to the documen
https://bugs.freedesktop.org/show_bug.cgi?id=110117
--- Comment #1 from Nicholas Kazlauskas ---
I don't see anything immediately wrong in the log at the first glance at least
so it'd be helpful if you could post your dmesg log from after the problem
occurred with drm.debug=4 in your kernel boot p
https://bugs.freedesktop.org/show_bug.cgi?id=108493
Timur Kristóf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Register cpufreq notifier after we have initialized the crtc and
unregister it before we remove the ctrc. Receiving a cpufreq notify
without crtc causes a crash.
Reported-by: Peter Ujfalusi
Signed-off-by: Jyri Sarha
---
Couple of minor changes:
- Add forgotten Reported-by:
- While moving cpufreq
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #20 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Not every user will want the same scaling parameters for non-native signals.
The display itself will often offer a configurable mode itself for its scaler
for this reason.
This series support Chipone ICN6211 DSI/RGB bridge support.
This ICN6211 bridge is taking flexible configuration of MIPI DSI
signal input and produce RGB565, RGB666, RGB888 output format
and it is present in the Bananapi s070wv20-ct16 panel.
Initially similar support is written as dsi panel driv
Export drm_bridge_detach from drm bridge core so-that it
can use on respective interface or bridge driver while
detaching the bridge.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/drm_bridge.c | 1 +
include/drm/drm_bridge.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/d
Some display panels would come up with a non-DSI output which
can have an option to connect DSI interface by means of bridge
convertor.
This DSI to non-DSI bridge convertor would require a bridge
driver that would communicate the DSI controller for bridge
functionalities.
So, add support for brid
drm_bridge_detach now available to use while detaching
bridge, use this core wrapper instead of explicitly
pointing the bridge funcs.
Cc: Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 3 +--
1 file changed,
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add bridge driver for it.
Signed-off-by: Jagan Teki
---
MAINTAINERS | 6 +
drivers/gpu/drm/bridge/Kcon
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211 DSI/RGB
convertor bridge, so enable bridge along with associated panel.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- PD6 gpio fo
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
---
.../display/bridge/chipone,icn6211.txt| 36 +++
1 file
On Fri, Mar 15, 2019 at 06:38:25PM +0530, Jagan Teki wrote:
> This patch add support for Bananapi S070WV20-CT16 DSI panel to
> BPI-M64 board.
>
> Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211 DSI/RGB
> convertor bridge, so enable bridge along with associated panel.
>
> DSI panel
Hi Jakan,
On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> Export drm_bridge_detach from drm bridge core so-that it
> can use on respective interface or bridge driver while
> detaching the bridge.
I don't see why this change is required based on the commit log. The
DRM bridge code clearly i
On 15/03/2019 14:28, Peter Ujfalusi wrote:
> On 15/03/2019 14.07, Tomi Valkeinen wrote:
>>> If the pclk-sample is not defined in DT, it will default to 0 which
>>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
>>>
>>> But all the boards where I can find schematics with tfp410 have their
>>> EDG
On Fri, Mar 15, 2019 at 06:38:24PM +0530, Jagan Teki wrote:
> ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> It has a flexible configuration of MIPI DSI signal input
> and produce RGB565, RGB666, RGB888 output format.
>
> Add bridge driver for it.
>
> Signed-off-by: Jagan Teki
> ---
>
Hi,
On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output which
> can have an option to connect DSI interface by means of bridge
> convertor.
>
> This DSI to non-DSI bridge convertor would require a bridge
> driver that would communicate th
On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote:
> ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> It has a flexible configuration of MIPI DSI signal input
> and produce RGB565, RGB666, RGB888 output format.
>
> Add dt-bingings for it.
>
> Signed-off-by: Jagan Teki
> ---
> .
Daniel Vetter wrote on Fri [2019-Mar-15 11:50:57 +0100]:
> On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> > During a suspend cycle the atomic state is saved to be used during the
> > restore cycle.
> >
> > However the current state duplication logic does not duplicate private
>
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #21 from thomas.lassdiesonner...@gmx.de ---
Ok thanks again. You can close this as "won't fix" then.
My last and final question. Why does the old code (kernel 4.14) work?
--
You are receiving this mail because:
You are watching the
On Fri, Mar 15, 2019 at 02:32:55PM +0100, Paul Kocialkowski wrote:
> Hi,
>
> On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> > Some display panels would come up with a non-DSI output which
> > can have an option to connect DSI interface by means of bridge
> > convertor.
> >
> > This DSI to
On Fri, Mar 15, 2019 at 08:51:57AM -0300, Rodrigo Siqueira wrote:
> On 03/11, Ville Syrjälä wrote:
> > On Sun, Mar 10, 2019 at 05:35:05PM -0300, Rodrigo Siqueira wrote:
> > > On 03/01, Ville Syrjälä wrote:
> > > > On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> > > > > Em sex, 1 d
Hi,
On Fri, 2019-03-15 at 14:45 +0100, Maxime Ripard wrote:
> On Fri, Mar 15, 2019 at 02:32:55PM +0100, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> > > Some display panels would come up with a non-DSI output which
> > > can have an option to con
This patchset adds :
- Optional reset properties in the midgard bindings
- Mali T820 Node in Amlogic Meson GXM DTSI
Changes since v1:
- Updated midgard DT wording following the recently submitted
bifrost bindings
Christian Hewitt (1):
arm64: dts: meson-gxm: Add Mali-T820 node
Neil Armstrong
From: Christian Hewitt
The Amlogic Meson GXM SoC embeds an ARM Mali T820 GPU.
This patch adds the node with all the needed properties to power
on the GPU.
This has been tested with the work-in-progress PanFrost project
aiming support for ARM Mali Midgard and later GPUs.
Signed-off-by: Christia
The Amlogic ARM Mali Midgard requires reset controls to power on and
software reset the GPU, adds these as optional in the bindings.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentat
On 15/03/2019 15.30, Tomi Valkeinen wrote:
> On 15/03/2019 14:28, Peter Ujfalusi wrote:
>> On 15/03/2019 14.07, Tomi Valkeinen wrote:
If the pclk-sample is not defined in DT, it will default to 0 which
selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
But all the boards where
Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
panel with resistive touch found on TI's AM335X-EVM.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
---
Changes since v5:
- Add all simple-panel properties that make sense with this panel to the
binding document
Previous
Den 15.03.2019 05.19, skrev Dave Airlie:
> Hey,
>
> Not sure how long this has been broken, considering plugging it in was
> broken, unplugging is much worse. Is there anything outside my tree
> that might be fixing this?
>
> Currently it appears if I unplug udl while userspace has the device
>
Den 15.03.2019 06.13, skrev Dave Airlie:
> From: Dave Airlie
>
> When we release the file handle on a device that has been unplugged
> it has already called the unregister path, which doesn't like being
> called again. We should just do the dev put version instead.
>
> This fixes some crashes
Den 15.03.2019 06.13, skrev Dave Airlie:
> From: Dave Airlie
>
> If we unplug a udl device, the usb callback with deinit the
> mode_config struct, however userspace will still have an open
> file descriptor and a framebuffer on that device. When userspace
> closes the fd, we'll oops because it'
On Fri, Mar 15, 2019 at 4:54 AM Neil Armstrong wrote:
>
> This patch is an attempt to limit HDMI 2.0 SCDC setup when :
> - the SoC embeds an HDMI 1.4 only controller
> - the EDID supports SCDC but not scrambling
> - the EDID supports SCDC scrambling but not for low TMDS bit rates,
> while only s
We have introduced some new formats DRM_FORMAT_VUY101010,
DRM_FORMAT_YUV420_8BIT,
and DRM_FORMAT_YUV420_10BIT whose cpp is 0 (as they are defined in bits per
pixel).
We need to ensure that the pitch returned by drm_format_info_min_pitch() for
such
formats is always 0.
Signed-off-by: Ayan Kumar
"Koenig, Christian" writes:
> Am 14.03.19 um 23:28 schrieb Eric Anholt:
>> Rob Herring writes:
>>
>>> On Thu, Mar 14, 2019 at 3:45 PM Dave Airlie wrote:
On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
wrote:
> Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
>
The function vkms_output_init() is invoked during the module
initialization, and it handles the creation/configuration of the vkms
essential elements (e.g., connectors, encoder, etc). Among the
initializations, this function tries to initialize a connector and
register it by calling drm_connector_r
Am 15.03.19 um 17:05 schrieb Eric Anholt:
> [SNIP]
> I think for lima not having this is fine, but for panfrost it really
> should have it.
>
> If you can implement vulkan you probably want this, nouveau hasn't a
> vulkan driver because of exactly this problem in their uapi, so
Since the binner buffer is only required for GPU rendering, it's a waste
to allocate it when the driver probes since internal users of the driver
(such as fbcon) won't try to use the GPU.
Move the allocation/liberation to the firstopen/lastclose to only
allocate it when userspace has opened the de
The binner BO is a pre-requisite to GPU operations, so we must ensure
that it is always allocated when the GPU is in use.
Because the buffer is allocated from the same pool as other GPU buffers,
we might run into a situation where we are out of memory at runtime
resume. This causes the binner BO a
The firstopen DRM driver hook was initially used to perform hardware
initialization, which is now considered legacy. Only a single user of
firstopen remains at this point (savage).
In some specific cases, non-legacy drivers may also need to implement
these hooks. For instance on VC4, we need to al
On 3/15/19 8:29 AM, Michel Dänzer wrote:
> On 2019-03-15 11:25 a.m., Boris Brezillon wrote:
>> On Fri, 15 Mar 2019 11:11:36 +0100
>> Michel Dänzer wrote:
>>
>>> On 2019-03-14 6:51 p.m., Helen Koike wrote:
On 3/14/19 6:15 AM, Michel Dänzer wrote:
> On 2019-03-13 7:08 p.m., Helen Koike
Provide helpers to allow CRTC configuration to be separated from the power
state handling. rcar_du_crtc_atomic_post_commit() is a no-op, but maintained
for API symmetry.
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 25 +++--
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 5 +
d
The DU processes the CRTC and group objects, with various operations storing
state of those objects globally, along with performing configuration operations
in the atomic_begin handlers.
This series aims to refactor the code to establish a private object for the
group state, and move all hardware
Refactoring of the group control code will soon require more iteration
over the available groups. Simplify this process by introducing a group
iteration helper.
Signed-off-by: Kieran Bingham
---
v2:
- no change
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 +
drivers/gpu/drm/rcar-du/rcar_du_k
Provide helpers to manage the power state, and initial configuration of
the CRTC.
rcar_du_crtc_get() and rcar_du_crtc_get() are no longer used, and are
removed, simplifying the implementation and removing the initialized
flag which was needed to track the state of the CRTC.
Signed-off-by: Kieran
The rcar_du_crtc functions have a heavy reliance on the rcar_du_group
structure, in many cases just to access the DU device context.
To better separate the groups out of the CRTC handling code, give the
rcar_du_crtc its own pointer to the device and remove the indirection
through the group pointer
Create a new private state object for the DU groups, and move the
initialisation of a group object to a new function rcar_du_group_init().
Signed-off-by: Kieran Bingham
---
v2:
- No change
drivers/gpu/drm/rcar-du/rcar_du_group.c | 81 +
drivers/gpu/drm/rcar-du/rcar_du_g
The group can now be handled independently from the CRTC tracking its
own state.
Introduce an rcar_du_group_atomic_check() call which will iterate the
CRTCs to determine the per-state use-count of the group.
This use count then allows us to determine if the group should be
configured or disabled
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #68 from bmil...@gmail.com ---
At this point we need at least a workaround. Add a runtime kernel parameter
that keeps memory clock maxed up always, even after sleep/wake and resolution
changes.
--
You are receiving this mail because
On Wed, Mar 13, 2019 at 02:05:28AM +0200, Laurent Pinchart wrote:
> As writeback jobs contain a framebuffer, drivers may need to prepare and
> cleanup them the same way they can prepare and cleanup framebuffers for
> planes. Add two new optional connector helper operations,
> .prepare_writeback_job
Hello to both of you, Tim and Mika,
sorry that I step in so late, but after I've read that Tim's laptop
didn't have PCIe atomics (is it realy PCIe 2.xx?) I have some hints,
too. Question: Is PCIe 3.xx+ needed together with Thunderbold 3 or is
PCIe 2.xx enaugth (like Tim's laptop)?
If Tim's l
As Mika said pci atomics have to be supported by the bridge for the
device to be able to use them.
Alex
On Fri, Mar 15, 2019 at 3:46 PM Dieter Nützel wrote:
>
> Hello to both of you, Tim and Mika,
>
> sorry that I step in so late, but after I've read that Tim's laptop
> didn't have PCIe atomics
On 3/6/19 9:01 AM, John Stultz wrote:
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
+
+ printf("Allocating 1 MEG\n");
+ ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, &dmabuf_fd);
+ if (ret)
+ goto out;
On Fri, Mar 15, 2019 at 2:06 AM Christoph Hellwig wrote:
>
> On Tue, Mar 05, 2019 at 12:54:32PM -0800, John Stultz wrote:
> > This adds a CMA heap, which allows userspace to allocate
> > a dma-buf of contiguous memory out of a CMA region.
>
> With my previous suggestion of DMA API usage you'd get
On Fri, Mar 15, 2019 at 1:07 PM Laura Abbott wrote:
>
> On 3/6/19 9:01 AM, John Stultz wrote:
> > On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
> > wrote:
> >> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> >>> +
> >>> + printf("Allocating 1 MEG\n");
> >>> + ret = dmabuf_hea
On 3/5/19 12:54 PM, John Stultz wrote:
+DMA-BUF HEAPS FRAMEWORK
+M: Laura Abbott
+R: Liam Mark
+R: Brian Starkey
+R: "Andrew F. Davis"
+R: John Stultz
+S: Maintained
+L: linux-me...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+L: linaro-mm-...@lists.lin
On 3/15/19 3:54 AM, Christoph Hellwig wrote:
>> +static int dma_heap_release(struct inode *inode, struct file *filp)
>> +{
>> +filp->private_data = NULL;
>> +
>> +return 0;
>> +}
>
> No point in clearing ->private_data, the file is about to be freed.
>
This was leftover from when release
On 3/5/19 12:54 PM, John Stultz wrote:
Here is a initial RFC of the dma-buf heaps patchset Andrew and I
have been working on which tries to destage a fair chunk of ION
functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dma
On 3/15/19 1:13 PM, John Stultz wrote:
On Fri, Mar 15, 2019 at 1:07 PM Laura Abbott wrote:
On 3/6/19 9:01 AM, John Stultz wrote:
On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
wrote:
Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
+
+ printf("Allocating 1 MEG\n");
+ ret =
On 3/15/19 3:18 PM, Laura Abbott wrote:
> On 3/5/19 12:54 PM, John Stultz wrote:
>> +DMA-BUF HEAPS FRAMEWORK
>> +M: Laura Abbott
>> +R: Liam Mark
>> +R: Brian Starkey
>> +R: "Andrew F. Davis"
>> +R: John Stultz
>> +S: Maintained
>> +L: linux-me...@vger.kernel.org
>> +L: dri-
On Fri, Mar 15, 2019 at 1:18 PM Laura Abbott wrote:
>
> On 3/5/19 12:54 PM, John Stultz wrote:
> > +DMA-BUF HEAPS FRAMEWORK
> > +M: Laura Abbott
> > +R: Liam Mark
> > +R: Brian Starkey
> > +R: "Andrew F. Davis"
> > +R: John Stultz
> > +S: Maintained
> > +L: linux-me...@vger.kernel.or
The pull request you sent on Fri, 15 Mar 2019 12:12:27 +0100:
> https://github.com/bzolnier/linux.git tags/fbdev-v5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2b9c272cf5cd81708e51b4ce3e432ce9566cfa47
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.k
The pull request you sent on Fri, 15 Mar 2019 10:35:19 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-03-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8264fd046a0884d6bf475a784412978dbbd93175
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Hi Ayan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0 next-20190306]
[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/
https://bugzilla.kernel.org/show_bug.cgi?id=202799
--- Comment #7 from Clément Guérin (li...@protonmail.com) ---
Created attachment 281855
--> https://bugzilla.kernel.org/attachment.cgi?id=281855&action=edit
dmesg drm.debug=4
Here's the log as requested.
--
You are receiving this mail because
On 3/15/19 2:29 PM, John Stultz wrote:
On Fri, Mar 15, 2019 at 1:18 PM Laura Abbott wrote:
On 3/5/19 12:54 PM, John Stultz wrote:
+DMA-BUF HEAPS FRAMEWORK
+M: Laura Abbott
+R: Liam Mark
+R: Brian Starkey
+R: "Andrew F. Davis"
+R: John Stultz
+S: Maintained
+L: linux-me...@vger.k
https://bugs.freedesktop.org/show_bug.cgi?id=109281
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Tue, Mar 05, 2019 at 12:54:28PM -0800, John Stultz wrote:
> Here is a initial RFC of the dma-buf heaps patchset Andrew and I
> have been working on which tries to destage a fair chunk of ION
> functionality.
>
> The patchset implements per-heap devices which can be opened
> directly and then an
On Thu, 14 Mar 2019 13:27:50 +0200, Jyri Sarha wrote:
> Remove trailing white space from sii902x display bridge binding.
>
> Signed-off-by: Jyri Sarha
> Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
> 1 file changed, 1 insertion(+), 1
Hi Ayan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.0 next-20190306]
[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/
On Fri, Mar 15, 2019 at 4:15 PM Jerome Glisse wrote:
> On Tue, Mar 05, 2019 at 12:54:28PM -0800, John Stultz wrote:
> > Here is a initial RFC of the dma-buf heaps patchset Andrew and I
> > have been working on which tries to destage a fair chunk of ION
> > functionality.
> >
> > The patchset imple
Hi Chunming,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on next-20190306]
[cannot apply to v5.0]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.co
https://bugs.freedesktop.org/show_bug.cgi?id=110137
Bug ID: 110137
Summary: drirc adaptive sync, vrr, freesync blacklisting
documentation
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
101 - 189 of 189 matches
Mail list logo
