- 07 Feb, 2018 5 commits
-
-
Linus Walleij authored
The ARM Versatile series can do RGB/BGR565 with an external "PLD" (Programmable Logical Device). However the CLCD does not have control bits for this, so it needs to be set into the ordinary 16BPP mode, then the RGB/BGR565 handling of the pixel data is handled by configuring the PLD through the external register. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180206093540.8147-2-linus.walleij@linaro.org
-
Linus Walleij authored
With a bit of refactoring we can contain the variant data for the strange PL110 versions that is feature-incomplete PL110 for the ARM Integrator/CP and somewhere inbetween PL110 and PL111 for the ARM Versatile AB and Versatile PB. We also accomodate for the custom duct-taped RGB565/BGR565 support in the Versatile variant. Reviewed-by:
-
Linus Walleij authored
The ARM reference designs "Versatile AB" and "Versatile PB" contain panel connectors with autodetection of the connected panel type. This adds a small driver utilizing the MFD syscon look-up to read the autodetection register and set up the corresponding panel appropriately. In the source file there is a bit of elaboration of the panel types and interfaces on these boards. This was tested with the PL111 DRM driver on the ARM Versatile AB with the IB2 daughterboard. Reviewed-by:
-
Linus Walleij authored
This adds a pretty simple set of device tree bindings for ARM Versatile panels appearing as child nodes of a system controller. Cc: devicetree@vger.kernel.org Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Linus Walleij authored
Why is the argument to ->mode_valid() called "crtc"? I guess a copy/paste error. Fix it. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 05 Feb, 2018 1 commit
-
-
Maarten Lankhorst authored
This will make it possible for userspace to know whether reading will block, without blocking on the fd. This makes it possible to drain all queued CRC's in blocking mode, without having to reopen the fd. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202142743.68527-1-maarten.lankhorst@linux.intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Use POLLIN|POLLRDNORM, based on Ville's suggestion]
-
- 02 Feb, 2018 2 commits
-
-
Ville Syrjälä authored
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: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Ville Syrjälä authored
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> Signed-off-by:
-
- 01 Feb, 2018 2 commits
-
-
Daniel Vetter authored
I'm stepping down, also handing all the drm-misc stuff to the new team. Plan is that Sean handles 4.17, and Maarten then has fun with 4.18 as his first release. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Sean Paul <seanpaul@chromium.org> Acked-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Tomeu Vizoso authored
If the wait timeouts, the caps are probably invalid and we shouldn't be passing them to userspace. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20171127142126.25765-1-tomeu.vizoso@collabora.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
- 30 Jan, 2018 11 commits
-
-
Gustavo A. R. Silva authored
Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180130100528.GA7154@training
-
Dan Carpenter authored
The parentheses are in the wrong place here so we pass the bits per pixel as zero. Fixes: abbee623 ("drm/mgag200: Added resolution and bandwidth limits for various G200e products.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Daniel Vetter authored
drm_encoder_slave is the old way to write bridge drivers, for i2c bridges only. It's deprecated, and definitely should not be used in new drivers. This has absolutely nothing to do with the new bridge driver infrastructure implemented by drm_bridge. What's even strange is that arcpgu doesn't even use any of this, it really only wants a plain normal drm_encoder. Nuke all the surplus real estate. v2: Actually git add after compile testing ... v3: Clarify commit message and stop including drm_encoder_slave.h. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Reviewed-by:
-
Shawn Guo authored
The structure should really be sw_sync_create_fence_data rather than sw_sync_ioctl_create_fence which is the function name. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Maarten Lankhorst authored
Userspace can set a FB_ID on a plane without setting CRTC_ID, which will fail with -EINVAL, but the kernel shouldn't warn about that. Same for !FB_ID and CRTC_ID being set. Signed-off-by:
Harry Wentland <harry.wentland@amd.com>
-
Philippe Cornu authored
The dw_mipi_dsi_host_transfer() must return the number of bytes transmitted/received on success instead of 0. Note: As the read feature is not implemented, only the transmitted number of bytes is returned for the moment. Reviewed-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180125103800.1999-3-philippe.cornu@st.com
-
Philippe Cornu authored
The dcs/generic dsi read feature is not yet implemented so it is important to warn the host_transfer() caller in case of read operation requests. Reviewed-by:
-
Philippe Cornu authored
To optimize data transfers, align pitch on 128 bytes & height on 4 bytes. This optimization is not applicable on hw without MMU. Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Signed-off-by:
Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180130104200.21602-1-philippe.cornu@st.com
-
Philippe CORNU authored
Add support for the stm dsi phy/wrapper version 1.31. Only lane capabilities need to be modified. Signed-off-by:
-
Philippe CORNU authored
In the dsi panel example, clock names in the "clock-names" field have been swapped: * "pclk" (peripheral clock) is <&rcc 1 CLK_F469_DSI> on stm32f4 * "ref" (dsi phy pll ref clock) is <&clk_hse> on stm32f4 Signed-off-by:
-
Leo (Sunpeng) Li authored
During a non-blocking commit, it is possible to return before the commit_tail work is queued (-ERESTARTSYS, for example). Since a reference on the crtc commit object is obtained for the pending vblank event when preparing the commit, the above situation will leave us with an extra reference. Therefore, if the commit_tail worker has not consumed the event at the end of a commit, release it's reference. Changes since v1: - Also check for state->event->base.completion being set, to handle the case where stall_checks() fails in setup_crtc_commit(). Changes since v2: - Add a flag to drm_crtc_commit, to prevent dereferencing a freed event. i915 may unreference the state in a worker. Fixes: 24835e44 ("drm: reference count event->completion") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by:
Leo (Sunpeng) Li <sunpeng.li@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> #v1 Signed-off-by:
-
- 29 Jan, 2018 19 commits
-
-
Ville Syrjälä authored
We never support certain mode flags etc. Reject those early on in the mode_config.mode_valid() hook. That allows us to remove some duplicated checks from the connector .mode_valid() hooks, and it guarantees that we never see those flags even from user mode as the mode_config.mode_valid() hooks gets executed for those as well. Signed-off-by:
-
Ville Syrjälä authored
Allow drivers to provide a device wide .mode_valid() hook in addition to the already existing crtc/encoder/bridge/connector hooks. This can be used to validate device/driver wide constraings without having to add those to the other hooks. And since we call this hook also for user modes later on in the modeset we don't have to worry about anything the hook has already rejected. I also have some further ideas for this hook. Eg. we could replace the drm_mode_set_crtcinfo(HALVE_V) call in drm_mode_convert_umode()/etc. with a driver specific variant via this hook. At least on i915 we would like to pass CRTC_STEREO_DOUBLE to that function instead, and then we could safely use the crtc_ timings in all our .mode_valid() hooks, which would allow us to reuse those hooks for validating the adjusted_mode during a modeset. v2: Fix the language fails in the kernel docs (Daniel) Signed-off-by:
-
Ville Syrjälä authored
BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's refuse to generate them or accept them from userspace either. A cursory check didn't reveal any userspace code that would depend on these. v2: Recommend DRIVER instead of BUILTIN (ajax) Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171115154504.14338-1-ville.syrjala@linux.intel.comReviewed-by:
Jose Abreu <joabreu@synopsys.com>
-
Ville Syrjälä authored
No idea what the DRM_MODE_TYPE_CLOCK_CRTC_C define is supposed to achieve. Totally unused so kill if off. Signed-off-by:
-
Ville Syrjälä authored
For some reason drm_mode_set_crtcinfo() does nothing if the mode has the DRM_MODE_TYPE_BUILTIN flag set without the other bit from DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed to achieve, but since we have no users for neither flag bit let's kill this nonsense off. v2: Fix typo in commit message Signed-off-by:
-
Ville Syrjälä authored
These days DRM_MODE_TYPE_USERDEF is used to flag modes defined via the kernel command line. Update the docs to reflect that fact. Signed-off-by:
-
Ville Syrjälä authored
Reject any mode with DRM_MODE_FLAG_BCAST. We have no code that even checks for this flag hence it can't possibly do any good. I think this maybe originated from fbdev where it was supposed to indicate PAL/NTSC broadcast timings. I have no idea why those would have to be identified by a flag rather than by just the timings themselves. And then I assume it got copied into xfree86 for fbdevhw, and later on it leaked into the randr protocol and kms uapi. Since kms fbdev emulation never uses the corresponding fbdev flag there should be no sane way for this to come back into kms via userspace either. Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Maxime Ripard authored
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:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com
-
Maxime Ripard authored
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:
-
Maxime Ripard authored
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:
-
Maxime Ripard authored
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:
-
Maxime Ripard authored
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:
-
Maxime Ripard authored
There was a typo in the width spelling of the (unused) SUN4I_BACKEND_IYUVLINEWITDTH_REG macro. Fix it. Acked-by:
-
Maxime Ripard authored
The sun4i_plane_desc structure was somehow indented to two tabulations instead of one as we shoud do. Fix that. Acked-by:
-
Maxime Ripard authored
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:
-
