1. 10 Feb, 2020 9 commits
  2. 09 Feb, 2020 5 commits
  3. 07 Feb, 2020 1 commit
  4. 06 Feb, 2020 14 commits
  5. 05 Feb, 2020 1 commit
  6. 04 Feb, 2020 6 commits
  7. 31 Jan, 2020 4 commits
    • Boris Brezillon's avatar
      drm/panel: simple: Fix the lt089ac29000 bus_format · 9781bd1d
      Boris Brezillon authored
      The lt089ac29000 panel is an LVDS panel, not a DPI one. Fix the
      definition to reflect this fact.
      
      v10:
      * Add changelog to the commit message
      
      v8 -> v9:
      * No changes
      
      v7:
      * New patch
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Suggested-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-12-boris.brezillon@collabora.com
      9781bd1d
    • Boris Brezillon's avatar
      drm/imx: pd: Use bus format/flags provided by the bridge when available · fe141ced
      Boris Brezillon authored
      Now that bridges can expose the bus format/flags they expect, we can
      use those instead of the relying on the display_info provided by the
      connector (which is only valid if the encoder is directly connected
      to bridge element driving the panel/display).
      
      We also explicitly expose the bus formats supported by our encoder by
      filling encoder->output_bus_caps with proper info.
      
      v10:
      * Add changelog to the commit message
      * Use kmalloc() instead of kcalloc()
      * Add a dev_warn() when unsupported flags are requested
      
      v8 -> v9:
      * No changes
      
      v7:
      * Add an imx_pd_format_supported() helper (suggested by Philipp)
      * Simplify imx_pd_bridge_atomic_get_output_bus_fmts() (suggested by Philipp)
      * Simplify imx_pd_bridge_atomic_get_input_bus_fmts()
      * Explicitly set the duplicate/destro_state() and reset() hooks
      
      v4 -> v6:
      * Patch was not part of the series
      
      v3 (all suggested by Philipp):
      * Adjust to match core changes
      * Propagate output format to input format
      * Pick a default value when output_fmt = _FIXED
      * Add missing BGR888 and GBR888 fmts to imx_pd_bus_fmts[]
      
      v2:
      * Adjust things to match the new bus-format negotiation infra
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-8-boris.brezillon@collabora.com
      fe141ced
    • Boris Brezillon's avatar
      drm/bridge: Add the necessary bits to support bus format negotiation · f32df58a
      Boris Brezillon authored
      drm_bridge_state is extended to describe the input and output bus
      configurations. These bus configurations are exposed through the
      drm_bus_cfg struct which encodes the configuration of a physical
      bus between two components in an output pipeline, usually between
      two bridges, an encoder and a bridge, or a bridge and a connector.
      
      The bus configuration is stored in drm_bridge_state separately for
      the input and output buses, as seen from the point of view of each
      bridge. The bus configuration of a bridge output is usually identical
      to the configuration of the next bridge's input, but may differ if
      the signals are modified between the two bridges, for instance by an
      inverter on the board. The input and output configurations of a
      bridge may differ if the bridge modifies the signals internally,
      for instance by performing format conversion, or*modifying signals
      polarities.
      
      Bus format negotiation is automated by the core, drivers just have
      to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
      want to take part to this negotiation. Negotiation happens in reverse
      order, starting from the last element of the chain (the one directly
      connected to the display) up to the first element of the chain (the one
      connected to the encoder).
      During this negotiation all supported formats are tested until we find
      one that works, meaning that the formats array should be in decreasing
      preference order (assuming the driver has a preference order).
      
      Note that the bus format negotiation works even if some elements in the
      chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
      In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
      the previous bridge element decide what to do (most of the time, bridge
      drivers will pick a default bus format or extract this piece of
      information from somewhere else, like a FW property).
      
      v10:
      * Add changelog to the commit message
      
      v9:
      * No changes
      
      v8:
      * Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
        Jonas)
      
      v7:
      * Adapt the code to deal with the fact that not all bridges in the
        chain have a bridge state
      
      v5 -> v6:
      * No changes
      
      v4:
      * Enhance the doc
      * Fix typos
      * Rename some parameters/fields
      * Reword the commit message
      
      v3:
      * Fix the commit message (Reported by Laurent)
      * Document the fact that bus formats should not be directly modified by
        drivers (Suggested by Laurent)
      * Document the fact that format order matters (Suggested by Laurent)
      * Propagate bus flags by default
      * Document the fact that drivers can tweak bus flags if needed
      * Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
        array (Suggested by Laurent)
      * Add a drm_atomic_helper_bridge_propagate_bus_fmt()
      * Mandate that bridge drivers return accurate input_fmts even if they
        are known to be the first element in the bridge chain
      
      v2:
      * Rework things to support more complex use cases
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      [narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
      Reviewed-by: default avatarJernej Skrabec <jernej.skrabec@siol.net>
      Tested-by: default avatarJonas Karlman <jonas@kwiboo.se>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
      f32df58a
    • Boris Brezillon's avatar
      drm/bridge: Add an ->atomic_check() hook · 5061b8a9
      Boris Brezillon authored
      So that bridge drivers have a way to check/reject an atomic operation.
      The drm_atomic_bridge_chain_check() (which is just a wrapper around
      the ->atomic_check() hook) is called in place of
      drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
      the core falls back on ->mode_fixup(), so the behavior should stay
      the same for existing bridge drivers).
      
      v10:
      * Add changelog to the commit message
      
      v8 -> v9:
      * No changes
      
      v7:
      * Fix a NULL pointer dereference
      
      v5 -> v6:
      * No changes
      
      v4:
      * Add R-bs
      
      v3:
      * No changes
      
      v2:
      * Clarify the fact that ->atomic_check() is replacing ->mode_fixup()
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Reviewed-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Reviewed by: Jernej Skrabec <jernej.skrabec@siol.net>
      Tested-by: default avatarJonas Karlman <jonas@kwiboo.se>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-6-boris.brezillon@collabora.com
      5061b8a9