All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Bobby Powers <bobbypowers@gmail.com>
Cc: Dave Airlie <airlied@gmail.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	daniel@ffwll.ch
Subject: Re: [Intel-gfx] [pull] drm-intel-next
Date: Fri, 14 Sep 2012 17:43:30 +0200	[thread overview]
Message-ID: <20120914154330.GA5799@phenom.ffwll.local> (raw)
In-Reply-To: <CAArOQ2UahPkBw9dxX7YQqGzDz6r0QgigjtEVoDTF6pS4=KQ-4w@mail.gmail.com>

On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote:
> This tree gives me recursive dependency problems, which ends up
> removing a big (& important) part of my .config:
> 
> [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09
> HEAD is now at e04190e drm/fb helper: don't call
> drm_helper_connector_dpms directly
> [bpowers@fina linux]$ git status
> # On branch master
> # Your branch and 'origin/master' have diverged,
> # and have 207 and 323 different commits each, respectively.
> #
> nothing to commit (working directory clean)
> [bpowers@fina linux]$ make oldconfig
> scripts/kconfig/conf --oldconfig Kconfig
> drivers/gpu/drm/udl/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/udl/Kconfig:1:	symbol DRM_UDL depends on USB_ARCH_HAS_HCD
> drivers/usb/Kconfig:76:	symbol USB_ARCH_HAS_HCD depends on USB_SUPPORT
> drivers/usb/Kconfig:58:	symbol USB_SUPPORT is selected by DRM_USB
> drivers/gpu/drm/Kconfig:22:	symbol DRM_USB is selected by DRM_UDL
> #
> # configuration written to .config
> #

That's an issue with Dave Airlie's udl code I'd say - the drm-intel-next
tree here simply includes a few drm-next patches already. Dave?
-Daniel

> 
> 
> I've attached my config & the diff between what is attached and the
> result of make oldconfig.  Let me know if there is any other info that
> would help, or if I'm just doing something boneheaded.  Thanks!
> 
> yours,
> Bobby
> 
> On Thu, Sep 13, 2012 at 10:18 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > Hi Dave,
> >
> > The big ticket item here is the new i915 modeset infrastructure.
> > Shockingly it didn't not blow up all over the place (i.e. I've managed to
> > fix the ugly issues before merging). 1-2 smaller corner cases broke, but
> > we have patches. Also, there's tons of patches on top of this that clean
> > out cruft and fix a few bugs that couldn't be fixed with the crtc helper
> > based stuff. So more stuff to come ;-)
> >
> > Also a few other things:
> > - Tiny fix in the fb helper to go through the official dpms interface
> >   instead of calling the crtc helper code.
> > - forcewake code frobbery from Ben, code should be more in-line with
> >   what Windows does now.
> > - fixes for the render ring flush on hsw (Paulo)
> > - gpu frequency tracepoint
> > - vlv forcewake changes to better align it with our understanding of the
> >   forcewake magic.
> > - a few smaller cleanups
> >
> > Cheers, Daniel
> >
> >
> > The following changes since commit d7c3b937bdf45f0b844400b7bf6fd3ed50bac604:
> >
> >   drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200)
> >
> > are available in the git repository at:
> >
> >   git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2012-09-09
> >
> > for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca:
> >
> >   drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 00:51:15 +0200)
> >
> > ----------------------------------------------------------------
> >
> > Ben Widawsky (5):
> >       drm/i915: Extract forcewake ack timeout
> >       drm/i915: use cpu_relax() in wait_for_atomic
> >       drm/i915: Change forcewake timeout to 2ms
> >       drm/i915: Never read FORCEWAKE
> >       drm/i915: Enable some sysfs stuff without CONFIG_PM
> >
> > Chris Wilson (1):
> >       drm/i915: Convert remaining debugfs iterators over rings to for_each_ring()
> >
> > Daniel Vetter (66):
> >       drm/ips: move drps/ips/ilk related variables into dev_priv->ips
> >       drm/i915: add a tracepoint for gpu frequency changes
> >       drm/i915: align vlv forcewake with common lore
> >       drm/i915: differ error message between forcwake timeouts
> >       drm/i915: add crtc->enable/disable vfuncs insted of dpms
> >       drm/i915: rip out crtc prepare/commit indirection
> >       drm/i915: add direct encoder disable/enable infrastructure
> >       drm/i915/hdmi: convert to encoder->disable/enable
> >       drm/i915/tv: convert to encoder enable/disable
> >       drm/i915/lvds: convert to encoder disable/enable
> >       drm/i915/dp: convert to encoder disable/enable
> >       drm/i915/crt: convert to encoder disable/enable
> >       drm/i915/sdvo: convert to encoder disable/enable
> >       drm/i915/dvo: convert to encoder disable/enable
> >       drm/i915: convert dpms functions of dvo/sdvo/crt
> >       drm/i915: rip out encoder->disable/enable checks
> >       drm/i915: clean up encoder_prepare/commit
> >       drm/i915: copy&paste drm_crtc_helper_set_config
> >       drm/i915: call set_base directly
> >       drm/i915: inline intel_best_encoder
> >       drm/i915: copy&paste drm_crtc_helper_set_mode
> >       drm/i915: simplify intel_crtc_prepare_encoders
> >       drm/i915: rip out encoder->prepare/commit
> >       drm/i915: call crtc functions directly
> >       drm/i915: WARN when trying to enabled an unused crtc
> >       drm/i915: Add interfaces to read out encoder/connector hw state
> >       drm/i915/dp: implement get_hw_state
> >       drm/i915/hdmi: implement get_hw_state
> >       drm/i915/tv: implement get_hw_state
> >       drm/i915/lvds: implement get_hw_state
> >       drm/i915/crt: implement get_hw_state
> >       drm/i915/sdvo: implement get_hw_state
> >       drm/i915/dvo: implement get_hw_state
> >       drm/i915: read out the modeset hw state at load and resume time
> >       drm/i915: check connector hw/sw state
> >       drm/i915: rip out intel_crtc->dpms_mode
> >       drm/i915: rip out intel_dp->dpms_mode
> >       drm/i915: ensure the force pipe A quirk is actually followed
> >       drm/i915: introduce struct intel_set_config
> >       drm/i915: extract modeset config save/restore code
> >       drm/i915: extract intel_set_config_compute_mode_changes
> >       drm/i915: extract intel_set_config_update_output_state
> >       drm/i915: implement crtc helper semantics relied upon by the fb helper
> >       drm/i915: don't update the fb base if there is no fb
> >       drm/i915: convert pointless error checks in set_config to BUGs
> >       drm/i915: don't save all the encoder/crtc state in set_config
> >       drm/i915: stage modeset output changes
> >       drm/i915: push crtc->fb update into pipe_set_base
> >       drm/i915: remove crtc disabling special case
> >       drm/i915: move output commit and crtc disabling into set_mode
> >       drm/i915: extract adjusted mode computation
> >       drm/i915: use staged outuput config in tv->mode_fixup
> >       drm/i915: use staged outuput config in lvds->mode_fixup
> >       drm/i915: compute masks of crtcs affected in set_mode
> >       drm/i915: implement new set_mode code flow
> >       drm/i915: push commit_output_state past crtc disabling
> >       drm/i915: s/intel_encoder_disable/intel_encoder_noop
> >       drm/i915: WARN if the pipe won't turn off
> >       drm/i915: switch the load detect code to the staged modeset config
> >       drm/i915: push commit_output_state past the crtc/encoder preparing
> >       drm/i915: disable all crtcs at suspend time
> >       drm/i915: no longer call drm_helper_resume_force_mode
> >       drm/i915: add tons of modeset state checks
> >       drm/i915: improve modeset state checking after dpms calls
> >       Merge the modeset-rework, basic conversion into drm-intel-next
> >       drm/fb helper: don't call drm_helper_connector_dpms directly
> >
> > Jani Nikula (2):
> >       drm/i915: only enable sdvo hotplug irq if needed
> >       drm/i915: fix sdvo hotplug support check and activation
> >
> > Paulo Zanoni (3):
> >       drm/i915: add gen7_render_ring_flush
> >       drm/i915: add workarounds directly to gen6_render_ring_flush
> >       drm/i915: add workarounds to gen7_render_ring_flush
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx




