- 30 1月, 2018 4 次提交
-
-
由 Ville Syrjälä 提交于
Reject any mode with DRM_MODE_FLAG_PIXMUX. We have no code that even checks for this flag hence it can't possibly do any good. Looks like this flag had something to do the the controller<->ramdac interface with some ancient S3 graphics adapters. Why someone though it would be a good idea to expose it directly to users I don't know. And later on it got copied into the randr protocol and kms uapi. Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-4-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJose Abreu <joabreu@synopsys.com>
-
由 Ville Syrjälä 提交于
Currently userspace is allowed to feed in any king of garbage in the high bits of the mode flags/type, as are drivers when probing modes. Reject any mode with bogus flags/type. Hopefully this won't break any current userspace... v2: Split the type and flags checks to separates ifs (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115154913.23827-1-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Ville Syrjälä 提交于
Currently we don't sanity check the 3D stereo flags for modes filled out by the kernel. Move the check from drm_mode_convert_umode() into drm_mode_validate_basic() so that we get the same check going both ways. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-2-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Ville Syrjälä 提交于
We use 32bit bitmasks to track planes/crtcs/encoders/connectors. Naturally we can only do that if the index of those objects stays below 32. Issue a warning whenever we exceed that limit, hopefully prompting someone to fix the problem. For connectors the issue is a bit more complicated as they can be created/destroyed at runtime due to MST. So the problem is no longer a purely theoretical programmer error. As the connector indexes are allocated via ida, we can simply limit the maximum value the ida is allowed to hand out. The error handling is already in place. v2: Return an error to the caller (Harry) v3: Print a debug message so that we know what happened (Maarten) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180125133020.23845-1-ville.syrjala@linux.intel.comReviewed-by: NHarry Wentland <harry.wentland@amd.com>
-
- 29 1月, 2018 13 次提交
-
-
由 Maxime Ripard 提交于
Due to the way the composition is done in hardware, we can only have a single alpha-enabled plane active at a time, placed in the second (highest priority) pipe. Make sure of that in our atomic_check to not end up in an impossible scenario. Reviewed-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Our various planes have a configurable zpos, that combined with the pipes allow to configure the composition. Since the interaction between the pipes, zpos and alphas framebuffers is not trivial, let's just enable the zpos as an immutable property for now, and use that zpos in our atomic_update part. Reviewed-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/b006853e908bd06661c5bc1f2191121523bce0e4.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
The plane state zpos value will be set only if there's an existing state attached to the plane when creating the property. However, this is not the case during the probe, and we therefore need to put our default value in our reset hook. Acked-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/b6a183234f0ad5a9a58c780c9cabbe29cbf40888.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
The function supposed to update a plane's coordinates is called in both branches of our function. Let's move it out the if statement. Acked-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/2cd57bcf13652109da7bd5bbe12fa1d29429f02f.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
In order to support normalized zpos, we need to call drm_atomic_normalize_zpos in our driver's drm_mode_config_funcs' atomic_check. Let's duplicate the definition of drm_atomic_helper_check for now. Acked-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/67cb4ca9889e6bf29314db37127ff15eed279c53.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
There was a typo in the width spelling of the (unused) SUN4I_BACKEND_IYUVLINEWITDTH_REG macro. Fix it. Acked-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/6b2e872b611b733a98a38902a2197b70c725e0b9.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
The sun4i_plane_desc structure was somehow indented to two tabulations instead of one as we shoud do. Fix that. Acked-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/8a6714bddb865adfcfe2b792e406a2f10bb819bc.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Now that the drm_format_info has a alpha field to tell if a format embeds an alpha component in it, let's use it. Cc: Eric Anholt <eric@anholt.net> Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/38d4d0a085634a0b8308e819c846b9173d4d93df.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Now that the drm_format_info has a alpha field to tell if a format embeds an alpha component in it, let's use it. Acked-by: NSandy huang <hjc@rock-chips.com> Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/5a217e8c93eea6f0a7f6bc5883424b47dbb6c664.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Now that the drm_format_info has a alpha field to tell if a format embeds an alpha component in it, let's use it. Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Acked-by: NInki Dae <inki.dae@samsung.com> Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/cb1bdfbb481419a17cc4f6c8a1f07930136ac13f.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Now that the drm_format_info has a alpha field to tell if a format embeds an alpha component in it, let's use it. Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/23518426a46320dd884465cebec0961f839f2972.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
There's a bunch of drivers that duplicate the same function to know if a particular format embeds an alpha component or not. Let's create a field in the drm_format_info to avoid duplicating that logic and looking up formats all the time. Cc: Eric Anholt <eric@anholt.net> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/9cd9951d147ff810c1f6f68d79e7983361ed6b68.1516617243.git-series.maxime.ripard@free-electrons.com
-
由 Philippe CORNU 提交于
There is a difference between the panel/bridge requested pixel clock value and the real one due to the hw platform clock preciseness (pll, dividers...). This patch updates the adjusted_mode clock value with the real hw clock value so then attached encoder & connector can use it for precise timing computations. Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com> Reviewed-by: NYannick Fertré <yannick.fertre@st.com> Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180125160101.9102-1-philippe.cornu@st.com
-
- 26 1月, 2018 2 次提交
-
-
由 Manasi Navare 提交于
DP 1.4 spec adds a TPS4 training pattern sequence required for HBR3. This patch adds the corresponding bit definitions in MAX_DOWNSPREAD register and TRAINING_PATTERN_SET and inline functions to check if this bit is set and for selecting a proper TRAINING_PATTERN_MASK that changed to 0x7 on DP spec 1.4 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-2-git-send-email-manasi.d.navare@intel.com
-
由 Manasi Navare 提交于
Existing helpers add support upto HBR2. This patch adds support for HBR3 rate (8.1 Gbps) introduced as part of DP 1.4 specification. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-1-git-send-email-manasi.d.navare@intel.com
-
- 24 1月, 2018 1 次提交
-
-
由 Christian König 提交于
Change reservation_object_get_fences_rcu to make the exclusive fence pointer optional. If not specified the exclusive fence is put into the fence array as well. This is helpful for a couple of cases where we need all fences in a single array. Reviewed-by: NChunming Zhou <david1.zhou@amd.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180110125341.3618-1-christian.koenig@amd.com
-
- 23 1月, 2018 16 次提交
-
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-15-ville.syrjala@linux.intel.comAcked-by: NShawn Guo <shawnguo@kernel.org> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-14-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). v2: Rebase due to tegra_plane_state_add() relocating to plane.c Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-tegra@vger.kernel.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NThierry Reding <treding@nvidia.com> Reviewed-by: NThierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-13-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-12-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-11-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-10-ville.syrjala@linux.intel.comReviewed-by: NArchit Taneja <architt@codeaurora.org> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: linux-amlogic@lists.infradead.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-9-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-8-ville.syrjala@linux.intel.comAcked-by: NPhilipp Zabel <p.zabel@pengutronix.de> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-7-ville.syrjala@linux.intel.comAcked-by: NPhilipp Zabel <p.zabel@pengutronix.de> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-6-ville.syrjala@linux.intel.comReviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-5-ville.syrjala@linux.intel.comAcked-by: NLiviu Dudau <liviu.dudau@arm.com> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-4-ville.syrjala@linux.intel.comAcked-by: NLiviu Dudau <liviu.dudau@arm.com> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes since pipe_src_w/h are already filled via drm_mode_get_hv_timing(). Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Ville Syrjälä 提交于
In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay we must not adjust pipe_src_w to accommodate double wide/dual link. Instead just reject the mode outright. This will allows us to rely on crtc_state->mode for plane clipping. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-2-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Sean Paul 提交于
Fixes the following build warnings: In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0, from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.h:13, from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.c:12: ../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *old_state); ^~~~~~~~~~~~~~ ../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *state); ^~~~~~~~~~~~~~ In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0, from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.h:12, from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.c:12: ../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *old_state); ^~~~~~~~~~~~~~ ../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *state); ^~~~~~~~~~~~~~ Fixes: 6b8562c8 ("drm/sun4i: engine: Create an atomic_begin callback") Fixes: 656e5f65 ("drm/sun4i: engine: Add a custom crtc atomic_check") Cc: Chen-Yu Tsai <wens@csie.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122174306.231609-1-seanpaul@chromium.org
-
由 Sean Paul 提交于
A couple more return value fixes which Philippe brought up during our previous review. Suggested-by: NPhilippe CORNU <philippe.cornu@st.com> Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180117213751.54668-1-seanpaul@chromium.org
-
- 22 1月, 2018 4 次提交
-
-
由 Maxime Ripard 提交于
If we try to read the backend registers while it fetches the new values, we end up with the value of some random register instead of the one we asked for. In order to prevent that, let's make sure that the very first thing we do during our atomic modesetting is to let the commit bit come to a rest. We don't have to worry about anything else since the only time we will trigger a new transaction is during the atomic_commit which comes much later. Reviewed-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/35604307e5bde2b85c674de79fa7c4d55700f085.1516613040.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
During a hardware commit, the commit bit in the backend will only be cleared if the TCON is enabled. Use the runtime_pm variant of the atomic_commit_tail hook that makes sure that the CRTC, our TCON, is enabled when we perform an atomic_commit. Reviewed-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/bde95faff2078f63e9af99c3abee5360b9050fd1.1516613040.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Now that we have everything in place, we can start enabling the frontend. This is more difficult than one would assume since there can only be one plane using the frontend per-backend. We therefore need to make sure that the userspace will not try to setup multiple planes using it, since that would be impossible. In order to prevent that, we can create an atomic_check callback that will check that only one plane will effectively make use of the frontend in a given configuration, and will toggle the switch in that plane state so that the proper setup function can do their role. Reviewed-by: NChen-Yu Tsai <wens@csie.org> Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/278e6c514a8311750fe627c7f28d58b3e2cbd825.1516613040.git-series.maxime.ripard@free-electrons.com
-
由 Maxime Ripard 提交于
Now that we have a driver, we can make use of it. This is done by adding a flag to our custom plane state that will trigger whether we should use the frontend on that particular plane or not. The rest is just plumbing to set up the backend to not perform the DMA but receive its data from the frontend. Note that we're still not making any use of the frontend itself, as no one is setting the flag yet. Reviewed-by: NChen-Yu Tsai <wens@csie.org> Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/cdffc25eab2d817820cc78cbd24f1f4b99902014.1516613040.git-series.maxime.ripard@free-electrons.com
-