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
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
---
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
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:
-
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(-)
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(-)
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
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 ---
>
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
> ---
>
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
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
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
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
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
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 +-
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
>
>
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 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,
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
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
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
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
>
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
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
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
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
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 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 */
> > +
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,
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
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(-)
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
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
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
>
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
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.
> (...)
> > > +
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
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!
-
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
https://bugs.freedesktop.org/show_bug.cgi?id=109281
Martin Peres changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
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
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
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
---
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
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
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
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
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
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
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
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
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 +-
>
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
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 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
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
>
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
>*
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:
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
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
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=edit
dmesg o/p with diags after applying attachment 143011
The line before the BUG line shows a null pointer
--
You are
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
Den 10.01.2019 11.16, skrev Gerd Hoffmann:
> Hi,
>
>>> - drm_fb_helper_set_suspend_unlocked(>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
Hi,
> > - drm_fb_helper_set_suspend_unlocked(>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 order
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
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
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:
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
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.
>
>
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
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
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,
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 |
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
>-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
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
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
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
--- 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
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
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
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
Martin Peres changed:
What|Removed |Added
Summary|[CI][SHARDS]|[CI][SHARDS]
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
On Thu, 10 Jan 2019 15:10:39 +
Peter Rosin wrote:
> The destination crtc rectangle is independent of source plane rotation.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in msm files.
Reported-by: kbuild test robot
Signed-off-by: Shayenne Moura
---
Changes in v2:
- Use DRM_MODE_FMT/ARG macros (Daniel).
- Make the commit message more clear
Changes in v3:
-
This patch removes the drm_mode_object prints, evaluation and use from
drm_display_mode objects used in drm files. It removes dependency from
drm_mode_object.
Signed-off-by: Shayenne Moura
Reviewed-by: Daniel Vetter
---
Changes in v2, v3, and v4:
- No changes
This patch serie removes drm_mode_object dependency from
drm_display_mode struct. This is part of KMS cleanup.
---
Changes in v2:
- Make alterations suggested by Daniel and commit messages clear
Changes in v3:
- Solve typo in first patch in v2
Changes in v4:
- Remove patches already
1 - 100 of 274 matches
Mail list logo
