benefit from syntax highlighting in the first place.
BR,
Jani.
[1]
http://lkml.kernel.org/r/1478164053-4562-1-git-send-email-jani.nik...@intel.com
--
Jani Nikula, Intel Open Source Technology Center
@@
> +=
> +TPM documentation
> +=
This will pop up at the top level of the documentation. I'm not saying
that's necessarily wrong per se, but IMO you should spell out Trusted
Platform Module here instead of just using the acronym.
(Sure we have "GPU"
will pop up at the top level of the documentation. I'm not saying
that's necessarily wrong per se, but IMO you should spell out Trusted
Platform Module here instead of just using the acronym.
(Sure we have "GPU" at the top level, but I think that's a better known
acronym. And we might change that to "Graphics" anyway.)
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 02 Nov 2016, Mauro Carvalho Chehab <mche...@infradead.org> wrote:
> Em Wed, 02 Nov 2016 13:14:47 +0200
> Jani Nikula <jani.nik...@linux.intel.com> escreveu:
>
>> On Wed, 02 Nov 2016, Mauro Carvalho Chehab <mche...@osg.samsung.com> wrote:
>> > Thi
On Wed, 02 Nov 2016, Mauro Carvalho Chehab wrote:
> Em Wed, 02 Nov 2016 13:14:47 +0200
> Jani Nikula escreveu:
>
>> On Wed, 02 Nov 2016, Mauro Carvalho Chehab wrote:
>> > This series address a series of errors during PDF generation from
>> > media docum
e2f Mon Sep 17 00:00:00 2001
From: Jani Nikula <jani.nik...@intel.com>
Date: Wed, 2 Nov 2016 13:05:59 +0200
Subject: [PATCH] Documentation/sphinx: include admin-guide in the latex/pdf
build
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula <jani.ni
the convertion.
>
> This is a temporary solution (That's why I'm marking this series
> as RFC).
This seems to work on top of docs-next.
...but it'll break again if we include the missing admin-guide in the
build. :(
BR,
Jani.
>From c296287c65f4b6ad6272171456dcf8508c92ae2f Mon Sep 17 00:00:00 2001
From
system example and it was quite easy to bisect.
> To quote the merge commit msg:
>
> This also required some changes outside of the IOMMU code, but these are
> acked by the respective maintainers.
>
> Any help on bisecting into it would be awesome.
So the information here is pretty scarce. Please file a bug at [1],
describe the problem, perhaps add drm.debug=14 module parameter and
attach dmesg from boot to reproducing the problem.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
> To quote the merge commit msg:
>
> This also required some changes outside of the IOMMU code, but these are
> acked by the respective maintainers.
>
> Any help on bisecting into it would be awesome.
So the information here is pretty scarce. Please file a bug at [1],
describe the problem, perhaps add drm.debug=14 module parameter and
attach dmesg from boot to reproducing the problem.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
ld fix the pyc stuff. I suspect the rest have been
broken forever; will be fixed when the DocBook toolchain gets nuked. ;)
BR,
Jani.
[1]
http://lkml.kernel.org/r/1477945781-8354-1-git-send-email-jani.nik...@intel.com
> Removing scripts/.check-lc_ctype.cmd
> Removing scripts/.docproc.cmd
&g
he rest have been
broken forever; will be fixed when the DocBook toolchain gets nuked. ;)
BR,
Jani.
[1]
http://lkml.kernel.org/r/1477945781-8354-1-git-send-email-jani.nik...@intel.com
> Removing scripts/.check-lc_ctype.cmd
> Removing scripts/.docproc.cmd
> Removing scripts/basic
dev_priv->drm.dev->power.is_suspended)
>> +intel_hpd_poll_init(dev_priv);
>
> The flag would appear to get set between suspend and suspend_late, so
> looks like this should be sufficient for our purposes.
>
> Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Pushed to drm-intel-next-queued, thanks for the patch and review.
BR,
Jani.
>
>> }
>>
>> static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
>> --
>> 2.7.4
--
Jani Nikula, Intel Open Source Technology Center
and suspend_late, so
> looks like this should be sufficient for our purposes.
>
> Reviewed-by: Ville Syrjälä
Pushed to drm-intel-next-queued, thanks for the patch and review.
BR,
Jani.
>
>> }
>>
>> static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
>> --
>> 2.7.4
--
Jani Nikula, Intel Open Source Technology Center
bably no need to
> # emit the "does MAINTAINERS need updating?" message on file add/move/delete
> if ($line =~ /^\s*MAINTAINERS\s*\|/) {
> @@ -6204,6 +6215,10 @@ sub process {
> ERROR("MISSING_SIGN_OFF",
> "Mi
^\s*MAINTAINERS\s*\|/) {
> @@ -6204,6 +6215,10 @@ sub process {
> ERROR("MISSING_SIGN_OFF",
> "Missing Signed-off-by: line(s)\n");
> }
> + if ($is_patch && $has_commit_log && $chk_review && $review == 0) {
> + ERROR("MISSING_REVIEW",
> + "Missing Reviewed-by: line(s)\n");
> + }
>
> print report_dump();
> if ($summary && !($clean == 1 && $quiet == 1)) {
--
Jani Nikula, Intel Open Source Technology Center
roughly 300ms pause before the third call of that function. Example:
>
> <7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.869057] i915: cdclk < crtc_clock: 33750
ore the third call of that function. Example:
>
> <7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
> <7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
>
> This pattern of cdclk being 337500 after roughly 300ms is surprisingly
> stable.
>
> 4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
> that sets cdclk to 337500 and triggers this issue. Ideas?
>
> To be continued,
>
>
> Paul Bolle
--
Jani Nikula, Intel Open Source Technology Center
which
> should remain a reasonable way to read things as well.
Agreed, that's a very good point too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
way to read things as well.
Agreed, that's a very good point too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
lock contents using in the output, possibly accompanied
by a reStructuredText admonition block [1]. For the math and diagram
directives, I think this would work just fine.
BR,
Jani.
[1]
http://docutils.sourceforge.net/docs/ref/rst/directives.html#specific-admonitions
--
Jani Nikula, Intel Open Source Technology Center
g in the output, possibly accompanied
by a reStructuredText admonition block [1]. For the math and diagram
directives, I think this would work just fine.
BR,
Jani.
[1]
http://docutils.sourceforge.net/docs/ref/rst/directives.html#specific-admonitions
--
Jani Nikula, Intel Open Source Technology Center
;> ../include/drm/drmP.h:201:43: note: in definition of macro 'DRM_ERROR'
>> drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
>>^
>> ../drivers/gpu/drm/i915/gvt/gtt.c:1945:3: note: in expansion of macro
>> 'gvt_err'
>>gvt_err("fail to translate vaddr:0x%llx\n", (u64)vaddr);
>>^
>>
>>
>>
>> --
>> ~Randy
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
finition of macro 'DRM_ERROR'
>> drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
>>^
>> ../drivers/gpu/drm/i915/gvt/gtt.c:1945:3: note: in expansion of macro
>> 'gvt_err'
>>gvt_err("fail to translate vaddr:0x%llx\n", (u64)vaddr);
>>^
>>
>>
>>
>> --
>> ~Randy
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
t.org/coh/sphinx-contrib-mathml/overview
>
> But I haven't test. So, I'm not sure:
> - if it would work;
> - if it would be portable to both HTML and PDF outputs;
> - if it won't require an even weirder toolbox.
>
> Thanks,
> Mauro
> --
> 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
aven't test. So, I'm not sure:
> - if it would work;
> - if it would be portable to both HTML and PDF outputs;
> - if it won't require an even weirder toolbox.
>
> Thanks,
> Mauro
> --
> 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
On Thu, 20 Oct 2016, Andrzej Hajda <a.ha...@samsung.com> wrote:
> Hi Jani,
>
> Forgive me late response.
>
> On 12.10.2016 16:28, Jani Nikula wrote:
>> On Wed, 12 Oct 2016, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>>> On 11 October 2016 at 10:33
On Thu, 20 Oct 2016, Andrzej Hajda wrote:
> Hi Jani,
>
> Forgive me late response.
>
> On 12.10.2016 16:28, Jani Nikula wrote:
>> On Wed, 12 Oct 2016, Emil Velikov wrote:
>>> On 11 October 2016 at 10:33, Jani Nikula
>>> wrote:
>>>> On Tue, 1
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a47ec00a09d..689f7f08a100 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3951,6 +3951,7 @@ DRM DRIVERS
M: David Airlie <airl...
Signed-off-by: Jani Nikula
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a47ec00a09d..689f7f08a100 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3951,6 +3951,7 @@ DRM DRIVERS
M: David Airlie
L: dri-de...@lists.freedesktop.org
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 53df9ccc5573..a6bde481170c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3954,6 +3954,7 @@ M:David Airlie <airl...@lin
Signed-off-by: Jani Nikula
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 53df9ccc5573..a6bde481170c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3954,6 +3954,7 @@ M:David Airlie
L: dri-de...@lists.freedesktop.org
T: git
l.ch>
Cc: Joe Perches <j...@perches.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
Dust settled since the last time, maybe we can make URI work?
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git
Cc: Andrew Morton
Signed-off-by: Jani Nikula
---
Dust settled since the last time, maybe we can make URI work?
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 89112a65b831..4a47ec00a09d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -
Make it easier to find the developer chat for the subsystem or driver.
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 689f7f08a100..53df9ccc5573 100644
--- a/MAINTAINERS
+++ b/MAINT
Make it easier to find the developer chat for the subsystem or driver.
Signed-off-by: Jani Nikula
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 689f7f08a100..53df9ccc5573 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -76,6 +76,8
On Thu, 20 Oct 2016, Lu Baolu <baolu...@linux.intel.com> wrote:
> Hi Jani,
>
> On 10/19/2016 03:48 PM, Jani Nikula wrote:
>> On Wed, 19 Oct 2016, Lu Baolu <baolu...@linux.intel.com> wrote:
>>> Add Documentation/usb/usb3-debug-port.txt. This document includes
&g
On Thu, 20 Oct 2016, Lu Baolu wrote:
> Hi Jani,
>
> On 10/19/2016 03:48 PM, Jani Nikula wrote:
>> On Wed, 19 Oct 2016, Lu Baolu wrote:
>>> Add Documentation/usb/usb3-debug-port.txt. This document includes
>>> the user guide for USB3 debug port.
>> If you
ng in the output.
> +
> += start of bash scripts =
> +#!/bin/bash
> +
> +while true ; do
> + while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
> + :
> + done
> + cat /dev/ttyUSB0 >> xdbc.log
> +done
> += end of bash scripts ===
> +
> +You should be able to see the early boot message in xdbc.log.
--
Jani Nikula, Intel Open Source Technology Center
g host to read the kernel
> +log sent from debug target.
Same here. Alternatively, if you do
.. code-block:: sh
and indent the block, you'll get syntax highlighting in the output.
> +
> += start of bash scripts =
> +#!/bin/bash
> +
> +while true ; do
> + while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
> + :
> + done
> + cat /dev/ttyUSB0 >> xdbc.log
> +done
> += end of bash scripts ===
> +
> +You should be able to see the early boot message in xdbc.log.
--
Jani Nikula, Intel Open Source Technology Center
Python module names should not have hyphens per [PEP 8]. Drop the hyphen
from kernel-doc.py. The extension directive remains unchanged.
[PEP 8] https://www.python.org/dev/peps/pep-0008/#package-and-module-names
Reported-by: Markus Heiser <markus.hei...@darmarit.de>
Signed-off-by: Jani
Python module names should not have hyphens per [PEP 8]. Drop the hyphen
from kernel-doc.py. The extension directive remains unchanged.
[PEP 8] https://www.python.org/dev/peps/pep-0008/#package-and-module-names
Reported-by: Markus Heiser
Signed-off-by: Jani Nikula
---
Documentation/conf.py
> +Which if successful should print
> +
> + .../vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver -
> ../../../bus/vmbus/drivers/uio_hv_generic
> +
> +
> +
> +
> +
> +Things to know about uio_hv_generic
> +
> +On each interrupt, uio_hv_generic se
11d6f3/driver -
> ../../../bus/vmbus/drivers/uio_hv_generic
> +
> +
> +
> +
> +
> +Things to know about uio_hv_generic
> +
> +On each interrupt, uio_hv_generic sets the Interrupt Disable bit.
> +This prevents the device from generating further interrupts
> +until the bit is cleared. The userspace driver should clear this
> +bit before blocking and waiting for more interrupts.
> +
> +
> +
> +
>
> Further information
>
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 18 Oct 2016, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
> Em Tue, 18 Oct 2016 13:01:01 +0300
> Jani Nikula <jani.nik...@linux.intel.com> escreveu:
>
>> On Tue, 18 Oct 2016, Jonathan Corbet <cor...@lwn.net> wrote:
>> > So I raised
On Tue, 18 Oct 2016, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Oct 2016 13:01:01 +0300
> Jani Nikula escreveu:
>
>> On Tue, 18 Oct 2016, Jonathan Corbet wrote:
>> > So I raised this topic in talks at both Kernel Recipes and LinuxCon
>> > Europe, and nobody
ing and disagreements about the Sphinx build
stuff, I very much appreciate your efforts here, Mauro!
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
greements about the Sphinx build
stuff, I very much appreciate your efforts here, Mauro!
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
size_t size=sizeof(intel_dp->edp_dpcd); /* == EDP_DISPLAY_CTL_CAP_SIZE */
> int ret;
>
> ret=drm_dp_dpcd_read(_dp->aux,
> DP_EDP_DPCD_REV,intel_dp->edp_dpcd,size);
>
> if (ret != size )
> ..
>
> }
>
> this way it improves readability and reduces line length.
Not convinced, let's just take the simple brace fix now.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
gt; ret=drm_dp_dpcd_read(_dp->aux,
> DP_EDP_DPCD_REV,intel_dp->edp_dpcd,size);
>
> if (ret != size )
> ..
>
> }
>
> this way it improves readability and reduces line length.
Not convinced, let's just take the simple brace fix now.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
don't lose track.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
ugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 12 Oct 2016, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 11 October 2016 at 10:33, Jani Nikula <jani.nik...@linux.intel.com> wrote:
>> On Tue, 11 Oct 2016, "Sun, Jing A" <jing.a@intel.com> wrote:
>>> It's needed that DRM Dri
On Wed, 12 Oct 2016, Emil Velikov wrote:
> On 11 October 2016 at 10:33, Jani Nikula wrote:
>> On Tue, 11 Oct 2016, "Sun, Jing A" wrote:
>>> It's needed that DRM Driver module could be removed and reloaded after
>>> kernel booting on the projects th
truly hope
> Hajda/Iwai's patches would be accepted and merged. No downside of it
> after all.
I think it's good to be able to unload and reload modules for debugging
and development, but not for normal use.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
tches would be accepted and merged. No downside of it
> after all.
I think it's good to be able to unload and reload modules for debugging
and development, but not for normal use.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
d attach dmesg from boot to the problem into the
bug.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
oot to the problem into the
bug.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
patch does *not* fix this issue.
Interestingly, I am able to reload i915 and drm. Our CI has tests for
i915 unload/reload, but does not check drm. In any case the config
problem should not impact the reloadability of i915.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
Interestingly, I am able to reload i915 and drm. Our CI has tests for
i915 unload/reload, but does not check drm. In any case the config
problem should not impact the reloadability of i915.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
onfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -22,7 +22,7 @@ menuconfig DRM
> (/dev/agpgart) support if it is available for your platform.
>
> config DRM_MIPI_DSI
> - bool
> + tristate
> depends on DRM
>
> config DRM_DP_AUX_CHARDEV
--
Jani Nikula, Intel Open Source Technology Center
M
> (/dev/agpgart) support if it is available for your platform.
>
> config DRM_MIPI_DSI
> - bool
> + tristate
> depends on DRM
>
> config DRM_DP_AUX_CHARDEV
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 05 Oct 2016, Daniel Vetter <dan...@ffwll.ch> wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
On Wed, 05 Oct 2016, Daniel Vetter wrote:
> Jani Nikula has a patch with a scrip to make the one kernel-doc parser
> into a lint/checker pass over the entire kernel. I think that'd would
> be more robust instead of trying to approximate the real kerneldoc
> parser. Otoh that parser
in drm-misc, so this needs to go in through
drm-misc as well. Daniel?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ot;drm/i915/debugfs: Move out pipe CRC code")
>> Fixes: 13fa0253d97a ("drm/i915: Use new CRC debugfs API")
> Reveiwed-by: Chris Wilson
Reveiwed tyop.
The commits being fixed are in drm-misc, so this needs to go in through
drm-misc as well. Daniel?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 22 Sep 2016, Jean Delvare <jdelv...@suse.de> 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
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
&
atch is submitted upstream, unless the maintainer
> agreed otherwise."
>
> Not sure if we need something for CHECK, as these messages are not
> printed by default so I'd assume people who get them know what they
> asked for. But apparently these confused Julia so maybe a similar
> explanation would be needed for them too.
--
Jani Nikula, Intel Open Source Technology Center
ringing 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 patch is submitted upstre
t, I did 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
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
> @@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private
> *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
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
v_priv)
> break;
> default:
> dev_err(dev->dev, "Unknown revision of GCT!\n");
> + return;
> }
>
> out:
--
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
i->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
zeof(*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
ct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL);
> if (!gct)
> return -1;
--
Jani Nikula, Intel Open Source Technology Center
drm_psb_private
> *dev_priv, u32 addr)
> if (read_vbt_r10(addr, ))
> 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
nstead 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
t 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
le of
> times.
>
> 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
y 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
On Mon, 19 Sep 2016, Shuah Khan <shua...@osg.samsung.com> 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
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
/gpu/drm/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
07db..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, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Mon, 19 Sep 2016, Dave Airlie <airl...@gmail.com> wrote:
>> Hi Linus,
>>
>> One important drm 32/64 ABI fix came in so I'll dequeue what I have, the
>> rest is
>> just exynos
On Mon, 19 Sep 2016, Jani Nikula wrote:
> On Mon, 19 Sep 2016, Dave Airlie wrote:
>> Hi Linus,
>>
>> One important drm 32/64 ABI fix came in so I'll dequeue what I have, the
>> rest is
>> just exynos runtime pm fixes, but the net removal of code seems lik
oradic this week due to school holidays, so if anything
> urgent
> turns up, Daniel will take care of it.
Hmm, missing my pull req [1]?
BR,
Jani.
[1] http://marc.info/?i=87intxpfay@intel.com
--
Jani Nikula, Intel Open Source Technology Center
e to school holidays, so if anything
> urgent
> turns up, Daniel will take care of it.
Hmm, missing my pull req [1]?
BR,
Jani.
[1] http://marc.info/?i=87intxpfay....@intel.com
--
Jani Nikula, Intel Open Source Technology Center
struct intel_crtc_state *pipe_config)
> +static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config)
Already fixed upstream.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Sun, 18 Sep 2016, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Am 07.09.2016 um 15:28 schrieb Jani Nikula <jani.nik...@linux.intel.com>:
>
>> On Wed, 07 Sep 2016, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>>> When running "make htmldo
te_bpp(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config)
Already fixed upstream.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Sun, 18 Sep 2016, Markus Heiser wrote:
> Am 07.09.2016 um 15:28 schrieb Jani Nikula :
>
>> On Wed, 07 Sep 2016, Geert Uytterhoeven wrote:
>>> When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
>>> in the source tree instead of in th
On Thu, 15 Sep 2016, Martin Steigerwald <mar...@lichtvoll.de> wrote:
> Am Mittwoch, 14. September 2016, 14:14:35 CEST schrieb Jani Nikula:
>> On Wed, 14 Sep 2016, Jani Nikula <jani.nik...@linux.intel.com> wrote:
>> > On Wed, 14 Sep 2016, Pavel Machek <pa...@ucw.cz
On Thu, 15 Sep 2016, Martin Steigerwald wrote:
> Am Mittwoch, 14. September 2016, 14:14:35 CEST schrieb Jani Nikula:
>> On Wed, 14 Sep 2016, Jani Nikula wrote:
>> > On Wed, 14 Sep 2016, Pavel Machek wrote:
>> >> For the "sometimes need xrandr after resume
RIME |
> DRIVER_RENDER | DRIVER_MODESET,
> - .open = i915_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
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
5_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
701 - 800 of 1745 matches
Mail list logo
