[Bug 108916] polaris11 d3d9 rendering issue
https://bugs.freedesktop.org/show_bug.cgi?id=108916 --- Comment #3 from Roman Elshin --- I saw some reports with distortions which looks similar to this and it was fixed in llvm-8. Installing llvm-8 from http://apt.llvm.org/ and recompiling libdrm + mesa from git does't solve this issue. $ glxinfo |grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 560 Series (POLARIS11, DRM 3.27.0, 4.19.9, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-8e9ad592c3) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Don't send MST hotplugs until after resume
Turns out we are sending a lot more hotplug events then we need, and
this is causing some pretty serious issues. Currently, we call
intel_dp_mst_resume() in i915_drm_resume() well before we have any sort
of hotplugging setup. This is a pretty big problem, because in practice
it will generally result in throwing the power domain refcounts out of
wack.
For instance: On my T480s, removing a previously connected topology
before the system finishes resuming causes
drm_kms_helper_hotplug_event() to be called before HPD is setup again,
which causes us to do a connector reprobe, which then causes
intel_dp_detect() to be called on all DP devices -including- the eDP
display. From there, intel_dp_detect() is run on the eDP display which
triggers DPCD transactions. Those DPCD transactions then cause us to
call edp_panel_vdd_on(), which then causes us to grab an additional
wakeref to the relevant power wells (PORT_DDI_A_IO on this machine).
From there, this wakeref is never released which then causes the next
suspend/resume cycle to entirely fail due to the hardware not being
powered off correctly.
This sucks really badly, and I don't see any decent way to actually fix
this in intel_dp_detect() easily. Additionally, I don't even think it'd
be worth the time now since we're not expecting to handle any kind of
connector reprobing at the point in which we call intel_dp_mst_resume(),
but we also can't move intel_dp_mst_resume() any higher in the resume
process since MST topologies need to be resumed before
intel_display_resume() is called.
However, there's a light at the end of the tunnel! After reading through
a lot of code dozens of times, it occurred to me that we -never-
actually need to send hotplug events when calling
drm_dp_mst_topology_mgr_set_mst() since we send hotplug events in
drm_dp_destroy_connector_work(). Imagine that!
So, since we only seem to call intel_dp_mst_check_status() to disable
MST on the encoder in question and then send a hotplug, get rid of this
and instead just disable MST mode when a hub fails in
intel_dp_mst_resume(). From there, drm_dp_destroy_connector_work() will
eventually send the hotplug event.
Signed-off-by: Lyude Paul
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v3.17+
---
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..c2399acf177b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private
*dev_priv)
continue;
ret = drm_dp_mst_topology_mgr_resume(&intel_dp->mst_mgr);
- if (ret)
- intel_dp_check_mst_status(intel_dp);
+ if (ret) {
+ intel_dp->is_mst = false;
+ drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+ false);
+ }
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: check yuv2yuv existence before assigning window data
Before assigning window data, we should check if the yuv2yuv vop-data
is set at all, because it looks like it can otherwise reference something
wrong, as I saw on my rk3188 today which ended up in a null pointer
dereference in vop_plane_atomic_update when accessing the yuv2yuv data.
Fixes: 1c21aa8f2b68 ("drm/rockchip: Fix YUV buffers color rendering")
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 619b6db05d58..1dc9fd1ffbe3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1675,7 +1675,9 @@ static void vop_win_init(struct vop *vop)
vop_win->data = win_data;
vop_win->vop = vop;
- vop_win->yuv2yuv_data = &vop_data->win_yuv2yuv[i];
+
+ if (vop_data->win_yuv2yuv)
+ vop_win->yuv2yuv_data = &vop_data->win_yuv2yuv[i];
}
}
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 --- Comment #8 from Elliot Thomas (e.singularity...@gmail.com) --- Created attachment 280777 --> https://bugzilla.kernel.org/attachment.cgi?id=280777&action=edit dmesg, amd-staging-drm-next-git (d0333a48e54fdcfdae5e378acd898a680967e939) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, amdkfd, ttm, sched drm-next-5.1
Hi Dave, Daniel, New stuff for 5.1. amdgpu: - DC bandwidth formula updates - Support for DCC on scanout surfaces - Support for multiple IH rings on soc15 asics - Fix xgmi locking - Add sysfs interface to get pcie usage stats - Simplify DC i2c/aux code - Initial support for BACO on vega10/20 - New runtime SMU feature debug interface - Expand existing sysfs power interfaces to new clock domains - Handle kexec properly - Simplify IH programming - Rework doorbell handling across asics - Drop old CI DPM implementation - DC page flipping fixes - Misc SR-IOV fixes amdkfd: - Simplify the interfaces between amdkfd and amdgpu ttm: - Add a callback to notify the driver when the lru changes sched: - Refactor mirror list handling - Rework hw fence processing The following changes since commit e3d093070eb0b5e3df668d3eb04100ea79343c65: Merge tag 'tilcdc-4.22' of https://github.com/jsarha/linux into drm-next (2019-01-11 06:29:31 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-5.1 for you to fetch changes up to 10117450735c7a7c0858095fb46a860e7037cb9a: drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines (2019-01-25 16:15:37 -0500) Aaron Liu (1): drm/amdgpu/psp: ignore psp response status Alex Deucher (12): drm/amdgpu: expose sclk and mclk via hwmon drm/amdgpu: add need_reset_on_init asic callback (v2) drm/amdgpu/si: add need_reset_on_init asic callback for SI (v2) drm/amdgpu/cik: add need_reset_on_init asic callback for CIK (v2) drm/amdgpu/vi: add need_reset_on_init asic callback for VI (v2) drm/amdgpu/soc15: add need_reset_on_init asic callback for SOC15 (v2) drm/amdgpu: check if we need to reset at init time (v2) drm/amdgpu/soc15: return proper error codes in baco reset drm/amdgpu: Add APTX quirk for Lenovo laptop drm/amdgpu: Add missing power attribute to APU check drm/radeon: check if device is root before getting pci speed caps drm/amdgpu: remove old CI DPM implementation Amber Lin (3): drm/amdgpu: Relocate kgd2kfd function declaration drm/amdgpu: Simplify kgd2kfd interface drm/amdgpu: Remove kgd2kfd function pointers Andrey Grodzovsky (2): drm/sched: Refactor ring mirror list handling. drm/sched: Rework HW fence processing. Bayan Zabihiyan (1): drm/amd/display: Add new infopacket definition Brajeswar Ghosh (3): drm/amd/display: Remove duplicate header drm/amd/display/dcn10_hw_sequencer_debug: Remove duplicate header drm/amd/display/i2c_hw_engine_dce110: Remove duplicate header Charlene Liu (2): drm/amd/display: fix PME notification not working in RV desktop drm/amd/display: dp interlace MSA timing programming for Interlace mode. Christian König (11): drm/amdgpu: disable system memory page tables for now drm/amdgpu: add IH ring to ih_get_wptr/ih_set_rptr v2 drm/amdgpu: simplify IH programming drm/amdgpu: fix IH overflow on Vega10 v2 drm/amdgpu: add the IH to the IV trace drm/amdgpu: improve GMC v9 page fault message drm/ttm: stop always moving BOs on the LRU on page fault drm/amdgpu: set the executable flag on unused Vega10 PTEs v2 drm/amdgpu: enable IH ring 1 and ring 2 v4 drm/amdgpu: add support for processing IH ring 1 & 2 drm/amdgpu: add support for self irq on Vega10 v2 Chunming Zhou (2): drm/ttm: add lru notify to bo driver v2 drm/amdgpu: set bulk_moveable to false when lru changed v2 Colin Ian King (1): amdgpu/dc: remove various variables that are defined but never used David Francis (12): drm/amd/display: Detach backlight from stream drm/amd/display: Add backlight pwm debugfs drm/amd/display: Remove unused parameter plane_states drm/amd/display: Shift dc link aux to aux_payload drm/amd/display: Switch ddc to new aux interface drm/amd/display: Change from aux_engine to dce_aux drm/amd/display: Remove i2caux folder drm/amd/display: Let updates with no scaling changes be fast drm/amd/display: Simplify underscan and ABM commit drm/amd/display: Call into DC once per multiplane flip drm/amd/display: Perform plane updates only when needed drm/amd/display: Know what a pageflip is Derek Lai (1): drm/amd/display: Set link rate set if eDP ver >= 1.4. Dmytro Laktyushkin (4): drm/amd/display: Remove some extra braces drm/amd/display: update DCN dml calcs drm/amd/display: add dsclk to pipe bw struct drm/amd/display: Rename configure_encoder to enc1_configure_encoder Emily Deng (4): drm/amdgpu/virtual_dce: No need to pin the fb's bo drm/amdgpu/virtual_dce: No need to pin the cursor bo drm/amdgpu/sriov:Correct pfvf exchange logic drm/amdgpu/sriov: For finishing routine send rel event after i
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote: > Minimum PLL used for MIPI is 500MHz, as per manual, but > lowering the min rate by 300MHz can result proper working > nkms divider with the help of desired dclock rate from > panel driver. > > Signed-off-by: Jagan Teki > Acked-by: Stephen Boyd Going 200MHz below the minimum doesn't seem really reasonable. What is the issue that you are trying to fix here? It looks like it's picking bad dividers, but if that's the case, this isn't the proper fix. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
On Tue, Jan 22, 2019 at 05:21:08PM +0530, Jagan Teki wrote: > On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard > wrote: > > > > On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote: > > > On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki > > > wrote: > > > > > > > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard > > > > wrote: > > > > > > > > > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote: > > > > > > > > > > > Again, I cannot help you without the datasheet for the > > > > > > > > > > > panels you're > > > > > > > > > > > trying to submit. > > > > > > > > > > > > > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > > > > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > > > > > > > > > > > > > It's the controller, not the panel > > > > > > > > > > > > > > > > As I said before, the datasheet of that panel doesn't have any > > > > > > > > information except electrical characteristics and used IC which > > > > > > > > is > > > > > > > > ST7701. > > > > > > > > > > > > > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 > > > > > > > > ICN621 > > > > > > > > please find the attachment for the same. > > > > > > > > > > > > > > > > Here is some more details of the same. > > > > > > > > > > > > > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81 > > > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > > > matches timings for > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > > > > > Where did you get the timings from then? > > > > > > > > > > > > You mean drm_mode timings, the same panel with RGB available in > > > > > > panel-simple[1], and dsi driver in Mailing list[2] and actual DSI > > > > > > sequence commands from BSP[3] > > > > > > > > > > > > [1] > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > > > [3] > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > > > > > So you had no reliable source for the timings then? How do you know if > > > > > all your patches that are timing related are right then? > > > > > > > > I don't understand your point, or may be I confused with many links > > > > that I attached in previous mail. > > > > > > > > 1. Patch for same panel timings are already in Mainline that was > > > > tested on one of the board. [1] > > > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > > > > > Do you think the above two points are not valid sources? > > > > > > fyi, the panel datasheet attached in above mail has timing information. > > > > Do you have a page number? > > Page 4 > 5.2 Interface Timings Which datasheet are we talking about here? The only one I've seen is the Sitronix IC's and the page 4 is the summary. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/i915/dsi: Call drm_connector_cleanup on vlv_dsi_init error exit path
On Sat, Dec 01, 2018 at 12:31:48PM +0100, Hans de Goede wrote:
> If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
> we've already called drm_connector_init() and we should call
> drm_connector_cleanup() to unregister the connector object.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/vlv_dsi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> index d72ccf557a9c..7ca5aafcdf93 100644
> --- a/drivers/gpu/drm/i915/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> @@ -1861,7 +1861,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
>
> if (!fixed_mode) {
> DRM_DEBUG_KMS("no fixed mode\n");
> - goto err;
> + goto err_cleanup_connector;
> }
>
> connector->display_info.width_mm = fixed_mode->width_mm;
> @@ -1874,6 +1874,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
>
> return;
>
> +err_cleanup_connector:
> + drm_connector_cleanup(&intel_connector->base);
> err:
> drm_encoder_cleanup(&intel_encoder->base);
> kfree(intel_dsi);
> --
> 2.19.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm: Sync errno values for property lookup errors
On Tue, Jan 22, 2019 at 10:39:38AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use ENOENT consistently for the case where the requested property
> > isn't found, and EINVAL for the case where the object has no
> > properties whatsoever. Currenrly these are handled differently
> > in the atomic and legacy codepaths.
> >
> > Signed-off-by: Ville Syrjälä
>
> Matches
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
>
> Reviewed-by: Daniel Vetter
>
> Any igts that blow up with this? We should have at least some trying to do
> invalid stuff ...
Looks like there was something caught by ci. I'll have to look those
over.
Also the logs seem to full of my
<7> [625.952666] [drm:drm_modeset_backoff] Retrying to avoid deadlock
Not sure if that debug print is a good idea after all :/
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> > drivers/gpu/drm/drm_mode_object.c | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 06390307e5a3..2a54f826cf65 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -1330,7 +1330,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> > obj_id);
> > drm_mode_object_put(obj);
> > - ret = -ENOENT;
> > + ret = -EINVAL;
> > goto out;
> > }
> >
> > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > b/drivers/gpu/drm/drm_mode_object.c
> > index e8dac94d576d..31730d935842 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ b/drivers/gpu/drm/drm_mode_object.c
> > @@ -527,6 +527,7 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
> > *dev, void *data,
> > property = drm_mode_obj_find_prop_id(arg_obj, arg->prop_id);
> > if (!property) {
> > DRM_DEBUG_KMS("Unknown property ID %d\n", arg->prop_id);
> > + ret = -ENOENT;
> > goto out_unref;
> > }
> >
> > --
> > 2.19.2
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm: Add debug prints for the various object lookup errors
On Tue, Jan 22, 2019 at 10:38:30AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 10:24:28PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Only some of the drm mode object lookups have a corresponding debug
> > print for the lookup failure. That makes logs a bit hard to parse
> > when you can't see where the bad object ID is being used. Add a bunch
> > more debug prints, and unify their appearance.
> >
> > Signed-off-by: Ville Syrjälä
>
> Instead of sprinkling these all over, what about the reverse route and
> pushing this into drm_mode_object_find? We can dump id + object type, that
> should be all we need really.
I suppose. Downside being that the debug then won't tell you who called
the _find(). Although with the atomic ioctl we really don't have much
information anyway since we didn't include the type of the object in the
ioctl struct. Perhaps that was a mistake.
> If we go this way maybe add kerneldoc to the
> various drm_*_find/lookup functions so this doesn't get copypasted again
> ...
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 5 +
> > drivers/gpu/drm/drm_color_mgmt.c | 8 ++--
> > drivers/gpu/drm/drm_connector.c | 5 -
> > drivers/gpu/drm/drm_crtc.c| 12 +++-
> > drivers/gpu/drm/drm_encoder.c | 4 +++-
> > drivers/gpu/drm/drm_framebuffer.c | 4 +++-
> > drivers/gpu/drm/drm_mode_object.c | 17 ++---
> > drivers/gpu/drm/drm_plane.c | 13 +
> > drivers/gpu/drm/drm_property.c| 12 +---
> > drivers/gpu/drm/drm_vblank.c | 8 ++--
> > 10 files changed, 66 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 9a1f41adfc67..06390307e5a3 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -1321,11 +1321,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >
> > obj = drm_mode_object_find(dev, file_priv, obj_id,
> > DRM_MODE_OBJECT_ANY);
> > if (!obj) {
> > + DRM_DEBUG_ATOMIC("Unknown object ID %d\n", obj_id);
> > ret = -ENOENT;
> > goto out;
> > }
> >
> > if (!obj->properties) {
> > + DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> > +obj_id);
> > drm_mode_object_put(obj);
> > ret = -ENOENT;
> > goto out;
> > @@ -1352,6 +1355,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> >
> > prop = drm_mode_obj_find_prop_id(obj, prop_id);
> > if (!prop) {
> > + DRM_DEBUG_ATOMIC("Unknown property ID %d\n",
> > +prop_id);
> > drm_mode_object_put(obj);
> > ret = -ENOENT;
> > goto out;
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 07dcf47daafe..a99ee15b8328 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -245,8 +245,10 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> > return -EOPNOTSUPP;
> >
> > crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> > - if (!crtc)
> > + if (!crtc) {
> > + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> > return -ENOENT;
> > + }
> >
> > if (crtc->funcs->gamma_set == NULL)
> > return -ENOSYS;
> > @@ -313,8 +315,10 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> > return -EOPNOTSUPP;
> >
> > crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> > - if (!crtc)
> > + if (!crtc) {
> > + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> > return -ENOENT;
> > + }
> >
> > /* memcpy into gamma store */
> > if (crtc_lut->gamma_size != crtc->gamma_size)
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 847539645558..8745eb132fd4 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1952,8 +1952,11 @@ int drm_mode_getconnector(struct drm_device *dev,
> > void *data,
> > memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
> >
> > connector = drm_connector_lookup(dev, file_priv,
> > out_resp->connector_id);
> > - if (!connector)
> > + if (!connector) {
> > + DRM_DEBUG_KMS("Unknown connector ID %d\n",
> > + out_resp->connector_id);
> > return -ENOENT;
> > + }
> >
> > drm_connector_for_each_possible_encoder(connector, encoder, i)
> > encoders_count++;
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 7dabbaf033a1..e5f234ffcd23 1
Re: [PATCH v5 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Hi Jagan.
Looks good, only very few nits left.
On Sat, Jan 26, 2019 at 12:52:33AM +0530, Jagan Teki wrote:
> Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
>
> Add panel driver for it.
>
> Tested-by: Bhushan Shah
> Signed-off-by: Jagan Teki
If you consider my inputs (I know you will) then you can add my:
Reviewed-by: Sam Ravnborg
> + msleep(20);
> +
> + gpiod_set_value(ctx->reset, 0);
> + /* T5 + T6 (avdd rise + video & logic signal rise)
> + * T5 >= 10ms, 0 < T6 <= 10ms
> + */
> + msleep(20);
Please use kernel coding style comment, and maybe an empty
line between gpiod...() and the comment:
gpiod_set_value(ctx->reset, 0);
/*
* T5 + T6 (avdd rise + video & logic signal rise)
* T5 >= 10ms, 0 < T6 <= 10ms
*/
msleep(20);
> +static int feiyang_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct feiyang *ctx = panel_to_feiyang(panel);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, &feiyang_default_mode);
> + if (!mode) {
> + DRM_DEV_ERROR(&ctx->dsi->dev, "failed to add mode %ux%ux@%u\n",
> + feiyang_default_mode.hdisplay,
> + feiyang_default_mode.vdisplay,
> + feiyang_default_mode.vrefresh);
Please consider to use DRM_MODE_FMT and DRM_MODE_ARG for printing.
> +static const struct of_device_id feiyang_of_match[] = {
> + { .compatible = "feiyang,fy07024di26a30d", },
> + { }
Maybe use { /* sentinel */ },
?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
Add panel driver for it.
Tested-by: Bhushan Shah
Signed-off-by: Jagan Teki
---
Changes for v5:
- drop drmP.h header
- order include files
- add empty line after kzalloc()
- drop gpio set for reset
- drop backlight put_device from probe()
- drop backlight put_device from remove()
- collect Tested-by from Bhushan Shah
Changes for v4:
- rebase on master
- adjust the hporch values to satisfy the refresh
Changes for v3:
- use simple structure for command init
- update proper comments on power, reset delay sequnce
- fix to use set_display_off in disable function
- move mode type to structure
- drop refres rate value, let drm compute
Changes for v2:
- new patch, derived from another dsi series
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 269 ++
4 files changed, 285 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e3f785bad68b..5c8591eb5840 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4831,6 +4831,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
S: Maintained
F: drivers/gpu/drm/tve200/
+DRM DRIVER FOR FEIYANG FY07024DI26A30-D MIPI-DSI LCD PANELS
+M: Jagan Teki
+S: Maintained
+F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+F:
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
+
DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 151ddf720b83..5304db7b7b55 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -47,6 +47,15 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_FEIYANG_FY07024DI26A30D
+ tristate "Feiyang FY07024DI26A30-D MIPI-DSI LCD panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y if you want to enable support for panels based on the
+ Feiyang FY07024DI26A30-D MIPI-DSI interface.
+
config DRM_PANEL_ILITEK_IL9322
tristate "Ilitek ILI9322 320x240 QVGA panels"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 54db0921f329..c88dacf9d439 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BANANAPI_S070WV20_ICN6211) +=
panel-bananapi-s070wv20-icn6211.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
new file mode 100644
index ..d5c608170e09
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions
+ * Author: Jagan Teki
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FEIYANG_INIT_CMD_LEN 2
+
+struct feiyang {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct backlight_device *backlight;
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct gpio_desc*reset;
+};
+
+static inline struct feiyang *panel_to_feiyang(struct drm_panel *panel)
+{
+ return container_of(panel, struct feiyang, panel);
+}
+
+struct feiyang_init_cmd {
+ u8 data[FEIYANG_INIT_CMD_LEN];
+};
+
+static const struct feiyang_init_cmd feiyang_init_cmds[] = {
+ { .data = { 0x80, 0x58 } },
+ { .data = { 0x81, 0x47 } },
+ { .data = { 0x82, 0xD4 } },
+ { .data = { 0x83, 0x88 } },
+ { .data = { 0x84, 0xA9 } },
+ { .data = { 0x85, 0xC3 } },
+ { .data = { 0x86, 0x82 } },
+};
+
+static int feiyang_prepare(struct drm_panel *panel)
+{
+ struct feiyang *ctx = panel_to_feiyang(panel);
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ unsigned int i;
+ int ret;
+
+ ret = regulator_enable(ctx->dvdd);
+ if (ret)
+ return ret;
+
+ /* T1 (dvdd start + dvdd rise) 0 < T1 <= 10ms */
+ msleep(10);
+
+ ret = regulator_enable(ctx->avdd);
+ if (ret)
+
[PATCH v5 1/2] dt-bindings: panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v5, v4, v3:
- none
Changes for v2:
- new patch, derived from another dsi series
.../display/panel/feiyang,fy07024di26a30d.txt | 20 +++
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
new file mode 100644
index ..82caa7b65ae8
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt
@@ -0,0 +1,20 @@
+Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
+
+Required properties:
+- compatible: must be "feiyang,fy07024di26a30d"
+- reg: DSI virtual channel used by that screen
+- avdd-supply: analog regulator dc1 switch
+- dvdd-supply: 3v3 digital regulator
+- reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+- backlight: phandle for the backlight control.
+
+panel@0 {
+ compatible = "feiyang,fy07024di26a30d";
+ reg = <0>;
+ avdd-supply = <®_dc1sw>;
+ dvdd-supply = <®_dldo2>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
+ backlight = <&backlight>;
+};
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 16/22] arm64: dts: allwinner: a64: Add DSI pipeline
On Fri, Jan 25, 2019 at 01:28:54AM +0530, Jagan Teki wrote:
> The A64 has a MIPI-DSI block which is similar to A31.
>
> Add dsi, dphy nodes with A31 fallback compatible and finally
> connect the dsi node to tcon0 node to make proper DSI pipeline.
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 47 +++
> 1 file changed, 47 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index cdc154b14a7e..e18d81aff813 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -358,6 +358,12 @@
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
> +
> + tcon0_out_dsi: endpoint@1 {
> + reg = <1>;
> + remote-endpoint =
> <&dsi_in_tcon0>;
> + allwinner,tcon-channel = <1>;
> + };
> };
> };
> };
> @@ -935,6 +941,47 @@
> status = "disabled";
> };
>
> + dsi: dsi@1ca {
> + compatible = "allwinner,sun50i-a64-mipi-dsi",
> + "allwinner,sun6i-a31-mipi-dsi";
> + reg = <0x01ca 0x1000>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> + <&ccu CLK_DSI_DPHY>;
This one looks weird. There's only a single clock in the A64, and it
seems to be for the D-PHY only.
And the rate is fixed at 148.5 MHz apparently, as opposed to the
current code that is running at twice that speed.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #15 from tme --- I've been attempting to perform a bisect on an off for a while now with no success. The main problem I'm running into is this error when trying to compile. RELOCS arch/x86/boot/compressed/vmlinux.relocs Unsupported relocation type: R_X86_64_PLT32 (4) make[4]: *** [arch/x86/boot/compressed/Makefile:123: arch/x86/boot/compressed/vmlinux.relocs] Error 1 make[3]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2 make[2]: *** [arch/x86/Makefile:299: bzImage] Error 2 make[1]: *** [scripts/package/Makefile:96: bindeb-pkg] Error 2 make: *** [Makefile:1386: bindeb-pkg] Error 2 I've tried searching for solutions for this problem, but I haven't found anything. It occurs when I run "make -j4 deb-pkg" and "make bzImage". If anyone can help me solve this, I'd be happy to start bisecting again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 18/23] drm/qxl: remove dead qxl fbdev emulation code
Den 25.01.2019 19.10, skrev Sam Ravnborg: > Hi Noralf. > >>> Lovely diffstat, thanks to the new generic fbdev emulation. >>> >>> drm/qxl/Makefile |2 >>> drm/qxl/qxl_draw.c | 232 >>> drm/qxl/qxl_drv.h | 21 --- >>> drm/qxl/qxl_fb.c | 300 >>> - >>> >>> Signed-off-by: Gerd Hoffmann >>> --- >>> drivers/gpu/drm/qxl/qxl_drv.h | 21 --- >>> drivers/gpu/drm/qxl/qxl_draw.c | 232 --- >>> drivers/gpu/drm/qxl/qxl_fb.c | 300 >>> - >>> drivers/gpu/drm/qxl/Makefile | 2 +- >>> 4 files changed, 1 insertion(+), 554 deletions(-) >>> delete mode 100644 drivers/gpu/drm/qxl/qxl_fb.c >>> >> >> Nice! >> >> Acked-by: Noralf Trønnes > It must be a very satisfying experience to see such benefits > of the many hours of works you have put into the genric > fbdev emulation code. Indeed and having more users of the code increases the chance of detecting any bugs lurking underneath the surface. > Well done, and indeed a nice patch from Gerd. > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/26] drm/fb_helper: set info->par in fill_info()
On Fri, Jan 25, 2019 at 09:44:06AM +0100, Daniel Vetter wrote: > On Thu, Jan 24, 2019 at 06:45:52PM +0100, Sam Ravnborg wrote: > > Hi Daniel. > > > > On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote: > > > The fbdev emulation helpers pretty much assume that this is set. > > > Let's do it for everyone. > > > > I do not know this code at all. > > But I failed to follow the code from the patch description. > > > > It do not give _me_ a clue why the assignment is removed from > > drm_fb_helper_generic_probe(). > > But it may be obvious for people that actually know this. > > generic_probe calls the new fill_info function, so it's not removed, it's > just moved, so that I can roll it out to all the drivers in the subsequent > patches. Obvious new you spell it out, thanks. Patch is fine: Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vmwgfx: Use ttm_dma_page_alloc_enabled
Hi Thomas.
One little nit, and an improvment proposal (for another patch/day).
On Fri, Jan 25, 2019 at 02:05:48PM +0100, Thomas Hellstrom wrote:
> Instead of guessing whether TTM has the dma page allocator enabled,
> ask TTM.
>
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 77f422cd18ab..125a2b423847 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> #define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices"
> #define VMWGFX_CHIP_SVGAII 0
> @@ -594,8 +595,7 @@ static int vmw_dma_select_mode(struct vmw_private
> *dev_priv)
> if (dev_priv->map_mode == vmw_dma_map_populate && vmw_restrict_iommu)
> dev_priv->map_mode = vmw_dma_map_bind;
>
> - /* No TTM coherent page pool? FIXME: Ask TTM instead! */
> -if (!(IS_ENABLED(CONFIG_SWIOTLB) || IS_ENABLED(CONFIG_INTEL_IOMMU))
> &&
> +if (!ttm_dma_page_alloc_enabled() &&
The line uses spaces for indent, tabs?
> (dev_priv->map_mode == vmw_dma_alloc_coherent))
The code could benefit from a:
static bool is_map_coherent(const struct vmw_private *dev_priv)
{
return dev_priv->map_mode == vmw_dma_alloc_coherent;
}
Then the above would become:
if (!ttm_dma_page_alloc_enabled() && is_map_coherent(dev_priv))
And the other places that test for vmw_dma_alloc_coherent
would be a bit simpler too.
Same goes for the other map types obviously.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 14/15] drm/i915/tv: Fix >1024 modes on gen3
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On gen3 we must disable the TV encoder vertical filter for >1024
> > pixel wide sources. Once that's done all we can is try to center
> > the image on the screen. Naturally the TV mode vertical resolution
> > must be equal or larger than the user mode vertical resolution
> > or else we'd have to cut off part of the user mode.
> >
> > And while we may not be able to respect the user's choice of
> > top and bottom borders exactly (or we'd have to reject he mode
> > most likely), we can try to maintain the relative sizes of the
> > top and bottom border with respect to each orher.
> >
> > Additionally we must configure the pipe as interlaced if the
> > TV mode is interlaced.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_tv.c | 100 +---
> > 1 file changed, 92 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 75126fce655d..7099d837e31a 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -861,6 +861,44 @@ static const struct tv_mode tv_modes[] = {
> > },
> > };
> >
> > +struct intel_tv_connector_state {
> > + struct drm_connector_state base;
> > +
> > + /*
> > +* May need to override the user margins for
> > +* gen3 >1024 wide source vertical centering.
> > +*/
> > + struct {
> > + u16 top, bottom;
> > + } margins;
> > +
> > + bool bypass_vfilter;
> > +};
> > +
> > +#define to_intel_tv_connector_state(x) container_of(x, struct
> > intel_tv_connector_state, base)
> > +
> > +/**
> > + * intel_digital_connector_duplicate_state - duplicate connector state
> ^intel_tv_connector_duplicate_state
> > + * @connector: digital connector
> ^tv connector?
Copy paste fail. I just dropped the kerneldoc here and made the
function static. Also fixed up the s/IS_GEN3(x)/IS_GEN(x,3)/ type
of things and pushed the lot to dinq.
Thanks for the review.
> > + *
> > + * Allocates and returns a copy of the connector state (both common and
> > + * digital connector specific) for the specified connector.
> > + *
> > + * Returns: The newly allocated connector state, or NULL on failure.
> > + */
> > +struct drm_connector_state *
> > +intel_tv_connector_duplicate_state(struct drm_connector *connector)
> > +{
> > + struct intel_tv_connector_state *state;
> > +
> > + state = kmemdup(connector->state, sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return NULL;
> > +
> > + __drm_atomic_helper_connector_duplicate_state(connector, &state->base);
> > + return &state->base;
> > +}
>
> You didn't add the corresponding checks for the new
> intel_tv_connector_state fields to intel_tv_atomic_check(). I suppose
> that's ok since something resulting in a change in those will force a
> modeset anyway:
>
> Reviewed-by: Imre Deak
>
> > +
> > static struct intel_tv *enc_to_tv(struct intel_encoder *encoder)
> > {
> > return container_of(encoder, struct intel_tv, base);
> > @@ -1129,6 +1167,9 @@ intel_tv_compute_config(struct intel_encoder *encoder,
> > struct intel_crtc_state *pipe_config,
> > struct drm_connector_state *conn_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + struct intel_tv_connector_state *tv_conn_state =
> > + to_intel_tv_connector_state(conn_state);
> > const struct tv_mode *tv_mode = intel_tv_mode_find(conn_state);
> > struct drm_display_mode *adjusted_mode =
> > &pipe_config->base.adjusted_mode;
> > @@ -1149,6 +1190,43 @@ intel_tv_compute_config(struct intel_encoder
> > *encoder,
> > pipe_config->port_clock = tv_mode->clock;
> >
> > intel_tv_mode_to_mode(adjusted_mode, tv_mode);
> > + drm_mode_set_crtcinfo(adjusted_mode, 0);
> > +
> > + if (IS_GEN3(dev_priv) && hdisplay > 1024) {
> > + int extra, top, bottom;
> > +
> > + extra = adjusted_mode->crtc_vdisplay - vdisplay;
> > +
> > + if (extra < 0) {
> > + DRM_DEBUG_KMS("No vertical scaling for >1024 pixel wide
> > modes\n");
> > + return false;
> > + }
> > +
> > + /* Need to turn off the vertical filter and center the image */
> > +
> > + /* Attempt to maintain the relative sizes of the margins */
> > + top = conn_state->tv.margins.top;
> > + bottom = conn_state->tv.margins.bottom;
> > +
> > + if (top + bottom)
> > + top = extra * top / (top + bottom);
> > + else
> > + top = extra / 2;
> > + bottom = extra - top;
> > +
> > + tv_conn_state->margins.top = top;
> > + tv_conn_state->margins.bottom = bottom;
> > +
> > +
Re: [PATCH v3 18/23] drm/qxl: remove dead qxl fbdev emulation code
Hi Noralf. > > Lovely diffstat, thanks to the new generic fbdev emulation. > > > > drm/qxl/Makefile |2 > > drm/qxl/qxl_draw.c | 232 > > drm/qxl/qxl_drv.h | 21 --- > > drm/qxl/qxl_fb.c | 300 > > - > > > > Signed-off-by: Gerd Hoffmann > > --- > > drivers/gpu/drm/qxl/qxl_drv.h | 21 --- > > drivers/gpu/drm/qxl/qxl_draw.c | 232 --- > > drivers/gpu/drm/qxl/qxl_fb.c | 300 > > - > > drivers/gpu/drm/qxl/Makefile | 2 +- > > 4 files changed, 1 insertion(+), 554 deletions(-) > > delete mode 100644 drivers/gpu/drm/qxl/qxl_fb.c > > > > Nice! > > Acked-by: Noralf Trønnes It must be a very satisfying experience to see such benefits of the many hours of works you have put into the genric fbdev emulation code. Well done, and indeed a nice patch from Gerd. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm/vc4: Wait for display list synchronization when completing commit
Paul Kocialkowski writes:
> Hi,
>
> On Wed, 2019-01-23 at 10:34 -0800, Eric Anholt wrote:
>> Paul Kocialkowski writes:
>>
>> > During an atomic commit, the HVS is configured with a display list
>> > for the channel matching the associated CRTC. The Pixel Valve (CRTC)
>> > and encoder are also configured for the new setup at that time.
>> > While the Pixel Valve and encoder are reconfigured synchronously, the
>> > HVS is only reconfigured after the display list address (DISPLIST) has
>> > been updated to the current display list address (DISPLACTX), which is
>> > the responsibility of the hardware.
>> >
>> > The time frame during which the HVS is still running on its previous
>> > configuration but the CRTC and encoder have been reconfigured already
>> > can lead to a number of synchronization issues. They will eventually
>> > cause errors reported on the FIFOs, such as underruns.
>> >
>> > With underrun detection enabled (from Boris Brezillon's series), this
>> > leads to unreliable underrun detection with random false positives.
>> >
>> > To ensure a coherent state, wait for each enabled channel of the HVS
>> > to synchronize its current display list address. This fixes the issue
>> > of random underrun reporting on commits.
>> >
>> > Signed-off-by: Paul Kocialkowski
>> > ---
>> > drivers/gpu/drm/vc4/vc4_drv.h | 1 +
>> > drivers/gpu/drm/vc4/vc4_hvs.c | 17 +
>> > drivers/gpu/drm/vc4/vc4_kms.c | 2 ++
>> > drivers/gpu/drm/vc4/vc4_regs.h | 2 ++
>> > 4 files changed, 22 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
>> > index c24b078f0593..955f157f5ad0 100644
>> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
>> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
>> > @@ -772,6 +772,7 @@ void vc4_irq_reset(struct drm_device *dev);
>> > extern struct platform_driver vc4_hvs_driver;
>> > void vc4_hvs_dump_state(struct drm_device *dev);
>> > int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
>> > +void vc4_hvs_sync_dlist(struct drm_device *dev);
>> >
>> > /* vc4_kms.c */
>> > int vc4_kms_load(struct drm_device *dev);
>> > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
>> > index 5d8c749c9749..1ba60b8e0c2d 100644
>> > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
>> > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
>> > @@ -166,6 +166,23 @@ static int vc4_hvs_upload_linear_kernel(struct
>> > vc4_hvs *hvs,
>> >return 0;
>> > }
>> >
>> > +void vc4_hvs_sync_dlist(struct drm_device *dev)
>> > +{
>> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
>> > + unsigned int i;
>> > + int ret;
>> > +
>> > + for (i = 0; i < SCALER_CHANNELS_COUNT; i++) {
>> > + if (!(HVS_READ(SCALER_DISPCTRLX(i)) & SCALER_DISPCTRLX_ENABLE))
>> > + continue;
>> > +
>> > + ret = wait_for(HVS_READ(SCALER_DISPLACTX(i)) ==
>> > + HVS_READ(SCALER_DISPLISTX(i)), 1000);
>> > + WARN(ret, "Timeout waiting for channel %d display list sync\n",
>> > + i);
>> > + }
>> > +}
>> > +
>> > static int vc4_hvs_bind(struct device *dev, struct device *master, void
>> > *data)
>> > {
>> >struct platform_device *pdev = to_platform_device(dev);
>> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
>> > index 0490edb192a1..2d66a2b57a91 100644
>> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
>> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
>> > @@ -155,6 +155,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state
>> > *state)
>> >
>> >drm_atomic_helper_commit_hw_done(state);
>> >
>> > + vc4_hvs_sync_dlist(dev);
>> > +
>> >drm_atomic_helper_wait_for_flip_done(dev, state);
>>
>> wait_for_flip_done should already be waiting for DISPLACTX to match our
>> crtc's display list, though, right (see vc4_crtc_handle_page_flip())?
>> This seems like a no-op to me.
>
> Right, at this stage it's pretty much a no-op. It does make a
> difference when bringing-in vc4_hvs_unmask_underrun, because this
> vc4_hvs_sync_dlist call comes before it.
>
> When the display lists are not yet synchronized (and differ), an
> underrun occurs so it will be reported although it's not related to the
> new display list configuration. Waiting for the display lists to sync
> before unmasking the interrupt prevents that.
>
> I think waiting for the page flip to unmask the underrun interrupt
> would be too late because the HVS should have finished processing the
> new dlist by then (but maybe I'm mistaken about that), so we would miss
> the underrun indication.
For load tracking I'm mainly concerned about making sure that we don't
have long-standing underruns -- if the first frame after a modeset is a
little wonky, you probably won't notice it.
Getting a clean modeset sequence would be really nice to have,
just... don't block on that.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop
Re: [PATCH v3 2/4] drm/vc4: Report underrun errors
Paul Kocialkowski writes:
> Hi Eric,
>
> On Wed, 2019-01-23 at 10:47 -0800, Eric Anholt wrote:
>> Paul Kocialkowski writes:
>> > +void vc4_hvs_mask_underrun(struct drm_device *dev)
>> > +{
>> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
>> > + u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
>> > +
>> > + dispctrl &= ~(SCALER_DISPCTRL_DSPEISLUR(0) |
>> > +SCALER_DISPCTRL_DSPEISLUR(1) |
>> > +SCALER_DISPCTRL_DSPEISLUR(2));
>> > +
>> > + HVS_WRITE(SCALER_DISPCTRL, dispctrl);
>> > +}
>> > +
>> > +void vc4_hvs_unmask_underrun(struct drm_device *dev)
>> > +{
>> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
>> > + u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
>> > +
>> > + dispctrl |= SCALER_DISPCTRL_DSPEISLUR(0) |
>> > + SCALER_DISPCTRL_DSPEISLUR(1) |
>> > + SCALER_DISPCTRL_DSPEISLUR(2);
>> > +
>> > + HVS_WRITE(SCALER_DISPSTAT,
>> > +SCALER_DISPSTAT_EUFLOW(0) |
>> > +SCALER_DISPSTAT_EUFLOW(1) |
>> > +SCALER_DISPSTAT_EUFLOW(2));
>> > + HVS_WRITE(SCALER_DISPCTRL, dispctrl);
>> > +}
>> > +
>> > +static void vc4_hvs_report_underrun(struct drm_device *dev)
>> > +{
>> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
>> > +
>> > + atomic_inc(&vc4->underrun);
>> > + DRM_DEV_ERROR(dev->dev, "HVS underrun\n");
>> > +}
>> > +
>> > +static irqreturn_t vc4_hvs_irq_handler(int irq, void *data)
>> > +{
>> > + struct drm_device *dev = data;
>> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
>> > + u32 status;
>> > +
>> > + status = HVS_READ(SCALER_DISPSTAT);
>> > +
>> > + if (status &
>> > + (SCALER_DISPSTAT_EUFLOW(0) | SCALER_DISPSTAT_EUFLOW(1) |
>> > + SCALER_DISPSTAT_EUFLOW(2))) {
>> > + vc4_hvs_mask_underrun(dev);
>> > + vc4_hvs_report_underrun(dev);
>> > + }
>> > +
>> > + HVS_WRITE(SCALER_DISPSTAT, status);
>> > +
>> > + return status ? IRQ_HANDLED : IRQ_NONE;
>> > +}
>>
>> So, if UFLOW is set then we incremented the counter and disabled the
>> interrupt, otherwise we acked this specific interrupt and return? Given
>> that a short-line error (the other potential cause of EISLUR) would be
>> likely to persist, we should probably either vc4_hvs_mask_underrun() in
>> that case too, or only return IRQ_HANDLED for the case we actually
>> handled.
>
> I see, there is definitely an inconsistency here. I don't think we
> should be disabling the interrupt if we get a short line indication,
> just in case the interrupt gets triggered later for a legitimate
> underrun (before the next commit).
>
> So I think we should just totally ignore the short line status bit for
> the IRQ return (although it certainly doesn't hurt to clear it as
> well). What do you think?
You just have to make sure that you return UNHANDLED for short line, so
an IRQ storm doesn't take down the machine.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 22/23] drm/qxl: use kernel mode db
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Add all standard modes from the kernel's video mode data base. > Keep a few non-standard modes in the qxl mode list. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 21/23] drm/qxl: add qxl_add_mode helper function
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Add a helper function to add custom video modes to a connector. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 20/23] drm/qxl: add mode/framebuffer check functions
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Add a helper functions to check video modes. Also add a helper to check > framebuffer buffer objects, using the former for consistency. That way > we should not fail in qxl_primary_atomic_check() because video modes > which are too big will not be added to the mode list in the first place. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 19/23] drm/qxl: implement qxl_gem_prime_(un)pin
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 18/23] drm/qxl: remove dead qxl fbdev emulation code
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Lovely diffstat, thanks to the new generic fbdev emulation. > > drm/qxl/Makefile |2 > drm/qxl/qxl_draw.c | 232 > drm/qxl/qxl_drv.h | 21 --- > drm/qxl/qxl_fb.c | 300 > - > > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/qxl/qxl_drv.h | 21 --- > drivers/gpu/drm/qxl/qxl_draw.c | 232 --- > drivers/gpu/drm/qxl/qxl_fb.c | 300 > - > drivers/gpu/drm/qxl/Makefile | 2 +- > 4 files changed, 1 insertion(+), 554 deletions(-) > delete mode 100644 drivers/gpu/drm/qxl/qxl_fb.c > Nice! Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108854] [polaris11] - GPU Hang - ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108854 Alex Deucher changed: What|Removed |Added Component|DRM/AMDgpu |Drivers/Gallium/radeonsi Product|DRI |Mesa QA Contact||dri-devel@lists.freedesktop ||.org Version|DRI git |unspecified -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 17/23] drm/qxl: use generic fbdev emulation
Den 18.01.2019 13.20, skrev Gerd Hoffmann:
> Switch qxl over to the new generic fbdev emulation.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 7 ---
> drivers/gpu/drm/qxl/qxl_drv.c | 2 ++
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index ef832f98ab..9c751f01e3 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -1221,18 +1221,11 @@ int qxl_modeset_init(struct qxl_device *qdev)
> qxl_display_read_client_monitors_config(qdev);
>
> drm_mode_config_reset(&qdev->ddev);
> -
> - /* primary surface must be created by this point, to allow
> - * issuing command queue commands and having them read by
> - * spice server. */
> - qxl_fbdev_init(qdev);
> return 0;
> }
>
> void qxl_modeset_fini(struct qxl_device *qdev)
> {
> - qxl_fbdev_fini(qdev);
> -
> qxl_destroy_monitors_object(qdev);
> drm_mode_config_cleanup(&qdev->ddev);
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 13c8a662f9..3fce7d16df 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -93,6 +93,8 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> if (ret)
> goto modeset_cleanup;
>
> + drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, "qxl");
I couldn't find that this was part of old fbdev code, so it would be
nice to mention it in the commit message.
Acked-by: Noralf Trønnes
> + drm_fbdev_generic_setup(&qdev->ddev, 32);
> return 0;
>
> modeset_cleanup:
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108854] [polaris11] - GPU Hang - ring gfx timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #11 from Alex Deucher --- The reset was actually successful. The problem is, userspace components need to be aware of the reset and recreate their contexts. As a workaround, you can kill the problematic app or restart X. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 190971] amdgpu (on Kabini) fails to resume, atombios stuck executing BA98
https://bugzilla.kernel.org/show_bug.cgi?id=190971 Johannes Hirte (johannes.hi...@datenkhaos.de) changed: What|Removed |Added CC||johannes.hirte@datenkhaos.d ||e --- Comment #2 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- I have this on Carrizo. First seen with kernel 4.20, but without log entries. Now I was able to capture the dmesg. Happens sometimes when resuming from S3. The display stays black and it takes several seconds until backlight is coming up. the log: Jan 25 17:34:27 probook kernel: [ 135.573972] Freezing user space processes ... (elapsed 0.003 seconds) done. Jan 25 17:34:27 probook kernel: [ 135.577658] OOM killer disabled. Jan 25 17:34:27 probook kernel: [ 135.577660] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Jan 25 17:34:27 probook kernel: [ 135.579536] printk: Suspending console(s) (use no_console_suspend to debug) Jan 25 17:34:27 probook kernel: [ 135.580086] wlp2s0: deauthenticating from 80:2a:a8:cb:7c:e5 by local choice (Reason: 3=DEAUTH_LEAVING) Jan 25 17:34:27 probook kernel: [ 135.590354] sd 0:0:0:0: [sda] Synchronizing SCSI cache Jan 25 17:34:27 probook kernel: [ 135.590484] sd 0:0:0:0: [sda] Stopping disk Jan 25 17:34:27 probook kernel: [ 137.849234] ACPI: EC: interrupt blocked Jan 25 17:34:27 probook kernel: [ 137.861123] snd_hda_intel :00:09.2: Refused to change power state, currently in D0 Jan 25 17:34:27 probook kernel: [ 137.873161] ACPI: Preparing to enter system sleep state S3 Jan 25 17:34:27 probook kernel: [ 137.875288] ACPI: EC: event blocked Jan 25 17:34:27 probook kernel: [ 137.875290] ACPI: EC: EC stopped Jan 25 17:34:27 probook kernel: [ 137.875291] PM: Saving platform NVS memory Jan 25 17:34:27 probook kernel: [ 137.875308] Disabling non-boot CPUs ... Jan 25 17:34:27 probook kernel: [ 137.877104] smpboot: CPU 1 is now offline Jan 25 17:34:27 probook kernel: [ 137.880333] smpboot: CPU 2 is now offline Jan 25 17:34:27 probook kernel: [ 137.883432] smpboot: CPU 3 is now offline Jan 25 17:34:27 probook kernel: [ 137.885219] ACPI: Low-level resume complete Jan 25 17:34:27 probook kernel: [ 137.885329] ACPI: EC: EC started Jan 25 17:34:27 probook kernel: [ 137.885330] PM: Restoring platform NVS memory Jan 25 17:34:27 probook kernel: [ 137.885410] LVT offset 0 assigned for vector 0x400 Jan 25 17:34:27 probook kernel: [ 137.885794] Enabling non-boot CPUs ... Jan 25 17:34:27 probook kernel: [ 137.885843] x86: Booting SMP configuration: Jan 25 17:34:27 probook kernel: [ 137.885845] smpboot: Booting Node 0 Processor 1 APIC 0x11 Jan 25 17:34:27 probook kernel: [ 137.888495] cache: parent cpu1 should not be sleeping Jan 25 17:34:27 probook kernel: [ 137.888568] microcode: CPU1: patch_level=0x0600611a Jan 25 17:34:27 probook kernel: [ 137.888742] CPU1 is up Jan 25 17:34:27 probook kernel: [ 137.888762] smpboot: Booting Node 0 Processor 2 APIC 0x12 Jan 25 17:34:27 probook kernel: [ 137.891477] cache: parent cpu2 should not be sleeping Jan 25 17:34:27 probook kernel: [ 137.891594] microcode: CPU2: patch_level=0x0600611a Jan 25 17:34:27 probook kernel: [ 137.891745] CPU2 is up Jan 25 17:34:27 probook kernel: [ 137.891780] smpboot: Booting Node 0 Processor 3 APIC 0x13 Jan 25 17:34:27 probook kernel: [ 137.894362] cache: parent cpu3 should not be sleeping Jan 25 17:34:27 probook kernel: [ 137.894466] microcode: CPU3: patch_level=0x0600611a Jan 25 17:34:27 probook kernel: [ 137.894827] CPU3 is up Jan 25 17:34:27 probook kernel: [ 137.895482] ACPI: Waking up from system sleep state S3 Jan 25 17:34:27 probook kernel: [ 137.985315] ACPI: EC: interrupt unblocked Jan 25 17:34:27 probook kernel: [ 138.010007] ACPI: EC: event unblocked Jan 25 17:34:27 probook kernel: [ 138.010605] ACPI: button: The lid device is not compliant to SW_LID. Jan 25 17:34:27 probook kernel: [ 138.010850] [drm] PCIE GART of 1024M enabled (table at 0x00F4). Jan 25 17:34:27 probook kernel: [ 138.010869] smu version 18.56.00 Jan 25 17:34:27 probook kernel: [ 138.017323] sd 0:0:0:0: [sda] Starting disk Jan 25 17:34:27 probook kernel: [ 138.096050] r8169 :01:00.0 enp1s0: Link is Down Jan 25 17:34:27 probook kernel: [ 138.248770] usb 2-1.1: reset high-speed USB device number 3 using ehci-pci Jan 25 17:34:27 probook kernel: [ 138.424764] usb 2-1.3: reset high-speed USB device number 4 using ehci-pci Jan 25 17:34:27 probook kernel: [ 138.523729] [drm] Fence fallback timer expired on ring sdma0 Jan 25 17:34:27 probook kernel: [ 138.571636] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Jan 25 17:34:27 probook kernel: [ 138.571765] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jan 25 17:34:27 probook kernel: [ 138.572172] ata1.00: ACPI cmd f5/00:00:00:00:00:e0 (SECURITY FREEZE LOCK) filtered out J
Re: [PATCH v3 16/23] drm/qxl: implement prime kmap/kunmap
Den 18.01.2019 13.20, skrev Gerd Hoffmann:
> Generic fbdev emulation needs this. Also: We must keep track of the
> number of mappings now, so we don't unmap early in case two users want a
> kmap of the same bo. Add a sanity check to destroy callback to make
> sure kmap/kunmap is balanced.
>
> Signed-off-by: Gerd Hoffmann
> ---
Just a note: You catch the one-to-many kmap type of unbalance, but not
the one-too-many kunmap situation.
Acked-by: Noralf Trønnes
> drivers/gpu/drm/qxl/qxl_drv.h| 1 +
> drivers/gpu/drm/qxl/qxl_object.c | 6 ++
> drivers/gpu/drm/qxl/qxl_prime.c | 17 +
> 3 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 43c6df9cf9..8c3af1cdbe 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -84,6 +84,7 @@ struct qxl_bo {
> struct ttm_bo_kmap_obj kmap;
> unsigned int pin_count;
> void*kptr;
> + unsigned intmap_count;
> int type;
>
> /* Constant after initialization */
> diff --git a/drivers/gpu/drm/qxl/qxl_object.c
> b/drivers/gpu/drm/qxl/qxl_object.c
> index 024c8dd317..4928fa6029 100644
> --- a/drivers/gpu/drm/qxl/qxl_object.c
> +++ b/drivers/gpu/drm/qxl/qxl_object.c
> @@ -36,6 +36,7 @@ static void qxl_ttm_bo_destroy(struct ttm_buffer_object
> *tbo)
> qdev = (struct qxl_device *)bo->gem_base.dev->dev_private;
>
> qxl_surface_evict(qdev, bo, false);
> + WARN_ON_ONCE(bo->map_count > 0);
> mutex_lock(&qdev->gem.mutex);
> list_del_init(&bo->list);
> mutex_unlock(&qdev->gem.mutex);
> @@ -131,6 +132,7 @@ int qxl_bo_kmap(struct qxl_bo *bo, void **ptr)
> if (bo->kptr) {
> if (ptr)
> *ptr = bo->kptr;
> + bo->map_count++;
> return 0;
> }
> r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
> @@ -139,6 +141,7 @@ int qxl_bo_kmap(struct qxl_bo *bo, void **ptr)
> bo->kptr = ttm_kmap_obj_virtual(&bo->kmap, &is_iomem);
> if (ptr)
> *ptr = bo->kptr;
> + bo->map_count = 1;
> return 0;
> }
>
> @@ -180,6 +183,9 @@ void qxl_bo_kunmap(struct qxl_bo *bo)
> {
> if (bo->kptr == NULL)
> return;
> + bo->map_count--;
> + if (bo->map_count > 0)
> + return;
> bo->kptr = NULL;
> ttm_bo_kunmap(&bo->kmap);
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
> index a55dece118..708378844c 100644
> --- a/drivers/gpu/drm/qxl/qxl_prime.c
> +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> @@ -22,7 +22,7 @@
> * Authors: Andreas Pokorny
> */
>
> -#include "qxl_drv.h"
> +#include "qxl_object.h"
>
> /* Empty Implementations as there should not be any other driver for a
> virtual
> * device that might share buffers with qxl */
> @@ -54,13 +54,22 @@ struct drm_gem_object *qxl_gem_prime_import_sg_table(
>
> void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
> {
> - WARN_ONCE(1, "not implemented");
> - return ERR_PTR(-ENOSYS);
> + struct qxl_bo *bo = gem_to_qxl_bo(obj);
> + void *ptr;
> + int ret;
> +
> + ret = qxl_bo_kmap(bo, &ptr);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + return ptr;
> }
>
> void qxl_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
> {
> - WARN_ONCE(1, "not implemented");
> + struct qxl_bo *bo = gem_to_qxl_bo(obj);
> +
> + qxl_bo_kunmap(bo);
> }
>
> int qxl_gem_prime_mmap(struct drm_gem_object *obj,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 15/23] drm/qxl: use qxl_num_crtc directly
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > qdev->monitors_config->max_allowed is effectively set by the > qxl.num_heads module parameter, stored in the qxl_num_crtc variable. > Lets get rid of the indirection and use the variable qxl_num_crtc > directly. The kernel doesn't need to dereference pointers each time it > needs the value, and when reading the code you don't have to trace where > and why qdev->monitors_config->max_allowed is set. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 14/23] drm/qxl: cover all crtcs in shadow bo.
Den 18.01.2019 13.20, skrev Gerd Hoffmann:
> The qxl device supports only a single active framebuffer ("primary
> surface" in spice terminology). In multihead configurations are handled
> by defining rectangles within the primary surface for each head/crtc.
>
> Userspace which uses the qxl ioctl interface (xorg qxl driver) is aware
> of this limitation and will setup framebuffers and crtcs accordingly.
>
> Userspace which uses dumb framebuffers (xorg modesetting driver,
> wayland) is not aware of this limitation and tries to use two
> framebuffers (one for each crtc) instead.
>
> The qxl kms driver already has the dumb bo separated from the primary
> surface, by using a (shared) shadow bo as primary surface. This is
> needed to support pageflips without having to re-create the primary
> surface. The qxl driver will blit from the dumb bo to the shadow bo
> instead.
>
> So we can extend the shadow logic: Maintain a global shadow bo (aka
> primary surface), make it big enough that dumb bo's for all crtcs fit in
> side-by-side. Adjust the pageflip blits to place the heads next to each
> other in the shadow.
>
> With this patch in place multihead qxl works with wayland.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_drv.h | 5 +-
> drivers/gpu/drm/qxl/qxl_display.c | 119
> +-
> drivers/gpu/drm/qxl/qxl_draw.c| 9 ++-
> 3 files changed, 104 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 150b1a4f66..43c6df9cf9 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -230,6 +230,8 @@ struct qxl_device {
> struct qxl_ram_header *ram_header;
>
> struct qxl_bo *primary_bo;
> + struct qxl_bo *dumb_shadow_bo;
> + struct qxl_head *dumb_heads;
>
> struct qxl_memslot main_slot;
> struct qxl_memslot surfaces_slot;
> @@ -437,7 +439,8 @@ void qxl_draw_dirty_fb(struct qxl_device *qdev,
> struct qxl_bo *bo,
> unsigned int flags, unsigned int color,
> struct drm_clip_rect *clips,
> -unsigned int num_clips, int inc);
> +unsigned int num_clips, int inc,
> +uint32_t dumb_shadow_offset);
>
> void qxl_draw_fill(struct qxl_draw_fill *qxl_draw_fill_rec);
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index ff13bc6a4a..d9de43e5fd 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -323,6 +323,8 @@ static void qxl_crtc_update_monitors_config(struct
> drm_crtc *crtc,
> head.y = crtc->y;
> if (qdev->monitors_config->count < i + 1)
> qdev->monitors_config->count = i + 1;
> + if (qdev->primary_bo == qdev->dumb_shadow_bo)
> + head.x += qdev->dumb_heads[i].x;
> } else if (i > 0) {
> head.width = 0;
> head.height = 0;
> @@ -426,7 +428,7 @@ static int qxl_framebuffer_surface_dirty(struct
> drm_framebuffer *fb,
> }
>
> qxl_draw_dirty_fb(qdev, fb, qobj, flags, color,
> - clips, num_clips, inc);
> + clips, num_clips, inc, 0);
>
> drm_modeset_unlock_all(fb->dev);
>
> @@ -535,6 +537,7 @@ static void qxl_primary_atomic_update(struct drm_plane
> *plane,
> .x2 = plane->state->fb->width,
> .y2 = plane->state->fb->height
> };
> + uint32_t dumb_shadow_offset = 0;
>
> if (old_state->fb) {
> bo_old = gem_to_qxl_bo(old_state->fb->obj[0]);
> @@ -551,7 +554,12 @@ static void qxl_primary_atomic_update(struct drm_plane
> *plane,
> qxl_primary_apply_cursor(plane);
> }
>
> - qxl_draw_dirty_fb(qdev, plane->state->fb, bo, 0, 0, &norect, 1, 1);
> + if (bo->is_dumb)
> + dumb_shadow_offset =
> + qdev->dumb_heads[plane->state->crtc->index].x;
> +
> + qxl_draw_dirty_fb(qdev, plane->state->fb, bo, 0, 0, &norect, 1, 1,
> + dumb_shadow_offset);
> }
>
> static void qxl_primary_atomic_disable(struct drm_plane *plane,
> @@ -707,12 +715,68 @@ static void qxl_cursor_atomic_disable(struct drm_plane
> *plane,
> qxl_release_fence_buffer_objects(release);
> }
>
> +static void qxl_update_dumb_head(struct qxl_device *qdev,
> + int index, struct qxl_bo *bo)
> +{
> + uint32_t width, height;
> +
> + if (index >= qdev->monitors_config->max_allowed)
> + return;
> +
> + if (bo && bo->is_dumb) {
> + width = bo->surf.width;
> + height = bo->surf.height;
> + } else {
> + width = 0;
> + height = 0;
> + }
> +
> + if (qdev->dumb_heads[index].width == width &&
> + qdev->dumb_heads[index].height == height)
> +
Re: [PATCH v3 13/23] drm/qxl: use shadow bo directly
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Pass the shadow bo to qxl_io_create_primary() instead of expecting > qxl_io_create_primary to check bo->shadow. Set is_primary flag on the > shadow bo. Move the is_primary tracking into qxl_io_create_primary() > and qxl_io_destroy_primary() functions. > > That simplifies primary surface tracking and the workflow in > qxl_primary_atomic_update(). > > Signed-off-by: Gerd Hoffmann > > qxl_io_create/destroy_primary: primary_bo tracking [fixup] > --- I'm unable to follow the logic, but I didn't spot anything suspicious looking. Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] phy: Add driver for mixel dphy
Hi Guido.
Patch looks good but a few comments below.
Sam
On Fri, Jan 25, 2019 at 11:14:46AM +0100, Guido Günther wrote:
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
> added once the necessary system controller bits are in via
> mixel_dpy_ops.
>
> Signed-off-by: Guido Günther
> ---
> drivers/phy/Kconfig | 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-mixel-mipi-dphy.c | 449 ++
> 3 files changed, 457 insertions(+)
> create mode 100644 drivers/phy/phy-mixel-mipi-dphy.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 250abe290ca1..9195b5876bcc 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -48,6 +48,13 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +config PHY_MIXEL_MIPI_DPHY
> + bool
> + depends on OF
> + select GENERIC_PHY
> + select GENERIC_PHY_MIPI_DPHY
> + default ARCH_MXC && ARM64
Is it correct that driver is mandatory if ARCH_MXC is y?
There is no prompt to allow the user to select it.
Or in other words - will all i.MX8 user need it?
> +
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/broadcom/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 0d9fddc498a6..264f570b67bf 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> obj-$(CONFIG_ARCH_RENESAS) += renesas/
> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> +obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-mixel-mipi-dphy.o
> obj-y+= broadcom/\
> cadence/ \
> freescale/ \
> diff --git a/drivers/phy/phy-mixel-mipi-dphy.c
> b/drivers/phy/phy-mixel-mipi-dphy.c
> new file mode 100644
> index ..8a43dab79cee
> --- /dev/null
> +++ b/drivers/phy/phy-mixel-mipi-dphy.c
There is already a PHY named phy-fsl-imx8mq-usb, located in the
freescale subdirectory.
Why locate another imx8 PHY in the top level directory with
another naming convention?
> @@ -0,0 +1,449 @@
> +/*
> + * Copyright 2017 NXP
> + * Copyright 2019 Purism SPC
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
SPDX-License-Identifier goes in at first line with //.
It is documented somewhere.
Also, did you double check that GPL 2.0 is correct?
> +
> +/* #define DEBUG 1 */
There is no reference to DEBUG in this file - delete?
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* DPHY registers */
> +#define DPHY_PD_DPHY 0x00
> +#define DPHY_M_PRG_HS_PREPARE0x04
> +#define DPHY_MC_PRG_HS_PREPARE 0x08
> +#define DPHY_M_PRG_HS_ZERO 0x0c
> +#define DPHY_MC_PRG_HS_ZERO 0x10
> +#define DPHY_M_PRG_HS_TRAIL 0x14
> +#define DPHY_MC_PRG_HS_TRAIL 0x18
> +#define DPHY_PD_PLL 0x1c
> +#define DPHY_TST 0x20
> +#define DPHY_CN 0x24
> +#define DPHY_CM 0x28
> +#define DPHY_CO 0x2c
> +#define DPHY_LOCK0x30
> +#define DPHY_LOCK_BYP0x34
> +#define DPHY_TX_RCAL 0x38
> +#define DPHY_AUTO_PD_EN 0x3c
> +#define DPHY_RXLPRP 0x40
> +#define DPHY_RXCDRP 0x44
> +
> +#define MBPS(x) ((x) * 100)
> +
> +#define DATA_RATE_MAX_SPEED MBPS(1500)
> +#define DATA_RATE_MIN_SPEED MBPS(80)
> +
> +#define CN_BUF 0xcb7a89c0
> +#define CO_BUF 0x63
> +#define CM(x)( \
> + ((x) < 32)?0xe0|((x)-16) : \
> + ((x) < 64)?0xc0|((x)-32) : \
> + ((x) < 128)?0x80|((x)-64) : \
> + ((x) - 128))
> +#define CN(x)(((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
> +#define CO(x)((CO_BUF)>>(8-(x))&0x3)
> +
> +/* PHY power on is LOW_ENABLE */
> +#define PWR_ON 0
> +#define PWR_OFF 1
> +
> +struct mixel_dphy_cfg {
> + u32 cm;
> + u32 cn;
> + u32 co;
> + unsigned long hs_clk_rate;
> + u8 mc_prg_hs_prepare;
> + u8 m_prg_hs_prepare;
> + u8 mc_prg_hs_zero;
> + u8 m_prg_hs_zero;
> + u8 mc_prg_hs_trail;
> + u8 m_prg_hs_trail;
> +};
For the naive reader it would be helpful to spell out the names in a comment.
As I assume the names comes from the data sheet t
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #50 from Shmerl --- I think I know what happened. When I was rebooting, I still had the older kernel running (without the fix), to actually test the new one, so probably the bug still kicked in after reboot. I now rebooted a few more times already from the patched kernel, and I don't see the issue anymore. It also doesn't happen with boot from complete off state. Thanks! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109389] memory leak in `amdgpu_bo_create()`
https://bugs.freedesktop.org/show_bug.cgi?id=109389 --- Comment #3 from Michel Dänzer --- Does this also happen with 4.20.y? If not, can you bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #49 from Shmerl --- Though my tests mostly focused on reboots. Let me double check what happens after actual cold off and boot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #48 from Shmerl --- (In reply to Jerry Zuo from comment #47) > You observed the monitor goes to sleep right after reboot, did you? Hotplug > will have the display back on. Is that what you observed? After any boot, not necessarily reboot. The system boots to the point where sddm should start, and monitor turns sleep mode on.Toggling the monitor off and (and then restarting sddm) works around it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/26] drm/irq: Ditch DRIVER_IRQ_SHARED
On Fri, Jan 25, 2019 at 02:46:55PM +, Emil Velikov wrote: > On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > > > This is only used by drm_irq_install(), which is an optional helper. > > And the right choice is to set it for all pci devices, and not for > > everything else. > > > Can you please add some information (or reference) why it's the right choice? pci devices can have a shared interrupt line. That's definitely the case for legacy pci, and I guess carries over to pcie. msi/msi-x interrupts will give you dedicated interrupts, but it doesn't really hurt to mark them as shared. I guess I could rephrase to state: "This is only used by drm_irq_install(), which is an optional helper. For legacy pci devices this is required (due to interrupt sharing without msi/msi-x), and just making this the default exactly matches the behaviour of all existing drivers using the drm_irq_install() helpers. In case that ever becomes wrong drivers can roll their own irq handling, as many drivers already do (for other reasons like needing a threaded interrupt handler, or having an entire pile of different interrupt sources)." That better? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #47 from Jerry Zuo --- You observed the monitor goes to sleep right after reboot, did you? Hotplug will have the display back on. Is that what you observed? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/23] drm/qxl: track primary bo
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Track which bo is used as primary surface. With that in place we don't > need the primary_created flag any more, we can just check the primary bo > pointer instead. > > Also verify we don't already have a primary surface in > qxl_io_create_primary(). > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/23] drm/qxl: drop unused offset parameter from qxl_io_create_primary()
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/23] drm/qxl: move qxl_primary_apply_cursor to correct place
Den 18.01.2019 13.20, skrev Gerd Hoffmann:
> The cursor must be set again after creating the primary surface.
> Also drop the error message.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 86bfc19bea..1b700ef503 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -533,7 +533,6 @@ static void qxl_primary_atomic_update(struct drm_plane
> *plane,
> .x2 = plane->state->fb->width,
> .y2 = plane->state->fb->height
> };
> - int ret;
> bool same_shadow = false;
>
> if (old_state->fb) {
> @@ -554,16 +553,13 @@ static void qxl_primary_atomic_update(struct drm_plane
> *plane,
> if (!same_shadow)
> qxl_io_destroy_primary(qdev);
> bo_old->is_primary = false;
> -
> - ret = qxl_primary_apply_cursor(plane);
> - if (ret)
> - DRM_ERROR(
> - "could not set cursor after creating primary");
> }
>
> if (!bo->is_primary) {
> - if (!same_shadow)
> + if (!same_shadow) {
> qxl_io_create_primary(qdev, 0, bo);
> + qxl_primary_apply_cursor(plane);
> + }
> bo->is_primary = true;
> }
>
>
I don't see how the commit message matches what you're doing. It gives
the impression that it must be applied under yet another condition, but
the condition for applying the cursor is changed from bo_old->is_primary
to !bo->is_primary.
It probably makes sense to someone that knows the driver.
Acked-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Fix flush_work() without INIT_WORK().
On Fri, Jan 25, 2019 at 09:46:15AM -0500, Sean Paul wrote:
> On Sat, Jan 19, 2019 at 01:43:43AM +0900, Tetsuo Handa wrote:
> > syzbot is hitting a lockdep warning [1] because flush_work() is called
> > without INIT_WORK() after kzalloc() at vkms_atomic_crtc_reset().
> >
> > Commit 6c234fe37c57627a ("drm/vkms: Implement CRC debugfs API") added
> > INIT_WORK() to only vkms_atomic_crtc_duplicate_state() side. Assuming
> > that lifecycle of crc_work is appropriately managed, fix this problem
> > by adding INIT_WORK() to vkms_atomic_crtc_reset() side.
> >
> > [1]
> > https://syzkaller.appspot.com/bug?id=a5954455fcfa51c29ca2ab55b203076337e1c770
> >
> > Reported-and-tested-by: syzbot
> >
> > Signed-off-by: Tetsuo Handa
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 177bbcb..3c37d8c 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -104,6 +104,7 @@ static void vkms_atomic_crtc_reset(struct drm_crtc
> > *crtc)
> > vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> > if (!vkms_state)
> > return;
> > + INIT_WORK(&vkms_state->crc_work, vkms_crc_work_handle);
>
> Presumably we should migrate/duplicate the crc_work state from the old state
> rather than just re-initializing? My context on the crc_work is foggy, but we
> should be sure that either:
>
> a) the existing crc work is flushed and inactive, or
> b) we migrate the existing crc work to the duplicated state to keep track of
> it
The various reset callbacks are used at driver load time to initialize
atomic kms state. Once we do have atomic states we're only using the
various duplicate_state callbacks, which already have the INIT_WORK here.
So was missing once at driver load, and we've hit it once on the first
frame. There is not existing/preceeding crc work when this code is called.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/23] drm/qxl: use QXL_GEM_DOMAIN_SURFACE for dumb gem objects
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > dumb buffers are used as qxl surfaces, so allocate them as > QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in > PRIV ttm domain then, so this reduces VRAM memory pressure. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 08/23] drm/qxl: use QXL_GEM_DOMAIN_SURFACE for shadow bo.
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > The shadow bo is used as qxl surface, so allocate it as > QXL_GEM_DOMAIN_SURFACE. Should usually be allocated in > PRIV ttm domain then, so this reduces VRAM memory pressure. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/23] drm/qxl: allow both PRIV and VRAM placement for QXL_GEM_DOMAIN_SURFACE
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > qxl surfaces (used for framebuffers and gem objects) can live in both > VRAM and PRIV ttm domains. Update placement setup to include both. > Put PRIV first in the list so it is preferred, so VRAM will have more > room for objects which must be allocated there. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 06/23] drm/qxl: use separate offset spaces for the two slots / ttm memory types.
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Without that ttm offsets are not unique, they can refer to objects > in both VRAM and PRIV memory (aka main and surfaces slot). > > One of those "why things didn't blow up without this" moments. > Probably offset conflicts are rare enough by pure luck. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/23] drm/qxl: drop unused fields from struct qxl_device
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > slot_id_bits and slot_gen_bits can be read directly from qxlrom instead. > va_slot_mask is never used anywhere. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 15/22] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
On Fri, Jan 25, 2019 at 01:28:53AM +0530, Jagan Teki wrote: > The MIPI DSI PHY controller on Allwinner A64 is similar > on the one on A31. > > Add A64 compatible and append A31 compatible as fallback. > > Signed-off-by: Jagan Teki > Reviewed-by: Rob Herring > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > index dbda2e567760..9c553637c72b 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > @@ -40,6 +40,7 @@ D-PHY > Required properties: >- compatible: value must be one of: > * allwinner,sun6i-a31-mipi-dphy > +* "allwinner,sun50i-a64-mipi-dphy", "allwinner,sun6i-a31-mipi-dphy" Same remark than patch 14 Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 14/22] dt-bindings: sun6i-dsi: Add A64 DSI compatible (w/ A31 fallback)
On Fri, Jan 25, 2019 at 01:28:52AM +0530, Jagan Teki wrote: > The MIPI DSI controller in Allwinner A64 is similar to A33. > > But unlike A33, A64 doesn't have DSI_SCLK gating which eventually > set the mod clock rate for the controller. > > So, use the DSI_DPHY gating for the similar purpose of mod clock > so-that the controller can operate properly. > > Signed-off-by: Jagan Teki > Reviewed-by: Rob Herring > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > index 69e233e8fad1..dbda2e567760 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. > Required properties: >- compatible: value must be one of: > * allwinner,sun6i-a31-mipi-dsi > +* "allwinner,sun50i-a64-mipi-dsi", "allwinner,sun6i-a31-mipi-dsi" The other line doesn't have quotes, we should be consistent Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/23] drm/qxl: change the way slot is detected
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > From: Frediano Ziglio > > Instead of relaying on surface type use the actual placement. > This allow to have different placement for a single type of > surface. > > Signed-off-by: Frediano Ziglio > > [ kraxel: rebased, adapted to upstream changes ] > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/23] drm/qxl: simplify slot management
Den 18.01.2019 13.20, skrev Gerd Hoffmann: > Drop pointless indirection, remove the mem_slots array and index > variables, drop dynamic allocation. Store memslots in qxl_device > instead. > > Signed-off-by: Gerd Hoffmann > --- Looks sane: Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 12/22] dt-bindings: sun6i-dsi: Add VCC-DSI supply property
On Fri, Jan 25, 2019 at 01:28:50AM +0530, Jagan Teki wrote: > Most of the Allwinner MIPI DSI controllers are supply with > VCC-DSI pin. which need to supply for some of the boards to > trigger the power. > > So, document the supply property so-that the required board > can eable it via device tree. > > Signed-off-by: Jagan Teki > Reviewed-by: Rob Herring > --- > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > index 6a6cf5de08b0..69e233e8fad1 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt > @@ -27,6 +27,9 @@ Required properties: > first port should be the input endpoint, usually coming from the > associated TCON. > > +Optional properties: > + - vcc-dsi-supply: the VCC-DSI power supply of the DSI encoder > + It looks like the VCC power rail is found on all the Allwinner SoCs, so it should be made mandatory. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/23] drm/qxl: drop unused qxl_fb_virtual_address
Den 18.01.2019 13.19, skrev Gerd Hoffmann: > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/23] drm/qxl: drop ttm_mem_reg arg from qxl_hw_surface_alloc()
Den 18.01.2019 13.19, skrev Gerd Hoffmann: > Not used, is always NULL. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109456] KVM VFIO guest X hang with guest kernel > 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=109456 --- Comment #1 from Alex Deucher --- Can you bisect? Please attach your dmesg output and xorg log. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote: > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The > AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn > on SSE2 to support emitting double precision floating point instructions > rather than calls to non-existent (usually available from gcc_s or > compiler_rt) floating point helper routines. > > Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html > Link: https://github.com/ClangBuiltLinux/linux/issues/327 > Cc: sta...@vger.kernel.org # 4.19 > Reported-by: S, Shirish > Reported-by: Matthias Kaehlcke > Suggested-by: James Y Knight > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers > Tested-by: Guenter Roeck Reviewed-by: Harry Wentland and applied. Harry > --- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > index 95f332ee3e7e..dc85a3c088af 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -calcs_ccflags := -mhard-float -msse $(cc_stack_align) > +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > CFLAGS_dcn_calcs.o := $(calcs_ccflags) > CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index d97ca6528f9d..33c7d7588712 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -dml_ccflags := -mhard-float -msse $(cc_stack_align) > +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > CFLAGS_display_mode_lib.o := $(dml_ccflags) > CFLAGS_display_pipe_clocks.o := $(dml_ccflags) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT
On Thu, Jan 24, 2019 at 05:58:31PM +0100, Daniel Vetter wrote: > It's 0. > > Signed-off-by: Daniel Vetter > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Patrik Jakobsson > Cc: Ben Skeggs > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Hans de Goede > Cc: Greg Kroah-Hartman > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: Alexander Kapshuk > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 - > drivers/gpu/drm/gma500/framebuffer.c | 1 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 1 - > drivers/gpu/drm/tegra/fb.c| 1 - > 5 files changed, 2 insertions(+), 6 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/26] drm/qxl: Use drm_fb_helper_fill_info
On Thu, Jan 24, 2019 at 05:58:27PM +0100, Daniel Vetter wrote: > Another driver that didn't set fbinfo->fix.id before. > > Signed-off-by: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/drm/tegra/fb.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) In the subject: drm/qxl -> drm/tegra, with that: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > If a non-legacy driver calls these it's valid to assume there is > interrupt support. The flag is really only needed for legacy drivers. ... legacy drivers which issue the IRQ via the DRM_IOCTL_CONTROL legacy IOCTL. At a later stage, we might as well add LEGACY to the name: DRIVER_LEGACY_HAVE_IRQ? > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- > drivers/gpu/drm/drm_irq.c| 6 -- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 2 +- > drivers/gpu/drm/gma500/psb_drv.c | 2 +- > drivers/gpu/drm/i915/i915_drv.c | 2 +- > drivers/gpu/drm/meson/meson_drv.c| 2 +- > drivers/gpu/drm/msm/msm_drv.c| 3 +-- > drivers/gpu/drm/mxsfb/mxsfb_drv.c| 3 +-- > drivers/gpu/drm/qxl/qxl_drv.c| 2 +- > drivers/gpu/drm/radeon/radeon_drv.c | 2 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_drv.c| 1 - > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- > drivers/staging/vboxvideo/vbox_drv.c | 2 +- Local grep shows one more non-legacy entry in drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c With that file addressed and trivial comment additions, patches: 1, 2, 3 and 26 are Reviewed-by: Emil Velikov HTH Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT
On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote: > > It's 0. > I'd add a bit more information here. Feel free to reuse as much/little of the following: Both macros evaluate to 0. At the same time flag is already set to zero since the struct is kzalloc'd in framebuffer_alloc(). As called by drm_fb_helper_alloc_fbi() in the DRM drivers. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb-helper: generic: Fix drm_fbdev_client_restore()
If fbdev setup has failed, lastclose will give a NULL pointer deref:
[ 77.794295] [drm:drm_lastclose]
[ 77.794414] [drm:drm_lastclose] driver lastclose completed
[ 77.794660] Unable to handle kernel NULL pointer dereference at virtual
address 0014
[ 77.809460] pgd = b376b71b
[ 77.818275] [0014] *pgd=175ba831, *pte=, *ppte=
[ 77.830813] Internal error: Oops: 17 [#1] ARM
[ 77.840963] Modules linked in: mi0283qt mipi_dbi tinydrm raspberrypi_hwmon
gpio_backlight backlight snd_bcm2835(C) bcm2835_rng rng_core
[ 77.865203] CPU: 0 PID: 527 Comm: lt-modetest Tainted: G C
5.0.0-rc1+ #1
[ 77.879525] Hardware name: BCM2835
[ 77.889185] PC is at restore_fbdev_mode+0x20/0x164
[ 77.900261] LR is at drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c
[ 78.002446] Process lt-modetest (pid: 527, stack limit = 0x7a3d5c14)
[ 78.291030] Backtrace:
[ 78.300815] [] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0x9c)
[ 78.319095] r9:d8a8a288 r8:d891acf0 r7:d7697910 r6: r5:d891ac00
r4:d891ac00
[ 78.334432] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[] (drm_fbdev_client_restore+0x18/0x20)
[ 78.353296] r8:d76978c0 r7:d7697910 r6:d7697950 r5:d7697800 r4:d891ac00
r3:c04f47d0
[ 78.368689] [] (drm_fbdev_client_restore) from []
(drm_client_dev_restore+0x7c/0xc0)
[ 78.385982] [] (drm_client_dev_restore) from []
(drm_lastclose+0xc4/0xd4)
[ 78.402332] r8:d76978c0 r7:d7471080 r6:c0e0c088 r5:d8a85e00 r4:d7697800
[ 78.416688] [] (drm_lastclose) from []
(drm_release+0xa8/0x10c)
[ 78.431929] r5:d8a85e00 r4:d7697800
[ 78.442989] [] (drm_release) from [] (__fput+0x104/0x1c8)
[ 78.457740] r8:d5ccea10 r7:d96cfb10 r6:0008 r5:d74c1b90 r4:d8a8a280
[ 78.472043] [] (__fput) from [] (fput+0x18/0x1c)
[ 78.486363] r10:0006 r9:d7722000 r8:c01011c4 r7: r6:c0ebac6c
r5:d892a340
[ 78.501869] r4:d8a8a280
[ 78.512002] [] (fput) from []
(task_work_run+0x98/0xac)
[ 78.527186] [] (task_work_run) from []
(do_work_pending+0x4f8/0x570)
[ 78.543238] r7:d7722030 r6:0004 r5:d7723fb0 r4:
[ 78.556825] [] (do_work_pending) from []
(slow_work_pending+0xc/0x20)
[ 78.674256] ---[ end trace 70d3a60cf739be3b ]---
Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.
Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation")
Cc: sta...@vger.kernel.org
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 31fcf94bf825..c5c79986f9c5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3185,9 +3185,7 @@ static void drm_fbdev_client_unregister(struct
drm_client_dev *client)
static int drm_fbdev_client_restore(struct drm_client_dev *client)
{
- struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
-
- drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+ drm_fb_helper_lastclose(client->dev);
return 0;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/26] drm/irq: Ditch DRIVER_IRQ_SHARED
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > This is only used by drm_irq_install(), which is an optional helper. > And the right choice is to set it for all pci devices, and not for > everything else. > Can you please add some information (or reference) why it's the right choice? Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm/vc4: Wait for display list synchronization when completing commit
Hi,
On Wed, 2019-01-23 at 10:34 -0800, Eric Anholt wrote:
> Paul Kocialkowski writes:
>
> > During an atomic commit, the HVS is configured with a display list
> > for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> > and encoder are also configured for the new setup at that time.
> > While the Pixel Valve and encoder are reconfigured synchronously, the
> > HVS is only reconfigured after the display list address (DISPLIST) has
> > been updated to the current display list address (DISPLACTX), which is
> > the responsibility of the hardware.
> >
> > The time frame during which the HVS is still running on its previous
> > configuration but the CRTC and encoder have been reconfigured already
> > can lead to a number of synchronization issues. They will eventually
> > cause errors reported on the FIFOs, such as underruns.
> >
> > With underrun detection enabled (from Boris Brezillon's series), this
> > leads to unreliable underrun detection with random false positives.
> >
> > To ensure a coherent state, wait for each enabled channel of the HVS
> > to synchronize its current display list address. This fixes the issue
> > of random underrun reporting on commits.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> > drivers/gpu/drm/vc4/vc4_hvs.c | 17 +
> > drivers/gpu/drm/vc4/vc4_kms.c | 2 ++
> > drivers/gpu/drm/vc4/vc4_regs.h | 2 ++
> > 4 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > index c24b078f0593..955f157f5ad0 100644
> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > @@ -772,6 +772,7 @@ void vc4_irq_reset(struct drm_device *dev);
> > extern struct platform_driver vc4_hvs_driver;
> > void vc4_hvs_dump_state(struct drm_device *dev);
> > int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
> > +void vc4_hvs_sync_dlist(struct drm_device *dev);
> >
> > /* vc4_kms.c */
> > int vc4_kms_load(struct drm_device *dev);
> > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> > index 5d8c749c9749..1ba60b8e0c2d 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> > @@ -166,6 +166,23 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs
> > *hvs,
> > return 0;
> > }
> >
> > +void vc4_hvs_sync_dlist(struct drm_device *dev)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + unsigned int i;
> > + int ret;
> > +
> > + for (i = 0; i < SCALER_CHANNELS_COUNT; i++) {
> > + if (!(HVS_READ(SCALER_DISPCTRLX(i)) & SCALER_DISPCTRLX_ENABLE))
> > + continue;
> > +
> > + ret = wait_for(HVS_READ(SCALER_DISPLACTX(i)) ==
> > + HVS_READ(SCALER_DISPLISTX(i)), 1000);
> > + WARN(ret, "Timeout waiting for channel %d display list sync\n",
> > +i);
> > + }
> > +}
> > +
> > static int vc4_hvs_bind(struct device *dev, struct device *master, void
> > *data)
> > {
> > struct platform_device *pdev = to_platform_device(dev);
> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > index 0490edb192a1..2d66a2b57a91 100644
> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > @@ -155,6 +155,8 @@ vc4_atomic_complete_commit(struct drm_atomic_state
> > *state)
> >
> > drm_atomic_helper_commit_hw_done(state);
> >
> > + vc4_hvs_sync_dlist(dev);
> > +
> > drm_atomic_helper_wait_for_flip_done(dev, state);
>
> wait_for_flip_done should already be waiting for DISPLACTX to match our
> crtc's display list, though, right (see vc4_crtc_handle_page_flip())?
> This seems like a no-op to me.
Right, at this stage it's pretty much a no-op. It does make a
difference when bringing-in vc4_hvs_unmask_underrun, because this
vc4_hvs_sync_dlist call comes before it.
When the display lists are not yet synchronized (and differ), an
underrun occurs so it will be reported although it's not related to the
new display list configuration. Waiting for the display lists to sync
before unmasking the interrupt prevents that.
I think waiting for the page flip to unmask the underrun interrupt
would be too late because the HVS should have finished processing the
new dlist by then (but maybe I'm mistaken about that), so we would miss
the underrun indication.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Fix flush_work() without INIT_WORK().
On Sat, Jan 19, 2019 at 01:43:43AM +0900, Tetsuo Handa wrote:
> syzbot is hitting a lockdep warning [1] because flush_work() is called
> without INIT_WORK() after kzalloc() at vkms_atomic_crtc_reset().
>
> Commit 6c234fe37c57627a ("drm/vkms: Implement CRC debugfs API") added
> INIT_WORK() to only vkms_atomic_crtc_duplicate_state() side. Assuming
> that lifecycle of crc_work is appropriately managed, fix this problem
> by adding INIT_WORK() to vkms_atomic_crtc_reset() side.
>
> [1]
> https://syzkaller.appspot.com/bug?id=a5954455fcfa51c29ca2ab55b203076337e1c770
>
> Reported-and-tested-by: syzbot
>
> Signed-off-by: Tetsuo Handa
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 177bbcb..3c37d8c 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -104,6 +104,7 @@ static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> if (!vkms_state)
> return;
> + INIT_WORK(&vkms_state->crc_work, vkms_crc_work_handle);
Presumably we should migrate/duplicate the crc_work state from the old state
rather than just re-initializing? My context on the crc_work is foggy, but we
should be sure that either:
a) the existing crc work is flushed and inactive, or
b) we migrate the existing crc work to the duplicated state to keep track of it
Sean
>
> crtc->state = &vkms_state->base;
> crtc->state->crtc = crtc;
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/vc4: Report underrun errors
Hi Eric,
On Wed, 2019-01-23 at 10:47 -0800, Eric Anholt wrote:
> Paul Kocialkowski writes:
>
> > From: Boris Brezillon
> >
> > The DRM framework provides a generic way to report underrun errors.
> > Let's implement the necessary hooks to support it in the VC4 driver.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > Changes in v3:
> > - Generic underrun report function has been dropped, adjust the
> > code accordingly
>
> Update commit message for DRM framework not providing a generic way any
> more?
Woops, sorry I missed that and left the commit inconsistent with the
changelog, indeed.
[...]
> > +void vc4_hvs_mask_underrun(struct drm_device *dev)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
> > +
> > + dispctrl &= ~(SCALER_DISPCTRL_DSPEISLUR(0) |
> > + SCALER_DISPCTRL_DSPEISLUR(1) |
> > + SCALER_DISPCTRL_DSPEISLUR(2));
> > +
> > + HVS_WRITE(SCALER_DISPCTRL, dispctrl);
> > +}
> > +
> > +void vc4_hvs_unmask_underrun(struct drm_device *dev)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
> > +
> > + dispctrl |= SCALER_DISPCTRL_DSPEISLUR(0) |
> > + SCALER_DISPCTRL_DSPEISLUR(1) |
> > + SCALER_DISPCTRL_DSPEISLUR(2);
> > +
> > + HVS_WRITE(SCALER_DISPSTAT,
> > + SCALER_DISPSTAT_EUFLOW(0) |
> > + SCALER_DISPSTAT_EUFLOW(1) |
> > + SCALER_DISPSTAT_EUFLOW(2));
> > + HVS_WRITE(SCALER_DISPCTRL, dispctrl);
> > +}
> > +
> > +static void vc4_hvs_report_underrun(struct drm_device *dev)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > +
> > + atomic_inc(&vc4->underrun);
> > + DRM_DEV_ERROR(dev->dev, "HVS underrun\n");
> > +}
> > +
> > +static irqreturn_t vc4_hvs_irq_handler(int irq, void *data)
> > +{
> > + struct drm_device *dev = data;
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + u32 status;
> > +
> > + status = HVS_READ(SCALER_DISPSTAT);
> > +
> > + if (status &
> > + (SCALER_DISPSTAT_EUFLOW(0) | SCALER_DISPSTAT_EUFLOW(1) |
> > +SCALER_DISPSTAT_EUFLOW(2))) {
> > + vc4_hvs_mask_underrun(dev);
> > + vc4_hvs_report_underrun(dev);
> > + }
> > +
> > + HVS_WRITE(SCALER_DISPSTAT, status);
> > +
> > + return status ? IRQ_HANDLED : IRQ_NONE;
> > +}
>
> So, if UFLOW is set then we incremented the counter and disabled the
> interrupt, otherwise we acked this specific interrupt and return? Given
> that a short-line error (the other potential cause of EISLUR) would be
> likely to persist, we should probably either vc4_hvs_mask_underrun() in
> that case too, or only return IRQ_HANDLED for the case we actually
> handled.
I see, there is definitely an inconsistency here. I don't think we
should be disabling the interrupt if we get a short line indication,
just in case the interrupt gets triggered later for a legitimate
underrun (before the next commit).
So I think we should just totally ignore the short line status bit for
the IRQ return (although it certainly doesn't hurt to clear it as
well). What do you think?
> > +
> > static int vc4_hvs_bind(struct device *dev, struct device *master, void
> > *data)
> > {
> > struct platform_device *pdev = to_platform_device(dev);
> > @@ -236,15 +305,33 @@ static int vc4_hvs_bind(struct device *dev, struct
> > device *master, void *data)
> > dispctrl = HVS_READ(SCALER_DISPCTRL);
> >
> > dispctrl |= SCALER_DISPCTRL_ENABLE;
> > + dispctrl |= SCALER_DISPCTRL_DSPEISLUR(0) | SCALER_DISPCTRL_DISPEIRQ(0) |
> > + SCALER_DISPCTRL_DSPEISLUR(1) | SCALER_DISPCTRL_DISPEIRQ(1) |
> > + SCALER_DISPCTRL_DSPEISLUR(2) | SCALER_DISPCTRL_DISPEIRQ(2);
> >
> > /* Set DSP3 (PV1) to use HVS channel 2, which would otherwise
> > * be unused.
> > */
> > dispctrl &= ~SCALER_DISPCTRL_DSP3_MUX_MASK;
> > + dispctrl &= ~(SCALER_DISPCTRL_DMAEIRQ |
> > + SCALER_DISPCTRL_SLVWREIRQ |
> > + SCALER_DISPCTRL_SLVRDEIRQ |
> > + SCALER_DISPCTRL_DSPEIEOF(0) |
> > + SCALER_DISPCTRL_DSPEIEOF(1) |
> > + SCALER_DISPCTRL_DSPEIEOF(2) |
> > + SCALER_DISPCTRL_DSPEIEOLN(0) |
> > + SCALER_DISPCTRL_DSPEIEOLN(1) |
> > + SCALER_DISPCTRL_DSPEIEOLN(2) |
> > + SCALER_DISPCTRL_SCLEIRQ);
> > dispctrl |= VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX);
>
> future work: At some point, we should stop inheriting old dispctrl setup
> and just initialize it on our own (so we get priority flags even if the
> firmware didn't set them up for us)
Sounds good, I'm taking a note of that for crafting a patch in that
direction.
> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > index 2d66a2b57a91..a28e801aeae2 100644
> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > @@ -139,6 +139,8 @@ vc4_ato
Re: [PATCH] drm/rockchip: rgb: update SPDX license identifier
Am Mittwoch, 23. Januar 2019, 11:14:39 CET schrieb Sandy Huang: > update SPDX License Identifier from GPL-2.0+ to GPL-2.0 > and drop some GPL text. > > Signed-off-by: Sandy Huang I've added Fixes, Cc-stable and Reported-by (for Thomas) tags and applied it to drm-misc-fixes Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus, Device}Info
On Wednesday, 2019-01-23 10:45:18 +, Emil Velikov wrote:
> From: Emil Velikov
>
> The functions are virtually identical, fold them up.
>
> Signed-off-by: Emil Velikov
Assuming patch 1 is OK, and `foo` gets renamed to something better:
Reviewed-by: Eric Engestrom
I don't know enough to review patch 1 though.
> ---
> xf86drm.c | 98 +--
> 1 file changed, 15 insertions(+), 83 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 374734eb..18c9693a 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3508,7 +3508,7 @@ free_device:
> return ret;
> }
>
> -static int drmParsePlatformBusInfo(int maj, int min, drmPlatformBusInfoPtr
> info)
> +static int drmParseOFBusInfo(int maj, int min, char *fullname)
> {
> #ifdef __linux__
> char path[PATH_MAX + 1], *name, *foo;
> @@ -3532,19 +3532,18 @@ static int drmParsePlatformBusInfo(int maj, int min,
> drmPlatformBusInfoPtr info)
> foo++;
> }
>
> -strncpy(info->fullname, foo, DRM_PLATFORM_DEVICE_NAME_LEN);
> -info->fullname[DRM_PLATFORM_DEVICE_NAME_LEN - 1] = '\0';
> +strncpy(fullname, foo, DRM_PLATFORM_DEVICE_NAME_LEN);
> +fullname[DRM_PLATFORM_DEVICE_NAME_LEN - 1] = '\0';
> free(name);
>
> return 0;
> #else
> -#warning "Missing implementation of drmParsePlatformBusInfo"
> +#warning "Missing implementation of drmParseOFBusInfo"
> return -EINVAL;
> #endif
> }
>
> -static int drmParsePlatformDeviceInfo(int maj, int min,
> - drmPlatformDeviceInfoPtr info)
> +static int drmParseOFDeviceInfo(int maj, int min, char ***compatible)
> {
> #ifdef __linux__
> char path[PATH_MAX + 1], *value, *foo;
> @@ -3562,8 +3561,8 @@ static int drmParsePlatformDeviceInfo(int maj, int min,
> count = 1;
> }
>
> -info->compatible = calloc(count + 1, sizeof(*info->compatible));
> -if (!info->compatible)
> +*compatible = calloc(count + 1, sizeof(char *));
> +if (!*compatible)
> return -ENOMEM;
>
> for (i = 0; i < count; i++) {
> @@ -3587,19 +3586,19 @@ static int drmParsePlatformDeviceInfo(int maj, int
> min,
> free(value);
> }
>
> -info->compatible[i] = foo;
> +*compatible[i] = foo;
> }
>
> return 0;
>
> free:
> while (i--)
> -free(info->compatible[i]);
> +free(*compatible[i]);
>
> -free(info->compatible);
> +free(*compatible);
> return err;
> #else
> -#warning "Missing implementation of drmParsePlatformDeviceInfo"
> +#warning "Missing implementation of drmParseOFDeviceInfo"
> return -EINVAL;
> #endif
> }
> @@ -3622,7 +3621,7 @@ static int drmProcessPlatformDevice(drmDevicePtr
> *device,
>
> dev->businfo.platform = (drmPlatformBusInfoPtr)ptr;
>
> -ret = drmParsePlatformBusInfo(maj, min, dev->businfo.platform);
> +ret = drmParseOFBusInfo(maj, min, dev->businfo.platform->fullname);
> if (ret < 0)
> goto free_device;
>
> @@ -3630,7 +3629,7 @@ static int drmProcessPlatformDevice(drmDevicePtr
> *device,
> ptr += sizeof(drmPlatformBusInfo);
> dev->deviceinfo.platform = (drmPlatformDeviceInfoPtr)ptr;
>
> -ret = drmParsePlatformDeviceInfo(maj, min, dev->deviceinfo.platform);
> +ret = drmParseOFDeviceInfo(maj, min,
> &dev->deviceinfo.platform->compatible);
> if (ret < 0)
> goto free_device;
> }
> @@ -3644,73 +3643,6 @@ free_device:
> return ret;
> }
>
> -static int drmParseHost1xBusInfo(int maj, int min, drmHost1xBusInfoPtr info)
> -{
> -#ifdef __linux__
> -char path[PATH_MAX + 1], *name;
> -
> -snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
> -
> -name = sysfs_uevent_get(path, "OF_FULLNAME");
> -if (!name)
> -return -ENOENT;
> -
> -strncpy(info->fullname, name, DRM_HOST1X_DEVICE_NAME_LEN);
> -info->fullname[DRM_HOST1X_DEVICE_NAME_LEN - 1] = '\0';
> -free(name);
> -
> -return 0;
> -#else
> -#warning "Missing implementation of drmParseHost1xBusInfo"
> -return -EINVAL;
> -#endif
> -}
> -
> -static int drmParseHost1xDeviceInfo(int maj, int min,
> -drmHost1xDeviceInfoPtr info)
> -{
> -#ifdef __linux__
> -char path[PATH_MAX + 1], *value;
> -unsigned int count, i;
> -int err;
> -
> -snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
> -
> -value = sysfs_uevent_get(path, "OF_COMPATIBLE_N");
> -if (!value)
> -return -ENOENT;
> -
> -sscanf(value, "%u", &count);
> -free(value);
> -
> -info->compatible = calloc(count + 1, sizeof(*info->compatible));
> -if (!info->compatible)
> -return -ENOMEM;
> -
> -for (i = 0; i < count; i++) {
> -value = sysfs_uevent_get(path, "OF_COMPATIBLE_%u", i);
> -if (!value) {
> -err = -ENOENT;
> -goto free;
> -}
> -
> -info->co
[PATCH v2] i2c: of: Try to find an I2C adapter matching the parent
From: Thierry Reding
If an I2C adapter doesn't match the provided device tree node, also try
matching the parent's device tree node. This allows finding an adapter
based on the device node of the parent device that was used to register
it.
This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
eDP controller registers an I2C adapter that is used to read to EDID.
After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt
suffix") this stopped working because the I2C adapter could no longer
be found. The approach in this patch fixes the regression without
introducing the issues that the above commit solved.
Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware device
node")
Signed-off-by: Thierry Reding
---
Changes in v2:
- check for both device and parent device tree nodes for each device
instead of looping through the list of devices twice
drivers/i2c/i2c-core-of.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 6cb7ad608bcd..0f01cdba9d2c 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -121,6 +121,17 @@ static int of_dev_node_match(struct device *dev, void
*data)
return dev->of_node == data;
}
+static int of_dev_or_parent_node_match(struct device *dev, void *data)
+{
+ if (dev->of_node == data)
+ return 1;
+
+ if (dev->parent)
+ return dev->parent->of_node == data;
+
+ return 0;
+}
+
/* must call put_device() when done with returned i2c_client device */
struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
{
@@ -145,7 +156,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct
device_node *node)
struct device *dev;
struct i2c_adapter *adapter;
- dev = bus_find_device(&i2c_bus_type, NULL, node, of_dev_node_match);
+ dev = bus_find_device(&i2c_bus_type, NULL, node,
+ of_dev_or_parent_node_match);
if (!dev)
return NULL;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Use ttm_dma_page_alloc_enabled
Instead of guessing whether TTM has the dma page allocator enabled, ask TTM. Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 77f422cd18ab..125a2b423847 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -35,6 +35,7 @@ #include #include #include +#include #define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices" #define VMWGFX_CHIP_SVGAII 0 @@ -594,8 +595,7 @@ static int vmw_dma_select_mode(struct vmw_private *dev_priv) if (dev_priv->map_mode == vmw_dma_map_populate && vmw_restrict_iommu) dev_priv->map_mode = vmw_dma_map_bind; - /* No TTM coherent page pool? FIXME: Ask TTM instead! */ -if (!(IS_ENABLED(CONFIG_SWIOTLB) || IS_ENABLED(CONFIG_INTEL_IOMMU)) && +if (!ttm_dma_page_alloc_enabled() && (dev_priv->map_mode == vmw_dma_alloc_coherent)) return -EINVAL; -- 2.19.0.rc1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/ttm: Implement and export ttm_dma_page_alloc_enabled
The vmwgfx driver needs to know whether the dma page pool is enabled
to determine whether to refuse loading if the dma mode logic
requests coherent memory from the dma page pool.
Cc: "Koenig, Christian"
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 11 +++
include/drm/ttm/ttm_page_alloc.h | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index d594f7520b7b..adf8cc189ecc 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -1235,4 +1235,15 @@ int ttm_dma_page_alloc_debugfs(struct seq_file *m, void
*data)
}
EXPORT_SYMBOL_GPL(ttm_dma_page_alloc_debugfs);
+/**
+ * ttm_dma_page_alloc_enabled - Is the dma page pool enabled?
+ *
+ * Returns true if the dma page pool is enabled. false otherwise.
+ */
+bool ttm_dma_page_alloc_enabled(void)
+{
+ return !!_manager;
+}
+EXPORT_SYMBOL(ttm_dma_page_alloc_enabled);
+
#endif
diff --git a/include/drm/ttm/ttm_page_alloc.h b/include/drm/ttm/ttm_page_alloc.h
index 4d9b019d253c..f810d389f5ad 100644
--- a/include/drm/ttm/ttm_page_alloc.h
+++ b/include/drm/ttm/ttm_page_alloc.h
@@ -94,6 +94,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev,
struct ttm_operation_ctx *ctx);
void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev);
+bool ttm_dma_page_alloc_enabled(void);
+
#else
static inline int ttm_dma_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
@@ -117,6 +119,8 @@ static inline void ttm_dma_unpopulate(struct ttm_dma_tt
*ttm_dma,
struct device *dev)
{
}
+
+static inline bool ttm_dma_page_alloc_enabled(void) { return false; }
#endif
#endif
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/11] drm/simple-kms-helper: Add drm_simple_connector_create()
Den 24.01.2019 15.53, skrev Hans de Goede:
> Hi,
>
> On 24-01-19 15:38, Noralf Trønnes wrote:
>> [cc:Hans]
>>
>> Den 21.01.2019 10.22, skrev Daniel Vetter:
>>> On Sun, Jan 20, 2019 at 12:43:10PM +0100, Noralf Trønnes wrote:
This adds a function that creates a simple connector that has only one
static mode. Additionally add a helper to set &drm_mode_config width
and height from the static mode.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_simple_kms_helper.c | 122
include/drm/drm_simple_kms_helper.h | 6 ++
2 files changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 917812448d1b..ca29975afefe 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -299,4 +301,124 @@ int drm_simple_display_pipe_init(struct
drm_device *dev,
}
EXPORT_SYMBOL(drm_simple_display_pipe_init);
+static const struct drm_connector_helper_funcs
drm_simple_connector_hfuncs = {
+ /* dummy for the atomic helper */
+};
+
+static int drm_simple_connector_fill_modes(struct drm_connector
*connector,
+ uint32_t maxX, uint32_t maxY)
+{
+ return 1;
+}
+
+static void drm_simple_connector_destroy(struct drm_connector
*connector)
+{
+ drm_connector_cleanup(connector);
+ kfree(connector);
+}
+
+static const struct drm_connector_funcs drm_simple_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .fill_modes = drm_simple_connector_fill_modes,
+ .destroy = drm_simple_connector_destroy,
+ .atomic_duplicate_state =
drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+/**
+ * drm_simple_connector_create - Create a connector with one static
mode
+ * @dev: DRM device
+ * @connector_type: Connector type
+ * @mode: Supported display mode
+ * @rotation: Initial @mode rotation in degrees
>>>
>>> We have rotation properties for this, pls don't use degress here.
>>>
>>
>> This rotation represents the way the display is mounted in the casing.
>> It is configured using a DT property:
>>
>> Documentation/devicetree/bindings/display/panel/panel.txt:
>> - rotation: Display rotation in degrees counter clockwise
>> (0,90,180,270)
>>
>> In the driver I set up a display mode which is rotated to match how it's
>> mounted:
>>
>> static const struct drm_display_mode mode = {
>> DRM_SIMPLE_MODE(320, 240, 58, 43),
>> };
>>
>> device_property_read_u32(dev, "rotation", &rotation);
>>
>> connector = drm_simple_connector_create(drm,
>> DRM_MODE_CONNECTOR_VIRTUAL, &mode, rotation);
>>
>>
>> The display controller is configured to scan out according to this
>> rotation.
>
> That sounds wrong, this sounds like you're trying to hide the fact
> that the LCD display is not mounted upright from userspace and
> transparently deal with this.
Indeed that's what I'm doing.
> This is what I wanted to do at
> first too, but in the end it turns out that that has a bunch
> of issues.
>
> This was extensively discussed and it was decided that this is not
> something which we want to do because it gets us into trouble with
> things like overlay planes, etc. Also many devices only support
> 90 / 270 degrees rotation if the framebuffer is tiled in a specific
> way, so if we do the rotation transparently, what do we do then
> if userspace attaches an incompatible framebuffer to the CRTC?
>
> Instead the decision was made to provide a property on the drm-connector
> which tells userspace that the LCD panel is not mounted upright and then
> let userspace deal with this.
>
>> It's important that the display mode matches the case mounting because
>> of fbdev. fbdev userspace has very limited support for rotation. Most
>> utilities have no support for it.
>
> Right, so maybe it is time for userspace to move to the kms API already?
>
These tiny SPI displays are heavily used in the Maker community which is
my main user base. Most are not professionals and fbdev is easy to use,
so I want to avoid crippling fbdev.
> Note that that will not fix things by itself, but at least it makes
> the info that the display is not upright available to userspace.
>
> Note I've already patched both plymouth and mutter to use the
> drm-connector property for this.
>
>> The work Hans did seems to only care about fbcon
>
> Since fbcon still uses fbdev, and since it already supported
> rendering the console rotated I added some glue code to ma
Re: [PATCH 0/5] tda998x updates
Hi, On Fri, Jan 25, 2019 at 11:56:09AM +, Russell King - ARM Linux admin wrote: > (Removed what I assume is a typo on the Cc line - n...@arm.com) Sadly not. I have to Cc (not Bcc!) n...@arm.com to remove the confidentiality disclaimer which would otherwise be added. Ugly, but my only option. > > On Fri, Jan 25, 2019 at 11:45:10AM +, Brian Starkey wrote: > > Hi Russell, > > > > On Fri, Jan 25, 2019 at 09:40:38AM +, Russell King - ARM Linux admin > > wrote: > > > Hi, > > > > > > This series adds support for programming the SPD and vendor infoframes. > > > > > > It also adds support for pixel repeated modes - we were not rejecting > > > these modes, but we also didn't have the implementation to support > > > them. As their implementation is simple, add it rather than rejecting > > > the modes. > > > > > > Support is also added for the bridge timing information, that upstream > > > components may wish to use to adjust their output appropriately. > > > > > > Lastly, rather than merely passing through the full-range RGB from the > > > CRTC, adapt the RGB range to the capabilities of the display and the > > > default range for the mode. This means that if the display does not > > > support the Q bit in the video infoframe, and the mode is defined to > > > have limited range RGB, we will compress the output RGB range to > > > limited range. > > > > > > Tested on 4.20 with a Panasonic TV. > > > > > > drm/i2c: tda998x: add support for pixel repeated modes > > > drm/i2c: tda998x: add bridge timing information > > > drm/i2c: tda998x: add support for writing SPD > > > drm/i2c: tda998x: add vendor specific infoframe support > > > drm/i2c: tda998x: improve correctness of quantisation range > > > > Only this cover letter made it to my inbox (and the dri-devel > > archives, for what they're worth). > > I think leave it a while longer - the series emails were accepted by > gabe.freedesktop.org at 09:51 UTC, maybe it's still thinking about > them. If not, I don't think there's anything I can do about it. > > > Is there somewhere I can take a look at the patches? > > http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=drm-tda998x-devel > > contains very similar patches, but based on 4.20. The series I posted > were those patches rebased on the linux-drm drm-next branch - and there > were some minor conflicts. Great, thanks. -Brian > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] tda998x updates
(Removed what I assume is a typo on the Cc line - n...@arm.com) On Fri, Jan 25, 2019 at 11:45:10AM +, Brian Starkey wrote: > Hi Russell, > > On Fri, Jan 25, 2019 at 09:40:38AM +, Russell King - ARM Linux admin > wrote: > > Hi, > > > > This series adds support for programming the SPD and vendor infoframes. > > > > It also adds support for pixel repeated modes - we were not rejecting > > these modes, but we also didn't have the implementation to support > > them. As their implementation is simple, add it rather than rejecting > > the modes. > > > > Support is also added for the bridge timing information, that upstream > > components may wish to use to adjust their output appropriately. > > > > Lastly, rather than merely passing through the full-range RGB from the > > CRTC, adapt the RGB range to the capabilities of the display and the > > default range for the mode. This means that if the display does not > > support the Q bit in the video infoframe, and the mode is defined to > > have limited range RGB, we will compress the output RGB range to > > limited range. > > > > Tested on 4.20 with a Panasonic TV. > > > > drm/i2c: tda998x: add support for pixel repeated modes > > drm/i2c: tda998x: add bridge timing information > > drm/i2c: tda998x: add support for writing SPD > > drm/i2c: tda998x: add vendor specific infoframe support > > drm/i2c: tda998x: improve correctness of quantisation range > > Only this cover letter made it to my inbox (and the dri-devel > archives, for what they're worth). I think leave it a while longer - the series emails were accepted by gabe.freedesktop.org at 09:51 UTC, maybe it's still thinking about them. If not, I don't think there's anything I can do about it. > Is there somewhere I can take a look at the patches? http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=drm-tda998x-devel contains very similar patches, but based on 4.20. The series I posted were those patches rebased on the linux-drm drm-next branch - and there were some minor conflicts. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] tda998x updates
Hi Russell, On Fri, Jan 25, 2019 at 09:40:38AM +, Russell King - ARM Linux admin wrote: > Hi, > > This series adds support for programming the SPD and vendor infoframes. > > It also adds support for pixel repeated modes - we were not rejecting > these modes, but we also didn't have the implementation to support > them. As their implementation is simple, add it rather than rejecting > the modes. > > Support is also added for the bridge timing information, that upstream > components may wish to use to adjust their output appropriately. > > Lastly, rather than merely passing through the full-range RGB from the > CRTC, adapt the RGB range to the capabilities of the display and the > default range for the mode. This means that if the display does not > support the Q bit in the video infoframe, and the mode is defined to > have limited range RGB, we will compress the output RGB range to > limited range. > > Tested on 4.20 with a Panasonic TV. > > drm/i2c: tda998x: add support for pixel repeated modes > drm/i2c: tda998x: add bridge timing information > drm/i2c: tda998x: add support for writing SPD > drm/i2c: tda998x: add vendor specific infoframe support > drm/i2c: tda998x: improve correctness of quantisation range Only this cover letter made it to my inbox (and the dri-devel archives, for what they're worth). Is there somewhere I can take a look at the patches? Thanks, -Brian > > drivers/gpu/drm/i2c/tda998x_drv.c | 120 > +- > 1 file changed, 105 insertions(+), 15 deletions(-) > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64
Am 25.01.19 um 09:43 schrieb Ard Biesheuvel: On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote: On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel wrote: On Thu, 24 Jan 2019 at 13:31, Koenig, Christian wrote: Am 24.01.19 um 13:06 schrieb Ard Biesheuvel: The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel The subject line should probably read "disable uncached...". Ugh, of course ... With that fixed the patch is Reviewed-by: Christian König . Same: Reviewed-by: Alex Deucher Thanks all Should I resend the patch with the subject corrected? I will update the subject line and push it upstream through drm-misc-next if nobody objects. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] Replace ttm_bo_{unref,reference} with ttm_bo_{get|put}
Reviewed-by: Christian König If there are no objections over the weekend I'm going to push that into upstream direction on monday. Thanks for the work, Christian. Am 25.01.19 um 12:02 schrieb Thomas Zimmermann: > This patchset cleans up the last remaining callers of ttm_bo_reference > and ttm_bo_unref. Calls are replaced with ttm_bo_get and ttm_bo_put, > which follow Linux' get/put semantics more closely. > > The most notable difference is that ttm_bo_get does not clear the supplied > pointer's value. This behaviour is now located in the calling code for cases > where it might be required. > > v2: > * rebased onto drm-tip > > Thomas Zimmermann (7): >drm/ast: Replace ttm_bo_unref with ttm_bo_put >drm/nouveau: Replace ttm_bo_reference with ttm_bo_get >drm/nouveau: Replace ttm_bo_unref with ttm_bo_put >drm/vmwgfx: Replace ttm_bo_reference with ttm_bo_get >drm/vmwgfx: Replace ttm_bo_unref with ttm_bo_put >drm/mgag200: Replace ttm_bo_unref with ttm_bo_put >drm/ttm: Remove ttm_bo_reference and ttm_bo_unref > > drivers/gpu/drm/ast/ast_main.c | 6 + > drivers/gpu/drm/mgag200/mgag200_main.c | 8 ++- > drivers/gpu/drm/nouveau/nouveau_bo.h | 12 ++ > drivers/gpu/drm/nouveau/nouveau_gem.c | 3 +-- > drivers/gpu/drm/ttm/ttm_bo.c | 9 --- > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 11 - > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 11 + > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 9 +++ > drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 21 ++-- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 9 --- > drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 6 +++-- > include/drm/ttm/ttm_bo_api.h | 28 -- > 12 files changed, 49 insertions(+), 84 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: fix AUO g185han01 horizontal blanking
On Mon, 2018-11-12 at 18:41 +0100, Lucas Stach wrote:
> The horizontal blanking periods are too short, as the values are
> specified for a single LVDS channel. Since this panel is dual LVDS
> they need to be doubled. With this change the panel reaches its
> nominal vrefresh rate of 60Fps, instead of the 64Fps with the
> current wrong blanking.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/panel/panel-simple.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 97964f7f2ace..2c89792e91e2 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -663,9 +663,9 @@ static const struct panel_desc auo_g133han01 = {
> static const struct display_timing auo_g185han01_timings = {
> .pixelclock = { 12000, 14400, 17500 },
> .hactive = { 1920, 1920, 1920 },
> - .hfront_porch = { 18, 60, 74 },
> - .hback_porch = { 12, 44, 54 },
> - .hsync_len = { 10, 24, 32 },
> + .hfront_porch = { 36, 120, 148 },
> + .hback_porch = { 24, 88, 108 },
> + .hsync_len = { 20, 48, 64 },
The datasheet specifies 960 active clocks + 40/128/160 clocks blanking
on each of the two LVDS channels (min/typical/max), so doubled this is
now correct.
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109456] KVM VFIO guest X hang with guest kernel > 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=109456 Bug ID: 109456 Summary: KVM VFIO guest X hang with guest kernel > 4.15 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: libgra...@gmail.com Hi Host: Arch running kernel 4.20.3 / Qemu 3.1 Guest: Ubuntu 18.04.1 (tried Ubuntu 18.10 also) with any kernel after 4.15 Driver: Happens with current stable, git from Padoka PPA and amdgpu-pro 18.50 Issue: Vega 64 passed through to guest causes X to hang on boot using 100% CPU for one of the passed through cores for the Xorg process. X never starts with the stopping point being 'LoadModule: "dri2"'. I cannot see any relevant errors in Xorg.log or the KRB - though it's easily reproducible. The system is still alive and can be ssh'd into. Adding the nomodeset kernel option allows the guest to boot to GUI (albeit without acceleration). Details: With Qemu 3.0 having more than ~12GB RAM assigned to the guest causes this behaviour. With Qemu 3.1 the amount of RAM is irrelevant - the hang always occurs. Believe this is related to one of the GPU reset patches added to the 4.16 kernel as the guest boots fine with Qemu 3.0/3.1 and guest kernel 4.15 (tested up to 16GB guest RAM). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] drm/vmwgfx: Replace ttm_bo_reference with ttm_bo_get
The function ttm_bo_get acquires a reference on a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 3 ++-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 7ce1c2f87d9a..bb9d95ef0707 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -614,7 +614,8 @@ int vmw_user_bo_alloc(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
return ret;
- tmp = ttm_bo_reference(&user_bo->vbo.base);
+ ttm_bo_get(&user_bo->vbo.base);
+ tmp = &user_bo->vbo.base;
ret = ttm_prime_object_init(tfile,
size,
&user_bo->prime,
@@ -911,7 +912,7 @@ int vmw_user_bo_lookup(struct ttm_object_file *tfile,
vmw_user_bo = container_of(base, struct vmw_user_buffer_object,
prime.base);
- (void)ttm_bo_reference(&vmw_user_bo->vbo.base);
+ ttm_bo_get(&vmw_user_bo->vbo.base);
if (p_base)
*p_base = base;
else
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index cd607ba9c2fe..b7fb9b79bfef 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1346,9 +1346,8 @@ static inline void vmw_bo_unreference(struct
vmw_buffer_object **buf)
static inline struct vmw_buffer_object *
vmw_bo_reference(struct vmw_buffer_object *buf)
{
- if (ttm_bo_reference(&buf->base))
- return buf;
- return NULL;
+ ttm_bo_get(&buf->base);
+ return buf;
}
static inline struct ttm_mem_global *vmw_mem_glob(struct vmw_private *dev_priv)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 3025bfc001a1..d67b928adf6a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -461,7 +461,8 @@ vmw_resource_check_buffer(struct ww_acquire_ctx *ticket,
}
INIT_LIST_HEAD(&val_list);
- val_buf->bo = ttm_bo_reference(&res->backup->base);
+ ttm_bo_get(&res->backup->base);
+ val_buf->bo = &res->backup->base;
val_buf->num_shared = 0;
list_add_tail(&val_buf->head, &val_list);
ret = ttm_eu_reserve_buffers(ticket, &val_list, interruptible, NULL);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm/nouveau: Replace ttm_bo_reference with ttm_bo_get
The function ttm_bo_get acquires a reference on a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_bo.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 73c48440d4d7..3920134cb132 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -61,7 +61,12 @@ nouveau_bo_ref(struct nouveau_bo *ref, struct nouveau_bo
**pnvbo)
return -EINVAL;
prev = *pnvbo;
- *pnvbo = ref ? nouveau_bo(ttm_bo_reference(&ref->bo)) : NULL;
+ if (ref) {
+ ttm_bo_get(&ref->bo);
+ *pnvbo = nouveau_bo(&ref->bo);
+ } else {
+ *pnvbo = NULL;
+ }
if (prev) {
struct ttm_buffer_object *bo = &prev->bo;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm/nouveau: Replace ttm_bo_unref with ttm_bo_put
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/nouveau_bo.h | 7 ++-
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 +--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 3920134cb132..846f4bdec0de 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -67,11 +67,8 @@ nouveau_bo_ref(struct nouveau_bo *ref, struct nouveau_bo
**pnvbo)
} else {
*pnvbo = NULL;
}
- if (prev) {
- struct ttm_buffer_object *bo = &prev->bo;
-
- ttm_bo_unref(&bo);
- }
+ if (prev)
+ ttm_bo_put(&prev->bo);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index b56524d343c3..fb028e3b5f51 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -41,7 +41,6 @@ nouveau_gem_object_del(struct drm_gem_object *gem)
{
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
- struct ttm_buffer_object *bo = &nvbo->bo;
struct device *dev = drm->dev->dev;
int ret;
@@ -56,7 +55,7 @@ nouveau_gem_object_del(struct drm_gem_object *gem)
/* reset filp so nouveau_bo_del_ttm() can test for it */
gem->filp = NULL;
- ttm_bo_unref(&bo);
+ ttm_bo_put(&nvbo->bo);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/7] drm/vmwgfx: Replace ttm_bo_unref with ttm_bo_put
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
In places where is might be necessary, the current behaviour of cleaning the
pointer is kept.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 8 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 11 +++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 +---
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 21 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 --
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 6 --
6 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index bb9d95ef0707..5d5c2bce01f3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -534,7 +534,6 @@ static void vmw_user_bo_release(struct ttm_base_object
**p_base)
{
struct vmw_user_buffer_object *vmw_user_bo;
struct ttm_base_object *base = *p_base;
- struct ttm_buffer_object *bo;
*p_base = NULL;
@@ -543,8 +542,7 @@ static void vmw_user_bo_release(struct ttm_base_object
**p_base)
vmw_user_bo = container_of(base, struct vmw_user_buffer_object,
prime.base);
- bo = &vmw_user_bo->vbo.base;
- ttm_bo_unref(&bo);
+ ttm_bo_put(&vmw_user_bo->vbo.base);
}
@@ -597,7 +595,6 @@ int vmw_user_bo_alloc(struct vmw_private *dev_priv,
struct ttm_base_object **p_base)
{
struct vmw_user_buffer_object *user_bo;
- struct ttm_buffer_object *tmp;
int ret;
user_bo = kzalloc(sizeof(*user_bo), GFP_KERNEL);
@@ -615,7 +612,6 @@ int vmw_user_bo_alloc(struct vmw_private *dev_priv,
return ret;
ttm_bo_get(&user_bo->vbo.base);
- tmp = &user_bo->vbo.base;
ret = ttm_prime_object_init(tfile,
size,
&user_bo->prime,
@@ -624,7 +620,7 @@ int vmw_user_bo_alloc(struct vmw_private *dev_priv,
&vmw_user_bo_release,
&vmw_user_bo_ref_obj_release);
if (unlikely(ret != 0)) {
- ttm_bo_unref(&tmp);
+ ttm_bo_put(&user_bo->vbo.base);
goto out_no_base_object;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 48d1380a952e..70dab55e7888 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -765,7 +765,7 @@ static bool vmw_cmdbuf_try_alloc(struct vmw_cmdbuf_man *man,
if (info->done)
return true;
-
+
memset(info->node, 0, sizeof(*info->node));
spin_lock(&man->lock);
ret = drm_mm_insert_node(&man->mm, info->node, info->page_size);
@@ -1276,8 +1276,10 @@ int vmw_cmdbuf_set_pool_size(struct vmw_cmdbuf_man *man,
return 0;
out_no_map:
- if (man->using_mob)
- ttm_bo_unref(&man->cmd_space);
+ if (man->using_mob) {
+ ttm_bo_put(man->cmd_space);
+ man->cmd_space = NULL;
+ }
return ret;
}
@@ -1380,7 +1382,8 @@ void vmw_cmdbuf_remove_pool(struct vmw_cmdbuf_man *man)
(void) vmw_cmdbuf_idle(man, false, 10*HZ);
if (man->using_mob) {
(void) ttm_bo_kunmap(&man->map_obj);
- ttm_bo_unref(&man->cmd_space);
+ ttm_bo_put(man->cmd_space);
+ man->cmd_space = NULL;
} else {
dma_free_coherent(&man->dev_priv->dev->pdev->dev,
man->size, man->map, man->handle);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index b7fb9b79bfef..accb2fafe2f1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1337,9 +1337,7 @@ static inline void vmw_bo_unreference(struct
vmw_buffer_object **buf)
*buf = NULL;
if (tmp_buf != NULL) {
- struct ttm_buffer_object *bo = &tmp_buf->base;
-
- ttm_bo_unref(&bo);
+ ttm_bo_put(&tmp_buf->base);
}
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
index 7ed179d30ec5..d83cc66e1210 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
@@ -300,7 +300,8 @@ static int vmw_otable_batch_setup(struct vmw_private
*dev_priv,
&batch->otables
[PATCH v2 6/7] drm/mgag200: Replace ttm_bo_unref with ttm_bo_put
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
The current behaviour of cleaning the pointer is kept in the calling code,
but should be removed if not required in a later patch.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 79d54103d470..163255099779 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -33,7 +33,7 @@ int mgag200_framebuffer_init(struct drm_device *dev,
struct drm_gem_object *obj)
{
int ret;
-
+
drm_helper_mode_fill_fb_struct(dev, &gfb->base, mode_cmd);
gfb->obj = obj;
ret = drm_framebuffer_init(dev, &gfb->base, &mga_fb_funcs);
@@ -318,13 +318,9 @@ int mgag200_dumb_create(struct drm_file *file,
static void mgag200_bo_unref(struct mgag200_bo **bo)
{
- struct ttm_buffer_object *tbo;
-
if ((*bo) == NULL)
return;
-
- tbo = &((*bo)->bo);
- ttm_bo_unref(&tbo);
+ ttm_bo_put(&((*bo)->bo));
*bo = NULL;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] Replace ttm_bo_{unref, reference} with ttm_bo_{get|put}
This patchset cleans up the last remaining callers of ttm_bo_reference and ttm_bo_unref. Calls are replaced with ttm_bo_get and ttm_bo_put, which follow Linux' get/put semantics more closely. The most notable difference is that ttm_bo_get does not clear the supplied pointer's value. This behaviour is now located in the calling code for cases where it might be required. v2: * rebased onto drm-tip Thomas Zimmermann (7): drm/ast: Replace ttm_bo_unref with ttm_bo_put drm/nouveau: Replace ttm_bo_reference with ttm_bo_get drm/nouveau: Replace ttm_bo_unref with ttm_bo_put drm/vmwgfx: Replace ttm_bo_reference with ttm_bo_get drm/vmwgfx: Replace ttm_bo_unref with ttm_bo_put drm/mgag200: Replace ttm_bo_unref with ttm_bo_put drm/ttm: Remove ttm_bo_reference and ttm_bo_unref drivers/gpu/drm/ast/ast_main.c | 6 + drivers/gpu/drm/mgag200/mgag200_main.c | 8 ++- drivers/gpu/drm/nouveau/nouveau_bo.h | 12 ++ drivers/gpu/drm/nouveau/nouveau_gem.c | 3 +-- drivers/gpu/drm/ttm/ttm_bo.c | 9 --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 11 - drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 11 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 9 +++ drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 21 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 9 --- drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 6 +++-- include/drm/ttm/ttm_bo_api.h | 28 -- 12 files changed, 49 insertions(+), 84 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm/ast: Replace ttm_bo_unref with ttm_bo_put
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_main.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 373700c05a00..2854399856ba 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -639,13 +639,9 @@ int ast_dumb_create(struct drm_file *file,
static void ast_bo_unref(struct ast_bo **bo)
{
- struct ttm_buffer_object *tbo;
-
if ((*bo) == NULL)
return;
-
- tbo = &((*bo)->bo);
- ttm_bo_unref(&tbo);
+ ttm_bo_put(&((*bo)->bo));
*bo = NULL;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] drm/ttm: Remove ttm_bo_reference and ttm_bo_unref
Both functions are obsolete and all calls have been replaced by
ttm_bo_get and ttm_bo_put.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo.c | 9 -
include/drm/ttm/ttm_bo_api.h | 28
2 files changed, 37 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0ec08394e17a..f2bee7be42ac 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -676,15 +676,6 @@ void ttm_bo_put(struct ttm_buffer_object *bo)
}
EXPORT_SYMBOL(ttm_bo_put);
-void ttm_bo_unref(struct ttm_buffer_object **p_bo)
-{
- struct ttm_buffer_object *bo = *p_bo;
-
- *p_bo = NULL;
- ttm_bo_put(bo);
-}
-EXPORT_SYMBOL(ttm_bo_unref);
-
int ttm_bo_lock_delayed_workqueue(struct ttm_bo_device *bdev)
{
return cancel_delayed_work_sync(&bdev->wq);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 3fc4854dce49..49d9cdfc58f2 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -295,23 +295,6 @@ static inline void ttm_bo_get(struct ttm_buffer_object *bo)
kref_get(&bo->kref);
}
-/**
- * ttm_bo_reference - reference a struct ttm_buffer_object
- *
- * @bo: The buffer object.
- *
- * Returns a refcounted pointer to a buffer object.
- *
- * This function is deprecated. Use @ttm_bo_get instead.
- */
-
-static inline struct ttm_buffer_object *
-ttm_bo_reference(struct ttm_buffer_object *bo)
-{
- ttm_bo_get(bo);
- return bo;
-}
-
/**
* ttm_bo_get_unless_zero - reference a struct ttm_buffer_object unless
* its refcount has already reached zero.
@@ -386,17 +369,6 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
*/
void ttm_bo_put(struct ttm_buffer_object *bo);
-/**
- * ttm_bo_unref
- *
- * @bo: The buffer object.
- *
- * Unreference and clear a pointer to a buffer object.
- *
- * This function is deprecated. Use @ttm_bo_put instead.
- */
-void ttm_bo_unref(struct ttm_buffer_object **bo);
-
/**
* ttm_bo_add_to_lru
*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install
Hi Daniel. On Thu, Jan 24, 2019 at 05:58:06PM +0100, Daniel Vetter wrote: > If a non-legacy driver calls these it's valid to assume there is > interrupt support. The flag is really only needed for legacy drivers. > > Also remove all the flag usage from non-legacy drivers. > > Signed-off-by: Daniel Vetter > Cc: linux-arm-ker...@lists.infradead.org > Cc: intel-...@lists.freedesktop.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: spice-de...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org The actual code changes looks good. But if this is the right thing to do I cannot tell. On this (limited) basis I provide an: Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/tegra: Restrict IOVA space to DMA mask
24.01.2019 13:24, Mikko Perttunen пишет:
> On 23.1.2019 21.42, Dmitry Osipenko wrote:
>> 23.01.2019 18:55, Dmitry Osipenko пишет:
>>> 23.01.2019 17:04, Thierry Reding пишет:
On Wed, Jan 23, 2019 at 04:41:44PM +0300, Dmitry Osipenko wrote:
> 23.01.2019 12:39, Thierry Reding пишет:
>> From: Thierry Reding
>>
>> On Tegra186 and later, the ARM SMMU provides an input address space that
>> is 48 bits wide. However, memory clients can only address up to 40 bits.
>> If the geometry is used as-is, allocations of IOVA space can end up in a
>> region that cannot be addressed by the memory clients.
>>
>> To fix this, restrict the IOVA space to the DMA mask of the host1x
>> device. Note that, technically, the IOVA space needs to be restricted to
>> the intersection of the DMA masks for all clients that are attached to
>> the IOMMU domain. In practice using the DMA mask of the host1x device is
>> sufficient because all host1x clients share the same DMA mask.
>>
>> Signed-off-by: Thierry Reding
>> ---
>> drivers/gpu/drm/tegra/drm.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>> index 271c7a5fc954..0c5f1e6a0446 100644
>> --- a/drivers/gpu/drm/tegra/drm.c
>> +++ b/drivers/gpu/drm/tegra/drm.c
>> @@ -136,11 +136,12 @@ static int tegra_drm_load(struct drm_device *drm,
>> unsigned long flags)
>> if (tegra->domain) {
>> u64 carveout_start, carveout_end, gem_start, gem_end;
>> + u64 dma_mask = dma_get_mask(&device->dev);
>> dma_addr_t start, end;
>> unsigned long order;
>> - start = tegra->domain->geometry.aperture_start;
>> - end = tegra->domain->geometry.aperture_end;
>> + start = tegra->domain->geometry.aperture_start & dma_mask;
>> + end = tegra->domain->geometry.aperture_end & dma_mask;
>> gem_start = start;
>> gem_end = end - CARVEOUT_SZ;
>>
>
> Wow, so IOVA could address >32bits on later Tegra's. AFAIK, currently
> there is no support for a proper programming of the 64bit addresses in
> the drivers code, hence.. won't it make sense to force IOVA mask to
> 32bit for now and hope that the second halve of address registers
> happen to be 0x in HW?
I think this restriction only applies to display at this point. In
practice you'd be hard put to trigger that case because IOVA memory is
allocated from the bottom, so you'd actually need to use up to 4 GiB of
IOVA space before hitting that.
That said, I vaguely remember typing up the patch to support writing the
WINBUF_START_ADDR_HI register and friends, but it looks as if that was
never merged.
I'll try to dig out that patch (or rewrite it, shouldn't be very
difficult) and make it part of this series. I'd rather fix that issue
than arbitrarily restrict the IOVA space, because that's likely to come
back and bite us at some point.
>>>
>>> Looking at falcon.c.. it writes 32bit address only. Something need to be
>>> done about it as well, seems there is FALCON_DMATRFMOFFS register to
>>> facilitate >32bits addressing.
>>
>> Although scratch about FALCON_DMATRFMOFFS, it should be about something
>> else. Mikko, could you please clarify whether falcon could load firmware
>> only from a 32bit AS?
>>
>
> The DMA base address is set using DMATRFBASE, which requires 256B alignment,
> meaning 40 bits are available for the address. The DMATRFFBOFFS I believe is
> then used as a 32-bit offset to that value.
TRM (up to T196) suggests that DMATRFMOFFS is a 16bit offset. Is it a kind of
TRM bug or I'm missing something?
I suppose it should be fine to just reserve carveout from the bottom of IOVA
space and done with it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/tegra: Restrict IOVA space to DMA mask
24.01.2019 16:27, Mikko Perttunen пишет:
> On 24.1.2019 15.15, Dmitry Osipenko wrote:
>> 24.01.2019 13:24, Mikko Perttunen пишет:
>>> On 23.1.2019 21.42, Dmitry Osipenko wrote:
23.01.2019 18:55, Dmitry Osipenko пишет:
> 23.01.2019 17:04, Thierry Reding пишет:
>> On Wed, Jan 23, 2019 at 04:41:44PM +0300, Dmitry Osipenko wrote:
>>> 23.01.2019 12:39, Thierry Reding пишет:
From: Thierry Reding
On Tegra186 and later, the ARM SMMU provides an input address space
that
is 48 bits wide. However, memory clients can only address up to 40
bits.
If the geometry is used as-is, allocations of IOVA space can end up in
a
region that cannot be addressed by the memory clients.
To fix this, restrict the IOVA space to the DMA mask of the host1x
device. Note that, technically, the IOVA space needs to be restricted
to
the intersection of the DMA masks for all clients that are attached to
the IOMMU domain. In practice using the DMA mask of the host1x device
is
sufficient because all host1x clients share the same DMA mask.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 271c7a5fc954..0c5f1e6a0446 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -136,11 +136,12 @@ static int tegra_drm_load(struct drm_device
*drm, unsigned long flags)
if (tegra->domain) {
u64 carveout_start, carveout_end, gem_start, gem_end;
+ u64 dma_mask = dma_get_mask(&device->dev);
dma_addr_t start, end;
unsigned long order;
- start = tegra->domain->geometry.aperture_start;
- end = tegra->domain->geometry.aperture_end;
+ start = tegra->domain->geometry.aperture_start & dma_mask;
+ end = tegra->domain->geometry.aperture_end & dma_mask;
gem_start = start;
gem_end = end - CARVEOUT_SZ;
>>>
>>> Wow, so IOVA could address >32bits on later Tegra's. AFAIK, currently
>>> there is no support for a proper programming of the 64bit addresses in
>>> the drivers code, hence.. won't it make sense to force IOVA mask to
>>> 32bit for now and hope that the second halve of address registers
>>> happen to be 0x in HW?
>>
>> I think this restriction only applies to display at this point. In
>> practice you'd be hard put to trigger that case because IOVA memory is
>> allocated from the bottom, so you'd actually need to use up to 4 GiB of
>> IOVA space before hitting that.
>>
>> That said, I vaguely remember typing up the patch to support writing the
>> WINBUF_START_ADDR_HI register and friends, but it looks as if that was
>> never merged.
>>
>> I'll try to dig out that patch (or rewrite it, shouldn't be very
>> difficult) and make it part of this series. I'd rather fix that issue
>> than arbitrarily restrict the IOVA space, because that's likely to come
>> back and bite us at some point.
>
> Looking at falcon.c.. it writes 32bit address only. Something need to be
> done about it as well, seems there is FALCON_DMATRFMOFFS register to
> facilitate >32bits addressing.
Although scratch about FALCON_DMATRFMOFFS, it should be about something
else. Mikko, could you please clarify whether falcon could load firmware
only from a 32bit AS?
>>>
>>> The DMA base address is set using DMATRFBASE, which requires 256B
>>> alignment, meaning 40 bits are available for the address. The DMATRFFBOFFS
>>> I believe is then used as a 32-bit offset to that value.
>>
>> TRM (up to T196) suggests that DMATRFMOFFS is a 16bit offset. Is it a kind
>> of TRM bug or I'm missing something?
>>
>> I suppose it should be fine to just reserve carveout from the bottom of IOVA
>> space and done with it.
>>
>
> DMATRFMOFFS is an offset to the Falcon IMEM, so 16 bits is enough to cover
> that.
Ah, there are source DMATRFMOFFS (32bit DRAM offset) and destination
DMATRFMOFFS (16bit IMEM offset). So one variant is to setup DMA address
correctly, the other variant is to change the carveout layout and make IOMMU
mandatory for the driver.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On Thu, Jan 24, 2019 at 04:52:59PM -0800, ndesaulni...@google.com wrote: > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The > AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn > on SSE2 to support emitting double precision floating point instructions > rather than calls to non-existent (usually available from gcc_s or > compiler_rt) floating point helper routines. > > Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html > Link: https://github.com/ClangBuiltLinux/linux/issues/327 > Cc: sta...@vger.kernel.org # 4.19 > Reported-by: S, Shirish > Reported-by: Matthias Kaehlcke > Suggested-by: James Y Knight > Suggested-by: Nathan Chancellor > Signed-off-by: Nick Desaulniers > Tested-by: Guenter Roeck Tested-by: Nathan Chancellor > --- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > index 95f332ee3e7e..dc85a3c088af 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -calcs_ccflags := -mhard-float -msse $(cc_stack_align) > +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > CFLAGS_dcn_calcs.o := $(calcs_ccflags) > CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index d97ca6528f9d..33c7d7588712 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > cc_stack_align := -mstack-alignment=16 > endif > > -dml_ccflags := -mhard-float -msse $(cc_stack_align) > +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > CFLAGS_display_mode_lib.o := $(dml_ccflags) > CFLAGS_display_pipe_clocks.o := $(dml_ccflags) > -- > 2.20.1.321.g9e740568ce-goog > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] phy: Add driver for mixel dphy
This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
this is an IP core it will likely be found on others in the future. So
instead of adding this to the nwl host driver make it a generic PHY
driver.
The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
added once the necessary system controller bits are in via
mixel_dpy_ops.
Signed-off-by: Guido Günther
---
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-mixel-mipi-dphy.c | 449 ++
3 files changed, 457 insertions(+)
create mode 100644 drivers/phy/phy-mixel-mipi-dphy.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 250abe290ca1..9195b5876bcc 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -48,6 +48,13 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_MIXEL_MIPI_DPHY
+ bool
+ depends on OF
+ select GENERIC_PHY
+ select GENERIC_PHY_MIPI_DPHY
+ default ARCH_MXC && ARM64
+
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0d9fddc498a6..264f570b67bf 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
obj-$(CONFIG_ARCH_RENESAS) += renesas/
obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-mixel-mipi-dphy.o
obj-y += broadcom/\
cadence/ \
freescale/ \
diff --git a/drivers/phy/phy-mixel-mipi-dphy.c
b/drivers/phy/phy-mixel-mipi-dphy.c
new file mode 100644
index ..8a43dab79cee
--- /dev/null
+++ b/drivers/phy/phy-mixel-mipi-dphy.c
@@ -0,0 +1,449 @@
+/*
+ * Copyright 2017 NXP
+ * Copyright 2019 Purism SPC
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/* #define DEBUG 1 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* DPHY registers */
+#define DPHY_PD_DPHY 0x00
+#define DPHY_M_PRG_HS_PREPARE 0x04
+#define DPHY_MC_PRG_HS_PREPARE 0x08
+#define DPHY_M_PRG_HS_ZERO 0x0c
+#define DPHY_MC_PRG_HS_ZERO0x10
+#define DPHY_M_PRG_HS_TRAIL0x14
+#define DPHY_MC_PRG_HS_TRAIL 0x18
+#define DPHY_PD_PLL0x1c
+#define DPHY_TST 0x20
+#define DPHY_CN0x24
+#define DPHY_CM0x28
+#define DPHY_CO0x2c
+#define DPHY_LOCK 0x30
+#define DPHY_LOCK_BYP 0x34
+#define DPHY_TX_RCAL 0x38
+#define DPHY_AUTO_PD_EN0x3c
+#define DPHY_RXLPRP0x40
+#define DPHY_RXCDRP0x44
+
+#define MBPS(x) ((x) * 100)
+
+#define DATA_RATE_MAX_SPEED MBPS(1500)
+#define DATA_RATE_MIN_SPEED MBPS(80)
+
+#define CN_BUF 0xcb7a89c0
+#define CO_BUF 0x63
+#define CM(x) ( \
+ ((x) < 32)?0xe0|((x)-16) : \
+ ((x) < 64)?0xc0|((x)-32) : \
+ ((x) < 128)?0x80|((x)-64) : \
+ ((x) - 128))
+#define CN(x) (((x) == 1)?0x1f : (((CN_BUF)>>((x)-1))&0x1f))
+#define CO(x) ((CO_BUF)>>(8-(x))&0x3)
+
+/* PHY power on is LOW_ENABLE */
+#define PWR_ON 0
+#define PWR_OFF1
+
+struct mixel_dphy_cfg {
+ u32 cm;
+ u32 cn;
+ u32 co;
+ unsigned long hs_clk_rate;
+ u8 mc_prg_hs_prepare;
+ u8 m_prg_hs_prepare;
+ u8 mc_prg_hs_zero;
+ u8 m_prg_hs_zero;
+ u8 mc_prg_hs_trail;
+ u8 m_prg_hs_trail;
+};
+
+struct mixel_dphy_priv;
+struct mixel_dphy_ops {
+ int (*probe)(struct mixel_dphy_priv *priv);
+ int (*power_on)(struct phy *phy);
+ int (*power_off)(struct phy *phy);
+};
+
+struct mixel_dphy_priv {
+ struct mixel_dphy_cfg cfg;
+ void __iomem *regs;
+ struct clk *phy_ref_clk;
+ struct mutex lock;
+ const struct mixel_dphy_ops *ops;
+};
+
+static inline u32 phy_read(struct phy *phy, unsigned int reg)
+{
+ struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
+
+ return readl(priv->regs + reg);
+}
+
+static inline void phy_write(struct phy *phy, u32 value, unsigned int reg)
+{
+ struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
+
+ writel(value, priv->regs + reg);
+}
+
+/* Find a ratio close to the desired one using continued fraction
+ approximation ending either at exact match or maximum allowed
+ nominator, denominator. */
+static void get_best_ratio(unsigned long *pnum, unsigned long *pdenom,
unsigned max_n, u
Re: [v4,2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
On Fri, Jan 25, 2019 at 12:13:13AM +0530, Jagan Teki wrote: > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel. > > Add panel driver for it. > > Signed-off-by: Jagan Teki Tested-by: Bhushan Shah -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > [SNIP]
> > This is *exactly* my point the whole time.
> >
> > The current code has
> >
> > static inline bool drm_arch_can_wc_memory(void)
> > {
> > #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
> > return false;
> >
> > which means the optimization is disabled *unless the system is
> > non-cache coherent*
> >
> > So if you have reports that the optimization works on some PowerPC, it
> > must be non-cache coherent PowerPC, because that is the only place
> > where it is enabled in the first place.
> >
> >> The only problematic here actually seems to be ARM, so you should
> >> probably just add an "#ifdef .._ARM return false;".
> >>
> > ARM/arm64 does not have a Kconfig symbol like
> > CONFIG_NOT_COHERENT_CACHE, so we can only disable it everywhere. If
> > there are non-coherent ARM systems that are currently working in the
> > same way as those non-coherent PowerPC systems, we will break them by
> > doing this.
>
> Summing the things I've read so far for ARM up I actually think it
> depends on a runtime configuration and not on compile time one.
>
> So the whole idea of providing the device to the drm_*_can_wc_memory()
> function isn't so far fetched.
>
Thank you.
> But for now I do prefer working and slightly slower system over broken
> one, so I think we should just disable this on ARM for now.
>
Again, this is not about non-cache coherent being slower without the
optimization, it is about non-cache coherent likely not working *at
all* unless the optimization is enabled.
Otherwise, the driver will vmap() DMA pages with cacheable attributes,
while the non-cache coherent device uses uncached attributes, breaking
coherency.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn on SSE2 to support emitting double precision floating point instructions rather than calls to non-existent (usually available from gcc_s or compiler_rt) floating point helper routines. Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html Link: https://github.com/ClangBuiltLinux/linux/issues/327 Cc: sta...@vger.kernel.org # 4.19 Reported-by: S, Shirish Reported-by: Matthias Kaehlcke Suggested-by: James Y Knight Suggested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Tested-by: Guenter Roeck --- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile b/drivers/gpu/drm/amd/display/dc/calcs/Makefile index 95f332ee3e7e..dc85a3c088af 100644 --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) cc_stack_align := -mstack-alignment=16 endif -calcs_ccflags := -mhard-float -msse $(cc_stack_align) +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) CFLAGS_dcn_calcs.o := $(calcs_ccflags) CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index d97ca6528f9d..33c7d7588712 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) cc_stack_align := -mstack-alignment=16 endif -dml_ccflags := -mhard-float -msse $(cc_stack_align) +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) CFLAGS_display_mode_lib.o := $(dml_ccflags) CFLAGS_display_pipe_clocks.o := $(dml_ccflags) -- 2.20.1.321.g9e740568ce-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
On Thu, 24 Jan 2019 at 10:25, Koenig, Christian wrote: > > Am 24.01.19 um 10:13 schrieb Christoph Hellwig: > > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote: > >> But my concern is that it seems likely that non-cache coherent > >> implementations are relying on this hack as well. There must be a > >> reason that this hack is only disabled for PowerPC platforms if they > >> are cache coherent, for instance, and I suspect that that reason is > >> that the hack is the only thing ensuring that the CPU mapping > >> attributes match the device ones used for these buffers (the vmap()ed > >> ones), whereas the rings and other consistent data structures are > >> using the DMA API as intended, and thus getting uncached attributes in > >> the correct way. > > Dave, who added that commit is on Cc together with just about everyone > > involved in the review chain. Based on the previous explanation > > that idea what we might want an uncached mapping for some non-coherent > > architectures for this to work at all makes sense, but then again > > the way to create those mappings is entirely architecture specific, > > and also need a cache flushing before creating the mapping to work > > properly. So my working theory is that this code never properly > > worked on architectures without DMA coherent for PCIe at all, but > > I'd love to be corrected by concrete examples including an explanation > > of how it actually ends up working. > > Cache coherency is mandatory for modern GPU operation. > > Otherwise you can't implement a bunch of the requirements of the > userspace APIs. > > In other words the applications doesn't inform the driver that the GPU > or the CPU is accessing data, it just does it and assumes that it works. > Wonderful! In that case, do you have any objections to the patch proposed by Christoph above? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/26] drm/fb-helper: Add fill_info() functions
On Fri, Jan 25, 2019 at 10:46 AM Noralf Trønnes wrote:
>
>
>
> Den 25.01.2019 09.48, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 24.01.2019 17.58, skrev Daniel Vetter:
> >>> The fbdev split between fix and var information is kinda
> >>> pointless for drm drivers since everything is fixed: The fbdev
> >>> emulation doesn't support changing modes at all.
> >>>
> >>> Create a new simplified helper and use it in the generic fbdev
> >>> helper code. Follow-up patches will beef it up more and roll
> >>> it out to all drivers.
> >>>
> >>> Signed-off-by: Daniel Vetter
> >>> ---
> >>> drivers/gpu/drm/drm_fb_helper.c | 27 +--
> >>> include/drm/drm_fb_helper.h | 1 +
> >>> 2 files changed, 26 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> >>> b/drivers/gpu/drm/drm_fb_helper.c
> >>> index 5eaccd202f4f..34c4ed378796 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -2105,6 +2105,30 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> >>> struct drm_fb_helper *fb_helpe
> >>> }
> >>> EXPORT_SYMBOL(drm_fb_helper_fill_var);
> >>>
> >>> +/**
> >>> + * drm_fb_helper_fill_info - initializes fbdev information
> >>> + * @info: fbdev instance to set up
> >>> + * @fb_helper: fb helper instance to use as template
> >>> + *
> >>> + *
> >>> + * Sets up the variable and fixed fbdev metainformation from the given
> >>> fb helper
> >>> + * instance and the drm framebuffer allocated in &drm_fb_helper.fb.
> >>> + *
> >>> + * Drivers should call this (or their equivalent setup code) from their
> >>> + * &drm_fb_helper_funcs.fb_probe callback after having allocated the
> >>> fbdev
> >>> + * backing storage framebuffer.
> >>> + */
> >>> +void drm_fb_helper_fill_info(struct fb_info *info,
> >>
> >> No need to pass in fb_info it's available as fb_helper->fbdev. Set by
> >> drm_fb_helper_alloc_fbi().
> >
> > Uh, I get to edit all the patches. Still, thanks for pointing out.
> >
> > I also realized that I've forgotten to add the dummy functiont for
> > !CONFIG_FB, will fix that too.
> >
> >>> +struct drm_fb_helper *fb_helper)
> >>> +{
> >>> + struct drm_framebuffer *fb = fb_helper->fb;
> >>> +
> >>> + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
> >>> + drm_fb_helper_fill_var(info, fb_helper, fb->width, fb->height);
> >>
> >> AFAIU fb->width/height can be different from sizes->fb_width/fb_height
> >> when there's double/triple buffering. I belive you need to use the sizes
> >> values here.
> >
> > Yup they're bigger than the actual screen size, but so is sizes: For
> > overallocting we adjust sizes before we call ->fb_probe, and the
> > ->fb_probe callbacks in turn then call this helper. So I think it should
> > be all equivalent. Agreed or do I miss something?
>
> I did a test setting drm_fbdev_overalloc = 200:
>
> [drm:drm_setup_crtcs] desired mode 320x240 set on crtc 33 (0,0)
> [drm:drm_fb_helper_generic_probe] surface width(320), height(480) and
> bpp(16)
> [drm:drm_fb_helper_generic_probe] fb_width(320), fb_height(240)
>
> sizes->surface_height != sizes->fb_height
>
> sizes->surface_height is used to create the framebuffer -> fb->height.
> My driver doesn't allow me to create such a big framebuffer so I didn't
> see the actual fb->height value come out the other end, but I still
> believe you need to use sizes->fb_height.
Hm right, I totally missed that. So the right interface would be:
drm_fb_helper_fill_info(fb_helper, sizes);
I also just noticed tha we could move the call to
drm_fb_helper_fill_info into the helper itself, I think that would
work for all drivers.
-Daniel
>
> Noralf.
>
> > -Daniel
> >
> >>
> >> Noralf.
> >>
> >>> +
> >>> +}
> >>> +EXPORT_SYMBOL(drm_fb_helper_fill_info);
> >>> +
> >>> static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper
> >>> *fb_helper,
> >>> uint32_t maxX,
> >>> uint32_t maxY)
> >>> @@ -3163,8 +3187,7 @@ int drm_fb_helper_generic_probe(struct
> >>> drm_fb_helper *fb_helper,
> >>> #endif
> >>> strcpy(fbi->fix.id, "DRM emulated");
> >>>
> >>> - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> >>> - drm_fb_helper_fill_var(fbi, fb_helper, sizes->fb_width,
> >>> sizes->fb_height);
> >>> + drm_fb_helper_fill_info(fbi, fb_helper);
> >>>
> >>> if (fb->funcs->dirty) {
> >>> struct fb_ops *fbops;
> >>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> >>> index bb9acea61369..e8d92724f472 100644
> >>> --- a/include/drm/drm_fb_helper.h
> >>> +++ b/include/drm/drm_fb_helper.h
> >>> @@ -292,6 +292,7 @@ void drm_fb_helper_fill_var(struct fb_info *info,
> >>> struct drm_fb_helper *fb_helpe
> >>> uint32_t fb_width, uint32_t fb_height);
> >>> void drm_fb_helper_fill_fix(struc
