Re: [PATCH 12/29] drm/i915: switch to drm_*{get,put} helpers

5/intel_fbdev.c > index 0c4cde6..13fbe80 100644 > --- a/drivers/gpu/drm/i915/intel_fbdev.c > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > @@ -189,7 +189,7 @@ static int intelfb_create(struct drm_fb_helper *helper, > " releasing it\n", > intel_fb->base.width, intel_fb->base.height, > sizes->fb_width, sizes->fb_height); > - drm_framebuffer_unreference(_fb->base); > + drm_framebuffer_put(_fb->base); > intel_fb = ifbdev->fb = NULL; > } > if (!intel_fb || WARN_ON(!intel_fb->obj)) { > @@ -650,7 +650,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; > ifbdev->fb = fb; > > - drm_framebuffer_reference(>fb->base); > + drm_framebuffer_get(>fb->base); > > /* Final pass to check if any active pipes don't have fbs */ > for_each_crtc(dev, crtc) { -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH 0/3] Kconfig dependencies: acpi-video, backlight and thermal

letions(-) >> >> To: dri-de...@lists.freedesktop.org >> Cc: "Rafael J. Wysocki" <r...@rjwysocki.net> >> Cc: Len Brown <l...@kernel.org> >> Cc: Lucas Stach <l.st...@pengutronix.de> >> Cc: Russell King <linux+etna...@armlinux.org.uk&

Re: [Intel-gfx] [PATCH 0/3] Kconfig dependencies: acpi-video, backlight and thermal

, but it is also a more invasive change that we >> can do separately at some point. > > Looks reasonable, but I think it'd be good to get Jani Nikula's explicit > ack on this, since he dugg around a lot in this area. And he's on vacation > this week. I didn't dig thro

Re: [PATCH v2] drm/i915: Explicit the connector name for DP link training result

link rate = %d, lane >> > count = %d", >> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at >> > link rate = %d, lane count = %d", >> > +intel_connector->base.base.id, >> > +intel_connector->base.name, >> > intel_dp->link_rate, intel_dp->lane_count); >> >if (!intel_dp_get_link_train_fallback_values(intel_dp, >> > intel_dp- >> > >link_rate, >> > -- >> > 2.13.2 >> > -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v2] drm/i915: Explicit the connector name for DP link training result

intel_dp->link_rate, intel_dp->lane_count); >> >return; >> > >> > failure_handling: >> > - DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane >> > count = %d", >> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at >> > link rate = %d, lane count = %d", >> > +intel_connector->base.base.id, >> > +intel_connector->base.name, >> > intel_dp->link_rate, intel_dp->lane_count); >> >if (!intel_dp_get_link_train_fallback_values(intel_dp, >> > intel_dp- >> > >link_rate, >> > -- >> > 2.13.2 >> > -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Explicit the connector name for DP link training result

(!intel_dp_get_link_train_fallback_values(intel_dp, >intel_dp->link_rate, >intel_dp->lane_count)) -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Explicit the connector name for DP link training result

DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d > for connector %s", > + intel_dp->link_rate, intel_dp->lane_count, > + intel_connector->base.name); > if (!intel_dp_get_link_train_fallback_values(intel_dp, >intel_dp->link_rate, >intel_dp->lane_count)) -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

context *sw_context, > SVGA3dCmdHeader *header) > { > - return capable(CAP_SYS_ADMIN) ? : -EINVAL; > + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL; > } > > static int vmw_cmd_ok(struct vmw_private *dev_priv, -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

der) > { > - return capable(CAP_SYS_ADMIN) ? : -EINVAL; > + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL; > } > > static int vmw_cmd_ok(struct vmw_private *dev_priv, -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

ly something we'd like to do in the long run and pedantically correct (and I tend to prefer code that way) but we certainly have more important things to do. BR, Jani. [1] http://mid.mail-archive.com/87wp9rahjy.fsf@intel.com -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

e long run and pedantically correct (and I tend to prefer code that way) but we certainly have more important things to do. BR, Jani. [1] http://mid.mail-archive.com/87wp9rahjy.fsf@intel.com -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: Reduce scope of 'state' variable

On Thu, 15 Jun 2017, Dawid Kurek <dawi...@gmail.com> wrote: > On 15/06/17, Jani Nikula wrote: >> Separate declaration and initialization would lead to a cleaner patch >> and result. > > I saw combining declaration and initialization is quite common, i.e. in > drm_a

Re: [PATCH] drm: Reduce scope of 'state' variable

On Thu, 15 Jun 2017, Dawid Kurek wrote: > On 15/06/17, Jani Nikula wrote: >> Separate declaration and initialization would lead to a cleaner patch >> and result. > > I saw combining declaration and initialization is quite common, i.e. in > drm_atomic file. Personally, I

Re: [PATCH] drm: Reduce scope of 'state' variable

= kzalloc(sizeof(*state), GFP_KERNEL); Separate declaration and initialization would lead to a cleaner patch and result. BR, Jani. > + > if (!state) > return NULL; > if (drm_atomic_state_init(dev, state) < 0) { -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: Reduce scope of 'state' variable

sizeof(*state), GFP_KERNEL); Separate declaration and initialization would lead to a cleaner patch and result. BR, Jani. > + > if (!state) > return NULL; > if (drm_atomic_state_init(dev, state) < 0) { -- Jani Nikula, Intel Open Source Technology Center

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

Do you have a plan? The upstream commit has the proper Cc: stable and Fixes: tags in place, it just takes a while for the patches to trickle to stable kernels. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

stream commit has the proper Cc: stable and Fixes: tags in place, it just takes a while for the patches to trickle to stable kernels. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 2/3] Documentation: Move visorbus documentation from staging to Documentation/

ot something as specific as this. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 2/3] Documentation: Move visorbus documentation from staging to Documentation/

, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] i915: fix build on gcc7

