Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 03 4月, 2015 2 次提交
    • P
      drm/panel: Add display timing support · 2938931f
      由 Philipp Zabel 提交于 
      Many panel data sheets, additionally to typical values, list allowed
ranges for timings such as hsync/vsync lengths, porches, and the pixel
clock rate. These can be stored in a struct display_timing, to be used
by an encoder mode_fixup callback to clamp user provided timing values
or to validate workarounds for clock source limitations.

This patch adds a new drm_panel_funcs callback that returns the panel's
available display_timing entries.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      2938931f
    • T
      drm/atomic: Add helpers for state-subclassing drivers · f5e7840b
      由 Thierry Reding 提交于 
      Drivers that subclass CRTC, plane or connector state need to carefully
duplicate the code that the atomic helpers have. This is bound to cause
breakage eventually because it requires auditing all drivers and update
them when code is added to the helpers.

In order to avoid that, implement new helpers that perform the required
steps when copying and destroying state. These new helpers are exported
so that state-subclassing drivers can use them. The default helpers are
implemented using them as well, providing a single location that needs
to be changed when adding to base atomic states.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      f5e7840b
  3. 31 3月, 2015 1 次提交
  5. 27 3月, 2015 2 次提交
  7. 24 3月, 2015 1 次提交
  9. 20 3月, 2015 1 次提交
  11. 18 3月, 2015 1 次提交
  13. 12 3月, 2015 3 次提交
  15. 10 3月, 2015 7 次提交
  17. 05 3月, 2015 3 次提交
  19. 24 2月, 2015 3 次提交
  21. 23 2月, 2015 4 次提交
    • D
      drm: Add DRM_DEBUG_ATOMIC · 17a38d9c
      由 Daniel Vetter 提交于 
      Atomic state handling adds a lot of indirection and complexity between
simple updates and drivers. For easier debugging the diagnostic output
is therefore rather chatty. Which is great for tracking down atomic
issues, but really annoying otherwise.

Add a new DRM_DEBUG_ATOMIC to be able to filter this out.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      17a38d9c
    • D
      drm: Fix the CRTC_STEREO_DOUBLE_ONLY define to include stero modes · 498b8738
      由 Damien Lespiau 提交于 
      The CRTC_STEREO_DOUBLE_ONLY define was introduced in commit:

  commit ecb7e16b
  Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
  Date:   Mon Dec 1 15:40:09 2014 -0800

      drm: add helper to get crtc timings (v5)

but if we want the stereo h/v adjustments, we need to set the
CRTC_STEREO_DOUBLE flag. Otherwise, we'll get the wrong h/v for frame packing
stereo 3d modes.

Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      498b8738
    • D
      drm/irq: Add drm_crtc_vblank_reset · 9625604c
      由 Daniel Vetter 提交于 
      At driver load we need to tell the vblank code about the state of the
pipes, so that the logic around reject vblank_get when the pipe is off
works correctly.

Thus far i915 used drm_vblank_off, but one of the side-effects of it
is that it also saves the vblank counter. And for that it calls down
into the ->get_vblank_counter hook. Which isn't really a good idea
when the pipe is off for a few reasons:
- With runtime pm the register might not respond.
- If the pipe is off some datastructures might not be around or
  unitialized.

The later is what blew up on gen3: We look at intel_crtc->config to
compute the vblank counter, and for a disabled pipe at boot-up that's
just not there. Thus far this was papered over by a check for
intel_crtc->active, but I want to get rid of that (since it's fairly
race, vblank hooks are called from all kinds of places).

So prep for that by adding a _reset functions which only does what we
really need to be done at driver load: Mark the vblank pipe as off,
but don't do any vblank counter saving or event flushing - neither of
that is required.

v2: Clarify the code flow slightly as suggested by Ville.

v3: Fix kerneldoc spelling, spotted by Laurent.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v2)
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      9625604c
    • R
      drm/i915/bdw: PCI IDs ending in 0xb are ULT. · 0dc6f20b
      由 Rodrigo Vivi 提交于 
      When reviewing patch that fixes VGA on BDW Halo Jani noticed that
we also had other ULT IDs that weren't listed there.

So this follow-up patch add these pci-ids as halo and fix comments
on i915_pciids.h

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      0dc6f20b
  23. 14 2月, 2015 2 次提交
    • R
      drm: add support for tiled/compressed/etc modifier in addfb2 · e3eb3250
      由 Rob Clark 提交于 
      In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats.  Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.

