Hi Daniel,
Thank you for the patch.
On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. s
A fair number of includes are not needed. Drop them, and add a couple of
required includes that were included indirectly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 +++-
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 -
2 files ch
The LCDIF present in the i.MX6SX has extra features compared to
the i.MX28. It has however lost its IP version register, so no official
version number is known. Bump the version to MXSFB_V6 following the i.MX
version, in preparation for support for the additional features.
Signed-off-by: Laurent P
The mxsfb driver is only used by OF platforms. Drop non-OF support.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b
The debug0 and ipversion fields of the mxsfb_devdata structure are
unused. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/d
The mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() functions both deal
with format configuration, are always called in a row from
mxsfb_crtc_mode_set_nofb(), and set fields from the LCDC_CTRL register.
This requires a read-modify-update cycle in mxsfb_set_bus_fmt(). Make
this more efficient by mergi
The mxsfb_set_pixel_fmt() function returns an error when the selected
pixel format is unsupported. This can never happen, as such errors are
caught by the DRM core. Remove the error check.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 11 ++---
The mxsfb_crtc.c file doesn't handle just the CRTC, but also the other
KMS objects. Rename it accordingly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/Makefile | 2 +-
drivers/gpu/drm/mxsfb/{mxsfb_crtc.c => mxsfb_kms.c} | 0
2 files c
Replace the manual connector implementation based on drm_panel with the
drm_panel_bridge helper. This simplifies the mxsfb driver by removing
connector-related code, and standardizing all pipeline control
operations on bridges.
A hack is needed to get hold of the connector, as that's our only sour
The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
plane. Support it.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Split whitespace cleanup to a separate patch
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 6 +-
drivers/gp
This is a cosmetic change only, no code change is included.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index 607a6a5e6b
Using BIT() is preferred over manual shifts as it's more readable,
handles the 1 << 31 case properly, and avoids other mistakes as shown by
the DEBUG0_HSYNC and DEBUG0_VSYNC bits (that are currently unused). Use
it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/m
The LCDC_CTRL register is located at address 0x. Some of the
accesses to the register simply use the mxsfb->base address. Reference
the LCDC_CTRL register explicitly instead to clarify the code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c
mxsfb_crtc.c defines several macros related to register addresses and
bit, which duplicates macros from mxsfb_regs.h. Use the macros from
mxsfb_regs.h instead and remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 14 +-
1
mxsfb_regs.h defines macros related to register bits. Some of them are
not used and don't clearly map to any particular register, so their
purpose isn't known. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 8
1 file chan
The driver attempts agressive power management by enabling and disabling
the AXI clock around register accesses. This results in attempts to
enable and disable the clock in the IRQ handler, which is a no-go as
preparing or unpreparing the clock may sleep.
On the other hand, the driver enables the
The DRM simple display pipeline helper only supports a single plane. In
order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
move away from the helper. No new feature is added.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Move after mxsfb_crtc.c rename to mxsfb_kms.c
Extend the Kconfig option description by listing the i.MX7 and i.MX8M
SoCs, as they are supported by the same driver. Replace the list of SoCs
in the short description with just "(e)LCDIF LCD controller" to avoid
expanding it further in the future as support for more SoCs is added.
Signed-off-by:
Hello,
This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
instance found in the i.MX7 is backward-compatible with the already
supported LCDC v4, but has extended features amongst which the most
notable one is a second plane.
The first 10 patches (01/22 to 10/22) contain miscella
Commit 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
replaced fbdev handling with drm_fbdev_generic_setup() but left
inclusion of the drm/drm_fb_cma_helper.h header. Remove it.
Fixes: 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
Signed-off-by: Laurent Pinchart
Reviewed-by
Replace the convoluted way to set the format and bus width through
difficult to read macros with more explicit ones. Also remove the
outdated comment related to the limitations on bus width setting as it
doesn't apply anymore (the bus width can be specified through the
display_info bus format).
Si
Enable vblank handling when the CRTC is turned on and disable it when it
is turned off. This requires moving vblank init after the KMS pipeline
initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
The vblank event is armed in the plane .atomic_update(). This works fine
as we have a single plane, and was the only option when the driver was
using the drm_simple_kms_helper helper, but will break as soon as
multiple planes are supported. Move it to CRTC .atomic_flush().
Signed-off-by: Laurent P
The mxsfb_reset_block() function isn't special, pass it the
mxsfb_drm_private pointer instead of a pointer to the base address.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
di
Hi Stefan,
On Tue, Mar 24, 2020 at 12:48:17AM +0100, Stefan Agner wrote:
> On 2020-03-09 20:52, Laurent Pinchart wrote:
> > The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
> > plane. Support it.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/mxsfb/mx
Hi Stefan,
On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
> On 2020-03-09 20:51, Laurent Pinchart wrote:
> > Replace the manual connector implementation based on drm_panel with the
> > drm_panel_bridge helper. This simplifies the mxsfb driver by removing
> > connector-related code,
Hi Stefan,
On Mon, Mar 23, 2020 at 10:53:50PM +0100, Stefan Agner wrote:
> On 2020-03-09 20:52, Laurent Pinchart wrote:
> > A fair number of includes are not needed. Drop them, and add a couple of
> > required includes that were included indirectly.
> >
> > Signed-off-by: Laurent Pinchart
>
> O
Hi Stefan,
On Tue, May 26, 2020 at 05:13:42PM +0200, Stefan Agner wrote:
> On 2020-03-09 20:51, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
> > instance found in the i.MX7 is backward-compatible with the already
> > supported LCD
Hi Noralf,
Noralf Trønnes wrote:
> This adds a generic USB display driver with the intention that it can be
> used with future USB interfaced low end displays/adapters.
Fun!
> The Linux gadget device driver will serve as the canonical device
> implementation.
That's a great goal, but as propos
Hi Laurent,
On Wed, 2020-05-27 at 15:45:24 -0700, Laurent Pinchart wrote:
> Hi Hyun,
>
> On Wed, May 27, 2020 at 10:54:35AM -0700, Hyun Kwon wrote:
> > On Sat, 2020-05-23 at 20:08:13 -0700, Laurent Pinchart wrote:
> > > On Mon, May 04, 2020 at 11:43:48AM -0700, Hyun Kwon wrote:
> > >> On Mon, 202
The variables are already the exact same value or will be overwritten
shortly afterwords. In either case there's no functional difference.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_auth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
The function always returns zero (success). Ideally we'll remove it all
together - although that's requires a little more work.
For now, we can drop the return type and simplify the drm core code
surrounding it.
Cc: David Airlie
Cc: Daniel Vetter
Cc: VMware Graphics
Cc: Roland Scheidegger
Sig
Quoting Arnd Bergmann (2020-05-29 21:43:47)
> On Fri, May 29, 2020 at 10:26 PM Chris Wilson
> wrote:
> > Quoting Arnd Bergmann (2020-05-29 21:15:26)
>
> > >
> > > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
> > > b/drivers/gpu/drm/selftests/test-drm_mm.c
> > > index 9aabe82dcd3a..30108
Hi Logan,
On 29.05.2020 21:05, Logan Gunthorpe wrote:
> On 2020-05-29 6:45 a.m., Christoph Hellwig wrote:
>> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
This issue is most likely in the i915 driver and is most likely caused by
the driver not respecting the return va
The pull request you sent on Fri, 29 May 2020 12:37:51 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-29-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/86e43b8bf0e6b3897e504cdb9230fd063ecd4452
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
On 5/29/20 5:52 PM, Chris Wilson wrote:
Quoting Nirmoy (2020-05-29 16:40:53)
This works correctly most of the times but sometimes
I have to take my word back. In another machine, 20k insertions in
best mode takes 6-9 times more than 10k insertions, all most all the time.
evict, bottom-up
On Fri, May 29, 2020 at 10:26 PM Chris Wilson wrote:
> Quoting Arnd Bergmann (2020-05-29 21:15:26)
> >
> > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
> > b/drivers/gpu/drm/selftests/test-drm_mm.c
> > index 9aabe82dcd3a..30108c330db8 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_m
Quoting Arnd Bergmann (2020-05-29 21:15:26)
> The check_reserve_boundaries() function has a large array on the stack,
> over 500 bytes. It gets inlined into __igt_reserve, which has multiple
> other large structures as well but stayed just under the stack size
> warning limit of 1024 bytes until on
The check_reserve_boundaries() function has a large array on the stack,
over 500 bytes. It gets inlined into __igt_reserve, which has multiple
other large structures as well but stayed just under the stack size
warning limit of 1024 bytes until one more member got added to struct
drm_mm_node, causi
On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> bindings, especially since the registers have been shuffled around in more
> register ranges.
>
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Signed
drm_client_init_from_id() provides a way for clients to add a client based
on the minor. drm_client_register() is changed to return whether it was
registered or not depending on the unplugged status of the DRM device.
Its only caller drm_fbdev_generic_setup() runs inside probe() so it
doesn't have
Since the USB gadget/device has to reach into the DRM internals, part of
the code is placed in the DRM subsystem as a separate module. All calls
into this module runs in process context and are serialized, except one
function that runs in interrupt context.
Since both the gadget side and the DRM s
This adds a generic USB display driver with the intention that it can be
used with future USB interfaced low end displays/adapters. The Linux
gadget device driver will serve as the canonical device implementation.
The following DRM properties are supported:
- Plane rotation
- Connector TV properti
This adds the gadget side support for the Generic USB Display. It presents
a DRM display device as a USB Display configured through configfs.
The display is implemented as a vendor type USB interface with one bulk
out endpoint. The protocol is implemented using control requests.
lz4 compressed fra
Hi,
A while back I had the idea to turn a Raspberry Pi Zero into a $5
USB to HDMI/SDTV/DSI/DPI display adapter.
This series adds a USB host driver and a device/gadget driver to achieve
that.
The reason for calling it 'Generic' is so anyone can make a USB
display/adapter against this driver, all
This adds functions for clients that need more control over the
configuration than what's setup by drm_client_modeset_probe().
Connector, fb and display mode can be set using drm_client_modeset_set().
Plane rotation can be set using drm_client_modeset_set_rotation() and
other properties using drm_c
Add a way for clients to disable all outputs.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client_modeset.c | 20
include/drm/drm_client.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm
On Fri, May 29, 2020 at 6:44 AM Rohan Garg wrote:
>
> Hey Eric!
>
> On jueves, 28 de mayo de 2020 20:45:24 (CEST) Eric Anholt wrote:
> > On Thu, May 28, 2020 at 10:06 AM Rohan Garg
> wrote:
> > > DRM_IOCTL_HANDLE_SET_LABEL lets you label buffers associated
> > > with a handle, making it easier to
This patch adds the following properties for Exynos4412 interconnect
bus nodes:
- samsung,interconnect-parent: to declare connections between
nodes in order to guarantee PM QoS requirements between nodes;
- #interconnect-cells: required by the interconnect framework.
Note that #interconnect-c
Add documentation for new optional properties in the exynos bus nodes:
samsung,interconnect-parent, #interconnect-cells.
These properties allow to specify the SoC interconnect structure which
then allows the interconnect consumer devices to request specific
bandwidth requirements.
Signed-off-by: A
From: Artur Świgoń
This patch adds an 'interconnects' property to Exynos4412 DTS in order to
declare the interconnect path used by the mixer. Please note that the
'interconnect-names' property is not needed when there is only one path in
'interconnects', in which case calling of_icc_get() with a
This patch adds a generic interconnect driver for Exynos SoCs in order
to provide interconnect functionality for each "samsung,exynos-bus"
compatible device.
The SoC topology is a graph (or more specifically, a tree) and its
edges are specified using the 'samsung,interconnect-parent' in the
DT. Du
This patch adds registration of a child platform device for the exynos
interconnect driver. It is assumed that the interconnect provider will
only be needed when #interconnect-cells property is present in the bus
DT node, hence the child device will be created only when such a property
is present.
This patchset adds interconnect API support for the Exynos SoC "samsung,
exynos-bus" compatible devices, which already have their corresponding
exynos-bus driver in the devfreq subsystem. Complementing the devfreq driver
with an interconnect functionality allows to ensure the QoS requirements
o
From: Marek Szyprowski
This patch adds interconnect support to exynos-mixer. The mixer works
the same as before when CONFIG_INTERCONNECT is 'n'.
For proper operation of the video mixer block we need to ensure the
interconnect busses like DMC or LEFTBUS provide enough bandwidth so
as to avoid DMA
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it woul
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due t
On Wed, 27 May 2020 15:27:28 +0800, dillon.min...@gmail.com wrote:
> From: dillon min
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min
> ---
> .../bindings/display/panel/ilitek,ili9341.yaml | 69
> ++
> 1 file changed, 69 insertions(+)
>
Quoting Nirmoy (2020-05-29 16:40:53)
> This works correctly most of the times but sometimes
>
> 20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
> Regards,
>
> Nirmoy
>
> On 5/29/20 6:33 PM, Nirmoy Das wrote:
> > This patch introduces fragm
Hi Adrian,
and thank you very much for the patchset.
Thank you also for having tested it on STM32F769 and STM32MP1.
Sorry for the late response, Yannick and I will review it as soon as
possible and we will keep you posted.
Note: Do not hesitate to put us in copy for the next version
(philippe.co.
This works correctly most of the times but sometimes
20k insertions can take more than 8 times of 10k insertion time.
Regards,
Nirmoy
On 5/29/20 6:33 PM, Nirmoy Das wrote:
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
wi
On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote:
>
> On Fri, 29 May 2020 at 15:36, Alex Deucher wrote:
> > On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote:
> > > On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
> > > > Maybe I'm over thinking this. I just don't want to get into a
> >
Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 118 +
1 file changed, 88 insertions(
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 c
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 53 ++-
1 file changed, 35 insertions(+), 18 del
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 25 +++--
1 file changed, 23 insertions(+), 2 deleti
Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing
register.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_registers.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_registers.
Setup the Amlogic FBC decoder for the VD1 video overlay plane.
The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.
This adds support for the basic layout, and needs to calculate the content
body size since the he
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 c
On Fri, 29 May 2020 at 15:36, Alex Deucher wrote:
> On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote:
> > On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
> > > Maybe I'm over thinking this. I just don't want to get into a
> > > situation where we go through a lot of effort to add modifier
On Fri, May 29, 2020 at 11:49:12AM +, Luis Chamberlain wrote:
> Yikes, sense, you're right. Nope, I left the random config tests to
> 0day. Will fix, thanks!
Yeah, I do the same for randconfig, but I always do an "allmodconfig"
build before sending stuff. It's a good smoke test.
--
Kees Cook
On Fri, 29 May 2020 16:05:42 +0200
Daniel Vetter wrote:
> - Ditch the ->pages array
> - Make it a private gem bo, which means no shmem object, which means
> fireworks if anyone calls drm_gem_object_get_pages. But we've just
> made sure that's all covered.
>
> v2: Rebase
>
> v3: I forgot to
On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote:
>
> On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
> > Maybe I'm over thinking this. I just don't want to get into a
> > situation where we go through a lot of effort to add modifier support
> > and then performance ends up being worse than
On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
> Maybe I'm over thinking this. I just don't want to get into a
> situation where we go through a lot of effort to add modifier support
> and then performance ends up being worse than it is today in a lot of
> cases.
I'm genuinely curious: what d
On Fri, May 29, 2020 at 9:58 AM Daniel Stone wrote:
>
> Hi Alex,
>
> On Fri, 29 May 2020 at 14:29, Alex Deucher wrote:
> > On Fri, May 29, 2020 at 4:59 AM Simon Ser wrote:
> > > OK. In this case I think it's fine to make the DMA-BUF import fail, as
> > > we've suggested on IRC. The more-or-less
On Fri, May 29, 2020 at 3:49 AM Pekka Paalanen wrote:
>
> On Thu, 28 May 2020 17:46:08 +0800
> Chih-Wei Huang wrote:
>
> > The main problem we're trying to solve is to
> > find the DRM device of the primary framebuffer (fb0).
>
> Hi,
>
> I would say that is a completely wrong starting point. Plea
Am 29.05.20 um 16:09 schrieb Chris Wilson:
Quoting Nirmoy Das (2020-05-29 15:04:01)
Fixes: 0cdea4455acd350a ("drm/mm: optimize rb_hole_addr rbtree search")
Hmm. Indeed. Now, do you have a test case on your end that hits this?
No, I just got time to double read through this and stumbled over i
Quoting Nirmoy Das (2020-05-29 15:04:01)
> Fixes: 0cdea4455acd350a ("drm/mm: optimize rb_hole_addr rbtree search")
Hmm. Indeed. Now, do you have a test case on your end that hits this?
One of us should add one for drm-mm.
-Chris
___
dri-devel mailing lis
- Ditch the ->pages array
- Make it a private gem bo, which means no shmem object, which means
fireworks if anyone calls drm_gem_object_get_pages. But we've just
made sure that's all covered.
v2: Rebase
v3: I forgot to remove the page_count mangling from the free path too.
Noticed by Boris wh
Hi Alex,
On Fri, 29 May 2020 at 14:29, Alex Deucher wrote:
> On Fri, May 29, 2020 at 4:59 AM Simon Ser wrote:
> > OK. In this case I think it's fine to make the DMA-BUF import fail, as
> > we've suggested on IRC. The more-or-less planned fix for these buffer
> > sharing issues is to revive the b
On Mon, 11 May 2020 11:35:45 +0200
Daniel Vetter wrote:
> Hi all,
>
> I've started this a while ago, with the idea to move shmem helpers over
> to dma_resv_lock. Big prep work for that was to untangle the layering
> between functions called by drivers, and functions used to implement
> drm_gem_o
On Wed, 20 May 2020 20:02:32 +0200
Daniel Vetter wrote:
> @@ -695,36 +702,16 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> struct sg_table *sgt)
> {
> size_t size = PAGE_ALIGN(attach->dmabuf->size);
> - size_t npages = size >> PA
Hey Eric!
On jueves, 28 de mayo de 2020 20:45:24 (CEST) Eric Anholt wrote:
> On Thu, May 28, 2020 at 10:06 AM Rohan Garg
wrote:
> > DRM_IOCTL_HANDLE_SET_LABEL lets you label buffers associated
> > with a handle, making it easier to debug issues in userspace
> > applications.
> >
> > DRM_IOCTL_H
On Fri, May 29, 2020 at 3:29 PM Alex Deucher wrote:
>
> On Fri, May 29, 2020 at 4:59 AM Simon Ser wrote:
> >
> > On Thursday, May 28, 2020 5:49 PM, Marek Olšák wrote:
> >
> > > On most hardware, there is a minimum pitch alignment for linear and
> > > any greater multiple of the alignment is fine
On Fri, 29 May 2020 15:34:28 +0200
Boris Brezillon wrote:
> Hi Daniel,
>
> On Wed, 20 May 2020 20:02:32 +0200
> Daniel Vetter wrote:
>
> > - Ditch the ->pages array
> > - Make it a private gem bo, which means no shmem object, which means
> > fireworks if anyone calls drm_gem_object_get_pages
Hi Daniel,
On Wed, 20 May 2020 20:02:32 +0200
Daniel Vetter wrote:
> - Ditch the ->pages array
> - Make it a private gem bo, which means no shmem object, which means
> fireworks if anyone calls drm_gem_object_get_pages. But we've just
> made sure that's all covered.
>
> v2: Rebase
>
> Acke
On Fri, May 29, 2020 at 12:15:27PM +1000, Dave Airlie wrote:
> On Fri, 29 May 2020 at 12:02, Dave Airlie wrote:
> >
> > On Fri, 29 May 2020 at 11:49, Linus Torvalds
> > wrote:
> > >
> > > On Thu, May 28, 2020 at 5:21 PM Dave Airlie wrote:
> > > >
> > > > Seems to have wound down nicely, a couple
On Fri, May 29, 2020 at 4:59 AM Simon Ser wrote:
>
> On Thursday, May 28, 2020 5:49 PM, Marek Olšák wrote:
>
> > On most hardware, there is a minimum pitch alignment for linear and
> > any greater multiple of the alignment is fine.
> >
> > On Navi, the pitch in bytes for linear must be
> > align(
https://bugzilla.kernel.org/show_bug.cgi?id=207833
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On 29/05/2020 13:35, Clément Péron wrote:
Hi Robin,
On Fri, 29 May 2020 at 14:20, Robin Murphy wrote:
On 2020-05-10 17:55, Clément Péron wrote:
Convert busy_count to a simple int protected by spinlock.
A little more reasoning might be nice.
I have follow the modification requested for li
On 2020-05-10 17:55, Clément Péron wrote:
Convert busy_count to a simple int protected by spinlock.
A little more reasoning might be nice.
Signed-off-by: Clément Péron
---
[...]
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 06
On Fri, May 29, 2020 at 11:13:21AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Luis Chamberlain wrote:
> > Often enough all we need to do is create a subdirectory so that
> > we can stuff sysctls underneath it. However, *if* that directory
> > was already created early on the boot sequence we
On Fri, May 29, 2020 at 12:26:13PM +0200, Greg KH wrote:
> On Fri, May 29, 2020 at 07:41:04AM +, Luis Chamberlain wrote:
> > From: Xiaoming Ni
> >
> > Move the firmware config sysctl table to fallback_table.c and use the
> > new register_sysctl_subdir() helper. This removes the clutter from
>
On Wed, 27 May 2020 11:47:57 +0200
Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a s
On Wed, May 27, 2020 at 11:47:57AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms a
On Fri, May 29, 2020 at 12:47:26PM +0100, Ben Davis wrote:
> DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
Is there a specific modifier for this 16x16 block linear format? Feels a
bit confusing, would be great to add that to the commit message so usage
is clearer. We have DRM_F
On Fri, May 29, 2020 at 01:23:19AM -0700, Kees Cook wrote:
> On Fri, May 29, 2020 at 07:41:01AM +, Luis Chamberlain wrote:
> > This simplifies the code considerably. The following coccinelle
> > SmPL grammar rule was used to transform this code.
> >
> > // pycocci sysctl-subdir.cocci fs/ocfs2/
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts. The format is similar to P010 with 4:2:0
sub-sampling but has no padding between components. Instead, luminance
and chrominance samples are grouped into 4s so that each group is packed
into an integer num
On Wed, May 27, 2020 at 02:02:12PM +0200, Thomas Zimmermann wrote:
>
> Am 27.05.20 um 13:11 schrieb Daniel Vetter:
> > For historical reasons it's called dev->num_crtcs, which is rather
> > confusing ever since kms was added. But now we have a nice helper, so
> > let's use it for better readabilit
On Thu, May 28, 2020 at 03:38:35PM +0200, Rohan Garg wrote:
> Introduce tests to cover the new generic labeling ioctl's
> being reviewed here [1].
>
> Signed-off-by: Rohan Garg
>
> [1] https://patchwork.freedesktop.org/series/77267/
>
> Signed-off-by: Rohan Garg
> ---
> include/drm-uapi/drm.h
1 - 100 of 130 matches
Mail list logo