-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2012-09-14 15:43 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-13 14:18 [pull] drm-intel-next Daniel Vetter
2012-09-14 13:55 ` [Intel-gfx] " Bobby Powers
2012-09-14 15:43   ` Daniel Vetter [this message]
2012-09-14 19:52     ` Paulo Zanoni
2012-09-17 23:09 ` Daniel Vetter
2013-03-15  2:11 ` Stéphane Marchesin
2013-03-17 19:46   ` Daniel Vetter
2013-03-18 19:35     ` Stéphane Marchesin
2013-03-18 20:59       ` Daniel Vetter
2013-03-18 21:00         ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2023-11-23 19:03 [Intel-gfx] [PULL] drm-intel-next Jani Nikula
2023-11-23 19:39 ` Daniel Vetter
2023-10-19 16:18 Rodrigo Vivi
2023-10-12 13:42 Jani Nikula
2023-09-29 10:49 Jani Nikula
2023-08-10 19:53 Rodrigo Vivi
2023-08-03 18:56 Rodrigo Vivi
2023-06-05 14:20 Jani Nikula
2023-04-06 14:03 Rodrigo Vivi
2023-04-06 16:24 ` Daniel Vetter
2023-03-23 20:43 Rodrigo Vivi
2023-03-24 20:13 ` Daniel Vetter
2023-03-07 22:00 Rodrigo Vivi
2023-03-08 13:24 ` Rodrigo Vivi
2023-03-08 13:24   ` Rodrigo Vivi
2023-01-27 11:11 Jani Nikula
2023-01-12 12:06 Jani Nikula
2022-11-18 21:40 Rodrigo Vivi
2022-10-28 18:22 Rodrigo Vivi
2022-10-28 23:41 ` Ville Syrjälä
2022-10-28 23:41   ` Ville Syrjälä
2022-11-01 22:29   ` Vivi, Rodrigo
2022-11-01 22:29     ` Vivi, Rodrigo
2022-11-02  5:29     ` Ville Syrjälä
2022-11-02  5:29       ` Ville Syrjälä
2022-09-16 12:09 Jani Nikula
2022-08-29 13:22 Jani Nikula
2022-09-15 11:55 ` Jani Nikula
2022-07-07  3:04 Rodrigo Vivi
2022-06-22 19:53 Rodrigo Vivi
2022-05-06 10:47 Jani Nikula
2022-04-13 15:51 Jani Nikula
2022-02-23 23:29 Rodrigo Vivi
2022-02-08 14:58 Rodrigo Vivi
2021-12-14 15:37 Jani Nikula
2021-11-30 15:04 Jani Nikula
2021-10-15 18:45 Rodrigo Vivi
2021-10-04 19:01 Rodrigo Vivi
2021-08-10 13:51 Jani Nikula
2021-06-09 21:30 Rodrigo Vivi
2021-05-19 19:10 Rodrigo Vivi
2021-04-01  9:06 Jani Nikula
2021-03-16 16:24 Jani Nikula
2021-01-29 22:53 Rodrigo Vivi
2021-01-27 14:08 Rodrigo Vivi
2021-01-27 21:51 ` Ville Syrjälä
2021-01-12 17:51 Rodrigo Vivi
2021-01-04 21:10 Rodrigo Vivi
2021-01-07 12:02 ` Daniel Vetter
2020-09-18 17:30 Rodrigo Vivi
2020-08-26 23:27 Rodrigo Vivi
2020-07-15 13:19 Jani Nikula
2020-07-15 13:33 ` Jani Nikula
2020-07-15 14:05   ` Daniel Vetter
2020-07-02 18:29 Jani Nikula
2020-05-15 16:07 Joonas Lahtinen
2020-04-30 12:49 Joonas Lahtinen
2020-05-13 17:10 ` Joonas Lahtinen
2020-05-14  1:28   ` Dave Airlie
2020-05-14 14:55     ` Joonas Lahtinen
2020-04-17 11:15 Joonas Lahtinen
2020-02-25 18:58 Rodrigo Vivi
2020-01-14 11:43 Jani Nikula
2020-01-14 12:05 ` Chris Wilson
2020-01-14 12:15   ` Jani Nikula
2019-12-23 17:53 Jani Nikula
2019-11-01 10:47 Joonas Lahtinen
2019-11-01 10:47 ` Joonas Lahtinen
2015-12-22 10:37 Daniel Vetter
2015-12-22 14:05 ` Daniel Vetter
2015-12-22 14:31   ` Chris Wilson
2015-12-22 16:31     ` [Intel-gfx] " Tvrtko Ursulin
2015-12-23 10:09       ` Chris Wilson
2014-04-28 13:26 Daniel Vetter
2014-05-06 13:08 ` [Intel-gfx] " Knut Petersen
2014-05-06 13:30   ` Jani Nikula
2014-05-06 18:59     ` Daniel Vetter
2014-05-06 20:04       ` Knut Petersen
2014-05-06 20:17         ` [Intel-gfx] " Daniel Vetter
2012-01-05  3:35 Keith Packard
2012-01-05 15:24 ` Daniel Vetter
2012-01-05 17:58   ` [Intel-gfx] " Ben Widawsky
2012-01-05 18:02   ` Jesse Barnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120914154330.GA5799@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@gmail.com \
    --cc=bobbypowers@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.