Re: linux-next: Tree for Jan 26 (gpu/drm/i915/)

Kconfig to keep the issues at bay. Since you're replying to linux-next, are you saying this is new? I wonder if something's changed elsewhere. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [RFC] doc: fix code snippet build warnings

On Tue, 16 Jan 2018, Markus Heiser <markus.hei...@darmarit.de> wrote: >> Am 16.01.2018 um 11:22 schrieb Jani Nikula <jani.nik...@linux.intel.com>: >> >> On Wed, 10 Jan 2018, Jonathan Corbet <cor...@lwn.net> wrote: >>> On Wed, 10 Jan 2018 15:04:53 +1100

Re: [RFC] doc: fix code snippet build warnings

On Tue, 16 Jan 2018, Markus Heiser wrote: >> Am 16.01.2018 um 11:22 schrieb Jani Nikula : >> >> On Wed, 10 Jan 2018, Jonathan Corbet wrote: >>> On Wed, 10 Jan 2018 15:04:53 +1100 >>> "Tobin C. Harding" wrote: >>> >>>>

Re: [RFC] doc: fix code snippet build warnings

ed onto the very end of any paragraph. The :: will be omitted if it is preceded by whitespace. The :: will be converted to a single colon if preceded by text" BR, Jani. [1] http://docutils.sourceforge.net/docs/user/rst/quickref.html#literal-blocks -- Jani Nikula, Intel Open Source Technology Center

Re: [RFC] doc: fix code snippet build warnings

of any paragraph. The :: will be omitted if it is preceded by whitespace. The :: will be converted to a single colon if preceded by text" BR, Jani. [1] http://docutils.sourceforge.net/docs/user/rst/quickref.html#literal-blocks -- Jani Nikula, Intel Open Source Technology Center

Re: [RFC] doc: fix code snippet build warnings

s with ones that have reference nodes within them. It's more complicated, but at that stage we can ignore stuff that should stay verbatim. I think it's also possible to check that the reference targets actually exist. In short, at that phase we have all the knowledge about the rst structure, parsed

Re: [RFC] doc: fix code snippet build warnings

thin them. It's more complicated, but at that stage we can ignore stuff that should stay verbatim. I think it's also possible to check that the reference targets actually exist. In short, at that phase we have all the knowledge about the rst structure, parsed by Sphinx, and we don't have to duplic

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

ble to properly discriminate between > having no regulator and not being able to get the regulator due to an error. Just a word of warning, IS_ERR(NULL) is false, and your proposed change would apparently require quite a churn all over the kernel. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

> having no regulator and not being able to get the regulator due to an error. Just a word of warning, IS_ERR(NULL) is false, and your proposed change would apparently require quite a churn all over the kernel. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Thu, 04 Jan 2018, Knut Omang <knut.om...@oracle.com> wrote: > On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote: >> On Thu, 04 Jan 2018, Knut Omang <knut.om...@oracle.com> wrote: >> > Add scripts/runchecks which has generic support for running >> >

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Thu, 04 Jan 2018, Knut Omang wrote: > On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote: >> On Thu, 04 Jan 2018, Knut Omang wrote: >> > Add scripts/runchecks which has generic support for running >> > checker tools in a convenient and user friendly way tha

Re: [git pull] drm fixes for 4.15-rc6

On Fri, 29 Dec 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Thu, 28 Dec 2017, Randy Dunlap <rdun...@infradead.org> wrote: >> It would be good to get this documentation build error patch >> merged into 4.15. Daniel Vetter says that he merged (applied) it.

Re: [git pull] drm fixes for 4.15-rc6

On Fri, 29 Dec 2017, Jani Nikula wrote: > On Thu, 28 Dec 2017, Randy Dunlap wrote: >> It would be good to get this documentation build error patch >> merged into 4.15. Daniel Vetter says that he merged (applied) it. >> >> [PATCH] documentation/gpu/i915: fix docs bu

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Thu, 04 Jan 2018, Knut Omang wrote: > Add scripts/runchecks which has generic support for running > checker tools in a convenient and user friendly way that > the author hopes can contribute to rein in issues detected > by these tools in a manageable and convenient way.

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

