On 9/5/19 6:17 AM, Harry Wentland wrote:
>
>
> On 2019-09-04 4:58 p.m., Randy Dunlap wrote:
>> On 9/4/19 6:34 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> News: this will be the last linux-next I will release until Sept 30.
>>>
>>> Changes since 20190903:
>>>
>>
>> on x86_64:
>>
>> In file inc
On 2019/9/5 16:38, Markus Elfring wrote:
>>> Were any source code analysis tools involved for finding
>>> these update candidates?
>> With the help of Coccinelle. You can find out some example in
>> scripts/coccinelle/.
> Thanks for such background information.
> Was the script “ifnullfree.cocci”
On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja
> Hello!
>
> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> I originally filed the issue on LaunchPad and more details can be found
> there, although I doubt whether these details are useful.
>
> https://bugs.
>> Were any source code analysis tools involved for finding
>> these update candidates?
> With the help of Coccinelle. You can find out some example in
> scripts/coccinelle/.
Thanks for such background information.
Was the script “ifnullfree.cocci” applied here?
Will it be helpful to add attribu
> The functions "debugfs_remove" and "kfree" tolerate the passing
> of null pointers. Hence it is unnecessary to check such arguments
> around the calls. Thus remove the extra condition check at two places.
Will a tag like “Generated-by: scripts/coccinelle/free/ifnullfree.cocci” be
relevant here?
Move the static keyword to the front of declaration of DC_BUILD_ID,
and resolve the following compiler warning that can be seen when
building with warnings enabled (W=1):
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-de
Hi Daniel, Dave,
Here is a drm-misc-next-fixes PR with a significant number of fixes
for panfrost.
Maxime
drm-misc-next-fixes-2019-09-06:
- A significant number of panfrost fixes for runtime_pm, MMU and GEM support
- A fix for DCS transfers on mcde
The following changes since commit 578d2342ec
This is a SW workaround for shadow un-flushed when together with the
DOU Timing-disable.
D71 HW doesn't update shadow registers when display output is turned
off. So when we disable all pipeline components together with display
output disabling by one flush or one operation, the disable operation
Hey Linus,
Live from my friend's couch in Barcelona. Latest round of drm fixes,
the command line parser regression fixes look a bit larger because
they come with selftests included for the bugs they fix. Otherwise a
single nouveau, single ingenic and single vmwgfx fix.
Dave.
drm-fixes-2019-09-06
The commit 3764137906a5 ("drm/modes: Introduce a whitelist for the named
modes") introduced a whitelist in the named modes lookup code in order to
be a bit more robust.
However, even though the char pointers were made const, the data they were
pointing were not. Let's fix that.
Fixes: 3764137906a
On Fri, 06 Sep 2019, Maxime Ripard wrote:
> The commit 3764137906a5 ("drm/modes: Introduce a whitelist for the named
> modes") introduced a whitelist in the named modes lookup code in order to
> be a bit more robust.
>
> However, even though the char pointers were made const, the data they were
>
Hi
Am 05.09.19 um 11:29 schrieb Gerd Hoffmann:
> On Thu, Sep 05, 2019 at 10:19:40AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 05.09.19 um 09:56 schrieb Daniel Vetter:
>>> On Thu, Sep 5, 2019 at 9:01 AM Gerd Hoffmann wrote:
Hi,
> - imo we should fix this by using the io_m
This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is detected to notify the drm part,
which can trigger for exa
This series introduce to drm a way to determine if something else
except connection_status had changed during probing, which
can be used by other drivers as well. Another i915 specific part
uses this approach to determine if edid had changed without
changing the connection status and send a hotplug
Added epoch counter checking to intel_encoder_hotplug
in order to be able process all the connector changes,
besides connection status. Also now any change in connector
would result in epoch counter change, so no multiple checks
are needed.
v2: Renamed change counter to epoch counter. Fixed type n
Many drivers would benefit from using
drm helper to compare edid, rather
than bothering with own implementation.
v2: Added documentation for this function.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_edid.c | 33 +
include/drm/drm_edid.h | 9 +
This patch prepares VRAM helpers for lazy unmapping of buffer objects.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vram_mm_helper.c | 12
include/drm/drm_vram_mm_helper.h | 4
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
Frequent mapping and unmapping a buffer object adds overhead for
modifying the page table and creates debug output. Unmapping a buffer
is only required when the memory manager evicts the buffer from its
current location.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c
The kmap and kunmap operations of GEM VRAM buffers can now be called
in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
buffer's memory to kernel address space and the final call to
drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
functions increment or decrem
(was: ast, mgag200: Map console BO while it's being displayed)
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such
On Fri, Sep 06, 2019 at 10:52:12AM +0200, Thomas Zimmermann wrote:
> The kmap and kunmap operations of GEM VRAM buffers can now be called
> in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
> buffer's memory to kernel address space and the final call to
> drm_gem_vram_kunmap() u
On Thu, Sep 05, 2019 at 05:26:08PM -0400, Kenny Ho wrote:
> On Thu, Sep 5, 2019 at 4:32 PM Daniel Vetter wrote:
> >
> *snip*
> > drm_dev_unregister gets called on hotunplug, so your cgroup-internal
> > tracking won't get out of sync any more than the drm_minor list gets
> > out of sync with drm_de
On Thu, Sep 05, 2019 at 09:05:01AM +0200, Gerd Hoffmann wrote:
>
>
> Gerd Hoffmann (8):
> drm/ttm: turn ttm_bo_device.vma_manager into a pointer
> drm/nouveau: switch to gem vma offset manager
> drm/vram: switch to gem vma offset manager
> drm/radeon: switch to gem vma offset manager
>
The implementation of functions encoder_enable and encoder_disable
make possible to control the pinctrl according to the encoder type.
The pinctrl must be activated only if the encoder type is DPI.
This helps to move the DPI-related pinctrl configuration from
all the panel or bridge to the LTDC dt
On Fri, Sep 06, 2019 at 10:52:13AM +0200, Thomas Zimmermann wrote:
> This patch prepares VRAM helpers for lazy unmapping of buffer objects.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_vram_mm_helper.c | 12
> include/drm/drm_vram_mm_helper.h | 4
> 2 f
> +void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
> + bool evict,
> + struct ttm_mem_reg *new_mem)
> +{
[ ... ]
> + if (!kmap->virtual)
> + return;
> + ttm_bo_kunmap(kmap);
> + kma
(+CC Rob - I'm not sure why he was dropped)
On 05/09/2019 17:34, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 02:02:38PM +0100, Steven Price wrote:
>> On 05/09/2019 13:40, Mark Brown wrote:
>
>>> Is that safe? You can't rely on being able to change voltages even if
>>> there's a physical regulato
Might be useful when debugging MMU exceptions.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index d47d1a8e0
On Fr, 2019-09-06 at 12:03 +0200, Christian Gmeiner wrote:
> Update the state HI and common header from rnndb commit
> a04283591a8a (rnndb: update MMU exception causes).
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/state.xml.h | 37 +-
> drivers/gpu/drm/etnaviv/stat
Hi
Am 06.09.19 um 11:28 schrieb Daniel Vetter:
> On Fri, Sep 06, 2019 at 10:52:13AM +0200, Thomas Zimmermann wrote:
>> This patch prepares VRAM helpers for lazy unmapping of buffer objects.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/drm_vram_mm_helper.c | 12
>>
Am Fr., 6. Sept. 2019 um 12:11 Uhr schrieb Lucas Stach :
>
> On Fr, 2019-09-06 at 12:03 +0200, Christian Gmeiner wrote:
> > Update the state HI and common header from rnndb commit
> > a04283591a8a (rnndb: update MMU exception causes).
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=204181
jamespharve...@gmail.com changed:
What|Removed |Added
CC||jamespharve...@gmail.com
--- C
Hi
Am 06.09.19 um 11:39 schrieb Gerd Hoffmann:
>> +void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
>> +bool evict,
>> +struct ttm_mem_reg *new_mem)
>> +{
> [ ... ]
>> +if (!kmap->virtual)
>> +
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #48 from jamespharve...@gmail.com ---
Vega 64.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
On Fr, 2019-09-06 at 12:35 +0200, Christian Gmeiner wrote:
> Am Fr., 6. Sept. 2019 um 12:11 Uhr schrieb Lucas Stach
> :
> > On Fr, 2019-09-06 at 12:03 +0200, Christian Gmeiner wrote:
> > > Update the state HI and common header from rnndb commit
> > > a04283591a8a (rnndb: update MMU exception cause
On Fri, Sep 06, 2019 at 11:00:53AM +0100, Steven Price wrote:
> On 05/09/2019 17:34, Mark Brown wrote:
> > that information, I'd recommend eliminating individual OPPs if some are
> > supported or just never doing any regulator configuration if none can be
> > set.
> The problem on the Hikey960 is
On Fr, 2019-09-06 at 12:03 +0200, Christian Gmeiner wrote:
> Might be useful when debugging MMU exceptions.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26
> ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/e
On Thu, Sep 05, 2019 at 07:51:59PM +, Siqueira, Rodrigo wrote:
> Hi Ville,
>
> First of all, thank you very much for the review.
>
> I added some comments below.
>
> On 09/05, Wentland, Harry wrote:
> > On 2019-09-05 1:29 p.m., Ville Syrjälä wrote:
> > > On Wed, Sep 04, 2019 at 07:02:18PM +0
On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>
> When handling a GPU page fault addr_to_drm_mm_node() is used to
> translate the GPU address to a buffer object. However it is possible for
> the buffer object to be freed after the function has returned resulting
> in a use-after-free of the B
On Fri, Sep 06, 2019 at 12:37:47PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 06.09.19 um 11:39 schrieb Gerd Hoffmann:
> >> +void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
> >> + bool evict,
> >> + struct ttm
On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza wrote:
> From: Dhinakaran Pandiyan
>
> Currently we restrict the number of encoders that can be linked to
> a connector to 3, increase it to match the maximum number of encoders
> that can be initialized(32).
>
> To more effiently d
>-Original Message-
>From: Ilia Mirkin
>Sent: Tuesday, September 3, 2019 6:12 PM
>To: Mun, Gwan-gyeong
>Cc: Intel Graphics Development ; Shankar, Uma
>; dri-devel
>Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace property
>
>So how would this work with a DP++ connector? Shou
On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ilia Mirkin
> >Sent: Tuesday, September 3, 2019 6:12 PM
> >To: Mun, Gwan-gyeong
> >Cc: Intel Graphics Development ; Shankar,
> >Uma
> >; dri-devel
> >Subject: Re: [PATCH v4 3/7] drm: Add D
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #68 from tempel.jul...@gmail.com ---
I did it, but it stopped after hitting the two breakpoints the first time
without me having moved the mouse at all. I suppose this isn't enough? Would it
be possible to provide me with a short hint
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #69 from tempel.jul...@gmail.com ---
Created attachment 145278
--> https://bugs.freedesktop.org/attachment.cgi?id=145278&action=edit
1st gdb log
--
You are receiving this mail because:
You are the assignee for the bug.
Hi,
> I think if we do an mmap callback, it should replace all the mmap handling
> (except the drm_gem_object_get) that drm_gem_mmap_obj does. So maybe
> something like the below:
[ snip ]
> Since I remember quite a few discussions where the default vma flag
> wrangling we're doing is seriousl
Frequent mapping and unmapping a buffer object adds overhead for
modifying the page table and creates debug output. Unmapping a buffer
is only required when the memory manager evicts the buffer from its
current location.
v4:
* WARN_ON if buffer is still mapped during BO cleanup
Signed-off
The kmap and kunmap operations of GEM VRAM buffers can now be called
in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
buffer's memory to kernel address space and the final call to
drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
functions increment or decrem
The implementation of vmap() is a combined pin() and kmap(). As both
functions share the same lock, we can make vmap() slightly faster by
acquiring the lock only once for both operations. Same for the inverse,
vunmap().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c |
This patch prepares VRAM helpers for lazy unmapping of buffer objects.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vram_mm_helper.c | 12
include/drm/drm_vram_mm_helper.h | 4
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such as
x86/PAT: Overlap at 0xd000-0xd100
x86/PAT: rese
On 06/09/2019 12:10, Rob Herring wrote:
> On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>>
>> When handling a GPU page fault addr_to_drm_mm_node() is used to
>> translate the GPU address to a buffer object. However it is possible for
>> the buffer object to be freed after the function has ret
On Fri, Sep 6, 2019 at 12:24 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 06.09.19 um 11:28 schrieb Daniel Vetter:
> > On Fri, Sep 06, 2019 at 10:52:13AM +0200, Thomas Zimmermann wrote:
> >> This patch prepares VRAM helpers for lazy unmapping of buffer objects.
> >>
> >> Signed-off-by: Thomas Zimmerm
On Fri, Sep 6, 2019 at 2:13 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > I think if we do an mmap callback, it should replace all the mmap handling
> > (except the drm_gem_object_get) that drm_gem_mmap_obj does. So maybe
> > something like the below:
>
> [ snip ]
>
> > Since I remember quite a few disc
On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
wrote:
>
> On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Ilia Mirkin
> > >Sent: Tuesday, September 3, 2019 6:12 PM
> > >To: Mun, Gwan-gyeong
> > >Cc: Intel Graphics Development ; Shank
Hello, new iteration of CMM support, with quite a few changes compared to
v3:
References:
A reference to the v1 cover letter, with some background on the CMM is
available here:
https://lkml.org/lkml/2019/6/6/583
v2:
https://lore.kernel.org/linux-renesas-soc/20190706140746.29132-10-jacopo+rene...@j
Expand comment in the 'vsps' parsing routine to specify the LIF
channel index defaults to 0 in case the second cell of the property
is not specified to remain compatible with older DT bindings.
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
This trivial change is a leftover from a
Enable/disable the CMM associated with a CRTC at CRTC start and stop
time and enable the CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc
Update CMM settings at in the atomic commit tail helper method.
The CMM is updated with new gamma values provided to the driver
in the GAMMA_LUT blob property.
When resuming from system suspend, the DU driver is responsible for
reprogramming and enabling the CMM unit if it was in use at the time t
[ Ugh, sorry for the double sending, but I forgot --cc-cover to git-send
email and the series has not been delivered to the mailing lists.
Sorry about that. ]
Hello, new iteration of CMM support, with quite a few changes compared to
v3:
References:
A reference to the v1 cover letter, with som
Add CMM units to Renesas R-Car Gen3 SoC that support it, and reference them
from the Display Unit they are connected to.
Sort the 'vsps' and 'renesas,cmm' entries in the DU unit consistently
in all the involved DTS.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 40
Implement device tree parsing to collect the available CMM instances
described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
store a mask of active CMMs in the DU group for later enablement.
Enforce the probe and suspend/resume ordering of DU and CMM by creating
a stateless device
Add CMM to the list of supported features for Gen3 SoCs that provide it:
- R8A7795
- R8A7796
- R8A77965
- R8A7799x
Leave R8A77970 out as V3M and V3H are the only Gen3 SoCs that do not
support CMM.
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/
Enable the GAMMA_LUT KMS property using the framework helpers to
register the property and set the associated gamma table maximum size.
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4
1 file changed, 4 ins
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanc
Add device tree bindings documentation for the Renesas R-Car Display
Unit Color Management Module.
CMM is the image enhancement module available on each R-Car DU video
channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
Signed-off-by: Jacopo Mondi
---
.../bindings/display/renesas,cmm.ya
Document the newly added 'cmms' property which accepts a list of phandle
and channel index pairs that point to the CMM units available for each
Display Unit output video channel.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
---
Documentation/devicetree/bindings/display/renesas,du.t
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #70 from Michel Dänzer ---
(In reply to tempel.julian from comment #68)
> I did it, but it stopped after hitting the two breakpoints the first time
> without me having moved the mouse at all. I suppose this isn't enough? Would
> it b
Am Fr., 6. Sept. 2019 um 12:55 Uhr schrieb Lucas Stach :
>
> On Fr, 2019-09-06 at 12:03 +0200, Christian Gmeiner wrote:
> > Might be useful when debugging MMU exceptions.
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26
> > ++
Hi
Am 06.09.19 um 15:05 schrieb Daniel Vetter:
> On Fri, Sep 6, 2019 at 12:24 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 06.09.19 um 11:28 schrieb Daniel Vetter:
>>> On Fri, Sep 06, 2019 at 10:52:13AM +0200, Thomas Zimmermann wrote:
This patch prepares VRAM helpers for lazy unmapping of b
Hi Wen,
On Thu, Aug 22, 2019 at 10:11:35AM +0800, Wen He wrote:
> Configure the display Quality of service (QoS) levels priority if the
> optional property node "arm,malidp-aqros-value" is defined in DTS file.
>
> QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
> driven fr
On Wed, Sep 04, 2019 at 10:05:09PM +0200, Daniel Vetter wrote:
> On Wed, Sep 4, 2019 at 9:58 PM Souza, Jose wrote:
> >
> > On Wed, 2019-09-04 at 16:39 +0200, Daniel Vetter wrote:
> > > - it's what we recommend in our docs:
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommen
Hi Jacopo,
On Fri, Sep 06, 2019 at 03:50:12PM +0200, Jacopo Mondi wrote:
> Expand comment in the 'vsps' parsing routine to specify the LIF
> channel index defaults to 0 in case the second cell of the property
> is not specified to remain compatible with older DT bindings.
>
> Reviewed-by: Laurent
We forgot that.
Proof is the one igt testcase we have:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280
While at it also document that we have immutable zpos properties in
some cases.
Reported-by: Pekka Paalanen
Cc: Pekka Paalanen
Reviewed-by: Pekka Paalane
On 06/09/2019 11:55, Mark Brown wrote:
[...]
>>> However you're probably better off hiding all this stuff with the
>>> generic OPP code rather than open coding it - this already has much
>>> better handling for this, it supports voltage ranges rather than single
>>> voltages and optional regulators
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #71 from tempel.jul...@gmail.com ---
Hope this helps:
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #72 from tempel.jul...@gmail.com ---
Created attachment 145280
--> https://bugs.freedesktop.org/attachment.cgi?id=145280&action=edit
2nd gdb backtrace log, now with debug symbols
--
You are receiving this mail because:
You are the
This function lost its only call site as part of
earlier dead code removal, so remove it as well:
drivers/video/fbdev/sa1100fb.c:975:21: error: unused function
'sa1100fb_min_dma_period' [-Werror,-Wunused-function]
Fixes: 390e5de11284 ("fbdev/sa1100fb: Remove dead code")
Signed-off-by: Arnd Bergm
On Fri, Sep 6, 2019 at 4:45 PM Daniel Vetter wrote:
>
> We forgot that.
>
> Proof is the one igt testcase we have:
>
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280
>
> While at it also document that we have immutable zpos properties in
> some cases.
>
> Repo
Hello, Daniel.
On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> I think system memory separate from vram makes sense. For one, vram is
> like 10x+ faster than system memory, so we definitely want to have
> good control on that. But maybe we only want one vram bucket overall
> for t
On 04/09/2019 13:30, Mark Brown wrote:
> The panfrost driver requests a supply using regulator_get_optional()
> but both the name of the supply and the usage pattern suggest that it is
> being used for the main power for the device and is not at all optional
> for the device for function, there is
On Fri, 6 Sep 2019 at 16:19, Daniel Vetter wrote:
> On Fri, Sep 6, 2019 at 4:45 PM Daniel Vetter wrote:
> > We forgot that.
> >
> > Proof is the one igt testcase we have:
> >
> > https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280
> >
> > While at it also document
Hello,
On Wed, Sep 04, 2019 at 10:54:34AM +0200, Daniel Vetter wrote:
> Anyway, I don't think reusing the drm_minor registration makes sense,
> since we want to be on the drm_device, not on the minor. Which is a bit
> awkward for cgroups, which wants to identify devices using major.minor
> pairs.
From: Colin Ian King
Don't populate the arrays on the stack but instead make them
static const. Makes the object code smaller by 1329 bytes.
Before:
textdata bss dec hex filename
55811488 6471331bdd drivers/staging/fbtft/fb_hx8340bn.o
54441264
On Fri, Sep 6, 2019 at 5:23 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> > I think system memory separate from vram makes sense. For one, vram is
> > like 10x+ faster than system memory, so we definitely want to have
> > good control o
On Fri, Sep 6, 2019 at 5:29 PM Tejun Heo wrote:
>
> Hello,
>
> On Wed, Sep 04, 2019 at 10:54:34AM +0200, Daniel Vetter wrote:
> > Anyway, I don't think reusing the drm_minor registration makes sense,
> > since we want to be on the drm_device, not on the minor. Which is a bit
> > awkward for cgroup
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:36:02PM +0200, Daniel Vetter wrote:
> Block devices are a great example I think. How do you handle the
> partitions on that? For drm we also have a main minor interface, and
cgroup IO controllers only distribute hardware IO capacity and are
blind to parti
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > Hmm... what'd be the fundamental difference from slab or socket memory
> > which are handled through memcg? Is system memory used by GPUs have
> > further global restrictions in addition to the amount of physical
>
The pull request you sent on Fri, 6 Sep 2019 17:18:34 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-09-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/08d433d8121598f7c2a45f3461c534746b1ed05b
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Hi Dave,
This time around:
+ move msm8998 (snapdragon 835) display support
+ dpu fixes/cleanup
+ better async commit support for cursor updates
(for dpu for now, I'll add mdp5 and possibly
mdp4 once the movers deliver boxes full of my
older hardware, so for v5.5)
The following change
On Fri, Sep 06, 2019 at 10:56:10AM +0300, Jani Nikula wrote:
> On Fri, 06 Sep 2019, Maxime Ripard wrote:
> > The commit 3764137906a5 ("drm/modes: Introduce a whitelist for the named
> > modes") introduced a whitelist in the named modes lookup code in order to
> > be a bit more robust.
> >
> > Howe
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #9 from Julien Isorce ---
Hi Michel, nice catch!
Instead of using totem which has other issues can you try:
gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! vaapih264dec !
vaapipostproc ! videoconvert ! ximagesink
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #73 from Michel Dänzer ---
Looks like some client repeatedly calls XForceScreenSaver (probably to prevent
the monitors from blanking), which results in the DPMS property getting re-set
over and over. Nicholas, maybe the kernel could
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #74 from Nicholas Kazlauskas ---
(In reply to Michel Dänzer from comment #73)
> Looks like some client repeatedly calls XForceScreenSaver (probably to
> prevent the monitors from blanking), which results in the DPMS property
> gettin
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Summary|[kernel 5.2.1][amdgpu][CIK] |[kernel
|BUG: K
From: Markus Elfring
Date: Fri, 6 Sep 2019 18:40:48 +0200
Simplify these function implementations by using a known function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 6 +-
drivers/gpu/drm/omapdrm
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Attachment #144932|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Attachment #144933|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #10 from Michel Dänzer ---
(In reply to Julien Isorce from comment #9)
> gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse !
> vaapih264dec ! vaapipostproc ! videoconvert ! ximagesink
>
> (with and without vaapipostpro
Hello,
syzbot found the following crash on:
HEAD commit:6d028043 Add linux-next specific files for 20190830
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16cbf22a60
kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
dashboard
1 - 100 of 137 matches
Mail list logo