The proposal is to add a per-plane format modifier.  This allows to, if
necessary, use different tiling patters for sub-sampled planes, etc.
The format modifiers are added at the end of the ioctl struct, so for
legacy userspace it will be zero padded.

v1: original
v1.5: increase modifier to 64b

v2: Incorporate review comments from the big thread, plus a few more.

- Add a getcap so that userspace doesn't have to jump through hoops.
- Allow modifiers only when a flag is set. That way drivers know when
  they're dealing with old userspace and need to fish out e.g. tiling
  from other information.
- After rolling out checks for ->modifier to all drivers I've decided
  that this is way too fragile and needs an explicit opt-in flag. So
  do that instead.
- Add a define (just for documentation really) for the "NONE"
  modifier. Imo we don't need to add mask #defines since drivers
  really should only do exact matches against values defined with
  fourcc_mod_code.
- Drop the Samsung tiling modifier on Rob's request since he's not yet
  sure whether that one is accurate.

v3:
- Also add a new ->modifier[] array to struct drm_framebuffer and fill
  it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin.
- Remove TODO in comment and add code comment that modifiers should be
  properly documented, requested by Rob.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5)
Reviewed-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      e3eb3250
    • D
      drm/i915/skl: Split the SKL PCI ids by GT · bf2b8a51
      由 Damien Lespiau 提交于 
      We need to have a separate GT3 struct intel_device_info to declare they
have a second VCS. Let's start by splitting the PCI ids per-GT.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bf2b8a51
  25. 02 2月, 2015 1 次提交
  27. 28 1月, 2015 2 次提交
  29. 27 1月, 2015 7 次提交
    • T
      drm/atomic: Add ->atomic_check() to encoder helpers · 4cd4df80
      由 Thierry Reding 提交于 
      This callback can be used instead of the legacy ->mode_fixup() and is
passed the CRTC and connector states. It can thus use these states to
validate the modeset and cache values in the state to be used during
the actual modeset.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      4cd4df80
    • T
      drm/plane: Add optional ->atomic_disable() callback · 407b8bd9
      由 Thierry Reding 提交于 
      In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.

v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled planes, remove redundant comment (Daniel Vetter)

v3: rename helper to drm_atomic_plane_disabling() to clarify that it is
checking for transitions, move helper to drm_atomic_helper.h, clarify
check for !old_state and its relation to transitional helpers

Here's an extract from some discussion rationalizing the behaviour (for
a full version, see the reference below):

    > > Hm, thinking about this some more this will result in a slight difference
    > > in behaviour, at least when drivers just use the helper ->reset functions
    > > but don't disable everything:
    > > - With transitional helpers we assume we know nothing and call
    > >   ->atomic_disable.
    > > - With atomic old_state->crtc == NULL in the same situation right after
    > >   boot-up, but we asssume the plane is really off and _dont_ call
    > >   ->atomic_disable.
    > >
    > > Should we instead check for (old_state && old_state->crtc) and state that
    > > drivers need to make sure they don't have stuff hanging around?
    >
    > I don't think we can check for old_state because otherwise this will
    > always return false, whereas we really want it to force-disable planes
    > that could be on (lacking any more accurate information). For
    > transitional helpers anyway.
    >
    > For the atomic helpers, old_state will never be NULL, but I'd assume
    > that the driver would reconstruct the current state in ->reset().

    By the way, the reason for why old_state can be NULL with transitional
    helpers is the ordering of the steps in the atomic transition. Currently
    the Tegra patches do this (based on your blog post and the Exynos proto-
    type):

        1) atomic conversion, phase 1:
           - implement ->atomic_{check,update,disable}()
           - use drm_plane_helper_{update,disable}()

        2) atomic conversion, phase 2:
           - call drm_mode_config_reset() from ->load()
           - implement ->reset()

    That's only a partial list of what's done in these steps, but that's the
    only relevant pieces for why old_state is NULL.

    What happens is that without ->reset() implemented there won't be any
    initial state, hence plane->state (the old_state here) will be NULL the
    first time atomic state is applied.

    We could of course reorder the sequence such that drivers are required
    to hook up ->reset() before they can (or at the same as they) hook up
    the transitional helpers. We could add an appropriate WARN_ON to this
    helper to make that more obvious.

    However, that will not solve the problem because it only gets rid of the
    special case. We still don't know whether old_state->crtc == NULL is the
    current state or just the initial default.

    So no matter which way we do this, I don't see a way to get away without
    requiring specific semantics from drivers. They would be that:

        - drivers recreate the correct state in ->reset() so that
          old_state->crtc != NULL if the plane is really enabled

    or

        - drivers have to ensure that the real state in fact mirrors the
          initial default as encoded in the state (plane disabled)