On Thu, 04 Jan 2018, Knut Omang wrote: > Add scripts/runchecks which has generic support for running > checker tools in a convenient and user friendly way that > the author hopes can contribute to rein in issues detected > by these tools in a manageable and convenient way. > > scripts/runchecks

Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

bit banging, or are the adapters just plain buggy? Do we have any control over gmbus timings (don't have the time to peruse the bpsec just now)? BR, Jani. > -Chris > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

bus timings (don't have the time to peruse the bpsec just now)? BR, Jani. > -Chris > _______ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center

Re: GPF with kernel 4.15-rc1, and display locks up

l: entry_SYSCALL_64_fastpath+0x13/0x6c > > I have attached the full GPF trace. > > (Haven't tried to login with ssh yet.) > > Mike. > > > ___ > 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: GPF with kernel 4.15-rc1, and display locks up

ath+0x13/0x6c > > I have attached the full GPF trace. > > (Haven't tried to login with ssh yet.) > > Mike. > > > ___ > 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: [RFC PATCH v2 00/13] Kernel based bootsplash

space bootsplash. We want our command-line tools to STFU if they don't have anything interesting to say. As a user, 99.99+% of the time I don't care what grub or dmesg have to say. Of course, with the kernel developer hat on, I want all of the clues every time in case something goes wrong. But this shouldn't have to be mutually exclusive. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

mand-line tools to STFU if they don't have anything interesting to say. As a user, 99.99+% of the time I don't care what grub or dmesg have to say. Of course, with the kernel developer hat on, I want all of the clues every time in case something goes wrong. But this shouldn't have to be mutually exclusive. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [git pull] drm fixes for 4.15-rc6

https://marc.info/?l=linux-kernel=151234419425847=2 Hi Randy, didn't look too closely but I presume our scripts tripped over the Fixes: tag that's split to two lines in that patch. I'll pick it up for our next fixes batch. Btw your documentation efforts haven't gone unnoticed, much appreciated.

Re: [git pull] drm fixes for 4.15-rc6

?l=linux-kernel=151234419425847=2 Hi Randy, didn't look too closely but I presume our scripts tripped over the Fixes: tag that's split to two lines in that patch. I'll pick it up for our next fixes batch. Btw your documentation efforts haven't gone unnoticed, much appreciated. BR, Jani. -- Jani Nik

Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

On Tue, 19 Dec 2017, Joe Perches <j...@perches.com> wrote: > drivers/gpu/drm/i915/i915_sysfs.c | 12 ++-- For i915, Acked-by: Jani Nikula <jani.nik...@intel.com> -- Jani Nikula, Intel Open Source Technology Center

Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

On Tue, 19 Dec 2017, Joe Perches wrote: > drivers/gpu/drm/i915/i915_sysfs.c | 12 ++-- For i915, Acked-by: Jani Nikula -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] docs: add submitting-pull-requests.rst

On Tue, 21 Nov 2017, "Tobin C. Harding" <m...@tobin.cc> wrote: > On Wed, Nov 15, 2017 at 04:09:32PM +0200, Jani Nikula wrote: >> On Wed, 15 Nov 2017, "Tobin C. Harding" <m...@tobin.cc> wrote: >> > Original email thread >> > >>

Re: [PATCH] docs: add submitting-pull-requests.rst

On Tue, 21 Nov 2017, "Tobin C. Harding" wrote: > On Wed, Nov 15, 2017 at 04:09:32PM +0200, Jani Nikula wrote: >> On Wed, 15 Nov 2017, "Tobin C. Harding" wrote: >> > Original email thread >> > >> > https://lkml.org/lkml/2

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

On Fri, 17 Nov 2017, Greg KH <gre...@linuxfoundation.org> wrote: > On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote: >> >> Cc: Greg >> >> On Wed, 15 Nov 2017, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: >> > On Wed

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

On Fri, 17 Nov 2017, Greg KH wrote: > On Fri, Nov 17, 2017 at 01:28:05PM +0200, Jani Nikula wrote: >> >> Cc: Greg >> >> On Wed, 15 Nov 2017, Ville Syrjälä wrote: >> > On Wed, Nov 15, 2017 at 04:44:54PM +, alexander.le...@verizon.com >> > wr

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

nst > backporting anything that isn't fixing a real issue affecting users. We > do try to add the cc:stable to such patches. Agreed. First, I think an automatic backport process is against the stable kernel rules (e.g. "It must fix a real bug that bothers people"). Second, we can't and

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

ainst the stable kernel rules (e.g. "It must fix a real bug that bothers people"). Second, we can't and won't take any responsibility for backports we didn't indicate with Cc: stable, a Fixes: tag, or a specific backport request. If you think there's a commit that should be backported and is known to fix a user visible issue (as per the stable rules!), please check with us first. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: 4.1 EOL

don't even know for sure if you have Sandy Bridge or not, although it's alluded to in your message. >From my point of view, you're shouting regression while giving us nothing to work with. You need to help us to help you. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: 4.1 EOL

e if you have Sandy Bridge or not, although it's alluded to in your message. >From my point of view, you're shouting regression while giving us nothing to work with. You need to help us to help you. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] docs: add submitting-pull-requests.rst

>> > + >> > +Note: please use the git protocol (for justification from Linus see >> > referenced >> > +email thread). >> >> We need a reference to that thread. >> >> > +If the char-misc-4.15-rc1 tag is not present in the repo that I am asking >> > to be >> > +pulled from, git will complain saying it is not there, a handy way to >> > remember >> > +to actually push it to a public location. >> > + >> > +The output of 'git request-pull' will contain the location of the git >> > tree and >> > +specific tag to pull from, and the full text description of that tag >> > (which is >> > +why you need to provide good information in that tag.) It will also >> > create a >> > +diffstat of the pull request, and a shortlog of the individual commits >> > that the >> > +pull request will provide. >> > + >> > + >> > +References >> > +-- >> > + >> > +The thread that this document is based on: >> > + >> > + https://lkml.org/lkml/2017/11/14/184 >> >> Ah, there's that reference. I think it should be at the top before you >> first start quoting from it. > > Perhaps (at start of document) > > This document was written by Tobin C. Harding (not an experienced > maintainer) primarily from emails by Greg Kroah-Hartman and Linus > Torvalds. Suggestions and fixes by Jonathan Corbet. Misrepresentation > was unintentional but inevitable, please direct abuse to "Tobin > C. Harding" <m...@tobin.cc>. > > Original email thread > > https://lkml.org/lkml/2017/11/14/184 Please use http://lkml.kernel.org/r/20171114110500.ga21...@kroah.com so people can find the messages using the message-id. Please consider using reStructuredText references instead of a semi-random looking indented block. BR, Jani. > >> I think there's something missing here: what do you do with that output >> from 'git request-pull'? There should be a little section on emailing it >> to the relevant upstream maintainer and how to decide where to copy the >> request to. Pull requests should always be copied to a public list so that >> others know that the request has been made. Some guidance on subject-line >> formatting would be good; as I recall, Linus filters mail that says "git" >> or "pull" specially. I might also add something about how to know when the >> pull has happened (sign up to the commits list if nothing else). >> >> Thanks for doing this, > > Cheers Jon, nice to work with you. > > Tobin. > -- > To unsubscribe from this list: send the line "unsubscribe linux-doc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] docs: add submitting-pull-requests.rst

from Linus see >> > referenced >> > +email thread). >> >> We need a reference to that thread. >> >> > +If the char-misc-4.15-rc1 tag is not present in the repo that I am asking >> > to be >> > +pulled from, git will complain saying it is not there, a handy way to >> > remember >> > +to actually push it to a public location. >> > + >> > +The output of 'git request-pull' will contain the location of the git >> > tree and >> > +specific tag to pull from, and the full text description of that tag >> > (which is >> > +why you need to provide good information in that tag.) It will also >> > create a >> > +diffstat of the pull request, and a shortlog of the individual commits >> > that the >> > +pull request will provide. >> > + >> > + >> > +References >> > +-- >> > + >> > +The thread that this document is based on: >> > + >> > + https://lkml.org/lkml/2017/11/14/184 >> >> Ah, there's that reference. I think it should be at the top before you >> first start quoting from it. > > Perhaps (at start of document) > > This document was written by Tobin C. Harding (not an experienced > maintainer) primarily from emails by Greg Kroah-Hartman and Linus > Torvalds. Suggestions and fixes by Jonathan Corbet. Misrepresentation > was unintentional but inevitable, please direct abuse to "Tobin > C. Harding" . > > Original email thread > > https://lkml.org/lkml/2017/11/14/184 Please use http://lkml.kernel.org/r/20171114110500.ga21...@kroah.com so people can find the messages using the message-id. Please consider using reStructuredText references instead of a semi-random looking indented block. BR, Jani. > >> I think there's something missing here: what do you do with that output >> from 'git request-pull'? There should be a little section on emailing it >> to the relevant upstream maintainer and how to decide where to copy the >> request to. Pull requests should always be copied to a public list so that >> others know that the request has been made. Some guidance on subject-line >> formatting would be good; as I recall, Linus filters mail that says "git" >> or "pull" specially. I might also add something about how to know when the >> pull has happened (sign up to the commits list if nothing else). >> >> Thanks for doing this, > > Cheers Jon, nice to work with you. > > Tobin. > -- > To unsubscribe from this list: send the line "unsubscribe linux-doc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jani Nikula, Intel Open Source Technology Center

Re: 4.1 EOL

On Tue, 14 Nov 2017, Tuncer Ayaz <tuncer.a...@gmail.com> wrote: > On 11/14/17, Jani Nikula <jani.nik...@linux.intel.com> wrote: >> >> Tuncer, where's your bug report? Can't find one. Please file your >> bug at the fdo bugzilla. > > I'm sorry if this wasn'

Re: 4.1 EOL

On Tue, 14 Nov 2017, Tuncer Ayaz wrote: > On 11/14/17, Jani Nikula wrote: >> >> Tuncer, where's your bug report? Can't find one. Please file your >> bug at the fdo bugzilla. > > I'm sorry if this wasn't clear. > > I didn't file a bug report since others have alre

Re: 4.1 EOL

or 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

Re: 4.1 EOL

or 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

Re: [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

On Thu, 09 Nov 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Wed, 08 Nov 2017, "Gustavo A. R. Silva" <garsi...@embeddedor.com> wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through

Re: [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

On Thu, 09 Nov 2017, Jani Nikula wrote: > On Wed, 08 Nov 2017, "Gustavo A. R. Silva" wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Addresses-Coverity-ID: 141432 >>

Re: [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

es-Coverity-ID: 141434 > Addresses-Coverity-ID: 141435 > Addresses-Coverity-ID: 141436 > Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com> Acked-by: Jani Nikula <jani.nik...@intel.com> > --- > drivers/gpu/drm/i915/intel_sdvo.c | 11 ++- > 1 file c

Re: [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

; Addresses-Coverity-ID: 141435 > Addresses-Coverity-ID: 141436 > Signed-off-by: Gustavo A. R. Silva Acked-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_sdvo.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_s

Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency

ne] *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

Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency

itching 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

Re: [PATCH v2 1/2] HID: i2c-hid: add reset gpio property

y_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

Re: [PATCH v2 1/2] HID: i2c-hid: add reset gpio property

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

Re: [PATCH] Check all .c files for bad kernel-doc comments

On Mon, 30 Oct 2017, Matthew Wilcox <wi...@infradead.org> 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 >&g

Re: [PATCH] Check all .c files for bad kernel-doc comments

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:/

Re: [PATCH] Check all .c files for bad kernel-doc comments

-- > To unsubscribe from this list: send the line "unsubscribe linux-doc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] Check all .c files for bad kernel-doc comments

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: send the line &quo

Re: [PATCH 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()

On Sun, 29 Oct 2017, Laurent Pinchart <laurent.pinch...@ideasonboard.com> 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

Re: [PATCH 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()

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 >>

Re: [PATCH 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()

CC software, which will detect that your patch does not compile. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 1/2] drm/rcar-du: Use common error handling code in rcar_du_encoders_init()

r patch does not compile. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

g the struct timer_list >>> >> > > pointer to >>> >> > > all timer callbacks, switch to using the new timer_setup() and >>> >> > > from_timer() >>> >> > > to pass the timer pointer explicitly. >>> >>

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

t; all timer callbacks, switch to using the new timer_setup() and >>> >> > > from_timer() >>> >> > > to pass the timer pointer explicitly. >>> >> > > >>> >> > > Cc: Jani Nikula >>> >>

Re: [PATCH 2/2] drm/i915/dp: Use common error handling code in intel_dp_sink_crc_stop()

nk_crc_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

Re: [PATCH 2/2] drm/i915/dp: Use common error handling code in intel_dp_sink_crc_stop()

gt; > - 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

Re: [PATCH] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

return ret; > - } > + if (ret < 0) > + goto report_failure; > + > 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

Re: [PATCH] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

> 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

Re: drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: warning: bitwise comparison always evaluates to false [-Wtautological-compare]

ied/linux/ > > > Regards > > > David Binderman > > > From: Jani Nikula <jani.nik...@linux.intel.com> > Sent: 24 October 2017 08:54 > To: David Binderman; patrik.r.jakobs...@gmail.com; airl...@linux.ie; > dri-de...@lists.freedesktop.org; linux-kernel@v

Re: drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: warning: bitwise comparison always evaluates to false [-Wtautological-compare]

t;> >> 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

Re: drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: warning: bitwise comparison always evaluates to false [-Wtautological-compare]

me \*.h -print` > drivers/gpu/drm/gma500/psb_intel_reg.h:#define PIPEACONF_PIPE_STATE > (1 << 30) > $ > > Suggest new code > > if ((temp & PIPEACONF_PIPE_STATE) != 0) > break; Suggest looking at latest sources. ;) Fixed by 67a3b63a54cb ("

Re: drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: warning: bitwise comparison always evaluates to false [-Wtautological-compare]

pu/drm/gma500/psb_intel_reg.h:#define PIPEACONF_PIPE_STATE > (1 << 30) > $ > > Suggest new 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

Re: [PATCH 4.13 30/53] drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel

; //Marek. > > > 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 <jani.nik...@intel.com> >> >> commit ea850f

Re: [PATCH 4.13 30/53] drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel

6 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. >> >> While technic

Re: Documentation: add Kernel Driver Statement to the kernel

file, you can read it as-such, right? *cough* reStructuredText *cough* BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: Documentation: add Kernel Driver Statement to the kernel

? *cough* reStructuredText *cough* BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/8] Documentation: fix ref to workqueue content

ueues. > + href="https://www.kernel.org/doc/Documentation/core-api/workqueue.rst;>workqueues. > > > The requesting task still does counter snapshotting and funnel-lock -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 3/8] Documentation: fix ref to workqueue content

ion/core-api/workqueue.rst;>workqueues. > > > The requesting task still does counter snapshotting and funnel-lock -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH v2] drm: Replace kzalloc with kcalloc

On Fri, 13 Oct 2017, Harsha Sharma <harshasharmai...@gmail.com> wrote: > Prefer kcalloc over kzalloc to allocate an array. > This patch fixes checkcpatch issue. > > Signed-off-by: Harsha Sharma <harshasharmai...@gmail.com> Reviewed-by: Jani Nikula <jani.nik...@intel.c

Re: [PATCH v2] drm: Replace kzalloc with kcalloc

On Fri, 13 Oct 2017, Harsha Sharma wrote: > Prefer kcalloc over kzalloc to allocate an array. > This patch fixes checkcpatch issue. > > Signed-off-by: Harsha Sharma Reviewed-by: Jani Nikula > --- > Changes in v2: > -kcalloc will take 3 arguments > > drivers/gpu

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

uct timer_list pointer to >>> all timer callbacks, switch to using the new timer_setup() and from_timer() >>> to pass the timer pointer explicitly. >>> >>> Cc: Daniel Vetter <daniel.vet...@intel.com> >>> Cc: Jani Nikula <jani.nik...@lin

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

h to using the new timer_setup() and from_timer() >>> to pass the timer pointer explicitly. >>> >>> Cc: Daniel Vetter >>> Cc: Jani Nikula >>> Cc: David Airlie >>> Cc: Chris Wilson >>> Cc: Joonas Lahtinen >>> Cc: Tvrtko Ursulin

Re: [PATCH 06/18] drm: use ARRAY_SIZE

9 - Patch 3: > drivers/gpu/drm/i915/gvt/vgpu.c | 3 ++- Patch 4: > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 7 --- Patch 5: > drivers/gpu/drm/via/via_verifier.c | 10 -- BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 06/18] drm: use ARRAY_SIZE

| 3 ++- Patch 4: > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 7 --- Patch 5: > drivers/gpu/drm/via/via_verifier.c | 10 -- BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 01/10] scripts: kernel-doc: get rid of unused output formats

As ReST is text, there's not much sense on outputting > on a different text format. > > After this patch, only man and rst output formats are > supported. FWIW, Acked-by: Jani Nikula <jani.nik...@intel.com> Please do keep at least two output formats going forward. Otherwise the

Re: [PATCH 01/10] scripts: kernel-doc: get rid of unused output formats

ense on outputting > on a different text format. > > After this patch, only man and rst output formats are > supported. FWIW, Acked-by: Jani Nikula Please do keep at least two output formats going forward. Otherwise the mechanisms of having more than one output format will bitrot

Re: [PATCH] drm: Reduce object size of drm_dev_printk/DRM_DEV_ uses

drv.h b/include/drm/drm_drv.h > index 71bbaaec836d..f6430f183ca8 100644 > --- a/include/drm/drm_drv.h > +++ b/include/drm/drm_drv.h > @@ -592,10 +592,9 @@ struct drm_driver { > int dev_priv_size; > }; > > -__printf(6, 7) > +__printf(4, 5) > void drm_dev_printk(const struct device *dev, const char *level, > - unsigned int category, const char *function_name, > - const char *prefix, const char *format, ...); > + unsigned int category, const char *format, ...); > __printf(3, 4) > void drm_printk(const char *level, unsigned int category, > const char *format, ...); -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm: Reduce object size of drm_dev_printk/DRM_DEV_ uses

ERN_DEBUG, DRM_UT_ ## level, \ > -__func__, "", fmt, ##args); \ > +fmt, ##__VA_ARGS__); \ > }) > > /** > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h > index 71bbaaec836d..

Re: [PATCH] drm/i915: Fix an error handling in 'intel_framebuffer_init()'

-EINVAL; > + goto err; > } > > stride_alignment = intel_fb_stride_alignment(fb, i); -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Fix an error handling in 'intel_framebuffer_init()'

fer *intel_fb, > > if (mode_cmd->handles[i] != mode_cmd->handles[0]) { > DRM_DEBUG_KMS("bad plane %d handle\n", i); > - return -EINVAL; > + goto err; > } > > s

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

On Thu, 31 Aug 2017, Randy Dunlap <rdun...@infradead.org> wrote: > On 08/31/17 09:36, Jani Nikula wrote: >> On Thu, 31 Aug 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote: >>> On Thu, 31 Aug 2017, Randy Dunlap <rdun...@infradead.org> wrote: >>&

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

On Thu, 31 Aug 2017, Randy Dunlap wrote: > On 08/31/17 09:36, Jani Nikula wrote: >> On Thu, 31 Aug 2017, Jani Nikula wrote: >>> On Thu, 31 Aug 2017, Randy Dunlap wrote: >>>> On 08/31/17 07:17, Jonathan Corbet wrote: >>>>> On Thu, 31 Aug 2017 10:5

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

On Thu, 31 Aug 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Thu, 31 Aug 2017, Randy Dunlap <rdun...@infradead.org> wrote: >> On 08/31/17 07:17, Jonathan Corbet wrote: >>> On Thu, 31 Aug 2017 10:56:26 -0300 >>> Mauro Carvalho

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

On Thu, 31 Aug 2017, Jani Nikula wrote: > On Thu, 31 Aug 2017, Randy Dunlap wrote: >> On 08/31/17 07:17, Jonathan Corbet wrote: >>> On Thu, 31 Aug 2017 10:56:26 -0300 >>> Mauro Carvalho Chehab wrote: >>> >>>> It should have something to do wit

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

wn to, and trying to work around non-UTF-8 LANG in both python 2 and 3 compatible ways. The odd thing is that I can reproduce the issue using a small python snippet, but not through Sphinx. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

and 3 compatible ways. The odd thing is that I can reproduce the issue using a small python snippet, but not through Sphinx. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

t recognize this. AFAIK that has nothing to do with python I/O, and everything to do with the encoding of that specific python source file. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 1/2] docs: kernel-doc comments are ASCII

has nothing to do with python I/O, and everything to do with the encoding of that specific python source file. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

ple trigger. You get to upload effects and have the kernel play them for you, also stopping them in a timely manner regardless of the userspace dying and whatnot. I didn't double check now, but IIRC you could also link the input to force feedback, e.g. for touch vibrations. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

d effects and have the kernel play them for you, also stopping them in a timely manner regardless of the userspace dying and whatnot. I didn't double check now, but IIRC you could also link the input to force feedback, e.g. for touch vibrations. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915/opregion: Remove null check before kfree

kfree(opregion->vbt_firmware); > - opregion->vbt_firmware = NULL; > - } > + kfree(opregion->vbt_firmware); > + opregion->vbt_firmware = NULL; > opregion->header = NULL; > opregion->acpi = NULL; > opregion->swsci = NULL; -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] drm/i915/opregion: Remove null check before kfree

ion->vbt_firmware = NULL; > - } > + kfree(opregion->vbt_firmware); > + opregion->vbt_firmware = NULL; > opregion->header = NULL; > opregion->acpi = NULL; > opregion->swsci = NULL; -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

LIST_HEAD(constraint_devices); >> static DEFINE_MUTEX(constraint_devices_mutex); >> >> +static bool boot_constraints_disabled; > > Again, this should only be an "enable" type of option, that kicks in if > you are using this type of bootloader/kernel interaction. Don't force > someone to disable it. I might add that "disable" type options lead to annoying double negatives. Regardless of the default, I'd generally prefer "enable" type options that you enable/disable as needed. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

Re: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

>> +static bool boot_constraints_disabled; > > Again, this should only be an "enable" type of option, that kicks in if > you are using this type of bootloader/kernel interaction. Don't force > someone to disable it. I might add that "disable" type options lead to annoying double negatives. Regardless of the default, I'd generally prefer "enable" type options that you enable/disable as needed. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

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

For intel-gfx it was in moderation, I let it through now. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

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

on, I let it through now. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

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

drivers/gpu/drm/i915/intel_fbdev.c > b/drivers/gpu/drm/i915/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

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