I_INIT_COUNT(port == > - PORT_A ? PORT_C : PORT_A), > + I915_WRITE(MIPI_INIT_COUNT(port_other), > intel_dsi->init_count); > } -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] i915: fix build on gcc7

OUNT for >* both the ports, even if only one is >* getting used. So write the other port >* if not in dual link mode. >*/ > - I915_WRITE(MIPI_INIT_COUNT(port == > - PORT_A ? PORT

[PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

Wilson <ch...@chris-wilson.co.uk> [Jani: bikeshed repainted] Signed-off-by: Jani Nikula <jani.nik...@intel.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/e

Re: [PULL] topic/e1000e-fix

On Wed, 31 May 2017, David Miller wrote: > And we can't understand why respinning with the requested change is > less work than making several postings such as this one. When our CI hits tons of non-drm issues every merge window, I imagine our developers can start to get a

[PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

ff Kirsher Cc: Dave Ertman Cc: Bruce Allan Cc: intel-wired-...@lists.osuosl.org Cc: net...@vger.kernel.org Signed-off-by: Chris Wilson [Jani: bikeshed repainted] Signed-off-by: Jani Nikula --- drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++- 1 file changed, 6 insertions(+), 1 del

Re: [PULL] topic/e1000e-fix

On Wed, 31 May 2017, David Miller wrote: > And we can't understand why respinning with the requested change is > less work than making several postings such as this one. When our CI hits tons of non-drm issues every merge window, I imagine our developers can start to get a little frustrated

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

g/patch/156990/ > > This fix seems to have got lost: we've been waiting a month, > and 4.12 is now at rc3: please expedite the unexpedited :) It's included in my latest pull request to Dave [1], should make it to v4.12-rc4. BR, Jani. [1] http://mid.mail-archive.com/877f0zlr5d.fsf@intel.com -- Jani Nikula, Intel Open Source Technology Center

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

; This fix seems to have got lost: we've been waiting a month, > and 4.12 is now at rc3: please expedite the unexpedited :) It's included in my latest pull request to Dave [1], should make it to v4.12-rc4. BR, Jani. [1] http://mid.mail-archive.com/877f0zlr5d.fsf@intel.com -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 0/8] i2c: refactor core and break out blocks

series to the intel-gfx list (Cc'd), our CI will run a bunch of tests on it, exercising our use of the I2C adapter interfaces for display data channel and I2C over Display Port native aux. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 0/8] i2c: refactor core and break out blocks

d), our CI will run a bunch of tests on it, exercising our use of the I2C adapter interfaces for display data channel and I2C over Display Port native aux. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH][drm-next] drm/pl111: make structure pl111_display_funcs static

nd should go wherever the referenced commit goes. Annotating typo fixes and missing static keywords and such is just noise from *our* POV, and need to be filtered out. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH][drm-next] drm/pl111: make structure pl111_display_funcs static

erenced commit goes. Annotating typo fixes and missing static keywords and such is just noise from *our* POV, and need to be filtered out. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH][drm-next] drm/pl111: make structure pl111_display_funcs static

onst struct drm_simple_display_pipe_funcs pl111_display_funcs = { > .check = pl111_display_check, > .enable = pl111_display_enable, > .disable = pl111_display_disable, -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH][drm-next] drm/pl111: make structure pl111_display_funcs static

ct > drm_simple_display_pipe *pipe, > return drm_fb_cma_prepare_fb(>plane, plane_state); > } > > -const struct drm_simple_display_pipe_funcs pl111_display_funcs = { > +static const struct drm_simple_display_pipe_funcs pl111_display_funcs = { > .check = pl111_display_c

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, 15 May 2017, Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: >> On Mon, 15 May 2017, Peter Zijlstra <pet...@infradead.org> wrote: >> > The intention is to aid readability. Making comments worse so

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, 15 May 2017, Peter Zijlstra wrote: > On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: >> On Mon, 15 May 2017, Peter Zijlstra wrote: >> > The intention is to aid readability. Making comments worse so that some >> > retarded script can generate bet

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

don't expect or want anyone to go overboard with markup. I don't think it's unreasonable to make small concessions to improve generated documentation for people who care about it even if you don't. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

to go overboard with markup. I don't think it's unreasonable to make small concessions to improve generated documentation for people who care about it even if you don't. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: Missing File REPORTING-BUGS In Linux Kernel.

too, making much more documentation human readable (and writable) without additional processing. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: Missing File REPORTING-BUGS In Linux Kernel.

mentation human readable (and writable) without additional processing. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

s actually on because it's being used by CRTC 2. So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we make sure we're pointing to our own original CRTC which is certainly not used by any other CRTC. Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com> Reviewed-by: Damien Lespiau <damien.lesp...@intel.com> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

ipe A assertion failure (expected off, current on)" because CRTC 0 still claims it's using TRANSCODER_EDP, so the HW state readout function will read it (through PIPECONF) and expect it to be off, when it's actually on because it's being used by CRTC 2. So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we make sure we're pointing to our own original CRTC which is certainly not used by any other CRTC. Signed-off-by: Paulo Zanoni Reviewed-by: Damien Lespiau Signed-off-by: Daniel Vetter -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 4/9] drm/i915: Delete unnecessary braces in three functions

cherryview_sseu_device_status(dev_priv, ); > - } else if (IS_BROADWELL(dev_priv)) { > + else if (IS_BROADWELL(dev_priv)) > broadwell_sseu_device_status(dev_priv, ); > - } else if (INTEL_GEN(dev_priv) >= 9) { > + else if (INTEL_GEN(dev_priv) >= 9) > gen9_sseu_device_status(dev_priv, ); > - } > > intel_runtime_pm_put(dev_priv); -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 4/9] drm/i915: Delete unnecessary braces in three functions

