On Wed, Jan 09, 2019 at 02:53:31PM +0100, Linus Walleij wrote:
[...]
> diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
> b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
[...]
> +static int tpg110_startup(struct tpg110 *tpg)
> +{
> + u8 val;
> + int i;
> +
> + /* De-assert the reset si
Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
userspace.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 4
drivers/gpu/drm/qxl/qxl_prime.c | 14 --
2 files changed, 18 deletions(-)
dif
Hi, Chunhui:
On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> move the setting of fixed divider from enable/disable
> to the function of setting rate.
Please describe more about _WHY_ of this patch. Does it fix any bug, or
enhance some thing, or a new feature?
Regards,
CK
>
> Signed-off
bochs_fbdev.c is almost empty now. Move the remaining framebuffer bits
over to bochs_kms.c. Pure code motion. No functional change.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 29 -
Conversion to atomic modesetting, step three.
Wire up atomic helpers. Switch planes to atomic.
We are late to the party, the transitional helpers are gone,
so this can't be splitted into smaller steps any more.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel
Remove the old, now unused crtc callbacks.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 81 ---
1 file changed, 81 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms
Conversion to atomic modesetting, step one.
Add atomic crtc helper callbacks.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gp
Conversion to atomic modesetting, step two.
Add mode_set_nofb crtc helper callback.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bochs
It's always NULL, so just remove it.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs.h | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
drivers/gpu/drm/bochs/bochs_
Conversion to atomic modesetting, final step.
Set the DRIVER_ATOMIC flag.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bo
Just enough to make the generic framebuffer emulation happy.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs.h | 7 ++
drivers/gpu/drm/bochs/bochs_drv.c | 11 -
drivers/gpu/drm/bochs/bochs_mm.c | 49 +++
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_drv.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index 379111f5a0..1d86c0fb5f 100644
--- a/drivers/gpu/drm/
Not needed any more, bochs uses the generic emulation now.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs.h | 9 ---
drivers/gpu/drm/bochs/bochs_drv.c | 6 --
drivers/gpu/drm/bochs/bochs_fbdev.c | 129 --
Create a separate bochs_hw_setformat function to configure
the framebuffer format (actually just the byteorder).
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs.h | 5 +++--
drivers/gpu/drm/bochs/bochs_hw.c | 19 ++
Conversion to atomic modesetting, step four.
Use atomic set_config helper for crtc.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
This series adds support for atomic modesetting to the bochs driver.
It also switches over to the generic fbdev implementation and does
some cleanups.
v3:
- adjust pin/unpin fix & reorder patches a bit,
to keep the series bisectable (Daniel).
- drop dmabuf import/export callbacks.
v2:
- som
Conversion to atomic modesetting, step five.
Use atomic page_flip helper for crtc.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff
Most unused callbacks can be NULL pointers these days.
Drop a bunch of empty encoder callbacks.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 26 --
1 file changed, 26 deletions(-)
diff
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 8
drivers/gpu/drm/bochs/bochs_kms.c | 14 +-
drivers/gpu/drm/bochs/bochs_mm.c| 8
3 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/
Bit 21 can alter the CTRL2_OUTSTANDING_REQS value right after the eLCDIF
is enabled, since it comes up with default value of 1 (this behaviour
has been seen on some imx8 platforms).
In order to fix this, clear CTRL2_OUTSTANDING_REQS bits before setting
its value.
Signed-off-by: Robert Chiras
---
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and th
This patchset improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
and 8QXP):
1. Add support for drm_bridge
On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
display connector, where an LCD panel can be attached, but instead it is
connected to DSI controller. Since t
Currently, the MXSFB DRM driver only supports a panel. But, its output
display signal can also be redirected to another encoder, like a DSI
controller. In this case, that DSI controller may act like a drm_bridge.
In order support this use-case too, this patch adds support for
drm_bridge in mxsfb.
On 2019-01-09 11:12, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
>> While trying to temporarily hide a plane, one thing that was attempted
>> was to call (from libdrm)
>>
>> drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
>> 0, 0, 0
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 12 insert
Hi,
On 9.01.19 18:04, Doug Anderson wrote:
> Hi,
>
> On Wed, Jan 9, 2019 at 6:38 AM Georgi Djakov wrote:
>>
>> Hi Jayant,
>>
>> On 12/21/18 08:20, Jayant Shekhar wrote:
>>> From: Sravanthi Kollukuduru
>>>
>>> The interconnect framework is designed to provide a
>>> standard kernel interface to c
ARM systems do not permit the use of anything other than cached
mappings for system memory, since that memory may be mapped in the
linear region as well, and the architecture does not permit aliases
with mismatched attributes.
So short-circuit the evaluation in ttm_io_prot() if the flags include
T
Hi Neil,
On Wed, Jan 9, 2019 at 2:36 PM Neil Armstrong wrote:
>
> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
> example) the display gets blurry, looking like an invalid framebuffer width.
>
> This commit fixed atomic crtc modesetting but didn't update the display
> pa
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and th
Currently, the enable of the axi clock return status is ignored, causing
issues when the enable fails then we try to disable it. Therefore, it is
better to check the return status and disable it only when enable
succeeded.
Also, remove the helper functions around clk_axi, since we can directly
use
As the requirement from:
P010 fourcc format support - Was: Re: Kernel error "Unknown pixelformat
0x" occurs when I start capture video
I don't know which device would support the P010, P012, P016 video pixel
format, but Rockchip would support that NV12_10LE40 and a patch for that
driver is
Currently, the vblank support is not correctly implemented in MXSFB_DRM
driver. The call to drm_vblank_init is made with mode_config.num_crtc
which at that time is 0. Because of this, vblank is not activated, so
there won't be any vblank event submitted.
Signed-off-by: Robert Chiras
---
drivers/
Add new optional property 'max-res', to limit the maximum supported
resolution by the MXSFB_DRM driver.
Signed-off-by: Robert Chiras
---
Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mxsfb.t
Hi Jayant,
On 12/21/18 08:20, Jayant Shekhar wrote:
> From: Sravanthi Kollukuduru
>
> The interconnect framework is designed to provide a
> standard kernel interface to control the settings of
> the interconnects on a SoC.
>
> The interconnect API uses a consumer/provider-based model,
> where t
Because of stability issues, we may want to limit the maximum resolution
supported by the MXSFB (eLCDIF) driver.
This patch add support for a new property which we can use to impose such
limitation.
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 12 ++--
1 file chan
The eLCDIF controller has control pin for the external LCD reset pin.
Add support for it and assert this pin in enable and de-assert it in
disable.
Also, correct the pm_runtime_enable call, since it was made too early in
the probe, causing issues to DRM enable routines.
Signed-off-by: Robert Chira
On 04/01/2019 08:03, chunhui dai wrote:
> DPI sample on rising and falling edge. It can reduce half data io.
>
> Signed-off-by: Jitao Shi
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff -
Since version 4 of eLCDIF, there are some registers that can do
transformations on the input data, like re-arranging the pixel
components. By doing that, we can support more pixel formats.
This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
is not supported by eLCDIF, the alpha
From: Mirela Rabulea
Add support for the following pixel formats:
16 bpp: RG16 ,BG16, XR15, XB15, AR15, AB15
Set the bus format based on input from the user and panel capabilities.
Save the bus format in crtc->mode.private_flags, the DSI will use it.
Use drm_get_format_name instead of loc
Panel expects pixel data to be driven on a rising clock edge,
according to A070-92-TT-01 spec, v01, figure 3.1 on page 10/20:
http://www.webcitation.org/75IfI67Kk
This is untested on the AT070TN92, but on its Acrowise AWY-800480T70PC15A
clone, this fixes a 'dancing pixels' artifact when running mo
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be double
On 04/01/2019 08:03, chunhui dai wrote:
> Recalculate the rate of this clock, by querying hardware.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 7 ++--
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 +-
> drivers/gpu/drm/mediatek/mtk_mt2701_h
On 04/01/2019 08:03, chunhui dai wrote:
> fix the rate and divder of hdmi phy for MT2701.
This is a bug? Then we would need a fixes tag.
Otherwise you should explain in the commit, that you need to change the
calculation due to previous commits.
Regards,
Matthias
>
> Signed-off-by: chunhui da
From: Mirela Rabulea
Add mxsfb_atomic_helper_check to signal mode changed when bpp changed.
This will trigger the execution of disable/enable on
a modeset with different bpp than the current one.
Signed-off-by: Mirela Rabulea
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 48 +
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be double
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.
P012 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010.
V4: format definition refined per
On 1/10/19 3:28 PM, Ard Biesheuvel wrote:
ARM systems do not permit the use of anything other than cached
mappings for system memory, since that memory may be mapped in the
linear region as well, and the architecture does not permit aliases
with mismatched attributes.
So short-circuit the evalua
Hi Ard,
thanks a lot for this! At least somebody who can explain why this
doesn't work as expected.
The problem is that the hardware actually needs a few pages as uncached
in a couple of cases to work correctly. So we could still run into
issues with that solution.
For now we have blocked use
Hi Thierry.
> > + case TPG110_RES_480X272:
> > + dev_info(tpg->dev, "480x272 RGB");
> > + break;
> > + case TPG110_RES_640X480:
> > + dev_info(tpg->dev, "640x480 RGB");
> > + break;
> > + case TPG110_RES_800X480:
> > + dev_info(tpg->dev, "800
Den 10.01.2019 09.28, skrev Gerd Hoffmann:
> Not needed any more, bochs uses the generic emulation now.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Oleksandr Andrushchenko
> Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/bochs/bochs.h | 9 ---
> drivers/gpu/drm/bochs/bochs_drv.c
On Tue, Jan 08, 2019 at 07:35:03PM -0500, Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things
On Tue, Jan 08, 2019 at 07:35:01PM -0500, Lyude Paul wrote:
> Split some stuff across multiple lines
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Harry Wentland
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Juston Li
On patches 1-4: Reviewed-by: Daniel Vetter
> ---
> driver
On Tue, Jan 08, 2019 at 07:35:04PM -0500, Lyude Paul wrote:
> While this isn't a complete fix, this will improve the reliability of
> drm_dp_get_last_connected_port_and_mstb() pretty significantly during
> hotplug events, since there's a chance that the in-memory topology tree
> may not be fully up
On Tue, Jan 08, 2019 at 07:35:05PM -0500, Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Harry Wentland
> Cc
On Fri, Dec 28, 2018 at 5:05 PM Daniel Vetter wrote:
> On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij
> wrote:
> > - Skip over YUV formats. The framebuffer emulation cannot
> > handle these formats.
(...)
> > + /* Do not consider YUV formats for framebuffers */
> > +
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns th
On Tue, Jan 08, 2019 at 07:35:14PM -0500, Lyude Paul wrote:
> Changes since v6:
> - Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
>commit
> - Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
>called directly
>
> Signed-off-by: Lyude Paul
> Reviewed
On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> ARM systems do not permit the use of anything other than cached
> mappings for system memory, since that memory may be mapped in the
> linear region as well, and the architecture does not permit aliases
> with mismatched attributes.
>
> So short-cir
On Tue, Jan 08, 2019 at 07:35:15PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
>
> /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>* bran
On Tue, Jan 08, 2019 at 07:35:16PM -0500, Lyude Paul wrote:
> It occurred to me that we never actually check this! So let's start
> doing that.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> Cc: David Airlie
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Juston Li
Reviewed-by: Dan
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #18 from network...@rkmail.ru ---
Is this bug still being worked on?
The problem is still here, but there's a little update: sometimes texture gets
cleared correctly.
Currently running Mesa git master 31e4c9ce400341df9b0136419b3b3c
On Thu, Jan 10, 2019 at 10:19 AM Linus Walleij wrote:
>
> On Fri, Dec 28, 2018 at 5:05 PM Daniel Vetter wrote:
> > On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij
> > wrote:
>
> > > - Skip over YUV formats. The framebuffer emulation cannot
> > > handle these formats.
> (...)
> > > +
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code". Any ideas?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusi
Hi,
> > - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1);
>
> The generic fbdev emulation doesn't take care of suspend/resume. You
> could do this:
> drm_fb_helper_set_suspend_unlocked(drm_dev->fb_helper, 1);
Additional to drm_mode_config_helper_suspend() I assume?
Does the call or
Motivated by an oversight of mine when looking at the atomic bochs
conversion. For consistency also switch over to the same style as used
elsewhere (e.g. in drm_mode_set_config_internal).
Cc: Gerd Hoffmann
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |
On Thu, Jan 10, 2019 at 07:19:31PM +0900, Tetsuo Handa wrote:
> We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
> failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
> succeeded.
>
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
Queued for 5.0,
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
succeeded.
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +--
drivers/gpu/drm/drm_mode_object.c | 4 ++--
On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> Currently MP clocks don't consider adjusting parent rate even if they
> are allowed to do so. Such behaviour considerably lowers amount of
> possible rates, which is very inconvenient when such clock is used for
> pixel clock, for ex
https://bugs.freedesktop.org/show_bug.cgi?id=108464
--- Comment #17 from Duncan Roe ---
Created attachment 143055
--> https://bugs.freedesktop.org/attachment.cgi?id=143055&action=edit
dmesg o/p with diags after applying attachment 143011
The line before the BUG line shows a null pointer
--
Y
Hi Uma,
On Tue, Jan 08, 2019 at 02:41:20PM +0530, Uma Shankar wrote:
> Hardware may have HDR capability on certain plane
> engines. Enabling the same in drm plane structure
> so that this can be communicated to user space.
>
> Each drm driver should set this flag to true for planes
> which suppor
On Tue, Jan 08, 2019 at 02:41:16PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
>
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
>
> v3:
https://bugs.freedesktop.org/show_bug.cgi?id=108464
--- Comment #18 from Duncan Roe ---
Mixed results on applying this patch.
IN BRIEF: If you could eliminate this second Oops then we can see what works
and what doesn't.
In the meantime with the patch applied to v4.20 in the stable repository:
re
On Thu, Jan 10, 2019 at 11:30:45AM +0100, Daniel Vetter wrote:
> Motivated by an oversight of mine when looking at the atomic bochs
> conversion. For consistency also switch over to the same style as used
> elsewhere (e.g. in drm_mode_set_config_internal).
>
> Cc: Gerd Hoffmann
> Cc: Noralf Trønn
Den 10.01.2019 11.16, skrev Gerd Hoffmann:
> Hi,
>
>>> - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1);
>>
>> The generic fbdev emulation doesn't take care of suspend/resume. You
>> could do this:
>> drm_fb_helper_set_suspend_unlocked(drm_dev->fb_helper, 1);
>
> Additional to drm
Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
userspace.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_drv.c | 4
drivers/gpu/drm/virtio/virtgpu_pr
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns th
>-Original Message-
>From: Liviu Dudau [mailto:li...@dudau.co.uk]
>Sent: Thursday, January 10, 2019 4:17 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 05/12]
Den 09.01.2019 18.49, skrev Noralf Trønnes:
> Useful for drivers that only care about the combined damage.
>
> Cc: Deepak Rawat
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_damage_helper.c | 43 +
> include/drm/drm_damage_helper.h | 3 ++
> 2 fi
https://bugs.freedesktop.org/show_bug.cgi?id=109281
Martin Peres changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=109281
--- Comment #2 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* ICL: igt@gem_ctx_isolation@* - skip - WARNING: GEN not recognized!
-
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DR
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
>
> Hi Christoph,
>
>
> https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
> into the dma_direct code". Any ideas?
From the trace it looks
Am 10.01.19 um 14:57 schrieb Christoph Hellwig:
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code".
Hi Dave/Daniel,
Some patches were pushed today to drm-misc-fixes, and I think it would be nice
if they are part of the pull req for v5.0-rc2. :)
drm-misc-fixes-2019-01-10-1:
Second pull request, drm-misc-fixes for v5.0-rc2:
- Fix fb-helper to work correctly with SDL 1.2 bugs.
- Fix lockdep warnin
On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>> From the trace it looks like we git the case where swiotlb tries
>> to copy back data from a bounce buffer, but hits a dangling or NULL
>> pointer. So a couple questions for the submitter:
>>
>> - does the system have more than
if lru is changed, we cannot do bulk moving.
Change-Id: Ide0fe920295cc25f7cabcf41a6400519e5783f2a
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++
allow driver do somethings when lru changed.
Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 11 +++
include/drm/ttm/ttm_bo_driver.h | 9 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/dri
On 2019-01-10 3:52 p.m., Chunming Zhou wrote:
> allow driver do somethings when lru changed.
>
> Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
> Signed-off-by: Chunming Zhou
>
> [...]
>
> void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
> diff --git a/include/drm/ttm/ttm_bo_d
https://bugs.freedesktop.org/show_bug.cgi?id=109290
Bug ID: 109290
Summary: [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip -
Estimated that we need \d+ objects and \d+ MiB for the
test, but only have \d+ MiB available \(RAM\) and a
https://bugs.freedesktop.org/show_bug.cgi?id=109290
Martin Peres changed:
What|Removed |Added
Summary|[CI][SHARDS]|[CI][SHARDS]
|igt@gem_
https://bugs.freedesktop.org/show_bug.cgi?id=109290
--- Comment #1 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* ICL: igt@gem_pwrite@huge-cpu - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+
https://bugs.freedesktop.org/show_bug.cgi?id=109290
--- Comment #2 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- ICL: igt@gem_pwrite@huge-cpu - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a
On Thu, 27 Dec 2018, Jani Nikula wrote:
> DRM_DEBUG() was intended to be used by the drm core code only, but we
> weren't careful. Today, the driver usage of DRM_DEBUG() trumps drm core
> usage about 10:1. It's easier to swith the core over to a new
> DRM_DEBUG_CORE() macro than the drivers over t
https://bugs.freedesktop.org/show_bug.cgi?id=109290
--- Comment #3 from Chris Wilson ---
Nah. Give me a machine with 49-bits of memory and I want to test what happens
if we have a full 48-bit GTT. (Not that it really matters, since the
interesting GTT is the global one, mappable vs non-mappable a
https://bugs.freedesktop.org/show_bug.cgi?id=109161
--- Comment #7 from Michel Dänzer ---
(In reply to mikhail.v.gavrilov from comment #5)
> Looks like I hurried to report that all is well.
> With prolonged working, hangs still happens.
This looks like a separate issue, see bug 109234 and follow
https://bugs.freedesktop.org/show_bug.cgi?id=109290
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- ICL: igt@gem_pwrite@huge-* - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a ma
Just a ping.
Andrey
On 01/09/2019 10:18 AM, Andrey Grodzovsky wrote:
>
>
> On 01/09/2019 05:22 AM, Christian König wrote:
>> Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
>>>
>>> On 01/07/2019 09:13 AM, Christian König wrote:
Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
> On 01/0
On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > >
> > > Hi Christoph,
> > >
> > >
> > > https://bugs.freedesktop.org/109234 (please ignore comments #6-#
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in msm files.
Signed-off-by: Shayenne Moura
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel).
- Make the commit message more clear
Changes in v3:
- Resolve typo in v2 patch
drivers
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in omapdrm files.
Signed-off-by: Shayenne Moura
Reviewed-by: Sebastian Reichel
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel)
- Make the commit message more clear
Changes in v3:
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in meson files.
Signed-off-by: Shayenne Moura
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel)
- Make the commit message more clear
Changes in v3:
- No changes
drivers/gpu/drm/meso
1 - 100 of 274 matches
Mail list logo
