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,
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Andrew F. Davis
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: linux-me...@vger.kernel.org
Cc:
On Wed, 29 Jul 2020 at 15:05, Nick Bowler wrote:
>
> Hi,
>
> After installing Linux 5.8-rc7 I seem to get no video output on my
> NV36 card once the nouveau module is loaded. The display (connected
> to the digital output) simply reports "No Signal".
>
> I bisected to the following commit, and
Hi Linus,
I'm sending this out a bit early, just to give you a chance to reject
it or help decide on an rc8.
The nouveau fixes missed the last pull by a few hours, and we had a
few arm driver/panel/bridge fixes come in. This is possibly a bit more
than I'm comfortable sending at this stage, but
On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote:
>
> On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
> >
> > On 7/23/20 9:06 PM, Ben Skeggs wrote:
> > > On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
> > >>
> > >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> > >> family of modifiers to
On Tue, 28 Jul 2020 at 04:51, James Jones wrote:
>
> On 7/23/20 9:06 PM, Ben Skeggs wrote:
> > On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
> >>
> >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> >> family of modifiers to handle broken userspace
> >> Xorg modesetting and Mesa drivers.
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #106 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #101)
> (In reply to Nicholas Kazlauskas from comment #95)
> > Created attachment 290583 [details]
> >
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on soc/for-next xlnx/master linus/master v5.8-rc7
next-20200728]
[cannot apply to mripard/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop
Hello,
On Tue, Jul 28, 2020 at 03:35:43PM -0700, Laurent Pinchart wrote:
> On Wed, Jul 29, 2020 at 12:02:05AM +0200, dan...@ffwll.ch wrote:
> > Hi Hyun Kwon,
> >
> > Are you all sorted with drm-misc commit rights so you can push the 3
> > (maybe there's more) xlnx fixup patches to
On Tue, 28 Jul 2020 at 17:49, Christian König wrote:
>
> Am 28.07.20 um 06:17 schrieb Dave Airlie:
> > From: Dave Airlie
> >
> > This is confusing, and from my reading of all the drivers only
> > nouveau got this right.
> >
> > Just make the API act under driver control of it's own allocation
>
On Tue, 28 Jul 2020 at 17:49, Christian König wrote:
>
> Am 28.07.20 um 06:51 schrieb Dave Airlie:
> > From: Dave Airlie
> >
> > This was removed in
> > f5a9a9383f279de9da63296cb623a6418a66196b drm/ttm: remove
> > TTM_MEMTYPE_FLAG_CMA
> >
> > but the the declaration was left dangling.
> >
> >
> On Jul 27, 2020, at 11:42 PM, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yea, it really should. This code is
On Tue, Jul 28, 2020 at 11:05 AM Rob Herring wrote:
>
> On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan
> wrote:
> >
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It
Hi Christoph,
On Tue, Jul 28, 2020 at 8:33 AM Christoph Hellwig wrote:
>
> A few tiny nitpicks:
>
> The subject should have the dma-mapping prefix, this doesn't
> really touch the device core.
>
> > - rc = of_dma_get_range(np, _addr, , );
> > + rc = of_dma_get_range(np, );
> > + rc =
Hi Colin,
Thank you for the patch.
On Fri, Jul 24, 2020 at 12:12:58PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_dbg messages. Fix it.
There is a spelling mistake in the commit message, s/xln/xlnx/ ;-)
> Signed-off-by: Colin Ian King
On Wed, Jul 29, 2020 at 12:02:05AM +0200, dan...@ffwll.ch wrote:
> Hi Hyun Kwon,
>
> Are you all sorted with drm-misc commit rights so you can push the 3
> (maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Thanks Daniel for bringing this up.
Hyun, would that work for you ?
> On
Hi Wei,
Thank you for the patch.
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
> Subsystem")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
Hi Randy,
(adding a few people to the CC list to discuss the proposed solution
below)
Thanks for the report.
On Mon, Jul 27, 2020 at 05:49:41PM -0700, Randy Dunlap wrote:
> On 7/27/20 6:23 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200724:
>
> on x86_64:
>
> WARNING:
Hi Hyun Kwon,
Are you all sorted with drm-misc commit rights so you can push the 3
(maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Cheers, Daniel
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d76271d22694 ("drm:
On Tue, Jul 28, 2020 at 10:17:36PM +0200, Sam Ravnborg wrote:
> Hi Paul.
>
> On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote:
> > Here are a few cleanups to the ingenic-drm driver.
> > - some error paths were missing and have been added;
> > - the mode validation has been moved to
On Tue, Jul 28, 2020 at 01:07:13PM -0400, Kazlauskas, Nicholas wrote:
> On 2020-07-28 5:22 a.m., Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > Am 25.07.20 um 07:20 schrieb Mazin Rezk:
> > > On Saturday, July 25, 2020 12:59 AM, Duncan wrote:
> > >
> > > > On Sat, 25 Jul 2020 03:03:52
On Tue, Jul 28, 2020 at 04:16:34PM +, Sidong Yang wrote:
> On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote:
> > On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote:
> > >
> > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote:
> > > >
> > > > > No, this very first warning
On Tue, Jul 28, 2020 at 12:08 PM Kevin Tang wrote:
>
> From: Kevin Tang
>
> Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
> It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>
> RFC v6:
> - Access registers via readl/writel
> - Checking
Revamp the way that the flow of data to the display is
defined.
I realized that the hardware supports something like
5 different modes of flow: oneshot, command with TE IRQ,
command with BTA (bus turn around) and TE IRQ, video
with TE IRQ and video without TE IRQ instead synchronizing
to the
The function mcde_display_send_one_frame() has a historical
name that stems from being implemented when the driver
only supported single frame updates.
Rename it mcde_start_flow() so that it reflects the current
usage.
Cc: Stephan Gerhold
Signed-off-by: Linus Walleij
---
Hi Kevin.
Thanks for submitting this set of drivers.
To better review the pataches can you please give some kind of high
level overview.
An ascii block diagram that identifies all the relevant blocks and how
they relate would be great.
This makes it easier to verify if the right modelling is
Hi Kevin.
Some feedback in the following.
I lost track of thing for the atomic modesettting stuff and I hope other
will review that.
Sam
On Tue, Jul 28, 2020 at 06:07:57PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> Adds DPU(Display Processor Unit) support for the Unisoc's display
Hi Kevin.
On Tue, Jul 28, 2020 at 06:07:56PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
> which transfers the image data from a video memory buffer to an internal
> LCD interface.
>
> Cc: Orson Zhai
> Cc: Chunyan
Hi Kevin.
Nice split of the driver.
Some feedback in the following.
Most to bring the driver up-to-date with what have happened since
we saw it last time.
Keeping up with the changes in drm is not always easy.
Sam
On Tue, Jul 28, 2020 at 06:07:55PM +0800, Kevin Tang wrote:
> From:
>-Original Message-
>From: Ben Skeggs
>Sent: Tuesday, July 28, 2020 4:16 PM
>To: Ruhl, Michael J
>Cc: Dave Airlie ; dri-devel@lists.freedesktop.org;
>bske...@redhat.com
>Subject: Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>
>On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael
Hi Kevin
On Tue, Jul 28, 2020 at 06:07:54PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
>
Hi Paul.
On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote:
> Here are a few cleanups to the ingenic-drm driver.
> - some error paths were missing and have been added;
> - the mode validation has been moved to the .mode_valid helper callback.
>
> Cheers,
> -Paul
>
> Paul Cercueil
On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael J wrote:
>
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Dave Airlie
> >Sent: Monday, July 27, 2020 11:26 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: bske...@redhat.com
> >Subject: [PATCH] nouveau: use ttm populate mapping
Hi,
On 7/28/20 9:36 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with
Hi,
On 7/28/20 8:57 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone
Hi,
On 7/28/20 8:45 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code.
On Tue, Jul 28, 2020 at 06:12:46PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 27/07/2020 10:13, Roger Pau Monne wrote:
> > > > To be used in order to create
The Powertip Tech. Corp. is an LCD panel manufacturer.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
V2: No change
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
> Before this commit a suspend + resume of the LPSS PWM controller
> would result in the controller being reset to its defaults of
> output-freq = clock/256, duty-cycle=100%, until someone changes
> to the output-freq and/or duty-cycle
Unlike we previously thought, the per-pixel alpha is just as broken on the
A20 as it is on the A10. Remove the quirk that says we can use it.
Cc: Paul Kocialkowski
Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
alpha support")
Signed-off-by: Maxime Ripard
---
Unlike what we previously thought, only the per-pixel alpha is broken on
the lowest plane and the per-plane alpha isn't. Remove the check on the
alpha property being set on the lowest plane to reject a mode.
Cc: Paul Kocialkowski
Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for
On Tue, Jul 28, 2020 at 12:35:17PM +, David Laight wrote:
> From: Peilin Ye
> > Sent: 28 July 2020 12:52
> > Currently `struct drm_buf_desc` is defined as follows:
> >
> > struct drm_buf_desc {
> > int count;
> > int size;
> > int low_mark;
> > int high_mark;
> > enum {
>
From: Jitao Shi
[Detail]
dpi/dsi get the possible_crtc by
mtk_drm_find_possible_crtc_by_comp(*drm_dev, ddp_comp)
Test: build pass and boot to logo
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
2 files changed, 4
On Tue, Jul 28, 2020 at 10:11:09AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 28, 2020 at 3:45 AM Peilin Ye wrote:
> >
> > copy_one_buf() is copying uninitialized stack memory to userspace due to
> > the compiler not initializing holes in statically allocated structures.
> > Fix it by initializing
From: Bibby Hsieh
We can select output component by decive node port.
Main path default output component is DSI.
External path default output component is DPI.
without this Patch i get this warning:
WARNING: CPU: 3 PID: 70 at drivers/gpu/drm/drm_mode_config.c:621
Validate modes in the drm_crtc_helper_funcs.mode_valid() callback, which
is designed for this purpose, instead of doing it in
drm_crtc_helper_funcs.atomic_check().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +--
1 file changed, 20
Hi Roger,
On 28/07/2020 17:59, Roger Pau Monné wrote:
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory
From: chunhui dai
- disable tmds on phy on mt2701
- support other resolutions like 1280x1024
without this Patch i see flickering on my TFT (1280x1024),
so i guess clock is wrong.
Signed-off-by: chunhui dai
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
Add support for Powertip PH800480T013 800x480 parallel LCD, this
one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
V2: Add bus_flags
On Tue, Jul 28, 2020 at 06:06:25PM +0100, Andrew Cooper wrote:
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> >> Hi,
> >>
> >> On 27/07/2020 10:13, Roger Pau Monne wrote:
> >>> To be used in order to create foreign mappings. This
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on
From: Stu Hsieh
Test: build pass and run ok
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
From: Peilin Ye
> Sent: 28 July 2020 12:52
> Currently `struct drm_buf_desc` is defined as follows:
>
> struct drm_buf_desc {
> int count;
> int size;
> int low_mark;
> int high_mark;
> enum {
> _DRM_PAGE_ALIGN = 0x01,
> _DRM_AGP_BUFFER =
Dear Linux folks,
Am 25.07.20 um 07:20 schrieb Mazin Rezk:
On Saturday, July 25, 2020 12:59 AM, Duncan wrote:
On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote:
Am 24.07.20 um 19:33 schrieb Kees Cook:
There was a fix to disable the async path for this driver that
worked around the bug
Hi Emil,
Sorry, I left for a long time because of other things. Now i'm back~
V6 fix access registers via readl/writel, check unsupported KMS
properties (format, rotation, blend mode, etc) by plane_check callback
ops
and remove always true checks for dpu core ops
Add changelog within the
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
> In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
> runtime-pm reference; and then on any errors it needs to release it
> again.
>
> This leads to somewhat hard to read code. This commit introduces a new
>
From: Kevin Tang
Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dphy.yaml | 75 +
.../devicetree/bindings/display/sprd/dsi.yaml
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/drm.yaml | 36
Add DT bindings for Powertip PH800480T013 800x480 parallel LCD,
this one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
V2: Add the
From: Kevin Tang
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
On 28/07/2020 17:59, Roger Pau Monné wrote:
> On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
>> Hi,
>>
>> On 27/07/2020 10:13, Roger Pau Monne wrote:
>>> To be used in order to create foreign mappings. This is based on the
>>> ZONE_DEVICE facility which is used by persistent memory
From: Kevin Tang
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> Hi,
>
> On 27/07/2020 10:13, Roger Pau Monne wrote:
> > To be used in order to create foreign mappings. This is based on the
> > ZONE_DEVICE facility which is used by persistent memory devices in
> > order to create struct pages and
From: Kevin Tang
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
RFC v6:
- Access registers via readl/writel
- Checking for unsupported KMS properties (format, rotation, blend_mode, etc)
Currently `struct drm_buf_desc` is defined as follows:
struct drm_buf_desc {
int count;
int size;
int low_mark;
int high_mark;
enum {
_DRM_PAGE_ALIGN = 0x01,
_DRM_AGP_BUFFER = 0x02,
_DRM_SG_BUFFER = 0x04,
fixed the following warning:
hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable.
hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable.
v2:
using the pci_dev.msi_enabled instead of priv->msi_enabled.
v3:
just call pci_enable_msi() and pci_disable_msi(), it's no
From: Kevin Tang
ChangeList:
v1:
1. only upstream modeset and atomic at first commit.
2. remove some unused code;
3. use alpha and blend_mode properties;
3. add yaml support;
4. remove auto-adaptive panel driver;
5. bugfix
v2:
1. add sprd crtc and plane module for KMS, preparing for multi crtc
drm_atomic_get_plane_state() can return errors, so we need to handle
these.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dpu.yaml
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
arch/arm/boot/dts/mt7623.dtsi | 177
This Patch-Series adds missing Patches/Bugfixes to get hdmi working
on BPI-R2
This is v2 of series https://patchwork.kernel.org/cover/10903309/ after
getting mmsys done
v1->v2:
- using get_possible_crtc API instead of hardcoded
- drop unused dts-nodes
- refine commit-messages as far as i can
Here are a few cleanups to the ingenic-drm driver.
- some error paths were missing and have been added;
- the mode validation has been moved to the .mode_valid helper callback.
Cheers,
-Paul
Paul Cercueil (2):
drm/ingenic: Handle errors of drm_atomic_get_plane_state
drm/ingenic: Validate
On 7/28/20 3:07 AM, Kevin Tang wrote:
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> new file mode 100644
> index 000..b189a54
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -0,0 +1,12 @@
> +config DRM_SPRD
> + tristate "DRM Support for Unisoc SoCs
On Thu, Jul 16, 2020 at 6:10 PM Kunihiko Hayashi
wrote:
>
> Current dma-buf heaps can handle only default CMA. This introduces
> dma_heap_add_cma() function to attach CMA heaps that belongs to a device.
>
> At first, the driver calls of_reserved_mem_device_init() to set
> memory-region property
From: Dave Airlie
Drop the WARN_ON and consolidate the two paths into one.
Use the consolidate slowpath in the execbuf utils code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 12 +--
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
Tested-by: Laurent Morichetti
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
1
Hi Thomas.
On Tue, Jul 28, 2020 at 09:44:12AM +0200, Thomas Zimmermann wrote:
> This is the final patchset for converting ast to managed initialization.
>
> Patches #1 to #4 address I2C helpers. The structures are being stored
> in struct ast_connector. The initialization and cleanups is being
On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
> Managed releases of the device's I2C adapter simplify the connector's
> release.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_mode.c | 21 ++---
> 1 file changed, 10 insertions(+), 11
Hi Thomas.
A few comments related to the code - but not to this patch and
not to this patch-set.
But I noticed so here goes.
Sam
On Tue, Jul 28, 2020 at 09:44:13AM +0200, Thomas Zimmermann wrote:
> The I2C support feels slammed down to the end of ast_mode.c. Improve
> this by moving the
Hi Thomas.
On Tue, Jul 28, 2020 at 09:44:14AM +0200, Thomas Zimmermann wrote:
> The ast driver is supposed to work without I2C support. This is
> tested by looking at the connector's i2c field being non-NULL.
>
> After embedding the I2C structure in the connector, the i2c field
> will not be a
On Tue, Jul 28, 2020 at 02:12:46PM +0200, Marek Vasut wrote:
> Add support for Powertip PH800480T013 800x480 parallel LCD, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob Herring
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member
'dmabuf' not described in 'dma_buf_set_name'
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma-buf/dma-buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Fix W=1 compile warnings (invalid kerneldoc):
drivers/dma-buf/dma-fence-chain.c:233: warning: Function parameter or
member 'seqno' not described in 'dma_fence_chain_init'
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma-buf/dma-fence-chain.c | 1 +
1 file changed, 1 insertion(+)
diff
On 2020-07-28 5:22 a.m., Paul Menzel wrote:
Dear Linux folks,
Am 25.07.20 um 07:20 schrieb Mazin Rezk:
On Saturday, July 25, 2020 12:59 AM, Duncan wrote:
On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote:
Am 24.07.20 um 19:33 schrieb Kees Cook:
There was a fix to disable the async
Quoting Daniel Vetter (2020-07-27 20:32:45)
> On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote:
> >
> > An unfortunate sequence of events, but it turns out there is a valid
> > usecase for being able to free/decouple the driver objects before they
> > are freed by the DRM core. In particular,
On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote:
> On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote:
> >
> > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote:
> > >
> > > > No, this very first warning continues (only once) :(
> > > > From here (drm_crtc_vblank_on):
> > > >
>-Original Message-
>From: dri-devel On Behalf Of
>Dave Airlie
>Sent: Monday, July 27, 2020 11:26 PM
>To: dri-devel@lists.freedesktop.org
>Cc: bske...@redhat.com
>Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>
>From: Dave Airlie
>
>Instead of rolling driver copies
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
Possibly a comment to say that the VEC and PV3 are deliberately NOT
enabled as the VEC requires further very specific clock
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The BCM2711 has a reworked display pipeline, and the load tracker needs
> some adjustement to operate properly. Let's add a compatible for BCM2711
s/adjustement/adjustment
> and disable the load tracker until properly supported.
>
On 2020-07-27 04:06, 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 LCDC v4, but has extended features amongst which the most
> notable one is a second
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> Now that the driver is ready for it, let's bring in the HDMI controllers
> variants for the BCM2711.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 278
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to avoid pixels getting stuck in an unflushable FIFO, we need when
> we disable the HDMI controller to switch away from getting our pixels from
> the pixelvalve and instead use blank pixels, and switch back to the
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The VID_CTL setup is done in several places in the driver even though it's
> not really required. Let's simplify it a bit to do the configuration in one
> go.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to prevent some pixels getting stuck in an unflushable FIFO on
> bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI
> controller (the encoder) in an intertwined way, and with tight delays.
>
>
Hi Greg,
Apparently the patchset has no more comments.
Could you take the patches to your tree? At least 1st and 2nd.
Regards
Andrzej
On 13.07.2020 16:43, Andrzej Hajda wrote:
> Hi All,
>
> Thanks for comments.
>
> Changes since v8:
> - fixed typo in function name,
> - removed cocci script
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to avoid a pixel getting stuck in an unflushable FIFO, we need to
> recenter the FIFO every time we're doing a modeset and not only if we're
> connected to an HDMI monitor.
>
> Signed-off-by: Maxime Ripard
Reviewed-by:
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The current code has some logic, disabled by default, to dump the register
> setup in the HDMI controller.
>
> However, since we're going to split those functions in multiple, shorter,
> functions that only make sense where they are
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HDMI driver was registering a single ALSA card so far with the name
> vc4-hdmi.
>
> Obviously, this is not going to work anymore when will have multiple HDMI
s/will/we
> controllers since we will end up trying to register two
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HSM clock needs to be setup at around 101% of the pixel rate. This
> was done previously by setting the clock rate to 163.7MHz at probe time and
> only check in mode_valid whether the mode pixel clock was under the pixel
> clock
1 - 100 of 172 matches
Mail list logo
