hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC
VCO to support a core-frequency of 550 MHz which is the minimum
frequency required by the HVS at 4Kp60. The side effect is that if the
display clock requirements are lower than 4Kp60 then you will see
different core frequencies
On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote:
> Hi Stefan,
>
> On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote:
> > Am 30.09.20 um 18:38 schrieb Nathan Chancellor:
> > > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > >> Hi Nathan,
> > >>
> > >>
On Thu, Oct 01 2020 at 10:17, Joonas Lahtinen wrote:
> Quoting paul...@kernel.org (2020-09-29 02:30:58)
>> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
>> removed. Cleanup the leftovers before doing so.
>
> Change looks fine:
>
> Reviewed-by: Joonas Lahtinen
>
> Are you looking
Sorry, my previous statement was misleading.
enable_uart will select the mini_uart for gpio14,15 unless the
disable-bt device tree overlay is loaded. As well as disabling
bluetooth disable-bt swaps the uart0 pin configs to point the regular
UART to gpio 14,15. After resolving the DT overlays the
On 2020-09-29 21:46, Chris Goldsworthy wrote:
On 2020-09-25 21:24, John Stultz wrote:
Reuse/abuse the pagepool code from the network code to speed
up allocation performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc:
Hi Daniel, Dave,
Here's a few fixes for the next merge window
Thanks!
Maxime
drm-misc-next-fixes-2020-10-02:
Three fixes for vc4 that addresses dual-display breakages
The following changes since commit 089d83418914abd4d908db117d9a3eca7f51a68c:
drm/vc4: hvs: Pull the state of all the CRTCs
Hi Tim, thanks for the info!
On Thu, 2020-10-01 at 11:15 +0100, Tim Gover wrote:
> hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC
> VCO to support a core-frequency of 550 MHz which is the minimum
> frequency required by the HVS at 4Kp60. The side effect is that if the
>
> that change, the NULL pointer dereference does not occur:
* Please provide a proper tag “Signed-off-by”.
* How do you think about to add the tag “Fixes” to the commit message?
* Would another imperative wording become helpful for the change description?
* Would you like to choose an other
On Wed, 2020-09-30 at 09:38 -0700, Nathan Chancellor wrote:
> On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > Hi Nathan,
> >
> > On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> > > On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > > > Now
On Thu, Oct 01, 2020 at 11:22:03AM +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-09-30 at 09:38 -0700, Nathan Chancellor wrote:
> > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > > Hi Nathan,
> > >
> > > On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
On Thu, Oct 01, 2020 at 11:22:03AM +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-09-30 at 09:38 -0700, Nathan Chancellor wrote:
> > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > > Hi Nathan,
> > >
> > > On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
Hi Daniel,
On 10/1/20 10:48 AM, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 01:53:46PM +0200, Alexandre Bailon wrote:
This adds a RPMsg driver that implements communication between the CPU and an
APU.
This uses VirtIO buffer to exchange messages but for sharing data, this uses
a dmabuf,
On Thu, Sep 24, 2020 at 05:08:56PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
>
> On 9/18/20 11:59 PM, Maxime Ripard wrote:
> > The HVS has three FIFOs that can be assigned to a number of PixelValves
> > through a mux.
> >
> > However, changing that FIFO requires that we disable and then enable the
On Fri, Oct 2, 2020 at 10:47 AM Christian König
wrote:
>
> This function also works with whole device and not individual BOs.
>
> Signed-off-by: Christian König
This doesn't operate on the device, but on the resource_manager. It's
just stuck using the old api of (bdev, man_type) pairs instead
If more than two jobs end up timeout-ing concurrently, only one of them
(the one attached to the scheduler acquiring the lock) is fully handled.
The other one remains in a dangling state where it's no longer part of
the scheduling queue, but still blocks something in scheduler, leading
to
Crank up the warning a notch and point at the right set of locking
functions for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 10 +-
1 file changed, 5
On Fri, Oct 2, 2020 at 11:07 AM Daniel Vetter wrote:
>
> On Fri, Oct 2, 2020 at 10:47 AM Christian König
> wrote:
> >
> > This function also works with whole device and not individual BOs.
> >
> > Signed-off-by: Christian König
>
> This doesn't operate on the device, but on the
On Fri, Oct 2, 2020 at 10:47 AM Christian König
wrote:
>
> It is the sole user of this.
>
> Signed-off-by: Christian König
Patches 1, 3&4: Acked-by: Daniel Vetter
Patch 1 is maybe a bit big and shouldn't be all smashed, but whatever.
-Daniel
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 11
W dniu 02.10.2020 o 14:31, Greg Kroah-Hartman pisze:
On Tue, Aug 18, 2020 at 01:28:23PM +0200, Andrzej Pietrasiewicz wrote:
This is a follow-up of this thread:
https://www.spinics.net/lists/linux-input/msg68446.html
lore.kernel.org is easier to pull stuff from :)
Anyway, what ever happened
If we don't initialize the entity to idle and the entity is never
scheduled before being destroyed we end up with an infinite wait in the
destroy path.
v2:
- Add Steven's R-b
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
This is something I noticed while debugging another issue
Am 02.10.20 um 08:55 schrieb Boris Brezillon:
If we don't initialize the entity to idle and the entity is never
scheduled before being destroyed we end up with an infinite wait in the
destroy path.
Good catch, of hand I would say that this is valid.
v2:
- Add Steven's R-b
Signed-off-by:
On Fri, Oct 02, 2020 at 02:54:35AM +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP.
>
> BSpec: 21257
>
> Changes since V2 :
> - Added IS_EHL_JSL to replace IS_ELKHARTLAKE
> - EHL/JSL PCI ids split added
> - Changes rebased as per new drm top commit
>
>
On Tue, Aug 18, 2020 at 01:28:23PM +0200, Andrzej Pietrasiewicz wrote:
> This is a follow-up of this thread:
>
> https://www.spinics.net/lists/linux-input/msg68446.html
lore.kernel.org is easier to pull stuff from :)
Anyway, what ever happened to this series? Is there a newer one
somewhere?
On Fri, Oct 2, 2020 at 1:31 PM Christian König
wrote:
>
> Amdgpu was the only user of this.
>
> Signed-off-by: Christian König
Uh this smells like a fishy band-aid. And the original commit
introducing this also doesn't sched any light on why this should
happen, and why it's specific to the
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f542d671ffcec772a561cd41c7e2394392d9dafb
commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon
after HPD in intel_dp_detect()
config: x86_64-randconfig-a003-20201001 (attached as .config)
On Fri, Oct 2, 2020 at 11:48 AM Christian König
wrote:
>
> Am 02.10.20 um 11:16 schrieb Daniel Vetter:
> > On Fri, Oct 2, 2020 at 11:07 AM Daniel Vetter wrote:
> >> On Fri, Oct 2, 2020 at 10:47 AM Christian König
> >> wrote:
> >>> This function also works with whole device and not individual
On Fri, Oct 2, 2020 at 1:30 PM Christian König
wrote:
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >>> Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> On
On Fri, Oct 2, 2020 at 3:47 AM Abhinav Kumar wrote:
>
> Add support to capture the drm atomic state snapshot which
> can then be wired up with the devcoredump of the relevant display
> errors to give useful information to debug the issues.
>
> Since the devcoredump is read by usermode and it is
On Thu, Oct 1, 2020 at 8:02 PM Chrisanthus, Anitha
wrote:
>
> Hi Daniel,
> I was finally able to test the driver with 5.9 kernel with minor changes in
> the driver.
> Ran the igt_vblank test and it passed/skipped all the subtests except the
> pipe-A-accuracy-idle test.
> Results are attached.
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> wrote:
> >
> > Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> > >> Am 30.09.20 um 10:19 schrieb Thomas
On Fri, Oct 02, 2020 at 02:54:34AM +0530, Tejas Upadhyay wrote:
> Split the basic platform definition, macros, and PCI IDs to
> differentiate between EHL and JSL platforms.
>
> Changes since V2 :
> - Added IS_EHL_JSL to replace IS_ELKHARTLAKE
> - EHL/JSL PCI ids split added
> Changes
Quoting Daniel Vetter (2020-10-01 18:13:26)
> On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula
> wrote:
> >
> > On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
> > >>
> > >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> >
On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote:
> >
> > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote:
> > >
> > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote:
> > > >
> > > > From: Rob Clark
> > > >
> > > > The
On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote:
> > >
> > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at 11:16 PM
Drivers can just set the DMA32 flag in their TT creation function.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 6 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c
Amdgpu was the only user of this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
drivers/gpu/drm/ttm/ttm_tt.c| 3 ---
include/drm/ttm/ttm_device.h| 2 --
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git
On Thu, Oct 01, 2020 at 07:28:27PM +0200, Alexandre Bailon wrote:
> Hi Daniel,
>
> On 10/1/20 10:48 AM, Daniel Vetter wrote:
> > On Wed, Sep 30, 2020 at 01:53:46PM +0200, Alexandre Bailon wrote:
> > > This adds a RPMsg driver that implements communication between the CPU
> > > and an
> > > APU.
On 02/10/2020 08:10, Boris Brezillon wrote:
If more than two jobs end up timeout-ing concurrently, only one of them
(the one attached to the scheduler acquiring the lock) is fully handled.
The other one remains in a dangling state where it's no longer part of
the scheduling queue, but still
Hi Alex,
adding Daniel as well.
Am 01.10.20 um 20:45 schrieb Alex Goins:
Hi Christian,
On Thu, 1 Oct 2020, Christian König wrote:
Hi Alex,
first of all accessing the underlying page of an exported DMA-buf is
illegal! So I'm not 100% sure what you're intentions are here, please
explain
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f542d671ffcec772a561cd41c7e2394392d9dafb
commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon
after HPD in intel_dp_detect()
config: x86_64-randconfig-a005-20201001 (attached as .config)
It is the sole user of this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +-
include/drm/ttm/ttm_bo_api.h| 1 -
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git
This function also works with whole device and not individual BOs.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c
We can always access the global state.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 5 +++--
drivers/gpu/drm/ttm/ttm_memory.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
Am 02.10.20 um 11:58 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19
On Fri, 2 Oct 2020 09:10:32 +0200
Boris Brezillon wrote:
> @@ -392,19 +411,41 @@ static void panfrost_job_timedout(struct drm_sched_job
> *sched_job)
> job_read(pfdev, JS_TAIL_LO(js)),
> sched_job);
>
> + /* Scheduler is already stopped, nothing to do. */
> +
If more than two jobs end up timeout-ing concurrently, only one of them
(the one attached to the scheduler acquiring the lock) is fully handled.
The other one remains in a dangling state where it's no longer part of
the scheduling queue, but still blocks something in scheduler, leading
to
Am 02.10.20 um 11:16 schrieb Daniel Vetter:
On Fri, Oct 2, 2020 at 11:07 AM Daniel Vetter wrote:
On Fri, Oct 2, 2020 at 10:47 AM Christian König
wrote:
This function also works with whole device and not individual BOs.
Signed-off-by: Christian König
This doesn't operate on the device, but
On Tue, Sep 29, 2020 at 05:14:31PM +0200, Thomas Zimmermann wrote:
> The parameters map and is_iomem are always of the same value. Removed them
> to prepares the function for conversion to struct dma_buf_map.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
>
On Fri, 2 Oct 2020 10:31:31 +0200
Christian König wrote:
> Am 02.10.20 um 08:55 schrieb Boris Brezillon:
> > If we don't initialize the entity to idle and the entity is never
> > scheduled before being destroyed we end up with an infinite wait in the
> > destroy path.
>
> Good catch, of hand
On Fri, Oct 2, 2020 at 8:41 AM Christian König wrote:
>
> Hi Alex,
>
> adding Daniel as well.
>
> Am 01.10.20 um 20:45 schrieb Alex Goins:
> > Hi Christian,
> >
> > On Thu, 1 Oct 2020, Christian König wrote:
> >
> >> Hi Alex,
> >>
> >> first of all accessing the underlying page of an exported
On Fri, Oct 02, 2020 at 03:42:52PM +0200, Andrzej Pietrasiewicz wrote:
> Hi,
>
> W dniu 02.10.2020 o 14:54, Greg Kroah-Hartman pisze:
> > On Tue, Aug 18, 2020 at 01:28:25PM +0200, Andrzej Pietrasiewicz wrote:
> > > Userland might want to execute e.g. 'w' (show blocked tasks), followed
> > > by
Hi,
W dniu 02.10.2020 o 16:02, Greg Kroah-Hartman pisze:
On Fri, Oct 02, 2020 at 03:42:52PM +0200, Andrzej Pietrasiewicz wrote:
Hi,
W dniu 02.10.2020 o 14:54, Greg Kroah-Hartman pisze:
On Tue, Aug 18, 2020 at 01:28:25PM +0200, Andrzej Pietrasiewicz wrote:
Userland might want to execute e.g.
On Tue, Sep 29, 2020 at 05:14:34PM +0200, Thomas Zimmermann wrote:
> GEM's vmap and vunmap interfaces now wrap memory pointers in struct
> dma_buf_map.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_client.c | 18 +++---
> drivers/gpu/drm/drm_gem.c | 28
On Tue, Sep 29, 2020 at 05:14:35PM +0200, Thomas Zimmermann wrote:
> Kernel DRM clients now store their framebuffer address in an instance
> of struct dma_buf_map. Depending on the buffer's location, the address
> refers to system or I/O memory.
>
> Callers of drm_client_buffer_vmap() receive a
W dniu 02.10.2020 o 14:33, Andrzej Pietrasiewicz pisze:
W dniu 02.10.2020 o 14:31, Greg Kroah-Hartman pisze:
On Tue, Aug 18, 2020 at 01:28:23PM +0200, Andrzej Pietrasiewicz wrote:
This is a follow-up of this thread:
https://www.spinics.net/lists/linux-input/msg68446.html
lore.kernel.org is
Hi Maxime
On Fri, 2 Oct 2020 at 16:19, Maxime Ripard wrote:
>
> Hi Tim,
>
> On Thu, Oct 01, 2020 at 11:15:46AM +0100, Tim Gover wrote:
> > hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC
> > VCO to support a core-frequency of 550 MHz which is the minimum
> > frequency
On Fri, Oct 02, 2020 at 02:45:29PM +0200, Daniel Vetter wrote:
> On Fri, Oct 02, 2020 at 02:36:33PM +0200, Andrzej Pietrasiewicz wrote:
> > W dniu 02.10.2020 o 14:33, Andrzej Pietrasiewicz pisze:
> > > W dniu 02.10.2020 o 14:31, Greg Kroah-Hartman pisze:
> > > > On Tue, Aug 18, 2020 at 01:28:23PM
On Tue, Aug 18, 2020 at 01:28:25PM +0200, Andrzej Pietrasiewicz wrote:
> Userland might want to execute e.g. 'w' (show blocked tasks), followed
> by 's' (sync), followed by 1000 ms delay and then followed by 'c' (crash)
> upon a single magic SysRq. Or one might want to execute the famous "Raising
Hi,
W dniu 02.10.2020 o 14:54, Greg Kroah-Hartman pisze:
On Tue, Aug 18, 2020 at 01:28:25PM +0200, Andrzej Pietrasiewicz wrote:
Userland might want to execute e.g. 'w' (show blocked tasks), followed
by 's' (sync), followed by 1000 ms delay and then followed by 'c' (crash)
upon a single magic
On Fri, Oct 2, 2020 at 2:31 PM Maxime Ripard wrote:
>
> Hi,
>
> On Fri, Oct 02, 2020 at 09:56:20AM +0200, Daniel Vetter wrote:
> > Crank up the warning a notch and point at the right set of locking
> > functions for atomic drivers.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
On Tue, Sep 29, 2020 at 05:14:33PM +0200, Thomas Zimmermann wrote:
> This patch replaces the vmap/vunmap's use of raw pointers in GEM object
> functions with instances of struct dma_buf_map. GEM backends are
> converted as well.
>
> For most GEM backends, this simply change the returned type. GEM
On Fri, Oct 02, 2020 at 02:36:33PM +0200, Andrzej Pietrasiewicz wrote:
> W dniu 02.10.2020 o 14:33, Andrzej Pietrasiewicz pisze:
> > W dniu 02.10.2020 o 14:31, Greg Kroah-Hartman pisze:
> > > On Tue, Aug 18, 2020 at 01:28:23PM +0200, Andrzej Pietrasiewicz wrote:
> > > > This is a follow-up of this
On Fri, Oct 2, 2020 at 11:54 AM Daniel Vetter wrote:
>
> On Fri, Oct 02, 2020 at 10:22:42AM -0700, Rob Clark wrote:
> > On Fri, Oct 2, 2020 at 12:36 AM Daniel Vetter wrote:
> > >
> > > On Fri, Oct 2, 2020 at 3:47 AM Abhinav Kumar
> > > wrote:
> > > >
> > > > Add support to capture the drm
Hi,
On Wed, Sep 30, 2020 at 3:40 PM Bjorn Andersson
wrote:
>
> The TI SN65DSI86 can be configured to generate a PWM pulse on GPIO4,
> to be used to drive a backlight driver.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/gpu/drm/bridge/Kconfig| 1 +
>
On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
link training was failing. Specifically, we'd see:
ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training failed,
link is off (-5)
The panel was hooked up to a logic analyzer and it was found that, as
part
Another round of wack-a-mole. The json-schema default is additional
unknown properties are allowed, but for DT all properties should be
defined.
Cc: Thierry Reding
Cc: Linus Walleij
Cc: Stephen Boyd
Cc: Shawn Guo
Cc: Bjorn Andersson
Cc: Baolin Wang
Cc: Guenter Roeck
Cc: Jonathan Cameron
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-+
Register definitions for Keem Bay display driver
v2: removed license text (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI-> ADV bridge
Only 1080p resolution and single plane is supported at this time.
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7:
v2: Added Maintainer entry
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Bob Paauwe
---
MAINTAINERS | 6 ++
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/kmb/Kconfig | 13 +
On 10/2/20 10:53 AM, Daniel Vetter wrote:
For $reasons I've stumbled over this code and I'm not sure the change
to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
convert get_user_pages() --> pin_user_pages()") was entirely correct.
This here is used for long term buffers (not
Some DSI controllers are missing a reference to the recently added
dsi-controller.yaml schema. Add it and we can drop the duplicate parts.
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Eric Anholt
Cc: Nicolas Saenz Julienne
Cc: Florian Fainelli
Cc: Ray Jui
Cc: Scott Branden
Cc:
On Fri, Oct 2, 2020 at 12:36 AM Daniel Vetter wrote:
>
> On Fri, Oct 2, 2020 at 3:47 AM Abhinav Kumar wrote:
> >
> > Add support to capture the drm atomic state snapshot which
> > can then be wired up with the devcoredump of the relevant display
> > errors to give useful information to debug the
FOLL_WRITE | FOLL_FORCE is really the only reasonable thing to do for
simple dma device that can't guarantee write protection. Which is also
what all the callers are using.
So just simplify this.
Signed-off-by: Daniel Vetter
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
For $reasons I've stumbled over this code and I'm not sure the change
to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
convert get_user_pages() --> pin_user_pages()") was entirely correct.
This here is used for long term buffers (not just quick I/O) like
RDMA, and John notes this
On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote:
> > > >
> > > > On Thu, Oct 1, 2020 at 12:25 AM Daniel
On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_ops test for
On Fri, Oct 2, 2020 at 8:06 PM Jason Gunthorpe wrote:
> On Fri, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote:
> > For $reasons I've stumbled over this code and I'm not sure the change
> > to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> > convert get_user_pages() -->
On Fri, Oct 2, 2020 at 9:23 PM Tomasz Figa wrote:
>
> On Fri, Oct 2, 2020 at 7:53 PM Daniel Vetter wrote:
> >
> > FOLL_WRITE | FOLL_FORCE is really the only reasonable thing to do for
> > simple dma device that can't guarantee write protection. Which is also
> > what all the callers are using.
>
From: Colin Ian King
Currently the check that the unsigned size_t variable i is >= 0
is always true because the unsigned variable will never be negative,
causing the loop to run forever. Fix this by changing the
pre-decrement check to a zero check on i followed by a decrement of i.
On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct access to the
On Tue, Sep 29, 2020 at 05:14:37PM +0200, Thomas Zimmermann wrote:
> Instances of struct dma_buf_map should be useful throughout DRM's
> memory management code. Furthermore, several drivers can now use
> generic fbdev emulation.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
>
Hi Dave and Daniel,
Here goes our first next-fixes. Please be aware this includes
both drm-intel-next and drm-intel-gt-next.
Also, most of patches from drm-intel-gt-next were accumulated
for not being part of current drm-intel-fixes flow while we
are defining the new split and flow.
So, there
On Fri, Oct 2, 2020 at 7:53 PM Daniel Vetter wrote:
>
> FOLL_WRITE | FOLL_FORCE is really the only reasonable thing to do for
> simple dma device that can't guarantee write protection. Which is also
> what all the callers are using.
>
> So just simplify this.
>
> Signed-off-by: Daniel Vetter
>
On Fri, Oct 2, 2020 at 4:01 AM Qais Yousef wrote:
>
> On 09/30/20 14:17, Rob Clark wrote:
> > From: Rob Clark
> >
> > The android userspace treats the display pipeline as a realtime problem.
> > And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> > it is. (See
On Fri, Oct 02, 2020 at 10:22:42AM -0700, Rob Clark wrote:
> On Fri, Oct 2, 2020 at 12:36 AM Daniel Vetter wrote:
> >
> > On Fri, Oct 2, 2020 at 3:47 AM Abhinav Kumar
> > wrote:
> > >
> > > Add support to capture the drm atomic state snapshot which
> > > can then be wired up with the
Hi,
On Wed, Sep 30, 2020 at 3:40 PM Bjorn Andersson
wrote:
>
> While the signal on GPIO4 to drive the backlight controller indeed is
> pulse width modulated its purpose is specifically to control the
> brightness of a backlight.
I'm a bit on the fence about this. I guess you're doing this
> -Original Message-
> From: Daniel Vetter
> Sent: Friday, October 2, 2020 2:19 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J
> ; Dea, Edmund J ;
> Vetter, Daniel
> Subject: Re: [PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
>
> On Thu,
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc:
Hi, Jassi:
Jassi Brar 於 2020年10月3日 週六 上午4:30寫道：
>
> On Sun, Sep 27, 2020 at 6:04 PM Chun-Kuang Hu wrote:
> >
> > CMDQ helper provide timer to detect execution timeout, but DRM driver
> > could have a better way to detect execution timeout by vblank IRQ.
> > For DRM, CMDQ command should execute
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops
Hey All,
So this is another revision of my patch series to performance
optimizations to the dma-buf system heap.
Unfortunately, in working these up, I realized the heap-helpers
infrastructure we tried to add to miniimize code duplication is
not as generic as we intended. For some heaps it makes
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc:
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc:
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices,
98 matches
Mail list logo
