Simon Ser [Tue, 22 Dec 2020 13:40:02 +0000 (14:40 +0100)]
drm: warn if cursor plane is set with legacy funcs
A driver must not set drm_crtc.cursor and any of the legacy funcs at the
same time, otherwise it's not clear which one DRM core should use for
legacy cursor updates.
Linus Walleij [Mon, 14 Dec 2020 22:22:10 +0000 (23:22 +0100)]
drm/panel: s6e63m0: Support max-brightness
The "max-brightness" is a standard backlight property that
we need to support for the Samsung GT-I8190 Golden because
the display will go black if we crank up the brightness
too high.
As the platform needs this ability to give picture this is
a regression fix along with the addition of the property
to the GT-I8190 device tree.
Tian Tao [Tue, 22 Dec 2020 11:55:56 +0000 (19:55 +0800)]
drm/hisilicon: Remove drm_dev_put in hibmc
Hibmc use the devm_drm_dev_alloc function in hibmc_pci_probe, if
hibmc_pci_probe returns non-zero, devm_drm_dev_alloc will call
devm_drm_dev_init, which will call devm_drm_dev_init_release to
release drm_dev_put. There is no need for hibmc to call
drm_dev_put separately.
Tian Tao [Fri, 11 Dec 2020 01:32:29 +0000 (09:32 +0800)]
drm/qxl: use flexible-array member instead of zero-length array
Use flexible-array member introduced in C99 instead of zero-length
array. Most of zero-length array was already taken care in previous
patch [1]. Now modified few more cases which were not handled earlier.
drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO
VIRTIO itself has no dependencies and therefore can easily be just
select'ed, instead of depending on it. The current depends on causes
any others trying to select VIRTIO to fail like this:
drivers/gpu/drm/Kconfig:74:error: recursive dependency detected!
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO
drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO
drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB
drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306
drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C
drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
It seems that having both 'depends on' as well as 'select' on the same symbol
sends us into big trouble, and Kconfig can't break up the circular dependency
(note that in the tested configuration, neither I2C, FB or DRM are enabled at
all). Perhaps we could consider this a bug in Kconfig, but the trouble can
easily be circumvented by changing 'depends on' into 'select'.
DRM_VIRTIO_GPU also depends on VIRTIO_MENU, so even after this change, that
option will only show up if the user already enabled virtio in the config.
This change didn't cause any changes in the .config after menuconfig run,
so we should be completely safe here.
Daniel Vetter [Fri, 11 Dec 2020 16:11:13 +0000 (17:11 +0100)]
drm/fb-helper: Add a FIXME that generic_setup is very confusing
I tried to fix this for real, but it's very sprawling and lots of
drivers get this mildly wrong one way or the other.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Simon Ser <contact@emersion.fr> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201211161113.3350061-2-daniel.vetter@ffwll.ch
Simon Ser [Fri, 11 Dec 2020 18:46:34 +0000 (19:46 +0100)]
drm: require each CRTC to have a unique primary plane
User-space expects to be able to pick a primary plane for each CRTC
exposed by the driver. Make sure this assumption holds in
drm_mode_config_validate.
Use the legacy drm_crtc.primary field to check this, because it's
simpler and we require drivers to set it anyways. Accumulate a set of
primary planes which are already used for a CRTC in a bitmask. Error out
if a primary plane is re-used.
v2: new patch
v3:
- Use u64 instead of __u64 (Jani)
- Use `unsigned int` instead of `unsigned` (Jani)
v4:
- Use u32 instead of u64 for plane mask (Ville)
- Use drm_plane_mask instead of BIT (Ville)
- Fix typos (Ville)
Simon Ser [Wed, 16 Dec 2020 20:22:18 +0000 (21:22 +0100)]
drm/doc: move color management functions under CRTC section
Move drm_color_mgmt function reference from the KMS properties
section to the CRTC abstraction section. This makes the KMS
properties section more readable for user-space developers.
Simon Ser [Wed, 16 Dec 2020 20:22:17 +0000 (21:22 +0100)]
drm/doc: move damage tracking functions to new section
Move drm_damage_helper function reference from the KMS properties
section to the plane abstraction section. This makes the KMS
properties section more readable for user-space developers.
Simon Ser [Wed, 16 Dec 2020 20:22:16 +0000 (21:22 +0100)]
drm/doc: move composition function docs to new section
Move drm_blend.c function reference from the KMS properties section to
the plane abstraction section. This makes the KMS properties section
more readable for user-space developers.
Maxime Ripard [Tue, 15 Dec 2020 15:42:42 +0000 (16:42 +0100)]
drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling
Unlike the previous generations, the HSM clock limitation is way above
what we can reach without scrambling, so let's move the maximum
frequency we support to the maximum clock frequency without scrambling.
Maxime Ripard [Tue, 15 Dec 2020 15:42:41 +0000 (16:42 +0100)]
drm/vc4: hdmi: Use the connector state pixel rate for the PHY
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reuse it from there instead of computing it again.
Maxime Ripard [Tue, 15 Dec 2020 15:42:40 +0000 (16:42 +0100)]
drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Maxime Ripard [Tue, 15 Dec 2020 15:42:39 +0000 (16:42 +0100)]
drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Maxime Ripard [Tue, 15 Dec 2020 15:42:38 +0000 (16:42 +0100)]
drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we don't end up accessing a NULL pointer.
Maxime Ripard [Tue, 15 Dec 2020 15:42:37 +0000 (16:42 +0100)]
drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check
Commit 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within
limits") was intended to compute the pixel rate to make sure we remain
within the boundaries of what the hardware can provide.
However, unlike what mode_valid was checking for, we forgot to take
into account the clock doubling flag that can be set for modes. Let's
honor that flag if it's there.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201215154243.540115-4-maxime@cerno.tech
Maxime Ripard [Tue, 15 Dec 2020 15:42:35 +0000 (16:42 +0100)]
drm/vc4: hvs: Align the HVS atomic hooks to the new API
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Tian Tao [Tue, 15 Dec 2020 12:18:59 +0000 (20:18 +0800)]
drm/hisilicon: Fix rmmod hibmc_drm failed
drm_irq_uninstall should be called before pci_disable_msi, if use
devm_drm_irq_install to register the interrupt, the system will
call pci_disable_msi first and then call drm_irq_uninstall, which
will result in the following callstack.
Simon Ser [Fri, 11 Dec 2020 18:46:33 +0000 (19:46 +0100)]
drm: require a non_NULL drm_crtc.primary
If a CRTC is missing a legacy primary plane pointer, a lot of things
will be broken for user-space: fbdev stops working and the entire legacy
uAPI stops working.
Require all drivers to populate drm_crtc.primary to prevent these
issues. Warn if it's NULL.
Simon Ser [Fri, 11 Dec 2020 18:46:32 +0000 (19:46 +0100)]
drm: validate possible_crtcs for primary and cursor planes
If a primary or cursor plane is not compatible with a CRTC it's attached
to via the legacy primary/cursor field, things will be broken for legacy
user-space.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:57 +0000 (12:46 +0200)]
drm/omap: dsi: allow DSI commands to be sent early
Panel drivers can send DSI commands in panel's prepare(), which happens
before the bridge's enable() is called. The OMAP DSI driver currently
only sets up the DSI interface at bridge's enable(), so prepare() cannot
be used to send DSI commands.
This patch fixes the issue by making it possible to enable the DSI
interface any time a command is about to be sent. Disabling the
interface is be done via delayed work.
Clarifications for the delayed disable work and the panel doing DSI
transactions:
bridge_enable: If the disable callback is called just before
bridge_enable takes the dsi_bus_lock, no problem, bridge_enable just
enables the interface again. If the callback is ran just after
bridge_enable's dsi_bus_unlock, no problem, dsi->video_enabled == true
so the callback does nothing.
bridge_disable: similar to bridge-enable, the callback won't do anything
if video_enabled == true, and after bridge-disable has turned the video
and the interface off, there's nothing to do for the callback.
omap_dsi_host_detach: this is called when the panel does
mipi_dsi_detach(), and we expect the panel to _not_ do any DSI
transactions after (or during) mipi_dsi_detatch(), so there are no
race conditions.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:56 +0000 (12:46 +0200)]
drm/omap: dsi: fix DCS_CMD_ENABLE
We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when
the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this
right by accident, but now we set DCS_CMD_ENABLE for video mode panels
too.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:55 +0000 (12:46 +0200)]
drm/omap: dsi: remove ulps support
ULPS is a niche power-saving feature which only really affects command
mode panels showing a static picture. I know the ULPS code used to work
very long time ago, but I could not get it working with the current
driver. As the ULPS code is not trivial and includes delayed work (so
lots of chances for race issues), and just keeping DSI video and command
mode panels working has been challenging enough even without ULPS, lets
remove ULPS support.
When the DSI driver works reliably for command and video mode displays,
someone interested can work on ULPS and add it back if the power saving
is substantial enough.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:51 +0000 (12:46 +0200)]
drm/omap: dsi: rename dsi_display_* functions
The function names have evolved to be very confusing, and bunch of them
have "display" in them even if the function doesn't deal with display as
such (e.g. dsi_display_enable which just enables the DSI interface).
Rename them by dropping the "display".
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:47 +0000 (12:46 +0200)]
drm/omap: dsi: move structs & defines to dsi.h
Move structs and defines to a private dsi.h header file to make dsi.c a
bit easier to navigate. Also move the (now) private structs and defines
from omapdss.h to dsi.h.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:45 +0000 (12:46 +0200)]
drm/panel: panel-dsi-cm: add panel database to driver
Add a panel database to the driver instead of reading propertes from DT
data. This is similar to panel-simple, and I believe it's more future
safe way to handle the panels.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:43 +0000 (12:46 +0200)]
drm/omap: dsi: use separate VCs for cmd and video
For command mode panels we can use a single VC for sending command and
video data, even if we have to change the data source for that VC when
going from command to video or vice versa.
However, with video mode panels we want to keep the pixel data VC
enabled, and use another VC for command data, and the commands will get
interleaved into the pixel data.
This patch makes the driver use VC0 for commands and VC1 for video.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:42 +0000 (12:46 +0200)]
drm/omap: dsi: enable HS before sending the frame
We currently use a single VC for sending commands and pixel data. The
LP/HS mode for pixel data is correctly set to HS by accident, as we have
set the VC to HS already earlier.
However, if we use a different VC for video data, the VC is in LP mode.
Fix this by always enabling HS mode before starting a frame update.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:41 +0000 (12:46 +0200)]
drm/omap: dsi: skip dsi_vc_enable_hs when already in correct mode
Simplify and optimize dsi_vc_enable_hs() so that it can be called
without checking the current HS/LP mode. Make dsi_vc_enable_hs() return
if the VC is already in the correct mode.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:40 +0000 (12:46 +0200)]
drm/omap: dsi: untangle vc & channel
DSI virtual channel and hardware VC blocks have gotten tangled as
described in the previous commits. This has not caused any issues, as
the value for both is 0, so it happens to work.
To fix the issue, change the code to use the correct one of the two.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:39 +0000 (12:46 +0200)]
drm/omap: dsi: pass vc and channel to various functions
To start fixing the issues related to channels and vcs described in the
previous commit, pass vc and/or channel to various functions which will
need it do properly handle different DSI channels and VCs.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:38 +0000 (12:46 +0200)]
drm/omap: dsi: rename 'channel' to 'vc'
The "channel" usage in omap dsi driver is confusing. We have three
different "channels":
1) DSI virtual channel ID. This is a number from 0 to 3, included in the
packet payload.
2) VC. This is a register block in the DSI IP. There are four of those
blocks. A VC is a DSI "pipeline", with defined fifo settings, data
source (cpu or dispc), and some other settings. It has no relation to
the 1).
3) dispc channel. It's the "pipeline" number dispc uses to send pixel
data.
The previous patch handled the third case.
To start fixing 1) and 2), we first rename all uses of 'channel' to
'vc', as in most of the cases that is the correct thing to use.
However, in some places 1) and 2) have gotten mixed up (i.e. the code
uses msg->channel when it should use vc), which will be fixed in the
following patch.
Note that mixing 1) and 2) currently is "fine", as at the moment we only
support DSI peripherals with DSI virtual channel 0, and we always use
VC0 to send data. So both 1) and 2) are always 0.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:35 +0000 (12:46 +0200)]
drm/omap: dsi: simplify VC handling
The VC handling has gotten quite tangled up. As the first step to clean
it up, lets define that we only support a single DSI peripheral (which
was really already the case), and we always use VC0 (define VC_DEFAULT
0) register block to send data to the peripheral.
We can thus have a single mipi_dsi_device pointer and remove the
for-loops which made passes over all the four VCs (just the first one
was ever used).
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:34 +0000 (12:46 +0200)]
drm/omap: dsi: send nop instead of page & column
The OMAP DSI command mode panel driver used to send page & column
address before each frame update, and this code was moved into the DSI
host driver when converting it to the DRM bridge model.
However, it's not really required to send the page & column address
before each frame. It's also something that doesn't really belong to the
DSI host driver, so we should drop the code.
That said, frame updates break if we don't send _something_ between the
frames. A NOP command does the trick.
It is not clear if this behavior is as expected from a DSI command mode
frame transfer, or is it a feature/issue with OMAP DSI driver, or a
feature/issue in the command mode panel used.
Most likely this is related to the following from the DSI spec:
"To enable PHY synchronization the host processor should periodically
end HS transmission and drive the Data Lanes to the LP state. This
transition should take place at least once per frame."
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:31 +0000 (12:46 +0200)]
drm/omap: pll: fix iteration loop check
If the PLL calc function is given bad parameters, n_start/m_start may be
higher than n_stop/m_stop, which leads to the loops iterating through
the whole u32 number space.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:26 +0000 (12:46 +0200)]
drm/omap: remove dispc_ops
dispc_ops was created to help with the multi-module architecture and
giving us the possibility of multiple dispc implementations. Neither of
these is valid anymore, and we can remove dispc_ops and use direct
calls to dispc.
Tomi Valkeinen [Tue, 15 Dec 2020 10:46:23 +0000 (12:46 +0200)]
drm/omap: squash omapdrm sub-modules into one
At the moment we have three different modules: omapdss-base, omapdss,
omapdrm. This setup is finally obsolete, as the last omapdrm specific
panel has been converted to DRM panel.
We can thus remove omapdss-base and omapdss, and just compile everything
into omapdrm.ko.
Simplify DSI pin config, which always originates from DT
nowadays. With the code being fully contained in the DSI
encoder, we can drop the public structure.
Since the function is no longer exposed, it now directly
takes the private DSI data pointer. This drops a pointless
conversion and means the pins can be configured earlier.
All DSS devices have been converted to bridge API, so
the device operations are always NULL. This removes
the device ops function pointers and all code using it.
In order to integrate with a chain of drm_bridge, the internal DSI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
We can simply provide the device to the omapdrm driver
via pdata. omapdss_is_initialized() is no longer required
(even before this patch), since omapdrm device is only
registered after the pointer is initialized.
Do not try to reset the panel after DSI has been
detached, since the DSI clocks may have been disabled
at this point. The panel will be disabled and unprepared
before being removed and a reset will be done when being
probed again.
drm/omap: dsi: drop custom panel capability support
Due to previous changes the DSI encoder gets the capabilities
via DSI client's mode_flags and no longer needs the omapdss
specific caps. The core code now checks if the DSI encoder
is actually configured into command mode instead of just checking
the panel capabilities.
drm/omap: dsi: Reverse direction of the DSS device enable/disable operations
Complete the direction reversal of the DSS device enable/disable
operations started by commit 19b4200d8f4b ("drm/omap: Reverse direction
of the DSS device enable/disable operations").
This effectively drops the requirement of calling DSS specific
code from the DSI panel driver moving it a bit further to a
standard drm_panel driver.
drm/omap: dsi: untangle ulps ops from enable/disable
Create a custom function pointer for ULPS and use it instead of
reusing disable/enable functions for ULPS mode switch. This allows
us to use the common disable/enable functions pointers for DSI.
In preparation for removing custom DSS calls from the DSI
panel driver, this moves support for external tearing event
GPIOs into the DSI host driver. This way tearing events are
always handled in the core resulting in simplification of
the panel drivers.
The TE GPIO acquisition follows works in the same way as the
exynos DSI implementation.
projects / kernel.git / log