On 11/06/18 14:20, Hans Verkuil wrote:
> Hi Ville,
>
> I finally found some time to dig deeper into when a CEC device should be
> registered.
>
> Since it's been a long while since we discussed this let me just recap the
> situation
> and then propose three solutions:
> CEC is implemented for
Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no
This still tries to address the hang seen by Ezequiel Garcia on rk3288.
As Tomasz noted, trying to count enablement can run into concurrency
issues, so instead we'll just check if the vop is runtime-enabled
to see if it could be the source of the irq and then just do our
own clk_enable in the isr
https://bugs.freedesktop.org/show_bug.cgi?id=106872
--- Comment #2 from Christian König ---
(In reply to Michel Dänzer from comment #1)
> One possible solution for this would be for amdgpu_bo_pin_restricted and
> amdgpu_bo_unpin to walk the list of memory nodes and calculate exactly how
> much
On Tue, 12 Jun 2018, Dave Airlie wrote:
> On 12 June 2018 at 02:27, Rodrigo Vivi wrote:
>> Hi Dave,
>>
>> This is the first round targeting 4.19.
>>
> Does this tree feed into linux-next already?
>
> Since we shouldn't have new stuff for linux-next feeding into it until
> after rc1.
I think
On Tue, 12 Jun 2018, Dan Carpenter wrote:
> On Mon, Jun 11, 2018 at 05:46:53PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> The check for level being less than zero always false because flags
>> is currently unsigned and can never be negative. Fix this by making
>> flags a s32.
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=106892
--- Comment #2 from Simon ---
Ok also crashed at 60Hz now, so seems that didn't fix it after all. But seems
to crash less often at 60Hz and also I didn't get a crash yet at
1024x768@60Hz..
--
You are receiving this mail because:
You are the
On Tue, 12 Jun 2018 11:38:04 +0200, Colin King
wrote:
From: Colin Ian King
The check for level being less than zero always false because flags
is currently unsigned and can never be negative. Fix this by making
level a s32.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the current media master branch
(https://git.linuxtv.org/media_tree.git/log/) but it applies fine on top
of the current mainline tree.
This patch series has been
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is
From: Hans Verkuil
Document the Display Port CEC helper functions.
Signed-off-by: Hans Verkuil
---
Documentation/gpu/drm-kms-helpers.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index
Hi,
On Fri, Jun 08, 2018 at 07:29:03PM +0300, Laurent Pinchart wrote:
> Hello,
>
> This patch series reworks all the timing-related operations (.get_timings(),
> .set_timings() and .check_timings()) as a step toward moving from
> omap_dss_device to drm_bridge.
>
> All timing-related operations
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
Quoting Rob Herring (2018-06-05 08:20:50)
> > +
> > +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
> > +
> > +- gpio-controller: Marks the device has a GPIO controller.
> > +- #gpio-cells: Should be two. The first cell is the pin number and
> > + the
Hey,
Only the qxl fix by Jeremy Cline is new. The rest has landed in v4.17 already.
drm-misc-fixes-2018-06-12:
Only a small qxl fix that was queued for v4.17.
The following changes since commit 9a0e9802217291e54c4dd1fc5462f189a4be14ec:
drm/vc4: Fix scaling of uni-planar formats (2018-05-09
Hi,
On 06/11/2018 06:49 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 08:46 PM, Julien Grall wrote:
Hi,
On 06/11/2018 06:16 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM,
On 06/11/2018 08:46 PM, Julien Grall wrote:
Hi,
On 06/11/2018 06:16 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano
Quoting Sandeep Panda (2018-06-04 22:40:15)
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 000..add6e0f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,666 @@
> +//
Hi,
On 06/11/2018 06:16 PM, Oleksandr Andrushchenko wrote:
On 06/11/2018 07:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static
Hi Stefano,
On 06/11/2018 05:51 PM, Stefano Stabellini wrote:
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote:
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote:
On 06/08/2018 01:59 PM, Stefano Stabellini wrote:
@@ -325,6 +401,14 @@ static int map_grant_pages(struct
grant_map
*map)
If 'platform_get_resource_byname()' fails, we should release some resources
before leaving, as already done in the other error handling path of the
function.
Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in
meson_drv_bind_master()")
Signed-off-by: Christophe JAILLET
---
https://bugs.freedesktop.org/show_bug.cgi?id=106871
--- Comment #3 from Michel Dänzer ---
(In reply to Erik from comment #2)
> (Still interesting how you can figure this out from my logging.)
In a nutshell: Because the dmesg output you attached doesn't contain the word
"Display".
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #16 from Christian König (christian.koe...@amd.com) ---
So the problem seems to be the bridge then.
Please provide me with the output of the following commands, once before you
suspended, once after you resumed without any change and
Quoting spa...@codeaurora.org (2018-06-05 21:50:16)
> On 2018-06-05 20:50, Rob Herring wrote:
> > On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
> >> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
[...]
> >> and
> >> + the second cell is used to
On Mon, Jun 11, 2018 at 05:46:53PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The check for level being less than zero always false because flags
> is currently unsigned and can never be negative. Fix this by making
> flags a s32.
>
> Detected by CoverityScan, CID#1468363 ("Macro
From: Colin Ian King
The check for level being less than zero always false because flags
is currently unsigned and can never be negative. Fix this by making
level a s32.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Fixes: cb5d64e9f13e ("drm/i915/guc: Allow user to
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner wrote:
> There are two drivers for the LCDIF/MXSFB peripheral. If the DRM
> and fbdev are compiled in, the registration of the second driver
> fails:
> mxs-dma 3300.dma-apbh: initialized
> mxsfb 3073.lcdif: 3073.lcdif supply lcd not
Hi Jani,
I like to understand how the DRM_DP_AUX_CHARDEV=y kick off.
Regards,John
On Monday, June 11, 2018, 7:36:51 PM GMT+8, Jani Nikula
wrote:
On Mon, 11 Jun 2018, John Sledge wrote:
> Thanks for the help. I was able to manage your advice on the
> drm_dp_aux_chardev. Though I
Seamless modes are ones which do not require a display
to be turned OFF/ON between mode switches.
Remove support for seamless modes from DPU for now.
This will be added later based on additional requirements.
This change depends on the DPU custom property removal series:
-
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec wrote:
> Display related peripherals need precise clocks to operate correctly.
>
> Allow DE2, TCONs and HDMI to set parent clock.
>
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
https://bugzilla.kernel.org/show_bug.cgi?id=198713
--- Comment #6 from Nicholas Johnson (nicholas.john...@outlook.com.au) ---
If you are referring to my comment, mine was with 4.17 kernel (latest stable
release). I was just commenting on this one (4.15) because it looks like the
same bug, and I
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component DPI1
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component OD1 and
> rename the OD to OD0
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the component DSI3
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the component DSI2
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec wrote:
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
>
> Signed-off-by:
On Mon, Jun 11, 2018 at 03:34:58PM +0200, Heiko Stuebner wrote:
> From: Nickey Yang
>
> This patch update describe panel/port links, including
> unit addresses in documentation of device tree bindings
> for the rockchip DSI controller based on the Synopsys
> DesignWare MIPI DSI host controller.
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #18 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276517
--> https://bugzilla.kernel.org/attachment.cgi?id=276517=edit
lspci before suspend
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #17 from Alexander Mezin (mezin.alexan...@gmail.com) ---
setpci - exactly the same output in all 3 cases (verified with 'diff' to be
sure):
0407
0001
fff1
00e0
00e2
--
You are receiving this mail because:
You are watching
cleans up left out scalar config definitions from headers
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 10 --
2 files changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
Subclass drm private state for DPU for handling driver
specific data. Adds atomic private object and private object
lock to dpu kms. Provides helper function to retrieve DPU
private data from current atomic state.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66
Switch to state based resource management. This patch
overhauls the resource manager and HW allocation methods by
maintaining the global resource pool and allocated hw
blocks in respective drm component states.
Global resource manager(RM) is tracked in private object.
Allocation strategy is
resource pool manager utility was introduced to manage
rotator sessions. Removing the support as the rotator
feature doesn't exist.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 494 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 84
This patchset introduces drm private object in KMS to manage HW
resource management. It modifies the resource manager by
introducing API's to do per DRM object resource allocation/cleanups.
The patchset is based on: https://patchwork.kernel.org/patch/10461375/
Jeykumar Sankaran (4):
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #20 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276521
--> https://bugzilla.kernel.org/attachment.cgi?id=276521=edit
lspci after resume with hack
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #19 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276519
--> https://bugzilla.kernel.org/attachment.cgi?id=276519=edit
lspci after resume, no hack
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #21 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Not sure if it'll help, but I've added more logging here:
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -436,6 +436,8 @@ int pci_resize_resource(struct pci_dev
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DSI2
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DPI0
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
Hi, Stu:
Two inline comment.
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA0 to DSI3
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> 2 files
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #32 from Luca ---
Happens to me too (kernel 4.17 ubuntu 18.04), especially the first boot of the
day I always get black screen after modeset. I haven't tried with KASAN and
can't get any log but I suspect is the same issue.
Asrock
On Mon, Jun 04, 2018 at 01:16:48PM +0200, Christoph Fritz wrote:
> This patch adds support for Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD
> panel.
>
> Signed-off-by: Christoph Fritz
> ---
> .../bindings/display/panel/innolux,g070y2-l01.txt | 12 +++
> drivers/gpu/drm/panel/panel-simple.c
On Mon, Jun 04, 2018 at 10:04:59PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> hardware seems the same as in the R-Car V3M (R8A77970).
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'drm-next' branch of David
On Tue, Jun 05, 2018 at 11:28:58PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car LVDS bindings.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 +
> 1 file changed, 1 insertion(+)
On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Print out the modeline when we reject a bad user mode. Avoids having to
> guess why it was rejected.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_atomic.c| 20
https://bugzilla.kernel.org/show_bug.cgi?id=200045
Bug ID: 200045
Summary: i2c-algo-bit: black screen on 'radeon' module probing
Product: Drivers
Version: 2.5
Kernel Version: 4.16
Hardware: All
OS: Linux
On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Print the id/name of the object we're dealing with. Makes it easier to
> figure out what's going on. Also toss in a few extra debug prints that
> might be useful.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Harry
https://bugzilla.kernel.org/show_bug.cgi?id=198713
Andrey Grodzovsky (andrey.grodzov...@amd.com) changed:
What|Removed |Added
CC|
On Thu, May 31, 2018 at 03:41:05PM +0300, Tomi Valkeinen wrote:
> Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS
> is quite simple, with a single plane and a single output.
>
> Signed-off-by: Tomi Valkeinen
> Cc: devicet...@vger.kernel.org
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=106870
--- Comment #2 from Luca ---
I think they are the same bug but in the title it was mentioned it was
occurring during boot and that is not my case although I have this problem at
boot (https://bugs.freedesktop.org/show_bug.cgi?id=106225). I've
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #36 from Samuel Sieb (samuel-kb...@sieb.net) ---
This is resolved for me with the 4.16 kernel after upgrading to F28. And the
Fedora bug has been closed as well with someone else saying the same thing.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=23017
Adam Jackson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=28771
Bug 28771 depends on bug 42035, which changed state.
Bug 42035 Summary: no way to turn off vline wait at runtime
https://bugs.freedesktop.org/show_bug.cgi?id=42035
What|Removed |Added
https://bugzilla.kernel.org/show_bug.cgi?id=199749
Andrey Grodzovsky (andrey.grodzov...@amd.com) changed:
What|Removed |Added
CC|
From: Brian Starkey
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of
Hi,
This is v10 of the writeback connector series. Compared to v9 I've
reverted to the v6 way of cleaning up the writeback job in the cleanup_work()
function, where we also drop the reference to the job's framebuffer. I was
trying to come up with a reference counted implementation for the job,
From: Brian Starkey
Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.
A timeline is added to
Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.
Changelog:
- only accept
Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.
Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no
This still tries to address the hang seen by Ezequiel Garcia on rk3288.
As Tomasz noted, trying to count enablement can run into concurrency
issues, so instead we'll just check if the vop is runtime-enabled
to see if it could be the source of the irq and then just do our
own clk_enable in the isr
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 54
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
From: Oleksandr Andrushchenko
This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
https://bugs.freedesktop.org/show_bug.cgi?id=106892
--- Comment #3 from Simon ---
ok also crashing with 1024x768@60Hz, so seems the resolution and frequency dont
really matter for that bug, sry for the confusion. ^^
Anyway how do I disable these annoying EDID message spam in dmesg?
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=99492
Jani Nikula changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99492
Jani Nikula changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
Am Dienstag, 12. Juni 2018, 14:39:03 CEST schrieb Marc Zyngier:
> Hi Heiko,
>
> On 12/06/18 13:15, Heiko Stuebner wrote:
> > From: Sandy Huang
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver moved to the probe function recently. This can in some
> >
https://bugs.freedesktop.org/show_bug.cgi?id=99492
--- Comment #1 from Jani Nikula ---
(In reply to Andreas Reis from comment #0)
> At least in the case of -g, intel_gpu_frequency currently (1.16 & git) fails
> if there are parameters. With none it works.
>
> Eg, the example's -gmin,cur yields
Hi Heiko,
On 06/12/2018 08:15 PM, Heiko Stuebner wrote:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it
From: Brian Starkey
Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.
Signed-off-by: Brian Starkey
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 22
Hi,
Updating the Mali DP memory writeback engine support series to match
the v10 generic writeback connector support posted here [1].
Changelog:
- v8: Addressed feedback from Brian wrt the state tracking that we deploy
for DP500 and the timing of the CVAL setting. Also added SPDX license
Mali DP500 behaves differently from the rest of the Mali DP IP,
in that it does not have a one-shot mode and keeps writing the
content of the current frame to the provided memory area until
stopped. As a way of emulating the one-shot behaviour, we are
going to use the CVAL interrupt that is being
From: Brian Starkey
Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer. Expose this functionality as a
DRM writeback connector on supported hardware.
Changes since v1:
Daniel Vetter:
- Don't require a modeset when writeback routing
Annotate the pixel format matrix for DP500 with the memory-write flag
for formats that are supported by the SE memwrite engine.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.
Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.
Changes since v3:
- Fix
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM
and fbdev are compiled in, the registration of the second driver
fails:
mxs-dma 3300.dma-apbh: initialized
mxsfb 3073.lcdif: 3073.lcdif supply lcd not found, using dummy
regulator
mxsfb 3073.lcdif: initialized
On 11/06/2018 18:53, Christophe JAILLET wrote:
> If 'platform_get_resource_byname()' fails, we should release some resources
> before leaving, as already done in the other error handling path of the
> function.
>
> Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in
>
On Mon, 4 Jun 2018, kbuild test robot wrote:
> Hi Mikulas,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on drm/drm-next]
> [also build test WARNING on v4.17-rc7 next-20180601]
> [if your patch is applied to the wrong git tree, please drop us a note to
>
On Mon, Jun 11, 2018 at 11:26 AM Jordan Crouse wrote:
>
> Now that the IOMMU is the master of it's own power we don't need to bring
> up the GPU to do IOMMU operations. This is good because bringing up a6xx
> requires the GMU so calling pm_runtime_get_sync() too early in the process
> gets us
99 matches
Mail list logo
