* Jani Nikula wrote:
> On Mon, 08 Apr 2024, Namhyung Kim wrote:
> > To pick up changes from:
> >
> >b112364867499 ("drm/i915: Add GuC submission interface version query")
> >5cf0fbf763741 ("drm/i915: Add some boring kerneldoc")
> >
> > This should be used to beautify DRM syscall argume
* Martin Sebor wrote:
> > I.e. the real workaround might be to turn off the
> > -Wstringop-overread-warning,
> > until GCC-11 gets fixed?
>
> In GCC 10 -Wstringop-overread is a subset of -Wstringop-overflow.
> GCC 11 breaks it out as a separate warning to make it easier to
> control. Both wa
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc-11 warns about using string operations on pointers that are
> defined at compile time as offsets from a NULL pointer. Unfortunately
> that also happens on the result of fix_to_virt(), which is a
> compile-time constant for a constantn input
* Jason A. Donenfeld wrote:
> Very little has changed from last time, and this whole series still
> looks good to me. I think I already ack'd most packages, but in case
> it helps:
>
> Reviewed-by: Jason A. Donenfeld
Acked-by: Ingo Molnar
> Since this touches a lo
gt;
> I did not know that these had already landed in tip tree.
>
> They are immature version.
> (In fact CONFIG_AS_CFI and AS_ADX are false-negative
> if GCC that defaults to 32-bit is used.)
>
> Can you simply discard the WIP.x86/asm branch,
> and only reapply
&g
* Masahiro Yamada wrote:
> This series of cleanups was prompted by Linus:
> https://lkml.org/lkml/2020/3/12/726
>
> First, this series drop always-on CONFIG_AS_* options.
> Some of those options were introduced in old days.
> For example, the check for CONFIG_AS_CFI dates back to 2006.
>
> We
* Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: In function 'intel_gt_resume':
> drivers/gpu/drm/i915/gt/intel_gt_pm.c:183:54: error: macro "mutex_release"
> passe
apping node
> in the tree.
>
> Finally, I've tested this on various servers, via sanity warnings, running
> side by side with the current version and so far see no differences in the
> returned pointer node when doing memtype_rb_lowest_match() lookups.
>
> Cc: Peter Zijlstr
* Thomas Gleixner wrote:
> - if (unlikely(!ret))
> + if (unlikely(!ret)) {
> + if (!trace->nr_entries) {
> + /*
> + * If save_trace fails here, the printing might
> + * trigger a WARN but because of the !nr_entries
* Thomas Hellstrom wrote:
> On 06/19/2018 11:45 AM, Peter Zijlstra wrote:
> > I suspect you want this through the DRM tree? Ingo are you OK with that?
>
>
> Yes, I can ask Dave to pull this. Ingo?
Sure, no problem if it's tested and all:
Acked-by: Ingo Molnar
desktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ingo Molnar
> Cc: H. Peter Anvin
> Cc: Thomas Gleixner
> Cc: x...@kernel.org
> Cc: # v4.13+ 0890540e21cf drm/i915: add GT number to
> intel_device_info
> Cc: # v4.13+ 41693fd52373 drm/i915/kbl: Change a KB
* Joonas Lahtinen wrote:
> + Dave as a heads-up
>
> On Thu, 2017-11-23 at 07:17 +0100, Ingo Molnar wrote:
> > * Matthew Auld wrote:
> >
> > > We duplicate the stolen discovery code in early-quirks and in i915,
> > > however if we just export the re
y: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Paulo Zanoni
> Cc: Ingo Molnar
> Cc: H. Peter Anvin
> Cc: dri-devel@lists.freedesktop.org
> Cc: x...@kernel.org
> ---
> arch/x86/kernel/early-quirks.c | 6 ++
> drivers/gpu/drm/i915/i915_ge
* Daniel Vetter wrote:
> On Tue, Oct 31, 2017 at 10:50:06AM +0100, Ingo Molnar wrote:
> >
> > * Hans de Goede wrote:
> >
> > > intel_uncore_forcewake_reset() does forcewake puts and gets as such
> > > we need to make sure that no-one tries to acces
* Hans de Goede wrote:
> intel_uncore_forcewake_reset() does forcewake puts and gets as such
> we need to make sure that no-one tries to access the PUNIT->PMIC bus
> (on systems where this bus is shared) while it runs, otherwise bad
> things happen.
>
> Normally this is taken care of by the i91
+++
> include/linux/io.h| 13 +
> 3 files changed, 32 insertions(+)
These changes look good to me in principle:
Acked-by: Ingo Molnar
I think it would be best to merge these fixes via the DRM tree?
Thanks,
Ingo
* Dave Airlie wrote:
> On 24 October 2016 at 16:03, Dave Airlie wrote:
> > I messed up one of the mailing lists last time (copied ancient
> > address from another script).
> >
>
> Oops ignore both of those sets, forgot a git add, will repost once it
> finish rebuild/boot cycle.
Could you plea
* Ingo Molnar wrote:
> as we have this in Makefile:
>
> # enforce correct pointer usage
> KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types)
Sorry, never mind - this is a recent commit that is not upstream.
So there's no upstream build re
* Patrik Jakobsson wrote:
> Hi Daniel,
>
> A patch to fix this is already merged into drm-misc:
>
> commit db9b60400f9253c25ae639797df2d0ff7a35d9d8
> Author: Sudip Mukherjee
> Date: Tue Feb 2 11:35:55 2016 +0530
>
> drm/gma500: remove helper function
>
> We were getting build warn
* Peter Zijlstra wrote:
> > - We may be making some technical compromises a.t.m for the sake of
> > using perf.
> >
> > perf_event_open() requires events to either relate to a pid or a
> > specific cpu core, while our device pmu relates to neither. Events
> > opened with a pid wi
* Archit Taneja wrote:
>
>
> On 9/17/2015 2:04 PM, Ingo Molnar wrote:
> >
> >
> >* Ingo Molnar wrote:
> >
> >
> >
> >>So this patch was whitespace damaged - I applied it by hand and made the
> >>commit
> >
> >>
* Ingo Molnar wrote:
> So this patch was whitespace damaged - I applied it by hand and made the
> commit
> below. This has solved the crash, thanks Archit!
Spoke too soon - the attached (allyesconfig-ish) config still crashes, first
there
are a handful of kobject debug warni
his results in drm_fb_helper_fini() being called twice if the
driver load drm op fails somewhere in between.
Make only mgag200_driver_unload() call drm_fb_helper_fini(), remove
the call from mgag200_fbdev_init().
Reported-by: Ingo Molnar
Signed-off-by: Archit Taneja
Cc: Archit Taneja
Cc: Danie
* Sudip Mukherjee wrote:
> On Sun, Sep 13, 2015 at 11:36:07AM +0200, Ingo Molnar wrote:
> >
> > * Sudip Mukherjee wrote:
> >
>
> >
> > There's a new regression: v4.3-rc1 crashes on bootup on non-supported
> > hardware, if
> > CONFIG
* Sudip Mukherjee wrote:
> If drm_fb_helper_alloc_fbi() fails then we were directly returning
> without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but
> mgag200_framebuffer_init() fails then we were not releasing sysram and
> we were not releasing fbi helper also.
>
> Signed-off
* Peter Zijlstra wrote:
> > As it is currently the kernel doesn't need to know anything about the
> > semantics of individual counters being selected, so it's currently
> > convenient
> > that we can aim to maintain all the counter meta data we have in userspace
> > according to the changing
* Robert Bragg wrote:
> To allow for pmus that may have internal buffering (e.g. the hardware
> itself writes out data to its own circular buffer which is only
> periodically forwarded to userspace via perf) this ioctl enables
> userspace to explicitly ensure it has received all samples before a
* David Herrmann wrote:
> Hi
>
> On Thu, Jan 23, 2014 at 6:14 PM, Ingo Molnar wrote:
> >
> > * David Herrmann wrote:
> >
> >> >> +#ifdef CONFIG_X86_SYSFB
> >> >> +# include
> >> >> +#endif
> >> >
> &
* David Herrmann wrote:
> >> +#ifdef CONFIG_X86_SYSFB
> >> +# include
> >> +#endif
> >
> > I guess a single space is sufficient?
> >
> > Better yet, I'd include sysfb.h unconditionally:
>
> Unconditionally won't work as only x86 has this header. [...]
Well, in non-x86 code an #ifdef x86 look
Just a couple of small nits:
* David Herrmann wrote:
> --- a/arch/x86/kernel/sysfb.c
> +++ b/arch/x86/kernel/sysfb.c
> @@ -33,11 +33,76 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
>
> +static DEFINE_MUTEX(sysfb_lock);
> +static st
* Maarten Lankhorst wrote:
> > I think the Nouveau guys need to comment further on this, but
> > returning -EFAULT might break existing user-space, and that's not
> > allowed, but IIRC the return value of "presumed" is only a hint, and
> > if it's incorrect will only trigger future command st
* Maarten Lankhorst wrote:
> Well they've helped me with some of the changes and contributed some
> code and/or fixes, but if acked-by is preferred I'll use that..
Such contributions can be credited in the changelog, and/or copyright
notices, and/or the code itself. The signoff chain on the o
* Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple. [...]
'TTM' here reads like a person - but in reality it's the TTM graphics
subsystem, right?
Please clarify this portion of the text.
Thanks,
Ingo
___
* Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes si
* Maarten Lankhorst wrote:
> Well they've helped me with some of the changes and contributed some
> code and/or fixes, but if acked-by is preferred I'll use that..
Such contributions can be credited in the changelog, and/or copyright
notices, and/or the code itself. The signoff chain on the o
* Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple. [...]
'TTM' here reads like a person - but in reality it's the TTM graphics
subsystem, right?
Please clarify this portion of the text.
Thanks,
Ingo
* Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes si
* Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be &
* Linus Torvalds wrote:
> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.
Yeah, it sounds really good to get rid of the (meanwhile) meaningless
"2.6." prefix from our
* Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting too big.
> I may just call the thing 2.8.0. And I almost guarantee that this PS is going
> to result in more discussion than the rest, but when the voices tell me to do
> things, I listen.
I really
* Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be &
* Linus Torvalds wrote:
> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.
Yeah, it sounds really good to get rid of the (meanwhile) meaningless
"2.6." prefix from our
* Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting too big.
> I may just call the thing 2.8.0. And I almost guarantee that this PS is going
> to result in more discussion than the rest, but when the voices tell me to do
> things, I listen.
I really
* Joerg Roedel wrote:
> On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
> >
> > * Alexandre Demers wrote:
> >
> > > On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > > > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
>
* Joerg Roedel wrote:
> On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
> >
> > * Alexandre Demers wrote:
> >
> > > On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > > > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
>
* Alexandre Demers wrote:
> On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
> >> the other patches?
> > Yes, apply it just on -rc3 without any other patch.
* Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> > we definitely want to also understand the reason for things not
> > working, even if we do revert..
>
> Okay, here it is.
>
> After experimenting with different configurations for the north-bridge
> it
* Alexandre Demers wrote:
> On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
> >> the other patches?
> > Yes, apply it just on -rc3 without any other patch.
* Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> > we definitely want to also understand the reason for things not
> > working, even if we do revert..
>
> Okay, here it is.
>
> After experimenting with different configurations for the north-bridge
> it
* Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
> > On 04/13/2011 12:14 PM, Yinghai Lu wrote:
> > >
> > > so looks bios program wrong address to the radon card?
> > >
> >
> > Okay, staring at this, it definitely seems toxic to overlay the GART
> > over
* Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 06:58:46PM -0700, H. Peter Anvin wrote:
> > On 04/13/2011 12:14 PM, Yinghai Lu wrote:
> > >
> > > so looks bios program wrong address to the radon card?
> > >
> >
> > Okay, staring at this, it definitely seems toxic to overlay the GART
> > over
* Joerg Roedel wrote:
> > > The problem does not happen with 2.6.38. I try to bisect this further
> > > down to a commit. Alex, please let me know if you need any further
> > > information.
> >
> > If you can bisect it, that would be great. Thanks,
>
> Bisecting actually gave a very weird r
* Joerg Roedel wrote:
> > > The problem does not happen with 2.6.38. I try to bisect this further
> > > down to a commit. Alex, please let me know if you need any further
> > > information.
> >
> > If you can bisect it, that would be great. Thanks,
>
> Bisecting actually gave a very weird r
t has Intel 830M, 845G,
852GM, 855GM 865G or 915G integrated graphics. If M is selected, the
But it's arguably not particularly nice looking, so maybe this area of code is
ripe
for a Kconfig restructuring/cleanup.
Signed-off-by: Ingo Molnar
---
drivers/gpu/stub/Kconfig |3 +
t has Intel 830M, 845G,
852GM, 855GM 865G or 915G integrated graphics. If M is selected, the
But it's arguably not particularly nice looking, so maybe this area of code is
ripe
for a Kconfig restructuring/cleanup.
Signed-off-by: Ingo Molnar
---
drivers/gpu/stub/Kconfig |3 +
* Justin P. Mattock wrote:
> On 07/07/2010 11:44 PM, Ingo Molnar wrote:
> >
> >* Justin P. Mattock wrote:
> >
> >>On 07/02/10 13:04, Justin P. Mattock wrote:
> >>>this is new(below) has anybody reported/bisected hit this yet
> >>>
* Justin P. Mattock wrote:
> On 07/02/10 13:04, Justin P. Mattock wrote:
> >this is new(below) has anybody reported/bisected hit this yet
> >(if not I'll bisect it)
> >
> >[drm] Num pipes: 1
> >[ 29.742432] [drm] writeback test succeeded in 1 usecs
> >[ 30.089717] X:2252 conflicting memory t
* Justin P. Mattock wrote:
> On 07/07/2010 11:44 PM, Ingo Molnar wrote:
> >
> >* Justin P. Mattock wrote:
> >
> >>On 07/02/10 13:04, Justin P. Mattock wrote:
> >>>this is new(below) has anybody reported/bisected hit this yet
> >>>
* Justin P. Mattock wrote:
> On 07/02/10 13:04, Justin P. Mattock wrote:
> >this is new(below) has anybody reported/bisected hit this yet
> >(if not I'll bisect it)
> >
> >[drm] Num pipes: 1
> >[ 29.742432] [drm] writeback test succeeded in 1 usecs
> >[ 30.089717] X:2252 conflicting memory t
59 matches
Mail list logo
