Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format
On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>
> 從我的 iPad 傳送
>
> > Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
> >
> > > On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
> > >
> > >
> > > 從我的 iPad 傳送
> > >
> > > > > Ville Syrjälä 於 2017年3月6日 下午9:06 寫道：
> > > > >
> > > > > On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
> > > > > P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> > > > > per channel video format.
> > > > >
> > > > > P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
> > > > > per channel video format.
> > > > >
> > > > > V3: Added P012 and fixed cpp for P010
> > > > > V4: format definition refined per review
> > > > > V5: Format comment block for each new pixel format
> > > > > V6: reversed Cb/Cr order in comments
> > > > > v7: reversed Cb/Cr order in comments of header files, remove
> > > > > the wrong part of commit message.
> > > >
> > > > What? Why? You just undid what Clint did in v6.
> > >
> > > He missed a file also keeping the wrong description of rockchip.
> >
> > I don't follow. Who missed what exactly?
>
> What he sent is v5, I increase the order number twice in the message, it
> confuse me as well.
> I think Clint forgot the include/uapi/drm/drm_fourcc.h .
Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":
https://patchwork.freedesktop.org/patch/141342/
Ander
> >
> >
> > > >
> > > > >
> > > > > Cc: Daniel Stone
> > > > > Cc: Ville Syrjälä
> > > > >
> > > > > Signed-off-by: Randy Li
> > > > > Signed-off-by: Clint Taylor
> > > > > ---
> > > > > drivers/gpu/drm/drm_fourcc.c | 3 +++
> > > > > include/uapi/drm/drm_fourcc.h | 21 +
> > > > > 2 files changed, 24 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > index 90d2cc8..3e0fd58 100644
> > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > > @@ -165,6 +165,9 @@ const struct drm_format_info
> > > > > *__drm_format_info(u32 format)
> > > > > { .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes =
> > > > > 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > > > > { .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes =
> > > > > 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > > > > { .format = DRM_FORMAT_AYUV,.depth = 0, .num_planes =
> > > > > 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > > > > +{ .format = DRM_FORMAT_P010,.depth = 0, .num_planes
> > > > > = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> > > > > +{ .format = DRM_FORMAT_P012,.depth = 0, .num_planes
> > > > > = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> > > > > +{ .format = DRM_FORMAT_P016,.depth = 0, .num_planes
> > > > > = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> > > > > };
> > > > >
> > > > > unsigned int i;
> > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > index ef20abb..306f979 100644
> > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > @@ -128,6 +128,27 @@ extern "C" {
> > > > > #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
> > > > > non-subsampled Cb:Cr plane */
> > > > >
> > > > > /*
> > > > > + * 2 plane YCbCr MSB aligned
> > > > > + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> > > > > + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
> > > > > + */
> > > > > +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /*
> > > > > 2x2 subsampled Cb:Cr plane 10 bits per channel */
> > > > > +
> > > > > +/*
> > > > > + * 2 plane YCbCr MSB aligned
> > > > > + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> > > > > + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
> > > > > + */
> > > > > +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /*
> > > > > 2x2 subsampled Cb:Cr plane 12 bits per channel */
> > > > > +
> > > > > +/*
> > > > > + * 2 plane YCbCr MSB aligned
> > > > > + * index 0 = Y plane, [15:0] Y little endian
> > > > > + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
> > > > > + */
> > > > > +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /*
> > > > > 2x2 subsampled Cb:Cr plane 16 bits per channel */
> > > > > +
> > > > > +/*
> > > > > * 3 plane YCbCr
> > > > > * index 0: Y plane, [7:0] Y
> > > > > * index 1: Cb plane, [7:0] Cb
> > > > > --
> > > > > 2.7.4
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel OTC
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Avoid drm_atomic_state_put(NULL) in intel_display_resume
On Sun, 2017-01-15 at 12:58 +, Chris Wilson wrote:
> intel_display_resume() may be called without a atomic state to restore,
> i.e. dev_priv->modeset_reset_restore state is NULL. One such case is
> following a lid open/close event and the forced modeset in
> intel_lid_notiy().
>
> Reported-by: Stefan Seyfried
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: # v4.10-rc1+
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3dc8724df400..260bbe8881e6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -17024,7 +17024,8 @@ void intel_display_resume(struct drm_device *dev)
>
> if (ret)
> DRM_ERROR("Restoring old state failed with %i\n", ret);
> - drm_atomic_state_put(state);
> + if (state)
> + drm_atomic_state_put(state);
> }
>
> void intel_modeset_gem_init(struct drm_device *dev)
Reviewed-by: Ander Conselvan de Oliveira
Re: Shared scaffolding to unit-test kernel code in userspace (was Re: [Intel-gfx] [PATCH] drm/i915: Add link training test)
On Wed, 2015-09-23 at 11:38 +0200, Daniel Vetter wrote: > On Wed, Sep 23, 2015 at 11:18 AM, Ander Conselvan De Oliveira > wrote: > > On Wed, 2015-09-23 at 10:24 +0200, Daniel Vetter wrote: > > > On Tue, Sep 15, 2015 at 04:08:53PM +0300, Ander Conselvan De Oliveira > > > wrote: > > > > On Mon, 2015-09-14 at 16:38 +0300, Ander Conselvan De Oliveira wrote: > > > > > On Mon, 2015-09-14 at 15:11 +0200, Daniel Vetter wrote: > > > > > > On Mon, Sep 14, 2015 at 02:51:51PM +0300, Ander Conselvan de > > > > > > Oliveira wrote: > > > > > > > --- > > > > > > > > > > > > > > On Fri, 2015-09-11 at 17:11 +0300, Ander Conselvan de Oliveira > > > > > > > wrote: > > > > > > > > On Wed, 2015-09-09 at 11:33 +0100, Thomas Wood wrote: > > > > > > > > > On 8 September 2015 at 13:28, Ander Conselvan de Oliveira > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/link-training-test/Makefile > > > > > > > > > > b/link-training-test/Makefile > > > > > > > > > > > > > > > > > > If this is meant to be part of the test suite, then it needs > > > > > > > > > to be in > > > > > > > > > the tests directory and use the igt test infrastructure. > > > > > > > > > Otherwise it > > > > > > > > > should be placed in tools or tools/link-training-test. > > > > > > > > > > > > > > > > I made the test use the igt infrastructure, but I'm not sure if > > > > > > > > this is > > > > > > > > a good fit for it. The dependency on the kernel is on build > > > > > > > > time, but > > > > > > > > once compiled this can be run on any machine. This can also > > > > > > > > introduce > > > > > > > > build failures if the test is not kept in sync with the driver > > > > > > > > source. > > > > > > > > Ideally that a failure to build this would be reported as the > > > > > > > > test > > > > > > > > failing, but I have no idea of how to achieve that. > > > > > > > > > > > > > > Alternatively, this could be in the kernel source tree directly. > > > > > > > This > > > > > > > patch adds a test subdir to the i915 source dir, containing the > > > > > > > link > > > > > > > training test. The test is compiled as part of the normal build > > > > > > > using > > > > > > > the extra-y variable so that it doesn't get linked to the final > > > > > > > kernel. > > > > > > > > > > > > > > When make is run from the tests directory, a thin wrapper around > > > > > > > the > > > > > > > tests is built and linked to the object file compiled as part of > > > > > > > the > > > > > > > kernel build. Running make run_tests from the test dir runs the > > > > > > > test > > > > > > > and reports success or failure. > > > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > I think there's some precedence in other subsystems to integrate > > > > > > unit > > > > > > tests directly in the kernel, e.g. locking selftest or similar > > > > > > things. > > > > > > Usual approach is to either have a special module (but that often > > > > > > means > > > > > > piles of EXPORT_SYMBOL only for that selftest module). Or just a y/n > > > > > > Kconfig option which enables that code and runs all the self/unit > > > > > > tests > > > > > > when the module loads. > > > > > > > > > > > > I'd go with that approach since it's simpler. And we'd only need to > > > > > > tell > > > > > > QA to enable that Kconfig option for more testing. > > > > > > > > > > I'll have a look into that Kconfig a
Re: [Intel-gfx] [PATCH] drm/i915: Clear pipe's pll hw state in hsw_dp_set_ddi_pll_sel()
On Tue, 2015-06-30 at 18:41 +0300, Jani Nikula wrote: > On Tue, 30 Jun 2015, Daniel Vetter wrote: > > On Tue, Jun 30, 2015 at 04:47:06PM +0300, Jani Nikula wrote: > >> On Tue, 30 Jun 2015, Ander Conselvan de Oliveira > >> wrote: > >> > Similarly to what is done for SKL, clear the dpll_hw_state of the pipe > >> > config in hsw_dp_set_ddi_pll_sel(), since it main contain stale values. > >> > That can happen if a crtc that was previously driving an HDMI connector > >> > switches to a DP connector. In that case, the wrpll field was left with > >> > its old value, leading to warnings like the one below: > >> > > >> > [drm:check_crtc_state [i915]] *ERROR* mismatch in dpll_hw_state.wrpll > >> > (expected 0xb035061f, found 0x) > >> > [ cut here ] > >> > WARNING: CPU: 1 PID: 767 at drivers/gpu/drm/i915/intel_display.c:12324 > >> > check_crtc_state+0x975/0x10b0 [i915]() > >> > pipe state doesn't match! > >> > > >> > This regression was indroduced in > >> > > >> > commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5 > >> > Author: Ander Conselvan de Oliveira > >> > > >> > Date: Fri May 15 13:34:29 2015 +0300 > >> > > >> > drm/i915: Don't overwrite (e)DP PLL selection on SKL > >> > > >> > Signed-off-by: Ander Conselvan de Oliveira > >> > > >> > >> Reported-by: Linus Torvalds > >> Tested-by: Jani Nikula > > > > Yeah makes sense as a fix for 4.2. But for 4.3 I wonder whether the > > original commit that started this chain needs to be changed a bit: > > > > commit 4978cc93d9ac240b435ce60431aef24239b4c270 > > Author: Ander Conselvan de Oliveira > > Date: Tue Apr 21 17:13:21 2015 +0300 > > > > drm/i915: Preserve shared DPLL information in new pipe_config > > > > All the trouble this caused is because it not only preserves the sharing > > config (in crtc_state->shared_dpll) but also the ->dpll_hw_state. And I > > think with Maarten's latest code (for 4.3) we'd just do an unconditional > > compute_config (need it for fast pfit updates and fastboot), which means > > the bogus values in ->dpll_hw_state aren't a problem any more since we'll > > overwrite them again. And then we could remove that sprinkle of memsets we > > have all over, which would be good (since the current approach is > > obviously a bit fragile). Anyway: > > > > Reviewed-by: Daniel Vetter > > Pushed to drm-intel-next-fixes, thanks for the patch and review. One > down, another one left to fix. I made some progress on the second issue, but I'm afraid Jani might have a found a third bug. The warning he gets happens because we try to wait for vblanks while updating the primary plane during the modeset. At that point, the crtc is off. The problem is in intel_check_primary_plane(), which is called from drm_atomic_helper_check_planes(). That function makes decisions about waiting for a vblank based on intel_crtc->active. Since the check is called before we disable the crtcs, active might be true, even though the plane update is done with crtcs disable. The patch below makes the warning go away, but I still need to figure out how to set crtc_state->planes_changed properly if we are going down that route. diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index dcb1d25..f14727c 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12480,10 +12480,6 @@ intel_modeset_compute_config(struct drm_crtc *crtc, intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,"[modeset]"); - ret = drm_atomic_helper_check_planes(state->dev, state); - if (ret) - return ERR_PTR(ret); - return pipe_config; } The backtrace on Linus' machine is different, though. It comes from the call to intel_crtc_disable_planes() in __intel_set_mode(). That would indicate we have a crtc with crtc->state->enable == true but that is actually inactive. I'm still not sure how we can get in that state. Ander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/i915: Clear pipe's pll hw state in hsw_dp_set_ddi_pll_sel()
Similarly to what is done for SKL, clear the dpll_hw_state of the pipe
config in hsw_dp_set_ddi_pll_sel(), since it main contain stale values.
That can happen if a crtc that was previously driving an HDMI connector
switches to a DP connector. In that case, the wrpll field was left with
its old value, leading to warnings like the one below:
[drm:check_crtc_state [i915]] *ERROR* mismatch in dpll_hw_state.wrpll (expected
0xb035061f, found 0x)
[ cut here ]
WARNING: CPU: 1 PID: 767 at drivers/gpu/drm/i915/intel_display.c:12324
check_crtc_state+0x975/0x10b0 [i915]()
pipe state doesn't match!
This regression was indroduced in
commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5
Author: Ander Conselvan de Oliveira
Date: Fri May 15 13:34:29 2015 +0300
drm/i915: Don't overwrite (e)DP PLL selection on SKL
Signed-off-by: Ander Conselvan de Oliveira
---
Only compile tested, for the wrpll warning.
Thanks,
Ander
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..fbd9ac3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1147,6 +1147,9 @@ skl_edp_set_pll_config(struct intel_crtc_state
*pipe_config, int link_clock)
static void
hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config, int link_bw)
{
+ memset(&pipe_config->dpll_hw_state, 0,
+ sizeof(pipe_config->dpll_hw_state));
+
switch (link_bw) {
case DP_LINK_BW_1_62:
pipe_config->ddi_pll_sel = PORT_CLK_SEL_LCPLL_810;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote: > On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote: > > > > This is the main drm pull request for v4.2. > > It seems to work ok for me, but it causes quite a few new warnings on > my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka > Haswell, aka 4th gen Intel Core i5) > > Most of them are in check_crtc_state(), and I currently have 18 of > these in my log: > > [drm:check_crtc_state [i915]] *ERROR* mismatch in > dpll_hw_state.wrpll (expected 0x90280202, found 0x) > WARNING: CPU: 0 PID: 115 at > drivers/gpu/drm/i915/intel_display.c:12319 > check_crtc_state+0x8be/0xf60 [i915]() > pipe state doesn't match! > > but there's a few others too: > > WARNING: CPU: 3 PID: 1871 at > drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160 > [i915]() > plane A assertion failure (expected on, current off) > > WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162 > drm_wait_one_vblank+0x148/0x1a0 [drm]() > vblank not available on crtc 0, ret=-22 > > and the backtraces aren't all that interesting, but I'm attaching the > cleaned-up dmesg, duplicate callchains and all. Please provide a full dmesg with drm.debug=0x1f in the kernel command line. Thanks, Ander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: Re: [PATCH] drm/i915: Properly initialize SDVO analog connectors]
Thanks for testing. Forwarded Message From: Stefan Lippers-Hollmann To: Ander Conselvan de Oliveira Subject: Re: [PATCH] drm/i915: Properly initialize SDVO analog connectors Date: Mon, 8 Jun 2015 12:16:04 +0200 Hi On 2015-06-08, Ander Conselvan de Oliveira wrote: > In the commit below, I missed the connector allocation in the function > intel_sdvo_analog_init(), leading to those connectors to have a NULL > state pointer. Thanks a lot, this patch is working (on top of 4.1-rc7). > commit 08d9bc920d465d762cac9383249c19bf69a2 > Author: Ander Conselvan de Oliveira > Date: Fri Apr 10 10:59:10 2015 +0300 > > drm/i915: Allocate connector state together with the connectors > > Signed-off-by: Ander Conselvan de Oliveira Feel free to add: Tested-by: Stefan Lippers-Hollmann Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git pull] drm for v4.1-rc1
On Mon, 2015-06-08 at 11:06 +0300, Ander Conselvan De Oliveira wrote: > On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote: > > Hi > > > > On 2015-06-07, Ville Syrjälä wrote: > > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote: > > > > Hi > > > > > > > > On 2015-04-20, Dave Airlie wrote: > > > > [...] > > > > > The following changes since commit > > > > > 09d51602cf84a1264946711dd4ea0dddbac599a1: > > > > > > > > > > Merge branch 'turbostat' of > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 > > > > > 14:31:41 -0700) > > > > > > > > > > are available in the git repository at: > > > > > > > > > > git://people.freedesktop.org/~airlied/linux drm-next-merged > > > > > > > > > > for you to fetch changes up to > > > > > 2c33ce009ca2389dbf0535d0672214d09738e35e: > > > > > > > > > > Merge Linus master into drm-next (2015-04-20 13:05:20 +1000) > > > > [...] > > > > > Ander Conselvan de Oliveira (28): > > > > [...] > > > > > drm/i915: Allocate connector state together with the connectors > > > > [...] > > > > > > > > This commit introduces a regression relative to v4.0 on an Intel > > > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics > > > > using its (only-) VGA connector for me. > > > > > > > > v4.1-rc6-52-gff25ea8: > > > > [ 13.265699] BUG: unable to handle kernel NULL pointer dereference at > > > > 0010 > > > > [ 13.265723] IP: [] > > > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915] > > > > > > Hmm. Smells like a connector with a NULL state pointer, and the bad > > > commit touched exactly the part that sets it up. I can't immediately > > > spot any place where we'd forget to set it up though. > > > > > > Can you try with something like this so we'd at least find out which > > > connector(s) is/are at fault here? > > > > With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even > > harder, so I had to switch to a serial console in order to fetch the > > boot messages: > > > > [ 13.492784] connector = 880079bb8000 > > [ 13.910439] connector = 8800795b5800 > > [ 14.463114] connector = 8800795b6000 > > [ 14.700707] connector = 8800795b6800 > > [ 14.869418] connector = 8800795b7000 > > [ 14.923848] connector = 8800795b7000 > > > > Full, gzipped, bootlog attached - thanks a lot for your efforts. > > Could you repeat the process with drm.debug=0xe in your kernel command > line and send the logs again? Never mind, Ville's patch produced all the information necessary. Please give the patch I just sent a try. Thanks, Ander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/i915: Properly initialize SDVO analog connectors
In the commit below, I missed the connector allocation in the function
intel_sdvo_analog_init(), leading to those connectors to have a NULL
state pointer.
commit 08d9bc920d465d762cac9383249c19bf69a2
Author: Ander Conselvan de Oliveira
Date: Fri Apr 10 10:59:10 2015 +0300
drm/i915: Allocate connector state together with the connectors
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index d24ef75..aa2fd75 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2554,7 +2554,7 @@ intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo, int
device)
DRM_DEBUG_KMS("initialising analog device %d\n", device);
- intel_sdvo_connector = kzalloc(sizeof(*intel_sdvo_connector),
GFP_KERNEL);
+ intel_sdvo_connector = intel_sdvo_connector_alloc();
if (!intel_sdvo_connector)
return false;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git pull] drm for v4.1-rc1
On Sun, 2015-06-07 at 04:32 +0200, Stefan Lippers-Hollmann wrote: > Hi > > On 2015-06-07, Ville Syrjälä wrote: > > On Fri, Jun 05, 2015 at 11:18:21PM +0200, Stefan Lippers-Hollmann wrote: > > > Hi > > > > > > On 2015-04-20, Dave Airlie wrote: > > > [...] > > > > The following changes since commit > > > > 09d51602cf84a1264946711dd4ea0dddbac599a1: > > > > > > > > Merge branch 'turbostat' of > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux (2015-04-19 > > > > 14:31:41 -0700) > > > > > > > > are available in the git repository at: > > > > > > > > git://people.freedesktop.org/~airlied/linux drm-next-merged > > > > > > > > for you to fetch changes up to 2c33ce009ca2389dbf0535d0672214d09738e35e: > > > > > > > > Merge Linus master into drm-next (2015-04-20 13:05:20 +1000) > > > [...] > > > > Ander Conselvan de Oliveira (28): > > > [...] > > > > drm/i915: Allocate connector state together with the connectors > > > [...] > > > > > > This commit introduces a regression relative to v4.0 on an Intel > > > D945GCLF2 mainboard[1] (Atom 330) with Intel 82945G/GZ onboard graphics > > > using its (only-) VGA connector for me. > > > > > > v4.1-rc6-52-gff25ea8: > > > [ 13.265699] BUG: unable to handle kernel NULL pointer dereference at > > > 0010 > > > [ 13.265723] IP: [] > > > intel_modeset_update_connector_atomic_state+0x61/0x90 [i915] > > > > Hmm. Smells like a connector with a NULL state pointer, and the bad > > commit touched exactly the part that sets it up. I can't immediately > > spot any place where we'd forget to set it up though. > > > > Can you try with something like this so we'd at least find out which > > connector(s) is/are at fault here? > > With the patch applied, the kernel (v4.1-rc6-104-g4b17069) locks up even > harder, so I had to switch to a serial console in order to fetch the > boot messages: > > [ 13.492784] connector = 880079bb8000 > [ 13.910439] connector = 8800795b5800 > [ 14.463114] connector = 8800795b6000 > [ 14.700707] connector = 8800795b6800 > [ 14.869418] connector = 8800795b7000 > [ 14.923848] connector = 8800795b7000 > > Full, gzipped, bootlog attached - thanks a lot for your efforts. Could you repeat the process with drm.debug=0xe in your kernel command line and send the logs again? Thanks, Ander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
