;
> val |= (ULPS_STATE_ENTER | DEVICE_READY);
> I915_WRITE(MIPI_DEVICE_READY(port), val);
> - usleep_range(2, 3);
> + udelay(2);
>
> /* 3. Exit ULPS */
> val = I915_READ(MIPI_DEVICE_READY(port));
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 15 Dec 2016, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire <hof...@osadl.org> wrote:
>> usleep_range() is intended for delays in the 10us to 10ms range that need
>> good precision. a useleep_range(1, will
On Thu, 15 Dec 2016, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> usleep_range() is intended for delays in the 10us to 10ms range that need
>> good precision. a useleep_range(1, will effectively be no more than an
>> imprecise udelay with some a
tel_encoder
> *encoder,
> config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
>
> /* wait at least 0.5 us after ungating before enabling VCO */
> - usleep_range(1, 10);
> + udelay(1);
>
> vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, config->dsi_pll.ctrl);
--
Jani Nikula, Intel Open Source Technology Center
config->dsi_pll.ctrl & ~DSI_PLL_VCO_EN);
>
> /* wait at least 0.5 us after ungating before enabling VCO */
> - usleep_range(1, 10);
> + udelay(1);
>
> vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, config->dsi_pll.ctrl);
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 13 Dec 2016, Nicholas Mc Guire <der.h...@hofr.at> wrote:
> I fully agree - without automation it is almost usless
> the coccinelle spatch is a seperate patch and it is tested butnot yet
> submitted.
Good, good! Sorry for the noise.
BR,
Jani.
--
Jani Nikula, In
On Tue, 13 Dec 2016, Nicholas Mc Guire wrote:
> I fully agree - without automation it is almost usless
> the coccinelle spatch is a seperate patch and it is tested butnot yet
> submitted.
Good, good! Sorry for the noise.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
less than 50 microseconds probably is only preventing
> + timer subsystem optimization but providing no benefit.
> +
> SLEEPING FOR LARGER MSECS ( 10ms+ )
> * Use msleep or possibly msleep_interruptible
--
Jani Nikula, Intel Open Source Technology Center
y preventing
> + timer subsystem optimization but providing no benefit.
> +
> SLEEPING FOR LARGER MSECS ( 10ms+ )
> * Use msleep or possibly msleep_interruptible
--
Jani Nikula, Intel Open Source Technology Center
w that is indeed the right answer, and the attitude we're looking for!
Being able to say "no", especially wrt fbdev drivers, is a must have
quality. You're hired! ;D
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
re looking for!
Being able to say "no", especially wrt fbdev drivers, is a must have
quality. You're hired! ;D
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
stead.
I don't have the time for this. I hope the bug reporters who'll be told
to report the bugs somewhere else do.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
or this. I hope the bug reporters who'll be told
to report the bugs somewhere else do.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 08 Dec 2016, "Rafael J. Wysocki" <r...@rjwysocki.net> wrote:
> On Wednesday, December 07, 2016 10:35:07 AM Jani Nikula wrote:
>> On Wed, 07 Dec 2016, "Rafael J. Wysocki" <r...@rjwysocki.net> wrote:
>> > On Monday, December 05, 2016 02:03:5
On Thu, 08 Dec 2016, "Rafael J. Wysocki" wrote:
> On Wednesday, December 07, 2016 10:35:07 AM Jani Nikula wrote:
>> On Wed, 07 Dec 2016, "Rafael J. Wysocki" wrote:
>> > On Monday, December 05, 2016 02:03:59 PM Jani Nikula wrote:
>> >> Different
On Wed, 07 Dec 2016, "Rafael J. Wysocki" <r...@rjwysocki.net> wrote:
> On Monday, December 05, 2016 02:03:59 PM Jani Nikula wrote:
>> Different subsystems and drivers have different preferences for where to
>> file bugs and what information to include. 6865644
On Wed, 07 Dec 2016, "Rafael J. Wysocki" wrote:
> On Monday, December 05, 2016 02:03:59 PM Jani Nikula wrote:
>> Different subsystems and drivers have different preferences for where to
>> file bugs and what information to include. 686564434e88 ("MAINTAINERS:
>&
g tracker directly, a web
page for detailed info on filing bugs, or a mailto: URI.
Fixes: 686564434e88 ("MAINTAINERS: Add bug tracking system location entry type")
Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Signed-off-by: Jani
g tracker directly, a web
page for detailed info on filing bugs, or a mailto: URI.
Fixes: 686564434e88 ("MAINTAINERS: Add bug tracking system location entry type")
Cc: Rafael J. Wysocki
Cc: Andrew Morton
Signed-off-by: Jani Nikula
---
Rafael, I just noticed the "B:"
an then reassign to the right
> component if it's not a kernel issue.\n");
> - DRM_INFO("The gpu crash dump is required to analyze gpu hangs,
> so please always attach it.\n");
> - DRM_INFO("GPU crash dump saved to
> /sys/class/drm/card%d/error\n",
> - dev_priv->drm.primary->index);
> - warned = true;
> - }
> }
>
> void i915_error_state_get(struct drm_device *dev,
--
Jani Nikula, Intel Open Source Technology Center
rnel issue.\n");
> - DRM_INFO("The gpu crash dump is required to analyze gpu hangs,
> so please always attach it.\n");
> - DRM_INFO("GPU crash dump saved to
> /sys/class/drm/card%d/error\n",
> - dev_priv->drm.primary->index);
> - warned = true;
> - }
> }
>
> void i915_error_state_get(struct drm_device *dev,
--
Jani Nikula, Intel Open Source Technology Center
That is all.
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 29 Nov 2016, Mauro Carvalho Chehab wrote:
> Sorry, but I agree with Daniel here: we should provide a guide
> for those people that will be helping with the document conversion.
That goal is not mutually exclusive with keeping this document concise.
That is all.
Jani.
--
Jani
ar and consice. I don't approve of the changes here. This is
going to sound like bikeshedding, but I just couldn't make myself not
reply.
> Cc: Jonathan Corbet <cor...@lwn.net>
> Cc: linux-...@vger.kernel.org
> Cc: Christoph Hellwig <h...@infradead.org>
> Cc: Peter Zijlstra
e of the changes here. This is
going to sound like bikeshedding, but I just couldn't make myself not
reply.
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Christoph Hellwig
> Cc: Peter Zijlstra
> Cc: Jani Nikula
> Cc: Mauro Carvalho Chehab
> Signed-off-by: D
On Mon, 28 Nov 2016, Peter Zijlstra <pet...@infradead.org> wrote:
> On Mon, Nov 28, 2016 at 01:16:45PM +0200, Jani Nikula wrote:
>> Using rst we can produce decent HTML pages, and make them available at
>> [1], in context. You don't have to read that, but it will be a lot
On Mon, 28 Nov 2016, Peter Zijlstra wrote:
> On Mon, Nov 28, 2016 at 01:16:45PM +0200, Jani Nikula wrote:
>> Using rst we can produce decent HTML pages, and make them available at
>> [1], in context. You don't have to read that, but it will be a lot more
>> discoverable for
l rst a "coding style" for plain text. We have
pretty uniform C code, I don't think it's unreasonable to have a little
bit of consistency in the plain text. And really, it's not much we're
asking.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
plain text. We have
pretty uniform C code, I don't think it's unreasonable to have a little
bit of consistency in the plain text. And really, it's not much we're
asking.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ocks. It would result in a smaller diff. But other than that, it's
fine.
I'm sure Peter is capable of editing a file with a .rst extension, and
we can clean up any hickups afterwards if getting the formatting right
is insurmountable.
> I will drop this patch.
Please don't. Please let Jon be the judge of that.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
that, it's
fine.
I'm sure Peter is capable of editing a file with a .rst extension, and
we can clean up any hickups afterwards if getting the formatting right
is insurmountable.
> I will drop this patch.
Please don't. Please let Jon be the judge of that.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 23 Nov 2016, Daniel Vetter <dan...@ffwll.ch> wrote:
> On Wed, Nov 23, 2016 at 11:23:23AM +, Liviu Dudau wrote:
>> On Wed, Nov 23, 2016 at 01:00:07PM +0200, Jani Nikula wrote:
>> > On Wed, 23 Nov 2016, Liviu Dudau <liviu.du...@arm.com> wrote:
>> >
On Wed, 23 Nov 2016, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 11:23:23AM +, Liviu Dudau wrote:
>> On Wed, Nov 23, 2016 at 01:00:07PM +0200, Jani Nikula wrote:
>> > On Wed, 23 Nov 2016, Liviu Dudau wrote:
>> > > drm_get_format_name() de-references the
annoy users that did not pass valid parameters to
> function.
>
> Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name())
> Cc: Eric Engestrom <e...@engestrom.ch>
> Cc: Rob Clark <robdcl...@gmail.com>
> Cc: Jani Nikula <jani.ni
not pass valid parameters to
> function.
>
> Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name())
> Cc: Eric Engestrom
> Cc: Rob Clark
> Cc: Jani Nikula
> Cc: Daniel Vetter
>
> Signed-off-by: Liviu Dudau
> ---
> I still think s
lds. I think it should Just Work(tm).
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ork(tm).
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
spaces within attributes with
newlines, and they should be normalized back to spaces by any compliant
xml parser.
You can use tidy or xmllint to clean up the xml before
committing. Unfortunately I couldn't make tidy actually wrap the long
attributes, but could be PEBKAC.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
aces by any compliant
xml parser.
You can use tidy or xmllint to clean up the xml before
committing. Unfortunately I couldn't make tidy actually wrap the long
attributes, but could be PEBKAC.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ms :)
FWIW I'm all for doing this stuff in Sphinx, with Sphinx extensions. And
to me it sounds like what you describe is interesting outside of kernel
too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
his stuff in Sphinx, with Sphinx extensions. And
to me it sounds like what you describe is interesting outside of kernel
too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ether they're
seasoned kernel developers or newcomers purely interested in
documentation.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ers or newcomers purely interested in
documentation.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
rting all the .gif and .png files to .pnm. This would
> make the files patchable but also add around 25MB to the uncompressed
> kernel source tree (118kb compressed, compared to 113kb for the .gif and
> .png files). This is certainly worse than the uuencoded files you
> had before
>
> Arnd
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Jani Nikula, Intel Open Source Technology Center
m. This would
> make the files patchable but also add around 25MB to the uncompressed
> kernel source tree (118kb compressed, compared to 113kb for the .gif and
> .png files). This is certainly worse than the uuencoded files you
> had before
>
> Arnd
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 17 Nov 2016, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> We don't just need better doc toolchains, we also need better docs for
> our doc toolchain!
>
> v2: Make sure we don't have foo twice (Jani).
Thanks, *now* LGTM. :)
>
> Cc: Daniel Vetter <dan...@
On Thu, 17 Nov 2016, Daniel Vetter wrote:
> We don't just need better doc toolchains, we also need better docs for
> our doc toolchain!
>
> v2: Make sure we don't have foo twice (Jani).
Thanks, *now* LGTM. :)
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Jona
On Thu, 17 Nov 2016, Jani Nikula <jani.nik...@intel.com> wrote:
> On Thu, 17 Nov 2016, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>> We don't just need better doc toolchains, we also need better docs for
>> our doc toolchain!
>
> Mea culpa. Thanks, LGTM.
Oh, th
On Thu, 17 Nov 2016, Jani Nikula wrote:
> On Thu, 17 Nov 2016, Daniel Vetter wrote:
>> We don't just need better doc toolchains, we also need better docs for
>> our doc toolchain!
>
> Mea culpa. Thanks, LGTM.
Oh, the example struct now has too "foo" fields, do
On Thu, 17 Nov 2016, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> We don't just need better doc toolchains, we also need better docs for
> our doc toolchain!
Mea culpa. Thanks, LGTM.
BR,
Jani.
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Jani Nikula <jani.nik..
On Thu, 17 Nov 2016, Daniel Vetter wrote:
> We don't just need better doc toolchains, we also need better docs for
> our doc toolchain!
Mea culpa. Thanks, LGTM.
BR,
Jani.
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
>
On Wed, 16 Nov 2016, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
> On 16 November 2016 at 13:58, Jani Nikula <jani.nik...@linux.intel.com> wrote:
>> On Wed, 16 Nov 2016, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
>>> On 15 November 2016 at 09:27, Jani
On Wed, 16 Nov 2016, Tomeu Vizoso wrote:
> On 16 November 2016 at 13:58, Jani Nikula wrote:
>> On Wed, 16 Nov 2016, Tomeu Vizoso wrote:
>>> On 15 November 2016 at 09:27, Jani Nikula
>>> wrote:
>>>> On Tue, 15 Nov 2016, David Weinehall wrote:
>>
On Wed, 16 Nov 2016, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
> On 15 November 2016 at 09:27, Jani Nikula <jani.nik...@linux.intel.com> wrote:
>> On Tue, 15 Nov 2016, David Weinehall <t...@kernel.org> wrote:
>>> On Mon, Nov 14, 2016 at 12:44:25PM +0200
On Wed, 16 Nov 2016, Tomeu Vizoso wrote:
> On 15 November 2016 at 09:27, Jani Nikula wrote:
>> On Tue, 15 Nov 2016, David Weinehall wrote:
>>> On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
>>>> On Thu, 06 Oct 2016, Tomeu Vizoso wrote:
>>&g
On Tue, 15 Nov 2016, David Weinehall <t...@kernel.org> wrote:
> On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
>> On Thu, 06 Oct 2016, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> >
On Tue, 15 Nov 2016, David Weinehall wrote:
> On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
>> On Thu, 06 Oct 2016, Tomeu Vizoso wrote:
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > ind
nale for not expressing this dependency in terms of Kconfig to
begin with. With this, it's hidden in code, and the hwmon stuff gets
used if the conditions for "nouveau depends on hwmon" are met, by
chance, but it's not enforced.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
pendency in terms of Kconfig to
begin with. With this, it's hidden in code, and the hwmon stuff gets
used if the conditions for "nouveau depends on hwmon" are met, by
chance, but it's not enforced.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
+ if (IS_G4X(dev_priv))
> + g4x_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + vlv_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_HASWELL(dev_priv) && crtc->index == PIPE_A)
> + hsw_trans_edp_pipe_A_crc_wa(dev_priv, false);
> +
> + hsw_enable_ips(intel_crtc);
> + }
> +
> + pipe_crc->skipped = 0;
> + *values_cnt = 5;
> +
> +out:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
> +}
--
Jani Nikula, Intel Open Source Technology Center
g4x_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + vlv_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_HASWELL(dev_priv) && crtc->index == PIPE_A)
> + hsw_trans_edp_pipe_A_crc_wa(dev_priv, false);
> +
> + hsw_enable_ips(intel_crtc);
> + }
> +
> + pipe_crc->skipped = 0;
> + *values_cnt = 5;
> +
> +out:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
> +}
--
Jani Nikula, Intel Open Source Technology Center
l.com>
>> > References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
>> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>> > Link:
>> > http://patchwork.freedesktop.org/patch/msgid/1476208368-5
port has no alternate aux
>> > ch/ddc pin
>> >
>> > Cc: Maarten Maathuis
>> > Tested-by: Maarten Maathuis
>> > References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
>> > Signed-off-by: Ville Syrjälä
>> > Link:
>>
On Thu, 10 Nov 2016, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Thu, 10 Nov 2016, Markus Heiser <markus.hei...@darmarit.de> wrote:
>> Could this POC persuade you, if so, I send a more elaborate RFC,
>> what do you think about?
>
>
On Thu, 10 Nov 2016, Jani Nikula wrote:
> On Thu, 10 Nov 2016, Markus Heiser wrote:
>> Could this POC persuade you, if so, I send a more elaborate RFC,
>> what do you think about?
>
> Sorry, I do not wish to be part of this.
That was uncalled for, apologies.
Like
On Thu, 10 Nov 2016, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote:
> Hi Jani,
>
> On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote:
>> On Thu, 10 Nov 2016, Laurent Pinchart wrote:
>> > The issue here is that printk can't format the fourcc as a string b
On Thu, 10 Nov 2016, Laurent Pinchart wrote:
> Hi Jani,
>
> On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote:
>> On Thu, 10 Nov 2016, Laurent Pinchart wrote:
>> > The issue here is that printk can't format the fourcc as a string by
>> > itself. There's a bu
On Thu, 10 Nov 2016, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Could this POC persuade you, if so, I send a more elaborate RFC,
> what do you think about?
Sorry, I do not wish to be part of this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 10 Nov 2016, Markus Heiser wrote:
> Could this POC persuade you, if so, I send a more elaborate RFC,
> what do you think about?
Sorry, I do not wish to be part of this.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
scary from the
security standpoint. And what if the hook has to allocate memory? Can't
do that in atomic contexts.
BR,
Jani.
>
>> Could you give me a quick explanation or point me to a doc/page that
>> explains how the various trees and branches get merged?
>> I googled a bit
if the hook has to allocate memory? Can't
do that in atomic contexts.
BR,
Jani.
>
>> Could you give me a quick explanation or point me to a doc/page that
>> explains how the various trees and branches get merged?
>> I googled a bit and found this doc [4] by Jani, but it doe
On Wed, 09 Nov 2016, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula <jani.nik...@linux.intel.com>:
>>> So I vote for :
>>>
>>>> 1) copy (or symlink) all rst files to Documentation/output (or to
On Wed, 09 Nov 2016, Markus Heiser wrote:
> Am 09.11.2016 um 12:16 schrieb Jani Nikula :
>>> So I vote for :
>>>
>>>> 1) copy (or symlink) all rst files to Documentation/output (or to the
>>>> build dir specified via O= directive) and generate the
On Wed, 09 Nov 2016, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
> Em Wed, 09 Nov 2016 13:16:55 +0200
> Jani Nikula <jani.nik...@linux.intel.com> escreveu:
>
>> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> &
On Wed, 09 Nov 2016, Mauro Carvalho Chehab wrote:
> Em Wed, 09 Nov 2016 13:16:55 +0200
> Jani Nikula escreveu:
>
>> >> 1) copy (or symlink) all rst files to Documentation/output (or to the
>> >> build dir specified via O= directive) and generate the *.pd
that IMHO shouldn't exist...
> IMO placing 'sourcedir' to O= is more sane since this marries the
> Linux Makefile concept (relative to $PWD) with the sphinx concept
> (in or below 'sourcedir').
>
>
> -- Markus --
>
>
> --
> 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
this marries the
> Linux Makefile concept (relative to $PWD) with the sphinx concept
> (in or below 'sourcedir').
>
>
> -- Markus --
>
>
> --
> 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
rrent batch of fixes by making unsubstantiated claims. Please do file
a bug about that issue over at [1] so we don't hijack this thread.
Thanks,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
g unsubstantiated claims. Please do file
a bug about that issue over at [1] so we don't hijack this thread.
Thanks,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 08 Nov 2016, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Mon, 07 Nov 2016, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
>> This series address a series of errors during PDF generation from
>> media documentation.
>
> I'm missing p
On Tue, 08 Nov 2016, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Mauro Carvalho Chehab wrote:
>> This series address a series of errors during PDF generation from
>> media documentation.
>
> I'm missing patches 3-6 of this series, and so is the archive.
I meant 4-6.
>
On Mon, 07 Nov 2016, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:
> This series address a series of errors during PDF generation from
> media documentation.
I'm missing patches 3-6 of this series, and so is the archive.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Mon, 07 Nov 2016, Mauro Carvalho Chehab wrote:
> This series address a series of errors during PDF generation from
> media documentation.
I'm missing patches 3-6 of this series, and so is the archive.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ranch of http://cgit.freedesktop.org/drm-intel. It's
-rc4 plus half a dozen fixes, including "drm/i915: Round tile chunks up
for constructing partial VMAs" which should fix the corruption.
Please try that, and report back. If it doesn't fix the issue, please
file a bug at the freedesktop.org bugzilla.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
g/drm-intel. It's
-rc4 plus half a dozen fixes, including "drm/i915: Round tile chunks up
for constructing partial VMAs" which should fix the corruption.
Please try that, and report back. If it doesn't fix the issue, please
file a bug at the freedesktop.org bugzilla.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Mon, 07 Nov 2016, Eric Engestrom <eric.engest...@imgtec.com> wrote:
> On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
>> On Mon, 07 Nov 2016, Eric Engestrom <e...@engestrom.ch> wrote:
>> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>> >
On Mon, 07 Nov 2016, Eric Engestrom wrote:
> On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
>> On Mon, 07 Nov 2016, Eric Engestrom wrote:
>> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>> >
>> > drm: make drm_get_format_name thread-sa
I hope I get a
> chance to report it there as well and you get to decide.
If drm-intel-fixes doesn't fix the issue for you, please file a *new*
bug over at the freedesktop.org bugzilla.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
to report it there as well and you get to decide.
If drm-intel-fixes doesn't fix the issue for you, please file a *new*
bug over at the freedesktop.org bugzilla.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
gt; X.org runs with modesetting driver (default was changed in Debian Sid a while
> back).
>
> Thanks,
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
river (default was changed in Debian Sid a while
> back).
>
> Thanks,
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
correct fix is to have this fixed in upstream Sphinx, but
as a workaround an extension doing the above seems plausible, and not
too much effort - provided that we can make the raw latex work.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
n upstream Sphinx, but
as a workaround an extension doing the above seems plausible, and not
too much effort - provided that we can make the raw latex work.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
merge.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
things...
Pretty please? It's easier for us to direct folks at the bug, with
history and logs in one place. I realize only Daniel and me were Cc'd
here, not intel-gfx list.
Also, please double check your bisect. Not sure why the finger points at
i915 when the bisect points at iommu merge.
BR,
Jani.
--
har *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
I wonder if it would be better to make that return "const char *". If
the user really wants to look under the hood, there's buf->str. *shrug*
With the co
t plane);
> int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
I wonder if it would be better to make that return "const char *&quo
100%
> rename from Documentation/tpm/tpm_vtpm_proxy.rst
> rename to Documentation/security/tpm/tpm_vtpm_proxy.rst
> diff --git a/Documentation/tpm/xen-tpmfront.txt
> b/Documentation/security/tpm/xen-tpmfront.txt
> similarity index 100%
> rename from Documentation/tpm/xen-tpmfront.txt
> rename to Documentation/security/tpm/xen-tpmfront.txt
--
Jani Nikula, Intel Open Source Technology Center
entation/security/tpm/tpm_vtpm_proxy.rst
> diff --git a/Documentation/tpm/xen-tpmfront.txt
> b/Documentation/security/tpm/xen-tpmfront.txt
> similarity index 100%
> rename from Documentation/tpm/xen-tpmfront.txt
> rename to Documentation/security/tpm/xen-tpmfront.txt
--
Jani Nikula, Intel Open Source Technology Center
, we don't have all that many literal blocks that would
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
601 - 700 of 1745 matches
Mail list logo
