Hi, Chrstian
I wonder whether you could Review / ack the second patch in this
series,
https://patchwork.freedesktop.org/patch/449868/?series=91893&rev=3
And also ack merging that through drm-intel-gt-next,
Thanks,
Thomas
Hi all,
After merging the hmm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function 'i915_ttm_tt_get_st':
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:396:7: error: implicit declaration of
function '__sg_alloc_table_from_pages'; di
Hi, Christian,
Still working through some backlog and this series appears to have
slipped under the radar.
Still I think a cover letter would benefit reviewers...
On Mon, 2021-07-19 at 13:51 +0200, Christian König wrote:
> Keep track for which BO a resource was allocated.
> This is necessary to
Thanks, Christophe.
On Sun, Aug 22, 2021 at 11:30:08AM +0200, Christophe JAILLET wrote:
> The wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below.
>
> It has been compile tested.
Reviewed-by: Sakari Ailus
--
Sakari Ailu
On Mon, 2021-07-19 at 13:51 +0200, Christian König wrote:
> This way we finally fix the problem that new resource are
> not immediately evict-able after allocation.
>
> That has caused numerous problems including OOM on GDS handling
> and not being able to use TTM as general resource manager.
>
>
Hi,
We've encountered an issue with the RaspberryPi DSI panel that prevented the
whole display driver from probing.
The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi:
Only register our component once a DSI device is attached"), but the basic idea
is that since the panel i
The bridge documentation overview is quite packed already, and we'll add
some more documentation that isn't part of an overview at all.
Let's add some sections to the documentation to separate each bits.
Reviewed-by: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
Documentation/gpu/drm-kms-helpe
Interactions between bridges, panels, MIPI-DSI host and the component
framework are not trivial and can lead to probing issues when
implementing a display driver. Let's document the various cases we need
too consider, and the solution to support all the cases.
Signed-off-by: Maxime Ripard
---
Do
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device on removal.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drive
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device. This also avoids leaking the device when we detach
the bridge but don't remove its driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 12 +++-
1 file changed, 3 inser
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mipi_dsi.c | 35 ++
include/drm/drm_mipi_dsi.h | 1 +
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index ddf67463eaa1..18cef04df2f2 100644
-
Devices that take their data through the MIPI-DSI bus but are controlled
through a secondary bus like I2C have to register a secondary device on
the MIPI-DSI bus through the mipi_dsi_device_register_full() function.
At removal or when an error occurs, that device needs to be removed
through a call
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 93 ++
1 file ch
In order to avoid any probe ordering issue, the best practice is to move
the secondary MIPI-DSI device registration and attachment to the
MIPI-DSI host at probe time. Let's do this.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 76 +++
1 file ch
Am 13.08.21 um 16:43 schrieb Thomas Hellström:
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able t
On 20/08/2021 22:31, Alyssa Rosenzweig wrote:
> In lock_region, simplify the calculation of the region_width parameter.
> This field is the size, but encoded as log2(ceil(size)) - 1.
> log2(ceil(size)) may be computed directly as fls(size - 1). However, we
> want to use the 64-bit versions as the a
On 20/08/2021 22:31, Alyssa Rosenzweig wrote:
> Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
> we can express the "lock everything" condition as ~0ULL without relying
> on platform-specific behaviour.
'platform-specific behaviour' makes it sound like this is something t
On 20/08/2021 22:31, Alyssa Rosenzweig wrote:
> When locking a region, we currently clamp to a PAGE_SIZE as the minimum
> lock region. While this is valid for Midgard, it is invalid for Bifrost,
While the spec does seem to state it's invalid for Bifrost - kbase
didn't bother with a lower clamp for
Hi Thomas,
sorry for the delay. I was on vacation and still digging though everything.
Just added an rb to the second patch, but can't find the first one
anywhere in my mailbox. Going to double check that on patchwork instead.
Did you had a chance taking a look at the patches about moving the
On 8/23/21 11:10 AM, Christian König wrote:
Hi Thomas,
sorry for the delay. I was on vacation and still digging though
everything.
Just added an rb to the second patch, but can't find the first one
anywhere in my mailbox. Going to double check that on patchwork instead.
Did you had a cha
Hi Thomas,
Am 23.08.21 um 09:56 schrieb Thomas Hellström:
Hi, Christian,
Still working through some backlog and this series appears to have
slipped under the radar.
Still I think a cover letter would benefit reviewers...
On Mon, 2021-07-19 at 13:51 +0200, Christian König wrote:
Keep track fo
Am 23.08.21 um 12:01 schrieb Thomas Hellström:
On 8/23/21 11:10 AM, Christian König wrote:
Hi Thomas,
sorry for the delay. I was on vacation and still digging though
everything.
Just added an rb to the second patch, but can't find the first one
anywhere in my mailbox. Going to double ch
Am 21.08.21 um 11:16 schrieb Gal Pressman:
On 20/08/2021 17:32, Jason Gunthorpe wrote:
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
Though it would've been nicer if we could agree on a solution that could work
for more than 1-2 RDMA devices, using the existing tools the RDMA s
[...]
> We have three components comprising PM on Tegra:
>
> 1. Power gate
> 2. Clock state
> 3. Voltage state
>
> GENPD on/off represents the 'power gate'.
>
> Clock and reset are controlled by device drivers using clk and rst APIs.
>
> Volta
Adding Thomas on CC as well.
Just a gentle ping. I think the patch set makes sense now.
Regards,
Christian.
Am 28.07.21 um 15:05 schrieb Christian König:
Doing this in vmw_ttm_destroy() is to late.
It turned out that this is not a good idea at all because it leaves pointers
to freed up system
On Mon, 2021-08-23 at 13:05 +0200, Christian König wrote:
> Adding Thomas on CC as well.
>
> Just a gentle ping. I think the patch set makes sense now.
>
> Regards,
> Christian.
>
> Am 28.07.21 um 15:05 schrieb Christian König:
> > Doing this in vmw_ttm_destroy() is to late.
> >
> > It turned o
On Thu, Aug 19, 2021 at 12:10:20PM +0200, Krzysztof Kozlowski wrote:
> Use common enum instead of oneOf and correct indentation warning:
> realtek,rt1015p.yaml:18:7: [warning] wrong indentation: expected 4 but
> found 6 (indentation)
For stuff like this where there's no relationship between the
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this and that seems to
work okay.
v2:
* Added prot
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
From: Tvrtko Ursulin
Convert fdinfo format to one documented in drm-usage-stats.rst.
Opens:
* Does it work for AMD?
* What are the semantics of AMD engine utilisation reported in percents?
Can it align with what i915 does or needs to document the alternative
in the specification document
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
Hi Laurent,
On Sun, Aug 22, 2021 at 2:36 AM Laurent Pinchart
wrote:
> On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
> even when LVDS outputs are not used. For this reason, the rcar-lvds
> driver probes successfully on those platforms even if no further bridge
> or panel
On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
>
> On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
> > On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
> >
> > > +/**
> > > + * __sg_free_table - Free a previously mapped sg table
> > > + * @table: The sg table he
On Mon, 23 Aug 2021 19:51:25 +0800, yangcong wrote:
> Add documentation for boe tv110c9m-ll3 panel.
>
> Signed-off-by: yangcong
> ---
> .../display/panel/boe,tv110c9m-ll3.yaml | 83 +++
> 1 file changed, 83 insertions(+)
> create mode 100644
> Documentation/devicetree/bin
Am 23.08.21 um 13:28 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
han
On Mon, Aug 23, 2021 at 04:45:45PM +0300, Maor Gottlieb wrote:
>
> On 8/23/2021 3:45 PM, Jason Gunthorpe wrote:
> > On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
> > > On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
> > > > On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wr
On August 22, 2021 11:28:54 PM PDT, "Christian König"
wrote:
>
>
>Am 19.08.21 um 22:14 schrieb Kees Cook:
>> [...]
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 96e895d6be35..4605934a4fb7 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu
On Sat, Aug 21, 2021 at 08:45:54PM +0300, Dmitry Osipenko wrote:
> 20.08.2021 16:08, Ulf Hansson пишет:
> ...
> >> I suppose if there's really no good way of doing this other than
> >> providing a struct device, then so be it. I think the cleaned up sysfs
> >> shown in the summary above looks much
On Sat, Aug 21, 2021 at 4:46 AM Liviu Cheru wrote:
>
> Fixed warnings regarding SPDX license, using "unsigned" instead
> of "unsigned int", wrong function parameter name for the
> documentation and a space between the function name and "(".
>
In general, please split these up by the type of chang
Hi Geert,
On Mon, Aug 23, 2021 at 02:25:32PM +0200, Geert Uytterhoeven wrote:
> On Sun, Aug 22, 2021 at 2:36 AM Laurent Pinchart wrote:
> > On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU,
> > even when LVDS outputs are not used. For this reason, the rcar-lvds
> > driver pr
On Tue, Jul 27, 2021 at 02:10:37PM +0200, Daniel Vetter wrote:
> The module init code is somewhat misplaced in i915_pci.c, since it
> needs to pull in init/exit functions from every part of the driver and
> pollutes the include list a lot.
>
> Extract an i915_module.c file which pulls all the bits
Hi yangcong,
On Mon, Aug 23, 2021 at 07:51:23PM +0800, yangcong wrote:
> Documentation/devicetree/bindings/display/panel/boe,tv110c9m-ll3.yaml:
>
> Compared with v1, add a space in the required list.
>
> yangcong (2):
> drm/panel: support for BOE tv1110c9m-ll3 wuxga dsi video mode panel
Can
Add driver for BOE tv110c9m-ll3 panel is a 10.95" 1200x2000 panel.
Signed-off-by: yangcong
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-boe-tv110c9m.c | 1303
3 files changed, 1314 i
23.08.2021 13:46, Ulf Hansson пишет:
>>> ...
>>> dev_pm_opp_set_rate(rate)
>>> pm_runtime_get_noresume()
>>> pm_runtime_set_active()
>>> pm_runtime_enable()
>>> ...
>>> pm_runtime_put()
>>> ...
>>>
>>> We need to call genpd_set_performance_state() independently of whether
>>> the device is runtime
Hi Dave, Daniel,
The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3:
Linux 5.14-rc1 (2021-07-11 15:07:40 -0700)
are available in the Git repository at:
git://git.pengutronix.de/pza/linux tags/imx-drm-fixes-2021-08-18
for you to fetch changes up to 72fc2752f91b40312
On Mon, 23 Aug 2021, Guenter Roeck wrote:
> On Tue, Jul 27, 2021 at 02:10:37PM +0200, Daniel Vetter wrote:
>> The module init code is somewhat misplaced in i915_pci.c, since it
>> needs to pull in init/exit functions from every part of the driver and
>> pollutes the include list a lot.
>>
>> Extr
The bw code equals link_rate / 0.27 Gbps only for 8b/10b link
rates. Handle DP 2.0 UHBR rates as special cases, though this is not
pretty.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 26 ++
1 file changed, 22 insert
Extend the use of extended receiver cap at 0x2200 to cover
MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
the DP 2.0 128b/132b channel encoding cap.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_help
DP 2.0 brings some new DPCD addresses for PHY repeaters.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Manasi Navare
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
in
The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
vswing and pre-emphasis.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 14 ++
include/drm/drm_dp_helper.h | 2 ++
2 files changed
Hi,
On Wed, Aug 18, 2021 at 08:48:46AM -0500, Rob Herring wrote:
> On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard wrote:
> >
> > Hi Rob, Sam,
> >
> > On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
> > > On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> > > > The bindin
Hi Maxime,
On 23.08.2021 10:47, Maxime Ripard wrote:
> Interactions between bridges, panels, MIPI-DSI host and the component
> framework are not trivial and can lead to probing issues when
> implementing a display driver. Let's document the various cases we need
> too consider, and the solution t
Hi,
I updated the series to untangle more lock inversions caught by the
Intel-gfx CI, but again there might be more that I missed.
This series now converts drm_device.master_mutex into master_rwsem, and
also removes drm_file.master_lookup_lock.
Overall, this series makes the following changes:
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns -
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence, c
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl p
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
drm_device.master_rwsem is an outer lock that's grabbed in the ioctl
handler. However, in a future patch, master_rwsem will replace
drm_file.master_lookup_lock in drm_file_get_master, which is sometimes
called while holding other locks that depend on master_rwsem. This
circular locking should be av
Previously, master_lookup_lock was introduced in
commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
spinlock") to serialize accesses to drm_file.master. This then allowed
us to write drm_file_get_master in commit 56f0729a510f ("drm: protect
drm_master pointers in drm_lease.c").
The ra
On Mon, Aug 23, 2021 at 05:50:27PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell
> Date: Mon, 23 Aug 2021 17:46:27 +1000
> Subject: [PATCH] drm/i915/ttm: fix up for "lib/scatterlist: Provide a
> dedicated function to support tableappend"
>
> Signed-off-by: Stephen Rothwell
> drivers/
On Thu, 19 Aug 2021 12:10:19 +0200, Krzysztof Kozlowski wrote:
> Correct indentation warning:
> ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> found 8 (indentation)
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
Applied. Thanks!
Alex
On Mon, Aug 23, 2021 at 2:16 AM Christian König
wrote:
>
> Am 22.08.21 um 23:21 schrieb Christophe JAILLET:
> > The wrappers in include/linux/pci-dma-compat.h should go away.
> >
> > The patch has been generated with the coccinelle script below.
> >
> > It has been compile
Applied. Thanks!
Alex
On Mon, Aug 23, 2021 at 2:17 AM Christian König
wrote:
>
> Am 22.08.21 um 23:23 schrieb Christophe JAILLET:
> > The wrappers in include/linux/pci-dma-compat.h should go away.
> >
> > The patch has been generated with the coccinelle script below.
> >
> > It has been compile
On Mon, Aug 23, 2021 at 12:41 AM Andy Shevchenko
wrote:
>
> On Mon, Aug 23, 2021 at 1:21 AM Jim Cromie wrote:
> >
> > DEFINE_DYNAMIC_DEBUG_CATEGORIES(name, var, bitmap_desc, @bit_descs)
> > allows users to define a drm.debug style (bitmap) sysfs interface, and
> > to specify the desired mapping f
On Sun, Aug 22, 2021 at 5:34 PM Christophe JAILLET
wrote:
>
> The wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below.
>
> It has been compile tested.
>
> @@
> @@
> -PCI_DMA_BIDIRECTIONAL
> +DMA_BIDIRECTIONAL
>
> @@
>
On Sat, 21 Aug 2021 11:13:57 +0800, Zenghui Yu wrote:
> The zte zx platform had been removed in commit 89d4f98ae90d ("ARM: remove
> zte zx platform"), so this driver is no longer needed.
>
> Cc: Arnd Bergmann
> Cc: Jun Nie
> Cc: Shawn Guo
> Signed-off-by: Zenghui Yu
> ---
> .../devicetree/bin
23.08.2021 17:33, Thierry Reding пишет:
> On Sat, Aug 21, 2021 at 08:45:54PM +0300, Dmitry Osipenko wrote:
>> 20.08.2021 16:08, Ulf Hansson пишет:
>> ...
I suppose if there's really no good way of doing this other than
providing a struct device, then so be it. I think the cleaned up sysfs
Ping? This is a pretty clear bug and it is not fixed in -next or
drm-intel at this point.
On Fri, Aug 13, 2021 at 10:11:58AM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514:
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62:
Am 23.08.21 um 16:23 schrieb Kees Cook:
On August 22, 2021 11:28:54 PM PDT, "Christian König"
wrote:
Am 19.08.21 um 22:14 schrieb Kees Cook:
[...]
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 96e895d6be35..4605934a4fb7 100644
--- a/drivers/gp
Hi Mark,
On Mon, Aug 23, 2021 at 06:37:55PM +0100, Mark Brown wrote:
> On Thu, 19 Aug 2021 12:10:19 +0200, Krzysztof Kozlowski wrote:
> > Correct indentation warning:
> > ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> > found 8 (indentation)
>
> Applied to
>
>htt
On Mon, Aug 23, 2021 at 09:38:56PM +0200, Sam Ravnborg wrote:
> On Mon, Aug 23, 2021 at 06:37:55PM +0100, Mark Brown wrote:
> > [2/2] dt-bindings: sound: rt1015p: correct indentation
> > commit: 0aeb17d1728257f29131a290f0cc8e281cc7274c
> I am confused here.
> Did you apply both patches or o
[Public]
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, August 23, 2021 3:02 PM
> To: Kees Cook ; Lazar, Lijo
>
> Cc: Pan, Xinhui ; David Airlie ;
> Daniel Vetter ; Zhang, Hawking
> ; Xu, Feifei ; Gao, Likun
> ; Gu, JiaWei (Will) ; Quan,
> Evan ; amd-...@lists.freedesktop
On Thu, Aug 19, 2021 at 12:10:19PM +0200, Krzysztof Kozlowski wrote:
> Correct indentation warning:
> ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> found 8 (indentation)
>
> Signed-off-by: Krzysztof Kozlowski
Thanks, applied to drm-misc-next, and the patch will show
20.08.2021 15:57, Ulf Hansson пишет:
...
>> We already have similar APIs, so that won't be a problem. We also have
>> a mechanism inside the OPP core, frequency based, which is used to
>> guess the current OPP. Maybe we can enhance and use that directly
>> here.
>
> After reading the last reply fr
> > In lock_region, simplify the calculation of the region_width parameter.
> > This field is the size, but encoded as log2(ceil(size)) - 1.
> > log2(ceil(size)) may be computed directly as fls(size - 1). However, we
> > want to use the 64-bit versions as the amount to lock can exceed
> > 32-bits.
> > Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
> > we can express the "lock everything" condition as ~0ULL without relying
> > on platform-specific behaviour.
>
> 'platform-specific behaviour' makes it sound like this is something to
> do with a particular board. This
> > When locking a region, we currently clamp to a PAGE_SIZE as the minimum
> > lock region. While this is valid for Midgard, it is invalid for Bifrost,
>
> While the spec does seem to state it's invalid for Bifrost - kbase
> didn't bother with a lower clamp for a long time. I actually think this
[snip]
I think I might still be misunderstanding something, some comments below
On Mon, 2021-08-23 at 06:33 +, Lin, Wayne wrote:
> > > Hi Lyude,
> > >
> > > Really thankful for willing to explain in such details. Really
> > > appreciate.
> > >
> > > I'm trying to fix some problems that obse
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below.
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
Signed-off-by: Christophe JAILLET
---
If needed, s
On 23 August 2021 22:09:08 BST, Alyssa Rosenzweig wrote:
>> > In lock_region, simplify the calculation of the region_width parameter.
>> > This field is the size, but encoded as log2(ceil(size)) - 1.
>> > log2(ceil(size)) may be computed directly as fls(size - 1). However, we
>> > want to use the
On 23 August 2021 22:11:09 BST, Alyssa Rosenzweig wrote:
>> > Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
>> > we can express the "lock everything" condition as ~0ULL without relying
>> > on platform-specific behaviour.
>>
>> 'platform-specific behaviour' makes it sou
On 8/23/2021 3:45 PM, Jason Gunthorpe wrote:
On Mon, Aug 23, 2021 at 02:09:37PM +0300, Maor Gottlieb wrote:
On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
+/**
+ * __sg_free_table - Free a previously mapped sg table
+ * @table:
On 8/20/2021 6:54 PM, Jason Gunthorpe wrote:
On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
+/**
+ * __sg_free_table - Free a previously mapped sg table
+ * @table: The sg table header to use
+ * @max_ents: The maximum number of entries per single scatterlist
+ * @total
On 23 August 2021 22:13:45 BST, Alyssa Rosenzweig wrote:
>> > When locking a region, we currently clamp to a PAGE_SIZE as the minimum
>> > lock region. While this is valid for Midgard, it is invalid for Bifrost,
>>
>> While the spec does seem to state it's invalid for Bifrost - kbase
>> didn't bo
Acked-by: Anitha Chrisanthus
> -Original Message-
> From: jing yangyang
> Sent: Thursday, August 19, 2021 7:10 PM
> To: Chrisanthus, Anitha
> Cc: Dea, Edmund J ; David Airlie ;
> Daniel Vetter ; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; jing yangyang ; Zeal
> Rob
Hi allr,
On Mon, 23 Aug 2021 08:47:38 -0700 Guenter Roeck wrote:
>
> Seen in next-20210823:
>
> Building x86_64:allyesconfig ... failed
>
> drivers/gpu/drm/i915/i915_module.c:50:11: error:
> positional initialization of field in 'struct' declared with
Hi all,
[Thanks Guenter for pointing this out]
On Mon, 23 Aug 2021 12:41:22 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>
> between commit:
>
> 71ac6f390f6a ("drm/mediatek: Add AAL output si
From: Kenneth Feng
[ Upstream commit 2fd31689f9e44af949f60ff4f8aca013e628ab81 ]
This reverts commit 0979d43259e13846d86ba17e451e17fec185d240.
Revert this because it does not apply to all the cards.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-
From: Mark Yacoub
[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]
[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.
Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it
From: Kenneth Feng
[ Upstream commit 93c5701b00d50d192ce2247cb10d6c0b3fe25cd8 ]
change the workload type for some cards as it is needed.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/powerplay/hwmgr/vega
From: Ben Skeggs
[ Upstream commit e78b1b545c6cfe9f87fc577128e00026fff230ba ]
Should fix some initial modeset failures on (at least) Ampere boards.
Signed-off-by: Ben Skeggs
Reviewed-by: Lyude Paul
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 27 +
From: Ben Skeggs
[ Upstream commit fa25f28ef2cef19bc9ffeb827b8ecbf48af7f892 ]
Still no GA106 as I don't have HW to verif.
Signed-off-by: Ben Skeggs
Reviewed-by: Lyude Paul
Signed-off-by: Sasha Levin
---
.../gpu/drm/nouveau/nvkm/engine/device/base.c | 21 +++
1 file changed,
From: Ben Skeggs
[ Upstream commit 6eaa1f3c59a707332e921e32782ffcad49915c5e ]
When booted with multiple displays attached, the EFI GOP driver on (at
least) Ampere, can leave DP links powered up that aren't being used to
display anything. This confuses our tracking of SOR routing, with the
likel
From: Ben Skeggs
[ Upstream commit 148a8653789c01f159764ffcc3f370008966b42f ]
Long ago, there had been plans for making use of a bunch of these APIs
from userspace and there's various checks in place to stop misbehaving.
Countless other projects have occurred in the meantime, and the pieces
did
From: Kenneth Feng
[ Upstream commit 2fd31689f9e44af949f60ff4f8aca013e628ab81 ]
This reverts commit 0979d43259e13846d86ba17e451e17fec185d240.
Revert this because it does not apply to all the cards.
Signed-off-by: Kenneth Feng
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-
1 - 100 of 123 matches
Mail list logo
