Re: [PATCH libdrm] xf86drm: fallback to normal path when realpath fails
On 2018-08-23 2:52 p.m., Emil Velikov wrote:
> On Thu, 23 Aug 2018 at 11:38, Michel Dänzer wrote:
>> On 2018-08-23 12:04 p.m., Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> Earlier commit reworked our sysfs handling to use realpath.
>>> Sadly that backfired since the Firefox sandboxing mechanism rejects
>>> that. Despite the files/folders being in the allowed list, of the
>>> sandboxing mechanism.
>>
>> From the Firefox bug report, the problem was stat on the top-level /sys
>> directory.
>>
> That's the part I didn't quite get. I don't see anything in libdrm
> that would do that.
> We do have fstat(open("/dev/dri/foo"), stat("/dev/dri/foo").
>
> I guess the C runtime (compiler?) might be doing that one?
> Like the realpath call being translated to a series of stat() calls.
Yeah, probably something like that.
>>> Oddly enough, the Chromium sandboxing doesn't complain about any of
>>> this.
>>>
>>> Since there are no Firefox releases with the fix, add a temporary
>>> solution which falls back to the original handling.
>>>
>>> Sadly, this won't work for virgl.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
>>> Cc: Michel Dänzer
>>> Cc: Mike
>>> Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
>>> Signed-off-by: Emil Velikov
>>
>> Reviewed-by: Michel Dänzer
>> Tested-by: Michel Dänzer
These are now also valid for v2, thanks again!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v2 2/3] drm/fourcc: Add remaining fourccs for Mali
As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). The AFBC modifiers can be found in [3]. AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed
Re: [PATCH] drm/fourcc: Add DOC: overview comment
Hi Matthew, On Thu, Aug 23, 2018 at 07:34:45AM -0700, Matthew Wilcox wrote: On Wed, Aug 22, 2018 at 04:57:33PM +0100, Brian Starkey wrote: On Wed, Aug 22, 2018 at 05:11:55PM +0200, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 4:59 PM, Eric Engestrom > wrote: > > On Tuesday, 2018-08-21 17:44:17 +0100, Brian Starkey wrote: > > > On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote: > > > > Can you turn them into enums? This seems to work ok: I'm not sure that swapping out explicit 32-bit unsigned integers for enums (unspecified width, signed integers) is necessarily a good idea, it seems like Bad Things could happen. The C spec says: "the value of an enumeration constant shall be an integer constant expression that has a value representable as an int" Which likely gives us 4 bytes to play with on all machines that run Linux, but if drm_fourcc.h is ever going to be some kind of standard reference, making it non-portable seems like a fail. And even if you do have 4 bytes in an enum, signed integers act differently from unsigned ones, and compilers do love to invoke the UB clause... I think you're exaggerating how much latitude C compilers have here. Further down in 6.7.2.2, it says: Each enumerated type shall be compatible with char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration. So if we include an integer which isn't representable in a plain int, then the compiler _must_ choose a larger type. I don't think so... the sentence I pasted says that including a value which isn't representable in a plain int would be illegal, and so the compiler doesn't _have_ to do anything (nasal demons, right?). It could choose a signed-64-bit type rather than an unsigned-32-bit type, but I can't imagine any compiler being quite so insane. The paragraph about the implementation choosing a representation is separate from the valid range of values - the compiler can pick whatever storage it likes (smaller or even larger than an int), so long as that storage can fit all the defined values. However, providing a value in an enum definition which is not representable as an int would still be invalid (irrespective of how large the storage is) - it's a separate restriction. Anyhow, I'm not dying to replace all the current definitions with enums, so if someone else wants to pick that up, be my guest. Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/msm: suspend devfreq on init
On Thu, Aug 23, 2018 at 02:48:27PM +0530, Sharat Masetty wrote: > Devfreq turns on and starts recommending power level as soon as it is > initialized. The GPU is still not powered on by the time the devfreq > init happens and this leads to problems on GPU's where register access > is needed to get/set power levels. So we start suspended and only restart > devfreq when GPU is powered on. Reviewed-by: Jordan Crouse > Signed-off-by: Sharat Masetty > --- > drivers/gpu/drm/msm/msm_gpu.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c > index 5281a32..04f9604 100644 > --- a/drivers/gpu/drm/msm/msm_gpu.c > +++ b/drivers/gpu/drm/msm/msm_gpu.c > @@ -104,6 +104,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu) > dev_err(>pdev->dev, "Couldn't initialize GPU devfreq\n"); > gpu->devfreq.devfreq = NULL; > } > + > + devfreq_suspend_device(gpu->devfreq.devfreq); > } > > static int enable_pwrrail(struct msm_gpu *gpu) > -- > 1.9.1 > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi
Hi Heiko, On 08/21/2018 04:05 PM, Heiko Stuebner wrote: > The Rockchip DSI driver was separate till now, not using the common > bridge driver that was introduced a bit later. So this series migrates > over to use that common bridge driver and then also adds support for > dual-dsi to both the bridge and Rockchip glue code. > > The bridge-migration itself is based on Nickeys earlier v8 > work, but adapted to current kernels and with a new split between probe > and bind, so that we do not create and drop the dsi-host on each deferred > bind attempt. > > changes in v2: > - rebase against newer drm code (dsi-bridge+rockchip changes) > - add SPDX header to new glue driver > - expect regular interface lanes from panel (like 4) not the double number >Similar to tegra > - keep links to both master and slave > changes in v3: > - don't defer in bridge_attach, instead add ability to check for finalized >panel attachement, for example in bind > - address bridge-conversion comments from Andrzej: >- include ordering >- moved hwaccess from mode_set to enable callback >- move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps) > - limited slave settings to dw_mipi_dsi_set_slave > - address dual-dsi comments from Philippe: >- remove unneeded separate variables >- remove unneeded second slave settings >- disable slave before master >- lane-sum calculation comments > changes in v4: > - rebase against some legacy rockchip-dsi changes > - add dsi-component only after panel has attached to dsi host >This solves quite some concurrency problems that happen when trying >to determine dsi-panel availability > changes in v5: > - use driver-internal method to find second host > - drop of-graph based dsi method for it FYI, Yannick tested successfully the v5 version on stm32 boards. Note that drm stm32 drivers do not use bind/unbind & dual-dsi so this email is simply to share with you this minor information: "v5 patch does not break stm32 dsi", hope it helps a little. Many thanks, Philippe :-) > > Unchanged from review comments: > - kept dw_mipi_dsi_bind, as the dsi->bridge member is only part of the >bridge drivers struct, so not accessible from glue drivers > - kept dual-dsi handling that mimicks tegra > > > Heiko Stuebner (4): >drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to > __dw_mipi_dsi_remove >drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from > dw_mipi_dsi_bind >drm/bridge/synopsys: dsi: add ability to have glue-specific attach and > detach >drm/rockchip: dsi: add dual mipi support > > Nickey Yang (3): >dt-bindings: display: rockchip: update DSI controller >drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver >drm/bridge/synopsys: dsi: add dual-dsi support > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 114 +- > drivers/gpu/drm/rockchip/Kconfig |2 +- > drivers/gpu/drm/rockchip/Makefile |2 +- > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1044 + > drivers/gpu/drm/rockchip/dw-mipi-dsi.c| 1349 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.h |3 +- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + > drivers/gpu/drm/rockchip/rockchip_drm_vop.h |4 + > drivers/gpu/drm/rockchip/rockchip_vop_reg.c |1 + > include/drm/bridge/dw_mipi_dsi.h | 14 +- > 12 files changed, 1182 insertions(+), 1379 deletions(-) > create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c > delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] drm/bridge: ti-sn65dsi86: Add mystery delay to enable()
On Tue, Aug 14, 2018 at 10:01:45AM -0400, Sean Paul wrote: > On Tue, Aug 14, 2018 at 10:00:33AM -0400, Sean Paul wrote: > > On Tue, Aug 14, 2018 at 04:59:31PM +0530, spa...@codeaurora.org wrote: > > > On 2018-08-14 03:00, Sean Paul wrote: > > > > From: Sean Paul > > > > > > > > This patch adds a 70ms mystery delay to the bridge driver in enable. > > > > By experimentation, it seems like it can go anywhere up until we > > > > initiate semi-auto link training. If we don't have the delay, link > > > > training fails. > > > > > > > > I tried to root cause this as best I could, but neither the datasheet > > > > for the panel nor the bridge mention a delay of this magnitude in their > > > > timing requirements. So for now, add the mystery delay until someone > > > > figures out a better fix. > > > > > > > > Changes in v3: > > > > - Added to the set > > > > > > > > Cc: Sandeep Panda > > > > Signed-off-by: Sean Paul > > > > --- > > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 > > > > 1 file changed, 12 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > index d3e27e52ea759..f8a931cf3665e 100644 > > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > > > @@ -458,6 +458,18 @@ static void ti_sn_bridge_enable(struct drm_bridge > > > > *bridge) > > > > unsigned int val; > > > > int ret; > > > > > > > > + /* > > > > +* FIXME: > > > > +* This 70ms was found necessary by experimentation. If it's not > > > > +* present, link training fails. It seems like it can go > > > > anywhere from > > > > +* pre_enable() up to semi-auto link training initiation below. > > > > +* > > > > +* Neither the datasheet for the bridge nor the panel tested > > > > mention a > > > > +* delay of this magnitude in the timing requirements. So for > > > > now, add > > > > +* the mystery delay until someone figures out a better fix. > > > > +*/ > > > > > > Is this newly found issue? Specific to any board config? > > > > It's specific to cheza. > > Well, I suppose I shouldn't say that since I've not tried the bridge on > another > board. I should say, it reproduces on cheza. Ping. Sandeep: any more feedback? Sean > > Sean > > > This was found with swboyd changed the panel regulator > > from always-on/boot-on to toggle. > > > > I've pushed the tag "mtp-testing-0813" to dpu-staging so you can play around > > with it. Without this delay, link training fails. > > > > Sean > > > > > > > > > + msleep(70); > > > > + > > > > /* DSI_A lane config */ > > > > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > > > > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG, > > > > -- > > Sean Paul, Software Engineer, Google / Chromium OS > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- 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 3/5] drm/msm/A6x: Add gmu_read64() register read op
On Thu, Aug 23, 2018 at 02:48:29PM +0530, Sharat Masetty wrote:
> Add a simple function to read 64 registers in the GMU domain
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> index a08ee8f..f9e4dfe 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> @@ -106,6 +106,19 @@ static inline void gmu_rmw(struct a6xx_gmu *gmu, u32
> reg, u32 mask, u32 or)
> gmu_write(gmu, reg, val | or);
> }
>
> +static inline u64 gmu_read64(struct a6xx_gmu *gmu, u32 lo, u32 hi)
> +{
> + u64 val;
> +
> + /*
> + * Implementation similar to gpu_read64()
> + */
I'm not sure this comment is really needed, and it certainly could just be one
line if it is.
> + val = (u64) msm_readl(gmu->mmio + (lo << 2));
> + val |= ((u64) msm_readl(gmu->mmio + (hi << 2)) << 32);
> +
> + return val;
> +}
> +
> #define gmu_poll_timeout(gmu, addr, val, cond, interval, timeout) \
> readl_poll_timeout((gmu)->mmio + ((addr) << 2), val, cond, \
> interval, timeout)
> --
> 1.9.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: add in missing sentinel to a of_device_id array
Hi, Colin
I has posted the same patch about a month ago. but it seems to be ignored.:-(
https://lore.kernel.org/patchwork/patch/971652/
Thanks,
zhong jiang
On 2018/8/21 18:54, Colin King wrote:
> From: Colin Ian King
>
> Array vexpress_muxfpga_match is missing an end of array sentinel,
> add it.
>
> Detected by Coccinelle: ("vexpress_muxfpga_match is not NULL
> terminated at line")
>
> Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/pl111/pl111_vexpress.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c
> b/drivers/gpu/drm/pl111/pl111_vexpress.c
> index a534b225e31b..48e2afcd4798 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.c
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
> @@ -111,7 +111,8 @@ static int vexpress_muxfpga_probe(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id vexpress_muxfpga_match[] = {
> - { .compatible = "arm,vexpress-muxfpga", }
> + { .compatible = "arm,vexpress-muxfpga", },
> + { /* sentinel */ }
> };
>
> static struct platform_driver vexpress_muxfpga_driver = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
Ping, Anyone has any objections a about the patch?
Best wishes,
zhong jiang
On 2018/8/17 10:24, zhong jiang wrote:
> for_each_available_child_of_node will get and put the node properly,
> the following of_node_put will lead to the double put. So just
> remove it.
>
> Signed-off-by: zhong jiang
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 6f4205e8..d7b9870 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -161,10 +161,8 @@ static int zx_drm_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - for_each_available_child_of_node(parent, child) {
> + for_each_available_child_of_node(parent, child)
> component_match_add(dev, , compare_of, child);
> - of_node_put(child);
> - }
>
> return component_master_add_with_match(dev, _drm_master_ops, match);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107595] amd-staging-drm-next: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 - R4 Mullins
https://bugs.freedesktop.org/show_bug.cgi?id=107595 --- Comment #10 from Michel Dänzer --- Thanks for testing the patches. Looks like there's still an issue with DC. -- 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 105913] [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c
https://bugs.freedesktop.org/show_bug.cgi?id=105913 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Lakshmi --- Closing as not a bug. -- 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 v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> wrote:
> > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
> >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> >> > > > The previous patch added tile_w and tile_h, which represent the
> >> > > > horizontal and vertical sizes of a tile.
> >> > > >
> >> > > > This one uses that to plumb through drm core in order to be able to
> >> > > > handle linear tile formats without the need for drivers to roll up
> >> > > > their own implementation.
> >> > > >
> >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> >> > > >
> >> > > > Now what are the restrictions:
> >> > > >
> >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> >> > > > pixels. Due to this the places where the pitch is checked/used need
> >> > > > to
> >> > > > be updated to take into consideration the tile_w, tile_h and
> >> > > > tile_size.
> >> > > > tile_size = cpp * tile_w * tile_h
> >> > > >
> >> > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> >> > > > tile_w/tile_h and we need to take into consideration the
> >> > > > tile_w/tile_h
> >> > > > when computing the start address.
> >> > > >
> >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> >> > > > didn't miss anything nothing should change.
> >> > > >
> >> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> >> > > > should be handle I kind of assumed that tile_h/tile_w will have to be
> >> > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> >> > > > put an warning in there and handle it when someone tries to add
> >> > > > support for them.
> >> > > >
> >> > > > Signed-off-by: Alexandru Gheorghe
> >> > > > ---
> >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> >> > > >
> >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> >> > > > include/drm/drm_fourcc.h | 2 +
> >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> >> > > >
> >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> >> > > > b/drivers/gpu/drm/drm_atomic.c
> >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> >> > > > drm_plane *plane,
> >> > > > return -ENOSPC;
> >> > > > }
> >> > > >
> >> > > > + /* Make sure source coordinates are a multiple of tile sizes
> >> > > > */
> >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates
> >> > > > do not meet tile restrictions",
> >> > > > +plane->base.id, plane->name);
> >> > > > + return -EINVAL;
> >> > > > + }
> >> > >
> >> > > Feels rather wrong to me to put such hardware specific limitations into
> >> > > the core.
> >> >
> >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> >> > work.
> >>
> >> If that guy is supposed to give you a tile aligned address then it could
> >> just do that and leave it up to the driver to deal with the remainder of
> >> the coordinates?
> >>
> >> >
> >> > An alternative, would be to include it in the driver and put an WARN
> >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> >> > src_x/src_y tile multiples.
> >> >
> >> > What do you think about that ?
> >> >
> >> > >
> >> > > > +
> >> > > > if (plane_switching_crtc(state->state, plane, state)) {
> >> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> >> > > > directly\n",
> >> > > > plane->base.id, plane->name);
> >> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > index 47e0e2f6642d..4d8052adce67 100644
> >> > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> >> > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> >> > > > drm_framebuffer *fb,
> >> > > > struct drm_gem_cma_object *obj;
> >> > > > dma_addr_t paddr;
> >> > > > u8
[RFC PATCH v2 1/3] drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel
Some formats have a non-integer number of bytes per pixel, which can't
be handled with the existing 'cpp' field in drm_format_info. To handle
these formats, add a 'bpp' field, which is only used if cpp[0] == 0.
This updates all the users of format->cpp in the core DRM code,
converting them to use a new function to get the bits-per-pixel for any
format.
It's assumed that drivers will use the 'bpp' field when they add support
for pixel formats with non-integer bytes-per-pixel.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_fb_cma_helper.c | 6 +++-
drivers/gpu/drm/drm_fb_helper.c | 8 +++--
drivers/gpu/drm/drm_fourcc.c | 50
drivers/gpu/drm/drm_framebuffer.c| 8 ++---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +-
include/drm/drm_fourcc.h | 4 +++
6 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..e279d70d3e60 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -118,13 +118,17 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
{
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
+ u8 bpp = drm_format_info_plane_bpp(fb->format, plane);
+
+ /* This can't work for non-integer bytes-per-pixel */
+ WARN_ON(bpp % 8);
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
return 0;
paddr = obj->paddr + fb->offsets[plane];
- paddr += fb->format->cpp[plane] * (state->src_x >> 16);
+ paddr += (bpp / 8) * (state->src_x >> 16);
paddr += fb->pitches[plane] * (state->src_y >> 16);
return paddr;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b108030b..ab369f250af4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1572,6 +1572,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct drm_fb_helper *fb_helper = info->par;
struct drm_framebuffer *fb = fb_helper->fb;
int depth;
+ u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
@@ -1580,14 +1581,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
*/
- if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
+ if (var->bits_per_pixel != bpp ||
var->xres > fb->width || var->yres > fb->height ||
var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
DRM_DEBUG("fb requested width/height/bpp can't fit in current
fb "
"request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
var->xres, var->yres, var->bits_per_pixel,
var->xres_virtual, var->yres_virtual,
- fb->width, fb->height, fb->format->cpp[0] * 8);
+ fb->width, fb->height, bpp);
return -EINVAL;
}
@@ -1949,11 +1950,12 @@ void drm_fb_helper_fill_var(struct fb_info *info,
struct drm_fb_helper *fb_helpe
uint32_t fb_width, uint32_t fb_height)
{
struct drm_framebuffer *fb = fb_helper->fb;
+ u8 bpp = drm_format_info_plane_bpp(fb->format, 0);
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
info->var.yres_virtual = fb->height;
- info->var.bits_per_pixel = fb->format->cpp[0] * 8;
+ info->var.bits_per_pixel = bpp;
info->var.accel_flags = FB_ACCELF_TEXT;
info->var.xoffset = 0;
info->var.yoffset = 0;
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 3b42c25bd58d..bb28919c32f3 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -272,10 +272,60 @@ int drm_format_plane_cpp(uint32_t format, int plane)
if (!info || plane >= info->num_planes)
return 0;
+ /*
+* Not valid for formats with non-integer cpp,
+* use drm_format{_info}_plane_bpp instead
+*/
+ WARN_ON(!info->cpp[0]);
+
return info->cpp[plane];
}
EXPORT_SYMBOL(drm_format_plane_cpp);
+/**
+ * drm_format_plane_bpp - determine the bits per pixel value
+ * @format: pixel format (DRM_FORMAT_*)
+ * @plane: plane index
+ *
+ * Returns:
+ * The bits per pixel value for the specified plane.
+ */
+int drm_format_plane_bpp(uint32_t format, int plane)
+{
+ const struct drm_format_info *info;
+
+ info = drm_format_info(format);
+ if (!info)
+ return 0;
+
+ return drm_format_info_plane_bpp(info, plane);
+}
+EXPORT_SYMBOL(drm_format_plane_bpp);
+
[RFC PATCH v2 3/3] drm/afbc: Add AFBC modifier usage documentation
AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey --- Documentation/gpu/afbc.rst| 226 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 231 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index ..58d2b6b5d48b --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,226 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) + * Component 3: A(2) + +
[RFC PATCH v2 0/3] Groundwork for AFBC YUV formats
Hi, This is the second round of RFC for adding a bunch of new YUV formats for Mali/AFBC. I've included a proper AFBC documentation file too, for posterity. Some of the new formats don't have an integer number of bytes-per-pixel, so I've added a bpp field to drm_format_info (patch 1), keen to hear thoughts on that. These three patches don't make a huge amount of sense in isolation, so we'll pull them into a more comprehensive series for AFBC support to merge them later. Thanks, -Brian Brian Starkey (3): drm/fourcc: Add 'bpp' field for formats with non-integer bytes-per-pixel drm/fourcc: Add remaining fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst | 226 +++ Documentation/gpu/drivers.rst| 1 + MAINTAINERS | 1 + drivers/gpu/drm/drm_fb_cma_helper.c | 6 +- drivers/gpu/drm/drm_fb_helper.c | 8 +- drivers/gpu/drm/drm_fourcc.c | 57 +++ drivers/gpu/drm/drm_framebuffer.c| 41 - drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 +- include/drm/drm_fourcc.h | 4 + include/uapi/drm/drm_fourcc.h| 17 ++ 10 files changed, 351 insertions(+), 13 deletions(-) create mode 100644 Documentation/gpu/afbc.rst -- 2.16.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] msm/drm: A6x DCVS series
On Thu, Aug 23, 2018 at 02:48:26PM +0530, Sharat Masetty wrote: > This patch series starts off with a few bug fixes in devfreq code, followed by > refactoring the devfreq code needed for supporting different chipsets, and > ends with adding devfreq support for A6x. Just an aside, I'm a sucker for consistency and I know the form A6x and A6xx are used interchangeably downstream but I feel like we should be more consistent upstream. I like the form a6xx since it matches the fine names and functions and is technically more correct in terms of the actual core name. > Sharat Masetty (5): > drm/msm: suspend devfreq on init > drm/msm: unregister devfreq upon clean up > drm/msm/A6x: Add gmu_read64() register read op > drm/msm: re-factor devfreq code > drm/msm/A6x: Add devfreq support in A6x > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46 ++ > drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 15 ++ > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 ++ > drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++ > drivers/gpu/drm/msm/msm_gpu.c | 53 > +-- > drivers/gpu/drm/msm/msm_gpu.h | 5 +++- > 7 files changed, 133 insertions(+), 31 deletions(-) > > -- > 1.9.1 > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/malidp: Fix writeback in NV12
On Wed, Aug 22, 2018 at 04:18:19PM +0100, Alexandru Gheorghe wrote:
> When we want to writeback to memory in NV12 format we need to program
> the RGB2YUV coefficients. Currently, we don't program the coefficients
> and NV12 doesn't work at all.
>
> This patchset fixes that by programming a sane default(bt709, limited
> range) as rgb2yuv coefficients.
>
> In the long run, probably we need to think of a way for userspace to
> be able to program that, but for now I think this is better than not
> working at all or not advertising NV12 as a supported format for
> memwrite.
>
> Changes since v1:
> - Write the rgb2yuv coefficients only once, since we don't change
>them at all, just write them the first time NV12 is programmed,
>suggested by Brian Starkey, here [1]
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186819.html
>
> Signed-off-by: Alexandru Gheorghe
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 25 +++--
> drivers/gpu/drm/arm/malidp_hw.h | 3 ++-
> drivers/gpu/drm/arm/malidp_mw.c | 25 +
> drivers/gpu/drm/arm/malidp_regs.h | 2 ++
> 4 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index c94a4422e0e9..2781e462c1ed 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -384,7 +384,8 @@ static long malidp500_se_calc_mclk(struct
> malidp_hw_device *hwdev,
>
> static int malidp500_enable_memwrite(struct malidp_hw_device *hwdev,
>dma_addr_t *addrs, s32 *pitches,
> - int num_planes, u16 w, u16 h, u32 fmt_id)
> + int num_planes, u16 w, u16 h, u32 fmt_id,
> + const s16 *rgb2yuv_coeffs)
> {
> u32 base = MALIDP500_SE_MEMWRITE_BASE;
> u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
> @@ -416,6 +417,16 @@ static int malidp500_enable_memwrite(struct
> malidp_hw_device *hwdev,
>
> malidp_hw_write(hwdev, MALIDP_DE_H_ACTIVE(w) | MALIDP_DE_V_ACTIVE(h),
> MALIDP500_SE_MEMWRITE_OUT_SIZE);
> +
> + if (rgb2yuv_coeffs) {
> + int i;
> +
> + for (i = 0; i < MALIDP_COLORADJ_NUM_COEFFS; i++) {
> + malidp_hw_write(hwdev, rgb2yuv_coeffs[i],
> + MALIDP500_SE_RGB_YUV_COEFFS + i * 4);
> + }
> + }
> +
> malidp_hw_setbits(hwdev, MALIDP_SE_MEMWRITE_EN, MALIDP500_SE_CONTROL);
>
> return 0;
> @@ -658,7 +669,8 @@ static long malidp550_se_calc_mclk(struct
> malidp_hw_device *hwdev,
>
> static int malidp550_enable_memwrite(struct malidp_hw_device *hwdev,
>dma_addr_t *addrs, s32 *pitches,
> - int num_planes, u16 w, u16 h, u32 fmt_id)
> + int num_planes, u16 w, u16 h, u32 fmt_id,
> + const s16 *rgb2yuv_coeffs)
> {
> u32 base = MALIDP550_SE_MEMWRITE_BASE;
> u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
> @@ -689,6 +701,15 @@ static int malidp550_enable_memwrite(struct
> malidp_hw_device *hwdev,
> malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT |
> MALIDP_SE_MEMWRITE_EN,
> MALIDP550_SE_CONTROL);
>
> + if (rgb2yuv_coeffs) {
> + int i;
> +
> + for (i = 0; i < MALIDP_COLORADJ_NUM_COEFFS; i++) {
> + malidp_hw_write(hwdev, rgb2yuv_coeffs[i],
> + MALIDP550_SE_RGB_YUV_COEFFS + i * 4);
> + }
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
> index ad2e96915d44..9fc94c08190f 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.h
> +++ b/drivers/gpu/drm/arm/malidp_hw.h
> @@ -191,7 +191,8 @@ struct malidp_hw {
>* @param fmt_id - internal format ID of output buffer
>*/
> int (*enable_memwrite)(struct malidp_hw_device *hwdev, dma_addr_t
> *addrs,
> -s32 *pitches, int num_planes, u16 w, u16 h, u32
> fmt_id);
> +s32 *pitches, int num_planes, u16 w, u16 h, u32
> fmt_id,
> +const s16 *rgb2yuv_coeffs);
>
> /*
>* Disable the writing to memory of the next frame's content.
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index cfd718e7e97c..429a11e6473b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -26,6 +26,8 @@ struct malidp_mw_connector_state {
> s32 pitches[2];
> u8 format;
> u8 n_planes;
> + bool rgb2yuv_initialized;
> + const s16 *rgb2yuv_coeffs;
> };
>
> static int malidp_mw_connector_get_modes(struct drm_connector *connector)
> @@
Re: [PATCH] drm: Fix crtc color management when doing suspend/resume
Hi Alex,
On Thu, Aug 23, 2018 at 04:11:17PM +0100, Alexandru Gheorghe wrote:
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problems is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the save state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true if the crtc duplicated
state differs from the reset state.
Signed-off-by: Alexandru Gheorghe
LGTM.
Reviewed-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6dd5036545ec..e88aa62bc822 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3196,8 +3196,13 @@ int drm_atomic_helper_commit_duplicated_state(struct
drm_atomic_state *state,
for_each_new_plane_in_state(state, plane, new_plane_state, i)
state->planes[i].old_state = plane->state;
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
state->crtcs[i].old_state = crtc->state;
+ new_crtc_state->color_mgmt_changed =
+ new_crtc_state->degamma_lut != crtc->state->degamma_lut
||
+ new_crtc_state->ctm != crtc->state->ctm ||
+ new_crtc_state->gamma_lut != crtc->state->gamma_lut;
+ }
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/msm: re-factor devfreq code
On Thu, Aug 23, 2018 at 02:48:30PM +0530, Sharat Masetty wrote:
> devfreq framework requires the drivers to provide busy time estimations.
It would help if you added an article to this sentence, i.e: "The devfreq
framework..."
> The GPU driver relies on the hardware performance counteres for the busy time
> estimations, but different hardware revisions have counters which can be
> sourced from different clocks. So the busy time estimation will be target
> dependent. Additionally on targets where the clocks are completely controlled
> by the on chip microcontroller, fetching and setting the current GPU frequency
> will be different. This patch aims to embrace these differences by
> re-factoring
> the devfreq code a bit.
Other than that, the code looks good. A bit of churn, but for a good cause.
Reviewed-by: Jordan Crouse
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 +---
> drivers/gpu/drm/msm/msm_gpu.c | 49
> ---
> drivers/gpu/drm/msm/msm_gpu.h | 5 +++-
> 3 files changed, 44 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 897f3e2..043e680 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1369,12 +1369,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
> msm_gpu *gpu)
> return a5xx_gpu->cur_ring;
> }
>
> -static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
> +static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
> {
> - *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> - REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> + u64 busy_cycles;
> + unsigned long busy_time;
>
> - return 0;
> + busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> + REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> +
> + busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
> + (clk_get_rate(gpu->core_clk) / 100);
> +
> + gpu->devfreq.busy_cycles = busy_cycles;
> +
> + return busy_time;
> }
>
> static const struct adreno_gpu_funcs funcs = {
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 83fd602..32269ef 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -36,12 +36,16 @@ static int msm_devfreq_target(struct device *dev,
> unsigned long *freq,
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> struct dev_pm_opp *opp;
>
> - opp = dev_pm_opp_find_freq_ceil(dev, freq);
> + opp = devfreq_recommended_opp(dev, freq, flags);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
>
> - if (!IS_ERR(opp)) {
> + if (gpu->funcs->gpu_set_freq)
> + gpu->funcs->gpu_set_freq(gpu, (u64)*freq);
> + else
> clk_set_rate(gpu->core_clk, *freq);
> - dev_pm_opp_put(opp);
> - }
> +
> + dev_pm_opp_put(opp);
>
> return 0;
> }
> @@ -50,16 +54,14 @@ static int msm_devfreq_get_dev_status(struct device *dev,
> struct devfreq_dev_status *status)
> {
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> - u64 cycles;
> ktime_t time;
>
> - status->current_frequency = (unsigned long) clk_get_rate(gpu->core_clk);
> - gpu->funcs->gpu_busy(gpu, );
> -
> - status->busy_time = (cycles - gpu->devfreq.busy_cycles) /
> - (status->current_frequency / 100);
> + if (gpu->funcs->gpu_get_freq)
> + status->current_frequency = gpu->funcs->gpu_get_freq(gpu);
> + else
> + status->current_frequency = clk_get_rate(gpu->core_clk);
>
> - gpu->devfreq.busy_cycles = cycles;
> + status->busy_time = gpu->funcs->gpu_busy(gpu);
>
> time = ktime_get();
> status->total_time = ktime_us_delta(time, gpu->devfreq.time);
> @@ -72,7 +74,10 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
> unsigned long *freq)
> {
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
>
> - *freq = (unsigned long) clk_get_rate(gpu->core_clk);
> + if (gpu->funcs->gpu_get_freq)
> + *freq = gpu->funcs->gpu_get_freq(gpu);
> + else
> + *freq = clk_get_rate(gpu->core_clk);
>
> return 0;
> }
> @@ -87,7 +92,7 @@ static int msm_devfreq_get_cur_freq(struct device *dev,
> unsigned long *freq)
> static void msm_devfreq_init(struct msm_gpu *gpu)
> {
> /* We need target support to do devfreq */
> - if (!gpu->funcs->gpu_busy || !gpu->core_clk)
> + if (!gpu->funcs->gpu_busy)
> return;
>
> msm_devfreq_profile.initial_freq = gpu->fast_rate;
> @@ -185,6 +190,14 @@ static int disable_axi(struct msm_gpu *gpu)
> return 0;
> }
>
> +void msm_gpu_resume_devfreq(struct msm_gpu *gpu)
> +{
> + gpu->devfreq.busy_cycles = 0;
[PATCH libdrm v2] xf86drm: fallback to normal path when realpath fails
From: Emil Velikov
Earlier commit reworked our sysfs handling to use realpath.
Sadly that backfired since the Firefox sandboxing mechanism rejects
that. Despite the files/folders being in the allowed list, of the
sandboxing mechanism.
Oddly enough, the Chromium sandboxing doesn't complain about any of
this.
Since there are no Firefox releases with the fix, add a temporary
solution which falls back to the original handling.
Sadly, this won't work for virgl.
v2: drop return type - function cannot return NULL (Eric)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
Cc: Michel Dänzer
Cc: Mike
Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
Signed-off-by: Emil Velikov
Reviewed-by: Michel Dänzer (v1)
Tested-by: Michel Dänzer (v1)
---
xf86drm.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 336d64de..7807dce9 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3014,6 +3014,12 @@ get_real_pci_path(int maj, int min, char *real_path)
return real_path;
}
+static void
+get_normal_pci_path(int maj, int min, char *normal_path)
+{
+snprintf(normal_path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+}
+
static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
{
#ifdef __linux__
@@ -3022,7 +3028,7 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
int num;
if (get_real_pci_path(maj, min, real_path) == NULL)
-return -ENOENT;
+get_normal_pci_path(maj, min, real_path);
value = sysfs_uevent_get(real_path, "PCI_SLOT_NAME");
if (!value)
@@ -3143,7 +3149,7 @@ static int parse_separate_sysfs_files(int maj, int min,
int ret;
if (get_real_pci_path(maj, min, real_path) == NULL)
-return -ENOENT;
+get_normal_pci_path(maj, min, real_path);
for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
snprintf(path, PATH_MAX, "%s/%s", real_path, attrs[i]);
@@ -3175,7 +3181,7 @@ static int parse_config_sysfs_file(int maj, int min,
int fd, ret;
if (get_real_pci_path(maj, min, real_path) == NULL)
-return -ENOENT;
+get_normal_pci_path(maj, min, real_path);
snprintf(path, PATH_MAX, "%s/config", real_path);
fd = open(path, O_RDONLY);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm: Add per-plane pixel blend mode property
On Thu, Aug 23, 2018 at 04:30:19PM +0800, Lowry Li wrote:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Adds a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Changes since v1:
> - Moves the blending equation into the DOC comment
> - Refines the comments of drm_plane_create_blend_mode_property to not
>enumerate the #defines, but instead the string values
> - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
> Changes since v2:
> - Refines the comments of drm_plane_create_blend_mode_property:
> 1) Puts the descriptions (after the ":") on a new line
> 2) Adds explaining why @supported_modes need PREMUL as default
> Changes since v3:
> - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
>can calculate the index itself just fine, so no point in having the
>caller pass it in.
> - Since the current DRM assumption is that alpha is premultiplied
>as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
> - Refines some comments.
> Changes since v4:
> - Adds comments in drm_blend.h.
> - Removes setting default value in drm_plane_create_blend_mode_property()
>as it is already in __drm_atomic_helper_plane_reset().
> - Fixes to use state->pixel_blend_mode instead of using
>plane->state->pixel_blend_mode in reset function.
> - Rebases on drm-misc-next.
>
> Reviewed-by: Liviu Dudau
Reviewed-by: Sean Paul
I've also Reviewed the userspace component in drm_hwc here:
https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/16#note_24690
Thanks,
Sean
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/drm_blend.c | 123
>
> include/drm/drm_blend.h | 6 ++
> include/drm/drm_plane.h | 9 +++
> 5 files changed, 143 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e..d0478ab 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -895,6 +895,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->src_h = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
> } else if (property == plane->rotation_property) {
> if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> 0x%llx\n",
> @@ -968,6 +970,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->src_h;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
> } else if (property == plane->rotation_property) {
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6dd5036..284a5d2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3569,6 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane
> *plane,
> /* Reset the alpha value to fully opaque if it matters */
> if (plane->alpha_property)
> state->alpha = plane->alpha_property->values[1];
> + state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> plane->state = state;
> }
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d..402b62d 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,52 @@
> * planes. Without this property the primary plane is always below the
> cursor
> * plane, and ordering between all other planes is undefined.
> *
> + * pixel blend mode:
> + * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> + * It adds a blend mode for alpha blending equation selection, describing
> + * how the pixels from the current plane are composited with the
> + * background.
> + *
> + *Three alpha blending equations are defined:
> + *
> + *"None":
> + *Blend formula that ignores the pixel alpha::
> + *
> + *out.rgb = plane_alpha * fg.rgb +
> + *(1 - plane_alpha) * bg.rgb
> + *
> + *"Pre-multiplied":
> + *Blend formula that assumes the pixel color values
> + *have been already pre-multiplied with the alpha
[PATCH] drm: Fix crtc color management when doing suspend/resume
When doing suspend/resume drivers usually use the
drm_atomic_helper_suspend/drm_atomic_helper_resume pair for saving the
state and then re-comitting it.
The problems is that drm_crtc_state has a bool field called
color_mgmt_changed, which mali-dp and other drivers uses it to detect
if coefficients need to be reprogrammed, but that never happens
because the save state has color_mgmt_changed set to 0.
Fix that by setting color_mgmt_changed to true if the crtc duplicated
state differs from the reset state.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_atomic_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6dd5036545ec..e88aa62bc822 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3196,8 +3196,13 @@ int drm_atomic_helper_commit_duplicated_state(struct
drm_atomic_state *state,
for_each_new_plane_in_state(state, plane, new_plane_state, i)
state->planes[i].old_state = plane->state;
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
state->crtcs[i].old_state = crtc->state;
+ new_crtc_state->color_mgmt_changed =
+ new_crtc_state->degamma_lut != crtc->state->degamma_lut
||
+ new_crtc_state->ctm != crtc->state->ctm ||
+ new_crtc_state->gamma_lut != crtc->state->gamma_lut;
+ }
for_each_new_connector_in_state(state, connector, new_conn_state, i)
state->connectors[i].old_state = connector->state;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/msm: unregister devfreq upon clean up
On Thu, Aug 23, 2018 at 02:48:28PM +0530, Sharat Masetty wrote:
> Call the devfreq_remove_device() API to remove the GPU devfreq instance
> during GPU driver cleanup.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 04f9604..83fd602 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -970,6 +970,8 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
>
> WARN_ON(!list_empty(>active_list));
>
> + devfreq_remove_device(gpu->devfreq.devfreq);
> +
Because everything eventually gets a devm_ wrapper we do have
devm_devfreq_add_device() - maybe that would be a better solution?
Jordan
> for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
> msm_ringbuffer_destroy(gpu->rb[i]);
> gpu->rb[i] = NULL;
> --
> 1.9.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2] xf86drm: fallback to normal path when realpath fails
On Thursday, 2018-08-23 14:37:28 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Earlier commit reworked our sysfs handling to use realpath.
> Sadly that backfired since the Firefox sandboxing mechanism rejects
> that. Despite the files/folders being in the allowed list, of the
> sandboxing mechanism.
>
> Oddly enough, the Chromium sandboxing doesn't complain about any of
> this.
>
> Since there are no Firefox releases with the fix, add a temporary
> solution which falls back to the original handling.
>
> Sadly, this won't work for virgl.
>
> v2: drop return type - function cannot return NULL (Eric)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107516
> Cc: Michel Dänzer
> Cc: Mike
> Fixes: a02900133b3 ("xf86drm: introduce a get_real_pci_path() helper")
> Signed-off-by: Emil Velikov
> Reviewed-by: Michel Dänzer (v1)
> Tested-by: Michel Dänzer (v1)
Reviewed-by: Eric Engestrom
> ---
> xf86drm.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 336d64de..7807dce9 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3014,6 +3014,12 @@ get_real_pci_path(int maj, int min, char *real_path)
> return real_path;
> }
>
> +static void
> +get_normal_pci_path(int maj, int min, char *normal_path)
> +{
> +snprintf(normal_path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
> +}
> +
> static int drmParsePciBusInfo(int maj, int min, drmPciBusInfoPtr info)
> {
> #ifdef __linux__
> @@ -3022,7 +3028,7 @@ static int drmParsePciBusInfo(int maj, int min,
> drmPciBusInfoPtr info)
> int num;
>
> if (get_real_pci_path(maj, min, real_path) == NULL)
> -return -ENOENT;
> +get_normal_pci_path(maj, min, real_path);
>
> value = sysfs_uevent_get(real_path, "PCI_SLOT_NAME");
> if (!value)
> @@ -3143,7 +3149,7 @@ static int parse_separate_sysfs_files(int maj, int min,
> int ret;
>
> if (get_real_pci_path(maj, min, real_path) == NULL)
> -return -ENOENT;
> +get_normal_pci_path(maj, min, real_path);
>
> for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
> snprintf(path, PATH_MAX, "%s/%s", real_path, attrs[i]);
> @@ -3175,7 +3181,7 @@ static int parse_config_sysfs_file(int maj, int min,
> int fd, ret;
>
> if (get_real_pci_path(maj, min, real_path) == NULL)
> -return -ENOENT;
> +get_normal_pci_path(maj, min, real_path);
>
> snprintf(path, PATH_MAX, "%s/config", real_path);
> fd = open(path, O_RDONLY);
> --
> 2.18.0
>
> ___
> 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 5/5] drm/msm/A6x: Add devfreq support in A6x
On Thu, Aug 23, 2018 at 02:48:31PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to set this new frequency on the GPU by
> sending an Out Of Band(OOB) request.
"sending an Out of Band (OOB) request _to the GMU_". Otherwise it is a little
confusing as to who is doing what.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 46
> +++
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++
> 4 files changed, 72 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index f6634c0..92ff48b 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -67,8 +67,10 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
> }
>
> -static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> +static int __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> + int ret;
Should be a u32 since we are doing a gmu_read().
> +
> gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
>
> gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
> @@ -84,7 +86,41 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
> index)
> a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
> a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
>
> - return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + if (!ret)
> + gmu->cur_freq = gmu->gpu_freqs[index];
> +
'ret' from the register read won't be an appropriate Unix error message so it
should be translated - otherwise it will be confusing because
'a6xx_gmu_set_freq' otherwise returns 0 or valid error messages.
> + return ret;
> +}
> +
> +int a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_gmu *gmu = _gpu->gmu;
> + u32 perf_index = 0;
> +
> + if (freq == gmu->cur_freq)
> + return 0;
> +
> + //TODO: Use a hashmap instead? This gets called potentially every ~10 ms
Please don't use C++ style comments. A TODO is okay, but I would prefer if you
solved this question. I'm not sure if walking a short list of 10 items is a big
concern if it happens every 10ms or so.
> + for (perf_index = 0; perf_index < gmu->nr_gpu_freqs; perf_index++)
> + if (freq == gmu->gpu_freqs[perf_index])
> + break;
Are you positive we don't need to worry about rounding here - will devfreq
*always* give you an exact frequency value? I know the clock subsystem allows
for rounding. You might want to double check just to be sure that we don't need
to worry about that here.
In particular, I would be concerned about the userspace governor for devfreq
where the user can set anything they want. I'm not 100% sure that gets vetted
against the OPP table before we get to this point.
> + if (perf_index == gmu->nr_gpu_freqs)
> + return -EINVAL;
Related to the previous comment slightly, if devfreq wants to set a frequency of
a hundred million HZ is it an error or should we just clamp to the highest
available frequency and call it good?
> + return __a6xx_gmu_set_freq(gmu, perf_index);
> +}
> +
> +unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> + struct a6xx_gmu *gmu = _gpu->gmu;
> +
> + return gmu->cur_freq;
> }
>
> static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
> @@ -629,8 +665,8 @@ int a6xx_gmu_reset(struct a6xx_gpu *a6xx_gpu)
> if (!ret)
> ret = a6xx_hfi_start(gmu, GMU_COLD_BOOT);
>
> - /* Set the GPU back to the highest power frequency */
> - a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
> + /* Save the current frequency for devfreq */
> + gmu->cur_freq = gmu->gpu_freqs[gmu->nr_gpu_freqs - 1];
I'm not sure I understand this change - don't we need to set the frequency
GPU immediately out of reset even if DCVS is expected to change it soon?
>
> out:
> if (ret)
> @@ -671,7 +707,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> ret = a6xx_hfi_start(gmu, status);
>
> /* Set the GPU to the highest power frequency */
> - a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
> + __a6xx_gmu_set_freq(gmu, gmu->nr_gpu_freqs - 1);
>
> out:
> /* Make sure to turn off the boot OOB request on error */
> diff --git
Re: [PATCH 1/5] drm/nouveau: Check backlight IDs are >= 0, not > 0
On Thu, 2018-08-23 at 14:00 +0200, Karol Herbst wrote:
> Patches 1-5 are Reviewed-by: Karol Herbst
>
> I think it might be worth to test those patches on a system without
> any backlight devices just to verify we don't break things, but the
> code looked good already, so maybe we don't really need to test.
Did! The P50 lets you switch between dedicated GPU mode and hybrid GPU mode, and
it switches backlight control between the intel and nvidia GPUs. Seemed to work
just fine for me
>
> On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
> > Remember, ida IDs start at 0, not 1!
> >
> > Signed-off-by: Lyude Paul
> > Cc: sta...@vger.kernel.org
> > Cc: Jeffery Miller
> > Cc: Karol Herbst
> > ---
> > drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > index 408b955e5c39..6dd72bc32897 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> > @@ -116,7 +116,7 @@ nv40_backlight_init(struct drm_connector *connector)
> >_bl_ops, );
> >
> > if (IS_ERR(bd)) {
> > - if (bl_connector.id > 0)
> > + if (bl_connector.id >= 0)
> > ida_simple_remove(_ida, bl_connector.id);
> > return PTR_ERR(bd);
> > }
> > @@ -249,7 +249,7 @@ nv50_backlight_init(struct drm_connector *connector)
> >nv_encoder, ops, );
> >
> > if (IS_ERR(bd)) {
> > - if (bl_connector.id > 0)
> > + if (bl_connector.id >= 0)
> > ida_simple_remove(_ida, bl_connector.id);
> > return PTR_ERR(bd);
> > }
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 10:18:51PM +0200, Daniel Vetter wrote:
> On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > The previous patch added tile_w and tile_h, which represent the
> > horizontal and vertical sizes of a tile.
> >
> > This one uses that to plumb through drm core in order to be able to
> > handle linear tile formats without the need for drivers to roll up
> > their own implementation.
> >
> > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > bytes per pixel and where tiles are laid out in a linear manner.
> >
> > Now what are the restrictions:
> >
> > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > pixels. Due to this the places where the pitch is checked/used need to
> > be updated to take into consideration the tile_w, tile_h and
> > tile_size.
> > tile_size = cpp * tile_w * tile_h
> >
> > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > when computing the start address.
> >
> > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > didn't miss anything nothing should change.
> >
> > Regarding multi-planar linear tile formats, I'm not sure how those
> > should be handle I kind of assumed that tile_h/tile_w will have to be
> > divided by horizontal/subsampling. Anyway, I think it's best to just
> > put an warning in there and handle it when someone tries to add
> > support for them.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c | 8 +++
> > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > drivers/gpu/drm/drm_fourcc.c | 52
> > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > include/drm/drm_fourcc.h | 2 +
> > 6 files changed, 94 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e11e2e..7a3e893a4cd1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > return -ENOSPC;
> > }
> >
> > + /* Make sure source coordinates are a multiple of tile sizes */
> > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > tile restrictions",
> > +plane->base.id, plane->name);
> > + return -EINVAL;
> > + }
> > +
> > if (plane_switching_crtc(state->state, plane, state)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > plane->base.id, plane->name);
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > index 47e0e2f6642d..4d8052adce67 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> > *fb,
> > struct drm_gem_cma_object *obj;
> > dma_addr_t paddr;
> > u8 h_div = 1, v_div = 1;
> > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> >
> > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > if (!obj)
> > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > drm_framebuffer *fb,
> > v_div = fb->format->vsub;
> > }
> >
> > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > + / h_div;
> > + /*
> > +* For tile formats pitches are expected to cover at least
> > +* width * tile_h pixels
> > +*/
> > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
> >
> > return paddr;
> > }
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index f55cd93ba2d0..d6c9c5aa4036 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t
> > format, int plane)
> > return height / info->vsub;
> > }
> > EXPORT_SYMBOL(drm_format_plane_height);
> > +
> > +/**
> > + * drm_format_tile_width - width of a tile for tile formats, should be 1
> > for all
> > + * non-tiled formats.
> > + * @format: pixel format
> > + * @plane: plane index
> > + *
> > + * Returns:
> > + * The width of a tile, depending on the plane index and horizontal
> > sub-sampling
> > + */
> >
Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 10:24 AM, Ville Syrjälä wrote: > On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote: >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> > Hey Noralf, all, >> > I've been digging for a bit on the regression that this patch has >> > tripped on the HiKey board as reported here: >> > https://lkml.org/lkml/2018/8/16/81 >> > >> > The first issue was that the kirin driver was setting >> > mode_config.max_width/height = 2048, which was causing errors as the >> > the requested resolution was 1920x2160 (due to surfaceflinger >> > requesting y*2 for page flipping). >> >> Hey Noralf, >> Sorry, I know your probably sick of me. But I just wanted to circle >> around on this little bit. So part of the issue I found earlier, was >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> Surfaceflinger's request for page flipping. This is what makes the Y >> resolution 2160, which runs afoul of the new max_height check of 2048 >> in the generic code. >> >> I was checking with Xinliang, who know the kirin display hardware, >> about the max_height being set to 2048 to ensure bumping it up wasn't >> a problem, but he said 2048x2048 was unfortunately not arbitrary, and >> that was the hard limit of the display hardware. However, with >> overalloc, the 1920x2160 res fbdev should still be ok, as only >> 1920x1080 is actually displayed at one time. > > I recently tried to clarify that max_width/height are simply the max > framebuffer dimensions supported by the driver. So it's perfectly legal > for a driver to declare max_height as something big that can't be > scanned out in its entirety by a single plane. For i915 I'm currently > working on bumping these limits to 32k-1 regardless of the hardware > scanout limitations. > > So if you're already running with a framebuffer height >2048 and it > works then it would seem to me that you could just bump this limit in > the driver. Ok. I'm fine with this as long as its not going to cause further trouble. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] etnaviv: setup missing dma_mask
As for today etnaviv device doesn't setup dma_mask.
The etnaviv device is a virtual device not represented in DT
so missing dma_mask isn't setup by generic plaform code
(by of_dma_configure function).
Missing dma_mask causes fails in some dma cache ops functions.
For example it causes fails on map_* operations in generic
dma_noncoherent_ops and dma_direct_ops.
We faced with this behaviour after switching ARC to generic
dma_noncoherent cache ops using.
So fix this by setting dma_mask via dma_coerce_mask_and_coherent()
Reviewed-by: Christoph Hellwig
Signed-off-by: Eugeniy Paltsev
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 540b59fb4103..69d80937e021 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -593,7 +593,7 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct component_match *match = NULL;
- dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
+ dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (!dev->platform_data) {
struct device_node *core_node;
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 08:25:46PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > > > wrote:
> > > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > > > >> wrote:
> > > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe
> > > > >> > > wrote:
> > > > >> > > > The previous patch added tile_w and tile_h, which represent the
> > > > >> > > > horizontal and vertical sizes of a tile.
> > > > >> > > >
> > > > >> > > > This one uses that to plumb through drm core in order to be
> > > > >> > > > able to
> > > > >> > > > handle linear tile formats without the need for drivers to
> > > > >> > > > roll up
> > > > >> > > > their own implementation.
> > > > >> > > >
> > > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > > > >> > > > which
> > > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > > > >> > > > average 2
> > > > >> > > > bytes per pixel and where tiles are laid out in a linear
> > > > >> > > > manner.
> > > > >> > > >
> > > > >> > > > Now what are the restrictions:
> > > > >> > > >
> > > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width
> > > > >> > > > in
> > > > >> > > > pixels. Due to this the places where the pitch is checked/used
> > > > >> > > > need to
> > > > >> > > > be updated to take into consideration the tile_w, tile_h and
> > > > >> > > > tile_size.
> > > > >> > > > tile_size = cpp * tile_w * tile_h
> > > > >> > > >
> > > > >> > > > 2. When doing source cropping plane_src_x/y need to be a
> > > > >> > > > multiple of
> > > > >> > > > tile_w/tile_h and we need to take into consideration the
> > > > >> > > > tile_w/tile_h
> > > > >> > > > when computing the start address.
> > > > >> > > >
> > > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so
> > > > >> > > > if I
> > > > >> > > > didn't miss anything nothing should change.
> > > > >> > > >
> > > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how
> > > > >> > > > those
> > > > >> > > > should be handle I kind of assumed that tile_h/tile_w will
> > > > >> > > > have to be
> > > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best
> > > > >> > > > to just
> > > > >> > > > put an warning in there and handle it when someone tries to add
> > > > >> > > > support for them.
> > > > >> > > >
> > > > >> > > > Signed-off-by: Alexandru Gheorghe
> > > > >> > > >
> > > > >> > > > ---
> > > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > >> > > >
> > > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > >> > > > include/drm/drm_fourcc.h | 2 +
> > > > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > > >> > > >
> > > > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > >> > > > @@ -1087,6 +1087,14 @@ static int
> > > > >> > > > drm_atomic_plane_check(struct drm_plane *plane,
> > > > >> > > > return -ENOSPC;
> > > > >> > > > }
> > > > >> > > >
> > > > >> > > > + /* Make sure source coordinates are a multiple of tile
> > > > >> > > > sizes */
> > > > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source
> > > > >> > > > coordinates do not meet tile restrictions",
> > > > >> > > > +plane->base.id, plane->name);
> > > > >> > > > + return -EINVAL;
> > > > >> > > > + }
> > > > >> > >
> > > > >> > > Feels rather wrong to me to put such hardware specific
> > > > >> > > limitations into
> > > > >> > > the core.
> > > > >> >
> > > > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr
> > > > >> > wouldn't
> > > > >> > work.
> > > > >>
> > > > >> If that guy is supposed to give you a tile aligned address then it
> > > > >> could
> > > > >> just do that and leave it up to the driver to deal with the
> > > > >> remainder of
> > > > >> the coordinates?
> > >
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:16 PM Zhenyu Wang wrote: > > yeah, that's the clear way to fix this imo. We only depend on guest > life cycle to access guest memory properly. Here's proposed fix, will > verify and integrate it later. Thanks, this looks sane to me, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Den 23.08.2018 09.37, skrev Daniel Vetter:
On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote:
On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote:
On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
Hey Noralf, all,
I've been digging for a bit on the regression that this patch has
tripped on the HiKey board as reported here:
https://lkml.org/lkml/2018/8/16/81
The first issue was that the kirin driver was setting
mode_config.max_width/height = 2048, which was causing errors as the
the requested resolution was 1920x2160 (due to surfaceflinger
requesting y*2 for page flipping).
Hey Noralf,
Sorry, I know your probably sick of me. But I just wanted to circle
around on this little bit. So part of the issue I found earlier, was
that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support
Surfaceflinger's request for page flipping. This is what makes the Y
resolution 2160, which runs afoul of the new max_height check of 2048
in the generic code.
I was checking with Xinliang, who know the kirin display hardware,
about the max_height being set to 2048 to ensure bumping it up wasn't
a problem, but he said 2048x2048 was unfortunately not arbitrary, and
that was the hard limit of the display hardware. However, with
overalloc, the 1920x2160 res fbdev should still be ok, as only
1920x1080 is actually displayed at one time.
So it seems like we might need to multiply the max_height by the
overalloc factor when we are checking it in
drm_internal_framebuffer_create?
Does that approach sound sane, or would folks prefer something different?
I guess we could simply not check against the height limit when
allocating framebuffers. But we've done that for userspace buffers
since forever (they just allocate 2 buffers for page-flipping), so I
have no idea what would all break if we'd suddenly lift this
restriction. And whether we'd lift it for fbdev only or for everyone
doesn't really make much of a difference, since either this works, or
it doesn't (across all chips).
That feels a bit more risky then what I was thinking. What about
something like (apologies, whitespace corrupted)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index fe7e545..0424a71 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1810,6 +1810,7 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+ struct drm_mode_config *config;
memset(, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1910,6 +1911,11 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
sizes.surface_height *= drm_fbdev_overalloc;
sizes.surface_height /= 100;
+ config = _helper->client.dev->mode_config;
+ config->max_height *= drm_fbdev_overalloc;
+ config->max_height /= 100;
+
+
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
if (ret < 0)
That way it only effects the fbdev + overalloc case?
Still changes it for everyone, not just fbdev, if you enable overalloc.
You'd need to reset.
Another, cleaner way to fix this would be to overallocate the buffer, but
have the drm_framebuffer limited. But that means we need to change the
fbdev scrolling logic. And the entire interface between fbdev helpers and
drivers needs a rework, since atm the driver allocates the drm_framebuffer
for you. That's what userspace can/will do in this case I guess. Has all
the issues of scrolling by moving the drm_fb without hw knowledge.
I guess maybe just dropping the max_height check in fbdev is ok, if we put
a really big comment/FIXME there. Or maybe make it conditional on
fbdev_overalloc being at the default value, that'd probably be better
even.
Maybe something like this could work:
int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
sizes->surface_width, sizes->surface_height,
sizes->surface_bpp);
format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
if (drm_fbdev_overalloc > 100 &&
sizes->surface_height >
fb_helper->client.dev->mode_config.max_height) {
u32 divisor = drm_fbdev_overalloc / 100;
buffer = drm_client_buffer_create(client, sizes->surface_width,
sizes->surface_height, format);
if (IS_ERR(buffer))
return PTR_ERR(buffer);
ret = drm_client_buffer_addfb(buffer, sizes->surface_width,
sizes->surface_height / divisor, format);
if (ret) {
drm_client_buffer_delete(buffer);
return ret;
}
buffer->fb->height =
Re: [Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote: > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > > Hey Noralf, all, > > I've been digging for a bit on the regression that this patch has > > tripped on the HiKey board as reported here: > > https://lkml.org/lkml/2018/8/16/81 > > > > The first issue was that the kirin driver was setting > > mode_config.max_width/height = 2048, which was causing errors as the > > the requested resolution was 1920x2160 (due to surfaceflinger > > requesting y*2 for page flipping). > > Hey Noralf, > Sorry, I know your probably sick of me. But I just wanted to circle > around on this little bit. So part of the issue I found earlier, was > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > Surfaceflinger's request for page flipping. This is what makes the Y > resolution 2160, which runs afoul of the new max_height check of 2048 > in the generic code. > > I was checking with Xinliang, who know the kirin display hardware, > about the max_height being set to 2048 to ensure bumping it up wasn't > a problem, but he said 2048x2048 was unfortunately not arbitrary, and > that was the hard limit of the display hardware. However, with > overalloc, the 1920x2160 res fbdev should still be ok, as only > 1920x1080 is actually displayed at one time. I recently tried to clarify that max_width/height are simply the max framebuffer dimensions supported by the driver. So it's perfectly legal for a driver to declare max_height as something big that can't be scanned out in its entirety by a single plane. For i915 I'm currently working on bumping these limits to 32k-1 regardless of the hardware scanout limitations. So if you're already running with a framebuffer height >2048 and it works then it would seem to me that you could just bump this limit in the driver. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > wrote:
> > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > >> wrote:
> > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > >> > > > The previous patch added tile_w and tile_h, which represent the
> > >> > > > horizontal and vertical sizes of a tile.
> > >> > > >
> > >> > > > This one uses that to plumb through drm core in order to be able to
> > >> > > > handle linear tile formats without the need for drivers to roll up
> > >> > > > their own implementation.
> > >> > > >
> > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > >> > > > which
> > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > >> > > > average 2
> > >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > >> > > >
> > >> > > > Now what are the restrictions:
> > >> > > >
> > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > >> > > > pixels. Due to this the places where the pitch is checked/used
> > >> > > > need to
> > >> > > > be updated to take into consideration the tile_w, tile_h and
> > >> > > > tile_size.
> > >> > > > tile_size = cpp * tile_w * tile_h
> > >> > > >
> > >> > > > 2. When doing source cropping plane_src_x/y need to be a multiple
> > >> > > > of
> > >> > > > tile_w/tile_h and we need to take into consideration the
> > >> > > > tile_w/tile_h
> > >> > > > when computing the start address.
> > >> > > >
> > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > >> > > > didn't miss anything nothing should change.
> > >> > > >
> > >> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > >> > > > should be handle I kind of assumed that tile_h/tile_w will have to
> > >> > > > be
> > >> > > > divided by horizontal/subsampling. Anyway, I think it's best to
> > >> > > > just
> > >> > > > put an warning in there and handle it when someone tries to add
> > >> > > > support for them.
> > >> > > >
> > >> > > > Signed-off-by: Alexandru Gheorghe
> > >> > > >
> > >> > > > ---
> > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > >> > > >
> > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > >> > > > include/drm/drm_fourcc.h | 2 +
> > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > >> > > >
> > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > >> > > > drm_plane *plane,
> > >> > > > return -ENOSPC;
> > >> > > > }
> > >> > > >
> > >> > > > + /* Make sure source coordinates are a multiple of tile
> > >> > > > sizes */
> > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates
> > >> > > > do not meet tile restrictions",
> > >> > > > +plane->base.id, plane->name);
> > >> > > > + return -EINVAL;
> > >> > > > + }
> > >> > >
> > >> > > Feels rather wrong to me to put such hardware specific limitations
> > >> > > into
> > >> > > the core.
> > >> >
> > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > >> > work.
> > >>
> > >> If that guy is supposed to give you a tile aligned address then it could
> > >> just do that and leave it up to the driver to deal with the remainder of
> > >> the coordinates?
> > >>
> > >> >
> > >> > An alternative, would be to include it in the driver and put an WARN
> > >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > >> > src_x/src_y tile multiples.
> > >> >
> > >> > What do you think about that ?
> > >> >
> > >> > >
> > >> > > > +
> > >> > > > if (plane_switching_crtc(state->state, plane, state)) {
> > >> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > >> > > > directly\n",
> > >> > > > plane->base.id, plane->name);
> > >> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > >> > >
Visibility of issues fd.o admins are faced with (Was: Re: RFC: Migration to Gitlab)
[Changing subject/recipients, to avoid hijacking the thread] Hi Dan, On Wed, 22 Aug 2018 at 17:29, Daniel Stone wrote: > > Hi, > > On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote: > > On 22 August 2018 at 12:44, Daniel Vetter wrote: > > > I think it's time to brainstorm a bit about the gitlab migration. Basic > > > reasons: > > > > > > - fd.o admins want to deprecate shell accounts and hand-rolled > > > infrastructure, because it's a pain to keep secure > > > > > > - gitlab will allow us to add committers on our own, greatly > > > simplifying that process (and offloading that task from fd.o admins). > > > > Random thought - I really wish the admins spoke early and louder about > > issues. > > From infra to manpower and adhoc tool maintenance. > > I thought I mostly had it covered, but fair enough. What knowledge are > you missing and how should it best be delivered? > > One first-order issue is that as documented at > https://www.freedesktop.org/wiki/AccountRequests/ creating accounts > requires manual admin intervention. You can also search the > 'freedesktop.org' product on Bugzilla to see the amount of time we > spend shuffling around GPG & SSH keys, which is about the worst > possible use of my time. Many other people have had access to drive > the ancient shell-script frontend to LDAP before, but for some reason > they mostly aren't very enthusiastic about doing it all the time. > > In the mesa-dev@ thread about Mesa's migration, which is linked from > my blog post, I went into quite a lot of detail about why Jenkins was > not suitable to roll out across fd.o globally. That knowledge was > gained from trial & error, which was a lot of time burnt. The end > result is that we don't have any CI, except if people hang > Travis/AppVeyor off GitHub mirrors. > > You've personally seen what's involved in setting up Git repository > hooks so we can build docs. We can't give access to let people work on > those, without giving them direct access to the literal Git repository > itself on disk. The hooks mostly involve bespoke sets of rsync jobs > and hand-managed SSH credentials and external services to build docs > and so on and so forth. None of this is accessible to a newcomer who > wants to make a non-code contribution: you have to find someone with > access to the repo to go bash some shell scripts directly and hope you > didn't screw it up. None of this is auditable, so if the repo > mysteriously gets wiped, then hopefully there are some backups > somewhere. But there definitely aren't any logs. Luckily we prevent > most people from having access to most repositories via a mandatory > 'shell' which only allows people to push Git; this was written by hand > by us 12 years ago. > > What else? Our fork of Patchwork was until recently based on an > ancient fork of Django, in a bespoke unreproducible production > environment. Bugzilla is patched for spam and templates (making > upgrades complex), yet we still have a surprising amount of spam pass > through. There's no way to delete spam, but you have to manually move > every bug to the 'spam' group, then go through and delete the user > which involves copying & pasting the email and a few clicks per user. > Mailman is patched to support Recaptcha, bringing more upgrade fun. > ikiwiki breaks all the time because it's designed to have the > public-access web server on the same host as the writeable Git > repositories. > > Our servers are several years old and approaching life expiry, and we > have no more spare disk. You can see in #freedesktop IRC the constant > network connectivity issues people have to PSU almost every day. Our > attempts to root-cause and solve those have got nowhere. > > I could go on, but the 'moved elsewhere' list in > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/2 > indicates that we do have problems to solve, and that changing > peoples' SSH keys for them isn't the best way for us to be spending > the extremely limited time that we do have. > Starting with the most important - regardless of what may come as nitpicking, I do admire the time, patience and effort that you've been putting in fd.o. Based on your blog-post, there are many issues beyond users usability (think people using cgit/annongit, pw failing to parse email, etc). And yes, I've read it a couple of times as it came out. You mentioned many of those, so let me respin that a bit: - old hacky/adhoc scripts - throw those over a git repo - annoying and/or admin requiring workflow - throw some suggestions about tools in ^^ - ageing servers - increasing maintenance People working on graphics [more or less familiar with some issues] may not be the best admin/tools engineers out there. Hence publicity, be that via blog post/XDC talk/other, is very important IMHO. Don't recall a blog or XDC (lighting) talk over the last 5 years - and seemingly during that time, more issues have been pilling up. I believe that people would have responded to such
Re: [PATCH 0/2] Add R-Car V3H (R8A77980) support to the R-Car LVDS driver
On 06/05/2018 11:25 PM, Sergei Shtylyov wrote: > Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git' > repo. > The purpose of these patches is to add the R-Car V3H (R8A77980) support to the > R-Car LVDS driver. > > [1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings > [2/2] drm: rcar-du: lvds: add R8A77980 support Laurent, I'm not seeing these patches merged... they are 2.5 months old without a comment! :-( MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Thu, Aug 23, 2018 at 06:19:31PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Thu, Aug 23, 2018 at 05:30:36PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 09:48:29PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
> > > wrote:
> > > > On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> > > >> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe
> > > >> wrote:
> > > >> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > >> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > >> > > > The previous patch added tile_w and tile_h, which represent the
> > > >> > > > horizontal and vertical sizes of a tile.
> > > >> > > >
> > > >> > > > This one uses that to plumb through drm core in order to be able
> > > >> > > > to
> > > >> > > > handle linear tile formats without the need for drivers to roll
> > > >> > > > up
> > > >> > > > their own implementation.
> > > >> > > >
> > > >> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind
> > > >> > > > which
> > > >> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in
> > > >> > > > average 2
> > > >> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > >> > > >
> > > >> > > > Now what are the restrictions:
> > > >> > > >
> > > >> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > >> > > > pixels. Due to this the places where the pitch is checked/used
> > > >> > > > need to
> > > >> > > > be updated to take into consideration the tile_w, tile_h and
> > > >> > > > tile_size.
> > > >> > > > tile_size = cpp * tile_w * tile_h
> > > >> > > >
> > > >> > > > 2. When doing source cropping plane_src_x/y need to be a
> > > >> > > > multiple of
> > > >> > > > tile_w/tile_h and we need to take into consideration the
> > > >> > > > tile_w/tile_h
> > > >> > > > when computing the start address.
> > > >> > > >
> > > >> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if
> > > >> > > > I
> > > >> > > > didn't miss anything nothing should change.
> > > >> > > >
> > > >> > > > Regarding multi-planar linear tile formats, I'm not sure how
> > > >> > > > those
> > > >> > > > should be handle I kind of assumed that tile_h/tile_w will have
> > > >> > > > to be
> > > >> > > > divided by horizontal/subsampling. Anyway, I think it's best to
> > > >> > > > just
> > > >> > > > put an warning in there and handle it when someone tries to add
> > > >> > > > support for them.
> > > >> > > >
> > > >> > > > Signed-off-by: Alexandru Gheorghe
> > > >> > > >
> > > >> > > > ---
> > > >> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > >> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > >> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > >> > > >
> > > >> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > >> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > >> > > > include/drm/drm_fourcc.h | 2 +
> > > >> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > >> > > >
> > > >> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > >> > > > b/drivers/gpu/drm/drm_atomic.c
> > > >> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > >> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > >> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > >> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > >> > > > drm_plane *plane,
> > > >> > > > return -ENOSPC;
> > > >> > > > }
> > > >> > > >
> > > >> > > > + /* Make sure source coordinates are a multiple of tile
> > > >> > > > sizes */
> > > >> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > >> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > >> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source
> > > >> > > > coordinates do not meet tile restrictions",
> > > >> > > > +plane->base.id, plane->name);
> > > >> > > > + return -EINVAL;
> > > >> > > > + }
> > > >> > >
> > > >> > > Feels rather wrong to me to put such hardware specific limitations
> > > >> > > into
> > > >> > > the core.
> > > >> >
> > > >> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > > >> > work.
> > > >>
> > > >> If that guy is supposed to give you a tile aligned address then it
> > > >> could
> > > >> just do that and leave it up to the driver to deal with the remainder
> > > >> of
> > > >> the coordinates?
> > > >>
> > > >> >
> > > >> > An alternative, would be to include it in the driver and put an WARN
> > > >> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > > >> > src_x/src_y tile multiples.
> > > >> >
> > > >> > What do you think about that ?
> > > >> >
> > > >> > >
> > > >> > > > +
> > > >> > > >
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 12:46 AM, Laurent Pinchart wrote: > Hi John, > > On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> > Hey Noralf, all, >> > >> > I've been digging for a bit on the regression that this patch has >> > >> > tripped on the HiKey board as reported here: >> > https://lkml.org/lkml/2018/8/16/81 >> > >> > The first issue was that the kirin driver was setting >> > mode_config.max_width/height = 2048, which was causing errors as the >> > the requested resolution was 1920x2160 (due to surfaceflinger >> > requesting y*2 for page flipping). >> >> Hey Noralf, >> Sorry, I know your probably sick of me. But I just wanted to circle >> around on this little bit. So part of the issue I found earlier, was >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> Surfaceflinger's request for page flipping. > > Possibly slightly out of topic, but we're in 2018, is there any plan to make > SurfaceFlinger move away from FBDEV ? Yes. That is actually work-in-progress for both HiKey and HiKey960, switching to use the drm_hwcomposer once we can get upstream project into a sane state. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
On 2018-08-17 10:11 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
>
> Signed-off-by: Hans Verkuil
> Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 34f34823bab5..77898c95bef6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct
> amdgpu_dm_connector *aconnector)
> aconnector->dc_sink = sink;
> if (sink->dc_edid.length == 0) {
> aconnector->edid = NULL;
> + drm_dp_cec_unset_edid(>dm_dp_aux.aux);
> } else {
> aconnector->edid =
> (struct edid *) sink->dc_edid.raw_edid;
> @@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct
> amdgpu_dm_connector *aconnector)
>
> drm_connector_update_edid_property(connector,
> aconnector->edid);
> + drm_dp_cec_set_edid(>dm_dp_aux.aux,
> + aconnector->edid);
> }
> amdgpu_dm_add_sink_to_freesync_module(connector,
> aconnector->edid);
>
> } else {
> + drm_dp_cec_unset_edid(>dm_dp_aux.aux);
> amdgpu_dm_remove_sink_from_freesync_module(connector);
> drm_connector_update_edid_property(connector, NULL);
> aconnector->num_modes = 0;
> @@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
> drm_kms_helper_hotplug_event(dev);
> }
> }
> +
> if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
> - (dc_link->type == dc_connection_mst_branch))
> + (dc_link->type == dc_connection_mst_branch)) {
> dm_handle_hpd_rx_irq(aconnector);
> + }
These lines don't really add anything functional.
Either way, this patch is
Reviewed-by: Harry Wentland
Harry
>
> - if (dc_link->type != dc_connection_mst_branch)
> + if (dc_link->type != dc_connection_mst_branch) {
> + drm_dp_cec_irq(>dm_dp_aux.aux);
> mutex_unlock(>hpd_lock);
> + }
> }
>
> static void register_hpd_handlers(struct amdgpu_device *adev)
> @@ -2732,6 +2740,7 @@ static void amdgpu_dm_connector_destroy(struct
> drm_connector *connector)
> dm->backlight_dev = NULL;
> }
> #endif
> + drm_dp_cec_unregister_connector(>dm_dp_aux.aux);
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 9a300732ba37..18a3a6e5ffa0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -496,6 +496,8 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
> aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
>
> drm_dp_aux_register(>dm_dp_aux.aux);
> + drm_dp_cec_register_connector(>dm_dp_aux.aux,
> + aconnector->base.name, dm->adev->dev);
> aconnector->mst_mgr.cbs = _mst_cbs;
> drm_dp_mst_topology_mgr_init(
> >mst_mgr,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #17 from madc...@atlas.cz --- I just ran a few tests with git/svn versions of LLVM 8.0 and mesa 18.3 and the problem is still there. I attached a dmesg log of the crash in Unigine Superposition. Just FTR the crash with LLVM 8.0/mesa 18.3 happens only on the Extreme settings, High settings survive without a hitch. -- 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 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #18 from madc...@atlas.cz --- Created attachment 141261 --> https://bugs.freedesktop.org/attachment.cgi?id=141261=edit dmesg log of the crash in Unigine Superposition -- 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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 6:49 PM, Noralf Trønnes wrote:
>
> Den 23.08.2018 09.37, skrev Daniel Vetter:
>>
>> On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote:
>>>
>>> On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote:
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz
wrote:
>
> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz
> wrote:
>>
>> Hey Noralf, all,
>>I've been digging for a bit on the regression that this patch has
>> tripped on the HiKey board as reported here:
>> https://lkml.org/lkml/2018/8/16/81
>>
>> The first issue was that the kirin driver was setting
>> mode_config.max_width/height = 2048, which was causing errors as the
>> the requested resolution was 1920x2160 (due to surfaceflinger
>> requesting y*2 for page flipping).
>
> Hey Noralf,
>Sorry, I know your probably sick of me. But I just wanted to circle
> around on this little bit. So part of the issue I found earlier, was
> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support
> Surfaceflinger's request for page flipping. This is what makes the Y
> resolution 2160, which runs afoul of the new max_height check of 2048
> in the generic code.
>
> I was checking with Xinliang, who know the kirin display hardware,
> about the max_height being set to 2048 to ensure bumping it up wasn't
> a problem, but he said 2048x2048 was unfortunately not arbitrary, and
> that was the hard limit of the display hardware. However, with
> overalloc, the 1920x2160 res fbdev should still be ok, as only
> 1920x1080 is actually displayed at one time.
>
> So it seems like we might need to multiply the max_height by the
> overalloc factor when we are checking it in
> drm_internal_framebuffer_create?
>
> Does that approach sound sane, or would folks prefer something
> different?
I guess we could simply not check against the height limit when
allocating framebuffers. But we've done that for userspace buffers
since forever (they just allocate 2 buffers for page-flipping), so I
have no idea what would all break if we'd suddenly lift this
restriction. And whether we'd lift it for fbdev only or for everyone
doesn't really make much of a difference, since either this works, or
it doesn't (across all chips).
>>>
>>> That feels a bit more risky then what I was thinking. What about
>>> something like (apologies, whitespace corrupted)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index fe7e545..0424a71 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -1810,6 +1810,7 @@ static int drm_fb_helper_single_fb_probe(struct
>>> drm_fb_helper *fb_helper,
>>> int i;
>>> struct drm_fb_helper_surface_size sizes;
>>> int gamma_size = 0;
>>> + struct drm_mode_config *config;
>>>
>>> memset(, 0, sizeof(struct drm_fb_helper_surface_size));
>>> sizes.surface_depth = 24;
>>> @@ -1910,6 +1911,11 @@ static int drm_fb_helper_single_fb_probe(struct
>>> drm_fb_helper *fb_helper,
>>> sizes.surface_height *= drm_fbdev_overalloc;
>>> sizes.surface_height /= 100;
>>>
>>> + config = _helper->client.dev->mode_config;
>>> + config->max_height *= drm_fbdev_overalloc;
>>> + config->max_height /= 100;
>>> +
>>> +
>>> /* push down into drivers */
>>> ret = (*fb_helper->funcs->fb_probe)(fb_helper, );
>>> if (ret < 0)
>>>
>>>
>>> That way it only effects the fbdev + overalloc case?
>>
>> Still changes it for everyone, not just fbdev, if you enable overalloc.
>> You'd need to reset.
>>
>> Another, cleaner way to fix this would be to overallocate the buffer, but
>> have the drm_framebuffer limited. But that means we need to change the
>> fbdev scrolling logic. And the entire interface between fbdev helpers and
>> drivers needs a rework, since atm the driver allocates the drm_framebuffer
>> for you. That's what userspace can/will do in this case I guess. Has all
>> the issues of scrolling by moving the drm_fb without hw knowledge.
>>
>> I guess maybe just dropping the max_height check in fbdev is ok, if we put
>> a really big comment/FIXME there. Or maybe make it conditional on
>> fbdev_overalloc being at the default value, that'd probably be better
>> even.
>
>
> Maybe something like this could work:
>
> int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper,
> struct drm_fb_helper_surface_size *sizes)
> {
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
> sizes->surface_width, sizes->surface_height,
> sizes->surface_bpp);
>
> format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> sizes->surface_depth);
>
> if (drm_fbdev_overalloc > 100 &&
> sizes->surface_height >
>
[PATCH V2] drm/vkms: Add support for vkms work without vblank
Currently, vkms needs VBlank to work well. This patch adds another
operation model that make vkms works without VBlank support. In this
scenario, vblank signaling is faked by calling drm_send_vblank_event()
in vkms_crtc_atomic_flush(); this approach works due to the
drm_vblank_get() == 0 verification.
Changes since V1:
Daniel Vetter:
- Change module parameter name from disablevblank to virtual_hw
- Improve parameter description
- Improve commit message
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
drivers/gpu/drm/vkms/vkms_drv.c | 13 +++--
drivers/gpu/drm/vkms/vkms_drv.h | 1 +
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index bfe6e0312cc4..001fa5c1d326 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -145,12 +145,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+
+ if (vkms_out->disable_vblank)
+ return;
+
drm_crtc_vblank_on(crtc);
}
static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
+
+ if (vkms_out->disable_vblank)
+ return;
+
drm_crtc_vblank_off(crtc);
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 5d78bd97e69c..0b6569ee9dcc 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -21,6 +21,11 @@
static struct vkms_device *vkms_device;
+static bool virtual_hw;
+module_param_named(virtual_hw, virtual_hw, bool, 0444);
+MODULE_PARM_DESC(virtual_hw,
+"Enable virtual hardware mode (disables vblanks and
immediately completes flips)");
+
static const struct file_operations vkms_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -105,9 +110,13 @@ static int __init vkms_init(void)
goto out_fini;
}
- vkms_device->drm.irq_enabled = true;
+ vkms_device->output.disable_vblank = virtual_hw;
+ vkms_device->drm.irq_enabled = !virtual_hw;
+
+ if (virtual_hw)
+ DRM_INFO("Virtual Hardware mode enabled");
- ret = drm_vblank_init(_device->drm, 1);
+ ret = (virtual_hw) ? 0 : drm_vblank_init(_device->drm, 1);
if (ret) {
DRM_ERROR("Failed to vblank\n");
goto out_fini;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index f156c930366a..9ee862e6f7e5 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -52,6 +52,7 @@ struct vkms_output {
struct drm_encoder encoder;
struct drm_connector connector;
struct hrtimer vblank_hrtimer;
+ bool disable_vblank;
ktime_t period_ns;
struct drm_pending_vblank_event *event;
bool crc_enabled;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote: > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: >> Hi John, >> >> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: >> > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> > > Hey Noralf, all, >> > > >> > > I've been digging for a bit on the regression that this patch has >> > > >> > > tripped on the HiKey board as reported here: >> > > https://lkml.org/lkml/2018/8/16/81 >> > > >> > > The first issue was that the kirin driver was setting >> > > mode_config.max_width/height = 2048, which was causing errors as the >> > > the requested resolution was 1920x2160 (due to surfaceflinger >> > > requesting y*2 for page flipping). >> > >> > Hey Noralf, >> > Sorry, I know your probably sick of me. But I just wanted to circle >> > around on this little bit. So part of the issue I found earlier, was >> > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> > Surfaceflinger's request for page flipping. >> >> Possibly slightly out of topic, but we're in 2018, is there any plan to make >> SurfaceFlinger move away from FBDEV ? > > Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or > is this just an artifact of the mali blob hwcomposer backend? Mostly its due to the simple fbdev being a legacy solution on android that works out of the box. I do suspect the android devs hope to retire it, which is why I'm working on getting things going w/ the drm_hwcomposer right now so we can get away from the fbdev. But in the meantime, keeping the fbdev method running is important so we have a functioning device for testing AOSP w/ mainline. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #29 from Andrey Grodzovsky --- (In reply to Jan Jurzitza from comment #28) > (In reply to Andrey Grodzovsky from comment #25) > > Still same issue happening here on both projects built from git. One issue > here which doesn't seem completely related: > Aug 23 20:41:20 archlinux kernel: [ cut here ] > Aug 23 20:41:20 archlinux kernel: CPU update of VM recommended only for > large BAR system > Aug 23 20:41:20 archlinux kernel: WARNING: CPU: 5 PID: 1092 at > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2606 amdgpu_vm_init+0x477/0x490 > [amdgpu] > Aug 23 20:41:20 archlinux kernel: Modules linked in: bnep nct6775 hwmon_vid > joydev btusb btrtl btbcm btintel bluetooth snd_usb_audio snd_usbmidi_lib > snd_rawmidi input_leds snd_seq_device ecdh_generic mousedev nls_iso8859_1 > nls_cp437 vfat fat btrfs zstd_compress libcrc32c zstd_decompress xxhash xor > arc4 amdkfd amd_iommu_v2 amdgpu iwlmvm mac80211 edac_mce_amd led_class > kvm_amd iwlwifi snd_hda_codec_realtek chash gpu_sched kvm snd_hda_codec_hdmi > snd_hda_codec_generic ttm snd_hda_intel drm_kms_helper irqbypass > snd_hda_codec cfg80211 morus1280_avx2 drm morus1280_sse2 morus1280_glue > morus640_sse2 morus640_glue snd_hda_core aegis256_aesni aegis128l_aesni > aegis128_aesni igb snd_hwdep crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel snd_pcm pcbc snd_timer agpgart evdev ccp sp5100_tco > aesni_intel snd syscopyarea i2c_algo_bit sysfillrect > Aug 23 20:41:20 archlinux kernel: aes_x86_64 wmi_bmof mac_hid crypto_simd > sysimgblt raid6_pq cryptd glue_helper fb_sys_fops soundcore k10temp > i2c_piix4 dca rfkill rng_core wmi button acpi_cpufreq sch_fq_codel > vboxnetflt(O) vboxnetadp(O) pci_stub vboxpci(O) vboxdrv(O) sg crypto_user > ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod > cdrom sd_mod uas usb_storage hid_uclogic hid_generic usbhid hid ahci libahci > xhci_pci libata crc32c_intel xhci_hcd usbcore scsi_mod usb_common > Aug 23 20:41:20 archlinux kernel: CPU: 5 PID: 1092 Comm: Xorg.wrap Tainted: > G O 4.18.0-rc1-5024f8dfe478 #1 > Aug 23 20:41:20 archlinux kernel: Hardware name: To Be Filled By O.E.M. To > Be Filled By O.E.M./X370 Gaming-ITX/ac, BIOS P3.40 11/07/2017 > Aug 23 20:41:20 archlinux kernel: RIP: 0010:amdgpu_vm_init+0x477/0x490 > [amdgpu] > Aug 23 20:41:20 archlinux kernel: Code: b8 08 d8 ff ff e8 79 89 7c e8 e9 ee > fe ff ff 41 89 ef e9 e6 fe ff ff 48 c7 c7 08 65 f0 c0 c6 05 41 af 2b 00 01 > e8 a3 8f 37 e8 <0f> 0b 0f b6 8b 60 01 00 00 e9 b4 fc ff ff e8 26 8d 37 e8 66 > 0f 1f > Aug 23 20:41:20 archlinux kernel: RSP: 0018:acc2c8df7b60 EFLAGS: 00010286 > Aug 23 20:41:20 archlinux kernel: RAX: RBX: > 9b10f7bf9000 RCX: 0006 > Aug 23 20:41:20 archlinux kernel: RDX: 0007 RSI: > 0002 RDI: 9b10fe7564d0 > Aug 23 20:41:20 archlinux kernel: RBP: 9b10f564 R08: > 001856da5330 R09: 0036 > Aug 23 20:41:20 archlinux kernel: R10: 0424 R11: > 0006ad48 R12: 9b10f7bf90b8 > Aug 23 20:41:20 archlinux kernel: R13: 000a R14: > R15: > Aug 23 20:41:20 archlinux kernel: FS: 7fcf6cc95500() > GS:9b10fe74() knlGS: > Aug 23 20:41:20 archlinux kernel: CS: 0010 DS: ES: CR0: > 80050033 > Aug 23 20:41:20 archlinux kernel: CR2: 7fcf6cb1d960 CR3: > 0007e119 CR4: 003406e0 > Aug 23 20:41:20 archlinux kernel: Call Trace: > Aug 23 20:41:20 archlinux kernel: ? ida_simple_get+0x91/0xf0 > Aug 23 20:41:20 archlinux kernel: amdgpu_driver_open_kms+0x83/0x1d0 [amdgpu] > Aug 23 20:41:20 archlinux kernel: drm_open+0x20b/0x440 [drm] > Aug 23 20:41:20 archlinux kernel: drm_stub_open+0xaf/0xf0 [drm] > Aug 23 20:41:20 archlinux kernel: chrdev_open+0xa3/0x1b0 > Aug 23 20:41:20 archlinux kernel: ? cdev_put.part.3+0x20/0x20 > Aug 23 20:41:20 archlinux kernel: do_dentry_open+0x1ab/0x2d0 > Aug 23 20:41:20 archlinux kernel: path_openat+0x31b/0x1440 > Aug 23 20:41:20 archlinux kernel: ? alloc_set_pte+0x1fd/0x4e0 > Aug 23 20:41:20 archlinux kernel: do_filp_open+0x93/0x100 > Aug 23 20:41:20 archlinux kernel: ? __check_object_size+0x9c/0x171 > Aug 23 20:41:20 archlinux kernel: do_sys_open+0x186/0x210 > Aug 23 20:41:20 archlinux kernel: do_syscall_64+0x4e/0x100 > Aug 23 20:41:20 archlinux kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Aug 23 20:41:20 archlinux kernel: RIP: 0033:0x7fcf6cbbc452 > Aug 23 20:41:20 archlinux kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 4c > 48 8d 05 f5 70 0d 00 8b 00 85 c0 75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c > ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 > 0c 25 > Aug 23 20:41:20 archlinux kernel: RSP: 002b:7ffe9a15b0a0 EFLAGS: > 0246 ORIG_RAX: 0101 > Aug 23 20:41:20 archlinux kernel: RAX: ffda RBX: > RCX:
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #28 from Jan Jurzitza --- (In reply to Andrey Grodzovsky from comment #25) Still same issue happening here on both projects built from git. One issue here which doesn't seem completely related: Aug 23 20:41:20 archlinux kernel: [ cut here ] Aug 23 20:41:20 archlinux kernel: CPU update of VM recommended only for large BAR system Aug 23 20:41:20 archlinux kernel: WARNING: CPU: 5 PID: 1092 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2606 amdgpu_vm_init+0x477/0x490 [amdgpu] Aug 23 20:41:20 archlinux kernel: Modules linked in: bnep nct6775 hwmon_vid joydev btusb btrtl btbcm btintel bluetooth snd_usb_audio snd_usbmidi_lib snd_rawmidi input_leds snd_seq_device ecdh_generic mousedev nls_iso8859_1 nls_cp437 vfat fat btrfs zstd_compress libcrc32c zstd_decompress xxhash xor arc4 amdkfd amd_iommu_v2 amdgpu iwlmvm mac80211 edac_mce_amd led_class kvm_amd iwlwifi snd_hda_codec_realtek chash gpu_sched kvm snd_hda_codec_hdmi snd_hda_codec_generic ttm snd_hda_intel drm_kms_helper irqbypass snd_hda_codec cfg80211 morus1280_avx2 drm morus1280_sse2 morus1280_glue morus640_sse2 morus640_glue snd_hda_core aegis256_aesni aegis128l_aesni aegis128_aesni igb snd_hwdep crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm pcbc snd_timer agpgart evdev ccp sp5100_tco aesni_intel snd syscopyarea i2c_algo_bit sysfillrect Aug 23 20:41:20 archlinux kernel: aes_x86_64 wmi_bmof mac_hid crypto_simd sysimgblt raid6_pq cryptd glue_helper fb_sys_fops soundcore k10temp i2c_piix4 dca rfkill rng_core wmi button acpi_cpufreq sch_fq_codel vboxnetflt(O) vboxnetadp(O) pci_stub vboxpci(O) vboxdrv(O) sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod cdrom sd_mod uas usb_storage hid_uclogic hid_generic usbhid hid ahci libahci xhci_pci libata crc32c_intel xhci_hcd usbcore scsi_mod usb_common Aug 23 20:41:20 archlinux kernel: CPU: 5 PID: 1092 Comm: Xorg.wrap Tainted: G O 4.18.0-rc1-5024f8dfe478 #1 Aug 23 20:41:20 archlinux kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X370 Gaming-ITX/ac, BIOS P3.40 11/07/2017 Aug 23 20:41:20 archlinux kernel: RIP: 0010:amdgpu_vm_init+0x477/0x490 [amdgpu] Aug 23 20:41:20 archlinux kernel: Code: b8 08 d8 ff ff e8 79 89 7c e8 e9 ee fe ff ff 41 89 ef e9 e6 fe ff ff 48 c7 c7 08 65 f0 c0 c6 05 41 af 2b 00 01 e8 a3 8f 37 e8 <0f> 0b 0f b6 8b 60 01 00 00 e9 b4 fc ff ff e8 26 8d 37 e8 66 0f 1f Aug 23 20:41:20 archlinux kernel: RSP: 0018:acc2c8df7b60 EFLAGS: 00010286 Aug 23 20:41:20 archlinux kernel: RAX: RBX: 9b10f7bf9000 RCX: 0006 Aug 23 20:41:20 archlinux kernel: RDX: 0007 RSI: 0002 RDI: 9b10fe7564d0 Aug 23 20:41:20 archlinux kernel: RBP: 9b10f564 R08: 001856da5330 R09: 0036 Aug 23 20:41:20 archlinux kernel: R10: 0424 R11: 0006ad48 R12: 9b10f7bf90b8 Aug 23 20:41:20 archlinux kernel: R13: 000a R14: R15: Aug 23 20:41:20 archlinux kernel: FS: 7fcf6cc95500() GS:9b10fe74() knlGS: Aug 23 20:41:20 archlinux kernel: CS: 0010 DS: ES: CR0: 80050033 Aug 23 20:41:20 archlinux kernel: CR2: 7fcf6cb1d960 CR3: 0007e119 CR4: 003406e0 Aug 23 20:41:20 archlinux kernel: Call Trace: Aug 23 20:41:20 archlinux kernel: ? ida_simple_get+0x91/0xf0 Aug 23 20:41:20 archlinux kernel: amdgpu_driver_open_kms+0x83/0x1d0 [amdgpu] Aug 23 20:41:20 archlinux kernel: drm_open+0x20b/0x440 [drm] Aug 23 20:41:20 archlinux kernel: drm_stub_open+0xaf/0xf0 [drm] Aug 23 20:41:20 archlinux kernel: chrdev_open+0xa3/0x1b0 Aug 23 20:41:20 archlinux kernel: ? cdev_put.part.3+0x20/0x20 Aug 23 20:41:20 archlinux kernel: do_dentry_open+0x1ab/0x2d0 Aug 23 20:41:20 archlinux kernel: path_openat+0x31b/0x1440 Aug 23 20:41:20 archlinux kernel: ? alloc_set_pte+0x1fd/0x4e0 Aug 23 20:41:20 archlinux kernel: do_filp_open+0x93/0x100 Aug 23 20:41:20 archlinux kernel: ? __check_object_size+0x9c/0x171 Aug 23 20:41:20 archlinux kernel: do_sys_open+0x186/0x210 Aug 23 20:41:20 archlinux kernel: do_syscall_64+0x4e/0x100 Aug 23 20:41:20 archlinux kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Aug 23 20:41:20 archlinux kernel: RIP: 0033:0x7fcf6cbbc452 Aug 23 20:41:20 archlinux kernel: Code: 25 00 00 41 00 3d 00 00 41 00 74 4c 48 8d 05 f5 70 0d 00 8b 00 85 c0 75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 0c 25 Aug 23 20:41:20 archlinux kernel: RSP: 002b:7ffe9a15b0a0 EFLAGS: 0246 ORIG_RAX: 0101 Aug 23 20:41:20 archlinux kernel: RAX: ffda RBX: RCX: 7fcf6cbbc452 Aug 23 20:41:20 archlinux kernel: RDX: 0002 RSI: 7ffe9a15b180 RDI: ff9c Aug 23 20:41:20 archlinux kernel: RBP: 7ffe9a15b130 R08: R09: Aug 23
[Bug 104284] [IGT] some gem_exec_fence Failed assertion: __gem_execbuf(fd, execbuf) == 0
https://bugs.freedesktop.org/show_bug.cgi?id=104284 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #18 from Lakshmi --- No failures noticed for gem_exec_fence tests. Closing the defect as fixed. -- 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 v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
>
> Cc: Gaurav K Singh
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
Looks like this version basically removes the bitfield definitions and adds
those
in the comments, compared to the review in May.
Reviewed-by: Harry Wentland
Harry
> ---
> include/drm/drm_dsc.h | 365
> ++
> 1 file changed, 365 insertions(+)
> create mode 100644 include/drm/drm_dsc.h
>
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index 000..678e8e6
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Manasi Navare
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include
> +
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES 15
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display
> + * stream compression encoders must communicate to decoders.
> + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The fields
> in
> + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
> + /**
> + * @dsc_version:
> + * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> + * PPS0[7:4] - dsc_version_major: Contains major version of DSC
> + */
> + u8 dsc_version;
> + /**
> + * @pps_identifier:
> + * PPS1[7:0] - Application specific identifier that can be
> + * used to differentiate between different PPS tables.
> + */
> + u8 pps_identifier;
> + /**
> + * @pps_reserved:
> + * PPS2[7:0]- RESERVED Byte
> + */
> + u8 pps_reserved;
> + /**
> + * @pps_3:
> + * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> + * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> + * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> + * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> + * PPS3[7:4] - bits_per_component: Bits per component for the original
> + * pixels of the encoded picture.
> + * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> + * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> + * allowed only when dsc_minor_version = 0x2)
> + */
> + u8 pps_3;
> + /**
> + * @pps_4:
> + * PPS4[1:0] -These are the most significant 2 bits of
> + * compressed BPP bits_per_pixel[9:0] syntax element.
> + * PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> + * PPS4[3] - simple_422: Indicates if decoder drops samples to
> + * reconstruct the 4:2:2 picture.
> + * PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
> + * active.
> + * PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
> + * groups in picture
> + * PPS4[7:6] - Reseved bits
> + */
> + u8 pps_4;
> + /**
> + * @bits_per_pixel_low:
> + * PPS5[7:0] - This indicates the lower significant 8 bits of
> + * the compressed BPP bits_per_pixel[9:0] element.
> + */
> + u8
Re: [PATCH v2 10/23] drm/dsc: Add helpers for DSC picture parameter set infoframes
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> According to Display Stream compression spec 1.2, the picture
> parameter set metadata is sent from source to sink device
> using the DP Secondary data packet. An infoframe is formed
> for the PPS SDP header and PPS SDP payload bytes.
> This patch adds helpers to fill the PPS SDP header
> and PPS SDP payload according to the DSC 1.2 specification.
>
> v5:
> Do not use bitfields for DRM structs (Jani N)
> v4:
> * Use DSC constants for params that dont change across
> configurations
> v3:
> * Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
> (Daniel Vetter)
>
> v2:
> * Add EXPORT_SYMBOL for the drm functions (Manasi)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
Acked-by: Harry Wentland
Harry
> ---
> Documentation/gpu/drm-kms-helpers.rst | 12 ++
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_dsc.c | 221
> ++
> include/drm/drm_dsc.h | 22
> 4 files changed, 256 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_dsc.c
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index f9cfcdc..50bb717 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -223,6 +223,18 @@ MIPI DSI Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
> :export:
>
> +Display Stream Compression Helper Functions Reference
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> + :doc: dsc helpers
> +
> +.. kernel-doc:: include/drm/drm_dsc.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> + :export:
> +
> Output Probing Helper Functions Reference
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a6771ce..961e511 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>
> -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
> drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> drm_simple_kms_helper.o drm_modeset_helper.o \
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> new file mode 100644
> index 000..99a8794
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -0,0 +1,221 @@
> +/*
> + *Copyright © 2018 Intel Corp
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + *
> + * Author:
> + * Manasi Navare
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * DOC: dsc helpers
> + *
> + * These functions contain some common logic and helpers to deal with VESA
> + * Display Stream Compression standard required for DSC on Display Port/eDP
> or
> + * MIPI display interfaces.
> + */
> +
> +/**
> + * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
> + * for DisplayPort as per the DP 1.4 spec.
> + * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
> + */
> +void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> +{
> + memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> +
> + pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> + pps_sdp->pps_header.HB2 =
Re: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
On Fri, Aug 17, 2018 at 12:31:51PM -0700, Srivatsa, Anusha wrote:
> This patch needs to now incorporate the newly added slice_row_per_frame
> parameter in PPS_16.
Nope, the slice_row_per_frame and slice_per_line are only required to configure
PPS
on the source side. They are not DSC spec related PPS parameters.
Manasi
>
> Anusha
>
> >-Original Message-
> >From: Navare, Manasi D
> >Sent: Tuesday, July 31, 2018 2:07 PM
> >To: intel-...@lists.freedesktop.org
> >Cc: Navare, Manasi D ; Singh, Gaurav K
> >; dri-devel@lists.freedesktop.org; Jani Nikula
> >; Ville Syrjala ;
> >Srivatsa, Anusha ; Harry Wentland
> >
> >Subject: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS
> >infoframe
> >
> >This patch defines a new header file for all the DSC 1.2 structures and
> >creates a
> >structure for PPS infoframe which will be used to send picture parameter set
> >secondary data packet for display stream compression.
> >All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> >from
> >VESA.
> >
> >Cc: Gaurav K Singh
> >Cc: dri-devel@lists.freedesktop.org
> >Cc: Jani Nikula
> >Cc: Ville Syrjala
> >Cc: Anusha Srivatsa
> >Cc: Harry Wentland
> >Signed-off-by: Manasi Navare
> >---
> > include/drm/drm_dsc.h | 365
> >++
> > 1 file changed, 365 insertions(+)
> > create mode 100644 include/drm/drm_dsc.h
> >
> >diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h new file mode
> >100644 index 000..678e8e6
> >--- /dev/null
> >+++ b/include/drm/drm_dsc.h
> >@@ -0,0 +1,365 @@
> >+/*
> >+ * Copyright (C) 2018 Intel Corp.
> >+ *
> >+ * Permission is hereby granted, free of charge, to any person
> >+obtaining a
> >+ * copy of this software and associated documentation files (the
> >+"Software"),
> >+ * to deal in the Software without restriction, including without
> >+limitation
> >+ * the rights to use, copy, modify, merge, publish, distribute,
> >+sublicense,
> >+ * and/or sell copies of the Software, and to permit persons to whom
> >+the
> >+ * Software is furnished to do so, subject to the following conditions:
> >+ *
> >+ * The above copyright notice and this permission notice shall be
> >+included in
> >+ * all copies or substantial portions of the Software.
> >+ *
> >+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >+EXPRESS OR
> >+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> >+MERCHANTABILITY,
> >+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> >EVENT
> >+SHALL
> >+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> >+DAMAGES OR
> >+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> >+OTHERWISE,
> >+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> >USE
> >+OR
> >+ * OTHER DEALINGS IN THE SOFTWARE.
> >+ *
> >+ * Authors:
> >+ * Manasi Navare */
> >+
> >+#ifndef DRM_DSC_H_
> >+#define DRM_DSC_H_
> >+
> >+#include
> >+
> >+/* VESA Display Stream Compression DSC 1.2 constants */
> >+#define DSC_NUM_BUF_RANGES 15
> >+
> >+/**
> >+ * struct picture_parameter_set - Represents 128 bytes of Picture
> >+Parameter Set
> >+ *
> >+ * The VESA DSC standard defines picture parameter set (PPS) which
> >+display
> >+ * stream compression encoders must communicate to decoders.
> >+ * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
> >+fields in
> >+ * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> >+ * The PPS fields that span over more than a byte should be stored in
> >+Big Endian
> >+ * format.
> >+ */
> >+struct picture_parameter_set {
> >+/**
> >+ * @dsc_version:
> >+ * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> >+ * PPS0[7:4] - dsc_version_major: Contains major version of DSC
> >+ */
> >+u8 dsc_version;
> >+/**
> >+ * @pps_identifier:
> >+ * PPS1[7:0] - Application specific identifier that can be
> >+ * used to differentiate between different PPS tables.
> >+ */
> >+u8 pps_identifier;
> >+/**
> >+ * @pps_reserved:
> >+ * PPS2[7:0]- RESERVED Byte
> >+ */
> >+u8 pps_reserved;
> >+/**
> >+ * @pps_3:
> >+ * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> >+ * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> >+ * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> >+ * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> >+ * PPS3[7:4] - bits_per_component: Bits per component for the original
> >+ * pixels of the encoded picture.
> >+ * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> >+ * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> >+ * allowed only when dsc_minor_version = 0x2)
> >+ */
> >+u8 pps_3;
> >+/**
> >+ * @pps_4:
> >+ * PPS4[1:0] -These are the most significant 2 bits of
> >+ * compressed BPP bits_per_pixel[9:0] syntax element.
> >+ *
[PULL] drm-misc-next-fixes for -rc1 part 2
Hi Dave, One more patch snuck in between my PR and today. drm-misc-next-fixes-2018-08-23-1: - Add quirk to Lenovo B50-80 to use 6 bpc instead of 8 (Feng) Cc: Kai-Heng Feng Cheers, Sean The following changes since commit 4acd8d01a2393f2145ad1db10b2d5c764582a98d: MAINTAINERS: drm-misc: Change seanpaul's email address (2018-08-16 11:48:24 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-08-23-1 for you to fetch changes up to 25da75043f8690fd083878447c91f289dfb63b87: drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 (2018-08-23 10:25:39 +0200) - Add quirk to Lenovo B50-80 to use 6 bpc instead of 8 (Feng) Cc: Kai-Heng Feng Kai-Heng Feng (1): drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) -- 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 v2 08/23] drm/dsc: Define VESA Display Stream Compression Capabilities
On 2018-07-31 05:07 PM, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
>
> v4 (From Manasi)
> * Add the DSC_MUX_WORD_SIZE constants (Manasi)
>
> v3 (From Manasi)
> * Remove the duplicate define (Suggested By:Harry Wentland)
>
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Manasi)
> * Remove driver specific fields (Manasi)
> * Move this struct definition to DRM (Manasi)
> * Define DSC 1.2 parameters (Manasi)
> * Use DSC_NUM_BUF_RANGES (Manasi)
> * Call it drm_dsc_config (Manasi)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
> Signed-off-by: Gaurav K Singh
Acked-by: Harry Wentland
Harry
> ---
> include/drm/drm_dsc.h | 110
> ++
> 1 file changed, 110 insertions(+)
>
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 678e8e6..eda323d 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -30,6 +30,116 @@
>
> /* VESA Display Stream Compression DSC 1.2 constants */
> #define DSC_NUM_BUF_RANGES 15
> +#define DSC_MUX_WORD_SIZE_8_10_BPC 48
> +#define DSC_MUX_WORD_SIZE_12_BPC 64
> +
> +/* Configuration for a single Rate Control model range */
> +struct dsc_rc_range_parameters {
> + /* Min Quantization Parameters allowed for this range */
> + u8 range_min_qp;
> + /* Max Quantization Parameters allowed for this range */
> + u8 range_max_qp;
> + /* Bits/group offset to apply to target for this group */
> + u8 range_bpg_offset;
> +};
> +
> +struct drm_dsc_config {
> + /* Bits / component for previous reconstructed line buffer */
> + u8 line_buf_depth;
> + /* Bits per component to code (must be 8, 10, or 12) */
> + u8 bits_per_component;
> + /*
> + * Flag indicating to do RGB - YCoCg conversion
> + * and back (should be 1 for RGB input)
> + */
> + bool convert_rgb;
> + u8 slice_count;
> + /* Slice Width */
> + u16 slice_width;
> + /* Slice Height */
> + u16 slice_height;
> + /*
> + * 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
> + * outside of DSC encode/decode algorithm)
> + */
> + bool enable422;
> + /* Picture Width */
> + u16 pic_width;
> + /* Picture Height */
> + u16 pic_height;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_high;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_low;
> + /* Bits/pixel target << 4 (ie., 4 fractional bits) */
> + u16 bits_per_pixel;
> + /*
> + * Factor to determine if an edge is present based
> + * on the bits produced
> + */
> + u8 rc_edge_factor;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit1;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit0;
> + /* Number of pixels to delay the initial transmission */
> + u16 initial_xmit_delay;
> + /* Number of pixels to delay the VLD on the decoder,not including SSM */
> + u16 initial_dec_delay;
> + /* Block prediction enable */
> + bool block_pred_enable;
> + /* Bits/group offset to use for first line of the slice */
> + u8 first_line_bpg_offset;
> + /* Value to use for RC model offset at slice start */
> + u16 initial_offset;
> + /* Thresholds defining each of the buffer ranges */
> + u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
> + /* Parameters for each of the RC ranges */
> + struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> + /* Total size of RC model */
> + u16 rc_model_size;
> + /* Minimum QP where flatness information is sent */
> + u8 flatness_min_qp;
> + /* Maximum QP where flatness information is sent */
> + u8 flatness_max_qp;
> + /* Initial value for scale factor */
> + u8 initial_scale_value;
> + /* Decrement scale factor every scale_decrement_interval groups */
> + u16 scale_decrement_interval;
> + /* Increment scale factor every scale_increment_interval groups */
> + u16 scale_increment_interval;
> + /* Non-first line BPG offset to use */
> + u16 nfl_bpg_offset;
> + /* BPG offset used to enforce slice bit */
> + u16 slice_bpg_offset;
> + /* Final RC linear transformation offset value */
> + u16 final_offset;
> + /* Enable on-off VBR (ie., disable stuffing bits) */
> + bool vbr_enable;
> + /* Mux word size (in bits) for SSM mode */
> + u8 mux_word_size;
> + /*
> + * The (max) size in bytes of the "chunks" that are
> + * used in slice multiplexing
> + */
> + u16 slice_chunk_size;
> + /* Rate
Re: [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe
Thanks for the review.
And yes it just removes the bitfields in PPS since the packing of the
bitfields and memory allocations are heavily dependent on HW.
So we cant have them in DRM level.
I will make sure to add this in version history and also add
Suggested-by: jani.nik...@linux.intel.com
Manasi
On Thu, Aug 23, 2018 at 03:40:12PM -0400, Harry Wentland wrote:
> On 2018-07-31 05:07 PM, Manasi Navare wrote:
> > This patch defines a new header file for all the DSC 1.2 structures
> > and creates a structure for PPS infoframe which will be used to send
> > picture parameter set secondary data packet for display stream compression.
> > All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> > from VESA.
> >
> > Cc: Gaurav K Singh
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Harry Wentland
> > Signed-off-by: Manasi Navare
>
> Looks like this version basically removes the bitfield definitions and adds
> those
> in the comments, compared to the review in May.
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > include/drm/drm_dsc.h | 365
> > ++
> > 1 file changed, 365 insertions(+)
> > create mode 100644 include/drm/drm_dsc.h
> >
> > diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> > new file mode 100644
> > index 000..678e8e6
> > --- /dev/null
> > +++ b/include/drm/drm_dsc.h
> > @@ -0,0 +1,365 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corp.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors:
> > + * Manasi Navare
> > + */
> > +
> > +#ifndef DRM_DSC_H_
> > +#define DRM_DSC_H_
> > +
> > +#include
> > +
> > +/* VESA Display Stream Compression DSC 1.2 constants */
> > +#define DSC_NUM_BUF_RANGES 15
> > +
> > +/**
> > + * struct picture_parameter_set - Represents 128 bytes of Picture
> > Parameter Set
> > + *
> > + * The VESA DSC standard defines picture parameter set (PPS) which display
> > + * stream compression encoders must communicate to decoders.
> > + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
> > fields in
> > + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> > + * The PPS fields that span over more than a byte should be stored in Big
> > Endian
> > + * format.
> > + */
> > +struct picture_parameter_set {
> > + /**
> > +* @dsc_version:
> > +* PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> > +* PPS0[7:4] - dsc_version_major: Contains major version of DSC
> > +*/
> > + u8 dsc_version;
> > + /**
> > +* @pps_identifier:
> > +* PPS1[7:0] - Application specific identifier that can be
> > +* used to differentiate between different PPS tables.
> > +*/
> > + u8 pps_identifier;
> > + /**
> > +* @pps_reserved:
> > +* PPS2[7:0]- RESERVED Byte
> > +*/
> > + u8 pps_reserved;
> > + /**
> > +* @pps_3:
> > +* PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> > +* generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> > +* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> > +* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> > +* PPS3[7:4] - bits_per_component: Bits per component for the original
> > +* pixels of the encoded picture.
> > +* 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> > +* 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> > +* allowed only when dsc_minor_version = 0x2)
> > +*/
> > + u8 pps_3;
> > + /**
> > +* @pps_4:
> > +* PPS4[1:0] -These are the most significant 2 bits of
> > +* compressed BPP bits_per_pixel[9:0] syntax element.
> > +* PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> > +* PPS4[3] - simple_422:
[Bug 107666] st_sampler_view.c:546 assert
https://bugs.freedesktop.org/show_bug.cgi?id=107666 Bug ID: 107666 Summary: st_sampler_view.c:546 assert Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: mar...@serafean.cz QA Contact: dri-devel@lists.freedesktop.org mesa 18.2.0_rc4 lspci: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] glxinfo: Device: AMD CAYMAN (DRM 2.50.0 / 4.17.14-gentoo, LLVM 6.0.1) (0x6719) Version: 18.2.0 Using Kodi to watch tv using the HTSP plugin, using VDPAU for decoding: kodi.bin: ../mesa-18.2.0-rc4/src/mesa/state_tracker/st_sampler_view.c:546: st_get_texture_sampler_view_from_stobj: Assertion `stObj->level_override || last_level(stObj) == view->u.tex.last_level' failed. VAAPI decoding works. -- 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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Hi John, On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote: > On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote: > > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: > >> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: > >>> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > Hey Noralf, all, > > I've been digging for a bit on the regression that this patch has > > tripped on the HiKey board as reported here: > https://lkml.org/lkml/2018/8/16/81 > > The first issue was that the kirin driver was setting > mode_config.max_width/height = 2048, which was causing errors as the > the requested resolution was 1920x2160 (due to surfaceflinger > requesting y*2 for page flipping). > >>> > >>> Hey Noralf, > >>> > >>> Sorry, I know your probably sick of me. But I just wanted to circle > >>> > >>> around on this little bit. So part of the issue I found earlier, was > >>> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > >>> Surfaceflinger's request for page flipping. > >> > >> Possibly slightly out of topic, but we're in 2018, is there any plan to > >> make SurfaceFlinger move away from FBDEV ? > > > > Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or > > is this just an artifact of the mali blob hwcomposer backend? > > Mostly its due to the simple fbdev being a legacy solution on android > that works out of the box. > I do suspect the android devs hope to retire it, which is why I'm > working on getting things going w/ the drm_hwcomposer right now so we > can get away from the fbdev. That would be good news. Are there many Android components other than vendor- specific hwcomposer implementations that still use fbdev ? > But in the meantime, keeping the fbdev method running is important so we > have a functioning device for testing AOSP w/ mainline. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart wrote: > On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote: >> On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter wrote: >> > On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: >> >> Possibly slightly out of topic, but we're in 2018, is there any plan to >> >> make SurfaceFlinger move away from FBDEV ? >> > >> > Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or >> > is this just an artifact of the mali blob hwcomposer backend? >> >> Mostly its due to the simple fbdev being a legacy solution on android >> that works out of the box. >> I do suspect the android devs hope to retire it, which is why I'm >> working on getting things going w/ the drm_hwcomposer right now so we >> can get away from the fbdev. > > That would be good news. Are there many Android components other than vendor- > specific hwcomposer implementations that still use fbdev ? So yea, I can't really speak about what the various vendors are doing, as I don't really know, but I'm aware there are still a few (in some cases major) vendors who still use fbdev on their shipping devices with their custom hwcomposer code. Other then that, to my knowledge AOSP only has a default fallback hwcomposer that uses fbdev, which is what we've used here as we didn't want to take the vendor's proprietary hwcomposer blob. But again, moving to the drm_hwcomposer is the shiny bright future, as soon as a few remaining issues are sorted upstream. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] libdrm 2.4.94
Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit : > https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2 -> Forbidden You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this server. > PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2.sig -> Not Found The requested URL /libdrm/libdrm-2.4.94.tar.bz2.sig was not found on this server. - Laurent Carlier http://www.archlinux.org signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107377] [CI][DRMTIP] igt@gem_gpgpu_fill - fail - Test assertion failure function gen7_render_flush, Failed assertion: ret == 0, Last errno: 5, Input/output error
https://bugs.freedesktop.org/show_bug.cgi?id=107377 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Lakshmi --- Closing this bug, this issue not seen since 1 month. -- 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
[no subject]
Hi Linus, Just a couple of fixes PRs for rc1, One MAINTAINERS address change, two panels fixes, and set of amdgpu fixes (build fixes, display fixes and some others). Thanks Dave. drm-next-2018-08-24: amdgpu and panel/misc fixes. The following changes since commit 3d63a3c14741ed015948943076f3c6a2f2cd7b27: Merge tag 'drm-msm-next-2018-08-10' of git://people.freedesktop.org/~robclark/linux into drm-next (2018-08-17 10:46:51 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-08-24 for you to fetch changes up to 3e20e97c2d55fb18e4b06d16478edc757483b7db: Merge tag 'drm-misc-next-fixes-2018-08-23-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-08-24 13:41:03 +1000) amdgpu and panel/misc fixes. Alex Deucher (1): drm/amdgpu/display: disable eDP fast boot optimization on DCE8 Christian König (3): drm/amdgpu: fix incorrect use of fcheck drm/amdgpu: fix incorrect use of drm_file->pid drm/amdgpu: fix amdgpu_amdkfd_remove_eviction_fence v3 Dave Airlie (3): Merge tag 'drm-misc-next-fixes-2018-08-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'drm-misc-next-fixes-2018-08-23-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Dmytro Laktyushkin (3): drm/amd/display: fix dp_ss_control vbios flag parsing drm/amd/display: make dp_ss_off optional drm/amd/display: fix dentist did ranges Evan Quan (1): drm/amdgpu: set correct base for THM/NBIF/MP1 IP Kai-Heng Feng (1): drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80 Leo (Sunpeng) Li (2): Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86" drm/amd/display: Don't build DCN1 when kcov is enabled Samson Tam (1): drm/amd/display: Do not retain link settings Sean Paul (2): drm/panel: simple: tv123wam: Add unprepare delay MAINTAINERS: drm-misc: Change seanpaul's email address Yintian Tao (2): drm/amdgpu: access register without KIQ drm/powerplay: enable dpm under pass-through MAINTAINERS| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 103 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 21 ++--- drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c | 3 + drivers/gpu/drm/amd/amdgpu/vi.c| 4 +- drivers/gpu/drm/amd/display/Kconfig| 6 ++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +- drivers/gpu/drm/amd/display/dc/Makefile| 2 +- .../amd/display/dc/bios/command_table_helper2.c| 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 21 - drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 6 +- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 12 +-- drivers/gpu/drm/amd/display/dc/dc.h| 2 +- .../gpu/drm/amd/display/dc/dce/dce_clock_source.c | 6 +- .../gpu/drm/amd/display/dc/dce/dce_clock_source.h | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 18 ++-- drivers/gpu/drm/amd/display/dc/dce/dce_clocks.h| 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 6 +- .../drm/amd/display/dc/dce/dce_stream_encoder.c| 20 ++-- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 10 +- drivers/gpu/drm/amd/display/dc/gpio/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c | 4 +- drivers/gpu/drm/amd/display/dc/gpio/hw_translate.c | 4 +- drivers/gpu/drm/amd/display/dc/i2caux/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/i2caux/i2caux.c | 4 +- drivers/gpu/drm/amd/display/dc/inc/core_types.h| 7 +- drivers/gpu/drm/amd/display/dc/irq/Makefile| 2 +- drivers/gpu/drm/amd/display/dc/irq/irq_service.c | 2 +- drivers/gpu/drm/amd/display/dc/os_types.h | 2 +- .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 4 +- drivers/gpu/drm/drm_edid.c | 3 + drivers/gpu/drm/panel/panel-simple.c | 3 + 35 files changed, 161 insertions(+), 142 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mach64: detect the dot clock divider correctly on sparc
On Sun, 19 Aug 2018, Ville Syrjälä wrote:
> On Fri, Aug 17, 2018 at 03:19:37PM -0400, Mikulas Patocka wrote:
> > On Sun Ultra 5, it happens that the dot clock is not set up properly for
> > some videomodes. For example, if we set the videomode "r1024x768x60" in
> > the firmware, Linux would incorrectly set a videomode with refresh rate
> > 180Hz when booting (suprisingly, my LCD monitor can display it, although
> > display quality is very low).
> >
> > The reason is this: Older mach64 cards set the divider in the register
> > VCLK_POST_DIV. The register has four 2-bit fields (the field that is
> > actually used is specified in the lowest two bits of the register
> > CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
> > there's another bit added - the top four bits of PLL_EXT_CNTL extend the
> > divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
> > The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
> > them, so it can work regardless if the card supports them. However, the
> > sparc64 firmware may set these extended dividers during boot - and the
> > mach64 driver detects incorrect dot clock in this case.
> >
> > This patch makes the driver read the additional divider bit from
> > PLL_EXT_CNTL and calculate the initial refresh rate properly.
> >
> > Signed-off-by: Mikulas Patocka
> > Cc: sta...@vger.kernel.org
> >
> > ---
> > drivers/video/fbdev/aty/atyfb.h |3 ++-
> > drivers/video/fbdev/aty/atyfb_base.c |7 ---
> > drivers/video/fbdev/aty/mach64_ct.c | 10 +-
> > 3 files changed, 11 insertions(+), 9 deletions(-)
> >
> > Index: linux-stable/drivers/video/fbdev/aty/atyfb.h
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/atyfb.h 2018-08-13
> > 21:12:11.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/atyfb.h2018-08-13
> > 21:17:14.0 +0200
> > @@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_
> > extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll
> > *pll);
> > extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
> >
> > +extern const u8 aty_postdividers[8];
> > +
> >
> > /*
> > * Hardware cursor support
> > @@ -359,7 +361,6 @@ static inline void wait_for_idle(struct
> >
> > extern void aty_reset_engine(const struct atyfb_par *par);
> > extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
> > -extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
> >
> > void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
> > void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
> > Index: linux-stable/drivers/video/fbdev/aty/atyfb_base.c
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/atyfb_base.c 2018-08-13
> > 21:12:11.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/atyfb_base.c 2018-08-13
> > 21:22:23.0 +0200
> > @@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_
> > /*
> > * PLL Reference Divider M:
> > */
> > - M = pll_regs[2];
> > + M = pll_regs[PLL_REF_DIV];
> >
> > /*
> > * PLL Feedback Divider N (Dependent on CLOCK_CNTL):
> > */
> > - N = pll_regs[7 + (clock_cntl & 3)];
> > + N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
> >
> > /*
> > * PLL Post Divider P (Dependent on CLOCK_CNTL):
> > */
> > - P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
> > + P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl
> > & 3) << 1)) & 3) |
> > +((pll_regs[PLL_EXT_CNTL] >> (2 +
> > (clock_cntl & 3))) & 4)];
> >
> > /*
> > * PLL Divider Q:
> > Index: linux-stable/drivers/video/fbdev/aty/mach64_ct.c
> > ===
> > --- linux-stable.orig/drivers/video/fbdev/aty/mach64_ct.c 2018-08-13
> > 21:12:11.0 +0200
> > +++ linux-stable/drivers/video/fbdev/aty/mach64_ct.c2018-08-13
> > 21:35:32.0 +0200
> > @@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8
> > */
> >
> > #define Maximum_DSP_PRECISION 7
> > -static u8 postdividers[] = {1,2,4,8,3};
> > +const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
>
> Not sure about the '5'. That setting is marked as reserved in my docs.
> So I guess it doesn't really matter what number we put there.
I downloaded documentation here:
http://ftp.nluug.nl/ftp/pub/NetBSD/misc/cegger/hw_manuals/ati/mach64_and_ragepro/
The RAGE XL/XC Register Reference Guide - at page 4-77 it says "select
alternate post dividers", but doesn't say what they are.
At page 4-89 it lists post dividers
[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off
https://bugs.freedesktop.org/show_bug.cgi?id=105046 --- Comment #17 from Michael Zapf --- Just installed openSUSE with kernel 4.18; the issue seems to be fixed! Let me check with my office PC (in about a week) before declaring it resolved. -- 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/nouveau: Fix nouveau_connector_ddc_detect()
It looks like that when we moved over to using
drm_connector_for_each_possible_encoder() in nouveau, that one rather
important part of this function got dropped by accident:
/* Right v here */
for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
int id = connector->encoder_ids[i];
if (id == 0)
break;
Since it's rather difficult to notice: the conditional in this loop is
actually:
nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER
Meaning that all early breaks result in nv_encoder keeping it's value,
otherwise nv_encoder = NULL. Ugh.
Since this got dropped, nouveau_connector_ddc_detect() now returns an
encoder for every single connector, regardless of whether or not it's
detected:
[ 1780.056185] nouveau :01:00.0: DRM: DDC responded, but no EDID for
DP-2
So: fix this to ensure we only return an encoder if we actually found
one, and clean up the rest of the function while we're at it since it's
nearly impossible to read properly.
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
Fixes: ddba766dd07e ("drm/nouveau: Use
drm_connector_for_each_possible_encoder()")
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 51 -
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 3b288be9c3f7..51b6f762f1e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -414,9 +414,9 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_gpio *gpio = nvxx_gpio(>client.device);
- struct nouveau_encoder *nv_encoder = NULL;
+ struct nouveau_encoder *nv_encoder = NULL, *found = NULL;
struct drm_encoder *encoder;
- int i, panel = -ENODEV;
+ int i, ret, panel = -ENODEV;
/* eDP panels need powering on by us (if the VBIOS doesn't default it
* to on) before doing any AUX channel transactions. LVDS panel power
@@ -433,37 +433,46 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
drm_connector_for_each_possible_encoder(connector, encoder, i) {
nv_encoder = nouveau_encoder(encoder);
- if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
- int ret = nouveau_dp_detect(nv_encoder);
+ switch (nv_encoder->dcb->type) {
+ case DCB_OUTPUT_DP:
+ ret = nouveau_dp_detect(nv_encoder);
if (ret == NOUVEAU_DP_MST)
return NULL;
- if (ret == NOUVEAU_DP_SST)
- break;
- } else
- if ((vga_switcheroo_handler_flags() &
-VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
- nv_encoder->dcb->type == DCB_OUTPUT_LVDS &&
- nv_encoder->i2c) {
- int ret;
+ else if (ret == NOUVEAU_DP_SST)
+ found = nv_encoder;
+
+ break;
+ case DCB_OUTPUT_LVDS:
+ /* Can we actually probe this LVDS display? */
+ if (!((vga_switcheroo_handler_flags() &
+ VGA_SWITCHEROO_CAN_SWITCH_DDC) &&
+ nv_encoder->i2c))
+ continue;
+
vga_switcheroo_lock_ddc(dev->pdev);
- ret = nvkm_probe_i2c(nv_encoder->i2c, 0x50);
- vga_switcheroo_unlock_ddc(dev->pdev);
- if (ret)
- break;
- } else
- if (nv_encoder->i2c) {
if (nvkm_probe_i2c(nv_encoder->i2c, 0x50))
- break;
+ found = nv_encoder;
+ vga_switcheroo_unlock_ddc(dev->pdev);
+
+ break;
+ default:
+ if (nv_encoder->i2c &&
+ nvkm_probe_i2c(nv_encoder->i2c, 0x50))
+ found = nv_encoder;
+
+ break;
}
+ if (found)
+ break;
}
/* eDP panel not detected, restore panel power GPIO to previous
* state to avoid confusing the SOR for other output types.
*/
- if (!nv_encoder && panel == 0)
+ if (!found && panel == 0)
nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, panel);
- return nv_encoder;
+ return found;
}
static struct nouveau_encoder *
--
2.17.1
___
dri-devel mailing list
[Bug 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #7 from Christopher --- Hello, I am getting similar issues with regards to fence wait timeouts. However I have narrowed it further to it ONLY happening when gnome is running on xorg. I have over the past month or so rebuilt my system from the ground up. I am NOT using a distro that holds peoples hands with package managers and bloated useless kernel modules. I use instructions from linuxfromscratch.org to build the entire system from the latest stable sourcecode. After I first boot into gnome, with it running on xorg, as soon as I have logged in and click on activities on the gnome menu and select terminal, then the little circle starts twirling, and after a few seconds the screen flashes, and it momentarily goes to the grey login background, then flashes to what can only be described as a mini pixal dump, then after a while it flashes back to the login screen again and you need to login again. At this point, if you click on the drop down list to see the types of login session available, gnome on xorg is missing from the list. At this stage I login and going back and activating gnome terminal is successfull, however the dmesg log shows that it has ring stalled errors, and the dreaded parser error that has been mentioned here. If I start gnome on wayland, and then proceed to click on activities and then on terminal to bring up gnome terminal, even though the circle twirls for a long time after, the terminal window opens almost immediately and the output of dmesg is free of the ring timeouts. Running xorg by itself using twm with clock and xterm also produces a clean dmesg log. Please find the results attached for both boot tests. By the way this is on one of the latest versions of the 4.18 kernel series available on kernel.org. The version of Mesa used is: mesa-18.1.5 -- 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 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #6 from Christopher --- Created attachment 141263 --> https://bugs.freedesktop.org/attachment.cgi?id=141263=edit dmsg output running on wayland -- 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 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 Bug ID: 107668 Summary: Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: naheemzaf...@gmail.com Created attachment 141265 --> https://bugs.freedesktop.org/attachment.cgi?id=141265=edit Dmesg from boot with Kernel 4.19 prerelease I have already reported this on Redhat Bugzilla, so if more information is needed, that may be a good place to look at comments: https://bugzilla.redhat.com/show_bug.cgi?id=1594488 Since the change to using dc in the kernel I am getting a blank screen with trying to boot my ultrawidescreen monitor. As a workaround I can use amdgpu.dc=0, but this hits al earlier big where at native resolution the display output is garbled (links in Redhat Bugzilla attach to another big report, youtube video of the same). I am attaching dmesg output from 4.19.0-0.rc0.git8.1.vanilla.knurd.1.fc28.x86_64 with and without amdgpu.dc=0 I have noticed a couple of entries in the dmesg without the amdgpu.dc=0: kernel: [drm] add ip block number 4 with amdgpu.dc=0 it is: kernel: [drm] add ip block number 4 The other ip address block entries are identical. with amdgpu.dc=0 I get this section: Aug 22 23:46:22 kernel: [drm] PCIE GART of 256M enabled (table at 0x00F40090). Aug 22 23:46:22 kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Aug 22 23:46:22 kernel: [drm] Driver supports precise vblank timestamp query. Aug 22 23:46:22 kernel: [drm] AMDGPU Display Connectors Aug 22 23:46:22 kernel: [drm] Connector 0: Aug 22 23:46:22 kernel: [drm] DP-1 Aug 22 23:46:22 kernel: [drm] HPD5 Aug 22 23:46:22 kernel: [drm] DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b Aug 22 23:46:22 kernel: [drm] Encoders: Aug 22 23:46:22 kernel: [drm] DFP1: INTERNAL_UNIPHY1 Aug 22 23:46:22 kernel: [drm] Connector 1: Aug 22 23:46:22 kernel: [drm] HDMI-A-1 Aug 22 23:46:22 kernel: [drm] HPD3 Aug 22 23:46:22 kernel: [drm] DDC: 0x4874 0x4874 0x4875 0x4875 0x4876 0x4876 0x4877 0x4877 Aug 22 23:46:22 kernel: [drm] Encoders: Aug 22 23:46:22 kernel: [drm] DFP2: INTERNAL_UNIPHY1 Aug 22 23:46:22 kernel: [drm] Connector 2: Aug 22 23:46:22 kernel: [drm] DVI-D-1 Aug 22 23:46:22 kernel: [drm] HPD4 Aug 22 23:46:22 kernel: [drm] DDC: 0x4878 0x4878 0x4879 0x4879 0x487a 0x487a 0x487b 0x487b Aug 22 23:46:22 kernel: [drm] Encoders: Aug 22 23:46:22 kernel: [drm] DFP3: INTERNAL_UNIPHY Aug 22 23:46:22 kernel: [drm] Chained IB support enabled! but without amdgpu.dc=0 only the first and last line of that section appear. Later down without the amdgpu.dc=0 I also get the following message: kernel: [drm] Cannot find any crtc or sizes This may also be similar to bug https://bugs.freedesktop.org/show_bug.cgi?id=105880 but that is for laptop panels on LVDS while this issue is with a discrete RX460 graphics card on HDMI -- 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 107627] Freedesktop runtime version 18.08 Mesa cached shaders result in crashes
https://bugs.freedesktop.org/show_bug.cgi?id=107627 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Timothy Arceri --- I've skimmed over the linked report and I've got no idea why you think this is a Mesa bug. Help me help you, a proper bug report should contain all the information I need to start looking into the issue. -- 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
[ANNOUNCE] libdrm 2.4.94
Benjamin Gaignard (2): tests/modetest: Add atomic support tests/util: Add support for stm module Christian König (7): amdgpu: stop using the hash table for fd_tab amdgpu: add handle table implementation v2 amdgpu: use handle table for KMS handles amdgpu: use handle table for flink names amdgpu: remove the hash table implementation amdgpu: always add all BOs to handle table amdgpu: fix off by one in handle_table_insert Junwei Zhang (5): amdgpu: add bo from user memory to handle table amdgpu: add a function to find bo by cpu mapping (v2) tests/amdgpu: add test for finding bo by CPU mapping amdgpu: free flink bo in bo import amdgpu: add a function to create amdgpu bo internally (v4) Kristian H. Kristensen (1): Bump to version 2.4.94 Likun Gao (1): amdgpu: Disable deadlock test suite for RV Michel Dänzer (2): amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping amdgpu: Eliminate void* arithmetic in amdgpu_find_bo_by_cpu_mapping Mike Lothian (1): libdrm: Fix amdgpu build failure Rob Clark (2): freedreno: don't leak stateobj rb refs freedreno: fix use-after-free with stateobj rb's Rodrigo Vivi (1): intel: Add a new CFL PCI ID. Tanmay Shah (1): libdrm: add msm drm uapi header git tag: libdrm-2.4.94 https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2 MD5: d48759b2c276382f9085799a08a153f5 libdrm-2.4.94.tar.bz2 SHA1: 740c5c19b5e451102d0f5b360dae3016b3e72eab libdrm-2.4.94.tar.bz2 SHA256: 31d9831e6eaa5b16fb560e5578b3428ce6aa024ff6c66882631005cc9624680f libdrm-2.4.94.tar.bz2 SHA512: ac6b37fd3b88f5b7660dc630ec0a22b05d24138d0985c93c45363b938f5ee72cfe8bb198d94765090c3a5c158c06f3be14b849fd00b8d865c04d4132e28f6920 libdrm-2.4.94.tar.bz2 PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2.sig https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.gz MD5: 1d2e80ffe5b69c31c8465966e5cc7ce4 libdrm-2.4.94.tar.gz SHA1: 05433abd64c692250a52694f1af74f161323a698 libdrm-2.4.94.tar.gz SHA256: c438b0e2a8e0c9e6a1d92f4c235176e545d81f4edb9a14bc606bb5ede6668d8e libdrm-2.4.94.tar.gz SHA512: 99cc4eba5e9fc44886c515484821e6d509d202ee269d292e0d9b426bb92a53f6fc7095174d12652b377cd12036e4138ebc324df9e36e5edde5da31d476fa4ebe libdrm-2.4.94.tar.gz PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.gz.sig ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
On 08/23/2018 01:47 AM, Christian König wrote: Am 22.08.2018 um 22:57 schrieb Jiandi An: On 08/22/2018 02:09 PM, Christian König wrote: Am 22.08.2018 um 20:57 schrieb Jiandi An: Framebuffer memory needs to be accessed decrypted. Ensure the memory encryption mask is not set for the ttm framebuffer mappings. NAK, the memory not only needs to be decrypted while CPU accessed but all the time. ttm_page_alloc.c and ttm_page_alloc_dma.c should already take care of that while mapping the pages. Regards, Christian. The path where the issue comes in is booting guest with AMD SEV enabled while using virtio-vga device. The ttm->pages doesn't go through ttm_populate_and_map_pages(). And that is the point where you need to jump in and fix the problem. When a driver implements the populate() and unpopulate() callbacks themselves it needs to take care of all that handling. Thanks for the suggestion and guidance. So you want me to register the callbacks something like virtio_gpu_ttm_populate() and virtio_gpu_ttm_unpopulate() in the virtio_gpu_bo_driver, and perform mapping by calling ttm_bo_kmap()? Then bring setting memory decrypted/encryped by calling set_memory_decrypted()/set_memory_encrypted() outside of ttm_bo_kmap(), do it within virtio_gpu_ttm_populate() and virtio_gpu_ttm_unpopulate() callbacks? Then get rid of the separate call of virtio_gpu_vmap_fb() the virtio_gpu driver does? In the kernel path, the virtio_gpu driver calls virtio_gpu_alloc_object() and goes down to ttm to allocate pages in ttm_pool_populate(). Driver in guest then does virtio_gpu_vmap_fb() which goes down to ttm_bo_kmap_ttm() and does a vmap() for GVA to GPA for those pages. If SEV is enabled, decryption should be set in this GVA to GPA mapping. That assumption is what is incorrect here. TTM can't work with encrypted pages, so you need to set the pages as decrypted directly after calling ttm_pool_populate(). And obviously set it to encrypted again before calling ttm_pool_unpopulate(). Probably best if we add that to ttm_tt_populate()/ttm_tt_unpopulate(). Here when you say ttm_tt_populate() and ttm_tt_unpopulate() you mean the virtio_gpu_ttm_populate() and virtio_gpu_ttm_unpopulate() that I register in virtio_gpu_bo_driver right? Regards, Christian. Guest then sends object attach command to host via virtio_gpu_object_attach() which stuffs the pages' physical addresses (guest physical address) in a scatter list and send them to host QEMU. Host QEMU maps those guest pages GPA to HPA and access via HVA while guest write stuff in those pages via GVA. virtio_gpu_alloc_object() virtio_gpu_object_create() sturct virtio_gpu_object bo kzalloc() ttm_bo_init() ... ttm_tt_create() bo->ttm = bdev->driver->ttm_tt_create() virtio_gpu_ttm_tt_create() ... ttm_tt_populate() ttm_pool_populate() ttm_get_pages(ttm->pages, ttm->num_pages) virtio_gpu_vmap_fb() virtio_gpu_object_kmap(obj, NULL) ttm_bo_kmap ttm_mem_io_reserve() ttm_bo_kmap_ttm() vmap() struct virtio_gpu_object bo->vmap = ttm_kmap_obj_virtual(>kmap, _iomem); virtio_gpu_object_attach() <<== Sending attach backing command virtio_gpu_object_get_sg_table() if (bo->tbo.ttm->state == tt_unpopulated) virtio_gpu_object bo.ttm->bdev->driver->ttm_tt_populate(bo->tbo.ttm, ); bo->pages = kmalloc(sizeof(struct sg_table), GFP_KERNEL); sg_alloc_table_from_pages(bo->tbo.ttm->pages) //Getfrom ttm->pages and put in sg __sg_alloc_table_from_pages() There is a separate userspace path for example when displace manager kicks in, virtio_gpu_alloc_object() followed by virtio_gpu_object_attach() are called through the ioctl virtio_gpu_resource_create_ioctl(). The mapping of the pages created in this page are handled in the do_page_fault() path in ttm_bo_vm_ops's ttm_bo_vm_fault() handler. do_page_fault() handle_mm_fault() __do_page_fault() ttm_bo_vm_fault() ttm_bo_reserve() __ttm_bo_reserve() ttm_mem_io_reserve_vm() ttm_mem_io_reserve() bdev->driver->io_mem_reserve() virtio_gpu_ttm_io_mem_reserve() mem->bus.is_iomem = false mem->mem_type == TTM_PL_TT I originally handled setting pages decrypted for the kernel path for GVA to GPA mapping in guest in virtio_gpu_vmap_fb() at the virtio_gpu driver layer. But for the user space path virtio_gpu_vmap_fb() is not called. Mapping is handled in the page_fault handler. So I moved it to the ttm layer. What layer do you recommend as more appropriate to handle setting memory decrypted for GVA to GPA mapping for thos ttm->pages? Thanks
[Bug 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #8 from Christopher --- Created attachment 141264 --> https://bugs.freedesktop.org/attachment.cgi?id=141264=edit dmsg output running on xorg -- 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 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 --- Comment #1 from Naheem Zaffar --- Created attachment 141266 --> https://bugs.freedesktop.org/attachment.cgi?id=141266=edit Dmesg output with amdgpu.dc=0 Taken when booting with Vanilla Mainline kernel 4.19.0-0.rc0.git8.1.vanilla.knurd.1.fc28.x86_64 with argument amdgpu.dc=0 -- 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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote: > On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote: >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >>> Hey Noralf, all, >>> I've been digging for a bit on the regression that this patch has >>> tripped on the HiKey board as reported here: >>> https://lkml.org/lkml/2018/8/16/81 >>> >>> The first issue was that the kirin driver was setting >>> mode_config.max_width/height = 2048, which was causing errors as the >>> the requested resolution was 1920x2160 (due to surfaceflinger >>> requesting y*2 for page flipping). >> >> Hey Noralf, >> Sorry, I know your probably sick of me. But I just wanted to circle >> around on this little bit. So part of the issue I found earlier, was >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> Surfaceflinger's request for page flipping. This is what makes the Y >> resolution 2160, which runs afoul of the new max_height check of 2048 >> in the generic code. >> >> I was checking with Xinliang, who know the kirin display hardware, >> about the max_height being set to 2048 to ensure bumping it up wasn't >> a problem, but he said 2048x2048 was unfortunately not arbitrary, and >> that was the hard limit of the display hardware. However, with >> overalloc, the 1920x2160 res fbdev should still be ok, as only >> 1920x1080 is actually displayed at one time. >> >> So it seems like we might need to multiply the max_height by the >> overalloc factor when we are checking it in >> drm_internal_framebuffer_create? >> >> Does that approach sound sane, or would folks prefer something different? > > I guess we could simply not check against the height limit when > allocating framebuffers. But we've done that for userspace buffers > since forever (they just allocate 2 buffers for page-flipping), so I > have no idea what would all break if we'd suddenly lift this > restriction. And whether we'd lift it for fbdev only or for everyone > doesn't really make much of a difference, since either this works, or > it doesn't (across all chips). That feels a bit more risky then what I was thinking. What about something like (apologies, whitespace corrupted) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index fe7e545..0424a71 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1810,6 +1810,7 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper, int i; struct drm_fb_helper_surface_size sizes; int gamma_size = 0; + struct drm_mode_config *config; memset(, 0, sizeof(struct drm_fb_helper_surface_size)); sizes.surface_depth = 24; @@ -1910,6 +1911,11 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper, sizes.surface_height *= drm_fbdev_overalloc; sizes.surface_height /= 100; + config = _helper->client.dev->mode_config; + config->max_height *= drm_fbdev_overalloc; + config->max_height /= 100; + + /* push down into drivers */ ret = (*fb_helper->funcs->fb_probe)(fb_helper, ); if (ret < 0) That way it only effects the fbdev + overalloc case? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm: Add per-plane pixel blend mode property
On Wed, Aug 22, 2018 at 03:27:44PM +0200, Maarten Lankhorst wrote:
> Op 15-08-18 om 08:35 schreef Lowry Li:
> > Pixel blend modes represent the alpha blending equation
> > selection, describing how the pixels from the current
> > plane are composited with the background.
> >
> > Adds a pixel_blend_mode to drm_plane_state and a
> > blend_mode_property to drm_plane, and related support
> > functions.
> >
> > Defines three blend modes in drm_blend.h.
> >
> > Changes since v1:
> > - Moves the blending equation into the DOC comment
> > - Refines the comments of drm_plane_create_blend_mode_property to not
> >enumerate the #defines, but instead the string values
> > - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
> > Changes since v2:
> > - Refines the comments of drm_plane_create_blend_mode_property:
> > 1) Puts the descriptions (after the ":") on a new line
> > 2) Adds explaining why @supported_modes need PREMUL as default
> > Changes since v3:
> > - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
> >can calculate the index itself just fine, so no point in having the
> >caller pass it in.
> > - Since the current DRM assumption is that alpha is premultiplied
> >as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
> > - Refines some comments.
> >
> > Signed-off-by: Lowry Li
> > ---
> > drivers/gpu/drm/drm_atomic.c| 4 ++
> > drivers/gpu/drm/drm_atomic_helper.c | 1 +
> > drivers/gpu/drm/drm_blend.c | 126
> >
> > include/drm/drm_blend.h | 6 ++
> > include/drm/drm_plane.h | 2 +
> > 5 files changed, 139 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e..d0478ab 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -895,6 +895,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > state->src_h = val;
> > } else if (property == plane->alpha_property) {
> > state->alpha = val;
> > + } else if (property == plane->blend_mode_property) {
> > + state->pixel_blend_mode = val;
> > } else if (property == plane->rotation_property) {
> > if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> > 0x%llx\n",
> > @@ -968,6 +970,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > *val = state->src_h;
> > } else if (property == plane->alpha_property) {
> > *val = state->alpha;
> > + } else if (property == plane->blend_mode_property) {
> > + *val = state->pixel_blend_mode;
> > } else if (property == plane->rotation_property) {
> > *val = state->rotation;
> > } else if (property == plane->zpos_property) {
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 6dd5036..563af09 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3569,6 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane
> > *plane,
> > /* Reset the alpha value to fully opaque if it matters */
> > if (plane->alpha_property)
> > state->alpha = plane->alpha_property->values[1];
> > + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> >
> > plane->state = state;
> > }
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index a16a74d..24016c9 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -107,6 +107,52 @@
> > * planes. Without this property the primary plane is always below the
> > cursor
> > * plane, and ordering between all other planes is undefined.
> > *
> > + * pixel blend mode:
> > + * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> > + * It adds a blend mode for alpha blending equation selection, describing
> > + * how the pixels from the current plane are composited with the
> > + * background.
> > + *
> > + * Three alpha blending equations are defined:
> > + *
> > + * "None":
> > + * Blend formula that ignores the pixel alpha::
> > + *
> > + * out.rgb = plane_alpha * fg.rgb +
> > + * (1 - plane_alpha) * bg.rgb
> > + *
> > + * "Pre-multiplied":
> > + * Blend formula that assumes the pixel color values
> > + * have been already pre-multiplied with the alpha
> > + * channel values::
> > + *
> > + * out.rgb = plane_alpha * fg.rgb +
> > + * (1 - (plane_alpha * fg.alpha)) * bg.rgb
> > + *
> > + * "Coverage":
> > + * Blend formula that assumes the pixel color values have not
> > + * been pre-multiplied and will do so when blending them to the
> > + *
Re: [PATCH 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
Hi Jiandi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jiandi-An/drm-ttm-Set-memory-as-decrypted-for-ttm-framebuffer-mappings/20180823-113546
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kmap':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:644:15: error: implicit declaration of
>> function 'sev_active'; did you mean 'cpu_active'?
>> [-Werror=implicit-function-declaration]
if (!ret && sev_active())
^~
cpu_active
>> drivers/gpu/drm/ttm/ttm_bo_util.c:645:4: error: implicit declaration of
>> function 'set_memory_decrypted'; did you mean 'set_memory_valid'?
>> [-Werror=implicit-function-declaration]
set_memory_decrypted((unsigned long) map->virtual,
^~~~
set_memory_valid
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kunmap':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:670:4: error: implicit declaration of
>> function 'set_memory_encrypted'; did you mean 'set_memory_valid'?
>> [-Werror=implicit-function-declaration]
set_memory_encrypted((unsigned long) map->virtual,
^~~~
set_memory_valid
cc1: some warnings being treated as errors
vim +644 drivers/gpu/drm/ttm/ttm_bo_util.c
617
618 int ttm_bo_kmap(struct ttm_buffer_object *bo,
619 unsigned long start_page, unsigned long num_pages,
620 struct ttm_bo_kmap_obj *map)
621 {
622 struct ttm_mem_type_manager *man =
623 >bdev->man[bo->mem.mem_type];
624 unsigned long offset, size;
625 int ret;
626
627 map->virtual = NULL;
628 map->bo = bo;
629 if (num_pages > bo->num_pages)
630 return -EINVAL;
631 if (start_page > bo->num_pages)
632 return -EINVAL;
633 #if 0
634 if (num_pages > 1 && !capable(CAP_SYS_ADMIN))
635 return -EPERM;
636 #endif
637 (void) ttm_mem_io_lock(man, false);
638 ret = ttm_mem_io_reserve(bo->bdev, >mem);
639 ttm_mem_io_unlock(man);
640 if (ret)
641 return ret;
642 if (!bo->mem.bus.is_iomem) {
643 ret = ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
> 644 if (!ret && sev_active())
> 645 set_memory_decrypted((unsigned long)
> map->virtual,
646 num_pages);
647 return ret;
648 } else {
649 offset = start_page << PAGE_SHIFT;
650 size = num_pages << PAGE_SHIFT;
651 return ttm_bo_ioremap(bo, offset, size, map);
652 }
653 }
654 EXPORT_SYMBOL(ttm_bo_kmap);
655
656 void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
657 {
658 struct ttm_buffer_object *bo = map->bo;
659 struct ttm_mem_type_manager *man =
660 >bdev->man[bo->mem.mem_type];
661
662 if (!map->virtual)
663 return;
664 switch (map->bo_kmap_type) {
665 case ttm_bo_map_iomap:
666 iounmap(map->virtual);
667 break;
668 case ttm_bo_map_vmap:
669 if (sev_active())
> 670 set_memory_encrypted((unsigned long)
> map->virtual,
671 bo->num_pages);
672 vunmap(map->virtual);
673 break;
674 case ttm_bo_map_kmap:
675 if (sev_active())
676 set_memory_encrypted((unsigned long)
map->virtual, 1);
677 kunmap(map->page);
678 break;
679 case ttm_bo_map_premapped:
680 break;
681 default:
682 BUG();
683 }
684 (void) ttm_mem_io_lock(man, false);
685 ttm_mem_io_free(map->bo->bdev, >bo->mem);
686 ttm_mem_i
[PATCH 0/3] drm: rcar-du: A few cosmetic changes
Hi Laurent,
there are a few things currently in-flight for DU on my side:
- non-DPLL channel clock source selction
- ESCR/OTAR handling for non-DPLL channel
Before taking those two functional changes series into account,
could you include these three cosmetic changes in your tree?
Patches based on your drm/du/next branch, with the following patch applied on
top:
'01449a9779b8 (" drm: rcar-du: Rework clock configuration based on hardware
limits")'
Tested on Salvator-X M3-W with kms-modes-tests.py: no functional changes
Thanks
j
Jacopo Mondi (3):
drm: rcar-du: Rename and document dpll_ch field
drm: rcar-du: Write ESCR register per channel
drm: rcar-du: Write OTAR register per channel
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +++---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 ++-
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 8
4 files changed, 12 insertions(+), 12 deletions(-)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: rcar-du: Write OTAR register per channel
The OTAR registers offset definition is confusing, as each channel is equipped with an OTAR register instance, but the names suggest only OTAR and OTAR2 are taken into account. Rename the offsets to a name that includes the channels they apply to, and write them to each channel with 'rcar_du_crtc_write()'. Cosmetic patch, no functional changes intended. Signed-off-by: Jacopo Mondi --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_regs.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 714c1fc..e2d9653 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -295,7 +295,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) } rcar_du_crtc_write(rcrtc, rcrtc->index % 2 ? ESCR13 : ESCR02, escr); - rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? OTAR2 : OTAR, 0); + rcar_du_crtc_write(rcrtc, rcrtc->index % 2 ? OTAR13 : OTAR02, 0); /* Signal polarities */ dsmr = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_regs.h b/drivers/gpu/drm/rcar-du/rcar_du_regs.h index ebc4aea..4144950 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_regs.h +++ b/drivers/gpu/drm/rcar-du/rcar_du_regs.h @@ -504,8 +504,8 @@ #define ESCR_SYNCSEL_EXHSYNC (3 << 8) #define ESCR_FRQSEL_MASK (0x3f << 0) -#define OTAR 0x10004 -#define OTAR2 0x31004 +#define OTAR02 0x10004 +#define OTAR13 0x01004 /* - * Dual Display Output Control Registers -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: rcar-du: Rename and document dpll_ch field
Document and re-name the 'dpll_ch' field to a more precise 'dpll_mask' for
consistency with the 'channels_mask' field defined in 'struct
rcar_du_device_info'.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +++---
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 ++-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 2664336..5454884 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -211,7 +211,7 @@ static void rcar_du_crtc_set_display_timing(struct
rcar_du_crtc *rcrtc)
u32 dsmr;
u32 escr;
- if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+ if (rcdu->info->dpll_mask & (1 << rcrtc->index)) {
unsigned long target = mode_clock;
struct dpll_info dpll = { 0 };
unsigned long extclk;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 02aee6c..b42145c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -215,7 +215,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7795_info = {
},
},
.num_lvds = 1,
- .dpll_ch = BIT(2) | BIT(1),
+ .dpll_mask = BIT(2) | BIT(1),
};
static const struct rcar_du_device_info rcar_du_r8a7796_info = {
@@ -243,7 +243,7 @@ static const struct rcar_du_device_info
rcar_du_r8a7796_info = {
},
},
.num_lvds = 1,
- .dpll_ch = BIT(1),
+ .dpll_mask = BIT(1),
};
static const struct rcar_du_device_info rcar_du_r8a77965_info = {
@@ -271,7 +271,7 @@ static const struct rcar_du_device_info
rcar_du_r8a77965_info = {
},
},
.num_lvds = 1,
- .dpll_ch = BIT(1),
+ .dpll_mask = BIT(1),
};
static const struct rcar_du_device_info rcar_du_r8a77970_info = {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index b3a25e8..6453b33 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -55,6 +55,7 @@ struct rcar_du_output_routing {
* @channels_mask: bit mask of available DU channels
* @routes: array of CRTC to output routes, indexed by output
(RCAR_DU_OUTPUT_*)
* @num_lvds: number of internal LVDS encoders
+ * @dpll_mask: mask of DU channels equipped with a DPLL
*/
struct rcar_du_device_info {
unsigned int gen;
@@ -63,7 +64,7 @@ struct rcar_du_device_info {
unsigned int channels_mask;
struct rcar_du_output_routing routes[RCAR_DU_OUTPUT_MAX];
unsigned int num_lvds;
- unsigned int dpll_ch;
+ unsigned int dpll_mask;
};
#define RCAR_DU_MAX_CRTCS 4
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: convert to SPDX identifiers for Renesas
Hi Laurent > > These are not yet appear on Linus tree. > > I will re-post it. > > Thank you, but there was no need to, they're stored safely in my tree :-) > I'll > send a pull request for v4.20. Thanks. Nice to know. Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80
Another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc
instead of 8 bpc.
Apply 6 bpc quirk for the panel to fix it.
BugLink: https://bugs.launchpad.net/bugs/1788308
Cc: # v4.8+
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5dc742b27ca0..3c9fc99648b7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -116,6 +116,9 @@ static const struct edid_quirk {
/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
{ "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+ /* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
+ { "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
atmel-hlcdc select pixel-clock outside of given range
Hi!
I just discovered that the atmel-hlcdc driver picks a pixel-clock
way outside the given range when used with a panel with these
timings from the device tree.
panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5335 6500 8000>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <48 88 88>;
hback-porch = <96 168 168>;
hsync-len = <32 64 64>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};
IIUC, the atmel-hlcdc driver uses this code to set the pixel-clock
cfg = 0;
prate = clk_get_rate(crtc->dc->hlcdc->sys_clk);
mode_rate = adj->crtc_clock * 1000;
if ((prate / 2) < mode_rate) {
prate *= 2;
cfg |= ATMEL_HLCDC_CLKSEL;
}
div = DIV_ROUND_UP(prate, mode_rate);
if (div < 2)
div = 2;
cfg |= ATMEL_HLCDC_CLKDIV(div);
regmap_update_bits(regmap, ATMEL_HLCDC_CFG(0),
ATMEL_HLCDC_CLKSEL | ATMEL_HLCDC_CLKDIV_MASK |
ATMEL_HLCDC_CLKPOL, cfg);
I.e., the driver sets the divider so that the output frequency is as high
as possible, but not above the target frequency, which seems sane enough.
Until you realize that the target frequency is the typical frequency
from the above device tree (i.e. 65MHz) without regard to the range of
allowed frequencies.
In my case, which happens to be really unfortunate, sys_clk is running
at 132MHz so the above results in div set to 3 which gives an output
frequency of 44MHz. This is way outside the given 53.35-80Mhz range.
Why was the mode allowed at all when the constraint was not met?
Further, selecting a div of 2 gets 66MHz, which is really close to the
target frequency and well inside the given range.
Given the overall picture, selecting div = 3 seems totally buggy.
Sure, I can work around it by saying
clock-frequency = <5335 6600 8000>;
but that is ... just an inappropriate workaround.
Side note, while looking at the above code, I wonder why ATMEL_HLCDC_CLKSEL
is not set most of the time, instead of only when it absolutely has to?
Dividing the doubled frequency (which seems to be what the flag is doing)
increases the accuracy of the output frequency. E.g. I would have gotten
52.8Mhz instead of 44MHz. So, still not inside the range, but much closer...
Side note, there is no sanity check in the code for too large div. That
will cause bits to be written outside the divider field in the register
and an output frequency that is not what the driver intended. But it is
probably not that important since div will probably be small most of the
time?
Cheers,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PROTO][PATCH 05/10] drm/bridge: adv7511: Add max-clock, min-vrefresh options
> On August 21, 2018 at 10:09 AM Laurent Pinchart > wrote: > > > Hi Ulrich, > > On Tuesday, 21 August 2018 11:03:45 EEST Ulrich Hecht wrote: > > On August 20, 2018 at 11:28 AM Laurent Pinchart wrote: > > > On Tuesday, 14 August 2018 16:49:59 EEST Ulrich Hecht wrote: > > >> From: Koji Matsuoka > > >> > > >> This patch adds the option to specify a maximal clock and a minimal > > >> vertical refresh rate. > > > > > > What is this needed for ? > > > > Somewhere in the chain there is a component that will not tolerate clocks in > > excess of 135 MHz; if you don't limit it, the default for a 1920x1200 > > display is somewhere along 148 MHz, and the HDMI signal output is invalid. > > Do you know which component that is ? Unfortunately not. It's not the ADV7511, though, that goes up to 225 MHz... CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: rcar-du: convert to SPDX identifiers
On Wed, Aug 22, 2018 at 01:57:19AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Kconfig doesn't have license line, thus, it is GPL-2.0 as default. > > Signed-off-by: Kuninori Morimoto > Acked-by: Laurent Pinchart Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: rcar-du: Refactor Feature and Quirk definitions
On Mon, Aug 20, 2018 at 05:00:43PM +0100, Kieran Bingham wrote: > These flags are represented by bit fields. To make this clear, utilise > the BIT() macro. > > Signed-off-by: Kieran Bingham > > --- > This patch fails checkpatch's 80-char limit, due to the line comments > extending across the 80-char boundary on RCAR_DU_FEATURE_EXT_CTRL_REGS > > To preserve formatting - this warning has been ignored. Reviewed-by: Simon Horman > > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h > b/drivers/gpu/drm/rcar-du/rcar_du_drv.h > index b3a25e8e07d0..78ea20abfb30 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h > @@ -27,11 +27,11 @@ struct drm_device; > struct drm_fbdev_cma; > struct rcar_du_device; > > -#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK (1 << 0)/* Per-CRTC IRQ > and clock */ > -#define RCAR_DU_FEATURE_EXT_CTRL_REGS(1 << 1)/* Has extended > control registers */ > -#define RCAR_DU_FEATURE_VSP1_SOURCE (1 << 2)/* Has inputs from VSP1 > */ > +#define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK BIT(0) /* Per-CRTC IRQ and > clock */ > +#define RCAR_DU_FEATURE_EXT_CTRL_REGSBIT(1) /* Has extended control > registers */ > +#define RCAR_DU_FEATURE_VSP1_SOURCE BIT(2) /* Has inputs from VSP1 */ > > -#define RCAR_DU_QUIRK_ALIGN_128B (1 << 0)/* Align pitches to 128 > bytes */ > +#define RCAR_DU_QUIRK_ALIGN_128B BIT(0) /* Align pitches to 128 bytes */ > > /* > * struct rcar_du_output_routing - Output routing specification > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: Fix typo in compatible description.
This fixes the error in the compatible documentation for the EDT etm0700[g].. panels which have accidentally documented as etm0700[8]0.. Signed-off-by: Jan Tuerk --- .../devicetree/bindings/display/panel/edt,et-series.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt index f56b99ebd9be..5759d64d0c15 100644 --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -23,13 +23,13 @@ simple-panel.txt +-+-+-+ | Identifier | compatbile | description | +=+=+=+ -| ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive| +| ETM0700G0DH6| edt,etm0700g0dh6| WVGA TFT Display with capacitive| | | | Touchscreen | +-+-+-+ -| ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with | +| ETM0700G0BDH6 | edt,etm0700g0bdh6 | Same as ETM0700G0DH6 but with | | | | inverted pixel clock. | +-+-+-+ -| ETM0700G0EDH6 | edt,etm070080edh6 | Same display as the ETM0700G0BDH6, | +| ETM0700G0EDH6 | edt,etm0700g0edh6 | Same display as the ETM0700G0BDH6, | | | | but with changed Hardware for the | | | | backlight and the touch interface | +-+-+-+ -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: omapdrm: displays: fix port_num for opa362 output
Hi Laurent, > Am 19.08.2018 um 16:07 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > Thank you for the patch. > > On Friday, 27 July 2018 17:24:32 EEST H. Nikolaus Schaller wrote: >> The opa362 amplifier has two ports, an input (usually connected >> to the OMAP3 VENC) and an output port connected to the external >> connector. >> >> These are usually defined as input port@0 and outpt port@1 in >> the DT and really distinguished by the reg = property >> of these nodes. >> >> But we are missing to define the output port as number 1 so >> it does not match the DT entry. >> >> Signed-off-by: H. Nikolaus Schaller > > I think this patch is superseded by "[PATCH v3 36/61] drm/omap: dss: Replace > omap_dss_device port number with bitmask" looks good and from cursory review it seems to resolve the opa362 bug as a side-effect. Maybe this can be noted in the commit description. What I am not sure how this magically defines the output as reg=<1> or if we have to swap reg number definitions in the DT. But encoder-tfp410.c and encoder-tpd12s015.c seem to do it the same way, so it is very likely that it works as defined. > which should get merged in v4.20. Well, I had hoped our bug fix makes it into v4.19 and can be potentially backported to stable. Do you plan to backport you patch? It seems to be quite independent and should apply to older releases. BR, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Update tree location for the Renesas DRM drivers
On Mon, Aug 20, 2018 at 01:14:13AM +0300, Laurent Pinchart wrote: > The fbdev git tree referenced in the MAINTAINERS file doesn't exist > anymore. Update the location to point to the new git tree. > > Signed-off-by: Laurent Pinchart Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: rcar-du: Write ESCR register per channel
The ESCR registers offset definition is confusing, as each channel is equipped with an ESCR register instance, but the names suggest only ESCR and ESCR2 are taken into account. Rename the offsets to a name that includes the channels they apply to, and write them to each channel with 'rcar_du_crtc_write()'. Cosmetic patch, no functional changes intended. Signed-off-by: Jacopo Mondi --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 +-- drivers/gpu/drm/rcar-du/rcar_du_regs.h | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 5454884..714c1fc 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -294,8 +294,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) } } - rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? ESCR2 : ESCR, - escr); + rcar_du_crtc_write(rcrtc, rcrtc->index % 2 ? ESCR13 : ESCR02, escr); rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? OTAR2 : OTAR, 0); /* Signal polarities */ diff --git a/drivers/gpu/drm/rcar-du/rcar_du_regs.h b/drivers/gpu/drm/rcar-du/rcar_du_regs.h index 9dfd220..ebc4aea 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_regs.h +++ b/drivers/gpu/drm/rcar-du/rcar_du_regs.h @@ -492,8 +492,8 @@ * External Synchronization Control Registers */ -#define ESCR 0x1 -#define ESCR2 0x31000 +#define ESCR02 0x1 +#define ESCR13 0x01000 #define ESCR_DCLKOINV (1 << 25) #define ESCR_DCLKSEL_DCLKIN(0 << 20) #define ESCR_DCLKSEL_CLKS (1 << 20) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: shmobile: convert to SPDX identifiers
On Wed, Aug 22, 2018 at 01:57:34AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto > Acked-by: Laurent Pinchart Reviewed-by: Simon Horman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Wed, Aug 22, 2018 at 11:21:11PM -0700, John Stultz wrote: > On Wed, Aug 22, 2018 at 10:51 PM, Daniel Vetter wrote: > > On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote: > >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz > >> wrote: > >>> Hey Noralf, all, > >>> I've been digging for a bit on the regression that this patch has > >>> tripped on the HiKey board as reported here: > >>> https://lkml.org/lkml/2018/8/16/81 > >>> > >>> The first issue was that the kirin driver was setting > >>> mode_config.max_width/height = 2048, which was causing errors as the > >>> the requested resolution was 1920x2160 (due to surfaceflinger > >>> requesting y*2 for page flipping). > >> > >> Hey Noralf, > >> Sorry, I know your probably sick of me. But I just wanted to circle > >> around on this little bit. So part of the issue I found earlier, was > >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > >> Surfaceflinger's request for page flipping. This is what makes the Y > >> resolution 2160, which runs afoul of the new max_height check of 2048 > >> in the generic code. > >> > >> I was checking with Xinliang, who know the kirin display hardware, > >> about the max_height being set to 2048 to ensure bumping it up wasn't > >> a problem, but he said 2048x2048 was unfortunately not arbitrary, and > >> that was the hard limit of the display hardware. However, with > >> overalloc, the 1920x2160 res fbdev should still be ok, as only > >> 1920x1080 is actually displayed at one time. > >> > >> So it seems like we might need to multiply the max_height by the > >> overalloc factor when we are checking it in > >> drm_internal_framebuffer_create? > >> > >> Does that approach sound sane, or would folks prefer something different? > > > > I guess we could simply not check against the height limit when > > allocating framebuffers. But we've done that for userspace buffers > > since forever (they just allocate 2 buffers for page-flipping), so I > > have no idea what would all break if we'd suddenly lift this > > restriction. And whether we'd lift it for fbdev only or for everyone > > doesn't really make much of a difference, since either this works, or > > it doesn't (across all chips). > > That feels a bit more risky then what I was thinking. What about > something like (apologies, whitespace corrupted) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index fe7e545..0424a71 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1810,6 +1810,7 @@ static int drm_fb_helper_single_fb_probe(struct > drm_fb_helper *fb_helper, > int i; > struct drm_fb_helper_surface_size sizes; > int gamma_size = 0; > + struct drm_mode_config *config; > > memset(, 0, sizeof(struct drm_fb_helper_surface_size)); > sizes.surface_depth = 24; > @@ -1910,6 +1911,11 @@ static int drm_fb_helper_single_fb_probe(struct > drm_fb_helper *fb_helper, > sizes.surface_height *= drm_fbdev_overalloc; > sizes.surface_height /= 100; > > + config = _helper->client.dev->mode_config; > + config->max_height *= drm_fbdev_overalloc; > + config->max_height /= 100; > + > + > /* push down into drivers */ > ret = (*fb_helper->funcs->fb_probe)(fb_helper, ); > if (ret < 0) > > > That way it only effects the fbdev + overalloc case? Still changes it for everyone, not just fbdev, if you enable overalloc. You'd need to reset. Another, cleaner way to fix this would be to overallocate the buffer, but have the drm_framebuffer limited. But that means we need to change the fbdev scrolling logic. And the entire interface between fbdev helpers and drivers needs a rework, since atm the driver allocates the drm_framebuffer for you. That's what userspace can/will do in this case I guess. Has all the issues of scrolling by moving the drm_fb without hw knowledge. I guess maybe just dropping the max_height check in fbdev is ok, if we put a really big comment/FIXME there. Or maybe make it conditional on fbdev_overalloc being at the default value, that'd probably be better even. -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 v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Hi John, On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > > Hey Noralf, all, > > > > I've been digging for a bit on the regression that this patch has > > > > tripped on the HiKey board as reported here: > > https://lkml.org/lkml/2018/8/16/81 > > > > The first issue was that the kirin driver was setting > > mode_config.max_width/height = 2048, which was causing errors as the > > the requested resolution was 1920x2160 (due to surfaceflinger > > requesting y*2 for page flipping). > > Hey Noralf, > Sorry, I know your probably sick of me. But I just wanted to circle > around on this little bit. So part of the issue I found earlier, was > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > Surfaceflinger's request for page flipping. Possibly slightly out of topic, but we're in 2018, is there any plan to make SurfaceFlinger move away from FBDEV ? > This is what makes the Y resolution 2160, which runs afoul of the new > max_height check of 2048 in the generic code. > > I was checking with Xinliang, who know the kirin display hardware, > about the max_height being set to 2048 to ensure bumping it up wasn't > a problem, but he said 2048x2048 was unfortunately not arbitrary, and > that was the hard limit of the display hardware. However, with > overalloc, the 1920x2160 res fbdev should still be ok, as only > 1920x1080 is actually displayed at one time. > > So it seems like we might need to multiply the max_height by the > overalloc factor when we are checking it in > drm_internal_framebuffer_create? > > Does that approach sound sane, or would folks prefer something different? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Add 6 bpc quirk for SDC panel in Lenovo B50-80
On Thu, Aug 23, 2018 at 05:53:32AM +, Kai-Heng Feng wrote:
> Another panel that reports "DFP 1.x compliant TMDS" but it supports 6bpc
> instead of 8 bpc.
>
> Apply 6 bpc quirk for the panel to fix it.
>
> BugLink: https://bugs.launchpad.net/bugs/1788308
> Cc: # v4.8+
> Signed-off-by: Kai-Heng Feng
Applied, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5dc742b27ca0..3c9fc99648b7 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -116,6 +116,9 @@ static const struct edid_quirk {
> /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
> { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
>
> + /* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
> + { "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
> +
> /* Belinea 10 15 55 */
> { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
> { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
[PATCH 1/5] drm: fix syncobj null_fence_enable_signaling
That is certainly totally nonsense. dma_fence_enable_sw_signaling()
is the function who is calling this callback.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
---
drivers/gpu/drm/drm_syncobj.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3a8837c49639..d17ed75ac7e2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -184,7 +184,6 @@ static const char *drm_syncobj_null_fence_get_name(struct
dma_fence *fence)
static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence *fence)
{
-dma_fence_enable_sw_signaling(fence);
return !dma_fence_is_signaled(fence);
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/7] add at91sam9 LCDC DRM driver
On Wed, Aug 22, 2018 at 10:12 PM, Sam Ravnborg wrote: > Hi Daniel. > >> > > Based on the above, would it be possible to utilise some >> > > of these features without any dedicated userspace (mesa) support? >> > > Any other driver that has something similar that can be used >> > > for inspiration? >> > >> > This is really an interesting question indeed. >> >> Needs userspace like everything else. There's unfortunately no real >> standard for 2d apis in userspace, which means none of these efforts go >> very far. Mostly it's just some custom-made X drivers. >> >> Adding a generic 2d api to drm is a FAQ, and the answer is "no". > > And then you went off writing a blog post about it - thanks. > The blog post provided a lot of useful answers - great. Yeah I figured more detail than this here would be good, but also wanted to avoid having to retype that ever again. > (Or rather you will write the blog in 5 days, seems to be some time > machine involved. (Date is the 27th below the title)). My blog platform pulled one on me - pushed it out with a future date, with the idea to proof-read a bit more. Didn't work, so everyone read the slightly draft-ish version :-/ In the past this did work, and was very neat. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Add plane alpha blending support, v2.
Op 23-08-18 om 00:57 schreef Matt Roper:
> On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
>> Add plane alpha blending support with the different blend modes.
>> This has been tested on a icl to show the correct results,
>> on earlier platforms small rounding errors cause issues. But this
>> already happens case with fully transparant or fully opaque RGB
>> fb's.
>>
>> The recommended HW workaround is to disable alpha blending when the
>> plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable
>> blending).
>> This is easy to implement on any platform, so just do that.
>>
>> The tests for userspace are also available, and pass on gen11.
>>
>> Changes since v1:
>> - Change mistaken < 0xff0 to 0xff00.
>> - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend
>> mode.
>> - Rework disabling FBC when per pixel alpha is used.
>>
>> Signed-off-by: Maarten Lankhorst
> One question and one minor suggestion inline below, but otherwise,
>
> Reviewed-by: Matt Roper
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 2 +
>> drivers/gpu/drm/i915/i915_reg.h | 2 +
>> drivers/gpu/drm/i915/intel_display.c | 58 +++-
>> drivers/gpu/drm/i915/intel_fbc.c | 8
>> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
>> 5 files changed, 73 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 3fa56b960ef2..29f75da5fa8c 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -545,6 +545,8 @@ struct intel_fbc {
>> int adjusted_y;
>>
>> int y;
>> +
>> +uint16_t pixel_blend_mode;
>> } plane;
>>
>> struct {
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 0c9f03dda569..93a1d87cdeb2 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -6561,8 +6561,10 @@ enum {
>> #define _PLANE_KEYVAL_2_A 0x70294
>> #define _PLANE_KEYMSK_1_A 0x70198
>> #define _PLANE_KEYMSK_2_A 0x70298
>> +#define PLANE_KEYMSK_ALPHA_ENABLE (1 << 31)
>> #define _PLANE_KEYMAX_1_A 0x701a0
>> #define _PLANE_KEYMAX_2_A 0x702a0
>> +#define PLANE_KEYMAX_ALPHA_SHIFT 24
>> #define _PLANE_AUX_DIST_1_A 0x701c0
>> #define _PLANE_AUX_DIST_2_A 0x702c0
>> #define _PLANE_AUX_OFFSET_1_A 0x701c4
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index a0345e7d3c2b..aedad3674b0d 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3167,6 +3167,12 @@ int skl_check_plane_surface(const struct
>> intel_crtc_state *crtc_state,
>> return -EINVAL;
>> }
>>
>> +/* HW only has 8 bits pixel precision, disable plane if invisible */
>> +if (!(plane_state->base.alpha >> 8)) {
>> +plane_state->base.visible = false;
>> +return 0;
>> +}
>> +
>> if (!plane_state->base.visible)
>> return 0;
>>
>> @@ -3512,30 +3518,39 @@ static u32 skl_plane_ctl_format(uint32_t
>> pixel_format)
>> return 0;
>> }
>>
>> -/*
>> - * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
>> - * to be already pre-multiplied. We need to add a knob (or a different
>> - * DRM_FORMAT) for user-space to configure that.
>> - */
>> -static u32 skl_plane_ctl_alpha(uint32_t pixel_format)
>> +static u32 skl_plane_ctl_alpha(const struct intel_plane_state *plane_state)
>> {
>> -switch (pixel_format) {
>> -case DRM_FORMAT_ABGR:
>> -case DRM_FORMAT_ARGB:
>> +if (!plane_state->base.fb->format->has_alpha)
>> +return PLANE_CTL_ALPHA_DISABLE;
>> +
>> +switch (plane_state->base.pixel_blend_mode) {
>> +case DRM_MODE_BLEND_PIXEL_NONE:
>> +return PLANE_CTL_ALPHA_DISABLE;
>> +case DRM_MODE_BLEND_PREMULTI:
>> return PLANE_CTL_ALPHA_SW_PREMULTIPLY;
>> +case DRM_MODE_BLEND_COVERAGE:
>> +return PLANE_CTL_ALPHA_HW_PREMULTIPLY;
>> default:
>> -return PLANE_CTL_ALPHA_DISABLE;
>> +MISSING_CASE(plane_state->base.pixel_blend_mode);
>> +return 0;
> Maybe just add the MISSING_CASE line before the current return? The
> macro still expands to 0, so leaving that makes it slightly more clear
> what the default fallback is. Same for the glk_ function below.
Makes sense, will change that in v3. :)
>> }
>> }
>>
>> -static u32 glk_plane_color_ctl_alpha(uint32_t pixel_format)
>> +static u32 glk_plane_color_ctl_alpha(const struct intel_plane_state
>> *plane_state)
>> {
>> -switch (pixel_format) {
>> -case DRM_FORMAT_ABGR:
>> -case DRM_FORMAT_ARGB:
>> +
Re: [PATCH 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
Am 22.08.2018 um 22:57 schrieb Jiandi An:
On 08/22/2018 02:09 PM, Christian König wrote:
Am 22.08.2018 um 20:57 schrieb Jiandi An:
Framebuffer memory needs to be accessed decrypted. Ensure the
memory encryption mask is not set for the ttm framebuffer mappings.
NAK, the memory not only needs to be decrypted while CPU accessed but all the
time.
ttm_page_alloc.c and ttm_page_alloc_dma.c should already take care of that
while mapping the pages.
Regards,
Christian.
The path where the issue comes in is booting guest with AMD SEV enabled while
using virtio-vga device.
The ttm->pages doesn't go through ttm_populate_and_map_pages().
And that is the point where you need to jump in and fix the problem.
When a driver implements the populate() and unpopulate() callbacks
themselves it needs to take care of all that handling.
In the kernel path, the virtio_gpu driver calls virtio_gpu_alloc_object() and
goes down to ttm to
allocate pages in ttm_pool_populate(). Driver in guest then does
virtio_gpu_vmap_fb() which goes
down to ttm_bo_kmap_ttm() and does a vmap() for GVA to GPA for those pages. If
SEV is enabled,
decryption should be set in this GVA to GPA mapping.
That assumption is what is incorrect here.
TTM can't work with encrypted pages, so you need to set the pages as
decrypted directly after calling ttm_pool_populate().
And obviously set it to encrypted again before calling
ttm_pool_unpopulate().
Probably best if we add that to ttm_tt_populate()/ttm_tt_unpopulate().
Regards,
Christian.
Guest then sends object attach command to host
via virtio_gpu_object_attach() which stuffs the pages' physical addresses
(guest physical address)
in a scatter list and send them to host QEMU. Host QEMU maps those guest pages
GPA to HPA and access
via HVA while guest write stuff in those pages via GVA.
virtio_gpu_alloc_object()
virtio_gpu_object_create()
sturct virtio_gpu_object bo kzalloc()
ttm_bo_init()
...
ttm_tt_create()
bo->ttm = bdev->driver->ttm_tt_create()
virtio_gpu_ttm_tt_create()
...
ttm_tt_populate()
ttm_pool_populate()
ttm_get_pages(ttm->pages, ttm->num_pages)
virtio_gpu_vmap_fb()
virtio_gpu_object_kmap(obj, NULL)
ttm_bo_kmap
ttm_mem_io_reserve()
ttm_bo_kmap_ttm()
vmap()
struct virtio_gpu_object bo->vmap = ttm_kmap_obj_virtual(>kmap,
_iomem);
virtio_gpu_object_attach() <<== Sending attach backing command
virtio_gpu_object_get_sg_table()
if (bo->tbo.ttm->state == tt_unpopulated)
virtio_gpu_object bo.ttm->bdev->driver->ttm_tt_populate(bo->tbo.ttm,
);
bo->pages = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
sg_alloc_table_from_pages(bo->tbo.ttm->pages) //Getfrom
ttm->pages and put in sg
__sg_alloc_table_from_pages()
There is a separate userspace path for example when displace manager kicks in,
virtio_gpu_alloc_object() followed by virtio_gpu_object_attach() are called
through
the ioctl virtio_gpu_resource_create_ioctl(). The mapping of the pages created
in this
page are handled in the do_page_fault() path in ttm_bo_vm_ops's
ttm_bo_vm_fault() handler.
do_page_fault()
handle_mm_fault()
__do_page_fault()
ttm_bo_vm_fault()
ttm_bo_reserve()
__ttm_bo_reserve()
ttm_mem_io_reserve_vm()
ttm_mem_io_reserve()
bdev->driver->io_mem_reserve()
virtio_gpu_ttm_io_mem_reserve()
mem->bus.is_iomem = false
mem->mem_type == TTM_PL_TT
I originally handled setting pages decrypted for the kernel path for GVA to GPA
mapping in guest
in virtio_gpu_vmap_fb() at the virtio_gpu driver layer. But for the user space
path
virtio_gpu_vmap_fb() is not called. Mapping is handled in the page_fault
handler. So I moved it
to the ttm layer.
What layer do you recommend as more appropriate to handle setting memory
decrypted for GVA to GPA
mapping for thos ttm->pages?
Thanks
Jiandi
Signed-off-by: Jiandi An
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..b3f5d26f571e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -29,6 +29,7 @@
* Authors: Thomas Hellstrom
*/
+#include
#include
#include
#include
@@ -639,7 +640,11 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
if (ret)
return ret;
if (!bo->mem.bus.is_iomem) {
- return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
+ ret = ttm_bo_kmap_ttm(bo, start_page,
Re: [PATCH v4 1/2] drm: Add per-plane pixel blend mode property
On Wed, Aug 22, 2018 at 08:39:49AM -0400, Sean Paul wrote:
> On Wed, Aug 15, 2018 at 02:35:32PM +0800, Lowry Li wrote:
> > Pixel blend modes represent the alpha blending equation
> > selection, describing how the pixels from the current
> > plane are composited with the background.
> >
> > Adds a pixel_blend_mode to drm_plane_state and a
> > blend_mode_property to drm_plane, and related support
> > functions.
> >
> > Defines three blend modes in drm_blend.h.
> >
> > Changes since v1:
> > - Moves the blending equation into the DOC comment
> > - Refines the comments of drm_plane_create_blend_mode_property to not
> >enumerate the #defines, but instead the string values
> > - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
> > Changes since v2:
> > - Refines the comments of drm_plane_create_blend_mode_property:
> > 1) Puts the descriptions (after the ":") on a new line
> > 2) Adds explaining why @supported_modes need PREMUL as default
> > Changes since v3:
> > - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
> >can calculate the index itself just fine, so no point in having the
> >caller pass it in.
> > - Since the current DRM assumption is that alpha is premultiplied
> >as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
> > - Refines some comments.
> >
> > Signed-off-by: Lowry Li
> > ---
> > drivers/gpu/drm/drm_atomic.c| 4 ++
> > drivers/gpu/drm/drm_atomic_helper.c | 1 +
> > drivers/gpu/drm/drm_blend.c | 126
> >
> > include/drm/drm_blend.h | 6 ++
> > include/drm/drm_plane.h | 2 +
> > 5 files changed, 139 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e..d0478ab 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -895,6 +895,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > state->src_h = val;
> > } else if (property == plane->alpha_property) {
> > state->alpha = val;
> > + } else if (property == plane->blend_mode_property) {
> > + state->pixel_blend_mode = val;
> > } else if (property == plane->rotation_property) {
> > if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> > 0x%llx\n",
> > @@ -968,6 +970,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > *val = state->src_h;
> > } else if (property == plane->alpha_property) {
> > *val = state->alpha;
> > + } else if (property == plane->blend_mode_property) {
> > + *val = state->pixel_blend_mode;
> > } else if (property == plane->rotation_property) {
> > *val = state->rotation;
> > } else if (property == plane->zpos_property) {
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 6dd5036..563af09 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3569,6 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane
> > *plane,
> > /* Reset the alpha value to fully opaque if it matters */
> > if (plane->alpha_property)
> > state->alpha = plane->alpha_property->values[1];
> > + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> Shouldn't this be state->pixel_blend_mode instead of
> plane->state->pixel_blend_mode?
Hi Sean,
Yeah, will refine this. Thanks for your comments:)
> >
> > plane->state = state;
> > }
>
> /snip
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Regards,
Lowry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On 2018.08.22 20:20:46 +0200, Paolo Bonzini wrote:
> On 22/08/2018 18:44, Linus Torvalds wrote:
> > An example of something that *isn't* right, is the i915 kvm interface,
> > which does
> >
> > use_mm(kvm->mm);
> >
> > on an mm that was initialized in virt/kvm/kvm_main.c using
> >
> > mmgrab(current->mm);
> > kvm->mm = current->mm;
> >
> > which is *not* right. Using "mmgrab()" does indeed guarantee the
> > lifetime of the 'struct mm_struct' itself, but it does *not* guarantee
> > the lifetime of the page tables. You need to use "mmget()" and
> > "mmput()", which get the reference to the actual process address
> > space!
> >
> > Now, it is *possible* that the kvm use is correct too, because kvm
> > does register a mmu_notifier chain, and in theory you can avoid the
> > proper refcounting by just making sure the mmu "release" notifier
> > kills any existing uses, but I don't really see kvm doing that. Kvm
> > does register a release notifier, but that just flushes the shadow
> > page tables, it doesn't kill any use_mm() use by some i915 use case.
>
> Yes, KVM is correct but the i915 bits are at least fishy. It's probably
> as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init
> and kvmgt_guest_exit, or maybe mmget_not_zero.
>
yeah, that's the clear way to fix this imo. We only depend on guest
life cycle to access guest memory properly. Here's proposed fix, will
verify and integrate it later.
Thanks!
From 5e5a8d0409aa150884adf5a4d0b956fd0b9906b3 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang
Date: Thu, 23 Aug 2018 14:08:06 +0800
Subject: [PATCH] drm/i915/gvt: Fix life cycle reference on KVM mm
Handle guest mm access life cycle properly with mmget()/mmput()
through guest init()/exit(). As noted by Linus, use_mm() depends
on valid live page table but KVM's mmgrab() doesn't guarantee that.
As vGPU usage depends on guest VM life cycle, need to make sure to
use mmget()/mmput() to guarantee VM address access.
Cc: Linus Torvalds
Cc: Paolo Bonzini
Cc: Zhi Wang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 71751be329e3..4a0988747d08 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1614,9 +1615,16 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
if (__kvmgt_vgpu_exist(vgpu, kvm))
return -EEXIST;
+ if (!mmget_not_zero(kvm->mm)) {
+ gvt_vgpu_err("Can't get KVM mm reference\n");
+ return -EINVAL;
+ }
+
info = vzalloc(sizeof(struct kvmgt_guest_info));
- if (!info)
+ if (!info) {
+ mmput(kvm->mm);
return -ENOMEM;
+ }
vgpu->handle = (unsigned long)info;
info->vgpu = vgpu;
@@ -1647,6 +1655,8 @@ static bool kvmgt_guest_exit(struct kvmgt_guest_info
*info)
debugfs_remove(info->debugfs_cache_entries);
kvm_page_track_unregister_notifier(info->kvm, >track_node);
+ if (info->kvm->mm)
+ mmput(info->kvm->mm);
kvm_put_kvm(info->kvm);
kvmgt_protect_table_destroy(info);
gvt_cache_destroy(info->vgpu);
--
2.18.0
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
Hi Jiandi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180822]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jiandi-An/drm-ttm-Set-memory-as-decrypted-for-ttm-framebuffer-mappings/20180823-113546
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kmap':
drivers/gpu/drm/ttm/ttm_bo_util.c:644:15: error: implicit declaration of
function 'sev_active'; did you mean 'cpu_active'?
[-Werror=implicit-function-declaration]
if (!ret && sev_active())
^~
cpu_active
>> drivers/gpu/drm/ttm/ttm_bo_util.c:645:4: error: implicit declaration of
>> function 'set_memory_decrypted'; did you mean 'set_memory_rw'?
>> [-Werror=implicit-function-declaration]
set_memory_decrypted((unsigned long) map->virtual,
^~~~
set_memory_rw
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kunmap':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:670:4: error: implicit declaration of
>> function 'set_memory_encrypted'; did you mean 'set_memory_nx'?
>> [-Werror=implicit-function-declaration]
set_memory_encrypted((unsigned long) map->virtual,
^~~~
set_memory_nx
cc1: some warnings being treated as errors
vim +645 drivers/gpu/drm/ttm/ttm_bo_util.c
617
618 int ttm_bo_kmap(struct ttm_buffer_object *bo,
619 unsigned long start_page, unsigned long num_pages,
620 struct ttm_bo_kmap_obj *map)
621 {
622 struct ttm_mem_type_manager *man =
623 >bdev->man[bo->mem.mem_type];
624 unsigned long offset, size;
625 int ret;
626
627 map->virtual = NULL;
628 map->bo = bo;
629 if (num_pages > bo->num_pages)
630 return -EINVAL;
631 if (start_page > bo->num_pages)
632 return -EINVAL;
633 #if 0
634 if (num_pages > 1 && !capable(CAP_SYS_ADMIN))
635 return -EPERM;
636 #endif
637 (void) ttm_mem_io_lock(man, false);
638 ret = ttm_mem_io_reserve(bo->bdev, >mem);
639 ttm_mem_io_unlock(man);
640 if (ret)
641 return ret;
642 if (!bo->mem.bus.is_iomem) {
643 ret = ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
> 644 if (!ret && sev_active())
> 645 set_memory_decrypted((unsigned long)
> map->virtual,
646 num_pages);
647 return ret;
648 } else {
649 offset = start_page << PAGE_SHIFT;
650 size = num_pages << PAGE_SHIFT;
651 return ttm_bo_ioremap(bo, offset, size, map);
652 }
653 }
654 EXPORT_SYMBOL(ttm_bo_kmap);
655
656 void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
657 {
658 struct ttm_buffer_object *bo = map->bo;
659 struct ttm_mem_type_manager *man =
660 >bdev->man[bo->mem.mem_type];
661
662 if (!map->virtual)
663 return;
664 switch (map->bo_kmap_type) {
665 case ttm_bo_map_iomap:
666 iounmap(map->virtual);
667 break;
668 case ttm_bo_map_vmap:
669 if (sev_active())
> 670 set_memory_encrypted((unsigned long)
> map->virtual,
671 bo->num_pages);
672 vunmap(map->virtual);
673 break;
674 case ttm_bo_map_kmap:
675 if (sev_active())
676 set_memory_encrypted((unsigned long)
map->virtual, 1);
677 kunmap(map->page);
678 break;
679 case ttm_bo_map_premapped:
680 break;
681 default:
682 BUG();
683 }
684 (void) ttm_mem_io_lock(man, false);
685 ttm_mem_io_free(map->bo->bdev, >bo->mem);
686 ttm_mem_io_unlock(man);
687 map-&
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote: > Hi John, > > On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote: > > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > > > Hey Noralf, all, > > > > > > I've been digging for a bit on the regression that this patch has > > > > > > tripped on the HiKey board as reported here: > > > https://lkml.org/lkml/2018/8/16/81 > > > > > > The first issue was that the kirin driver was setting > > > mode_config.max_width/height = 2048, which was causing errors as the > > > the requested resolution was 1920x2160 (due to surfaceflinger > > > requesting y*2 for page flipping). > > > > Hey Noralf, > > Sorry, I know your probably sick of me. But I just wanted to circle > > around on this little bit. So part of the issue I found earlier, was > > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > > Surfaceflinger's request for page flipping. > > Possibly slightly out of topic, but we're in 2018, is there any plan to make > SurfaceFlinger move away from FBDEV ? Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or is this just an artifact of the mali blob hwcomposer backend? -Daniel > > > This is what makes the Y resolution 2160, which runs afoul of the new > > max_height check of 2048 in the generic code. > > > > I was checking with Xinliang, who know the kirin display hardware, > > about the max_height being set to 2048 to ensure bumping it up wasn't > > a problem, but he said 2048x2048 was unfortunately not arbitrary, and > > that was the hard limit of the display hardware. However, with > > overalloc, the 1920x2160 res fbdev should still be ok, as only > > 1920x1080 is actually displayed at one time. > > > > So it seems like we might need to multiply the max_height by the > > overalloc factor when we are checking it in > > drm_internal_framebuffer_create? > > > > Does that approach sound sane, or would folks prefer something different? > > -- > Regards, > > Laurent Pinchart > > > -- 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 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #7 from Michel Dänzer --- (In reply to Jorge Blasio from comment #6) > I've an almost identical issue, however I'm using HDMI and I can get back to > the graphical session by switching to VT1 and then back to VT2. Sounds like bug 107519, fixed in current xf86-video-amdgpu Git master. -- 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 4/5] drm: expand replace_fence to support timeline point
we can place a fence to a timeline point after expanded.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 16 +---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/v3d/v3d_gem.c | 3 ++-
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
include/drm/drm_syncobj.h | 2 +-
6 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4d3f1a6ee078..ef922e34086e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1151,7 +1151,7 @@ static void amdgpu_cs_post_dependencies(struct
amdgpu_cs_parser *p)
int i;
for (i = 0; i < p->num_post_dep_syncobjs; ++i)
- drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence);
+ drm_syncobj_replace_fence(p->post_dep_syncobjs[i], p->fence, 0);
}
static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 3aac0b50a104..6227df2cc0a4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -141,11 +141,13 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
* drm_syncobj_replace_fence - replace fence in a sync object.
* @syncobj: Sync object to replace fence in
* @fence: fence to install in sync file.
+ * @point: timeline point
*
- * This replaces the fence on a sync object.
+ * This replaces the fence on a sync object, or a timeline point fence.
*/
void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
- struct dma_fence *fence)
+ struct dma_fence *fence,
+ u64 point)
{
struct dma_fence *old_fence;
struct drm_syncobj_cb *cur, *tmp;
@@ -206,7 +208,7 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
>lock, 0, 0);
dma_fence_signal(>base);
- drm_syncobj_replace_fence(syncobj, >base);
+ drm_syncobj_replace_fence(syncobj, >base, 0);
dma_fence_put(>base);
@@ -258,7 +260,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- drm_syncobj_replace_fence(syncobj, NULL);
+ drm_syncobj_replace_fence(syncobj, NULL, 0);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -298,7 +300,7 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
}
if (fence)
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, fence, 0);
*out_syncobj = syncobj;
return 0;
@@ -483,7 +485,7 @@ static int drm_syncobj_import_sync_file_fence(struct
drm_file *file_private,
return -ENOENT;
}
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, fence, 0);
dma_fence_put(fence);
drm_syncobj_put(syncobj);
return 0;
@@ -965,7 +967,7 @@ drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
return ret;
for (i = 0; i < args->count_handles; i++)
- drm_syncobj_replace_fence(syncobjs[i], NULL);
+ drm_syncobj_replace_fence(syncobjs[i], NULL, 0);
drm_syncobj_array_free(syncobjs, args->count_handles);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 60dc2a865f5f..fab3b8fe7a60 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2211,7 +2211,7 @@ signal_fence_array(struct i915_execbuffer *eb,
if (!(flags & I915_EXEC_FENCE_SIGNAL))
continue;
- drm_syncobj_replace_fence(syncobj, fence);
+ drm_syncobj_replace_fence(syncobj, fence, 0);
}
}
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index f6dfb8140a62..f3ec1f18c04c 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -587,7 +587,8 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
sync_out = drm_syncobj_find(file_priv, args->out_sync);
if (sync_out) {
drm_syncobj_replace_fence(sync_out,
- >render.base.s_fence->finished);
+ >render.base.s_fence->finished,
+ 0);
drm_syncobj_put(sync_out);
}
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index f7b4971342e8..68832d66d716 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
