[GIT PULL] drm/fsl-dcu: fixes for v4.11
Hi Dave, Just two minor fixes this time around. -- Stefan The following changes since commit 4eaa39c63caf535dc1a8cc43b9a8677a100c09e1: Merge branch 'drm-rockchip-next-2017-02-07' of https://github.com/markyzq/kernel-drm-rockchip into drm-next (2017-02-08 11:28:19 +1000) are available in the git repository at: http://git.agner.ch/git/linux-drm-fsl-dcu.git tags/drm-fsl-dcu-for-v4.11 for you to fetch changes up to ef15d36154cc741d7ded4ae4fa0cf7987354e313: drm/fsl-dcu: check for clk_prepare_enable() error (2017-02-07 20:28:04 -0800) Fabio Estevam (2): drm/fsl-dcu: remove unneeded 'ret' assignment drm/fsl-dcu: check for clk_prepare_enable() error drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc
On Wed, Feb 8, 2017 at 1:45 AM, Mark yao wrote: > On 2017年02月08日 00:14, Sean Paul wrote: >> >> On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote: >>> >>> drm crtc already has mode_fixup callback to can do mode check, but >>> We actually want to valid display mode on connector getmode time, >>> mode_fixup can't do it. >>> >>> So add a private mode_valid callback to rockchip crtc, connectors can >>> check mode with this mode_valid callback. >>> >> There are some nasty layer violations happening in this set. You should >> use >> mode_fixup if the crtc has limitations on the mode being set. >> >> Sean > > Mode_fixup can also check crtc limitations, but it's secondly time to check > display mode. > > mode_fixup only works on drm_setcrtc or atomic_commit check, when userspace > get a series of display modes, > They don't know which display mode is bad before drm_setcrtc or > atomic_commit check, they need try, > but drm_setcrtc or atomic_commit check not only for display mode check, > means that userspace didn't have a sure > method to verify display mode. > > So I try to add the mode_valid callback to connector getmodes time, verify > display mode before send mode list to userspace. > then userspace would get a good display mode list. You need both, the kerneldoc of these hooks explains in detail why. -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 v2] drm/mxsfb: fix pixel clock polarity
On Wed, Feb 8, 2017 at 6:19 AM, Stefan Agner wrote:
> On 2016-12-14 13:25, Marek Vasut wrote:
>> On 12/14/2016 09:48 PM, Stefan Agner wrote:
>>> The DRM subsystem specifies the pixel clock polarity from a
>>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>>> the controller drives the data on pixel clocks falling edge.
>>> That is the controllers DOTCLK_POL=0 (Default is data launched
>>> at negative edge).
>>>
>>> Also change the data enable logic to be high active by default
>>> and only change if explicitly requested via bus_flags. With
>>> that defaults are:
>>> - Data enable: high active
>>> - Pixel clock polarity: controller drives data on negative edge
>>>
>>> Signed-off-by: Stefan Agner
>>
>> Acked-by: Marek Vasut
>>
>
> This seems not have made into drm-next yet. Not sure what the plan is
> here, who will pick this up? There is also another fix on ML for the
> same driver ("drm: mxsfb: Fix crash when provided invalid DT bindings").
By default, driver maintainers are expected to pick up driver patches.
Exception is trivial patches by newcomers, to get them on board fast
(and avoid frustration when a maintainer isn't around). drm-misc and
Dave by default don't pick up anything.
-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: mxsfb_crtc: Fix the framebuffer misplacement
On Tue, Feb 7, 2017 at 11:31 PM, Marek Vasut wrote: > On 02/07/2017 11:15 PM, Daniel Vetter wrote: >> On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote: >>> On 02/02/2017 10:26 PM, Fabio Estevam wrote: From: Fabio Estevam Currently the framebuffer content is displayed with incorrect offsets in both the vertical and horizontal directions. The fbdev version of the driver does not show this problem. Breno Lima dumped the eLCDIF controller registers on both the drm and fbdev drivers and noticed that the VDCTRL3 register is configured incorrectly in the drm driver. The fbdev driver calculates the vertical and horizontal wait counts of the VDCTRL3 register by doing: back porch + sync length. Looking at the horizontal and vertical timing diagram from include/drm/drm_modes.h this value corresponds to: crtc_[hv]total - crtc_[hv]sync_start So fix the VDCTRL3 register setting accordingly so that the eLCDIF controller can properly show the framebuffer content in the correct position. Reported-by: Breno Lima Signed-off-by: Fabio Estevam >>> >>> Tested-by: Marek Vasut >> >> You're listed as maintainer in MAINTAINERS, replying with tested-by is >> super confusing. Did you pick this up and will do a pull request? > > No > >> Do you expect someone else to pick this up? > > The last patches for mxsfb were picked by you, but if you expect me to > pick the mxsfb patches through my own tree and then submit PR, I can do > that. I apply trivial patches as a welcoming gesture for new folks, but that's generally about it. Anyway, if you expect drm-misc maintainers to pick up stuff then you need to tell us, otherwise the patch will be lost. But then if you want mxsfb maintained in drm-misc I'd say better to get commit rights and join the club :-) Just ping on #dri-devel on freenode. -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: vc4: adapt to new behaviour of drm_crtc.c
On Wed, Feb 8, 2017 at 1:33 AM, Eric Anholt wrote:
> Andrzej Pietrasiewicz writes:
>
>> When drm_crtc_init_with_planes() was orignally added
>> (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
>> drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
>> being non-null. If that was the case, it modified primary->possible_crtcs.
>>
>> Then, when support for cursor planes was added
>> (fc1d3e44ef7c1db93384150fdbf8948dcf949f15 drm: Allow drivers to register
>> cursor planes with crtc), the same behaviour was implemented for cursor
>> planes.
>>
>> vc4_plane_init() since its inception has passed 0xff as "possible_crtcs"
>> parameter to drm_universal_plane_init(). With a change in drm_crtc.c
>> (7abc7d47510c75dd984380ebf819616e574c9604 drm: don't override
>> possible_crtcs for primary/cursor planes) passing 0xff results in primary's
>> and cursor's possible_crtcs set to 0xff. Consequently, these planes
>> (incorrectly) match many crtcs. This patch gives drm_ctc_init_with_planes()
>> a chance to properly set possible_crtcs for primary and cursor planes.
>>
>> Signed-off-by: Andrzej Pietrasiewicz
>
> Thanks for the detailed explanation!
>
> I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
> we don't pass the cursor into drm_crtc_init_with_planes()). I was also
> skeptical that there would be an actual visible bug, since our planes
> aren't really attached to the CRTCs other than the CRTC putting the
> plane's dlist entry into their dlist. However, I think if you stole
> CRTC 1's primary plane for CRTC 0 instead of CRTC 0's primary, the
> primary plane would appear on top of the overlays and cursor of CRTC 0.
>
> 7abc7d47510c75dd984380ebf819616e574c9604 appears only in 4.10-rc*. I
> think I want to add to the commit message:
>
> Fixes: 7abc7d47510c ("drm: don't override possible_crtcs for primary/cursor
> planes")
>
> and push this to drm-misc-fixes. drm-misc maintainers, can you confirm
> that this is the right way to handle it?
Yeah, I'll try to get the pr out still so it'll hit 4.10. Otherwise
it's going to be for 4.11. For safety maybe add a cc: stable # 4.10
-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: [bug report] drm: zte: add overlay plane support
Oh. Also this one: drivers/gpu/drm/zte/zx_plane.c:253 zx_vl_plane_atomic_update() warn: always true condition '(fmt >= 0) => (0-u32max >= 0)' regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm: zte: add overlay plane support
Hello Shawn Guo,
The patch 4e986d3705df: "drm: zte: add overlay plane support" from
Nov 16, 2016, leads to the following static checker warning:
drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup()
warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'
drivers/gpu/drm/zte/zx_plane.c
156 static void zx_vl_rsz_setup(struct zx_plane *zplane, uint32_t format,
157 u32 src_w, u32 src_h, u32 dst_w, u32 dst_h)
158 {
159 void __iomem *rsz = zplane->rsz;
160 u32 src_chroma_w = src_w;
161 u32 src_chroma_h = src_h;
162 u32 fmt;
^^^
163
164 /* Set up source and destination resolution */
165 zx_writel(rsz + RSZ_SRC_CFG, RSZ_VER(src_h - 1) | RSZ_HOR(src_w
- 1));
166 zx_writel(rsz + RSZ_DEST_CFG, RSZ_VER(dst_h - 1) |
RSZ_HOR(dst_w - 1));
167
168 /* Configure data format for VL RSZ */
169 fmt = zx_vl_rsz_get_fmt(format);
^^^
If fmt is -EINVAL then don't we just want to return anyway?
170 if (fmt >= 0)
171 zx_writel_mask(rsz + RSZ_VL_CTRL_CFG, RSZ_VL_FMT_MASK,
fmt);
172
173 /* Calculate Chroma height and width */
174 if (fmt == RSZ_VL_FMT_YCBCR420) {
175 src_chroma_w = src_w >> 1;
176 src_chroma_h = src_h >> 1;
177 } else if (fmt == RSZ_VL_FMT_YCBCR422) {
178 src_chroma_w = src_w >> 1;
179 }
180
181 /* Set up Luma and Chroma step registers */
182 zx_writel(rsz + RSZ_VL_LUMA_HOR, rsz_step_value(src_w, dst_w));
183 zx_writel(rsz + RSZ_VL_LUMA_VER, rsz_step_value(src_h, dst_h));
184 zx_writel(rsz + RSZ_VL_CHROMA_HOR, rsz_step_value(src_chroma_w,
dst_w));
185 zx_writel(rsz + RSZ_VL_CHROMA_VER, rsz_step_value(src_chroma_h,
dst_h));
186
187 zx_vl_rsz_set_update(zplane);
188 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #3 from garththei...@hotmail.com --- Created attachment 129409 --> https://bugs.freedesktop.org/attachment.cgi?id=129409&action=edit lspci output -- 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 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #2 from garththei...@hotmail.com --- GPU: XFX R9 390 -- 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 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #1 from garththei...@hotmail.com --- Created attachment 129408 --> https://bugs.freedesktop.org/attachment.cgi?id=129408&action=edit Xorg.log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=99710 Bug ID: 99710 Summary: [amdgpu R9 390] GPU hang when playing Hearthstone in Wine Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: garththei...@hotmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 129407 --> https://bugs.freedesktop.org/attachment.cgi?id=129407&action=edit DDEBUG_DUMP_#1 Repeatedly able to hang system running Hearthstone via Wine. The crash is never predictable but it often occurs right as the game is entering a multiplayer match or some short while after. Screen goes blank and system is unresponsive, no luck with Magic SysRq key in most cases. System Profile ... GPU: R9 390X Distro: Gentoo Kernel: Linux 4.9.8 KMD: amdgpu UMD: Mesa (git) -- 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] drm/mxsfb: fix pixel clock polarity
Dave, Marek,
On 2016-12-14 13:25, Marek Vasut wrote:
> On 12/14/2016 09:48 PM, Stefan Agner wrote:
>> The DRM subsystem specifies the pixel clock polarity from a
>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
>> the controller drives the data on pixel clocks falling edge.
>> That is the controllers DOTCLK_POL=0 (Default is data launched
>> at negative edge).
>>
>> Also change the data enable logic to be high active by default
>> and only change if explicitly requested via bus_flags. With
>> that defaults are:
>> - Data enable: high active
>> - Pixel clock polarity: controller drives data on negative edge
>>
>> Signed-off-by: Stefan Agner
>
> Acked-by: Marek Vasut
>
This seems not have made into drm-next yet. Not sure what the plan is
here, who will pick this up? There is also another fix on ML for the
same driver ("drm: mxsfb: Fix crash when provided invalid DT bindings").
--
Stefan
>> ---
>> Changes since v1:
>> - Improved comments/fixed typo
>>
>> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> index 3770dd2..5556e53 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>> @@ -195,9 +195,16 @@ static void mxsfb_crtc_mode_set_nofb(struct
>> mxsfb_drm_private *mxsfb)
>> vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
>> if (m->flags & DRM_MODE_FLAG_PVSYNC)
>> vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
>> -if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
>> +/* Make sure Data Enable is high active by default */
>> +if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
>> vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
>> -if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
>> +/*
>> + * DRM_BUS_FLAG_PIXDATA_ defines are controller centric,
>> + * controllers VDCTRL0_DOTCLK is display centric.
>> + * Drive on positive edge -> display samples on falling edge
>> + * DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
>> + */
>> +if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
>> vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
>>
>> writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/fsl-dcu: remove unneeded 'ret' assignment
On 2016-12-28 08:48, Fabio Estevam wrote:
> From: Fabio Estevam
>
> When devm_kzalloc() fails there is no need to assign an error code
> to the 'ret' variable as it will not be used after jumping to the
> 'err_node_put' label, so just remove the assignment.
>
> Signed-off-by: Fabio Estevam
Applied both to my drm-fsl-dcu tree.
--
Stefan
> ---
> drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> index 3194e54..2fbb7ee 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> @@ -72,10 +72,8 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev)
> return NULL;
>
> tcon = devm_kzalloc(dev, sizeof(*tcon), GFP_KERNEL);
> - if (!tcon) {
> - ret = -ENOMEM;
> + if (!tcon)
> goto err_node_put;
> - }
>
> ret = fsl_tcon_init_regmap(dev, tcon, np);
> if (ret) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/23] drm: fsl-dcu: use vblank hooks in struct drm_crtc_funcs
On 2017-02-07 01:16, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by: Shawn Guo
> Cc: Stefan Agner
Acked-by: Stefan Agner
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 26 ++
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 -
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> index deb57435cc89..cc4e944a1d3c 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> @@ -137,6 +137,30 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> drm_crtc *crtc)
> .mode_set_nofb = fsl_dcu_drm_crtc_mode_set_nofb,
> };
>
> +static int fsl_dcu_drm_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> + unsigned int value;
> +
> + regmap_read(fsl_dev->regmap, DCU_INT_MASK, &value);
> + value &= ~DCU_INT_MASK_VBLANK;
> + regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> +
> + return 0;
> +}
> +
> +static void fsl_dcu_drm_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> + unsigned int value;
> +
> + regmap_read(fsl_dev->regmap, DCU_INT_MASK, &value);
> + value |= DCU_INT_MASK_VBLANK;
> + regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> +}
> +
> static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> @@ -144,6 +168,8 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct
> drm_crtc *crtc)
> .page_flip = drm_atomic_helper_page_flip,
> .reset = drm_atomic_helper_crtc_reset,
> .set_config = drm_atomic_helper_set_config,
> + .enable_vblank = fsl_dcu_drm_crtc_enable_vblank,
> + .disable_vblank = fsl_dcu_drm_crtc_disable_vblank,
> };
>
> int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device *fsl_dev)
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index b59b816a1d7d..b5391c124c64 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -154,29 +154,6 @@ static irqreturn_t fsl_dcu_drm_irq(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> -static int fsl_dcu_drm_enable_vblank(struct drm_device *dev, unsigned int
> pipe)
> -{
> - struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> - unsigned int value;
> -
> - regmap_read(fsl_dev->regmap, DCU_INT_MASK, &value);
> - value &= ~DCU_INT_MASK_VBLANK;
> - regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> -
> - return 0;
> -}
> -
> -static void fsl_dcu_drm_disable_vblank(struct drm_device *dev,
> -unsigned int pipe)
> -{
> - struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> - unsigned int value;
> -
> - regmap_read(fsl_dev->regmap, DCU_INT_MASK, &value);
> - value |= DCU_INT_MASK_VBLANK;
> - regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
> -}
> -
> static void fsl_dcu_drm_lastclose(struct drm_device *dev)
> {
> struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> @@ -203,8 +180,6 @@ static void fsl_dcu_drm_lastclose(struct drm_device *dev)
> .load = fsl_dcu_load,
> .unload = fsl_dcu_unload,
> .irq_handler= fsl_dcu_drm_irq,
> - .enable_vblank = fsl_dcu_drm_enable_vblank,
> - .disable_vblank = fsl_dcu_drm_disable_vblank,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/6] Rockchip dw-mipi-dsi driver
Hi all This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of RK3399 is almost the same as RK3288, except a little bit of difference in phy clock controlling and port id selection register. These patches add RK3399 support and the power domain support. And these patches base on John Keeping's v3 patches[0], it fixes many bugs, they have been tested on rk3288 evb board. [0]: [01/24] https://patchwork.kernel.org/patch/9544089 [02/24] https://patchwork.kernel.org/patch/9544061 [03/24] https://patchwork.kernel.org/patch/9544065 [04/24] https://patchwork.kernel.org/patch/9544077 [05/24] https://patchwork.kernel.org/patch/9544033 [06/24] https://patchwork.kernel.org/patch/9544037 [07/24] https://patchwork.kernel.org/patch/9544029 [08/24] https://patchwork.kernel.org/patch/9544031 [09/24] https://patchwork.kernel.org/patch/9544083 [10/24] https://patchwork.kernel.org/patch/9544063 [11/24] https://patchwork.kernel.org/patch/9544085 [12/24] https://patchwork.kernel.org/patch/9544093 [13/24] https://patchwork.kernel.org/patch/9544081 [14/24] https://patchwork.kernel.org/patch/9544057 [15/24] https://patchwork.kernel.org/patch/9544079 [16/24] https://patchwork.kernel.org/patch/9544035 [17/24] https://patchwork.kernel.org/patch/9544105 [18/24] https://patchwork.kernel.org/patch/9544059 [21/24] https://patchwork.kernel.org/patch/9544009 [22/24] https://patchwork.kernel.org/patch/9544049 [23/24] https://patchwork.kernel.org/patch/9544055 [24/24] https://patchwork.kernel.org/patch/9544109 Changes in v6: - no need check phy_cfg_clk before enable/disable Changes in v5: - check the error of phy_cfg_clk in dw_mipi_dsi_bind Changes in v4: - remove the unrelated change Changes in v3: - base on John Keeping's patch series Chris Zhong (6): dt-bindings: add rk3399 support for dw-mipi-rockchip drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi drm/rockchip/dsi: dw-mipi: correct the coding style drm/rockchip/dsi: remove mode_valid function dt-bindings: add power domain node for dw-mipi-rockchip drm/rockchip/dsi: add dw-mipi power domain support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 156 - 2 files changed, 98 insertions(+), 65 deletions(-) -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/6] dt-bindings: add rk3399 support for dw-mipi-rockchip
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has additional phy config clock. Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 1753f0c..0f82568 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -5,10 +5,12 @@ Required properties: - #address-cells: Should be <1>. - #size-cells: Should be <0>. - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi". + "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference - clock(ref) and APB clock(pclk), as described in [1]. + clock(ref) and APB clock(pclk). For RK3399, a phy config clock + (phy_cfg) is additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
---
Changes in v6:
- no need check phy_cfg_clk before enable/disable
Changes in v5:
- check the error of phy_cfg_clk in dw_mipi_dsi_bind
Changes in v4:
- remove the unrelated change
Changes in v3:
- base on John Keeping's patch series
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 72 +-
1 file changed, 62 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 3f24333..8f60b89 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -29,9 +29,17 @@
#define DRIVER_NAME"dw-mipi-dsi"
-#define GRF_SOC_CON60x025c
-#define DSI0_SEL_VOP_LIT(1 << 6)
-#define DSI1_SEL_VOP_LIT(1 << 9)
+#define RK3288_GRF_SOC_CON60x025c
+#define RK3288_DSI0_SEL_VOP_LITBIT(6)
+#define RK3288_DSI1_SEL_VOP_LITBIT(9)
+
+#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_DSI0_SEL_VOP_LITBIT(0)
+#define RK3399_DSI1_SEL_VOP_LITBIT(4)
+
+/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
+#define RK3399_GRF_SOC_CON22 0x6258
+#define RK3399_GRF_DSI_MODE0x
#define DSI_VERSION0x00
#define DSI_PWR_UP 0x04
@@ -265,6 +273,11 @@ enum {
};
struct dw_mipi_dsi_plat_data {
+ u32 dsi0_en_bit;
+ u32 dsi1_en_bit;
+ u32 grf_switch_reg;
+ u32 grf_dsi0_mode;
+ u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
@@ -281,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk *phy_cfg_clk;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -425,6 +439,12 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
+ ret = clk_prepare_enable(dsi->phy_cfg_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+ return ret;
+ }
+
dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
VCO_RANGE_CON_SEL(vco) |
VCO_IN_CAP_CON_LOW |
@@ -481,17 +501,18 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to wait for phy lock state\n");
- return ret;
+ goto phy_init_end;
}
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & STOP_STATE_CLK_LANE, 1000,
PHY_STATUS_TIMEOUT_US);
- if (ret < 0) {
+ if (ret < 0)
dev_err(dsi->dev,
"failed to wait for phy clk lane stop state\n");
- return ret;
- }
+
+phy_init_end:
+ clk_disable_unprepare(dsi->phy_cfg_clk);
return ret;
}
@@ -960,6 +981,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
+ const struct dw_mipi_dsi_plat_data *pdata = dsi->pdata;
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
u32 val;
int ret;
@@ -985,6 +1007,10 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
+ if (pdata->grf_dsi0_mode_reg)
+ regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
+pdata->grf_dsi0_mode);
+
dw_mipi_dsi_phy_init(dsi);
dw_mipi_dsi_wait_for_two_frames(mode);
@@ -998,11 +1024,11 @@ static void dw_mipi_dsi_encoder_enable(struct
drm_encoder *encoder)
clk_disable_unprepare(dsi->pclk);
if (mux)
- val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+ val = pdata->dsi0_en_bit | (pdata->dsi0_en_bit << 16);
else
- val = DSI0_SEL_VOP_LIT << 16;
+ val = pdata->dsi0_en_bit << 16;
- regmap_write(dsi->grf_regmap, GRF_SOC_CON6, val);
+ regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi-
[PATCH v6 4/6] drm/rockchip/dsi: remove mode_valid function
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Signed-off-by: Chris Zhong
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 6795190..a2b4ec4 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -1077,23 +1075,8 @@ static int dw_mipi_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
- enum drm_mode_status mode_status = MODE_OK;
-
- if (dsi->pdata->mode_valid)
- mode_status = dsi->pdata->mode_valid(connector, mode);
-
- return mode_status;
-}
-
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
- .mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1164,33 +1147,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi
*dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
- if (mode->hdisplay > 0x7ff)
- return MODE_BAD_HVALUE;
-
- /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
- if (mode->vdisplay > 0x7ff)
- return MODE_BAD_VVALUE;
-
- return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
- .mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/6] dt-bindings: add power domain node for dw-mipi-rockchip
Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 0f82568..188f6f7 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -15,6 +15,9 @@ Required properties: - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. +Optional properties: +- power-domains: a phandle to mipi dsi power domain node. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/media/video-interfaces.txt -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/6] drm/rockchip/dsi: dw-mipi: correct the coding style
correct the coding style, according the checkpatch scripts
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 8f60b89..6795190 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -157,7 +157,6 @@
#define LPRX_TO_CNT(p) ((p) & 0x)
#define DSI_BTA_TO_CNT 0x8c
-
#define DSI_LPCLK_CTRL 0x94
#define AUTO_CLKLANE_CTRL BIT(1)
#define PHY_TXREQUESTCLKHS BIT(0)
@@ -223,11 +222,11 @@
#define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
-#define INPUT_DIVIDER(val) ((val - 1) & 0x7f)
+#define INPUT_DIVIDER(val) (((val) - 1) & 0x7f)
#define LOW_PROGRAM_EN 0
#define HIGH_PROGRAM_ENBIT(7)
-#define LOOP_DIV_LOW_SEL(val) ((val - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) (((val - 1) >> 5) & 0x1f)
+#define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
#define PLL_LOOP_DIV_ENBIT(5)
#define PLL_INPUT_DIV_EN BIT(4)
@@ -369,6 +368,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct
drm_encoder *encoder)
{
return container_of(encoder, struct dw_mipi_dsi, encoder);
}
+
static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
{
writel(val, dsi->base + reg);
@@ -380,7 +380,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
}
static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
-u8 test_data)
+ u8 test_data)
{
/*
* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
@@ -496,7 +496,6 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
-
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
@@ -571,7 +570,7 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
if (device->lanes > dsi->pdata->max_data_lanes) {
dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
- device->lanes);
+ device->lanes);
return -EINVAL;
}
@@ -1060,14 +1059,14 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
*encoder,
return 0;
}
-static struct drm_encoder_helper_funcs
+static const struct drm_encoder_helper_funcs
dw_mipi_dsi_encoder_helper_funcs = {
.enable = dw_mipi_dsi_encoder_enable,
.disable = dw_mipi_dsi_encoder_disable,
.atomic_check = dw_mipi_dsi_encoder_atomic_check,
};
-static struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
+static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -1103,7 +1102,7 @@ static void dw_mipi_dsi_drm_connector_destroy(struct
drm_connector *connector)
drm_connector_cleanup(connector);
}
-static struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
+static const struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = dw_mipi_dsi_drm_connector_destroy,
@@ -1113,7 +1112,7 @@ static struct drm_connector_funcs
dw_mipi_dsi_atomic_connector_funcs = {
};
static int dw_mipi_dsi_register(struct drm_device *drm,
- struct dw_mipi_dsi *dsi)
+ struct dw_mipi_dsi *dsi)
{
struct drm_encoder *encoder = &dsi->encoder;
struct drm_connector *connector = &dsi->connector;
@@ -1134,14 +1133,14 @@ static int dw_mipi_dsi_register(struct drm_device *drm,
drm_encoder_helper_add(&dsi->encoder,
&dw_mipi_dsi_encoder_helper_funcs);
ret = drm_encoder_init(drm, &dsi->encoder, &dw_mipi_dsi_encoder_funcs,
-DRM_MODE_ENCODER_DSI, NULL);
+ DRM_MODE_ENCODER_DSI, NULL);
if (ret) {
dev_err(dev, "Failed to initialize encoder with drm\n");
return ret;
}
drm_connector_helper_add(connector,
- &dw_mipi_dsi_connector_helper_funcs);
+&dw_mipi_dsi_connector_helper_funcs);
drm_connector_init(drm, &dsi->connector,
&dw_mipi_dsi_atomic_connector_funcs,
@@ -1
[PATCH v6 6/6] drm/rockchip/dsi: add dw-mipi power domain support
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a2b4ec4..2ee2317 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -293,6 +294,7 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
+ int dpms_mode;
unsigned int lane_mbps; /* per lane */
u32 channel;
u32 lanes;
@@ -960,6 +962,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+ if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+ return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
@@ -971,7 +976,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
drm_panel_unprepare(dsi->panel);
dw_mipi_dsi_disable(dsi);
+ pm_runtime_put(dsi->dev);
clk_disable_unprepare(dsi->pclk);
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
}
static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
@@ -987,11 +994,15 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
if (ret < 0)
return;
+ if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+ return;
+
if (clk_prepare_enable(dsi->pclk)) {
dev_err(dsi->dev, "%s: Failed to enable pclk\n", __func__);
return;
}
+ pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
dw_mipi_dsi_dpi_config(dsi, mode);
dw_mipi_dsi_packet_handler_config(dsi);
@@ -1027,6 +1038,7 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
+ dsi->dpms_mode = DRM_MODE_DPMS_ON;
}
static int
@@ -1194,6 +1206,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dsi->dev = dev;
dsi->pdata = pdata;
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
@@ -1274,6 +1287,8 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, dsi);
+ pm_runtime_enable(dev);
+
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1296,6 +1311,7 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct
device *master,
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
mipi_dsi_host_unregister(&dsi->dsi_host);
+ pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted
https://bugs.freedesktop.org/show_bug.cgi?id=99444 --- Comment #19 from Shmerl --- (In reply to Samuel Pitoiset from comment #16) > Does the following patch help? > > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=dfe111368d11aaffae7f8738c858c335cdec1e9d > > It actually fixes the glActiveTexture() errors but I still get rendering > issues on my side using the trace. > > Can you confirm by running the game directly? > Thanks! I built Mesa from source after that commit, and rendering issues in the menu are still present when game is run in Wine. -- 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 0/7] drm/rockchip: switch to drm_mm for support arm64 iommu
On 2017年02月07日 20:38, Thierry Reding wrote: On Tue, Feb 07, 2017 at 04:35:35PM +0800, Mark Yao wrote: Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and enable on ARM64" already landed, So drm/rockchip related patches [1] and [2] ready to landed, this series just rebase them to lastest drm-next. And fix some bugs for drm/rockchip drm_mm [0]: http://www.spinics.net/lists/arm-kernel/msg513781.html [1]: https://patchwork.kernel.org/patch/9196367 [2]: https://patchwork.kernel.org/patch/9196369 Changes in v2: Advices by Tomasz: add some fixes patches from chromeos project. I think those fixes should've been squashed into the patches that they fix. It's very unusual to merge patches upstream that are know to have been fixed already. Thierry Got it, I will fix them at v3 version. Thanks for review. -- Ｍark Yao ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm: scrambling support in drm layer
Hi Jani,
On 07-02-2017 13:35, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu wrote:
>>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>>> +{
>>> + u8 status;
>>> + int ret;
>>> +
>>> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>>> + if (ret < 0) {
>>> + DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
>>> + return false;
>>> + }
>>> +
>>> + return status & SCDC_SCRAMBLING_STATUS;
>> "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?
> What's the point in that?
>
> BR,
> Jani.
>
>
Sorry, I didn't see the SCDC_SCRAMBLING_STATUS is BIT(0). Anyway,
my intention was to return either 1 or 0 or else the value of the
"and" would be returned. I think in x86 the bool is char, what
could happen if SCDC_SCRAMBLING_STATUS was BIT(>7)? Does the cast
work as expected?
Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code
Hi Shawn, On Tue, 2017-02-07 at 17:16 +0800, Shawn Guo wrote: > From: Shawn Guo > > Core code already makes drm_driver.get_vblank_counter hook optional by > letting drm_vblank_no_hw_counter be the default implementation for the > function hook. So the drm_vblank_no_hw_counter assignment in the driver > code becomes redundant and can be removed now. > > Signed-off-by: Shawn Guo > Cc: Alexey Brodkin For ARC PGU part Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mxsfb: Implement drm_panel handling
On 02/01/2017 06:19 PM, Fabio Estevam wrote: > Currently when the 'power-supply' regulator is passed via device tree > it does not actually work since drm_panel_prepare()/drm_panel_enable() > are never called. > > Quoting Thierry Reding: "It should really call drm_panel_prepare() and > drm_panel_enable() while switching on the display pipeline and > drm_panel_disable(), followed by drm_panel_unprepare() while switching > off the display pipeline." > > So do as suggested, so that the 'power-supply' regulator can be functional. > > Reported-by: Breno Lima > Suggested-by: Thierry Reding > Signed-off-by: Fabio Estevam Tested-by: Marek Vasut -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
On 02/07/2017 11:15 PM, Daniel Vetter wrote: > On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote: >> On 02/02/2017 10:26 PM, Fabio Estevam wrote: >>> From: Fabio Estevam >>> >>> Currently the framebuffer content is displayed with incorrect offsets >>> in both the vertical and horizontal directions. >>> >>> The fbdev version of the driver does not show this problem. Breno Lima >>> dumped the eLCDIF controller registers on both the drm and fbdev drivers >>> and noticed that the VDCTRL3 register is configured incorrectly in the >>> drm driver. >>> >>> The fbdev driver calculates the vertical and horizontal wait counts >>> of the VDCTRL3 register by doing: back porch + sync length. >>> >>> Looking at the horizontal and vertical timing diagram from >>> include/drm/drm_modes.h this value corresponds to: >>> >>> crtc_[hv]total - crtc_[hv]sync_start >>> >>> So fix the VDCTRL3 register setting accordingly so that the eLCDIF >>> controller can properly show the framebuffer content in the correct >>> position. >>> >>> Reported-by: Breno Lima >>> Signed-off-by: Fabio Estevam >> >> Tested-by: Marek Vasut > > You're listed as maintainer in MAINTAINERS, replying with tested-by is > super confusing. Did you pick this up and will do a pull request? No > Do you expect someone else to pick this up? The last patches for mxsfb were picked by you, but if you expect me to pick the mxsfb patches through my own tree and then submit PR, I can do that. -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] arm64: dts: exynos: Move the clock-frequency property
Hi,
I think the subject is not really matching the real work. You are rather
removing the OF graph from DSI node.
On Mon, Feb 06, 2017 at 11:19:41AM +0900, Hoegeun Kwon wrote:
> The OF graph is not needed because the panel is a child of dsi. So
> removed the ports and moved burst, esc clock-frequency property to the
> top.
Keep the commit style and tense - imperative mode (see
submitting-patches.rstsubmitting-patches.rst), so last sentence could
look like:
"Remove the ports node abd move burst and esc clock frequency properties
to the parent (DSI node)."
The information which is missing is the answer for WHY? Why are you
doing this?
Does the patch depends on 1/5?
Best regards,
Krzysztof
>
> Signed-off-by: Hoegeun Kwon
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++--
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 6ce93a3..77ba238 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -298,23 +298,11 @@
> status = "okay";
> vddcore-supply = <&ldo6_reg>;
> vddio-supply = <&ldo7_reg>;
> + samsung,burst-clock-frequency = <51200>;
> + samsung,esc-clock-frequency = <1600>;
> samsung,pll-clock-frequency = <2400>;
> pinctrl-names = "default";
> pinctrl-0 = <&te_irq>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@1 {
> - reg = <1>;
> -
> - dsi_out: endpoint {
> - samsung,burst-clock-frequency = <51200>;
> - samsung,esc-clock-frequency = <1600>;
> - };
> - };
> - };
> };
>
> &hdmi {
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] drm: Add SCDC helpers
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides the
> symbolic names for the various registers defined in the specification.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Shashank Sharma
> ---
> Documentation/gpu/drm-kms-helpers.rst | 12
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_scdc_helper.c | 111
> include/drm/drm_scdc_helper.h | 132
> ++
> 4 files changed, 257 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
> create mode 100644 include/drm/drm_scdc_helper.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 03040aa..7592756 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -217,6 +217,18 @@ EDID Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_edid.c
> :export:
>
> +SCDC Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> + :doc: scdc helpers
> +
> +.. kernel-doc:: include/drm/drm_scdc_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> + :export:
> +
> Rectangle Utilities Reference
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 92de399..ad91cd9 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.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
> + drm_simple_kms_helper.o drm_modeset_helper.o \
> + drm_scdc_helper.o
>
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
> b/drivers/gpu/drm/drm_scdc_helper.c
> new file mode 100644
> index 000..fe0e121
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
> + *
> + * 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, sub license,
> + * 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 (including the
> + * next paragraph) 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 NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS 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.
> + */
> +
> +#include
> +
> +#include
> +
> +/**
> + * DOC: scdc helpers
> + *
> + * Status and Control Data Channel (SCDC) is a mechanism introduced by the
> + * HDMI 2.0 specification. It is a point-to-point protocol that allows the
> + * HDMI source and HDMI sink to exchange data. The same I2C interface that
> + * is used to access EDID serves as the transport mechanism for SCDC.
> + */
> +
> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
> +
> +/**
> + * drm_scdc_read - read a block of data from SCDC
> + * @adapter: I2C controller
> + * @offset: start offset of block to read
> + * @buffer: return location for the block to read
> + * @size: size of the block to read
> + *
> + * Reads a block of data from SCDC, starting at a given offset.
> + *
> + * Returns:
> + * The number of bytes read from SCDC or a negative error code on failure.
> + */
> +ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
> + size_t size)
> +{
> + struct i2c_msg msgs[2] = {
> + {
> + .addr = SCDC_I2C_SLAVE_ADDRESS,
> + .flags = 0,
> + .len = 1,
.len = sizeof(offset) ?
> +
Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
On 02/02/2017 10:26 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Currently the framebuffer content is displayed with incorrect offsets > in both the vertical and horizontal directions. > > The fbdev version of the driver does not show this problem. Breno Lima > dumped the eLCDIF controller registers on both the drm and fbdev drivers > and noticed that the VDCTRL3 register is configured incorrectly in the > drm driver. > > The fbdev driver calculates the vertical and horizontal wait counts > of the VDCTRL3 register by doing: back porch + sync length. > > Looking at the horizontal and vertical timing diagram from > include/drm/drm_modes.h this value corresponds to: > > crtc_[hv]total - crtc_[hv]sync_start > > So fix the VDCTRL3 register setting accordingly so that the eLCDIF > controller can properly show the framebuffer content in the correct > position. > > Reported-by: Breno Lima > Signed-off-by: Fabio Estevam Tested-by: Marek Vasut -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/6] drm/edid: check for HF-VSDB block
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> This patch implements a small function that finds if a
> given CEA db is hdmi-forum vendor specific data block
> or not.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
Best regards,
Jose Miguel Abreu
> ---
> drivers/gpu/drm/drm_edid.c | 15 +++
> include/linux/hdmi.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index baa6ccb..96d3e47 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3239,6 +3239,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> return hdmi_id == HDMI_IEEE_OUI;
> }
>
> +static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
> +{
> + unsigned int oui;
> +
> + if (cea_db_tag(db) != VENDOR_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) < 7)
> + return false;
> +
> + oui = db[3] << 16 | db[2] << 8 | db[1];
> +
> + return oui == HDMI_FORUM_IEEE_OUI;
> +}
> +
> #define for_each_cea_db(cea, i, start, end) \
> for ((i) = (start); (i) < (end) && (i) +
> cea_db_payload_len(&(cea)[(i)]) < (end); (i) +=
> cea_db_payload_len(&(cea)[(i)]) + 1)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index edbb4fc..d271ff2 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -35,6 +35,7 @@ enum hdmi_infoframe_type {
> };
>
> #define HDMI_IEEE_OUI 0x000c03
> +#define HDMI_FORUM_IEEE_OUI 0xc45dd8
> #define HDMI_INFOFRAME_HEADER_SIZE 4
> #define HDMI_AVI_INFOFRAME_SIZE13
> #define HDMI_SPD_INFOFRAME_SIZE25
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code
On Tue, Feb 07, 2017 at 12:42:15PM +0200, Laurent Pinchart wrote: > On an unrelated note, for security reasons we should try to make the driver > structure static, or at least move ops to a static structure. ITYM "const" not "static". "static" doesn't get you anything from a security point of view. "const" gets you write protection, so code can't modify the function pointers. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_hdmi_info, to
> reflect scdc support and capabilities in connected HDMI 2.0 sink.
> - Checks the HF-VSDB block for presence of SCDC, and marks it
> in scdc structure
> - If SCDC is present, checks if sink is capable of generating
> SCDC read request, and marks it in scdc structure.
>
> V2: Addressed review comments
> Thierry:
> - Fix typos in commit message and make abbreviation consistent
> across the commit message.
> - Change structure object name from hdmi_info -> hdmi
> - Fix typos and abbreviations in description of structure drm_hdmi_info
> end the description with a full stop.
> - Create a structure drm_scdc, and keep all information related to SCDC
> register set (supported, read request supported) etc in it.
>
> Ville:
> - Change rr -> read_request
> - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
> of HF-VSDB parsing can be kept in same function, in incremental
> patches.
>
> Reviewed-by: Thierry Reding
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c | 14 ++
> include/drm/drm_connector.h | 33 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 96d3e47..a487b80 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
> }
> EXPORT_SYMBOL(drm_default_rgb_quant_range);
>
> +static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> + const u8 *hf_vsdb)
> +{
> + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> +
> + if (hf_vsdb[6] & 0x80) {
BIT(7) ?
> + hdmi->scdc.supported = true;
> + if (hf_vsdb[6] & 0x40)
BIT(6) ?
> + hdmi->scdc.read_request = true;
> + }
> +}
> +
> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> const u8 *hdmi)
> {
> @@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
>
> if (cea_db_is_hdmi_vsdb(db))
> drm_parse_hdmi_vsdb_video(connector, db);
> + if (cea_db_is_hdmi_forum_vsdb(db))
> + drm_parse_hdmi_forum_vsdb(connector, db);
> }
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index e5e1edd..6d5304e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -87,6 +87,34 @@ enum subpixel_order {
> SubPixelVerticalRGB,
> SubPixelVerticalBGR,
> SubPixelNone,
> +
> +};
> +
> +/*
> + * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
> + *
> + * Provides SCDC register support and capabilities related information on a
> + * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
> + */
> +struct drm_scdc {
> + /**
> + * @supported: status control & data channel present.
> + */
> + bool supported;
> + /**
> + * @read_request: sink is capable of generating scdc read request.
> + */
> + bool read_request;
> +};
> +
> +/**
> + * struct drm_hdmi_info - runtime information about the connected HDMI sink
> + *
> + * Describes if a given display supports advanced HDMI 2.0 features.
> + * This information is available in CEA-861-F extension blocks (like
> HF-VSDB).
> + */
> +struct drm_hdmi_info {
> + struct drm_scdc scdc;
> };
>
> /**
> @@ -188,6 +216,11 @@ struct drm_display_info {
>* @cea_rev: CEA revision of the HDMI sink.
>*/
> u8 cea_rev;
> +
> + /**
> + * @hdmi: advance features of a HDMI sink.
Maybe change to the same general description you used above:
"Runtime information about the connected HDMI sink" ?
> + */
> + struct drm_hdmi_info hdmi;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm: scrambling support in drm layer
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340 MHz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scrambling support parsing HF-VSDB
> - A function to check scrambling status runtime using SCDC read.
> - Two functions to enable/disable scrambling using SCDC read/write.
> - Few new bools to reflect scrambling support and status.
>
> V2: Addressed review comments from Thierry, Ville and Dhinakaran
> Thierry:
> - Mhz -> MHz in comments and commit message.
> - i2c -> I2C in comments.
> - Fix the function documentations, keep in sync with drm_scdc_helper.c
> - drm_connector -> DRM connector.
> - Create structure for SCDC, and save scrambling status inside that,
> in a sub-structure.
> - Call this sub-structure scrambling instead of scr_info.
> - low_rates -> low_clocks in scrambling status structure.
> - Store the return value of I2C read/write and print the error code
> in case of failure.
>
> Thierry and Ville:
> - Move the scrambling enable/disable/query functions in
> drm_scdc_helper.c file.
> - Add drm_SCDC prefix for the functions.
> - Optimize the return statement from function
> drm_SCDC_check_scrambling_status.
>
> Ville:
> - Dont overwrite saved max TMDS clock value in display_info,
> if max tmds clock from HF-VSDB is not > 340 MHz.
> - drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
> - Remove dynamic tracking of SCDC status from DRM layer, force bool.
> - Program clock ratio bit also, while enabling scrambling.
>
> Dhinakaran:
> - Add a comment about *5000 while extracting max clock supported.
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_edid.c| 33 -
> drivers/gpu/drm/drm_scdc_helper.c | 100
> ++
> include/drm/drm_connector.h | 19
> include/drm/drm_edid.h| 6 ++-
> include/drm/drm_scdc_helper.h | 20
> 5 files changed, 176 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a487b80..dc85eb9 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #define version_greater(edid, maj, min) \
> (((edid)->version > (maj)) || \
> @@ -3805,13 +3806,43 @@ enum hdmi_quantization_range
> static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
> {
> - struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> + struct drm_display_info *display = &connector->display_info;
> + struct drm_hdmi_info *hdmi = &display->hdmi;
>
> if (hf_vsdb[6] & 0x80) {
> hdmi->scdc.supported = true;
> if (hf_vsdb[6] & 0x40)
> hdmi->scdc.read_request = true;
> }
> +
> + /*
> + * All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
> + * And as per the spec, three factors confirm this:
> + * * Availability of a HF-VSDB block in EDID (check)
> + * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
> + * * SCDC support available (let's check)
> + * Lets check it out.
> + */
> +
> + if (hf_vsdb[5]) {
> + /* max clock is 5000 KHz times block value */
> + u32 max_tmds_clock = hf_vsdb[5] * 5000;
> + struct drm_scdc *scdc = &hdmi->scdc;
> +
> + if (max_tmds_clock > 34) {
> + display->max_tmds_clock = max_tmds_clock;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> + }
> +
> + if (scdc->supported) {
> + scdc->scrambling.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
BIT(3) ?
> + scdc->scrambling.low_rates = true;
> + }
> + }
> }
>
> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
> b/drivers/gpu/drm/drm_scdc_helper.c
> index fe0e121..311f62e 100644
> --- a/drivers/gpu/drm/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -22,8 +22,10 @@
> */
>
> #include
> +#include
>
> #include
> +#include
>
> /**
> * DOC: scdc helpers
> @@ -109,3 +111,101 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8
> offset,
> return err;
> }
> EXPORT_SYMBOL(drm_scdc_write);
> +
> +/**
> + * drm_scdc_check_scrambling_status - what is status of scrambling?
> + * @adapter: I2C adapter for DDC channel
> + *
> + * Reads the scrambler status over SCDC, and checks the
> + * scrambling status.
> + *
> + *
Re: [PATCH v3 06/23] drm: armada: use vblank hooks in struct drm_crtc_funcs
On Tue, Feb 07, 2017 at 05:16:18PM +0800, Shawn Guo wrote: > From: Shawn Guo > > The vblank hooks in struct drm_driver are deprecated and only meant for > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks > in struct drm_crtc_funcs should be used instead. As the result, > functions armada_drm_crtc_enable[disable]_irq() can be static, although > they are moved around a bit to save forward declaration. > > The armada_crtc pointer array in struct armada_private is still kept in > there, because armada_debugfs.c still have reference to it. > > Signed-off-by: Shawn Guo > Cc: Russell King Acked-by: Russell King Thanks. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code
On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote: For: > drivers/gpu/drm/armada/armada_drv.c | 1 - Acked-by: Russell King -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #67 from Michel Dänzer --- The patch forces most buffers to GTT, which is clearly a bad idea with a dedicated GPU. Marek, what theory did you want to test with this patch? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info
On 7 February 2017 at 14:49, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: >> On 7 February 2017 at 14:29, Daniel Vetter wrote: >> > Noticed that everyone duplicates the same logic here and we could safe >> > a few lines per driver. Yay for lots of drivers to make such tiny >> > refactors worth-while! >> > >> > v2: Forgot to git add everything :( >> > >> Hmm afaict this patch inlines drm_fb_helper_release_fbi within >> drm_fb_helper_fini yet it is missing: >> - removal of the (now unused ?) drm_fb_helper_release_fbi >> - the leaks which now occur in the error paths. > > The error cleanup is a bit unobvious. The fbi is allocated during the > create/initial_fb callback, which is after a successful > framebuffer_init. The caller must be prepared to do a framebuffer_fini > (and so release_fbi will be handled if required) on failure or success. Silly me was assuming that drm_fb_helper_init() executes the fb_probe callback, while in fact it is drm_fb_helper_initial_config() that does so. I should read the docs more carefully ;-) Thanks gents, Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: > Except I have no way of knowing whether: a) you omitted a supply > because you don't (yet) care, b) the panel has a single supply and you > are using power-supply or c) the panel has multiple supplies and your > binding is wrong. > > I can only eliminate A if you list the supplies. Just need something > like "power-supply : see simple-panel.txt". I've still got to go read > the panel spec if I really want to check the binding. Just checked the panel datasheet at http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf and it lists two supplies: DVDD (Digital power supply) and AVDD (Analog power supply). Our dts was just providing a single 'power-supply' which referred to a GPIO enabled regulator that drives DVDD. So it seems we missed to pass AVDD (not software controlled in our case, but we need to describe it in dts anyway). Does this mean we cannot use simple-panel for this particular panel and we should add a separate driver for it? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc
On 2017年02月08日 00:14, Sean Paul wrote:
On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote:
drm crtc already has mode_fixup callback to can do mode check, but
We actually want to valid display mode on connector getmode time,
mode_fixup can't do it.
So add a private mode_valid callback to rockchip crtc, connectors can
check mode with this mode_valid callback.
There are some nasty layer violations happening in this set. You should use
mode_fixup if the crtc has limitations on the mode being set.
Sean
Mode_fixup can also check crtc limitations, but it's secondly time to
check display mode.
mode_fixup only works on drm_setcrtc or atomic_commit check, when
userspace get a series of display modes,
They don't know which display mode is bad before drm_setcrtc or
atomic_commit check, they need try,
but drm_setcrtc or atomic_commit check not only for display mode check,
means that userspace didn't have a sure
method to verify display mode.
So I try to add the mode_valid callback to connector getmodes time,
verify display mode before send mode list to userspace.
then userspace would get a good display mode list.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +
4 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..d10b15c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -39,6 +39,8 @@
struct rockchip_crtc_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
+ enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode);
};
struct rockchip_crtc_state {
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001..256fe73 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -853,9 +853,24 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
+static enum drm_mode_status
+vop_crtc_mode_valid(struct drm_crtc *crtc, const struct drm_display_mode *mode)
+{
+ struct vop *vop = to_vop(crtc);
+ const struct vop_data *vop_data = vop->data;
+
+ if (mode->hdisplay > vop_data->max_output.width)
+ return MODE_BAD_HVALUE;
+ if (mode->vdisplay > vop_data->max_output.height)
+ return MODE_BAD_VVALUE;
+
+ return MODE_OK;
+}
+
static const struct rockchip_crtc_funcs private_crtc_funcs = {
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
+ .mode_valid = vop_crtc_mode_valid,
};
static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 1dbc526..9e9dba1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -133,6 +133,11 @@ struct vop_win_data {
enum drm_plane_type type;
};
+struct vop_rect {
+ int width;
+ int height;
+};
+
struct vop_data {
const struct vop_reg_data *init_table;
unsigned int table_size;
@@ -140,6 +145,8 @@ struct vop_data {
const struct vop_intr *intr;
const struct vop_win_data *win;
unsigned int win_size;
+ struct vop_rect max_input;
+ struct vop_rect max_output;
};
/* interrupt define */
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 35c51f3..0c72361 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -132,6 +132,8 @@
};
static const struct vop_data rk3036_vop = {
+ .max_input = { 1920, 1080},
+ .max_output = { 1920, 1080},
.init_table = rk3036_vop_init_reg_table,
.table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
@@ -273,6 +275,13 @@
};
static const struct vop_data rk3288_vop = {
+ .max_input = { 4096, 8192},
+ /*
+* TODO: rk3288 have two vop, big one support 3840x2160,
+* little one only support 2560x1600.
+* Now force use 3840x2160.
+*/
+ .max_output = { 3840, 2160},
.init_table = rk3288_init_reg_table,
.table_size = ARRAY_SIZE(rk3288_init_reg_table),
.intr = &rk3288_vop_intr,
@@ -339,6 +348,8 @@
};
static const struct vop_data rk3399_vop_big = {
+ .max_input = { 4096, 8192},
+ .max_output = { 4096, 2160},
.init
Re: [patch] drm/radeon: remove some dead code
On 07/02/17 10:16 PM, Dan Carpenter wrote:
> If "rdev->bios" is NULL then we don't need to free it.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 00cfb5d2875f..04c0ed41374f 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -638,10 +638,8 @@ static bool radeon_acpi_vfct_bios(struct radeon_device
> *rdev)
>vhdr->ImageLength,
>GFP_KERNEL);
>
> - if (!rdev->bios) {
> - kfree(rdev->bios);
> + if (!rdev->bios)
> return false;
> - }
> return true;
Could be simplified further to
return rdev->bios != NULL;
or maybe
return !!rdev->bios;
Either way,
Reviewed-by: Michel Dänzer
--
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
Re: [PATCH] drm: vc4: adapt to new behaviour of drm_crtc.c
Andrzej Pietrasiewicz writes:
> When drm_crtc_init_with_planes() was orignally added
> (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
> drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
> being non-null. If that was the case, it modified primary->possible_crtcs.
>
> Then, when support for cursor planes was added
> (fc1d3e44ef7c1db93384150fdbf8948dcf949f15 drm: Allow drivers to register
> cursor planes with crtc), the same behaviour was implemented for cursor
> planes.
>
> vc4_plane_init() since its inception has passed 0xff as "possible_crtcs"
> parameter to drm_universal_plane_init(). With a change in drm_crtc.c
> (7abc7d47510c75dd984380ebf819616e574c9604 drm: don't override
> possible_crtcs for primary/cursor planes) passing 0xff results in primary's
> and cursor's possible_crtcs set to 0xff. Consequently, these planes
> (incorrectly) match many crtcs. This patch gives drm_ctc_init_with_planes()
> a chance to properly set possible_crtcs for primary and cursor planes.
>
> Signed-off-by: Andrzej Pietrasiewicz
Thanks for the detailed explanation!
I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
we don't pass the cursor into drm_crtc_init_with_planes()). I was also
skeptical that there would be an actual visible bug, since our planes
aren't really attached to the CRTCs other than the CRTC putting the
plane's dlist entry into their dlist. However, I think if you stole
CRTC 1's primary plane for CRTC 0 instead of CRTC 0's primary, the
primary plane would appear on top of the overlays and cursor of CRTC 0.
7abc7d47510c75dd984380ebf819616e574c9604 appears only in 4.10-rc*. I
think I want to add to the commit message:
Fixes: 7abc7d47510c ("drm: don't override possible_crtcs for primary/cursor
planes")
and push this to drm-misc-fixes. drm-misc maintainers, can you confirm
that this is the right way to handle it?
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/rockchip: gem: add mutex lock for drm mm
On 2017年02月07日 20:19, Thierry Reding wrote: On Tue, Feb 07, 2017 at 04:35:38PM +0800, Mark Yao wrote: drm_mm_insert_node_generic and drm_mm_remove_node may access same resource with list ops, it's not threads safe, so protect this context with mutex lock. Fix bug: [49451.856244] == [49451.856350] BUG: KASAN: wild-memory-access on address dead0108 [49451.856379] Write of size 8 by task Binder:218_4/683 [49451.856417] CPU: 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62 [49451.856443] Hardware name: Rockchip RK3399 Excavator Board edp (Android) (DT) [49451.856469] Call trace: [49451.856519] [] dump_backtrace+0x0/0x230 [49451.856556] [] show_stack+0x14/0x1c [49451.856592] [] dump_stack+0xa0/0xc8 [49451.856633] [] kasan_report+0x110/0x4dc [49451.856670] [] __asan_store8+0x24/0x7c [49451.856715] [] drm_mm_insert_node_generic+0x2dc/0x464 [49451.856760] [] rockchip_gem_iommu_map+0x60/0x158 [49451.856794] [] rockchip_gem_create_object+0x278/0x488 [49451.856827] [] rockchip_gem_create_with_handle+0x24/0x10c [49451.856862] [] rockchip_gem_create_ioctl+0x3c/0x50 [49451.856896] [] drm_ioctl+0x354/0x52c [49451.856939] [] do_vfs_ioctl+0x670/0x78c [49451.856976] [] SyS_ioctl+0x60/0x88 [49451.857009] [] el0_svc_naked+0x24/0x28 Change-Id: I2ea377aa9ca24f70c59e2d86f2a6ad5ccb9c0891 This is meaningless in an upstream tree. Please remove. Thierry Right, Forget to remove "Change-Id: " Thanks. -- Ｍark Yao ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: simplify exit path of a failed allocation of dsi_connector
Colin King writes:
> From: Colin Ian King
>
> If dsi_connector fails to allocate, the exit path via label 'fail'
> checks if connector is null, which it always is, so the cleanup
> that destroys connector is never going to be called. Hence the
> failure path can be more optimally performed by removing this
> and just returning ERR_PTR(-ENOMEM). This also removes the need
> to initialize connector to NULL, and we can also remove ret too.
>
> Detected by CoverityScan, CID#1399504 ("Logicall Dead Code")
>
> Signed-off-by: Colin Ian King
Reviewed and pushed to drm-misc-next. Thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/atomic: fix an error code in mode_fixup()
Having "ret" be a bool type works for everything except
ret = funcs->atomic_check(). The other functions all return zero on
error but ->atomic_check() returns negative error codes. We want to
propagate the error code but instead we return 1.
I found this bug with static analysis and I don't know if it affects
run time.
Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9a08445a7a7a..01d936b7be43 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -369,7 +369,7 @@ mode_fixup(struct drm_atomic_state *state)
struct drm_connector *connector;
struct drm_connector_state *conn_state;
int i;
- bool ret;
+ int ret;
for_each_crtc_in_state(state, crtc, crtc_state, i) {
if (!crtc_state->mode_changed &&
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
On Tue, Feb 7, 2017 at 12:55 PM, Fabio Estevam wrote: > Hi Rob, > > On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote: > >> No power supply(ies) for this panel? > > power-supply is mentioned in simple-panel.txt. > >>> +This binding is compatible with the simple-panel binding, which is >>> specified >>> +in simple-panel.txt in this directory. > > and this doc refers to simple-panel.txt. Isn't that enough? Except I have no way of knowing whether: a) you omitted a supply because you don't (yet) care, b) the panel has a single supply and you are using power-supply or c) the panel has multiple supplies and your binding is wrong. I can only eliminate A if you list the supplies. Just need something like "power-supply : see simple-panel.txt". I've still got to go read the panel spec if I really want to check the binding. > Seems like a common pattern for the other simple panel binding doc. We've gotten stricter about this. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
On Tue, Feb 07, 2017 at 10:44:59PM +0100, Marek Vasut wrote: > On 02/02/2017 10:26 PM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > Currently the framebuffer content is displayed with incorrect offsets > > in both the vertical and horizontal directions. > > > > The fbdev version of the driver does not show this problem. Breno Lima > > dumped the eLCDIF controller registers on both the drm and fbdev drivers > > and noticed that the VDCTRL3 register is configured incorrectly in the > > drm driver. > > > > The fbdev driver calculates the vertical and horizontal wait counts > > of the VDCTRL3 register by doing: back porch + sync length. > > > > Looking at the horizontal and vertical timing diagram from > > include/drm/drm_modes.h this value corresponds to: > > > > crtc_[hv]total - crtc_[hv]sync_start > > > > So fix the VDCTRL3 register setting accordingly so that the eLCDIF > > controller can properly show the framebuffer content in the correct > > position. > > > > Reported-by: Breno Lima > > Signed-off-by: Fabio Estevam > > Tested-by: Marek Vasut You're listed as maintainer in MAINTAINERS, replying with tested-by is super confusing. Did you pick this up and will do a pull request? Do you expect someone else to pick this up? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98634] Fedora/Ubuntu 32bits is not able to resume from hibernate
https://bugs.freedesktop.org/show_bug.cgi?id=98634 --- Comment #2 from Humberto Israel Perez Rodriguez --- the issue still occurs with the following configuration on SKL == Software == kernel version: 4.8.0-34-generic architecture : x86_64 os version: Ubuntu 16.10 os codename : yakkety kernel driver : i915 bios revision : 5.6 bios release date : 09/29/2016 == Graphic drivers == mesa : 12.0.3 xorg-xserver : 1.18.4 libva : 1.7.3-2 vaapi (intel-driver) : 1.7.3 intel-gpu-tools : 1.16-1 xserver-xorg-video-intel :2:2.99.917-git20160706 -- 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 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #66 from Captain Crutches --- I'm having the same results as everyone else with the patch: hanging seems diminished, FPS down noticeably (in multiplayer, not free play) but still playable. Patched mesa 17.0_rc2 R9 290 -- You are receiving this mail because: You are on the CC list for the bug. 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 1/3] dt-bindings: Document the dmas and dma-names properties for VC4 HDMI
From: Boris Brezillon These are optional, but necessary for HDMI audio support. Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt --- Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt index 34c7fddcea39..ca02d3e4db91 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt @@ -34,6 +34,9 @@ Optional properties for HDMI: - hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear as an interrupt/status bit in the HDMI controller itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt +- dmas:Should contain one entry pointing to the DMA channel used to + transfer audio data +- dma-names: Should contain "audio-rx" Required properties for DPI: - compatible: Should be "brcm,bcm2835-dpi" -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vc4: Add HDMI audio support
The HDMI encoder IP embeds all needed blocks to output audio, with a
custom DAI called MAI moving audio between the two parts of the HDMI
core. This driver now exposes a sound card to let users stream audio
to their display.
Using the hdmi-codec driver has been considered here, but MAI meant
having to significantly rework hdmi-codec, and it would have left
little shared code with the I2S mode anyway.
The encoder requires that the audio be SPDIF-formatted frames only,
which alsalib will format-convert for us.
This patch is the combined work of Eric Anholt (initial register setup
with a separate dmaengine driver and using simple-audio-card) and
Boris Brezillon (moving it all into HDMI, massive debug to get it
actually working), and which Eric has the permission to release.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/Kconfig| 4 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 494 -
drivers/gpu/drm/vc4/vc4_regs.h | 107 -
3 files changed, 603 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index e1517d07cb7d..973b4203c0b2 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -2,11 +2,15 @@ config DRM_VC4
tristate "Broadcom VC4 Graphics"
depends on ARCH_BCM2835 || COMPILE_TEST
depends on DRM
+ depends on SND && SND_SOC
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
select DRM_PANEL
+ select SND_PCM
+ select SND_PCM_ELD
+ select SND_SOC_GENERIC_DMAENGINE_PCM
select DRM_MIPI_DSI
help
Choose this option if you have a system that has a Broadcom
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 93d5994f3a04..56c285253ee5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -31,11 +31,27 @@
#include "linux/clk.h"
#include "linux/component.h"
#include "linux/i2c.h"
+#include "linux/of_address.h"
#include "linux/of_gpio.h"
#include "linux/of_platform.h"
+#include "linux/rational.h"
+#include "sound/dmaengine_pcm.h"
+#include "sound/pcm_drm_eld.h"
+#include "sound/pcm_params.h"
+#include "sound/soc.h"
#include "vc4_drv.h"
#include "vc4_regs.h"
+/* HDMI audio information */
+struct vc4_hdmi_audio {
+ struct snd_soc_card card;
+ struct snd_soc_dai_link link;
+ int samplerate;
+ int channels;
+ struct snd_dmaengine_dai_dma_data dma_data;
+ struct snd_pcm_substream *substream;
+};
+
/* General HDMI hardware state. */
struct vc4_hdmi {
struct platform_device *pdev;
@@ -43,6 +59,8 @@ struct vc4_hdmi {
struct drm_encoder *encoder;
struct drm_connector *connector;
+ struct vc4_hdmi_audio audio;
+
struct i2c_adapter *ddc;
void __iomem *hdmicore_regs;
void __iomem *hd_regs;
@@ -98,6 +116,10 @@ static const struct {
HDMI_REG(VC4_HDMI_SW_RESET_CONTROL),
HDMI_REG(VC4_HDMI_HOTPLUG_INT),
HDMI_REG(VC4_HDMI_HOTPLUG),
+ HDMI_REG(VC4_HDMI_MAI_CHANNEL_MAP),
+ HDMI_REG(VC4_HDMI_MAI_CONFIG),
+ HDMI_REG(VC4_HDMI_MAI_FORMAT),
+ HDMI_REG(VC4_HDMI_AUDIO_PACKET_CONFIG),
HDMI_REG(VC4_HDMI_RAM_PACKET_CONFIG),
HDMI_REG(VC4_HDMI_HORZA),
HDMI_REG(VC4_HDMI_HORZB),
@@ -108,6 +130,7 @@ static const struct {
HDMI_REG(VC4_HDMI_VERTB0),
HDMI_REG(VC4_HDMI_VERTB1),
HDMI_REG(VC4_HDMI_TX_PHY_RESET_CTL),
+ HDMI_REG(VC4_HDMI_TX_PHY_CTL0),
};
static const struct {
@@ -116,6 +139,9 @@ static const struct {
} hd_regs[] = {
HDMI_REG(VC4_HD_M_CTL),
HDMI_REG(VC4_HD_MAI_CTL),
+ HDMI_REG(VC4_HD_MAI_THR),
+ HDMI_REG(VC4_HD_MAI_FMT),
+ HDMI_REG(VC4_HD_MAI_SMP),
HDMI_REG(VC4_HD_VID_CTL),
HDMI_REG(VC4_HD_CSC_CTL),
HDMI_REG(VC4_HD_FRAME_COUNT),
@@ -215,6 +241,7 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
+ drm_edid_to_eld(connector, edid);
return ret;
}
@@ -300,7 +327,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder
*encoder,
struct drm_device *dev = encoder->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
u32 packet_id = frame->any.type - 0x80;
- u32 packet_reg = VC4_HDMI_GCP_0 + VC4_HDMI_PACKET_STRIDE * packet_id;
+ u32 packet_reg = VC4_HDMI_RAM_PACKET(packet_id);
uint8_t buffer[VC4_HDMI_PACKET_STRIDE];
ssize_t len, i;
int ret;
@@ -381,6 +408,24 @@ static void vc4_hdmi_set_spd_infoframe(struct drm_encoder
*encoder)
vc4_hdmi_write_infoframe(encoder, &frame);
}
+static void vc4_hdmi_set_audio_infoframe(struct drm_encoder *encoder)
+{
+ struct drm_device *drm = encoder->dev;
+ struct vc4_dev *vc4 = drm-
[PATCH 3/3] ARM: dts: bcm283x: Add HDMI audio related properties
From: Boris Brezillon Add the dmas and dma-names properties to support HDMI audio. Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt --- arch/arm/boot/dts/bcm283x.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index 9a44da190897..48a055d3f25e 100644 --- a/arch/arm/boot/dts/bcm283x.dtsi +++ b/arch/arm/boot/dts/bcm283x.dtsi @@ -491,6 +491,8 @@ clocks = <&clocks BCM2835_PLLH_PIX>, <&clocks BCM2835_CLOCK_HSM>; clock-names = "pixel", "hdmi"; + dmas = <&dma 17>; + dma-names = "audio-rx"; status = "disabled"; }; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98869] Electronic Super Joy graphic artefacts (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=98869 --- Comment #18 from cosiek...@o2.pl --- I have compiled couple of times. Here are my results. b7da8fa11d5c6ec71113350eed1959191a7d5990 working 84b961dd53a0509a6865d8417301838b34a40096 working e54b2e902aba22f697c0ba8622cd0a905f1edfff working 172bfdaa9e80342ade3f023f72d455d76713b866 not working f75a1084349f2332aa080d77acc175ddbe0ab886 not working -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Add TODO list
On Tue, Feb 07, 2017 at 06:51:13PM +0100, Thierry Reding wrote: > From: Thierry Reding > > This commit adds a TODO list to the GPU driver developer's guide. The > content was taken from the DRMJanitors page on the X.Org wiki: > > https://www.x.org/wiki/DRMJanitors/ > > The goal is to track a list of refactorings that would be nice to see > merged eventually. Sometimes these would be encountered during patch > review on the mailing list, and at other times one can come across > these while working in a specific area of code. > > Signed-off-by: Thierry Reding Sean also acked this on irc, merged to drm-misc-next. I'll update the wiki with the link. And I assume you'll follow up with a patch, cc: Noralf, with the tinydrm cleanups once that landed? Thanks, Daniel > --- > Documentation/gpu/index.rst| 1 + > Documentation/gpu/introduction.rst | 10 ++ > Documentation/gpu/todo.rst | 298 > + > 3 files changed, 309 insertions(+) > create mode 100644 Documentation/gpu/todo.rst > > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst > index 367d7c36b8e9..c9b08b02f57c 100644 > --- a/Documentation/gpu/index.rst > +++ b/Documentation/gpu/index.rst > @@ -13,6 +13,7 @@ Linux GPU Driver Developer's Guide > i915 > vga-switcheroo > vgaarbiter > + todo > > .. only:: subproject and html > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index eb284eb748ba..1f8bd5ef5f9d 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -50,3 +50,13 @@ names are "Notes" with information for dangerous or tricky > corner cases, > and "FIXME" where the interface could be cleaned up. > > Also read the :ref:`guidelines for the kernel documentation at large > `. > + > +Getting Started > +=== > + > +Developers interested in helping out with the DRM subsystem are very welcome. > +Often people will resort to sending in patches for various issues reported by > +checkpatch or sparse. We welcome such contributions. > + > +Anyone looking to kick it up a notch can find a list of janitorial tasks on > +the :ref:`TODO list `. > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > new file mode 100644 > index ..3813a2525ada > --- /dev/null > +++ b/Documentation/gpu/todo.rst > @@ -0,0 +1,298 @@ > +.. _todo: > + > += > +TODO list > += > + > +This section contains a list of smaller janitorial tasks in the kernel DRM > +graphics subsystem useful as newbie projects. Or for slow rainy days. > + > +Subsystem-wide refactorings > +=== > + > +De-midlayer drivers > +--- > + > +With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required > +to have a ``drm_bus`` structure set up. Drivers can directly set up the > +``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` > +and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` / > +``->unload`` callbacks and open-code the load/unload sequence properly, using > +the new two-stage ``drm_device`` setup/teardown. > + > +Once all existing drivers are converted we can also remove those bus support > +files for USB and platform devices. > + > +All you need is a GPU for a non-converted driver (currently almost all of > +them, but also all the virtual ones used by KVM, so everyone qualifies). > + > +Contact: Daniel Vetter, Thierry Reding, respective driver maintainers > + > +Switch from reference/unreference to get/put > + > + > +For some reason DRM core uses ``reference``/``unreference`` suffixes for > +refcounting functions, but kernel uses ``get``/``put`` (e.g. > +``kref_get``/``put()``). It would be good to switch over for consistency, and > +it's shorter. Needs to be done in 3 steps for each pair of functions: > + > +* Create new ``get``/``put`` functions, define the old names as compatibility > + wrappers > +* Switch over each file/driver using a cocci-generated spatch. > +* Once all users of the old names are gone, remove them. > + > +This way drivers/patches in the progress of getting merged won't break. > + > +Contact: Daniel Vetter > + > +Convert existing KMS drivers to atomic modesetting > +-- > + > +3.19 has the atomic modeset interfaces and helpers, so drivers can now be > +converted over. Modern compositors like Wayland or Surfaceflinger on Android > +really want an atomic modeset interface, so this is all about the bright > +future. > + > +There is a conversion guide for atomic and all you need is a GPU for a > +non-converted driver (again virtual HW drivers for KVM are still all > +suitable). > + > +As part of this drivers also need to convert to universal plane (which means > +exposing primary & cursor as proper plane objects). But that's much easier to > +do by direct
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Hi Rob, On Tue, Feb 7, 2017 at 4:49 PM, Rob Herring wrote: > No power supply(ies) for this panel? power-supply is mentioned in simple-panel.txt. >> +This binding is compatible with the simple-panel binding, which is specified >> +in simple-panel.txt in this directory. and this doc refers to simple-panel.txt. Isn't that enough? Seems like a common pattern for the other simple panel binding doc. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
On Thu, Feb 02, 2017 at 06:04:00PM -0200, Breno Lima wrote: > Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) > TFT with Touch-Panel, which can be supported by the simple panel driver. > > Data-sheet available at: > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf > > Signed-off-by: Breno Lima > --- > .../bindings/display/panel/sii,43wvf1g.txt | 7 ++ > drivers/gpu/drm/panel/panel-simple.c | 28 > ++ > 2 files changed, 35 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt > > diff --git a/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt > b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt > new file mode 100644 > index 000..bbbc49f > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt > @@ -0,0 +1,7 @@ > +Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel > + > +Required properties: > +- compatible: should be "sii,43wvf1g" > + No power supply(ies) for this panel? > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #65 from andrei.demin1...@gmail.com --- > Got it tested on another system with a rx470. >The hangs are mostly gone, but fps drops from 60+ to ~25. (btw the patch was >>applied to mesa 13.0.0.4) Yep, same. FPS drops from 60+ to 30-40 FPS, the hangs are mostly gone, but some still there. MESA 13.0.3 RX 480 -- You are receiving this mail because: You are on the CC list for the bug. 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/doc: Add TODO list
From: Thierry Reding This commit adds a TODO list to the GPU driver developer's guide. The content was taken from the DRMJanitors page on the X.Org wiki: https://www.x.org/wiki/DRMJanitors/ The goal is to track a list of refactorings that would be nice to see merged eventually. Sometimes these would be encountered during patch review on the mailing list, and at other times one can come across these while working in a specific area of code. Signed-off-by: Thierry Reding --- Documentation/gpu/index.rst| 1 + Documentation/gpu/introduction.rst | 10 ++ Documentation/gpu/todo.rst | 298 + 3 files changed, 309 insertions(+) create mode 100644 Documentation/gpu/todo.rst diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 367d7c36b8e9..c9b08b02f57c 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -13,6 +13,7 @@ Linux GPU Driver Developer's Guide i915 vga-switcheroo vgaarbiter + todo .. only:: subproject and html diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index eb284eb748ba..1f8bd5ef5f9d 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -50,3 +50,13 @@ names are "Notes" with information for dangerous or tricky corner cases, and "FIXME" where the interface could be cleaned up. Also read the :ref:`guidelines for the kernel documentation at large `. + +Getting Started +=== + +Developers interested in helping out with the DRM subsystem are very welcome. +Often people will resort to sending in patches for various issues reported by +checkpatch or sparse. We welcome such contributions. + +Anyone looking to kick it up a notch can find a list of janitorial tasks on +the :ref:`TODO list `. diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst new file mode 100644 index ..3813a2525ada --- /dev/null +++ b/Documentation/gpu/todo.rst @@ -0,0 +1,298 @@ +.. _todo: + += +TODO list += + +This section contains a list of smaller janitorial tasks in the kernel DRM +graphics subsystem useful as newbie projects. Or for slow rainy days. + +Subsystem-wide refactorings +=== + +De-midlayer drivers +--- + +With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required +to have a ``drm_bus`` structure set up. Drivers can directly set up the +``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` +and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` / +``->unload`` callbacks and open-code the load/unload sequence properly, using +the new two-stage ``drm_device`` setup/teardown. + +Once all existing drivers are converted we can also remove those bus support +files for USB and platform devices. + +All you need is a GPU for a non-converted driver (currently almost all of +them, but also all the virtual ones used by KVM, so everyone qualifies). + +Contact: Daniel Vetter, Thierry Reding, respective driver maintainers + +Switch from reference/unreference to get/put + + +For some reason DRM core uses ``reference``/``unreference`` suffixes for +refcounting functions, but kernel uses ``get``/``put`` (e.g. +``kref_get``/``put()``). It would be good to switch over for consistency, and +it's shorter. Needs to be done in 3 steps for each pair of functions: + +* Create new ``get``/``put`` functions, define the old names as compatibility + wrappers +* Switch over each file/driver using a cocci-generated spatch. +* Once all users of the old names are gone, remove them. + +This way drivers/patches in the progress of getting merged won't break. + +Contact: Daniel Vetter + +Convert existing KMS drivers to atomic modesetting +-- + +3.19 has the atomic modeset interfaces and helpers, so drivers can now be +converted over. Modern compositors like Wayland or Surfaceflinger on Android +really want an atomic modeset interface, so this is all about the bright +future. + +There is a conversion guide for atomic and all you need is a GPU for a +non-converted driver (again virtual HW drivers for KVM are still all +suitable). + +As part of this drivers also need to convert to universal plane (which means +exposing primary & cursor as proper plane objects). But that's much easier to +do by directly using the new atomic helper driver callbacks. + +Contact: Daniel Vetter, respective driver maintainers + +Convert early atomic drivers to async commit helpers + + +For the first year the atomic modeset helpers didn't support asynchronous / +nonblocking commits, and every driver had to hand-roll them. This is fixed +now, but there's still a pile of existing drivers that easily could be +converted over to the new infrastructure. + +One issue with the helpers
Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
Am Dienstag, den 07.02.2017, 17:45 +0100 schrieb Philipp Zabel:
> On Fri, 2017-02-03 at 10:52 -0200, Fabio Estevam wrote:
> > Hi Philipp,
> >
> > On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam wrote:
> > > From: Fabio Estevam
> > >
> > > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> > > regulator_set_voltage()") exposes the following probe issue:
> > >
> > > 63ff.tve supply dac not found, using dummy regulator
> > > imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops):
> > > -22
> > >
> > > When the 'dac' regulator is not passed in the device tree,
> > > devm_regulator_get() will return NULL and when regulator_set_voltage()
> > > is called it returns an error.
> > >
> > > Fix the issue by making the 'dac' regulator optional.
> > >
> > > Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> > > regulator_set_voltage()")
> > > Cc: # 4.8+
> > > Signed-off-by: Fabio Estevam
> >
> > Any comments, please?
>
> I've applied this to the fixes branch, since the current device trees
> don't have the regulator set.
>
> Is this really optional, though? It would be better to add the correct
> dac-supply to the device trees.
>
Why does the driver attempt to set the voltage? I guess the voltage is
fixed, even if it is hooked up to a configurable regulator.
Shouldn't we just remove the set_voltage call from the driver and make
sure the correct voltage is supplied by board level DT constraints?
Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 --- Comment #64 from freedesk...@bremsspur.org --- Got it tested on another system with a rx470. The hangs are mostly gone, but fps drops from 60+ to ~25. (btw the patch was applied to mesa 13.0.0.4) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
Hi Philipp, On Tue, Feb 7, 2017 at 2:45 PM, Philipp Zabel wrote: > I've applied this to the fixes branch, since the current device trees > don't have the regulator set. I have sent a patch providing the dac-supply regulator for imx53-qsb: https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=for-next&id=042f6d98261d8edc225237acaeb627aeadbf54ad > Is this really optional, though? It would be better to add the correct > dac-supply to the device trees. The other TVE user is imx53-mba53.dts, but as I don't have its schematics I am not able to provide the regulator for it. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm: mali-dp: add malidp_crtc_state struct
Add a custom CRTC state struct to enable storing driver-private per-CRTC
state. This patch only adds the base drm_crtc_state struct.
Signed-off-by: Mihail Atanassov
Reviewed-by: Brian Starkey
Acked-by: Liviu Dudau
---
Link to v2: https://lkml.org/lkml/2017/2/1/378
Link to v1: https://lkml.org/lkml/2017/2/1/203
Changes since v2:
- rebased and fixed conflicts
- s/MALIDP_DISP_FUNC_GAM/MALIDP_DISP_FUNC_GAMMA/g
- added MALIDP_GAMMA_LUT_SIZE #define + s/4096/MALIDP_GAMMA_LUT_SIZE/g in
malidp_crtc.c
- improved readability in a few places
Changes since v1:
- Moved unused variable to patch 2/2, where it is used.
drivers/gpu/drm/arm/malidp_crtc.c | 37 +++--
drivers/gpu/drm/arm/malidp_drv.h | 6 ++
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 08e6a71..ebf57e6 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -160,6 +160,39 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
+static struct drm_crtc_state *malidp_crtc_duplicate_state(struct drm_crtc
*crtc)
+{
+ struct malidp_crtc_state *state;
+
+ if (WARN_ON(!crtc->state))
+ return NULL;
+
+ state = kmalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, &state->base);
+
+ return &state->base;
+}
+
+static void malidp_crtc_reset(struct drm_crtc *crtc)
+{
+ struct malidp_crtc_state *cs = (crtc->state) ?
+ to_malidp_crtc_state(crtc->state) : NULL;
+
+ if (crtc->state)
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
+
+ kfree(cs);
+ cs = kzalloc(sizeof(*cs), GFP_KERNEL);
+ if (!cs)
+ return;
+
+ crtc->state = &cs->base;
+ crtc->state->crtc = crtc;
+}
+
static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
.mode_fixup = malidp_crtc_mode_fixup,
.enable = malidp_crtc_enable,
@@ -171,8 +204,8 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
- .reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .reset = malidp_crtc_reset,
+ .atomic_duplicate_state = malidp_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index dbc617c..558f4bf 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -47,6 +47,12 @@ struct malidp_plane_state {
#define to_malidp_plane(x) container_of(x, struct malidp_plane, base)
#define to_malidp_plane_state(x) container_of(x, struct malidp_plane_state,
base)
+struct malidp_crtc_state {
+ struct drm_crtc_state base;
+};
+
+#define to_malidp_crtc_state(x) container_of(x, struct malidp_crtc_state, base)
+
int malidp_de_planes_init(struct drm_device *drm);
void malidp_de_planes_destroy(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm: mali-dp: enable gamma support
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same table of coefficients for
all 3 curves on DP500.
Signed-off-by: Mihail Atanassov
Reviewed-by: Brian Starkey
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 130 --
drivers/gpu/drm/arm/malidp_drv.c | 52 +++
drivers/gpu/drm/arm/malidp_drv.h | 1 +
drivers/gpu/drm/arm/malidp_hw.c | 3 +
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_regs.h | 19 --
6 files changed, 196 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index ebf57e6..6a46520 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -21,6 +21,8 @@
#include "malidp_drv.h"
#include "malidp_hw.h"
+#define MALIDP_GAMMA_LUT_SIZE 4096
+
static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -82,6 +84,114 @@ static void malidp_crtc_disable(struct drm_crtc *crtc)
clk_disable_unprepare(hwdev->pxlclk);
}
+static const struct gamma_curve_segment {
+ u16 start;
+ u16 end;
+} segments[MALIDP_COEFFTAB_NUM_COEFFS] = {
+ /* sector 0 */
+ {0,0 }, {1,1 }, {2,2 }, {3,3 },
+ {4,4 }, {5,5 }, {6,6 }, {7,7 },
+ {8,8 }, {9,9 }, { 10, 10 }, { 11, 11 },
+ { 12, 12 }, { 13, 13 }, { 14, 14 }, { 15, 15 },
+ /* sector 1 */
+ { 16, 19 }, { 20, 23 }, { 24, 27 }, { 28, 31 },
+ /* sector 2 */
+ { 32, 39 }, { 40, 47 }, { 48, 55 }, { 56, 63 },
+ /* sector 3 */
+ { 64, 79 }, { 80, 95 }, { 96, 111 }, { 112, 127 },
+ /* sector 4 */
+ { 128, 159 }, { 160, 191 }, { 192, 223 }, { 224, 255 },
+ /* sector 5 */
+ { 256, 319 }, { 320, 383 }, { 384, 447 }, { 448, 511 },
+ /* sector 6 */
+ { 512, 639 }, { 640, 767 }, { 768, 895 }, { 896, 1023 },
+ { 1024, 1151 }, { 1152, 1279 }, { 1280, 1407 }, { 1408, 1535 },
+ { 1536, 1663 }, { 1664, 1791 }, { 1792, 1919 }, { 1920, 2047 },
+ { 2048, 2175 }, { 2176, 2303 }, { 2304, 2431 }, { 2432, 2559 },
+ { 2560, 2687 }, { 2688, 2815 }, { 2816, 2943 }, { 2944, 3071 },
+ { 3072, 3199 }, { 3200, 3327 }, { 3328, 3455 }, { 3456, 3583 },
+ { 3584, 3711 }, { 3712, 3839 }, { 3840, 3967 }, { 3968, 4095 },
+};
+
+#define DE_COEFTAB_DATA(a, b) a) & 0xfff) << 16) | (((b) & 0xfff)))
+
+static void malidp_generate_gamma_table(struct drm_property_blob *lut_blob,
+ u32 coeffs[MALIDP_COEFFTAB_NUM_COEFFS])
+{
+ struct drm_color_lut *lut = (struct drm_color_lut *)lut_blob->data;
+ int i;
+
+ for (i = 0; i < MALIDP_COEFFTAB_NUM_COEFFS; ++i) {
+ u32 a, b;
+ u32 delta_in;
+ u32 out_start, out_end;
+
+ delta_in = segments[i].end - segments[i].start;
+ /* DP has 12-bit internal precision for its LUTs. */
+ out_start = drm_color_lut_extract(lut[segments[i].start].green,
+ 12);
+ out_end = drm_color_lut_extract(lut[segments[i].end].green, 12);
+ a = (delta_in == 0) ?
+ 0 : ((out_end - out_start) * 256) / delta_in;
+ b = out_start;
+ coeffs[i] = DE_COEFTAB_DATA(a, b);
+ }
+}
+
+/*
+ * Check if there is a new gamma LUT and if it is of an acceptable size. Also,
+ * reject any LUTs that use distinct red, green, and blue curves.
+ */
+static int malidp_crtc_atomic_check_gamma(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct malidp_crtc_state *mc = to_malidp_crtc_state(state);
+ struct drm_color_lut *lut;
+ size_t lut_size;
+ int i;
+
+ if (!state->color_mgmt_changed)
+ return 0;
+
+ if (!state->gamma_lut)
+ return 0;
+
+ if (crtc->state->gamma_lut && (crtc->state->gamma_lut->base.id ==
+ state->gamma_lut->base.id))
+ return 0;
+
+ if (state->gamma_lut->length % sizeof(struct drm_color_lut))
+ return -EINVAL;
+
+ lut_size = state->gamma_lut->length / sizeof(struct drm_color_lut);
+ if (lut_size != MALIDP_GAMMA_LUT_SIZE)
+ return -EINVAL;
+
+ lut = (struct drm_color_lut *)state->gamma_lut->data;
+ for (i = 0; i < l
Re: [PATCH 0/2] drm/panel: Add support for the Sitronix ST7789V
On Tue, Feb 07, 2017 at 04:34:44PM +0100, Maxime Ripard wrote: > On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote: > > > > Den 06.02.2017 11.39, skrev Maxime Ripard: > > > Hi Noralf, > > > > > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote: > > > > Den 03.02.2017 10.59, skrev Maxime Ripard: > > > > > Hi, > > > > > > > > > > Here is an attempt at supporting the ST7789V LCD controller from > > > > > Sitronix. > > > > What happens if there's another panel driven by ST7789V that needs > > > > a different controller initialization? > > > You know those panels / controllers much better than I do, but why > > > would that be the case? > > > > > > > Maybe it's better to name it after the panel, not the controller. > > > I guess you could also use that panel directly without the controller? > > > > A controller can drive many different panels that can require different > > initializations. I faced that with staging/fbtft, when I wrote > > controller drivers having initialization code, and then came across > > displays with the same controller but with a different initialization. > > > > Trying to write controller drivers for these controllers is very > > difficult with all the possible permutations. On top of that we have > > those undocumented commands/registers. > > > > Some panels come with embedded controllers, in which case it makes > > sense to write a driver for the panel. > > > > But if the panel and controller are separate, then I don't know. Maybe > > the chance of coming across two uncompatible ST7789V and panel > > combinations in drm/panel is extremly low. > > Hmm, I see. If we ever come across that case, I guess we could just > add new optional properties to override the current sequence. I think if that ever happens it's probably best to split out ST7789V code into a helper library that has functions which take parameters. Then we can simply call those functions with parameters specific to a panel from a panel-specific driver. Trying to fit all that into device tree properties is likely going to end up being really messy. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional
On Fri, 2017-02-03 at 10:52 -0200, Fabio Estevam wrote:
> Hi Philipp,
>
> On Tue, Jan 3, 2017 at 5:11 PM, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> > regulator_set_voltage()") exposes the following probe issue:
> >
> > 63ff.tve supply dac not found, using dummy regulator
> > imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops):
> > -22
> >
> > When the 'dac' regulator is not passed in the device tree,
> > devm_regulator_get() will return NULL and when regulator_set_voltage()
> > is called it returns an error.
> >
> > Fix the issue by making the 'dac' regulator optional.
> >
> > Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> > regulator_set_voltage()")
> > Cc: # 4.8+
> > Signed-off-by: Fabio Estevam
>
> Any comments, please?
I've applied this to the fixes branch, since the current device trees
don't have the regulator set.
Is this really optional, though? It would be better to add the correct
dac-supply to the device trees.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
On Tue, Feb 07, 2017 at 04:44:42PM +0100, Maxime Ripard wrote: > Hi Thierry, > > On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote: > > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote: > > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that > > > can drive 18-bits 240x320 LCD displays. > > > > > > Signed-off-by: Maxime Ripard > > > --- > > > Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | > > > 36 > > > 1 file changed, 36 insertions(+), 0 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > > b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > > new file mode 100644 > > > index ..f70e6e9c54ed > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > > @@ -0,0 +1,36 @@ > > > +Sitronix ST7789V RGB panel with SPI control bus > > > + > > > +Required properties: > > > + - compatible: "sitronix,st7789v" > > > + - reg: Chip select of the panel on the SPI bus > > > + - reset-gpios: a GPIO phandle for the reset pin > > > > Shouldn't this have some sort of power supply? > > On the board I currently have, it's just tied to an always on > regulator, but you're right, I'll add it. Yes, we need to make sure to describe this from the panel's perspective to make sure that when other board designers hook things up differently we can still model it in DT. But you already knew that... Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB
On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:31 PM, Jose Abreu wrote:
> > Hi Shashank,
> >
> >
> >
> > On 06-02-2017 13:59, Shashank Sharma wrote:
> > > This patch does following:
> > > - Adds a new structure (drm_hdmi_info) in drm_display_info.
> > >This structure will be used to save and indicate if sink
> > >supports advanced HDMI 2.0 features
> > > - Adds another structure drm_scdc within drm_hdmi_info, to
> > >reflect scdc support and capabilities in connected HDMI 2.0 sink.
> > > - Checks the HF-VSDB block for presence of SCDC, and marks it
> > >in scdc structure
> > > - If SCDC is present, checks if sink is capable of generating
> > >SCDC read request, and marks it in scdc structure.
> > >
> > > V2: Addressed review comments
> > > Thierry:
> > > - Fix typos in commit message and make abbreviation consistent
> > >across the commit message.
> > > - Change structure object name from hdmi_info -> hdmi
> > > - Fix typos and abbreviations in description of structure drm_hdmi_info
> > >end the description with a full stop.
> > > - Create a structure drm_scdc, and keep all information related to SCDC
> > >register set (supported, read request supported) etc in it.
> > >
> > > Ville:
> > > - Change rr -> read_request
> > > - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
> > >of HF-VSDB parsing can be kept in same function, in incremental
> > >patches.
> > >
> > > Reviewed-by: Thierry Reding
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 14 ++
> > > include/drm/drm_connector.h | 33 +
> > > 2 files changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 96d3e47..a487b80 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
> > > }
> > > EXPORT_SYMBOL(drm_default_rgb_quant_range);
> > > +static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> > > + const u8 *hf_vsdb)
> > > +{
> > > + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> > > +
> > > + if (hf_vsdb[6] & 0x80) {
> > BIT(7) ?
> Yes, SCDC_present bit is bit 7, byte 6 in HF-VSDB. Am I missing something ?
> >
> > > + hdmi->scdc.supported = true;
> > > + if (hf_vsdb[6] & 0x40)
> > BIT(6) ?
> Yes, RR_Capable bit is bit 6, byte 6 in HF-VSDB.
I think what Jose was trying to say is that you should be using BIT(7)
instead of 0x80 and BIT(6) instead of 0x40. That said, I think either is
fine, but perhaps another idea would be to define macros for these. I
know that most (all?) of the EDID parsing code uses literals, so this is
consistent with existing code. Also usually code will be like:
if (hf_vsdb[X] & 0xYZ)
foo_supported = true;
So the meaning of the bit is easy to read from the context. I think
literals are fine in this case.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info
On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
> v3: Actually remove release_fbi (Sean, Emil, Chris) ...
>
> Cc: Chris Wilson
> Cc: Sean Paul
> Cc: Noralf Trønnes
> Cc: Emil Velikov
Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 +++
> drivers/gpu/drm/armada/armada_fbdev.c | 2 --
> drivers/gpu/drm/ast/ast_fb.c | 9 ++
> drivers/gpu/drm/bochs/bochs_fbdev.c | 5 +--
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 -
> drivers/gpu/drm/drm_fb_cma_helper.c | 3 +-
> drivers/gpu/drm/drm_fb_helper.c | 39
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 --
> drivers/gpu/drm/gma500/framebuffer.c | 9 ++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 --
> drivers/gpu/drm/i915/intel_fbdev.c| 5 +--
> drivers/gpu/drm/mgag200/mgag200_fb.c | 5 +--
> drivers/gpu/drm/msm/msm_fbdev.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 ---
> drivers/gpu/drm/qxl/qxl_fb.c | 5 +--
> drivers/gpu/drm/radeon/radeon_fb.c| 11 +++
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 ++
> drivers/gpu/drm/tegra/fb.c| 5 +--
> drivers/gpu/drm/udl/udl_fb.c | 5 +--
> drivers/gpu/drm/virtio/virtgpu_fb.c | 5 +--
> include/drm/drm_fb_helper.h | 4 ---
> 22 files changed, 39 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 838943d0962e..f4a2f1f0a6ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
> info = drm_fb_helper_alloc_fbi(helper);
> if (IS_ERR(info)) {
> ret = PTR_ERR(info);
> - goto out_unref;
> + goto out;
> }
>
> info->par = rfbdev;
> @@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
> ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd,
> gobj);
> if (ret) {
> DRM_ERROR("failed to initialize framebuffer %d\n", ret);
> - goto out_destroy_fbi;
> + goto out;
> }
>
> fb = &rfbdev->rfb.base;
> @@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>
> if (info->screen_base == NULL) {
> ret = -ENOSPC;
> - goto out_destroy_fbi;
> + goto out;
> }
>
> DRM_INFO("fb mappable at 0x%lX\n", info->fix.smem_start);
> @@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
> vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
> return 0;
>
> -out_destroy_fbi:
> - drm_fb_helper_release_fbi(helper);
> -out_unref:
> +out:
> if (abo) {
>
> }
> @@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev,
> struct amdgpu_fbdev *rfb
> struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
>
> drm_fb_helper_unregister_fbi(&rfbdev->helper);
> - drm_fb_helper_release_fbi(&rfbdev->helper);
>
> if (rfb->obj) {
> amdgpufb_destroy_pinned_object(rfb->obj);
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 78335100cbc3..7f184a52594e 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
>
> return 0;
> err_fb_setup:
> - drm_fb_helper_release_fbi(fbh);
> drm_fb_helper_fini(fbh);
> err_fb_helper:
> priv->fbdev = NULL;
> @@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
>
> if (fbh) {
> drm_fb_helper_unregister_fbi(fbh);
> - drm_fb_helper_release_fbi(fbh);
>
> drm_fb_helper_fini(fbh);
>
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index b085140fae95..f8421d23946a 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
> info = drm_fb_helper_alloc_fbi(helper);
> if (IS_ERR(info)) {
> ret = PTR_ERR(info);
> - goto err_free_vram;
> + goto out;
> }
> info->par = afbdev;
>
> ret = ast_framebuffer_init(dev, &afbdev->afb,
Re: [PATCH v2 4/6] drm: scrambling support in drm layer
Regards
Shashank
On 2/7/2017 4:44 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.
V2: Addressed review comments from Thierry, Ville and Dhinakaran
Thierry:
- Mhz -> MHz in comments and commit message.
- i2c -> I2C in comments.
- Fix the function documentations, keep in sync with drm_scdc_helper.c
- drm_connector -> DRM connector.
- Create structure for SCDC, and save scrambling status inside that,
in a sub-structure.
- Call this sub-structure scrambling instead of scr_info.
- low_rates -> low_clocks in scrambling status structure.
- Store the return value of I2C read/write and print the error code
in case of failure.
Thierry and Ville:
- Move the scrambling enable/disable/query functions in
drm_scdc_helper.c file.
- Add drm_SCDC prefix for the functions.
- Optimize the return statement from function
drm_SCDC_check_scrambling_status.
Ville:
- Dont overwrite saved max TMDS clock value in display_info,
if max tmds clock from HF-VSDB is not > 340 MHz.
- drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
- Remove dynamic tracking of SCDC status from DRM layer, force bool.
- Program clock ratio bit also, while enabling scrambling.
Dhinakaran:
- Add a comment about *5000 while extracting max clock supported.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c| 33 -
drivers/gpu/drm/drm_scdc_helper.c | 100 ++
include/drm/drm_connector.h | 19
include/drm/drm_edid.h| 6 ++-
include/drm/drm_scdc_helper.h | 20
5 files changed, 176 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a487b80..dc85eb9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#define version_greater(edid, maj, min) \
(((edid)->version > (maj)) || \
@@ -3805,13 +3806,43 @@ enum hdmi_quantization_range
static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
const u8 *hf_vsdb)
{
- struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+ struct drm_display_info *display = &connector->display_info;
+ struct drm_hdmi_info *hdmi = &display->hdmi;
if (hf_vsdb[6] & 0x80) {
hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+ /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+ if (hf_vsdb[5]) {
+ /* max clock is 5000 KHz times block value */
+ u32 max_tmds_clock = hf_vsdb[5] * 5000;
+ struct drm_scdc *scdc = &hdmi->scdc;
+
+ if (max_tmds_clock > 34) {
+ display->max_tmds_clock = max_tmds_clock;
+ DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+ display->max_tmds_clock);
+ }
+
+ if (scdc->supported) {
+ scdc->scrambling.supported = true;
+
+ /* Few sinks support scrambling for cloks < 340M */
+ if ((hf_vsdb[6] & 0x8))
BIT(3) ?
Yes, bit 3 is LTE_340Mcsc_scramble, indicating that the sink support
scrambling at rates below 340Mhz too, isn't it ?
+ scdc->scrambling.low_rates = true;
+ }
+ }
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/drm_scdc_helper.c
b/drivers/gpu/drm/drm_scdc_helper.c
index fe0e121..311f62e 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
*/
#include
+#include
#include
+#include
/**
* DOC: scdc helpers
@@ -109,3 +111,101 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8
offset,
return err;
}
EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambli
[PATCH] drm/fb-helper: Automatically clean up fb_info
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
v3: Actually remove release_fbi (Sean, Emil, Chris) ...
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Cc: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 +++
drivers/gpu/drm/armada/armada_fbdev.c | 2 --
drivers/gpu/drm/ast/ast_fb.c | 9 ++
drivers/gpu/drm/bochs/bochs_fbdev.c | 5 +--
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 -
drivers/gpu/drm/drm_fb_cma_helper.c | 3 +-
drivers/gpu/drm/drm_fb_helper.c | 39 ---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 --
drivers/gpu/drm/gma500/framebuffer.c | 9 ++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 --
drivers/gpu/drm/i915/intel_fbdev.c| 5 +--
drivers/gpu/drm/mgag200/mgag200_fb.c | 5 +--
drivers/gpu/drm/msm/msm_fbdev.c | 1 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 ---
drivers/gpu/drm/qxl/qxl_fb.c | 5 +--
drivers/gpu/drm/radeon/radeon_fb.c| 11 +++
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 ++
drivers/gpu/drm/tegra/fb.c| 5 +--
drivers/gpu/drm/udl/udl_fb.c | 5 +--
drivers/gpu/drm/virtio/virtgpu_fb.c | 5 +--
include/drm/drm_fb_helper.h | 4 ---
22 files changed, 39 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..f4a2f1f0a6ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto out_unref;
+ goto out;
}
info->par = rfbdev;
@@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd,
gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
- goto out_destroy_fbi;
+ goto out;
}
fb = &rfbdev->rfb.base;
@@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
if (info->screen_base == NULL) {
ret = -ENOSPC;
- goto out_destroy_fbi;
+ goto out;
}
DRM_INFO("fb mappable at 0x%lX\n", info->fix.smem_start);
@@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
return 0;
-out_destroy_fbi:
- drm_fb_helper_release_fbi(helper);
-out_unref:
+out:
if (abo) {
}
@@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev,
struct amdgpu_fbdev *rfb
struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
drm_fb_helper_unregister_fbi(&rfbdev->helper);
- drm_fb_helper_release_fbi(&rfbdev->helper);
if (rfb->obj) {
amdgpufb_destroy_pinned_object(rfb->obj);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 78335100cbc3..7f184a52594e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
return 0;
err_fb_setup:
- drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
err_fb_helper:
priv->fbdev = NULL;
@@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
if (fbh) {
drm_fb_helper_unregister_fbi(fbh);
- drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index b085140fae95..f8421d23946a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto err_free_vram;
+ goto out;
}
info->par = afbdev;
ret = ast_framebuffer_init(dev, &afbdev->afb, &mode_cmd, gobj);
if (ret)
- goto err_release_fbi;
+ goto out;
afbdev->sysram = sysram;
afbdev->size = size;
@@ -250,9 +250,7 @@ static int astfb_create(struct drm_fb_helper *helper,
retur
Re: [PATCH v5 2/6] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
On Sun, Feb 05, 2017 at 11:54:10AM +0800, Chris Zhong wrote:
> The vopb/vopl switch register of RK3399 mipi is different from RK3288,
> the default setting for mipi dsi mode is different too, so add a
> of_device_id structure to distinguish them, and make sure set the
> correct mode before mipi phy init.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Mark Yao
>
> ---
>
> Changes in v5:
> - check the error of phy_cfg_clk in dw_mipi_dsi_bind
>
> Changes in v4:
> - remove the unrelated change
>
> Changes in v3:
> - base on John Keeping's patch series
>
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 75
> +-
> 1 file changed, 65 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 45af890..7d337e2 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -29,9 +29,17 @@
>
> #define DRIVER_NAME"dw-mipi-dsi"
>
> -#define GRF_SOC_CON60x025c
> -#define DSI0_SEL_VOP_LIT(1 << 6)
> -#define DSI1_SEL_VOP_LIT(1 << 9)
> +#define RK3288_GRF_SOC_CON6 0x025c
> +#define RK3288_DSI0_SEL_VOP_LIT BIT(6)
> +#define RK3288_DSI1_SEL_VOP_LIT BIT(9)
> +
> +#define RK3399_GRF_SOC_CON19 0x6250
> +#define RK3399_DSI0_SEL_VOP_LIT BIT(0)
> +#define RK3399_DSI1_SEL_VOP_LIT BIT(4)
> +
> +/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
> +#define RK3399_GRF_SOC_CON22 0x6258
> +#define RK3399_GRF_DSI_MODE 0x
>
> #define DSI_VERSION 0x00
> #define DSI_PWR_UP 0x04
> @@ -265,6 +273,11 @@ enum {
> };
>
> struct dw_mipi_dsi_plat_data {
> + u32 dsi0_en_bit;
> + u32 dsi1_en_bit;
> + u32 grf_switch_reg;
> + u32 grf_dsi0_mode;
> + u32 grf_dsi0_mode_reg;
> unsigned int max_data_lanes;
> enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> struct drm_display_mode *mode);
> @@ -281,6 +294,7 @@ struct dw_mipi_dsi {
>
> struct clk *pllref_clk;
> struct clk *pclk;
> + struct clk *phy_cfg_clk;
>
> unsigned int lane_mbps; /* per lane */
> u32 channel;
> @@ -426,6 +440,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
> dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
> dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
>
> + if (dsi->phy_cfg_clk) {
You don't need this check any longer.
> + ret = clk_prepare_enable(dsi->phy_cfg_clk);
> + if (ret) {
> + dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
> + return ret;
> + }
> + }
> +
> dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
>VCO_RANGE_CON_SEL(vco) |
>VCO_IN_CAP_CON_LOW |
> @@ -479,17 +501,19 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
> if (ret < 0) {
> dev_err(dsi->dev, "failed to wait for phy lock state\n");
> - return ret;
> + goto phy_init_end;
> }
>
> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
>val, val & STOP_STATE_CLK_LANE, 1000,
>PHY_STATUS_TIMEOUT_US);
> - if (ret < 0) {
> + if (ret < 0)
> dev_err(dsi->dev,
> "failed to wait for phy clk lane stop state\n");
> - return ret;
> - }
> +
> +phy_init_end:
> + if (dsi->phy_cfg_clk)
Or this
> + clk_disable_unprepare(dsi->phy_cfg_clk);
>
> return ret;
> }
> @@ -965,6 +989,7 @@ static void dw_mipi_dsi_encoder_disable(struct
> drm_encoder *encoder)
> static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
> {
> struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
> + const struct dw_mipi_dsi_plat_data *pdata = dsi->pdata;
> int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
> u32 val;
>
> @@ -985,6 +1010,10 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> dw_mipi_dsi_dphy_interface_config(dsi);
> dw_mipi_dsi_clear_err(dsi);
>
> + if (pdata->grf_dsi0_mode_reg)
> + regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
> + pdata->grf_dsi0_mode);
> +
> dw_mipi_dsi_phy_init(dsi);
> dw_mipi_dsi_wait_for_two_frames(dsi);
>
> @@ -998,11 +1027,11 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> clk_disable_unprepare(dsi->pclk);
>
> if (mux)
> - val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
> + val = pdata->dsi0_en_bit | (pda
Re: [PATCH 1/2] drm/rockchip: support mode_valid for crtc
On Sun, Feb 05, 2017 at 03:36:36PM +0800, Mark Yao wrote:
> drm crtc already has mode_fixup callback to can do mode check, but
> We actually want to valid display mode on connector getmode time,
> mode_fixup can't do it.
>
> So add a private mode_valid callback to rockchip crtc, connectors can
> check mode with this mode_valid callback.
>
There are some nasty layer violations happening in this set. You should use
mode_fixup if the crtc has limitations on the mode being set.
Sean
> Signed-off-by: Mark Yao
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 ++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 +++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 +++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +
> 4 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index fb6226c..d10b15c 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -39,6 +39,8 @@
> struct rockchip_crtc_funcs {
> int (*enable_vblank)(struct drm_crtc *crtc);
> void (*disable_vblank)(struct drm_crtc *crtc);
> + enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
> +const struct drm_display_mode *mode);
> };
>
> struct rockchip_crtc_state {
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb5f001..256fe73 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -853,9 +853,24 @@ static void vop_crtc_disable_vblank(struct drm_crtc
> *crtc)
> spin_unlock_irqrestore(&vop->irq_lock, flags);
> }
>
> +static enum drm_mode_status
> +vop_crtc_mode_valid(struct drm_crtc *crtc, const struct drm_display_mode
> *mode)
> +{
> + struct vop *vop = to_vop(crtc);
> + const struct vop_data *vop_data = vop->data;
> +
> + if (mode->hdisplay > vop_data->max_output.width)
> + return MODE_BAD_HVALUE;
> + if (mode->vdisplay > vop_data->max_output.height)
> + return MODE_BAD_VVALUE;
> +
> + return MODE_OK;
> +}
> +
> static const struct rockchip_crtc_funcs private_crtc_funcs = {
> .enable_vblank = vop_crtc_enable_vblank,
> .disable_vblank = vop_crtc_disable_vblank,
> + .mode_valid = vop_crtc_mode_valid,
> };
>
> static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 1dbc526..9e9dba1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -133,6 +133,11 @@ struct vop_win_data {
> enum drm_plane_type type;
> };
>
> +struct vop_rect {
> + int width;
> + int height;
> +};
> +
> struct vop_data {
> const struct vop_reg_data *init_table;
> unsigned int table_size;
> @@ -140,6 +145,8 @@ struct vop_data {
> const struct vop_intr *intr;
> const struct vop_win_data *win;
> unsigned int win_size;
> + struct vop_rect max_input;
> + struct vop_rect max_output;
> };
>
> /* interrupt define */
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 35c51f3..0c72361 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -132,6 +132,8 @@
> };
>
> static const struct vop_data rk3036_vop = {
> + .max_input = { 1920, 1080},
> + .max_output = { 1920, 1080},
> .init_table = rk3036_vop_init_reg_table,
> .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
> .ctrl = &rk3036_ctrl_data,
> @@ -273,6 +275,13 @@
> };
>
> static const struct vop_data rk3288_vop = {
> + .max_input = { 4096, 8192},
> + /*
> + * TODO: rk3288 have two vop, big one support 3840x2160,
> + * little one only support 2560x1600.
> + * Now force use 3840x2160.
> + */
> + .max_output = { 3840, 2160},
> .init_table = rk3288_init_reg_table,
> .table_size = ARRAY_SIZE(rk3288_init_reg_table),
> .intr = &rk3288_vop_intr,
> @@ -339,6 +348,8 @@
> };
>
> static const struct vop_data rk3399_vop_big = {
> + .max_input = { 4096, 8192},
> + .max_output = { 4096, 2160},
> .init_table = rk3399_init_reg_table,
> .table_size = ARRAY_SIZE(rk3399_init_reg_table),
> .intr = &rk3399_vop_intr,
> @@ -358,6 +369,8 @@
> };
>
> static const struct vop_data rk3399_vop_lit = {
> + .max_input = { 4096, 8192},
> + .max_output = { 2560, 1600},
> .init_table = rk3399_init_reg_table,
> .table_size = ARRAY_SIZE(rk3399_init_reg_table),
> .intr = &rk3399_vop_intr,
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
>
Re: [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB
Regards
Shashank
On 2/7/2017 4:31 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.
V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.
Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.
Reviewed-by: Thierry Reding
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 14 ++
include/drm/drm_connector.h | 33 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96d3e47..a487b80 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
}
EXPORT_SYMBOL(drm_default_rgb_quant_range);
+static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+ struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+ if (hf_vsdb[6] & 0x80) {
BIT(7) ?
Yes, SCDC_present bit is bit 7, byte 6 in HF-VSDB. Am I missing something ?
+ hdmi->scdc.supported = true;
+ if (hf_vsdb[6] & 0x40)
BIT(6) ?
Yes, RR_Capable bit is bit 6, byte 6 in HF-VSDB.
+ hdmi->scdc.read_request = true;
+ }
+}
+
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
const u8 *hdmi)
{
@@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
+ if (cea_db_is_hdmi_forum_vsdb(db))
+ drm_parse_hdmi_forum_vsdb(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index e5e1edd..6d5304e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,34 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/*
+ * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
+ *
+ * Provides SCDC register support and capabilities related information on a
+ * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
+ */
+struct drm_scdc {
+ /**
+* @supported: status control & data channel present.
+*/
+ bool supported;
+ /**
+* @read_request: sink is capable of generating scdc read request.
+*/
+ bool read_request;
+};
+
+/**
+ * struct drm_hdmi_info - runtime information about the connected HDMI sink
+ *
+ * Describes if a given display supports advanced HDMI 2.0 features.
+ * This information is available in CEA-861-F extension blocks (like HF-VSDB).
+ */
+struct drm_hdmi_info {
+ struct drm_scdc scdc;
};
/**
@@ -188,6 +216,11 @@ struct drm_display_info {
* @cea_rev: CEA revision of the HDMI sink.
*/
u8 cea_rev;
+
+ /**
+* @hdmi: advance features of a HDMI sink.
Maybe change to the same general description you used above:
"Runtime information about the connected HDMI sink" ?
Actually the description I used in patch set 1, was similar, but this is
based on feedbacks from review set 1.
- Shashank
+*/
+ struct drm_hdmi_info hdmi;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info
On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote: > On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: > > On 7 February 2017 at 14:29, Daniel Vetter wrote: > > > Noticed that everyone duplicates the same logic here and we could safe > > > a few lines per driver. Yay for lots of drivers to make such tiny > > > refactors worth-while! > > > > > > v2: Forgot to git add everything :( > > > > > Hmm afaict this patch inlines drm_fb_helper_release_fbi within > > drm_fb_helper_fini yet it is missing: > > - removal of the (now unused ?) drm_fb_helper_release_fbi Uh right, somehow I forgot about that one ... > > - the leaks which now occur in the error paths. > > The error cleanup is a bit unobvious. The fbi is allocated during the > create/initial_fb callback, which is after a successful > framebuffer_init. The caller must be prepared to do a framebuffer_fini > (and so release_fbi will be handled if required) on failure or success. Yup, Chris is right, and I updated the kerneldoc to explain this. -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 v2 1/6] drm: Add SCDC helpers
Thanks for the review Jose, my comments inline.
Regards
Shashank
On 2/7/2017 4:24 PM, Jose Abreu wrote:
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
---
Documentation/gpu/drm-kms-helpers.rst | 12
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_scdc_helper.c | 111
include/drm/drm_scdc_helper.h | 132 ++
4 files changed, 257 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
create mode 100644 include/drm/drm_scdc_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:
+SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+ :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+ :export:
+
Rectangle Utilities Reference
=
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 92de399..ad91cd9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.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
+ drm_simple_kms_helper.o drm_modeset_helper.o \
+ drm_scdc_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..fe0e121
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * 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, sub license,
+ * 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 (including the
+ * next paragraph) 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 NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS 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.
+ */
+
+#include
+
+#include
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * The number of bytes read from SCDC or a negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = SCDC_I2C_SLAVE_ADDRESS,
+ .flags = 0,
+ .len = 1,
.len = sizeof(offset) ?
Technically correct, but wouldn't that mean that we are expecting to
have I2C offsets with length more than
Re: [PATCH] drm/rockchip: cdn-dp: fix cdn-dp complie warning
On Tue, Feb 07, 2017 at 09:34:01AM +0800, Mark Yao wrote:
> fix warning:
>
> drivers/gpu/drm/rockchip/cdn-dp-reg.c:632:24: warning:
> 'val[1]' may be used uninitialized in this function [-Wmaybe-uninitialized]
> msa_misc = 2 * val[0] + 32 * val[1] +
>
> Signed-off-by: Mark Yao
> ---
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index 3a5b8a4..319dbba 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -592,7 +592,7 @@ static int cdn_dp_get_msa_misc(struct video_info *video,
> struct drm_display_mode *mode)
> {
> u32 msa_misc;
> - u8 val[2];
> + u8 val[2] = {0};
Kind of a nit, but it would be better to add default cases to the switches
below so it's more
obvious which format/depth you consider the fallback.
Sean
>
> switch (video->color_fmt) {
> case PXL_RGB:
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/6] drm/i915: enable scrambling
Regards
Shashank
On 2/7/2017 3:51 PM, Jani Nikula wrote:
On Mon, 06 Feb 2017, Shashank Sharma wrote:
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
Throughout this series, but particularly in this patch, I'd prefer using
the term "sink" instead of "monitor" everywhere. The HDMI specifications
use source and sink almost exclusively.
BR,
Jani.
Sure, can be done.
- Shashank
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 26 +++
drivers/gpu/drm/i915/intel_drv.h | 11 ++
drivers/gpu/drm/i915/intel_hdmi.c | 70 +++
4 files changed, 109 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 495b789..cc85892 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7807,6 +7807,8 @@ enum {
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
#define TRANS_DDI_BFI_ENABLE (1<<4)
+#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
/* DisplayPort Transport Control */
#define _DP_TP_CTL_A 0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a9a670..cc7e091 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+ if (IS_GEMINILAKE(dev_priv))
+ temp = intel_hdmi_handle_source_scrambling(
+ intel_encoder,
+ &intel_crtc->config->base.adjusted_mode, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1845,6 +1850,21 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
+ if (IS_GEMINILAKE(dev_priv)) {
+ /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by monitor, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+ intel_hdmi_handle_monitor_scrambling(intel_encoder,
+ conn_state->connector,
+ intel_crtc->config,
+ true);
+ }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
* are ignored so nothing special needs to be done besides
* enabling the port.
@@ -1885,6 +1905,12 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder,
intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
}
+ if (type == INTEL_OUTPUT_HDMI) {
+ intel_hdmi_handle_monitor_scrambling(intel_encoder,
+ old_conn_state->connector,
+ intel_crtc->config, false);
+ }
+
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 393f243..300353c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -681,6 +681,9 @@ struct intel_crtc_state {
/* Gamma mode programmed on the pipe */
uint32_t gamma_mode;
+
+ /* HDMI scrambling status (monitor) */
+ bool scrambling;
};
struct vlv_wm_state {
@@ -1588,6 +1591,14 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_co
Re: [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > Cc: Chris Wilson > Cc: Sean Paul > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 --- > drivers/gpu/drm/armada/armada_fbdev.c | 2 -- > drivers/gpu/drm/ast/ast_fb.c | 9 +++-- > drivers/gpu/drm/bochs/bochs_fbdev.c | 5 + > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 - > drivers/gpu/drm/drm_fb_cma_helper.c | 3 +-- > drivers/gpu/drm/drm_fb_helper.c | 16 ++-- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 -- > drivers/gpu/drm/gma500/framebuffer.c | 9 +++-- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 3 +-- > drivers/gpu/drm/i915/intel_fbdev.c| 5 + > drivers/gpu/drm/mgag200/mgag200_fb.c | 5 + > drivers/gpu/drm/msm/msm_fbdev.c | 1 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 - > drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 > drivers/gpu/drm/qxl/qxl_fb.c | 5 + > drivers/gpu/drm/radeon/radeon_fb.c| 11 --- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 +++-- > drivers/gpu/drm/tegra/fb.c| 5 + > drivers/gpu/drm/udl/udl_fb.c | 5 + > drivers/gpu/drm/virtio/virtgpu_fb.c | 5 + > include/drm/drm_fb_helper.h | 4 > 22 files changed, 40 insertions(+), 81 deletions(-) > Driver changes look good. I'll echo Emil's comments about removing drm_fb_helper_release_fbi() from drm_fb_helper.c Sean -- 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 2/2] drm/panel: Add driver for sitronix ST7789V panel
On Mon, Feb 06, 2017 at 02:26:20PM +0100, Thierry Reding wrote:
> > +#define NUMARGS(...) (sizeof((int[]){__VA_ARGS__}) / sizeof(int))
> > +#define st7789v_send(ctx, cmd, ...)
> > \
> > + st7789v_write_command_data(ctx, cmd, NUMARGS(__VA_ARGS__), \
> > + ##__VA_ARGS__)
>
> How is this going to work if any of the arguments happens to not be an
> int? What if you have something like this:
>
> u8 value = 0x2;
>
> st7789v_write_command_data(ctx, cmd, 0x1, value, 0x3);
>
> ? Wouldn't that invalidly read "value" as int and wrongly increment the
> ap by three bytes too many?
Hmmm, it might be. I'll remove it, and take all your other changes
into account.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
Hi Thierry, On Mon, Feb 06, 2017 at 02:05:49PM +0100, Thierry Reding wrote: > On Fri, Feb 03, 2017 at 10:59:05AM +0100, Maxime Ripard wrote: > > The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that > > can drive 18-bits 240x320 LCD displays. > > > > Signed-off-by: Maxime Ripard > > --- > > Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 36 > > > > 1 file changed, 36 insertions(+), 0 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > new file mode 100644 > > index ..f70e6e9c54ed > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt > > @@ -0,0 +1,36 @@ > > +Sitronix ST7789V RGB panel with SPI control bus > > + > > +Required properties: > > + - compatible: "sitronix,st7789v" > > + - reg: Chip select of the panel on the SPI bus > > + - reset-gpios: a GPIO phandle for the reset pin > > Shouldn't this have some sort of power supply? On the board I currently have, it's just tied to an always on regulator, but you're right, I'll add it. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 9/9] drm/i915: Add render decompression support
On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes
> which parts of the main surface are compressed and which are not. The
> location of CCS is provided by userspace as just another plane with its
> own offset.
>
> Add the required stuff to validate the user provided AUX plane metadata
> and convert the user provided linear offset into something the hardware
> can consume.
>
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with NV12), so finding suitable
> offsets for both requires a bit of work. Assuming we still want keep
> playing tricks with the offsets. I've just gone with a dumb "search
> backward for suitable offsets" approach, which is far from optimal,
> but it works.
>
> Also not all planes will be capable of scanning out compressed surfaces,
> and eg. 90/270 degree rotation is not supported in combination with
> decompression either.
>
> This patch may contain work from at least the following people:
> * Vandana Kannan
> * Daniel Vetter
> * Ben Widawsky
>
> v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
>
> Cc: Paulo Zanoni
> Cc: Vandana Kannan
> Cc: Daniel Vetter
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 23
> drivers/gpu/drm/i915/intel_display.c | 234
> ---
> drivers/gpu/drm/i915/intel_pm.c | 29 -
> drivers/gpu/drm/i915/intel_sprite.c | 5 +
> 4 files changed, 274 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa77afa..6849ba93f1d9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6209,6 +6209,28 @@ enum {
> _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
> _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>
> +#define PLANE_AUX_DIST_1_A 0x701c0
> +#define PLANE_AUX_DIST_2_A 0x702c0
> +#define PLANE_AUX_DIST_1_B 0x711c0
> +#define PLANE_AUX_DIST_2_B 0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> +#define _PLANE_AUX_DIST_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane) \
> + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A 0x701c4
> +#define PLANE_AUX_OFFSET_2_A 0x702c4
> +#define PLANE_AUX_OFFSET_1_B 0x711c4
> +#define PLANE_AUX_OFFSET_2_B 0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> +#define _PLANE_AUX_OFFSET_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> +#define PLANE_AUX_OFFSET(pipe, plane) \
> + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
> +
> /* legacy palette */
> #define _LGC_PALETTE_A 0x4a000
> #define _LGC_PALETTE_B 0x4a800
> @@ -6433,6 +6455,7 @@ enum {
> # define CHICKEN3_DGMG_DONE_FIX_DISABLE (1 << 2)
>
> #define CHICKEN_PAR1_1 _MMIO(0x42080)
> +#define SKL_RC_HASH_OUTSIDE (1 << 15)
> #define DPA_MASK_VBLANK_SRD (1 << 15)
> #define FORCE_ARB_IDLE_PLANES (1 << 14)
> #define SKL_EDP_PSR_FIX_RDWRAP (1 << 3)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 38de9df0ec60..2236abebd8bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> return 128;
> else
> return 512;
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + if (plane == 1)
> + return 64;
> + /* fall through */
> case I915_FORMAT_MOD_Y_TILED:
> if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
> return 128;
> else
> return 512;
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + if (plane == 1)
> + return 64;
> + /* fall through */
> case I915_FORMAT_MOD_Yf_TILED:
> /*
>* Bspec seems to suggest that the Yf tile width would
> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct
> drm
Re: [PATCH v3 17/23] drm: rockchip: remove struct rockchip_crtc_funcs
On Tue, Feb 07, 2017 at 05:16:29PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> With the vblank hooks in struct drm_crtc_funcs, we do not need to
> maintain struct rockchip_crtc_funcs and the related registration
> functions. Remove them.
>
Reviewed-by: Sean Paul
> Signed-off-by: Shawn Guo
> Cc: Mark Yao
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 51
> -
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 14
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 ++---
> 3 files changed, 2 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 39243480c834..7719b9cd5b74 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -74,55 +74,6 @@ void rockchip_drm_dma_detach_device(struct drm_device
> *drm_dev,
> arm_iommu_detach_device(dev);
> }
>
> -int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
> - const struct rockchip_crtc_funcs *crtc_funcs)
> -{
> - int pipe = drm_crtc_index(crtc);
> - struct rockchip_drm_private *priv = crtc->dev->dev_private;
> -
> - if (pipe >= ROCKCHIP_MAX_CRTC)
> - return -EINVAL;
> -
> - priv->crtc_funcs[pipe] = crtc_funcs;
> -
> - return 0;
> -}
> -
> -void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
> -{
> - int pipe = drm_crtc_index(crtc);
> - struct rockchip_drm_private *priv = crtc->dev->dev_private;
> -
> - if (pipe >= ROCKCHIP_MAX_CRTC)
> - return;
> -
> - priv->crtc_funcs[pipe] = NULL;
> -}
> -
> -static int rockchip_drm_crtc_enable_vblank(struct drm_device *dev,
> -unsigned int pipe)
> -{
> - struct rockchip_drm_private *priv = dev->dev_private;
> - struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> -
> - if (crtc && priv->crtc_funcs[pipe] &&
> - priv->crtc_funcs[pipe]->enable_vblank)
> - return priv->crtc_funcs[pipe]->enable_vblank(crtc);
> -
> - return 0;
> -}
> -
> -static void rockchip_drm_crtc_disable_vblank(struct drm_device *dev,
> - unsigned int pipe)
> -{
> - struct rockchip_drm_private *priv = dev->dev_private;
> - struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> -
> - if (crtc && priv->crtc_funcs[pipe] &&
> - priv->crtc_funcs[pipe]->enable_vblank)
> - priv->crtc_funcs[pipe]->disable_vblank(crtc);
> -}
> -
> static int rockchip_drm_bind(struct device *dev)
> {
> struct drm_device *drm_dev;
> @@ -270,8 +221,6 @@ static void rockchip_drm_lastclose(struct drm_device *dev)
> .driver_features= DRIVER_MODESET | DRIVER_GEM |
> DRIVER_PRIME | DRIVER_ATOMIC,
> .lastclose = rockchip_drm_lastclose,
> - .enable_vblank = rockchip_drm_crtc_enable_vblank,
> - .disable_vblank = rockchip_drm_crtc_disable_vblank,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .gem_free_object_unlocked = rockchip_gem_free_object,
> .dumb_create= rockchip_gem_dumb_create,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index fb6226cf84b7..9f9bc959b108 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -31,16 +31,6 @@
> struct drm_device;
> struct drm_connector;
>
> -/*
> - * Rockchip drm private crtc funcs.
> - * @enable_vblank: enable crtc vblank irq.
> - * @disable_vblank: disable crtc vblank irq.
> - */
> -struct rockchip_crtc_funcs {
> - int (*enable_vblank)(struct drm_crtc *crtc);
> - void (*disable_vblank)(struct drm_crtc *crtc);
> -};
> -
> struct rockchip_crtc_state {
> struct drm_crtc_state base;
> int output_type;
> @@ -58,16 +48,12 @@ struct rockchip_crtc_state {
> struct rockchip_drm_private {
> struct drm_fb_helper fbdev_helper;
> struct drm_gem_object *fbdev_bo;
> - const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
> struct drm_atomic_state *state;
>
> struct list_head psr_list;
> spinlock_t psr_list_lock;
> };
>
> -int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
> - const struct rockchip_crtc_funcs *crtc_funcs);
> -void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
> int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
> struct device *dev);
> void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb5f001f51c3..ffee8d8c3794 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -853,11 +853,6 @@ stati
Re: [PATCH 0/2] drm/panel: Add support for the Sitronix ST7789V
On Mon, Feb 06, 2017 at 12:29:31PM +0100, Noralf Trønnes wrote: > > Den 06.02.2017 11.39, skrev Maxime Ripard: > > Hi Noralf, > > > > On Fri, Feb 03, 2017 at 07:48:51PM +0100, Noralf Trønnes wrote: > > > Den 03.02.2017 10.59, skrev Maxime Ripard: > > > > Hi, > > > > > > > > Here is an attempt at supporting the ST7789V LCD controller from > > > > Sitronix. > > > What happens if there's another panel driven by ST7789V that needs > > > a different controller initialization? > > You know those panels / controllers much better than I do, but why > > would that be the case? > > > > > Maybe it's better to name it after the panel, not the controller. > > I guess you could also use that panel directly without the controller? > > A controller can drive many different panels that can require different > initializations. I faced that with staging/fbtft, when I wrote > controller drivers having initialization code, and then came across > displays with the same controller but with a different initialization. > > Trying to write controller drivers for these controllers is very > difficult with all the possible permutations. On top of that we have > those undocumented commands/registers. > > Some panels come with embedded controllers, in which case it makes > sense to write a driver for the panel. > > But if the panel and controller are separate, then I don't know. Maybe > the chance of coming across two uncompatible ST7789V and panel > combinations in drm/panel is extremly low. Hmm, I see. If we ever come across that case, I guess we could just add new optional properties to override the current sequence. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 23/23] drm: zte: use vblank hooks in struct drm_crtc_funcs
On Tue, Feb 07, 2017 at 05:16:35PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> The functions are moved around to save forward declaration.
>
Reviewed-by: Sean Paul
> Signed-off-by: Shawn Guo
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
> drivers/gpu/drm/zte/zx_vou.c | 61
> +++-
> drivers/gpu/drm/zte/zx_vou.h | 3 --
> 3 files changed, 23 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index afd713a954c6..b24a70ba4b83 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -71,8 +71,6 @@ static void zx_drm_lastclose(struct drm_device *drm)
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
> DRIVER_ATOMIC,
> .lastclose = zx_drm_lastclose,
> - .enable_vblank = zx_vou_enable_vblank,
> - .disable_vblank = zx_vou_disable_vblank,
> .gem_free_object = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .dumb_create = drm_gem_cma_dumb_create,
> diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
> index cf92d675feaa..b500c8dd0d9d 100644
> --- a/drivers/gpu/drm/zte/zx_vou.c
> +++ b/drivers/gpu/drm/zte/zx_vou.c
> @@ -470,6 +470,27 @@ static void zx_crtc_atomic_flush(struct drm_crtc *crtc,
> .atomic_flush = zx_crtc_atomic_flush,
> };
>
> +static int zx_vou_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct zx_crtc *zcrtc = to_zx_crtc(crtc);
> + struct zx_vou_hw *vou = crtc_to_vou(crtc);
> + u32 int_frame_mask = zcrtc->bits->int_frame_mask;
> +
> + zx_writel_mask(vou->timing + TIMING_INT_CTRL, int_frame_mask,
> +int_frame_mask);
> +
> + return 0;
> +}
> +
> +static void zx_vou_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct zx_crtc *zcrtc = to_zx_crtc(crtc);
> + struct zx_vou_hw *vou = crtc_to_vou(crtc);
> +
> + zx_writel_mask(vou->timing + TIMING_INT_CTRL,
> +zcrtc->bits->int_frame_mask, 0);
> +}
> +
> static const struct drm_crtc_funcs zx_crtc_funcs = {
> .destroy = drm_crtc_cleanup,
> .set_config = drm_atomic_helper_set_config,
> @@ -477,6 +498,8 @@ static void zx_crtc_atomic_flush(struct drm_crtc *crtc,
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> + .enable_vblank = zx_vou_enable_vblank,
> + .disable_vblank = zx_vou_disable_vblank,
> };
>
> static int zx_crtc_init(struct drm_device *drm, struct zx_vou_hw *vou,
> @@ -553,44 +576,6 @@ static int zx_crtc_init(struct drm_device *drm, struct
> zx_vou_hw *vou,
> return 0;
> }
>
> -int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe)
> -{
> - struct drm_crtc *crtc;
> - struct zx_crtc *zcrtc;
> - struct zx_vou_hw *vou;
> - u32 int_frame_mask;
> -
> - crtc = drm_crtc_from_index(drm, pipe);
> - if (!crtc)
> - return 0;
> -
> - vou = crtc_to_vou(crtc);
> - zcrtc = to_zx_crtc(crtc);
> - int_frame_mask = zcrtc->bits->int_frame_mask;
> -
> - zx_writel_mask(vou->timing + TIMING_INT_CTRL, int_frame_mask,
> -int_frame_mask);
> -
> - return 0;
> -}
> -
> -void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe)
> -{
> - struct drm_crtc *crtc;
> - struct zx_crtc *zcrtc;
> - struct zx_vou_hw *vou;
> -
> - crtc = drm_crtc_from_index(drm, pipe);
> - if (!crtc)
> - return;
> -
> - vou = crtc_to_vou(crtc);
> - zcrtc = to_zx_crtc(crtc);
> -
> - zx_writel_mask(vou->timing + TIMING_INT_CTRL,
> -zcrtc->bits->int_frame_mask, 0);
> -}
> -
> void zx_vou_layer_enable(struct drm_plane *plane)
> {
> struct zx_crtc *zcrtc = to_zx_crtc(plane->state->crtc);
> diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
> index 57e3c31ee6a5..97d72bfce982 100644
> --- a/drivers/gpu/drm/zte/zx_vou.h
> +++ b/drivers/gpu/drm/zte/zx_vou.h
> @@ -61,9 +61,6 @@ struct vou_div_config {
> void zx_vou_config_dividers(struct drm_crtc *crtc,
> struct vou_div_config *configs, int num);
>
> -int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe);
> -void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe);
> -
> void zx_vou_layer_enable(struct drm_plane *plane);
> void zx_vou_layer_disable(struct drm_plane *plane);
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engine
Re: [PATCH v3 05/23] drm: malidp: use vblank hooks in struct drm_crtc_funcs
On Tue, Feb 07, 2017 at 05:16:17PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by: Shawn Guo
> Cc: Mali DP Maintainers
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_crtc.c | 21 +
> drivers/gpu/drm/arm/malidp_drv.c | 21 -
> 2 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index 08e6a71f5d05..bad4d80cb711 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -167,6 +167,25 @@ static int malidp_crtc_atomic_check(struct drm_crtc
> *crtc,
> .atomic_check = malidp_crtc_atomic_check,
> };
>
> +static int malidp_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> + struct malidp_hw_device *hwdev = malidp->dev;
> +
> + malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
> + hwdev->map.de_irq_map.vsync_irq);
> + return 0;
> +}
> +
> +static void malidp_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
> + struct malidp_hw_device *hwdev = malidp->dev;
> +
> + malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK,
> + hwdev->map.de_irq_map.vsync_irq);
> +}
> +
> static const struct drm_crtc_funcs malidp_crtc_funcs = {
> .destroy = drm_crtc_cleanup,
> .set_config = drm_atomic_helper_set_config,
> @@ -174,6 +193,8 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> + .enable_vblank = malidp_crtc_enable_vblank,
> + .disable_vblank = malidp_crtc_disable_vblank,
> };
>
> int malidp_crtc_init(struct drm_device *drm)
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index ca6ccd172de3..5dfcdb05c96e 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -111,25 +111,6 @@ static void malidp_atomic_commit_tail(struct
> drm_atomic_state *state)
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> -static int malidp_enable_vblank(struct drm_device *drm, unsigned int crtc)
> -{
> - struct malidp_drm *malidp = drm->dev_private;
> - struct malidp_hw_device *hwdev = malidp->dev;
> -
> - malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
> - hwdev->map.de_irq_map.vsync_irq);
> - return 0;
> -}
> -
> -static void malidp_disable_vblank(struct drm_device *drm, unsigned int pipe)
> -{
> - struct malidp_drm *malidp = drm->dev_private;
> - struct malidp_hw_device *hwdev = malidp->dev;
> -
> - malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK,
> - hwdev->map.de_irq_map.vsync_irq);
> -}
> -
> static int malidp_init(struct drm_device *drm)
> {
> int ret;
> @@ -213,8 +194,6 @@ static void malidp_lastclose(struct drm_device *drm)
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_PRIME,
> .lastclose = malidp_lastclose,
> - .enable_vblank = malidp_enable_vblank,
> - .disable_vblank = malidp_disable_vblank,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .dumb_create = drm_gem_cma_dumb_create,
> --
> 1.9.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code
On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> Core code already makes drm_driver.get_vblank_counter hook optional by
> letting drm_vblank_no_hw_counter be the default implementation for the
> function hook. So the drm_vblank_no_hw_counter assignment in the driver
> code becomes redundant and can be removed now.
>
> Signed-off-by: Shawn Guo
> Cc: Alexey Brodkin
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Russell King
> Cc: Boris Brezillon
> Cc: Inki Dae
> Cc: Stefan Agner
> Cc: Xinliang Liu
> Cc: Daniel Vetter
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Neil Armstrong
> Cc: Rob Clark
> Cc: Marek Vasut
> Cc: Ben Skeggs
> Cc: Tomi Valkeinen
> Cc: Laurent Pinchart
> Cc: Mark Yao
> Cc: Benjamin Gaignard
> Cc: Maxime Ripard
> Cc: Jyri Sarha
> Cc: Eric Anholt
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c| 1 -
> drivers/gpu/drm/arm/hdlcd_drv.c | 1 -
> drivers/gpu/drm/arm/malidp_drv.c| 1 -
For the HDLCD and Mali DP drivers:
Acked-by: Liviu Dudau
Thanks for doing this!
Liviu
> drivers/gpu/drm/armada/armada_drv.c | 1 -
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 1 -
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 -
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 -
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 -
> drivers/gpu/drm/i915/i915_irq.c | 1 -
> drivers/gpu/drm/imx/imx-drm-core.c | 1 -
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
> drivers/gpu/drm/meson/meson_drv.c | 1 -
> drivers/gpu/drm/msm/msm_drv.c | 1 -
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
> drivers/gpu/drm/omapdrm/omap_drv.c | 1 -
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
> drivers/gpu/drm/shmobile/shmob_drm_drv.c| 1 -
> drivers/gpu/drm/sti/sti_drv.c | 1 -
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 -
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 -
> drivers/gpu/drm/vc4/vc4_drv.c | 1 -
> drivers/gpu/drm/zte/zx_drm_drv.c| 1 -
> 25 files changed, 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 8d8344ed655e..1926b200e4cb 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -175,7 +175,6 @@ static int arcpgu_unload(struct drm_device *drm)
> .dumb_create = drm_gem_cma_dumb_create,
> .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> .dumb_destroy = drm_gem_dumb_destroy,
> - .get_vblank_counter = drm_vblank_no_hw_counter,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 4ce4f970920b..5d79e87f7421 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -278,7 +278,6 @@ static int hdlcd_debugfs_init(struct drm_minor *minor)
> .irq_preinstall = hdlcd_irq_preinstall,
> .irq_postinstall = hdlcd_irq_postinstall,
> .irq_uninstall = hdlcd_irq_uninstall,
> - .get_vblank_counter = drm_vblank_no_hw_counter,
> .enable_vblank = hdlcd_enable_vblank,
> .disable_vblank = hdlcd_disable_vblank,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 8b0672d4aee9..ca6ccd172de3 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -213,7 +213,6 @@ static void malidp_lastclose(struct drm_device *drm)
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> DRIVER_PRIME,
> .lastclose = malidp_lastclose,
> - .get_vblank_counter = drm_vblank_no_hw_counter,
> .enable_vblank = malidp_enable_vblank,
> .disable_vblank = malidp_disable_vblank,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> diff --git a/drivers/gpu/drm/armada/armada_drv.c
> b/drivers/gpu/drm/armada/armada_drv.c
> index 63f42d001f33..bb27892012de 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -87,7 +87,6 @@ static void armada_drm_lastclose(struct drm_device *dev)
>
> static struct drm_driver armada_drm_driver = {
> .lastclose = armada_drm_lastclose,
> - .get_vblank_counter = drm_vblank_no_hw_counter,
> .enable_vblank = armada_drm_enable_vblank,
> .disable_vblank = armada_drm_disable_vblank,
> .gem_free_object_unlocked = armada_gem_free_object,
> diff --git
Re: [PATCH libdrm] intel: avoid null pointer dereference
On Tuesday, 2017-02-07 15:59:32 +0100, Thomas H.P. Andersen wrote:
> On Fri, Feb 3, 2017 at 11:57 AM, Eric Engestrom
> wrote:
> >
> > On Thursday, 2017-02-02 23:57:29 +0100, Thomas Hindoe Paaboel Andersen
> > wrote:
> > > Introduced in 028715ee
> > >
> > > Move the dereference after the null check.
> >
> > Fixes: 028715ee707469189505 ("intel: Avoid the need for most overflow
> > checks by using a scratch page.")
> > Reviewed-by: Eric Engestrom
>
> Thanks. I do not have commit access. Can I ask you to push it?
I actually don't have commit access to libdrm either :)
Emil, can you push this (and the autogen patches)?
Cheers,
Eric
>
> >
> > > ---
> > > intel/intel_decode.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/intel/intel_decode.c b/intel/intel_decode.c
> > > index 803d202..2721ffd 100644
> > > --- a/intel/intel_decode.c
> > > +++ b/intel/intel_decode.c
> > > @@ -3899,7 +3899,7 @@ drm_intel_decode(struct drm_intel_decode *ctx)
> > > int ret;
> > > unsigned int index = 0;
> > > uint32_t devid;
> > > - int size = ctx->base_count * 4;
> > > + int size;
> > > void *temp;
> > >
> > > if (!ctx)
> > > @@ -3909,6 +3909,7 @@ drm_intel_decode(struct drm_intel_decode *ctx)
> > >* the batchbuffer. This lets us avoid a bunch of length
> > >* checking in statically sized packets.
> > >*/
> > > + size = ctx->base_count * 4;
> > > temp = malloc(size + 4096);
> > > memcpy(temp, ctx->base_data, size);
> > > memset((char *)temp + size, 0xd0, 4096);
> > > --
> > > 2.9.3
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm: scrambling support in drm layer
On Tue, 07 Feb 2017, Jose Abreu wrote:
> Hi Jani,
>
>
> On 07-02-2017 13:35, Jani Nikula wrote:
>> On Tue, 07 Feb 2017, Jose Abreu wrote:
+bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
+{
+ u8 status;
+ int ret;
+
+ ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
+ return false;
+ }
+
+ return status & SCDC_SCRAMBLING_STATUS;
>>> "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?
>> What's the point in that?
>>
>> BR,
>> Jani.
>>
>>
>
> Sorry, I didn't see the SCDC_SCRAMBLING_STATUS is BIT(0). Anyway,
> my intention was to return either 1 or 0 or else the value of the
> "and" would be returned. I think in x86 the bool is char, what
> could happen if SCDC_SCRAMBLING_STATUS was BIT(>7)? Does the cast
> work as expected?
The implicit type conversion works just fine.
BR,
Jani.
>
> Best regards,
> Jose Miguel Abreu
>
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] intel: avoid null pointer dereference
On Fri, Feb 3, 2017 at 11:57 AM, Eric Engestrom
wrote:
>
> On Thursday, 2017-02-02 23:57:29 +0100, Thomas Hindoe Paaboel Andersen wrote:
> > Introduced in 028715ee
> >
> > Move the dereference after the null check.
>
> Fixes: 028715ee707469189505 ("intel: Avoid the need for most overflow
> checks by using a scratch page.")
> Reviewed-by: Eric Engestrom
Thanks. I do not have commit access. Can I ask you to push it?
>
> > ---
> > intel/intel_decode.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/intel/intel_decode.c b/intel/intel_decode.c
> > index 803d202..2721ffd 100644
> > --- a/intel/intel_decode.c
> > +++ b/intel/intel_decode.c
> > @@ -3899,7 +3899,7 @@ drm_intel_decode(struct drm_intel_decode *ctx)
> > int ret;
> > unsigned int index = 0;
> > uint32_t devid;
> > - int size = ctx->base_count * 4;
> > + int size;
> > void *temp;
> >
> > if (!ctx)
> > @@ -3909,6 +3909,7 @@ drm_intel_decode(struct drm_intel_decode *ctx)
> >* the batchbuffer. This lets us avoid a bunch of length
> >* checking in statically sized packets.
> >*/
> > + size = ctx->base_count * 4;
> > temp = malloc(size + 4096);
> > memcpy(temp, ctx->base_data, size);
> > memset((char *)temp + size, 0xd0, 4096);
> > --
> > 2.9.3
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch v2] drm/i915/gvt/kvmgt: remove some dead code
"caps.buf" is always NULL here and "caps.size" is always zero. The code
is a no-op and can be removed.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..773a45aa18f8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -965,11 +965,6 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
sparse->areas[0].offset =
PAGE_ALIGN(vgpu_aperture_offset(vgpu));
sparse->areas[0].size = vgpu_aperture_sz(vgpu);
- if (!caps.buf) {
- kfree(caps.buf);
- caps.buf = NULL;
- caps.size = 0;
- }
break;
case VFIO_PCI_BAR3_REGION_INDEX ... VFIO_PCI_BAR5_REGION_INDEX:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info
On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote: > On 7 February 2017 at 14:29, Daniel Vetter wrote: > > Noticed that everyone duplicates the same logic here and we could safe > > a few lines per driver. Yay for lots of drivers to make such tiny > > refactors worth-while! > > > > v2: Forgot to git add everything :( > > > Hmm afaict this patch inlines drm_fb_helper_release_fbi within > drm_fb_helper_fini yet it is missing: > - removal of the (now unused ?) drm_fb_helper_release_fbi > - the leaks which now occur in the error paths. The error cleanup is a bit unobvious. The fbi is allocated during the create/initial_fb callback, which is after a successful framebuffer_init. The caller must be prepared to do a framebuffer_fini (and so release_fbi will be handled if required) on failure or success. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99136] Blood Effects Total War: Warhammer
https://bugs.freedesktop.org/show_bug.cgi?id=99136 --- Comment #21 from siyia --- (In reply to Gregor Münch from comment #20) > (In reply to Samuel Pitoiset from comment #19) > > Created attachment 129356 [details] > > no blood effects option (v 1.5) > > Maybe you need the Blood DLC? (just wild guess) > http://store.steampowered.com/app/404011/ If you have the blood dlc,can you reproduce the bug Gregor Münch? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code
On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> > If "caps.buf" is already NULL then it doesn't need to be freed or set to
> > NULL.
> >
> > Signed-off-by: Dan Carpenter
>
>
>
> > @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
> > unsigned int cmd,
> > sparse->areas[0].offset =
> > PAGE_ALIGN(vgpu_aperture_offset(vgpu));
> > sparse->areas[0].size = vgpu_aperture_sz(vgpu);
> > - if (!caps.buf) {
>
> Looking at the code around, the right thing would be to just remove the
> negation? This currently seems like a memory leak.
>
> > - kfree(caps.buf);
> > - caps.buf = NULL;
> > + if (!caps.buf)
> > caps.size = 0;
> > - }
>
> And quickly looking, the caps is pre-initialized but unused at this
> point, so the whole if could just be removed, right?
Hm... Duh. You're right. Let me resend.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats
Let's disable all scaling that requires horizontal decimation with
higher factor than 4, until we have better estimates of what we can
and can not do. However, 1 byte per pixel color format appear to work
Ok with all decimation factors.
When decimating horizontally by more that 4 the dss is not able to
fetch the data in burst mode. When this happens it is hard to tell if
there enough bandwidth. Despite what theory says this appears to be
true also for 16-bit color formats.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 5554b72..61daef6 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2506,6 +2506,25 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long
pclk, unsigned long lclk,
return -EINVAL;
}
+ if (*decim_x > 4 && color_mode_to_bpp(color_mode) > 8) {
+ /*
+ Let's disable all scaling that requires horizontal
+ decimation with higher factor than 4, until we have
+ better estimates of what we can and can not
+ do. However, 1 byte per pixel color format appear to
+ work Ok with all decimation factors.
+
+ When decimating horizontally by more that 4 the dss
+ is not able to fetch the data in burst mode. When
+ this happens it is hard to tell if there enough
+ bandwidth. Despite what theory says this appears to
+ be true also for 16-bit color formats.
+ */
+ DSSERR("Not enough bandwidth (x-decimation factor %d > 4)",
+ *decim_x);
+ return -EINVAL;
+ }
+
*core_clk = dispc.feat->calc_core_clk(pclk, in_width, in_height,
out_width, out_height, mem_to_mem);
return 0;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info
On 7 February 2017 at 14:29, Daniel Vetter wrote: > Noticed that everyone duplicates the same logic here and we could safe > a few lines per driver. Yay for lots of drivers to make such tiny > refactors worth-while! > > v2: Forgot to git add everything :( > Hmm afaict this patch inlines drm_fb_helper_release_fbi within drm_fb_helper_fini yet it is missing: - removal of the (now unused ?) drm_fb_helper_release_fbi - the leaks which now occur in the error paths. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5220a7b5e6ff..074ab22a7cf3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -781,7 +781,9 @@ EXPORT_SYMBOL(drm_fb_helper_init);
> * @fb_helper: driver-allocated fbdev helper
> *
> * A helper to alloc fb_info and the members cmap and apertures. Called
> - * by the driver within the fb_probe fb_helper callback function.
> + * by the driver within the fb_probe fb_helper callback function. Drivers do
> not
> + * need to release the allocated fb_info structure themselves, this is
> + * automatically done when calling drm_fb_helper_fini().
> *
> * RETURNS:
> * fb_info pointer if things went okay, pointer containing error code
> @@ -866,9 +868,19 @@ EXPORT_SYMBOL(drm_fb_helper_release_fbi);
I was expecting to see drm_fb_helper_release_fbi() removed.
> */
> void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
> {
> - if (!drm_fbdev_emulation)
> + struct fb_info *info;
> +
> + if (!drm_fbdev_emulation || !fb_helper)
> return;
>
> + info = fb_helper->fbdev;
> + if (info) {
> + if (info->cmap.len)
> + fb_dealloc_cmap(&info->cmap);
> + framebuffer_release(info);
> + }
> + fb_helper->fbdev = NULL;
> +
> mutex_lock(&kernel_fb_helper_lock);
> if (!list_empty(&fb_helper->kernel_fb_list)) {
> list_del(&fb_helper->kernel_fb_list);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code
On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> If "caps.buf" is already NULL then it doesn't need to be freed or set to
> NULL.
>
> Signed-off-by: Dan Carpenter
> @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
> unsigned int cmd,
> sparse->areas[0].offset =
> PAGE_ALIGN(vgpu_aperture_offset(vgpu));
> sparse->areas[0].size = vgpu_aperture_sz(vgpu);
> - if (!caps.buf) {
Looking at the code around, the right thing would be to just remove the
negation? This currently seems like a memory leak.
> - kfree(caps.buf);
> - caps.buf = NULL;
> + if (!caps.buf)
> caps.size = 0;
> - }
And quickly looking, the caps is pre-initialized but unused at this
point, so the whole if could just be removed, right?
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb-helper: Automatically clean up fb_info
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 ---
drivers/gpu/drm/armada/armada_fbdev.c | 2 --
drivers/gpu/drm/ast/ast_fb.c | 9 +++--
drivers/gpu/drm/bochs/bochs_fbdev.c | 5 +
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 -
drivers/gpu/drm/drm_fb_cma_helper.c | 3 +--
drivers/gpu/drm/drm_fb_helper.c | 16 ++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 --
drivers/gpu/drm/gma500/framebuffer.c | 9 +++--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 --
drivers/gpu/drm/i915/intel_fbdev.c| 5 +
drivers/gpu/drm/mgag200/mgag200_fb.c | 5 +
drivers/gpu/drm/msm/msm_fbdev.c | 1 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/qxl/qxl_fb.c | 5 +
drivers/gpu/drm/radeon/radeon_fb.c| 11 ---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 +++--
drivers/gpu/drm/tegra/fb.c| 5 +
drivers/gpu/drm/udl/udl_fb.c | 5 +
drivers/gpu/drm/virtio/virtgpu_fb.c | 5 +
include/drm/drm_fb_helper.h | 4
22 files changed, 39 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..f4a2f1f0a6ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto out_unref;
+ goto out;
}
info->par = rfbdev;
@@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd,
gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
- goto out_destroy_fbi;
+ goto out;
}
fb = &rfbdev->rfb.base;
@@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
if (info->screen_base == NULL) {
ret = -ENOSPC;
- goto out_destroy_fbi;
+ goto out;
}
DRM_INFO("fb mappable at 0x%lX\n", info->fix.smem_start);
@@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
return 0;
-out_destroy_fbi:
- drm_fb_helper_release_fbi(helper);
-out_unref:
+out:
if (abo) {
}
@@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev,
struct amdgpu_fbdev *rfb
struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
drm_fb_helper_unregister_fbi(&rfbdev->helper);
- drm_fb_helper_release_fbi(&rfbdev->helper);
if (rfb->obj) {
amdgpufb_destroy_pinned_object(rfb->obj);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 78335100cbc3..7f184a52594e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
return 0;
err_fb_setup:
- drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
err_fb_helper:
priv->fbdev = NULL;
@@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
if (fbh) {
drm_fb_helper_unregister_fbi(fbh);
- drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index b085140fae95..f8421d23946a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto err_free_vram;
+ goto out;
}
info->par = afbdev;
ret = ast_framebuffer_init(dev, &afbdev->afb, &mode_cmd, gobj);
if (ret)
- goto err_release_fbi;
+ goto out;
afbdev->sysram = sysram;
afbdev->size = size;
@@ -250,9 +250,7 @@ static int astfb_create(struct drm_fb_helper *helper,
return 0;
-err_release_fbi:
- drm_fb_helper_re
Re: [PATCH 1/2] drm/fb-helper: Explain unload sequence a bit better
On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote: > While reviewing Chris' patches to properly cancel our async workers I > checked that this happens after the fbdev is already unregistered. > That's the case, but I found a small gap in our docs, fill that in. > > Note that I don't explain what release_fbi does, because that function > will disappear in the next patch ... > > Cc: Chris Wilson > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/fb-helper: Automatically clean up fb_info
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 ---
drivers/gpu/drm/armada/armada_fbdev.c | 2 --
drivers/gpu/drm/ast/ast_fb.c | 9 +++--
drivers/gpu/drm/bochs/bochs_fbdev.c | 5 +
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 -
drivers/gpu/drm/drm_fb_cma_helper.c | 3 +--
drivers/gpu/drm/drm_fb_helper.c | 16 ++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 --
drivers/gpu/drm/gma500/framebuffer.c | 9 +++--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c| 5 +
drivers/gpu/drm/mgag200/mgag200_fb.c | 5 +
drivers/gpu/drm/msm/msm_fbdev.c | 1 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 -
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/qxl/qxl_fb.c | 5 +
drivers/gpu/drm/radeon/radeon_fb.c| 11 ---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 9 +++--
drivers/gpu/drm/tegra/fb.c| 5 +
drivers/gpu/drm/udl/udl_fb.c | 5 +
drivers/gpu/drm/virtio/virtgpu_fb.c | 5 +
include/drm/drm_fb_helper.h | 4
22 files changed, 40 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..f4a2f1f0a6ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto out_unref;
+ goto out;
}
info->par = rfbdev;
@@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd,
gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
- goto out_destroy_fbi;
+ goto out;
}
fb = &rfbdev->rfb.base;
@@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
if (info->screen_base == NULL) {
ret = -ENOSPC;
- goto out_destroy_fbi;
+ goto out;
}
DRM_INFO("fb mappable at 0x%lX\n", info->fix.smem_start);
@@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
return 0;
-out_destroy_fbi:
- drm_fb_helper_release_fbi(helper);
-out_unref:
+out:
if (abo) {
}
@@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev,
struct amdgpu_fbdev *rfb
struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
drm_fb_helper_unregister_fbi(&rfbdev->helper);
- drm_fb_helper_release_fbi(&rfbdev->helper);
if (rfb->obj) {
amdgpufb_destroy_pinned_object(rfb->obj);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 78335100cbc3..7f184a52594e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
return 0;
err_fb_setup:
- drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
err_fb_helper:
priv->fbdev = NULL;
@@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
if (fbh) {
drm_fb_helper_unregister_fbi(fbh);
- drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index b085140fae95..f8421d23946a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
- goto err_free_vram;
+ goto out;
}
info->par = afbdev;
ret = ast_framebuffer_init(dev, &afbdev->afb, &mode_cmd, gobj);
if (ret)
- goto err_release_fbi;
+ goto out;
afbdev->sysram = sysram;
afbdev->size = size;
@@ -250,9 +250,7 @@ static int astfb_create(struct drm_fb_helper *helper,
return 0;
-err_release_fbi:
- drm_fb_helper_release_fbi(helper);
-err_free_vram:
+
