[Bug 87568] WebGL can cause GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=87568 --- Comment #3 from almos --- (In reply to Ian Romanick from comment #1) > It can be impossible to tell the difference between a draw that will take a > very long time and a draw that will never complete, so possibly not. See > also http://en.wikipedia.org/wiki/Halting_problem. That's why WebGL was a bad idea in the first place. As far as I can remember the timeout was 1 second, but since then I upgraded my system, kernel included, and when I tried now the timeout was 10s. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150117/73c1569d/attachment.html>
[Bug 88522] unreal effectscave demo locks up gpu
:00.0: R_008680_CP_STAT = 0x80268647 [760744.522087] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [760744.522255] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [760744.522310] radeon :01:00.0: SRBM_SOFT_RESET=0x0100 [760744.523469] radeon :01:00.0: GRBM_STATUS = 0x3828 [760744.523471] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [760744.523475] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [760744.523477] radeon :01:00.0: SRBM_STATUS = 0x20C0 [760744.523479] radeon :01:00.0: SRBM_STATUS2 = 0x [760744.523481] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [760744.523483] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [760744.523486] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [760744.523488] radeon :01:00.0: R_008680_CP_STAT = 0x [760744.523490] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [760744.523525] radeon :01:00.0: GPU reset succeeded, trying to resume [760744.535154] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [760744.538833] [drm] PCIE GART of 1024M enabled (table at 0x00273000). [760744.538926] radeon :01:00.0: WB enabled [760744.538929] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88041e6dbc00 [760744.538931] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x88041e6dbc0c [760744.540384] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc900120b2118 [760744.556776] [drm] ring test on 0 succeeded in 2 usecs [760744.556787] [drm] ring test on 3 succeeded in 7 usecs [760744.734161] [drm] ring test on 5 succeeded in 2 usecs [760744.734170] [drm] UVD initialized successfully. [760744.734257] [drm] ib test on ring 0 succeeded in 0 usecs [760744.734340] [drm] ib test on ring 3 succeeded in 0 usecs [760744.885694] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to get create msg (-22). [760744.885701] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-22). [760744.885793] switching from power state: [760744.885797] ui class: none [760744.885798] internal class: boot [760744.885799] caps: [760744.885801] uvdvclk: 0 dclk: 0 [760744.885802] power level 0sclk: 1 mclk: 3 vddc: 950 vddci: 950 [760744.885803] power level 1sclk: 1 mclk: 3 vddc: 950 vddci: 950 [760744.885804] power level 2sclk: 1 mclk: 3 vddc: 950 vddci: 950 [760744.885805] status: c b [760744.885806] switching to power state: [760744.885807] ui class: performance [760744.885808] internal class: none [760744.885808] caps: [760744.885809] uvdvclk: 0 dclk: 0 [760744.885810] power level 0sclk: 1 mclk: 15000 vddc: 950 vddci: 950 [760744.885811] power level 1sclk: 6 mclk: 10 vddc: 1100 vddci: 1100 [760744.885812] power level 2sclk: 86000 mclk: 11 vddc: 1150 vddci: 1100 [760744.885813] status: r This is with AMD Barts (HD6850), kernel is 3.17.7, mesa 10.3.2 and 10.5-dev. I also tried the Realistic Rendering demo, and it works fine (with mesa 10.1 it was completely blue, but it has been fixed). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150117/51d82b09/attachment-0001.html>
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
On Fri, Jan 16, 2015 at 03:53:04PM +0100, Thierry Reding wrote:
> On Fri, Jan 16, 2015 at 03:35:10PM +0100, Thierry Reding wrote:
> > On Tue, Nov 25, 2014 at 01:26:34PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 25, 2014 at 12:57:04PM +0100, Thierry Reding wrote:
> > > > On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> > > > > On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > > > > > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> > > > [...]
> > > > > > > +/*
> > > > > > > + * drm_plane_disabled - check whether a plane is being disabled
> > > > > > > + * @plane: plane object
> > > > > > > + * @old_state: previous atomic state
> > > > > > > + *
> > > > > > > + * Checks the atomic state of a plane to determine whether it's
> > > > > > > being disabled
> > > > > > > + * or not. This also WARNs if it detects an invalid state (both
> > > > > > > CRTC and FB
> > > > > > > + * need to either both be NULL or both be non-NULL).
> > > > > > > + *
> > > > > > > + * RETURNS:
> > > > > > > + * True if the plane is being disabled, false otherwise.
> > > > > > > + */
> > > > > > > +static inline bool drm_plane_disabled(struct drm_plane *plane,
> > > > > > > + struct drm_plane_state *old_state)
> > > > > > > +{
> > > > [...]
> > > > > > > + return (!old_state || old_state->crtc) && !plane->state->crtc;
> > > > > >
> > > > > > The !old_state check here confused me a bit, until I've realized
> > > > > > that you
> > > > > > use this for transitional helpers too. What about adding
> > > > > >
> > > > > > /* Cope with NULL old_state for transitional helpers. */
> > > > > >
> > > > > > right above?
> > > > >
> > > > > Sounds good.
> > > >
> > > > When I now thought about the reason again it took me a while to
> > > > reconstruct, so I figured I'd be extra verbose and used this:
> > > >
> > > > /*
> > > > * When using the transitional helpers, old_state may be NULL. If so,
> > > > * we know nothing about the current state and have to assume that it
> > > > * might be enabled.
> > > > */
> > > >
> > > > Does that sound accurate and sufficient to you?
> > >
> > > 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)
>
> So I think the comment below that I proposed earlier is the best we can
> do.
>
> /*
> * When using the transitional helpers, old_state may be NULL. If so,
> * we know nothing about the current state an
[PATCH 2/2] drm/msm/mdp5: Add hardware cursor support
On Thu, Jan 15, 2015 at 08:46:46AM -0500, Rob Clark wrote: > On Wed, Jan 14, 2015 at 7:55 PM, Daniel Vetter wrote: > > On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote: > >> From: Beeresh Gopal > >> > >> This patch implements the hardware accelarated cursor > >> support for MDP5 platforms. > >> > >> Signed-off-by: Beeresh Gopal > >> Signed-off-by: Wentao Xu > >> Signed-off-by: Stephane Viau > > > > Imo implementing legacy cursor support instead of with universal planes > > makes no sense. Especially since msm is converted to atomic already, and > > you can't move the cursor with atomic when it's legacy only. See the > > cursor argument for the drm_crtc_init_with_planes function and how it's > > used in e.g. i915. > > > > well, I'm still not 100% convinced about going through the whole > atomic mechanism for cursors.. in particular stuff that tries to > enable/disable the cursor at 1000fps, goes *really* badly when things > start waiting for vsync. > > I'll probably try some experiments with it at some point, but at this > point something that works with x11 is a lot more interesting for me > (since every time I switch from mdp4 device to mdp5 device I forget to > disable hw cursor the first time I start x) Well for one this uses the legacy cursor callbacks directly, at least a cursor plane is imo in order. Otoh we just need to fix up the cursor atomic implementation to allow drivers to do fully async updates which get merged down to one update. Which Ville's original atomic stuff already had. So all recoverable by adding a flag somewhere and setting that in the plane_update-on-atomic function. Merging legacy code just because the new stuff isn't 100% perfect yet imo just doesn't make that much sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 3/6] drm/plane: Add optional ->atomic_disable() callback
On January 17, 2015 4:48:53 AM Daniel Vetter wrote:
> On Fri, Jan 16, 2015 at 03:53:04PM +0100, Thierry Reding wrote:
> > On Fri, Jan 16, 2015 at 03:35:10PM +0100, Thierry Reding wrote:
> > > On Tue, Nov 25, 2014 at 01:26:34PM +0100, Daniel Vetter wrote:
> > > > On Tue, Nov 25, 2014 at 12:57:04PM +0100, Thierry Reding wrote:
> > > > > On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> > > > > > On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > > > > > > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> > > > > [...]
> > > > > > > > +/*
> > > > > > > > + * drm_plane_disabled - check whether a plane is being disabled
> > > > > > > > + * @plane: plane object
> > > > > > > > + * @old_state: previous atomic state
> > > > > > > > + *
> > > > > > > > + * Checks the atomic state of a plane to determine whether
> it's being disabled
> > > > > > > > + * or not. This also WARNs if it detects an invalid state
> (both CRTC and FB
> > > > > > > > + * need to either both be NULL or both be non-NULL).
> > > > > > > > + *
> > > > > > > > + * RETURNS:
> > > > > > > > + * True if the plane is being disabled, false otherwise.
> > > > > > > > + */
> > > > > > > > +static inline bool drm_plane_disabled(struct drm_plane *plane,
> > > > > > > > + struct drm_plane_state *old_state)
> > > > > > > > +{
> > > > > [...]
> > > > > > > > + return (!old_state || old_state->crtc) && !plane->state->crtc;
> > > > > > >
> > > > > > > The !old_state check here confused me a bit, until I've
> realized that you
> > > > > > > use this for transitional helpers too. What about adding
> > > > > > >
> > > > > > > /* Cope with NULL old_state for transitional helpers. */
> > > > > > >
> > > > > > > right above?
> > > > > >
> > > > > > Sounds good.
> > > > >
> > > > > When I now thought about the reason again it took me a while to
> > > > > reconstruct, so I figured I'd be extra verbose and used this:
> > > > >
> > > > > /*
> > > > > * When using the transitional helpers, old_state may be NULL. If so,
> > > > > * we know nothing about the current state and have to assume that it
> > > > > * might be enabled.
> > > > > */
> > > > >
> > > > > Does that sound accurate and sufficient to you?
> > > >
> > > > 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
[PATCH RESEND] drm: tda998x: Use drm_do_get_edid()
On Fri, 16 Jan 2015 17:47:34 + Russell King - ARM Linux wrote: > Thanks, committed, and updated the summary line to: > > "drm/i2c: tda998x: use drm_do_get_edid()" > > to match the style used in the past. You also committed 2 fixes of mine on the tda998x, but I could not retrieve them in linux-next nor elsewhere. I will soon resubmit a new patch of the tda998x codec. I could base it on linux-next or Mark's ASoC reference, but basing it on your tda998x version would avoid you to merge... -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #31 from kb at spatium.org --- Christian, do you have any further ideas? Can perhaps the ref_div_max be settable via sysfs so that I can cap it on boot? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] drm/msm/mdp5: Add hardware cursor support
On Fri, Jan 16, 2015 at 11:06 PM, Daniel Vetter wrote: > On Thu, Jan 15, 2015 at 08:46:46AM -0500, Rob Clark wrote: >> On Wed, Jan 14, 2015 at 7:55 PM, Daniel Vetter wrote: >> > On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote: >> >> From: Beeresh Gopal >> >> >> >> This patch implements the hardware accelarated cursor >> >> support for MDP5 platforms. >> >> >> >> Signed-off-by: Beeresh Gopal >> >> Signed-off-by: Wentao Xu >> >> Signed-off-by: Stephane Viau >> > >> > Imo implementing legacy cursor support instead of with universal planes >> > makes no sense. Especially since msm is converted to atomic already, and >> > you can't move the cursor with atomic when it's legacy only. See the >> > cursor argument for the drm_crtc_init_with_planes function and how it's >> > used in e.g. i915. >> > >> >> well, I'm still not 100% convinced about going through the whole >> atomic mechanism for cursors.. in particular stuff that tries to >> enable/disable the cursor at 1000fps, goes *really* badly when things >> start waiting for vsync. >> >> I'll probably try some experiments with it at some point, but at this >> point something that works with x11 is a lot more interesting for me >> (since every time I switch from mdp4 device to mdp5 device I forget to >> disable hw cursor the first time I start x) > > Well for one this uses the legacy cursor callbacks directly, at least a > cursor plane is imo in order. > > Otoh we just need to fix up the cursor atomic implementation to allow > drivers to do fully async updates which get merged down to one update. > Which Ville's original atomic stuff already had. So all recoverable by > adding a flag somewhere and setting that in the plane_update-on-atomic > function. something that could merge multiple intra-vsync updates would, I think, make cursor planes usable > Merging legacy code just because the new stuff isn't 100% perfect yet imo > just doesn't make that much sense. but merging legacy because new stuff isn't usable yet does ;-) BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 64449] AMD graphics hardware hangs with an homogeneous coloured screen or blank screen, and with chirp coming from the graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=64449 Alberto Salvia Novella changed: What|Removed |Added Summary|xorg hangs randomly with|AMD graphics hardware hangs |Radeon HD 7450A |with an homogeneous ||coloured screen or blank ||screen, and with chirp ||coming from the graphics ||card -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150117/7680c1a9/attachment.html>
[Bug 64449] xorg hangs randomly with Radeon HD 7450A
https://bugs.freedesktop.org/show_bug.cgi?id=64449 Alberto Salvia Novella changed: What|Removed |Added Priority|medium |highest URL||https://bugs.launchpad.net/ ||ubuntu/+source/xserver-xorg ||-video-ati/+bug/881526 CC||es20490446e at gmail.com Component|Drivers/Gallium/r600|GLX Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Summary|AMD graphics hardware hangs |xorg hangs randomly with |with an homogeneous |Radeon HD 7450A |coloured screen or blank| |screen, and with chirp | |coming from the graphics| |card| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150117/b7fcc4db/attachment.html>
[PATCH 00/72] staging imx-drm new features and fixes
Hi Steve, On Tue, Nov 4, 2014 at 11:20 PM, Steve Longerbeam wrote: > Well, if you think imx-drm is ready to be moved out of staging, then > let's do that first. I will resubmit the imx-drm patches after the move > is merged. > The fixes that are important in terms of multi-display, upping channel > priorities, stability (irq ordering, locking), and better video mode support > are: Yes, these are all very good material. > > ARM: i.MX6: use pll2_pfd0_352m as clock root of ipu_di > gpu: ipu-v3: Implement use counter for ipu_dc_enable(), ipu_dc_disable() > gpu: ipu-v3: Split out DI clock enable/disable > gpu: ipu-v3: Protect more CM reg access with IPU lock > gpu: ipu-v3: Move DI waveform counter enable/disable to ipu-di > gpu: ipu-v3: Allow burstsize of 20 in ipu_dmfc_setup_channel() > gpu: ipu-di: Set rate of DI pre clock > imx-drm: hdmi: rework irq request/free > imx-drm: hdmi: set DI clock source to DI pre clock > imx-drm: ipuv3-plane: Assign correct dmfc burst size > imx-drm: ipuv3-crtc: Disable overlay plane during crtc disable > imx-drm: ipuv3-plane: Enable 8 burst locking > > > But in any case, I'd prefer if we just wait until imx-drm is moved > and then I will resubmit the imx-drm patches, and in the meantime > I will go ahead and resubmit only the IPU patches. imx-drm has moved out of staging. Do you plan to re-submit this series? Thanks, Fabio Estevam
[PATCH v2] drm: imx: imx-tve: Check and propagate the errors
From: Fabio Estevam In the case of errors we should propagate them. Signed-off-by: Fabio Estevam --- Changes since v1: - Fixed a typo on my FSL address drivers/gpu/drm/imx/imx-tve.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c index a729f4f7..a281723 100644 --- a/drivers/gpu/drm/imx/imx-tve.c +++ b/drivers/gpu/drm/imx/imx-tve.c @@ -191,10 +191,18 @@ static int tve_setup_vga(struct imx_tve *tve) /* set gain to (1 + 10/128) to provide 0.7V peak-to-peak amplitude */ ret = regmap_update_bits(tve->regmap, TVE_TVDAC0_CONT_REG, TVE_TVDAC_GAIN_MASK, 0x0a); + if (ret) + return ret; + ret = regmap_update_bits(tve->regmap, TVE_TVDAC1_CONT_REG, TVE_TVDAC_GAIN_MASK, 0x0a); + if (ret) + return ret; + ret = regmap_update_bits(tve->regmap, TVE_TVDAC2_CONT_REG, TVE_TVDAC_GAIN_MASK, 0x0a); + if (ret) + return ret; /* set configuration register */ mask = TVE_DATA_SOURCE_MASK | TVE_INP_VIDEO_FORM; @@ -210,10 +218,8 @@ static int tve_setup_vga(struct imx_tve *tve) } /* set test mode (as documented) */ - ret = regmap_update_bits(tve->regmap, TVE_TST_MODE_REG, + return regmap_update_bits(tve->regmap, TVE_TST_MODE_REG, TVE_TVDAC_TEST_MODE_MASK, 1); - - return 0; } static enum drm_connector_status imx_tve_connector_detect( @@ -671,6 +677,8 @@ static int imx_tve_bind(struct device *dev, struct device *master, void *data) /* disable cable detection for VGA mode */ ret = regmap_write(tve->regmap, TVE_CD_CONT_REG, 0); + if (ret) + return ret; ret = imx_tve_register(drm, tve); if (ret) -- 1.9.1
[PATCH] drm: sti: fix check for clk_pix_main
copy-paste wasn't followed by editing, do it.
Signed-off-by: Jassi Brar
---
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index f3db05d..b0eb62d 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1025,7 +1025,7 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
/* Get clock resources */
hqvdp->clk = devm_clk_get(dev, "hqvdp");
hqvdp->clk_pix_main = devm_clk_get(dev, "pix_main");
- if (IS_ERR(hqvdp->clk) || IS_ERR(hqvdp->clk)) {
+ if (IS_ERR(hqvdp->clk) || IS_ERR(hqvdp->clk_pix_main)) {
DRM_ERROR("Cannot get clocks\n");
return -ENXIO;
}
--
1.9.1
[BUG, bisect] drm/i915: mouse pointer lags and overshoots
Matt, all, Commit ea2c67bb4aff introduces a bug which causes the mouse to move in a very unusual way, as if it has a lot of inertia. It will lag behind and then overshoot the expected position. I reproduced this bug on all my machines which use the drm/i915 drivers and it affects all forms of mouse pointers including both touchpads and usb mice. The patch is present in linux-next 20150116. commit ea2c67bb4affa84080c616920f3899f123786e56 Author: Matt Roper Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) Switch plane handling to use the atomic plane helpers. This means that rather than provide our own implementations of .update_plane() and .disable_plane(), we expose the lower-level check/prepare/commit/cleanup entrypoints and let the DRM core implement update/disable for us using those entrypoints. The other main change that falls out of this patch is that our drm_plane's will now always have a valid plane->state that contains the relevant plane state (initial state is allocated at plane creation). The base drm_plane_state pointed to holds the requested source/dest coordinates, and the subclassed intel_plane_state holds the adjusted values that our driver actually uses. v2: - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel) - Fix a copy/paste comment mistake (Bob) v3: - Use prepare/cleanup functions that we've already factored out - Use newly refactored pre_commit/commit/post_commit to avoid sleeping during vblank evasion v4: - Rebase to latest di-nightly requires adding an 'old_state' parameter to atomic_update; v5: - Must have botched a rebase somewhere and lost some work. Restore state 'dirty' flag to let begin/end code know which planes to run the pre_commit/post_commit hooks for. This would have actually shown up as broken in the next commit rather than this one. v6: - Squash kerneldoc patch into this one. - Previous patches have now already taken care of most of the infrastructure that used to be in this patch. All we're adding here now is some thin wrappers. v7: - Check return of intel_plane_duplicate_state() for allocation failures. v8: - Drop unused drm_plane_state -> intel_plane_state cast. (Ander) - Squash in actual transition to plane helpers. Significant refactoring earlier in the patchset has made the combined prep+transition much easier to swallow than it was in earlier iterations. (Ander) v9: - s/track_fbs/disabled_planes/ in the atomic crtc flags. The only fb's we need to update frontbuffer tracking for are those on a plane about to be disabled (since the atomic helpers never call prepare_fb() when disabling a plane), so the new name more accurately describes what we're actually tracking. Testcase: igt/kms_plane Testcase: igt/kms_universal_plane Testcase: igt/kms_cursor_crc Signed-off-by: Matt Roper Reviewed-by: Ander Conselvan de Oliveira Signed-off-by: Daniel Vetter -- - Jeremiah Mahler
