Hi Florian, all -
First, thanks for your work on adding the bugzilla comments when patches
referencing bugs get merged. I find it useful.
Recently however there was a comment about a commit referencing a commit
referencing the bug report. Turns out the comment was missing one level
of indirectio
On Thu, 24 Jan 2013, "Su, Xuemin" wrote:
> From: xueminsu
> Date: Tue, 22 Jan 2013 22:39:39 +0800
> Subject: [PATCH] drm_crtc: check if fb_create return NULL
>
> Some buggy driver may still return NULL in fb_create,
> which leads to kernel panic.
>
> Signed-off-by: xueminsu
> ---
> drivers/gpu/
On Thu, 24 Jan 2013, "Su, Xuemin" wrote:
> On Thu, 2013-01-24 at 10:31 +0200, Jani Nikula wrote:
>> >}
>> > + /* some buggy driver may return NULL here, which may cause panic */
>> > + BUG_ON(!fb);
>>
>> I fail to see the benefit of thi
On Thu, 14 Mar 2013, Chris Li wrote:
> Hi, I attach the two demsg and with and without the bad commit
> on the intel nightly branch. Without the bad commit it actually works.
> However, on the tip of intel nightly. the moeset work around does not work
> there any more.
Hi Chris, thanks for the dm
> Thanks,
>
> - Ted
>
> commit 6c34ed3be47036c173f7f43df112f93fbd89026f
> Author: Jani Nikula
> Date: Wed Sep 26 18:43:10 2012 +0300
>
> drm/i915: use adjusted_mode instead of mode for checking the 6bpc force
> flag
>
> comm
On Tue, 30 Oct 2012, Jani Nikula wrote:
> Hi Ted -
>
> On Tue, 30 Oct 2012, Theodore Ts'o wrote:
>> I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able
>> to work with an HP ZR30w 30" 2560x1600 display. I saw the fol
AW))
> + return false;
> + return acpi_video_backlight_support();
> +}
IIUC this expects the raw backlight device to have been registered prior
to calling acpi_video_register(). This only works for i915 which calls
acpi_video_register() itself.
BR,
Jani.
> +EXPORT_SYMBOL(acpi_video_verify_backlight_support);
> +
> /*
> * Use acpi_backlight=vendor/video to force that backlight switching
> * is processed by vendor specific acpi drivers or video.ko driver.
> --
> 1.8.4.12.g2ea3df6
>
--
Jani Nikula, Intel Open Source Technology Center
--
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/
possible
> without user testing. So, the idea is to make that testing possible without
> hacking the kernel and that's why we're introducing the new command line
> switch. And we're going to ask users to try it and report back.
The thing that slightly bugs me with the proposed patc
On Tue, 10 Sep 2013, Matthew Garrett wrote:
> On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
>
>> I think the parameter "Does the ACPI backlight interface work or not"
>> belongs to the ACPI video driver.
>
> That depends on how Windows 8 works. If Window
heck in patch 2/2 is the whole
story.
Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code
paths, what guarantees do we have of UEFI+CSM or legacy boots working?
BR,
Jani.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=47941#c96
--
Jani Nikula, Intel Open Source Te
On Wed, 11 Sep 2013, Matthew Garrett wrote:
> On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
>
>> Before plunging forward, have you observed any difference between the
>> boot modes? We have reports [1] that the backlight behaviour is
>> different with UEFI vs. UEF
we are solving here, if someday we need to
> differentiate, we can enhance the code then.
Since both Baytrail and Haswell already have two backlight PWMs, this
may be needed sooner than you think. But we shouldn't let that block
fixing the more urgent issue we have now. So I'm f
On Thu, 10 Oct 2013, Aaron Lu wrote:
> On 10/10/2013 12:29 PM, Jani Nikula wrote:
>> On Thu, 10 Oct 2013, Aaron Lu wrote:
>>> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
>>>> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
>>>>> +bool ba
On Fri, 27 Sep 2013, Patrik Jakobsson wrote:
>> +#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
Hi, while at it, you should probably let backlight be built as module:
#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
Cheers,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsub
4 Igor Gnatenko
>>
>> > On Tue, 2013-09-24 at 17:47 +0800, Aaron Lu wrote:
>> > > v3:
>> > > 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module;
>> > > 2 Remove unnecessary function acpi_video_unregister introduced in
>> >
On Wed, 25 Sep 2013, Jörg Otte wrote:
> 2013/9/25 Jani Nikula :
>> On Wed, 25 Sep 2013, Aaron Lu wrote:
>>> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
>>>> Backlight can't be modified with this patch set - neither with
>>>> function
On Thu, 06 Dec 2012, Tim Gardner wrote:
> smatch warning:
>
> drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
> 500 bytes on stack
>
> Refactor so that saved_mode and saved_hwmode are dynamically allocated as
> opposed
> to being automatic variables. 500 bytes seem
On Fri, 07 Dec 2012, Chris Wilson wrote:
> On Fri, 07 Dec 2012 13:47:46 +0200, Jani Nikula
> wrote:
>>
>> On Thu, 06 Dec 2012, Tim Gardner wrote:
>> > + if (!saved_mode) {
>> > + pr_err("i915: Could not allocate saved display mode.\n");
tic variables. 500 bytes seems like it could run the potential
> for blowing
> the kernel stack.
Reviewed-by: Jani Nikula
>
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Tim Gardner
> ---
>
> V2 - spaces around '
driver is to allow us to use an exact
match for D510MO, without also incorrectly matching D510MOV:
{
.ident = "Intel D510MO",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"),
7;s D510MO mainboard
Jani Nikula (2):
dmi: add support for exact DMI matches in addition to substring
matching
drm/i915: Quirk away phantom LVDS on Intel's D525MW mainboard
drivers/firmware/dmi_scan.c | 12 +---
drivers/gpu/drm/i915/intel_lvds.c | 16
This replaceable mainboard only has a VGA-out, yet it claims to also
have a connected LVDS header.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65256
Reported-by: Cornel Panceac
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8
-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 10c3d56..76213e4 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
With Greg's address fixed. Please drop the old one from any
replies. Sorry for the noise.
On Thu, 06 Jun 2013, Jani Nikula wrote:
> Hi Greg, Andrew -
>
> Patch 1 is for DMI, bugfixes in patches 2-3 for i915 and included for
> completeness. After a tested-by they should be good
uld only ever get called once. Which means the acpi_walk_namespace()
with video_unregister_backlight() should never get called in register.
Please enlighten me.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linu
On Thu, 25 Jul 2013, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek wrote:
>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
>> wrote:
>>> On Thu, 25 Jul 2013, Sedat Dilek wrote:
>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen
On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
> On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
>> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
>> > Well, I wonder what about the appended (untested) patch?
>>
>> Rafael, before goi
On Wed, 06 Mar 2013, Daniel Vetter wrote:
> On Wed, Mar 6, 2013 at 3:35 AM, Benson Leung wrote:
>> I'm working on touch devices Chromium OS, and I've noticed a
>> regression between 3.8 and 3.9-rc1, which was posted yesterday.
>>
>> The hardware in question is a Chromebook Pixel. For this device,
On Tue, 09 Apr 2013, Josh Boyer wrote:
> Upstream commit 01e3a8feb40e54b962a20fa7eb595c5efef5e109
This patch seems to be the above commit and
commit 160320879830e469e26062c18f75236822ba
Author: Jani Nikula
Date: Tue Jan 22 12:50:34 2013 +0200
drm/i915: add quirk to invert brightn
k to invert brightness on Packard Bell NCL20
>
> Should these all be applied to the various 3.x.y stable branches?
Acked-by: Jani Nikula
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
On Fri, 03 May 2013, Daniel Vetter wrote:
> On Fri, May 03, 2013 at 11:17:42AM +0200, dl...@gmx.de wrote:
>> From: Jan-Simon Möller
>>
>> Description:
>> intel_gmbus_is_forced_bit is no extern as its body is right below.
>> Likewise for intel_gmbus_is_port_valid.
>>
>> This fixes a compilation
On Tue, 05 Mar 2013, Chris Li wrote:
> On Mon, Mar 4, 2013 at 3:16 PM, Chris Li wrote:
Two things to test:
- Can you please check whether any of the backlight drivers in
/sys/class/backlight does anything? You need to frob the brightness
file. Please also list all the drivers
essary.
I'm not quite sure what the patch below is against, but just removing
the reference to raw_edid from a slightly different place is the way to
go. Like you seem to do, so:
Acked-by: Jani Nikula
I can also provide a patch against drm-next if needed.
BR,
Jani.
> --
> Cheers
>
> I used a quirk in my patch, but I could instead change the driver to
> bail here instead of trying to limp along.
Hi Grant, please try v3.6-rc6 that does exactly that with:
commit 28dcc2d60cb570d9f549c329b2f51400553412a1
Author: Jani Nikula
Date: Mon Sep 3 16:25:12 2012 +0300
On Tue, 18 Sep 2012, Daniel Vetter wrote:
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map console_lock_dep_map = {
> + .name = "console_lock"
> +};
> +#endif
static?
BR,
Jani.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
Alex, Maciej, please test the following to see if it fixes the issue
[1], thanks.
BR,
Jani.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=45881
Jani Nikula (2):
drm/i915: extract connector update from intel_ddc_get_modes() for
reuse
drm/i915: fall back to bit-banging if GMBUS fails
Refactor the connector update part of intel_ddc_get_modes() into a separate
intel_connector_update_modes() function for reuse. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_modes.c | 31
=45881
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_crt.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index bc5e2c9..80bf311 100644
--- a/drivers/gpu/dr
i2c_add_adapter() only after intel_gpio_setup().
LKML-Reference: <5021f00b.7000...@ionic.de>
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel
Hi Mihai, could you test the following patch to see if it fixes the problem,
please?
BR,
Jani.
Jani Nikula (1):
drm/i915: ensure i2c adapter is all set before adding it
drivers/gpu/drm/i915/intel_i2c.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--
1.7.9.5
--
To
On Mon, 13 Aug 2012, Daniel Vetter wrote:
> On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote:
>> (Bringing this back to the mailing lists after a bit of uninteresting private
>> conversation.)
>>
>> > Honestly, I think we need a way to force disable gmbus with a module
>> > paramet
On Mon, 13 Aug 2012, Mihai Moldovan wrote:
> Had another look at the code and would like to apologize for the confusion...
No worries Mihai, thanks for testing!
BR,
Jani.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Thu, 22 Nov 2012, Henrik Rydberg wrote:
>> Yeah, the utter lack of a vbt fits very nicely, thanks for checking,
>> I've merged the patch into drm-intel-fixes and will forward it for
>> inclusion into 3.7 rsn.
>
> Great, thanks. One thing about that patch: if we would ever encounter
> a non-zero
On Mon, 14 Jan 2013, Jiri Slaby wrote:
> On 01/14/2013 01:56 PM, Rafael J. Wysocki wrote:
>> On Monday, January 14, 2013 11:11:52 AM Jiri Slaby wrote:
>>> Hi,
>>>
>>> since friday's -next (the last known to be working is the last monday's)
>>> I cannot resume from suspend. The last thing I see wit
drm_dp_helper.c
> index a07adf0a07db..3e6fe82c6d64 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
--
Jani Nikula, Intel Open Source Technology Center
On Mon, 19 Sep 2016, Shuah Khan wrote:
> Move runnable examples code from Documentation to samples. I moved
> just the example code, and left documentation files as is.
FWIW I like this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
gt; I haven't seen any of the link training errors so far and I've run
> through my usual battery of be nasty to the external monitor tests.
Thanks for the update. We still have fixes for the underruns in the
pipeline.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)
Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
sb_private
> *dev_priv, u32 addr)
> if (read_vbt_r10(addr, &vbt))
> return -1;
>
> - gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL);
> + gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL);
> if (!gct)
> return -1;
--
Jani Nikula, Intel Open Source Technology Center
gct_virtual, sizeof(*gct));
> iounmap(gct_virtual);
>
> @@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private
> *dev_priv, u32 addr)
> dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo;
>
> ret = 0;
> -out:
> + free_gct:
> kfree(gct);
> return ret;
> }
--
Jani Nikula, Intel Open Source Technology Center
e5cece0 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private
> *dev_priv)
> break;
> default:
> dev_err(dev->dev, "Unknown rev
ate
> *dev_priv)
> dev_err(dev->dev, "Unknown revision of GCT!\n");
> return;
> }
> -
> -out:
> if (ret)
> + report_failure:
> dev_err(dev->dev, "Unable to read GCT!");
> else
> dev_priv->has_gct = true;
--
Jani Nikula, Intel Open Source Technology Center
only look at the patches, not who they were from. We
have CI for drm/i915, but I don't think it's constructive to keep
changing drivers like this where the upstream isn't actively developed
and tested. But I digress. It's up to Patrik anyway.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
means the code is infringing a core coding style rule. This MUST
> be fixed before the patch is submitted upstream."
>
> And if any WARNING was printed, include the following:
>
> "WARNING means the code is not following the best practice. This SHOULD
> be fixed before the
On Thu, 22 Sep 2016, Jean Delvare wrote:
> Hi Jani,
>
> On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote:
>>
>> You could make checkpatch have different defaults for patches and files,
>> to encourage better style in new code, but to discourage finding
&
gs from boot both with and without the above commit (it's
enough to see i915 load). Please also provide
/sys/kernel/debug/dri/0/i915_opregion.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
display the help (without warnings!) even if the
tool is not available. Patch follows.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
Simply move the dochelp rule outside of the HAVE_SPHINX check,
overriding the .DEFAULT rule for HAVE_SPHINX=0.
Cc: Jonathan Corbet
Cc: Christian Kujau
Signed-off-by: Jani Nikula
---
Documentation/Makefile.sphinx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
structureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Jani Nikula, Intel Open Source Technology Center
gt; - if (ret)
> - return ret;
> -
> - return 0;
> + return i915_gem_open(dev, file);
> }
Seems to me the whole function could be replaced by a direct use of
i915_gem_open().
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 07 Sep 2016, Markus Heiser wrote:
> Am 06.09.2016 um 15:36 schrieb Jonathan Corbet :
>
>> On Sat, 27 Aug 2016 11:43:18 +0300
>> Jani Nikula wrote:
>>
>>> On Fri, 26 Aug 2016, Jonathan Corbet wrote:
>>>> As far as I can tell, the handling o
the Sphinx build has grown so ugly and
complicated now. :(
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 07 Sep 2016, Geert Uytterhoeven wrote:
> Hi Jani,
>
> On Wed, Sep 7, 2016 at 3:28 PM, Jani Nikula
> wrote:
>> On Wed, 07 Sep 2016, Geert Uytterhoeven wrote:
>>> When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
>>> i
[] ? ret_from_fork+0x1f/0x40
> [ 15.847478] [] ? kthread_worker_fn+0x160/0x160
> [ 15.847487] ---[ end trace ad9e991297d99be1 ]---
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 06 Sep 2016, li...@eikelenboom.it wrote:
> On 2016-09-06 11:25, Jani Nikula wrote:
>> On Tue, 06 Sep 2016, li...@eikelenboom.it wrote:
>>> L.S.,
>>>
>>> Since one of the last 4.8 RC's i'm getting the warning below when
>>> booting on
the CONFIG_BUILD_DOCSRC config option,
and reserving Documentation/Makefile for documentation build. After this
series, some of the remaining code belongs under samples, some under
tools.
We could make it possible to include the code samples from samples into
the Sphinx built documentation.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ould look at
MAINTAINERS and remind the user if a MAINTAINERS update is needed.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
> + * Let's ignore the OpRegion panel type for this chip.
> + */
> + if (IS_IVYBRIDGE(dev_priv) && IS_MOBILE(dev_priv)) {
> + DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
> + return -ENODEV;
> + }
> +
> return ret - 1;
> }
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 13 Sep 2016, Shuah Khan wrote:
> On 09/13/2016 03:20 AM, Jani Nikula wrote:
>> FWIW, I'm in favor of moving *all* the code away from Documentation, not
>> just tests. Essentially removing the CONFIG_BUILD_DOCSRC config option,
>> and reserving Documentation/
//patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrj...@linux.intel.com
--
Jani Nikula, Intel Open Source Technology Center
probably the
fastest way to resolve this.
BR,
Jani.
>
> X log is attached as delme, kernel log as delme2. Nothing too
> suspicious :-(.
>
> Pavel
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 14 Sep 2016, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
>> Hi!
>>
>>> I have
>>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>>> Integrated Graphics Controller (rev 03)
>>>
>
gt; [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
Pavel, Martin, do you always see this when the display fails to resume?
Is it HDMI/DVI for both of you?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Mon, 20 Jun 2016, James Bottomley
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bo
On Wed, 14 Sep 2016, Pavel Machek wrote:
> Intel folks, any ideas? Can you reproduce it?
It's possible (but not confirmed yet) we've seen this in our CI, but has
slipped through because it's sporadic.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 14 Sep 2016, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
>> For the "sometimes need xrandr after resume": I don't think I can
>> bisect that. It only happens sometimes :-(. But there's something
>> helpful in the logs:
>
gt;mmio_base);
> +
> + /* ring should be idle before issuing a sync flush*/
> + WARN_ON((I915_READ_MODE(engine) & MODE_IDLE) == 0);
> +
> + I915_WRITE(reg, 0x0 | IOTLB_INVALID_IVT | IOTLB_GLOBAL_INV_REQ);
> +
> + if (intel_wait_for_register(dev_priv,
> + reg, IOTLB_INVALID_IAIG, 0,
> + 1000))
> + DRM_ERROR("%s: wait for TLB invalidation timed out\n",
> + engine->name);
> + } else if (IS_GEN(dev_priv, 6, 7)) {
> i915_reg_t reg = RING_INSTPM(engine->mmio_base);
>
> /* ring should be idle before issuing a sync flush*/
--
Jani Nikula, Intel Open Source Technology Center
i915_reg_t reg = IOTLB_INVALID(engine->mmio_base);
> +
> + /* ring should be idle before issuing a sync flush*/
> + WARN_ON((I915_READ_MODE(engine) & MODE_IDLE) == 0);
> +
> + I915_WRITE(reg, 0x0 | IOTLB_INVALID_IVT | IOTLB_GLOBAL_INV_REQ);
> +
> + if (intel_wait_for_register(dev_priv,
> + reg, IOTLB_INVALID_IAIG, 0,
> + 1000))
> + DRM_ERROR("%s: wait for TLB invalidation timed out\n",
> + engine->name);
> + } else if (IS_GEN(dev_priv, 6, 7)) {
> i915_reg_t reg = RING_INSTPM(engine->mmio_base);
>
> /* ring should be idle before issuing a sync flush*/
--
Jani Nikula, Intel Open Source Technology Center
rm IOTLB invalidation.
> + */
> + if (IS_GEN8(dev_priv)) {
> + i915_reg_t reg = IOTLB_INVALID(engine->mmio_base);
> +
> + /* ring should be idle before issuing a sync flush*/
> + WARN_ON((I915_READ_MODE(engine) & MODE_IDLE) == 0);
> +
> + I915_WRITE(reg, 0x0 | IOTLB_INVALID_IVT | IOTLB_GLOBAL_INV_REQ);
> +
> + if (intel_wait_for_register(dev_priv,
> + reg, IOTLB_INVALID_IAIG, 0,
> + 1000))
> + DRM_ERROR("%s: wait for TLB invalidation timed out\n",
> + engine->name);
> + } else if (IS_GEN(dev_priv, 6, 7)) {
> i915_reg_t reg = RING_INSTPM(engine->mmio_base);
>
> /* ring should be idle before issuing a sync flush*/
--
Jani Nikula, Intel Open Source Technology Center
15_driver_open,
> + .open = i915_gem_open,
> .lastclose = i915_driver_lastclose,
> .preclose = i915_driver_preclose,
> .postclose = i915_driver_postclose,
--
Jani Nikula, Intel Open Source Technology Center
you don't always know in advance whether the patch should be
applied to -next or -fixes. We'd end up with cherry-picks like this
anyway. Now we can do QA on the fixes in -next, and choose the ones to
backport.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
nothing to handle it, we
>> should aware about this.
>
> I actually prefer the opposite:
Ditto.
Jani.
>
> - on a *.c file, it should assume that *all* exported symbols should be
> documented (either at the C code itself or at a header file);
>
> - on a *.h file, it should
?
*cough* reStructuredText *cough*
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
gt; W dniu 2017-10-16 o 18:16, Greg Kroah-Hartman pisze:
>> 4.13-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Jani Nikula
>>
>> commit ea850f64c2722278f150dc11de2141baeb24211c upstream.
>>
&g
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
44.003597] Console: switching to colour frame buffer device 128x48
> [ 54.240707] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
> [CRTC:58:crtc-3] flip_done timed out
> [ 64.480706] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> [CRTC:58:crtc-3] flip_done timed out
> [ 64.544876] rcar-du feb0.display: fb0: frame buffer device
> [ 64.552013] [drm] Initialized rcar-du 1.0.0 20130110 for
> feb0.display on minor 0
> [ 64.559873] [drm] Device feb0.display probed
>
>>> Commit 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm device resume
>>> latency") fixes the second issue, but not the first.
>
> ... nor the third.
>
>>> Reverting commits 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm
>>> device resume latency") and 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume
>>> latency PM QoS") fixes both.
>
> ... all three.
>
>>> Do you have a clue?
>>> Thanks!
--
Jani Nikula, Intel Open Source Technology Center
ew code
>>
>> if ((temp & PIPEACONF_PIPE_STATE) != 0)
>> break;
>
> Suggest looking at latest sources. ;)
>
> Fixed by 67a3b63a54cb ("drm: gma500: fix logic error").
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Jani Nikula, Intel Open Source Technology Center
t; +
> return 0;
> +
> +report_failure:
> + gvt_vgpu_err("fail to copy guest ring buffer\n");
> + return ret;
> }
>
> int intel_gvt_scan_and_shadow_ringbuffer(struct intel_vgpu_workload
> *workload)
--
Jani Nikula, Intel Open Source Technology Center
stop(struct intel_dp
> *intel_dp)
> ret = -ETIMEDOUT;
> }
>
> - out:
> +enable_ips:
> hsw_enable_ips(intel_crtc);
> return ret;
> +
> +report_failure:
> + DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
> +e_io:
> + ret = -EIO;
> + goto enable_ips;
*shudder* Please no.
BR,
Jani.
> }
>
> static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
--
Jani Nikula, Intel Open Source Technology Center
t; all timer callbacks, switch to using the new timer_setup() and
>>> >> > > from_timer()
>>> >> > > to pass the timer pointer explicitly.
>>> >> > >
>>> >> > > Cc: Jani Nikula
>>> >>
modesetting in the next Xorg release, so will suffer from the same
>>easy GPU hang likelihood.
>>
>>Prior to SandyBridge there was zero tearing but beginning with
>>SandyBridge xf86-video-intel's TearFree=TRUE is the only reliable way
>>to fix Xorg tearing.
>>
>>I do appreciate you maintaining 4.1 so far and hate to admit that I'm
>>reliant on it on more than two machines, before and after Sandybridge,
>>exluding those machines which need a newer kernel. I also understand
>>how much work this is and since I'm not using Linux professionally for
>>a product, I can't offer compensation for your time. I can only offer
>>to collect and point you at a list of DRM bugs for validation of my
>>claims.
--
Jani Nikula, Intel Open Source Technology Center
r
patch does not compile.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Sun, 29 Oct 2017, Laurent Pinchart wrote:
> Hi Jani,
>
> On Friday, 27 October 2017 21:45:17 EET Jani Nikula wrote:
>> On Tue, 24 Oct 2017, SF Markus Elfring wrote:
>> > Add a jump target so that a bit of exception handling can be better reused
>> > at the end
is checked only when W=... is given?
Related, there was also a script to do reStructuredText lint style
checks in addition to the kernel-doc checks using make CHECK and
C=1. See [1].
BR,
Jani.
[1] http://mid.mail-archive.com/87h98quc1w.fsf@intel.com
> --
> To unsubscribe from this list
On Mon, 30 Oct 2017, Matthew Wilcox wrote:
> On Mon, Oct 30, 2017 at 05:19:18PM +0200, Jani Nikula wrote:
>> Related, there was also a script to do reStructuredText lint style
>> checks in addition to the kernel-doc checks using make CHECK and
>> C=1. See http:/
a.post_power_delay_ms);
> + hid_warn(hid, "Failed to enable hw power: %d\n", ret);
> } else if (ihid->irq_wake_enabled) {
> wake_status = disable_irq_wake(client->irq);
> if (!wake_status)
> diff --git a/include/linux/platform_data/i2c-hid.h
> b/include/linux/platform_data/i2c-hid.h
> index 1fb0882..40f1840 100644
> --- a/include/linux/platform_data/i2c-hid.h
> +++ b/include/linux/platform_data/i2c-hid.h
> @@ -14,6 +14,7 @@
>
> #include
>
> +struct gpio_desc;
> struct regulator;
>
> /**
> @@ -37,6 +38,8 @@ struct i2c_hid_platform_data {
> u16 hid_descriptor_address;
> struct regulator *supply;
> int post_power_delay_ms;
> + struct gpio_desc *reset_gpio;
> + int assert_reset_us;
> };
>
> #endif /* __LINUX_I2C_HID_H */
--
Jani Nikula, Intel Open Source Technology Center
There's plenty of drm/i915 related hardware and software documentation,
and firmware downloads for the latest platforms.
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f467845ef72..95c6bcb
i?id=92084.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
--
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/
what get_maintainer.pl already solves.
However, documenting all of this in the main kernel MAINTAINERS file is
just too much noise, and potentially confusing for community
contributors. Add support for specifying and using an alternate
MAINTAINERS file with --maintainers option.
Signed-off-by:
On Fri, 16 Oct 2015, Joe Perches wrote:
> On Fri, 2015-10-16 at 11:36 +0300, Jani Nikula wrote:
>> There are large and/or complex subsystems/drivers that have domain
>> experts that should review patches in their domain. One such example is
>> drm/i915. We'd like to be
1 - 100 of 950 matches
Mail list logo
