Hello David Francis,
This is a semi-automatic email about new static checker warnings.
The patch 8a48b44cd00f: "drm/amd/display: Call into DC once per
multiplane flip" from Dec 11, 2018, leads to the following Smatch
complaint:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:48
On Mon, Feb 18, 2019 at 01:47:57PM -0300, Helen Koike wrote:
> Hello,
>
> After some discussions I had with some people I would like to discuss
> some design choices regarding uAPI to expose async updates.
>
> The plan is to allow userspace to update the cursor plane through the
> atomic API inst
https://bugs.freedesktop.org/show_bug.cgi?id=108262
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Lakshmi ---
Repor
https://bugs.freedesktop.org/show_bug.cgi?id=108073
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Lakshmi ---
Last
I have my mail and real name in git configuration but it has taken my
computer's username. I suppose there should be a way to make git to take
the real name I have set in it's configuration. Will check it and resend as
I won't do ammend cause I have signed of by all public commits as in these
patch
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> Add support for aborting/bailing out of test cases. Needed for
> implementing assertions.
>
> Signed-off-by: Brendan Higgins
> ---
> Changes Since Last Version
> - This patch is new introducing a new cross-architecture way to abort
>out of a test
On 2/15/19 2:56 AM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand wrote:
>>
>> On 2/14/19 4:56 PM, Brendan Higgins wrote:
>>> On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand wrote:
On 12/5/18 3:54 PM, Brendan Higgins wrote:
> On Tue, Dec 4, 2018 at 2:58 AM Frank
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function
'ttm_eu_fence_buffer_objects':
drivers/gpu/drm/ttm/ttm_execbuf_util.c:191:24: warning:
variable 'bdev' set but not used [-Wunused-but-set-variable]
It's not used any more and can be removed.
Sign
added the temperature alert irq handler in adv driver , in the irq
calling schedule_work(&adv7511->hpd_work); , initially in the
adv7511_detect , if we set status = connector_status_disconnected; later
when irq handler calls the schedule work, hpd does not works.
[ 55.052677] [drm] Cannot find an
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a VM
>
Don't skip the framebuffer CLUT pointer register initialization when
the first dafb_setpalette() invocation has regno equal to zero.
Cc: linux-m...@lists.linux-m68k.org
Suggested-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
drivers/video/fbdev/macfb.c | 2 +-
1 file changed, 1 insertion
On 2/18/19 8:36 AM, Daniel Vetter wrote:
> Polish the kerneldoc a bit with suggestions from Randy.
>
> v2: Randy found another typo: s/compent/component/
>
> Cc: Randy Dunlap
> Signed-off-by: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: Daniel Vetter
> Cc: Ramalinga
The (void *) casting in the driver_data variable assignment is superfluous.
Spotted by Jani Nikula.
Signed-off-by: David Santamaría Rogado
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm
OK, I think I did it right, rebase two commits and ammeded both and
now resend. This one has been attached to this thread but number 2 has
been in a new thread.
El mar., 19 feb. 2019 a las 0:35, David Santamaría Rogado
() escribió:
>
> The (void *) casting in the driver_data variable assignment is
Lenovo Ideapad D330 Pentium CPU version has 1920x1200 LCD. Console
ouput gets rotated at boot as Miix 310.
Signed-off-by: David Santamaría Rogado
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orient
On 2/18/19 12:52 AM, Daniel Vetter wrote:
> Polish the kerneldoc a bit with suggestions from Randy.
>
Hi Daniel,
There are 2 more typos below. With those fixed, you or Greg can add:
Acked-by: Randy Dunlap
Thanks.
> Cc: Randy Dunlap
> Signed-off-by: Daniel Vetter
> Cc: Greg Kroah-Hartman
>
On 2/12/19 5:44 PM, Brendan Higgins wrote:
> On Wed, Nov 28, 2018 at 12:56 PM Rob Herring wrote:
>>
>> On Wed, Nov 28, 2018 at 1:38 PM Brendan Higgins
>> wrote:
>>>
>>> Migrate tests without any cleanup, or modifying test logic in anyway to
>>> run under KUnit using the KUnit expectation and asse
https://bugs.freedesktop.org/show_bug.cgi?id=108579
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail becaus
On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 18, 2019 at 10:26 AM Rob Herring wrote:
> >
> > On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > > Validate the cloc
This patch add mt8183 mipi_tx driver.
And also support other chips that use the same binding and driver.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 2 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168
MT8183 has different setting to MT8173(exist chip). We add mt8183 mipi_tx
driver.
1) Separate mipi_tx to common part and chip relate part.
2) Add mt8183 mipi_tx driver
Changes since v0:
- Separate two independent patches.
Jitao Shi (2):
drm/mediatek: separate mipi_tx to different file
drm/me
Different IC has different mipi_tx setting of dsi.
This patch separates the mipi_tx hardware relate part for mt8173.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 350 ++
drivers/gpu/drm/mediate
On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> wrote:
> >
> > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom
> > wrote:
> > >
> > > On Friday, 2019-02-15 13:36:39 +, Eric Engestrom wrote:
> > > > On Friday, 20
Hi Lionel,
the attached should fix your problem and also messed signal order.
Hi Christian,
Could you have a look if it's reasonable?
btw: I pushed to change to
https://github.com/amingriyue/timeline-syncobj-kernel, which is already
rebased to latest drm-misc(kernel 5.0). You can directly u
Hi Robin,
On Wed, Feb 13, 2019 at 04:40:11PM +, Robin Murphy wrote:
> On 13/02/2019 15:41, Maxime Ripard wrote:
> > Hi Robin,
> >
> > Thanks for your feedback!
> >
> > On Tue, Feb 12, 2019 at 06:46:40PM +, Robin Murphy wrote:
> > > On 11/02/2019 15:02, Maxime Ripard wrote:
> > > > Now th
On Tue, Feb 12, 2019 at 05:46:15PM +0100, Daniel Vetter wrote:
> Now that component has docs it's worth spending a few words and
> hyperlinks on recommended best practices in drm.
>
> v2: Add another item that component shouldn't be preferred over
> drm_bridge/panel and similar subsystems already
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #13 from Zdenek ---
I get hard lock during LibreOffice start after this workaround. Nothing
interesting in logs can be found.
--
You are receiving this mail because:
You are the assignee for the bug.
Thanks David,
Will give this a go!
-Lionel
On 19/02/2019 10:46, zhoucm1 wrote:
Hi Lionel,
the attached should fix your problem and also messed signal order.
Hi Christian,
Could you have a look if it's reasonable?
btw: I pushed to change to
https://github.com/amingriyue/timeline-syncobj-
Hi David,
Could you have a look if it's reasonable?
Patch #1 is also something I already fixed on my local branch.
But patch #2 won't work like this.
We can't return an error from drm_syncobj_add_point() because we already
submitted work to the hardware. And just dropping the fence like you do
On Mon, 18 Feb 2019 at 17:10, Eric Engestrom wrote:
>
> On Wednesday, 2018-12-19 17:08:01 +, Eric Engestrom wrote:
> > Adapted from a local patch carried by DragonFlyBSD:
> > https://github.com/DragonFlyBSD/DPorts/blob/bc056f88f7e4d468d8c9751f831a47b5ae1326e3/graphics/libdrm/files/patch-xf86dr
On Mon, 18 Feb 2019 at 17:42, Eric Engestrom wrote:
>
> On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > Signed-off-by: Eric Engestrom
> > > ---
> > > RELEASING | 27 ---
> > > 1 file changed, 8 insertions(+
On Tue, 19 Feb 2019 at 10:08, Eric Engestrom wrote:
>
> On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> > wrote:
> > >
> > > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom
> > > wrote:
> > > >
> > > > On Friday,
From: Colin Ian King
Currently when the call to of_get_drm_display_mode fails the error return
path does not free an earlier allocated struct drm_display_mode, causing
a memory leak. Fix this by kfree'ing mode before returning.
Fixes: 76ecd9c9fb24 ("drm/imx: parallel-display: check return code f
On Tue, Feb 19, 2019 at 08:55:27AM +0100, Daniel Vetter wrote:
> Hi all,
>
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
> P
https://bugs.freedesktop.org/show_bug.cgi?id=109650
--- Comment #1 from tempel.jul...@gmail.com ---
I can confirm this with RX 580, /sys/kernel/debug/dri/0/amdgpu_pm_info also
shows a constant GPU usage of 100%.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov wrote:
>
> On Mon, 18 Feb 2019 at 17:42, Eric Engestrom wrote:
> >
> > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > Signed-off-by: Eric Engestrom
> > > > ---
> > > > RELEASING
---
.../bindings/display/panel/ilitek,ili9341.txt | 33 +++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
b/Documentation/dev
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 320 +++
4 files changed, 334 insertions(+)
create mode 100644 drive
These patches add panel driver for ili9341-based panels in parallel RGB mode.
The driver was developed for DispleyTech DT024CTFT LCD panel [1] which features
ILI9341 chip [2].
The driver was tested on the Allwinner A13 (sun5i) platform.
The driver supports 240x320 pixel resolution with 18-bit RGB
+ dri-devel mailing list, especially for the buddy allocator part
Quoting Dave Airlie (2019-02-15 02:47:07)
> On Fri, 15 Feb 2019 at 00:57, Matthew Auld wrote:
> >
> > In preparation for upcoming devices with device local memory, introduce the
> > concept of different memory regions, and a simple
On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov
> wrote:
> >
> > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom
> > wrote:
> > >
> > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > Quoting Eric Engestrom (2018-12-19
On Tuesday, 2019-02-19 11:56:21 +, Emil Velikov wrote:
> On Tue, 19 Feb 2019 at 10:08, Eric Engestrom wrote:
> >
> > On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > > On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> > > wrote:
> > > >
> > > > On Fri, Feb 15,
On Mon, Feb 18, 2019 at 1:07 PM Vasily Khoruzhick wrote:
>
> On Mon, Feb 18, 2019 at 10:33 AM Rob Herring wrote:
> >
> > On Thu, Feb 14, 2019 at 09:09:56PM -0800, Vasily Khoruzhick wrote:
> > > This commit adds support for the NewEast Optoelectronics CO., LTD
> > > WJFH116008A 11.6" 1920x1080 TFT
From: Colin Ian King
There is a memory leak of 'spin' on an error return path. Fix this by
kfree'ing spin before the return.
Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 4 ++
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Tuesday, February 19, 2019 1:37 AM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst,
>Maarten ; dri-devel@lists.freedesktop.org
>
Quoting Colin King (2019-02-19 15:01:29)
> From: Colin Ian King
>
> There is a memory leak of 'spin' on an error return path. Fix this by
> kfree'ing spin before the return.
>
> Fixes: c06ee6ff2cbc ("drm/i915/selftests: Context SSEU reconfiguration tests")
> Signed-off-by: Colin Ian King
I hop
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 19, 2019 1:39 AM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v16 2/4] d
On Tue, Feb 19, 2019 at 03:09:00PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, February 19, 2019 1:37 AM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop
On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom wrote:
>
> On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov
> > wrote:
> > >
> > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom
> > > wrote:
> > > >
> > > > On Thursday, 2018-12-20 11:53
Quoting Daniel Vetter (2019-02-19 07:20:12)
> On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom
> wrote:
> >
> > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov
> > > wrote:
> > > >
> > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom
On Tue, Feb 19, 2019 at 12:56 AM Maxime Ripard
wrote:
>
> On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 18, 2019 at 10:26 AM Rob Herring wrote:
> > >
> > > On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > > > Clock rate check that was add
On Tue, Feb 19, 2019 at 9:07 AM Eric Engestrom wrote:
>
> On Tuesday, 2019-02-19 11:56:21 +, Emil Velikov wrote:
> > On Tue, 19 Feb 2019 at 10:08, Eric Engestrom
> > wrote:
> > >
> > > On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > > > On Fri, 15 Feb 2019 at 15:0
https://bugs.freedesktop.org/show_bug.cgi?id=109678
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Product|xorg
https://bugs.freedesktop.org/show_bug.cgi?id=109678
Michel Dänzer changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #2 from Michel Dä
https://bugs.freedesktop.org/show_bug.cgi?id=109587
Michel Dänzer changed:
What|Removed |Added
CC||pedretti.fa...@gmail.com
--- Comment #2
On Sun, Feb 17, 2019 at 05:43:16PM -0500, Rob Clark wrote:
> On Sun, Feb 17, 2019 at 4:08 PM Rob Herring wrote:
> >
> > On Mon, Feb 4, 2019 at 10:15 AM Jordan Crouse
> > wrote:
> > >
> > > The GMU should have two power domains defined: "cx" and "gx". "cx" is the
> > > actual power domain for the
https://bugs.freedesktop.org/show_bug.cgi?id=109679
Martin Peres changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=109679
--- Comment #2 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call
failed: RPC failed at server.
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scen
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. Thi
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with prop
On Tue, 19 Feb 2019 at 15:36, Dylan Baker wrote:
>
> Quoting Daniel Vetter (2019-02-19 07:20:12)
> > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom
> > wrote:
> > >
> > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov
> > > > w
On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
>> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
>>> On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
Another good question is also why the heck the acc_size counts
tow
On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey wrote:
> On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
> > This is a *very early RFC* (it builds, that's all I'll say :)
> > but I wanted to share it to get some initial feedback before I
> > go down the rabit hole of trying to adapt the
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #35 from quirin.blae...@freenet.de ---
Bug is still alive. v4.20.9
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lis
On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> Compared to linux and libdrm Mesa is missing a VLV and ICL id.
>
> 0x0f30
> ff049b6ce21d2814451afd4a116d001712e0116b
> drm/i915: bind driver to ValleyView chipsets
>
> 0x8A70
> d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> drm/i915/icl
On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> >
> > 0x0f30
> > ff049b6ce21d2814451afd4a116d001712e0116b
> > drm/i915: bind driver to ValleyView chip
https://bugs.freedesktop.org/show_bug.cgi?id=109679
--- Comment #3 from Stuart Summers ---
Agree this looks like an issue in IGT or possibly in the chameleond daemon. At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It
https://bugs.freedesktop.org/show_bug.cgi?id=109679
--- Comment #4 from Stuart Summers ---
Sent that previous comment a little too quickly... It looks like we aren't
actually sending those 0's in the first place, in addition to my off-by-one
(given we are taking 0 - 1, not 0) miss:
(w && h) ? "
If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.
This is on top of [1] reported and fixed by Dan Carpenter.
[1] https://patchwork.freedesktop.org/series/56656/
Fi
(Resend since there was a compile error that I forgot to commit before sending)
If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.
This is on top of [1] reported and
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
Currently the IOMMU code calls pm_runtime_get/put on the GPU or display
device before doing a IOMMU operation. This was because usually the
IOMMU driver didn't do power control of its own and since the hardware
used the same clocks and power as the respective multimedia device it
was a easy way to
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + cou
https://bugs.freedesktop.org/show_bug.cgi?id=109679
Easwar Hariharan changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |stuart.summ...@intel.com
https://bugzilla.kernel.org/show_bug.cgi?id=202537
--- Comment #22 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
Ok, being back at the system after some days, I see the kmemleaks are still
present with Linux 5.0-rc6+.
Bernd, what triggers this on your system? What is your test
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #14 from Harry Wentland ---
I'd recommend updating the System BIOS.
Early BIOSes on HP Envy x360 (and possibly other Raven laptops) had trouble
loading the DMCU FW.
--
You are receiving this mail because:
You are the assignee for
On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
From: Jérôme Glisse
Use an unsigned field for flags other than blockable and convert
the blockable field to be one of those flags.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Jan Kara
Cc: Andrea Arcangeli
Cc: Peter Xu
Cc: Feli
From: Jérôme Glisse
Simple helpers to test if range invalidation is blockable. Latter
patches use cocinnelle to convert all direct dereference of range->
blockable to use this function instead so that we can convert the
blockable field to an unsigned for more flags.
Signed-off-by: Jérôme Glisse
From: Jérôme Glisse
This update each existing invalidation to use the correct mmu notifier
event that represent what is happening to the CPU page table. See the
patch which introduced the events to see the rational behind this.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Joonas Lahtin
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU p
From: Jérôme Glisse
Since last version [4] i added the extra bits needed for the change_pte
optimization (which is a KSM thing). Here i am not posting users of
this, they will be posted to the appropriate sub-systems (KVM, GPU,
RDMA, ...) once this serie get upstream. If you want to look at users
From: Jérôme Glisse
Use the mmu_notifier_range_blockable() helper function instead of
directly dereferencing the range->blockable field. This is done to
make it easier to change the mmu_notifier range field.
This patch is the outcome of the following coccinelle patch:
%<
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
This patch introduce a set of enums that can be asso
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU p
From: Jérôme Glisse
Helper to test if a range is updated to read only (it is still valid
to read from the range). This is useful for device driver or anyone
who wish to optimize out update when they know that they already have
the range map read only.
Signed-off-by: Jérôme Glisse
Cc: Christian
From: Jérôme Glisse
When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag
for page table update that use set_pte_at_notify() and where the we are
going either from read and write to read only with same pfn or read only
to read and write with new pfn.
Note that set_pte_at_notify(
On 2/19/19 1:51 PM, Alex Deucher wrote:
> On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
> wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements
On Tue, Feb 19, 2019 at 12:04 PM wrote:
>
> From: Jérôme Glisse
>
> Since last version [4] i added the extra bits needed for the change_pte
> optimization (which is a KSM thing). Here i am not posting users of
> this, they will be posted to the appropriate sub-systems (KVM, GPU,
> RDMA, ...) once
On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:04 PM wrote:
> >
> > From: Jérôme Glisse
> >
> > Since last version [4] i added the extra bits needed for the change_pte
> > optimization (which is a KSM thing). Here i am not posting users of
> > this, the
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #15 from Harry Wentland ---
Can you see if this patch fixes it:
https://patchwork.freedesktop.org/patch/277181/
--
You are receiving this mail because:
You are the assignee for the bug.__
On Thu, Jan 24, 2019 at 10:45:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 09:56:51AM +1300, Christopher James Halse Rogers
> wrote:
> > On 24 January 2019 6:18:32 am NZDT, Emil Velikov
> > wrote:
> > >On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
> > > wrote:
> > >>
On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse wrote:
>
> On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:04 PM wrote:
> > >
> > > From: Jérôme Glisse
> > >
> > > Since last version [4] i added the extra bits needed for the change_pte
> > > optimizati
On 2/15/19 11:01 AM, John Stultz wrote:
On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
[snip]
Some thoughts, as this ABI break has the potential to be pretty painful.
1) Unfortunately, this ABI is exposed *throu
On 2/15/19 12:24 PM, John Stultz wrote:
With all the slight interface changes ion has had
through its time in staging, keeping userland working
properly has been a pain. Assuming more churn going
forward, provide a proper version interface.
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Liam Mark
Cc:
On Tue, Feb 19, 2019 at 12:41 PM Jason Gunthorpe wrote:
>
> On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote:
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM wrote:
> > > >
> > > > From: Jérôme Glisse
> > > >
> > > > Since las
On 2/19/19 9:21 AM, John Stultz wrote:
On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey wrote:
On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabi
On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse wrote:
> >
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM wrote:
> > > >
> > > > From: Jérôme Glisse
> > > >
> > > > Since last
1 - 100 of 158 matches
Mail list logo