References: http://lists.freedesktop.org/archives/dri-devel/2015-January/075578.htmlReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      407b8bd9
    • T
      drm/plane: Make ->atomic_update() mandatory · 3cad4b68
      由 Thierry Reding 提交于 
      There is no use-case where it would be useful for drivers not to
implement this function and the transitional plane helpers already
require drivers to provide an implementation.

v2: add new requirement to kerneldoc
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      3cad4b68
    • D
      drm/atomic-helpers: Saner encoder/crtc callbacks · ee0a89cf
      由 Daniel Vetter 提交于 
      For historical reasons going all the way back to how the Xrandr code
was implemented the semantics of the callbacks used to enable/disable
crtcs and encoders are ... interesting.

But with atomic helpers all that complexity has been binned, with only
a well-defined on/off action left. Unfortunately the names stuck.

Let's fix that by adding enable/disable hooks every, make them the
preferred variant for atomic and update documentations.

Later on we add debug warnings when drivers have deprecated hooks. But
while everything is in-flight with lots of drivers converting to
atomic that's a bit too much - better wait for things to settle a bit
first.

v2: Fix kerneldoc, reported by Wu Fengguang.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      ee0a89cf
    • D
      drm/atomic-helpers: Recover full cursor plane behaviour · f02ad907
      由 Daniel Vetter 提交于 
      Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor specific behaviour with a hint
flag and some hacks to drop the vblank wait.

v2: Fix kerneldoc, reported by Wu Fengguang.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      f02ad907
    • D
      drm/atomic-helper: add connector->dpms() implementation · b486e0e6
      由 Daniel Vetter 提交于 
      This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.

Of course it also clamps everything that's not ON to OFF.

v2: Fix spelling in one comment.

v3: Don't do an async commit (Thierry)

v4: Dan Carpenter noticed missing error case handling.

Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      b486e0e6
    • D
      drm/atomic: Add drm_crtc_state->active · eab3bbef
      由 Daniel Vetter 提交于 
      This is the infrastructure for DPMS ported to the atomic world.
Fundamental changes compare to legacy DPMS are:

- No more per-connector dpms state, instead there's just one per each
  display pipeline. So if you clone either you have to unclone first
  if you only want to switch off one screen, or you just switch of
  everything (like all desktops do). This massively reduces complexity
  for cloning since now there's no more half-enabled cloned configs to
  consider.

- Only on/off, dpms standby/suspend are as dead as real CRTs. Again
  reduces complexity a lot.

Now especially for backwards compat the really important part for dpms
support is that dpms on always succeeds (except for hw death and
unplugged cables ofc). Which means everything that could fail (like
configuration checking, resources assignments and buffer management)
must be done irrespective from ->active. ->active is really only a
toggle to change the hardware state. More precisely:

- Drivers MUST NOT look at ->active in their ->atomic_check callbacks.
  Changes to ->active MUST always suceed if nothing else changes.

- Drivers using the atomic helpers MUST NOT look at ->active anywhere,
  period. The helpers will take care of calling the respective
  enable/modeset/disable hooks as necessary. As before the helpers
  will carefully keep track of the state and not call any hooks
  unecessarily, so still no double-disables or enables like with crtc
  helpers.

- ->mode_set hooks are only called when the mode or output
  configuration changes, not for changes in ->active state.

- Drivers which reconstruct the state objects in their ->reset hooks
  or through some other hw state readout infrastructure must ensure
  that ->active reflects actual hw state.

This just implements the core bits and helper logic, a subsequent
patch will implement the helper code to implement legacy dpms with
this.

v2: Rebase on top of the drm ioctl work:
- Move crtc checks to the core check function.
- Also check for ->active_changed when deciding whether a modeset
  might happen (for the ALLOW_MODESET mode).
- Expose the ->active state with an atomic prop.

v3: Review from Rob
- Spelling fix in comment.
- Extract needs_modeset helper to consolidate the ->mode_changed ||
  ->active_changed checks.

v4: Fixup fumble between crtc->state and crtc_state.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      eab3bbef