This function returns a bool type so returning -EBUSY is equivalent to
returning true. It should return false instead.
Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Hi Bernard,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v5.16-rc2 next-2028]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
On 04.11.21 14:24, Yunfei Dong wrote:
Width and height need to 64 bytes aligned when setting the format.
Need to make sure all is 64 bytes align when use width and height to
calculate buffer size.
Signed-off-by: Yunfei Dong
Acked-by: Nicolas Dufresne
Tested-by: Steve Cho
---
drivers/medi
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-2028]
url:
https://github.com/0day-ci/linux/commits/cgel-zte-gmail-com/drm-i915-request-Remove-unused-variables/20211121-181441
base:5191249f880367a4cd675825cd721a8d78f26a45
config: x86_64
Get the display mode settings via mode_set bridge function
instead of explicitly de-reference.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/driver
Some display panels would come up with a non-DSI output, those
can have an option to connect the DSI host by means of interface
bridge converter.
This DSI to non-DSI interface bridge converter would requires
DSI Host to handle drm bridge functionalities in order to DSI
Host to Interface bridge.
T
This is initial step to convert exynos dsi to bridge and
make use of i.MX8MMini.
The previous RFC series for this is here [1]
I'm trying to add minimalist patches as I don't have hardware
to validate, the next plan is to add panel_bridge and other
improvements.
[1] https://www.spinics.net/lists
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts | 79 +--
1 file changed, 73 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts
b/arch/arm/boot/dts/sun8i-r16-renew-vista-e.dts
index d28b7b35a3c5..c3ee6a879ddb 1006
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211
DSI/RGB convertor bridge.
Enable bridge along with associated panel.
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm/boot/
This patch add support for Bananapi S070WV20-CT16 panel to
BPI-M2M board.
This specific DSI Bananapi S070WV20-CT16 panel driver is not
available in upstream, added for testing purpose.
Signed-off-by: Jagan Teki
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 40
1 file c
Get the display mode settings via mode_set bridge function
instead of explicitly de-reference.
Signed-off-by: Jagan Teki
---
Changes for v5:
- new patch
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++-
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
2 files changed, 12 insertions(+), 1
Some display panels would come up with a non-DSI output, those
can have an option to connect the DSI host by means of interface
bridge converter.
This DSI to non-DSI interface bridge converter would requires
DSI Host to handle drm bridge functionalities in order to DSI
Host to Interface bridge.
T
Having component_add for running all drm bind callbacks returns
error or unbound due to chain of DSI devices connected across
bridge topology on a display pipeline.
In a typical bridge oriented display pipeline where the host is
connected to the bridge converter and that indeed connected to
a pane
Existing host driver will keep looking for DRM pointer in
sun6i_dsi_attach and defers even if the particular DSI device
is found for the first time. Meanwhile it triggers the bind
callback and gets the DRM pointer and then continues the
sun6i_dsi_attach.
This makes a deadlock situation if sun6i_ds
This series convert Allwinner DSI controller to full functional
drm bridge driver for supporting all variants of DSI devices.
Here, are the previous version changes[1].
Patch 1: Drop the DRM bind race while attaching bridges
Patch 2: Move component_add into sun6i_dsi_attach
Patch 3: Convert th
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-2028]
url:
https://github.com/0day-ci/linux/commits/cgel-zte-gmail-com/drm-i915-request-Remove-unused-variables/20211121-181441
base:5191249f880367a4cd675825cd721a8d78f26a45
config: x86_64
> >> diff --git a/mm/migrate.c b/mm/migrate.c
> >> index 1852d787e6ab..f74422a42192 100644
> >> --- a/mm/migrate.c
> >> +++ b/mm/migrate.c
> >> @@ -362,7 +362,7 @@ static int expected_page_refs(struct address_space
> >> *mapping, struct page *page)
> >> * Device private pages have an extra ref
Hi Sascha,
Am 17.11.21 um 15:33 schrieb Sascha Hauer:
> This series adds initial graphics support for the Rockchip RK356[68]
> SoCs. Graphics support is based around the VOP2 controller which
> replaces the VOP controller found on earlier Rockchip SoCs. The driver
> has been tested with HDMI supp
Hi, this is your Linux kernel regression tracker speaking.
On 16.11.21 05:52, Harald Dunkel wrote:
>
> if I enable CONFIG_SYSFB_SIMPLEFB in 5.15.2 and use grub's default
> configuration
> (Debian sid amd64), then a few lines at the bottom of /dev/tty1 including
> login prompt are off-screen. Scro
Le dim., nov. 21 2021 at 19:49:03 +0100, Lars-Peter Clausen
a écrit :
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen
a écrit :
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming a
The intel_gmbus_set_speed() function is not used anywhere, remove it.
Note drivers/gpu/drm/gma500 has its own copy called
gma_intel_gmbus_set_speed() which is used, the intel_gmbus_set_speed()
version in the i915 code is not used at all
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/disp
On 11/21/21 6:52 PM, Paul Cercueil wrote:
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen
a écrit :
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.
While this totally wo
Hi Lars,
Le dim., nov. 21 2021 at 17:23:35 +0100, Lars-Peter Clausen
a écrit :
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.
While this totally works, it adds some complexity to the code,
e
Hi Jonathan,
Le dim., nov. 21 2021 at 15:10:26 +, Jonathan Cameron
a écrit :
On Mon, 15 Nov 2021 14:22:43 +
Paul Cercueil wrote:
Document the new DMABUF based API.
Signed-off-by: Paul Cercueil
Hi Paul,
A few trivial things inline but looks good to me if we do end up
using DM
Hi Jonathan,
Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron
a écrit :
On Mon, 15 Nov 2021 14:19:21 +
Paul Cercueil wrote:
We can be certain that the input buffers will only be accessed by
userspace for reading, and output buffers will mostly be accessed by
userspace for wr
The 'doorbell_bitmap' bitmap has just been allocated. So we can use the
non-atomic '__set_bit()' function to save a few cycles as no concurrent
access can happen.
Signed-off-by: Christophe JAILLET
---
bitmap_set() could certainly also be use, but range checking would be
tricky.
---
drivers/gpu/d
'doorbell_bitmap' is a bitmap. So use 'bitmap_zalloc()' to simplify code,
improve the semantic and avoid some open-coded arithmetic in allocator
arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/amd
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Hristos (kernel-b...@hristos.co) changed:
What|Removed |Added
CC||kernel-b...@hristos.co
Hi Jonathan,
Le dim., nov. 21 2021 at 14:20:49 +, Jonathan Cameron
a écrit :
On Mon, 15 Nov 2021 14:19:14 +
Paul Cercueil wrote:
Adding write support to the buffer-dma code is easy - the write()
function basically needs to do the exact same thing as the read()
function: dequeue a
On 11/15/21 3:19 PM, Paul Cercueil wrote:
The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.
While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much easier to
just check eac
Fix kernel-doc warnings in ttm_range_manager.c:
drivers/gpu/drm/ttm/ttm_range_manager.c:144: warning: expecting prototype for
ttm_range_man_init(). Prototype was for ttm_range_man_init_nocheck() instead
drivers/gpu/drm/ttm/ttm_range_manager.c:178: warning: expecting prototype for
ttm_range_man_f
On Mon, 15 Nov 2021 14:22:43 +
Paul Cercueil wrote:
> Document the new DMABUF based API.
>
> Signed-off-by: Paul Cercueil
Hi Paul,
A few trivial things inline but looks good to me if we do end up using DMABUF
anyway.
Jonathan
> ---
> Documentation/driver-api/dma-buf.rst | 2 +
> Docum
On Mon, 15 Nov 2021 14:19:21 +
Paul Cercueil wrote:
> We can be certain that the input buffers will only be accessed by
> userspace for reading, and output buffers will mostly be accessed by
> userspace for writing.
Mostly? Perhaps a little more info on why that's not 'only'.
>
> Therefor
Hi,
i have found this warning in my vanilla 5.15.4 kernel's dmesg log:
[ 87.687139] [ cut here ]
[ 87.710799] WARNING: CPU: 1 PID: 1 at
drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x1c/0x266 [ttm]
[ 87.718965] Modules linked in: nf_nat_ftp nf_conntrack_ftp cfg802
On Mon, 15 Nov 2021 14:19:17 +
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new DMABUF
> based interface.
>
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
> kernel
On Mon, 15 Nov 2021 14:19:14 +
Paul Cercueil wrote:
> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
>
> Th
On Mon, 15 Nov 2021 14:19:13 +
Paul Cercueil wrote:
> We know that the buffer's alignment will always be a power of two;
> therefore, we can use the faster round_down() macro.
>
> Signed-off-by: Paul Cercueil
*groan*. I don't want to know where the naming of these two came from but that
is
On Mon, 15 Nov 2021 14:19:11 +
Paul Cercueil wrote:
> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
>
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much
On Mon, 15 Nov 2021 14:19:10 +
Paul Cercueil wrote:
> Hi Jonathan,
>
> This patchset introduces a new userspace interface based on DMABUF
> objects, to complement the existing fileio based API.
>
> The advantage of this DMABUF based interface vs. the fileio
> interface, is that it avoids an
On Tue, 16 Nov 2021 12:59:30 +0200
Alexandru Ardelean wrote:
> On Mon, Nov 15, 2021 at 4:20 PM Paul Cercueil wrote:
> >
> > From: Alexandru Ardelean
> >
> > A part of the logic in the iio_dma_buffer_exit() is required for the change
> > to add mmap support to IIO buffers.
> > This change splits
Starting from a patch from Matt to_root_gt() returns the
reference to the root tile in order to abstract the root tile
from th callers.
Being the root tile identified as tile '0', embed the id in the
name so that i915->gt becomes i915->gt0.
The renaming has been mostly done with the following com
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
Signed-off-by: Michał Winiarski
Signed-off-by: Matt Roper
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_dri
From: Andi Shyti
Hi,
the first of the two patches concludes the first stage of
refactoring which makes the use of intel_gt on the different
subsystem. It's taken from Matt's series and it has alread been
reviewed. The patch has just been replaced before any multitile
patches and I think it can b
Hi Chris,
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -817,7 +817,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> > * maximum clocks following a vblank miss (see do_rps_boost()).
> > */
> >
Le 21/11/2021 à 11:13, cgel@gmail.com a écrit :
From: yong yiran
The clang_analyzer complains as follows:
drivers/gpu/drm/i915/i915_request.c:2119:2 warning:
Value stored to 'x' is never read
Reported-by: Zeal Robot
Signed-off-by: yong yiran
---
drivers/gpu/drm/i915/i915_request.c | 3
At least the Bay Trail LPSS PWM controller used with DSI panels on many
Bay Trail tablets seems to leave the PWM pin in whatever state it was
(high or low) ATM that the PWM gets disabled. Combined with some panels
not having a separate backlight-enable pin this leads to the backlight
sometimes stay
After the recent refactoring of the backlight code the contents of
intel_panel_actually_set_backlight() is exactly the same (minus a
small wording difference in the drm_dbg_kms() as the contents if the
more widely used intel_backlight_set_pwm_level() function.
Drop the duplicate intel_panel_actual
From: yong yiran
The clang_analyzer complains as follows:
drivers/gpu/drm/i915/i915_request.c:2119:2 warning:
Value stored to 'x' is never read
Reported-by: Zeal Robot
Signed-off-by: yong yiran
---
drivers/gpu/drm/i915/i915_request.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drive
48 matches
Mail list logo