*m, void > *unused) > > intel_runtime_pm_get(dev_priv); > > - if (IS_CHERRYVIEW(dev_priv)) { > + if (IS_CHERRYVIEW(dev_priv)) > cherryview_sseu_device_status(dev_priv, ); > - } else if (IS_BROADWELL(dev_priv)) { > + else if (IS_BROADWELL(dev_

Re: [PATCH 3/9] drm/i915: Replace 14 seq_printf() calls by seq_puts()

and seq_puts. > > And don't even start on converting seq_printf / seq_puts to seq_putc... Agreed. I don't want any of the seq_* changes in this series. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/9] drm/i915: Replace 14 seq_printf() calls by seq_puts()

_puts to seq_putc... Agreed. I don't want any of the seq_* changes in this series. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 6/9] drm/i915: Add spaces for better code readability

gt; -eu_mask[ss%2]); > + eu_cnt = 2 * hweight32(eu_reg[2 * s + ss / 2] & > + eu_mask[ss % 2]); > sseu->eu_total += eu_cnt; > sseu->eu_per_subslice = max_t(unsigned int, > sseu->eu_per_subslice, -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 6/9] drm/i915: Add spaces for better code readability

weight32(eu_reg[2 * s + ss / 2] & > +eu_mask[ss % 2]); > sseu->eu_total += eu_cnt; > sseu->eu_per_subslice = max_t(unsigned int, > sseu->eu_per_subslice, -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 5/9] drm/i915: Adjust seven checks for null pointers

55,7 +3855,7 @@ static int i915_displayport_test_type_show(struct > seq_file *m, void *data) > continue; > > if (connector->status == connector_status_connected && > - connector->encoder != NULL) { > + connector->encoder) { > intel_dp = enc_to_intel_dp(connector->encoder); > seq_printf(m, "%02lx", intel_dp->compliance.test_type); > } else { -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 5/9] drm/i915: Adjust seven checks for null pointers

continue; > > if (connector->status == connector_status_connected && > - connector->encoder != NULL) { > + connector->encoder) { > intel_dp = enc_to_intel_dp(connector->encoder); > seq_printf(m, "%02lx", intel_dp->compliance.test_type); > } else { -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v1] ACPI: Switch to use generic UUID API

ndle, intel_dsm_guid, INTEL_DSM_REVISION_ID, > + if (!acpi_check_dsm(dhandle, _dsm_guid, INTEL_DSM_REVISION_ID, > 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) { > DRM_DEBUG_KMS("no _DSM method for intel device\n"); > ret

Re: [PATCH v1] ACPI: Switch to use generic UUID API

ION_ID, > + if (!acpi_check_dsm(dhandle, _dsm_guid, INTEL_DSM_REVISION_ID, > 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) { > DRM_DEBUG_KMS("no _DSM method for intel device\n"); > return false; The drm/i915 hunk above is Rev

Re: [PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

lways be built-in or completely disabled. This makes > it really easy to use, at the expense of a larger kernel image for those > that > currently use a loadable module. > >Arnd > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 1/3] drm/omap: displays: panel-dpi: add backlight dependency

it really easy to use, at the expense of a larger kernel image for those > that > currently use a loadable module. > >Arnd > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: i915: Avoid format string expansion from engine names

'\0'; > > - return i915_handle_error(i915, hung, msg); > + return i915_handle_error(i915, hung, "%s", msg); > } > > /* > -- > 2.7.4 -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: i915: Avoid format string expansion from engine names

15, hung, msg); > + return i915_handle_error(i915, hung, "%s", msg); > } > > /* > -- > 2.7.4 -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

On Sun, 02 Apr 2017, Martin Kepplinger <mart...@posteo.de> wrote: > Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis > <regressi...@leemhuis.info>: >>Lo! On 22.03.2017 11:36, Jani Nikula wrote: >>> On Wed, 22 Mar 2017, Martin Kepplinger <mart...@pos

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

On Sun, 02 Apr 2017, Martin Kepplinger wrote: > Am 2. April 2017 13:50:26 MESZ schrieb Thorsten Leemhuis > : >>Lo! On 22.03.2017 11:36, Jani Nikula wrote: >>> On Wed, 22 Mar 2017, Martin Kepplinger wrote: >>>> I know something similar is here: >>>>

Re: [PATCH] drm/i915: disable KASAN for handlers

t. There are too many for KASAN to keep up. >> >> So disable KASAN for this file. >> >> Signed-off-by: Jiri Slaby <jsl...@suse.cz> >> Cc: Martin Liska <mli...@suse.cz> >> Cc: Zhenyu Wang <zhen...@linux.intel.com> >> Cc: Zhi Wang <

Re: [PATCH] drm/i915: disable KASAN for handlers

KASAN to keep up. >> >> So disable KASAN for this file. >> >> Signed-off-by: Jiri Slaby >> Cc: Martin Liska >> Cc: Zhenyu Wang >> Cc: Zhi Wang >> Cc: Daniel Vetter >> Cc: Jani Nikula >> Cc: David Airlie >> Cc: intel-gvt-...@lists.f

Re: [PATCH] drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE

ACPI_VIDEO's dependencies, ick > select BACKLIGHT_LCD_SUPPORT if ACPI > - select BACKLIGHT_CLASS_DEVICE if ACPI > + select BACKLIGHT_CLASS_DEVICE > select INPUT if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915: fix build error without CONFIG_BACKLIGHT_CLASS_DEVICE

_LCD_SUPPORT if ACPI > - select BACKLIGHT_CLASS_DEVICE if ACPI > + select BACKLIGHT_CLASS_DEVICE > select INPUT if ACPI > select ACPI_VIDEO if ACPI > select ACPI_BUTTON if ACPI -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v2 0/2] kconfig/mconf: propagate jumping function in search result view

t; >> > Documentation/kbuild/kconfig.txt | 4 >> > scripts/kconfig/mconf.c | 8 >> > 2 files changed, 8 insertions(+), 4 deletions(-) >> > >> > -- >> > 2.7.4 >> > >> >> -- >> Thanks, >> Changbin Du -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v2 0/2] kconfig/mconf: propagate jumping function in search result view

v2: correct spell (Jim) >> > >> > Changbin Du (2): >> > kconfig/mconf: add jumping tip in title of search result textbox >> > Documentation/kconfig: add search jump feature description >> > >> > Documentation/kbuild/kconfig.txt | 4 >

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

file a bug over at [1]. Thanks, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

nks, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH] drm/i915: use static const array for PICK macro

On Tue, 21 Mar 2017, Daniel Vetter <dan...@ffwll.ch> wrote: > On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote: >> On Tue, Mar 21, 2017 at 9:26 AM, Jani Nikula >> <jani.nik...@linux.intel.com> wrote: >> > On Mon, 20 Mar 2017, Arnd Bergmann <

Re: [Intel-gfx] [PATCH] drm/i915: use static const array for PICK macro

On Tue, 21 Mar 2017, Daniel Vetter wrote: > On Tue, Mar 21, 2017 at 09:44:07AM +0100, Arnd Bergmann wrote: >> On Tue, Mar 21, 2017 at 9:26 AM, Jani Nikula >> wrote: >> > On Mon, 20 Mar 2017, Arnd Bergmann wrote: >> >> The varargs macro tr

Re: [PATCH] drm/i915: use static const array for PICK macro

nd my version gets most of it back at the expense of larger .data when > kasan is enabled. > > Fixes: ce64645d86ac ("drm/i915: use variadic macros and arrays to choose > port/pipe based registers") > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114 > Cc: Jani N

Re: [PATCH] drm/i915: use static const array for PICK macro

ts most of it back at the expense of larger .data when > kasan is enabled. > > Fixes: ce64645d86ac ("drm/i915: use variadic macros and arrays to choose > port/pipe based registers") > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114 > Cc: Jani Nikula > S

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

https://godbolt.org/g/hgS817 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114 -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114 -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

T3(port, a, b, c) ((port) == PORT_A ? (a) : \ > +(port) == PORT_B ? (b) : (c)) > #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PORT3(pipe, a, b, c)) > -#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) > +#define _PHY3(phy, a, b, c) ((phy) == DPIO_PHY0 ? (a) :

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

\ > +(port) == PORT_B ? (b) : (c)) > #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PORT3(pipe, a, b, c)) > -#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) > +#define _PHY3(phy, a, b, c) ((phy) == DPIO_PHY0 ? (a) : \ > + (phy) =

Re: [Intel-gfx] The i915 stable patch marking is totally broken

s just that stable doesn't merge back with Linus' master. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] The i915 stable patch marking is totally broken

ith what's in -next. We ended up stalling on fixes in *both* branches. I think we did a much worse job getting things done with the reverse order of applying fixes, because it was so much harder for us. In the end, the model is not unlike the stable workflow. It's just that stable doesn't merge bac

Re: [Intel-gfx] The i915 stable patch marking is totally broken

you'd like, just let us know. (Too bad it's virtually impossible to modify the commit being cherry-picked. Unless someone(tm) comes up with a way to share git-notes in a sensible, distributed way.) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] The i915 stable patch marking is totally broken

t us know. (Too bad it's virtually impossible to modify the commit being cherry-picked. Unless someone(tm) comes up with a way to share git-notes in a sensible, distributed way.) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: linux-next: build failure after merge of the sunxi tree

ndard operating procedure for fixing them. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: linux-next: build failure after merge of the sunxi tree

BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 0/2] Documentation/EDID fixes

On Tue, 07 Mar 2017, Javi Merino <javi.mer...@kernel.org> wrote: > On Tue, Mar 07, 2017 at 06:16:51PM +0200, Jani Nikula wrote: >> On Mon, 06 Mar 2017, Javi Merino <javi.mer...@kernel.org> wrote: >> > I found these two minor issues while building an EDID. I'm no

Re: [PATCH 0/2] Documentation/EDID fixes

On Tue, 07 Mar 2017, Javi Merino wrote: > On Tue, Mar 07, 2017 at 06:16:51PM +0200, Jani Nikula wrote: >> On Mon, 06 Mar 2017, Javi Merino wrote: >> > I found these two minor issues while building an EDID. I'm not sure >> > whether the second patch (Add O= to su

Re: [PATCH 0/2] Documentation/EDID fixes

ing issues like this, but really I think there should be an userspace tool for this. Definitely outside of the Documentation directory, perhaps even outside the kernel tree altogether. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 0/2] Documentation/EDID fixes

y I think there should be an userspace tool for this. Definitely outside of the Documentation directory, perhaps even outside the kernel tree altogether. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues

gt;> + * device so the audio device can come back >> + */ >> mutex_lock(_mutex); >> list_for_each_entry(client, _priv.clients, list) { >> if (PCI_SLOT(client->pdev->devfn) == PCI_SLOT(pdev->devfn) && >> @@ -1112,7 +1114,7 @@ static int >> vga_switcheroo_runtime_resume_hdmi_audio(struct device *dev) >> >> /** >> * vga_switcheroo_init_domain_pm_optimus_hdmi_audio() - helper for driver >> - * power control >> + * power control >> * @dev: audio client device >> * @domain: power domain >> * >> -- >> 2.7.4 >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues

come back >> + */ >> mutex_lock(_mutex); >> list_for_each_entry(client, _priv.clients, list) { >> if (PCI_SLOT(client->pdev->devfn) == PCI_SLOT(pdev->devfn) && >> @@ -1112,7 +1114,7 @@ static int >> vga_switcheroo_runtime_resume_hdmi_audio(struct device *dev) >> >> /** >> * vga_switcheroo_init_domain_pm_optimus_hdmi_audio() - helper for driver >> - * power control >> + * power control >> * @dev: audio client device >> * @domain: power domain >> * >> -- >> 2.7.4 >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center

Re: I915 dmesg warnings on Mac Mini, solo core edition

er_bug.cgi?product=DRI=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center

Re: I915 dmesg warnings on Mac Mini, solo core edition

RI=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center

Re: making documentation targets on v4.10 with Fedora 25

; by the top-level Makefile. Why do you say O= isn't useful with the targets? The goal was that it would work as expected, and it did work in the past. But, as with everything, if there's no automated testing, it ceases to exist. :( BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: making documentation targets on v4.10 with Fedora 25

y do you say O= isn't useful with the targets? The goal was that it would work as expected, and it did work in the past. But, as with everything, if there's no automated testing, it ceases to exist. :( BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: drm_printer: add __printf validation

On Tue, 21 Feb 2017, Joe Perches <j...@perches.com> wrote: > On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote: >> You know how this stuff works, please split it up to get the stuff >> merged. > > Quite well actually. > > Fix it as you think appropriate. >

Re: [PATCH] drm: drm_printer: add __printf validation

On Tue, 21 Feb 2017, Joe Perches wrote: > On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote: >> You know how this stuff works, please split it up to get the stuff >> merged. > > Quite well actually. > > Fix it as you think appropriate. > But in any case,

Re: [PATCH] drm: drm_printer: add __printf validation

our patches when you send them to the list :) > > If you want to break it up, go ahead. You know how this stuff works, please split it up to get the stuff merged. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: drm_printer: add __printf validation

ou send them to the list :) > > If you want to break it up, go ahead. You know how this stuff works, please split it up to get the stuff merged. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: make pdfdoc errors with 4.10-rc7

. > ./sound/soc/soc-core.c:2508: ERROR: Unknown target name: "snd_soc_daifmt". > ./sound/core/jack.c:312: ERROR: Unknown target name: "snd_jack_btn". > make[2]: *** [linux-user.pdf] Error 1 > make[1]: *** [pdfdocs] Error 2 > make: *** [pdfdocs] Error 2 -- Jani Nikula, Intel Open Source Technology Center

Re: make pdfdoc errors with 4.10-rc7

c-core.c:2508: ERROR: Unknown target name: "snd_soc_daifmt". > ./sound/core/jack.c:312: ERROR: Unknown target name: "snd_jack_btn". > make[2]: *** [linux-user.pdf] Error 1 > make[1]: *** [pdfdocs] Error 2 > make: *** [pdfdocs] Error 2 -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v2] drm/i915/debugfs: Add i915_hpd_storm_ctl

ection to speed up hotplugging tests without breaking anything. > > Changes since v1: > - Make HPD storm interval configurable > - Misc code cleanup > > Signed-off-by: Lyude <ly...@redhat.com> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: Tomeu Vizoso &l

Re: [PATCH v2] drm/i915/debugfs: Add i915_hpd_storm_ctl

ugging tests without breaking anything. > > Changes since v1: > - Make HPD storm interval configurable > - Misc code cleanup > > Signed-off-by: Lyude > Cc: Jani Nikula > Cc: Tomeu Vizoso Acked-by: Jani Nikula > --- >

Re: [PATCH v2 1/2] kconfig/mconf: add jumping tip in title of search result textbox

On Wed, 08 Feb 2017, changbin...@intel.com wrote: > From: Changbin Du <changbin...@intel.com> > > Prompt user how to quickly jump to the item he/she is interested in. > > Signed-off-by: Changbin Du <changbin...@intel.com> > Reviewed-by: Jani Nikula <jani.nik...@l

Re: [PATCH v2 1/2] kconfig/mconf: add jumping tip in title of search result textbox

On Wed, 08 Feb 2017, changbin...@intel.com wrote: > From: Changbin Du > > Prompt user how to quickly jump to the item he/she is interested in. > > Signed-off-by: Changbin Du > Reviewed-by: Jani Nikula This is assuming too much... but I looked at it now, and it looks good to

Re: [PATCH] drm/i915/debugfs: Add i915_hpd_storm_ctl

ers/gpu/drm/i915/intel_hotplug.c > @@ -129,7 +129,8 @@ static bool intel_hpd_irq_storm_detect(struct > drm_i915_private *dev_priv, > dev_priv->hotplug.stats[pin].last_jiffies = jiffies; > dev_priv->hotplug.stats[pin].count = 0; > DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n", > pin); > - } else if (dev_priv->hotplug.stats[pin].count > HPD_STORM_THRESHOLD) { > + } else if (dev_priv->hotplug.stats[pin].count > HPD_STORM_THRESHOLD && > +dev_priv->hotplug.hpd_storm_detect_enabled) { How about making the threshold configurable, with 0 being off? BR, Jani. PS. I do wonder if anyone besides Egbert has really seen this much in the wild... > dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED; > DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin); > storm = true; -- Jani Nikula, Intel Open Source Technology Center

<    1   2   3   4   5   6   7   8   9   10   >