detect(struct
> drm_i915_private *dev_priv,
> dev_priv->hotplug.stats[pin].last_jiffies = jiffies;
> dev_priv->hotplug.stats[pin].count = 0;
> DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n",
> pin);
> - } else if (dev_priv->hotplug.stats[pin].count > HPD_STORM_THRESHOLD) {
> + } else if (dev_priv->hotplug.stats[pin].count > HPD_STORM_THRESHOLD &&
> +dev_priv->hotplug.hpd_storm_detect_enabled) {
How about making the threshold configurable, with 0 being off?
BR,
Jani.
PS. I do wonder if anyone besides Egbert has really seen this much in
the wild...
> dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED;
> DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin);
> storm = true;
--
Jani Nikula, Intel Open Source Technology Center
false;
> for (i = 0; i < JUMP_NB && keys[i]; i++)
> if (dres == keys[i]) {
--
Jani Nikula, Intel Open Source Technology Center
ould be even better and discoverable if this could be turned into a
dialog menu, so that you could navigate the search results using arrow
keys and hit enter to choose. But this is already an improvement.
> again = false;
> for (i = 0; i < JUMP_NB &&
e macro for MIPI DSI. But since I'm
> apparently the only one that doesn't like this, maybe it's time for me
> to embrace this.
I think that's less interesting for MIPI DSI now that we have specific
functions for most standard DCS commands anyway. That also avoids the
need to have a list of read
y one that doesn't like this, maybe it's time for me
> to embrace this.
I think that's less interesting for MIPI DSI now that we have specific
functions for most standard DCS commands anyway. That also avoids the
need to have a list of read functions like here.
I guess the question is if it feels like too much duplication to have
the DCS commands as functions also for DBI. And whether it's worth
trying to deduplicate DSI and DBI in this case, or if it gets just too
confusing/complicated.
BR,
Jani.
>
> Thierry
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
t;mipi_dbi" or "dbi"? We never talk about "vesa" displays or use that as
a shorthand when we refer to Display Port either.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
"? We never talk about "vesa" displays or use that as
a shorthand when we refer to Display Port either.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
; + .mmap = drm_gem_cma_mmap,
> +};
> +EXPORT_SYMBOL(tinydrm_fops);
--
Jani Nikula, Intel Open Source Technology Center
gem_cma_mmap,
> +};
> +EXPORT_SYMBOL(tinydrm_fops);
--
Jani Nikula, Intel Open Source Technology Center
depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
in your Kconfig.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
ICE || BACKLIGHT_CLASS_DEVICE=n
in your Kconfig.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 02 Feb 2017, Shuah Khan <shua...@osg.samsung.com> wrote:
> On 02/02/2017 01:32 AM, Jani Nikula wrote:
>> On Thu, 02 Feb 2017, Shuah Khan <shua...@osg.samsung.com> wrote:
>>> Change drm_helper_probe_single_connector_modes() to print an error to
>>&g
On Thu, 02 Feb 2017, Shuah Khan wrote:
> On 02/02/2017 01:32 AM, Jani Nikula wrote:
>> On Thu, 02 Feb 2017, Shuah Khan wrote:
>>> Change drm_helper_probe_single_connector_modes() to print an error to
>>> report connector disconnected status instead of a debug message.
,
obviously, be made calmly, independent of any particular patch series.)
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
any particular patch series.)
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
connector->base.id, connector->name);
> drm_mode_connector_update_edid_property(connector, NULL);
> verbose_prune = false;
> goto prune;
--
Jani Nikula, Intel Open Source Technology Center
mode_connector_update_edid_property(connector, NULL);
> verbose_prune = false;
> goto prune;
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 31 Jan 2017, Brian Starkey <brian.star...@arm.com> wrote:
> Hi Jani,
>
> On Tue, Jan 31, 2017 at 01:30:41PM +0200, Jani Nikula wrote:
>>On Tue, 31 Jan 2017, Brian Starkey <brian.star...@arm.com> wrote:
>>> Explicitly state the expected CTM eq
On Tue, 31 Jan 2017, Brian Starkey wrote:
> Hi Jani,
>
> On Tue, Jan 31, 2017 at 01:30:41PM +0200, Jani Nikula wrote:
>>On Tue, 31 Jan 2017, Brian Starkey wrote:
>>> Explicitly state the expected CTM equations in the kerneldoc for the CTM
>>> property, and
ersion matrix in S31.32 format, in row-major form:
> + *
> + * | matrix[0] matrix[1] matrix[2] |
> + * | matrix[3] matrix[4] matrix[5] |
> + * | matrix[6] matrix[7] matrix[8] |
> + */
Same here.
> __s64 matrix[9];
> };
--
Jani Nikula, Intel Open Source Technology Center
rtc_lut {
> };
>
> struct drm_color_ctm {
> - /* Conversion matrix in S31.32 format. */
> + /*
> + * Conversion matrix in S31.32 format, in row-major form:
> + *
> + * | matrix[0] matrix[1] matrix[2] |
> + * | matrix[3] matrix[4] matrix[5] |
> + * | matrix[6] matrix[7] matrix[8] |
> + */
Same here.
> __s64 matrix[9];
> };
--
Jani Nikula, Intel Open Source Technology Center
On Mon, 30 Jan 2017, Jani Nikula <jani.nik...@intel.com> wrote:
> Make targets that don't depend on Sphinx work without warnings about
> missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and
> the targets that are no-ops for Sphinx should just be skipped. Move
On Mon, 30 Jan 2017, Jani Nikula wrote:
> Make targets that don't depend on Sphinx work without warnings about
> missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and
> the targets that are no-ops for Sphinx should just be skipped. Move them
> outside of the HAVE_S
om
the real edid. This kind of hacks will bypass the override/firmware edid
mechanisms then too. :(
BR,
Jani.
>
> [...]
>
> I fixed all your other suggestions. Thank you!
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
will bypass the override/firmware edid
mechanisms then too. :(
BR,
Jani.
>
> [...]
>
> I fixed all your other suggestions. Thank you!
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
for HAVE_SPHINX=0.
Reported-by: Jim Davis <jim.ep...@gmail.com>
Reference:
http://lkml.kernel.org/r/ca+r1zhjrvqkjpxgogb_boax2hkfb+qqcttzffbmfeh1mfee...@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
Documentation/Makefile.sphinx | 7 +--
1 file changed, 5 inse
for HAVE_SPHINX=0.
Reported-by: Jim Davis
Reference:
http://lkml.kernel.org/r/ca+r1zhjrvqkjpxgogb_boax2hkfb+qqcttzffbmfeh1mfee...@mail.gmail.com
Signed-off-by: Jani Nikula
---
Documentation/Makefile.sphinx | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation
l->backlight.level < panel->backlight.min) {
> panel->backlight.level = panel->backlight.max;
If we changed this to follow your logic, the sensible thing to do would
be to set the backlight to min, not max, in this case.
But the point is moot. I don't want to deal with the regressions that I
predict the change will inevitably cause.
BR,
Jani.
> if (panel->backlight.device)
> panel->backlight.device->props.brightness =
--
Jani Nikula, Intel Open Source Technology Center
panel->backlight.level = panel->backlight.max;
If we changed this to follow your logic, the sensible thing to do would
be to set the backlight to min, not max, in this case.
But the point is moot. I don't want to deal with the regressions that I
predict the change will inevitably cause.
BR,
Jani.
> if (panel->backlight.device)
> panel->backlight.device->props.brightness =
--
Jani Nikula, Intel Open Source Technology Center
to
have. Switching to a homebrew Python parser first does not preclude a
unicorn hunt later.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
o a homebrew Python parser first does not preclude a
unicorn hunt later.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 26 Jan 2017, Borislav Petkov <b...@alien8.de> wrote:
> On Thu, Jan 26, 2017 at 03:51:25PM +0200, Jani Nikula wrote:
>> On Thu, 26 Jan 2017, Borislav Petkov <b...@alien8.de> wrote:
>> > Hi all,
>> >
>> > I see this brand new warning when boo
On Thu, 26 Jan 2017, Borislav Petkov wrote:
> On Thu, Jan 26, 2017 at 03:51:25PM +0200, Jani Nikula wrote:
>> On Thu, 26 Jan 2017, Borislav Petkov wrote:
>> > Hi all,
>> >
>> > I see this brand new warning when booting here.
>> >
>> > Top co
ulti-head: yes rom: no post: no)
> [2.304017] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
> [2.304287] [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on
> minor 0
--
Jani Nikula, Intel Open Source Technology Center
es rom: no post: no)
> [2.304017] input: Video Bus as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
> [2.304287] [drm] Initialized i915 1.6.0 20161121 for :00:02.0 on
> minor 0
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 26 Jan 2017, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Am 25.01.2017 um 21:59 schrieb Jani Nikula <jani.nik...@intel.com>:
>
>>> But the problem I see here is, that the perl script generates a
>>> reST output which I can't use. As an example we
On Thu, 26 Jan 2017, Markus Heiser wrote:
> Am 25.01.2017 um 21:59 schrieb Jani Nikula :
>
>>> But the problem I see here is, that the perl script generates a
>>> reST output which I can't use. As an example we can take a look at
>>> the man-page builder I shipp
On Wed, 25 Jan 2017, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Am 25.01.2017 um 11:24 schrieb Jani Nikula <jani.nik...@intel.com>:
>
>> Markus, thanks for your work on this.
>
> Thanks for your comments!
>
>> Excuse me for my bluntness, but
On Wed, 25 Jan 2017, Markus Heiser wrote:
> Am 25.01.2017 um 11:24 schrieb Jani Nikula :
>
>> Markus, thanks for your work on this.
>
> Thanks for your comments!
>
>> Excuse me for my bluntness, but I think changing everything in a single
>> commit, o
(Now without the typo in Daniel's address; apologies for the extra
noise.)
On Wed, 25 Jan 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Wed, 25 Jan 2017, Ingo Molnar <mi...@kernel.org> wrote:
>> * Paulo Zanoni <paulo.r.zan...@intel.com> wrote:
>>
&
(Now without the typo in Daniel's address; apologies for the extra
noise.)
On Wed, 25 Jan 2017, Jani Nikula wrote:
> On Wed, 25 Jan 2017, Ingo Molnar wrote:
>> * Paulo Zanoni wrote:
>>
>>> So don't forget to reserve its stolen memory bits.
>>>
>>&g
drm-intel along with the
deps?
BR,
Jani.
>
> Thanks,
>
> Ingo
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
ndency here on other
> changes to the i915 GPU driver?
It's in our -next. Ack for merging this through drm-intel along with the
deps?
BR,
Jani.
>
> Thanks,
>
> Ingo
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
ll, incremental changes. Just like we do everything in the
kernel.
BR,
Jani.
(*) Please do not get hung up on these numbers. The Python version does
more in some ways, but adds more deps such as fspath that's not
included in the figures, and the Perl version outputs more
formats. It's not an apples to apples comparison. Let's just say
they are somewhere in the same ballpark.
--
Jani Nikula, Intel Open Source Technology Center
he
kernel.
BR,
Jani.
(*) Please do not get hung up on these numbers. The Python version does
more in some ways, but adds more deps such as fspath that's not
included in the figures, and the Perl version outputs more
formats. It's not an apples to apples comparison. Let's just say
they are somewhere in the same ballpark.
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 25 Jan 2017, Markus Heiser <markus.hei...@darmarit.de> wrote:
> Am 25.01.2017 um 09:21 schrieb Jani Nikula <jani.nik...@intel.com>:
>> Yes, see below. It's simplistic and it has an external dependency, but
>> it got the job done. And it does not depend on Sphinx
On Wed, 25 Jan 2017, Markus Heiser wrote:
> Am 25.01.2017 um 09:21 schrieb Jani Nikula :
>> Yes, see below. It's simplistic and it has an external dependency, but
>> it got the job done. And it does not depend on Sphinx; it's just a
>> kernel-doc and rst lint, not Sphinx
Sphinx; it's just a
kernel-doc and rst lint, not Sphinx lint. Whether that's a good or a bad
thing is debatable.
Anyway, I do think the approach of making 'make CHECK=the-tool C=1' work
is what we should aim at. Markus' patch could probably be made to do
that by accepting the same arguments that a
int. Whether that's a good or a bad
thing is debatable.
Anyway, I do think the approach of making 'make CHECK=the-tool C=1' work
is what we should aim at. Markus' patch could probably be made to do
that by accepting the same arguments that are passed to compilers.
BR,
Jani.
>From 96
)) {
> pipe->plane.fb = fb;
> if (fb->funcs->dirty)
> fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> }
> }
>
> void tinydrm_send_pending_event(struct tinydrm_device *tdev)
> {
> struct drm_crtc *crtc = >pipe.crtc;
>
> if (!crtc->state->event)
> return;
>
> spin_lock_irq(>dev->event_lock);
> drm_crtc_send_vblank_event(crtc, crtc->state->event);
> spin_unlock_irq(>dev->event_lock);
> crtc->state->event = NULL;
> }
>
> static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_file *file_priv,
> unsigned int flags, unsigned int color,
> struct drm_clip_rect *clips,
> unsigned int num_clips)
> {
>
> mutex_lock(>dirty_lock);
>
>
>
> tinydrm_send_pending_event(tdev);
>
> mutex_unlock(>dirty_lock);
>
> return ret;
> }
>
>
> Noralf.
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
if (fb->funcs->dirty)
> fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
> }
> }
>
> void tinydrm_send_pending_event(struct tinydrm_device *tdev)
> {
> struct drm_crtc *crtc = >pipe.crtc;
>
> if (!crtc->state->event)
> return;
>
> spin_lock_irq(>dev->event_lock);
> drm_crtc_send_vblank_event(crtc, crtc->state->event);
> spin_unlock_irq(>dev->event_lock);
> crtc->state->event = NULL;
> }
>
> static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_file *file_priv,
> unsigned int flags, unsigned int color,
> struct drm_clip_rect *clips,
> unsigned int num_clips)
> {
>
> mutex_lock(>dirty_lock);
>
>
>
> tinydrm_send_pending_event(tdev);
>
> mutex_unlock(>dirty_lock);
>
> return ret;
> }
>
>
> Noralf.
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 18 Jan 2017, Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Wed, 18 Jan 2017, Sreedhar Donelli <sreedhar.done...@tcs.com> wrote:
>> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
>> please find the attachment for patch file.
&
On Wed, 18 Jan 2017, Jani Nikula wrote:
> On Wed, 18 Jan 2017, Sreedhar Donelli wrote:
>> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
>> please find the attachment for patch file.
>
> There are several issues with this contribution. Please le
gt; @@ -54,6 +54,7 @@
> #define GEN6_PTE_UNCACHED (1 << 1)
> #define GEN6_PTE_VALID (1 << 0)
>
> +#define I915_NULL_PTE 0
> #define I915_PTES(pte_len) (PAGE_SIZE / (pte_len))
> #define I915_PTE_MASK(pte_len) (I915_PTES(pte_len) - 1)
> #define I915_PDES512
--
Jani Nikula, Intel Open Source Technology Center
#define GEN6_PTE_UNCACHED (1 << 1)
> #define GEN6_PTE_VALID (1 << 0)
>
> +#define I915_NULL_PTE 0
> #define I915_PTES(pte_len) (PAGE_SIZE / (pte_len))
> #define I915_PTE_MASK(pte_len) (I915_PTES(pte_len) - 1)
> #define I915_PDES512
--
Jani Nikula, Intel Open Source Technology Center
On Wed, 11 Jan 2017, Joe Perches <j...@perches.com> wrote:
> On Wed, 2017-01-11 at 10:54 +0200, Jani Nikula wrote:
>> On Wed, 11 Jan 2017, Joe Perches <j...@perches.com> wrote:
>> > Make these files symlinks to the .rst equivalents
>>
>> If we're going
On Wed, 11 Jan 2017, Joe Perches wrote:
> On Wed, 2017-01-11 at 10:54 +0200, Jani Nikula wrote:
>> On Wed, 11 Jan 2017, Joe Perches wrote:
>> > Make these files symlinks to the .rst equivalents
>>
>> If we're going to do this (and I really don't mind either way), t
bmitting-patches.rst
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> new file mode 12
> index ..5ca6e8ba3682
> --- /dev/null
> +++ b/Documentation/SubmittingPatches
> @@ -0,0 +1 @@
> +./process/submitting-patches.rst
> \ No newline at end of file
--
Jani Nikula, Intel Open Source Technology Center
ation/SubmittingPatches b/Documentation/SubmittingPatches
> new file mode 12
> index ..5ca6e8ba3682
> --- /dev/null
> +++ b/Documentation/SubmittingPatches
> @@ -0,0 +1 @@
> +./process/submitting-patches.rst
> \ No newline at end of file
--
Jani Nikula, Intel Open Source Technology Center
ork to do...
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
deps to
even see their config.
I wish kconfig would warn about incorrect use of select... though I
guess that would produce a wall of warnings. Additionally, it really
should be easier to find and enable unmet dependencies in
menuconfig. Someone(tm) has a lot of work to do...
BR,
Jani.
--
Jani Ni
: symbol NEW_LEDS is selected by ATH9K_HTC
> drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on
> USB
>
> Caused by commit
>
> a5ad0fd8524e ("drm: nouveau: fix build when LEDS_CLASS=m")
>
> I have reverted that commit for today (just
is selected by ATH9K_HTC
> drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on
> USB
>
> Caused by commit
>
> a5ad0fd8524e ("drm: nouveau: fix build when LEDS_CLASS=m")
>
> I have reverted that commit for today (just because I had to to make
> s
->limited_color_range = false;
> } else {
> pipe_config->limited_color_range =
> intel_dp->limited_color_range;
--
Jani Nikula, Intel Open Source Technology Center
;* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
>*/
> - pipe_config->limited_color_range =
> - bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> + pipe_config->limited_color_range = fals
-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
>> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
>> @@ -1,6 +1,7 @@
>> config DRM_NOUVEAU
>> tristate "Nouveau (NVIDIA) cards"
>> depends on DRM && PCI
>> +depends on LE
el
>
>> ---
>> drivers/gpu/drm/nouveau/Kconfig |1 +
>> 1 file changed, 1 insertion(+)
>>
>> --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
>> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
>> @@ -1,6 +1,7 @@
>> config DRM_NOUVEAU
>
On Wed, 04 Jan 2017, Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 03/01/2017 10:57, Jani Nikula wrote:
>> On Mon, 02 Jan 2017, Paolo Bonzini <pbonz...@redhat.com> wrote:
>>> Hi,
>>>
>>> these patches are the result of my experiments with using ker
On Wed, 04 Jan 2017, Paolo Bonzini wrote:
> On 03/01/2017 10:57, Jani Nikula wrote:
>> On Mon, 02 Jan 2017, Paolo Bonzini wrote:
>>> Hi,
>>>
>>> these patches are the result of my experiments with using kernel-doc
>>> for QEMU's documen
On Wed, 04 Jan 2017, Sebastian Andrzej Siewior <bige...@linutronix.de> wrote:
> On 2016-12-23 10:03:09 [+0200], Jani Nikula wrote:
>> > --- /dev/null
>> > +++ b/Documentation/core-api/cpu_hotplug.rst
>> > @@ -0,0 +1,372 @@
>> > +
On Wed, 04 Jan 2017, Sebastian Andrzej Siewior wrote:
> On 2016-12-23 10:03:09 [+0200], Jani Nikula wrote:
>> > --- /dev/null
>> > +++ b/Documentation/core-api/cpu_hotplug.rst
>> > @@ -0,0 +1,372 @@
>> > +==
ested.
>
> Sorry that this is such a bikeshed heaven ;-)
If there's going to be another version, please fix the commit message
while at it. "Now sent with git send-email" is useless for posterity.
BR,
Jani.
> -Daniel
>
>> +
>> /* 8 bpp RGB */
>> #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
>> 3:3:2 */
>> #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
>> 2:3:3 */
>> --
>> 2.9.3
>>
--
Jani Nikula, Intel Open Source Technology Center
be another version, please fix the commit message
while at it. "Now sent with git send-email" is useless for posterity.
BR,
Jani.
> -Daniel
>
>> +
>> /* 8 bpp RGB */
>> #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
>> 3:3:2 */
>> #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
>> 2:3:3 */
>> --
>> 2.9.3
>>
--
Jani Nikula, Intel Open Source Technology Center
is managing i915 fixes pull.
Send what to me? I've pushed fixes to drm-intel-fixes today for testing,
and expect to send a pull request to Dave early Thursday. If there's a
conflict, it can usually be solved while merging, like Stephen has done.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
to me? I've pushed fixes to drm-intel-fixes today for testing,
and expect to send a pull request to Dave early Thursday. If there's a
conflict, it can usually be solved while merging, like Stephen has done.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
instead,
> are making the docbook backend (and the others too) more consistent with
> the input and output of the rST backend.
I did not test the patches, and for sure I will not attempt reviewing
perl, but at a high level the changes seem sensible.
Acked-by: Jani Nikula <jani.nik...@in
he docbook backend (and the others too) more consistent with
> the input and output of the rST backend.
I did not test the patches, and for sure I will not attempt reviewing
perl, but at a high level the changes seem sensible.
Acked-by: Jani Nikula
> I am not sure what is the state of the ker
et = vfio_unregister_notifier(>vdev.mdev->dev, VFIO_GROUP_NOTIFY,
> ++ret = vfio_unregister_notifier(mdev_dev(vgpu->vdev.mdev),
> VFIO_GROUP_NOTIFY,
> >vdev.group_notifier);
> + WARN(ret, "vfio_unregister_notifier for group failed: %d\n", ret);
>
> info = (struct kvmgt_guest_info *)vgpu->handle;
> kvmgt_guest_exit(info);
>
--
Jani Nikula, Intel Open Source Technology Center
vdev.mdev->dev, VFIO_GROUP_NOTIFY,
> ++ret = vfio_unregister_notifier(mdev_dev(vgpu->vdev.mdev),
> VFIO_GROUP_NOTIFY,
> >vdev.group_notifier);
> + WARN(ret, "vfio_unregister_notifier for group failed: %d\n", ret);
>
> info = (struct kvmgt_guest_info *)vgpu->handle;
> kvmgt_guest_exit(info);
>
--
Jani Nikula, Intel Open Source Technology Center
On Thu, 29 Dec 2016, Sedat Dilek <sedat.di...@gmail.com> wrote:
> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki <raf...@kernel.org> wrote:
>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek <sedat.di...@gmail.com> wrote:
>>> On Wed, Dec 28, 2016 at 9:29 AM
On Thu, 29 Dec 2016, Sedat Dilek wrote:
> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki wrote:
>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek wrote:
>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula wrote:
>>>> On Wed, 28 Dec 2016, Sedat Dilek wrote:
>&
is reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner <t...@linutronix.de>
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/C
top.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e9939387
CPU.
> - Actually look at some example code in other arch
> - that implement CPU hotplug. The processor is taken
> - down from the idle() loop for that specific
> - architecture. __cpu_die() typically waits for some
> - per_cpu state to be set, to ensure the processor
> - dead routine is called to be sure positively.
> -
> -Q: I need to ensure that a particular CPU is not removed when there is some
> - work specific to this CPU in progress.
> -A: There are two ways. If your code can be run in interrupt context, use
> - smp_call_function_single(), otherwise use work_on_cpu(). Note that
> - work_on_cpu() is slow, and can fail due to out of memory:
> -
> - int my_func_on_cpu(int cpu)
> - {
> - int err;
> - get_online_cpus();
> - if (!cpu_online(cpu))
> - err = -EINVAL;
> - else
> -#if NEEDS_BLOCKING
> - err = work_on_cpu(cpu, __my_func_on_cpu, NULL);
> -#else
> - smp_call_function_single(cpu, __my_func_on_cpu, ,
> - true);
> -#endif
> - put_online_cpus();
> - return err;
> - }
> -
> -Q: How do we determine how many CPUs are available for hotplug.
> -A: There is no clear spec defined way from ACPI that can give us that
> - information today. Based on some input from Natalie of Unisys,
> - that the ACPI MADT (Multiple APIC Description Tables) marks those possible
> - CPUs in a system with disabled status.
> -
> - Andi implemented some simple heuristics that count the number of disabled
> - CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
> - we assume 1/2 the number of CPUs currently present can be hotplugged.
> -
> - Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI
> 2.0c
> - or earlier ACPI version supported, because the apicid field in MADT is
> only
> - 8 bits. From ACPI 3.0, this limitation was removed since the apicid field
> - was extended to 32 bits with x2APIC introduced.
> -
> -User Space Notification
> -
> -Hotplug support for devices is common in Linux today. Its being used today to
> -support automatic configuration of network, usb and pci devices. A hotplug
> -event can be used to invoke an agent script to perform the configuration
> task.
> -
> -You can add /etc/hotplug/cpu.agent to handle hotplug notification user space
> -scripts.
> -
> - #!/bin/bash
> - # $Id: cpu.agent
> - # Kernel hotplug params include:
> - #ACTION=%s [online or offline]
> - #DEVPATH=%s
> - #
> - cd /etc/hotplug
> - . ./hotplug.functions
> -
> - case $ACTION in
> - online)
> - echo `date` ":cpu.agent" add cpu >> /tmp/hotplug.txt
> - ;;
> - offline)
> - echo `date` ":cpu.agent" remove cpu >>/tmp/hotplug.txt
> - ;;
> - *)
> - debug_mesg CPU $ACTION event not supported
> -exit 1
> -;;
> - esac
--
Jani Nikula, Intel Open Source Technology Center
that implement CPU hotplug. The processor is taken
> - down from the idle() loop for that specific
> - architecture. __cpu_die() typically waits for some
> - per_cpu state to be set, to ensure the proces
FIELD(0x, 0));
> - if (request->ctx != port[0].request->ctx) {
> + if (!execlists_elsp_idle(engine) && request->ctx !=
> port[0].request->ctx) {
> i915_gem_request_put(port[0].request);
> port[0] = port[1];
> memset([1], 0, sizeof(port[1]));
--
Jani Nikula, Intel Open Source Technology Center
if (!execlists_elsp_idle(engine) && request->ctx !=
> port[0].request->ctx) {
> i915_gem_request_put(port[0].request);
> port[0] = port[1];
> memset([1], 0, sizeof(port[1]));
--
Jani Nikula, Intel Open Source Technology Center
}
>>
>> +if (dev->mode_config.delayed_event) {
>> + poll = true;
>> +delay = 0;
>> +}
>> +
>> if (poll)
>> -schedule_delayed_work(>mode_config.output_poll_work,
>> DRM_OUTPUT_POLL_PERIOD);
>> +schedule_delayed_work(>mode_config.output_poll_work,
>> delay);
>> }
>> EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>>
>> --
>> 2.9.3
>>
--
Jani Nikula, Intel Open Source Technology Center
>mode_config.delayed_event) {
>> +poll = true;
>> +delay = 0;
>> +}
>> +
>> if (poll)
>> -schedule_delayed_work(>mode_config.output_poll_work,
>> DRM_OUTPUT_POLL_PERIOD);
>> +schedule_delayed_work(>mode_config.output_poll_work,
>> delay);
>> }
>> EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>>
>> --
>> 2.9.3
>>
--
Jani Nikula, Intel Open Source Technology Center
On Fri, 16 Dec 2016, Nicholas Mc Guire <hof...@osadl.org> wrote:
> udelay_range(1, 2) is inefficient and as discussions with Jani Nikula
> <jani.nik...@linux.intel.com> unnecessary here. This replaces this
> tight setting with a relaxed delay of min=20 and max=50 whic
On Fri, 16 Dec 2016, Nicholas Mc Guire wrote:
> udelay_range(1, 2) is inefficient and as discussions with Jani Nikula
> unnecessary here. This replaces this
> tight setting with a relaxed delay of min=20 and max=50 which helps
> the hrtimer subsystem optimize timer handling.
>
On Thu, 15 Dec 2016, Nicholas Mc Guire <der.h...@hofr.at> wrote:
> On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wr
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Ville Syrjälä wrote:
>> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> >> On Thu, 15 Dec 2016, Nicholas Mc Guire
On Thu, 15 Dec 2016, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire <der.h...@hofr.at> wrote:
>> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wr
On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> >> On Thu, 15 Dec 2016, Nicholas Mc Guir
On Thu, 15 Dec 2016, Nicholas Mc Guire <der.h...@hofr.at> wrote:
> On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire <hof...@osadl.org> wrote:
>> > Even on fast systems a 2 microsecond delay is most likely more effi
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > Even on fast systems a 2 microsecond delay is most likely more efficient
>> > as a busy-wait loop. The
On Thu, 15 Dec 2016, Nicholas Mc Guire <der.h...@hofr.at> wrote:
> On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula 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
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 10:47:57AM +0200, 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 uselee
val &= ~ULPS_STATE_MASK;
> 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
501 - 600 of 1745 matches
Mail list logo
