tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 7aebbbd59a2ee62e3b75d7e8e3617171c3c6a208
commit: 4dc079787b23524c4d88a21bc25db29e9e525eb2 [448/499] drm/amd/display: Use
dmub fw to lock pipe, cursor, dig
config: i386-randconfig-a014-20200624 (attached as .config)
compiler:
On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote:
>
> Ignoring everything else ...
>
> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula
> wrote:
> > As a side note, there seem to be extra checks in place for acks when
> > applying non-i915 patches to drm-intel; there are no such checks for
> >
Hi Linus,
Usual rc3 pickup, lots of little fixes all over, The core VT
registration regression fix is probably the largest, otherwise ttm,
amdgpu and tegra are the bulk, with some minor driver fixes. No i915
pull this week which may or may not mean I get 2x of it next week,
we'll see how it goes.
Hi all,
On Fri, 12 Jun 2020 10:25:52 +1000 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function
> 'kfd_sdma_activity_worker':
>
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
between commit:
eaad0c3aa978 ("drm/amdgpu: rename direct to immediate for VM updates")
from the Linus' and commit:
b1a8ef952a25 ("drm/amdgpu: move ttm bo->offset to
On Fri, 26 Jun 2020 at 05:27, Jani Nikula wrote:
>
> On Fri, 26 Jun 2020, Dave Airlie wrote:
> > WTUF?
> >
> > How did this ever land in my tree, there is no ACK on this from anyone
> > in core dma-buf,
> >
> > Intel team, clean your house up here, I'm going to have to ask you to
> > stop Chris
Hi Sonny,
First bad commit (maybe != root cause):
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: cd5dd023c24f097393cd351bfaaba81284d1a15b
commit: 788c2ef8c423ccd8c62a471c7e7debe115b3e124 [9951/] drm amdgpu: SI UVD
add uvd_v3_1 to makefile
config:
This driver includes but does not use any
symbols from that file, drop the include.
Signed-off-by: Linus Walleij
---
drivers/video/backlight/lms501kf03.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/lms501kf03.c
b/drivers/video/backlight/lms501kf03.c
index
This converts the lms283gf05 backlight driver to use GPIO
descriptors and switches the single PXA Palm Z2 device
over to defining these.
Since the platform data was only used to convey GPIO
information we can delete the platform data header.
Notice that we define the proper active low semantics
Thanks Bhanu for the patch, merged to drm-misc
Manasi
On Mon, Jun 22, 2020 at 07:55:18PM +0530, Bhanuprakash Modem wrote:
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector,
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: cd5dd023c24f097393cd351bfaaba81284d1a15b
commit: e060721131c59a375125f7e5202d8e2cd7462406 [9928/] drm/powerplay:
label internally used symbols as static
config: s390-randconfig-s032-20200624 (attached as
Hi,
On Thu, Jun 25, 2020 at 5:17 AM Kalyan Thota wrote:
>
> This change enables dither block for primary interface
> in display.
>
> Enabled for 6bpc in the current version.
>
> Changes in v1:
> - Remove redundant error checks (Rob).
>
> Signed-off-by: Kalyan Thota
> ---
>
Ignoring everything else ...
On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula wrote:
> As a side note, there seem to be extra checks in place for acks when
> applying non-i915 patches to drm-intel; there are no such checks for
> drm-misc.
One option to generalize that that I pondered is to consult
On Fri, 26 Jun 2020, Dave Airlie wrote:
> WTUF?
>
> How did this ever land in my tree, there is no ACK on this from anyone
> in core dma-buf,
>
> Intel team, clean your house up here, I'm going to have to ask you to
> stop Chris merging stuff without oversight, if this sort of thing
> happens,
Hi Lee.
On Thu, Jun 25, 2020 at 09:03:37AM +0100, Lee Jones wrote:
> On Wed, 24 Jun 2020, Sam Ravnborg wrote:
>
> > Hi Lee.
> >
> > On Wed, Jun 24, 2020 at 04:43:21PM +0100, Lee Jones wrote:
> > > On Wed, 24 Jun 2020, Sam Ravnborg wrote:
> > >
> > > > Hi Lee.
> > > >
> > > > On Wed, Jun 24,
Use a bit-mask of EOF irqs to determine when all required idmac
channel EOFs have been received for a tile conversion, and only do
tile completion processing after all EOFs have been received. Otherwise
it was found that a conversion would stall after the completion of a
tile and the start of the
https://bugzilla.kernel.org/show_bug.cgi?id=201139
--- Comment #11 from Adarion from userland (h_mailingli...@posteo.de) ---
Potentially related
https://bugzilla.kernel.org/show_bug.cgi?id=208115
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Fri, 8 May 2020 at 15:58, Joonas Lahtinen
wrote:
>
> Quoting Dave Airlie (2020-05-07 21:27:27)
> > On Fri, 8 May 2020 at 01:44, Chris Wilson wrote:
> > >
> > > Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > >
Applied. Thanks!
Alex
On Thu, Jun 25, 2020 at 1:14 PM Ivan Mironov wrote:
>
> I updated my system with Radeon VII from kernel 5.6 to kernel 5.7, and
> following started to happen on each boot:
>
> ...
> BUG: kernel NULL pointer dereference, address: 0128
>
WTUF?
How did this ever land in my tree, there is no ACK on this from anyone
in core dma-buf,
Intel team, clean your house up here, I'm going to have to ask you to
stop Chris merging stuff without oversight, if this sort of thing
happens, this is totally unacceptable.
Dave.
Signed-off-by:
On Thu, Jun 25, 2020 at 8:55 AM Daniel Vetter wrote:
>
> On Thu, Jun 25, 2020 at 4:17 PM Rob Clark wrote:
> >
> > On Thu, Jun 25, 2020 at 5:35 AM Daniel Vetter
> > wrote:
> > >
> > > On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote:
> > > >
> > > > From: Shawn Guo
> > > >
> > > > The msm/mdp5
Am 25.06.20 um 17:52 schrieb Christian König:
Am 25.06.20 um 17:44 schrieb Daniel Vetter:
On Thu, Jun 25, 2020 at 11:50 AM Christian König
wrote:
I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next.
I think you left an unresolved conflict behind in drm-tip, please
resolve
On Thu, Jun 25, 2020 at 4:17 PM Rob Clark wrote:
>
> On Thu, Jun 25, 2020 at 5:35 AM Daniel Vetter wrote:
> >
> > On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote:
> > >
> > > From: Shawn Guo
> > >
> > > The msm/mdp5 driver uses drm_private_obj as its global atomic state,
> > > which keeps the
Am 25.06.20 um 17:44 schrieb Daniel Vetter:
On Thu, Jun 25, 2020 at 11:50 AM Christian König
wrote:
I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next.
I think you left an unresolved conflict behind in drm-tip, please resolve per
On Thu, Jun 25, 2020 at 11:50 AM Christian König
wrote:
>
> I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next.
I think you left an unresolved conflict behind in drm-tip, please resolve per
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #21 from Maurice Gale (mauricega...@gmail.com) ---
Created attachment 289887
--> https://bugzilla.kernel.org/attachment.cgi?id=289887=edit
Log after Nouveau Patch
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #20 from Maurice Gale (mauricega...@gmail.com) ---
Hi,
I tried the patch, but I am still missing two displays. I have attached the new
log.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
On Tue, Mar 03, 2020 at 12:55:04PM +0100, Lucas Stach wrote:
> On Mo, 2020-03-02 at 20:13 +0100, Guido Günther wrote:
> > At least GC7000 fails to enter runtime suspend for long periods of time
> > since
> > the MC becomes busy again even when the FE is idle. The rest of the series
> > makes
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129.
v5.7.5: Build OK!
v5.4.48: Failed to apply!
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.7.5, v5.4.48, v4.19.129.
v5.7.5: Build OK!
v5.4.48: Failed to apply!
On Thu, Jun 25, 2020 at 5:35 AM Daniel Vetter wrote:
>
> On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote:
> >
> > From: Shawn Guo
> >
> > The msm/mdp5 driver uses drm_private_obj as its global atomic state,
> > which keeps the assignment of hwpipe to plane. With drm_private_obj
> > missing
On Thu, Jun 25, 2020 at 3:23 PM Lionel Landwerlin
wrote:
>
> On 25/06/2020 16:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> >> There was probably a misunderstand on how the dma-fence-chain is
> >> supposed to work or what dma_fence_chain_find_seqno() is supposed to
On 25/06/2020 16:47, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 14:23:25)
On 25/06/2020 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what
Quoting Lionel Landwerlin (2020-06-25 14:23:25)
> On 25/06/2020 16:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> >> There was probably a misunderstand on how the dma-fence-chain is
> >> supposed to work or what dma_fence_chain_find_seqno() is supposed to
> >>
Hi Thomas,
On Thu, Jun 25, 2020 at 2:00 PM Thomas Zimmermann wrote:
> Make sure required hardware regulators are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Regulators are released automatically via devres
Hi Thomas,
On Thu, Jun 25, 2020 at 2:00 PM Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers.
On 25/06/2020 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
> There was probably a misunderstand on how the dma-fence-chain is
> supposed to work or what dma_fence_chain_find_seqno() is supposed to
> return.
>
> dma_fence_chain_find_seqno() is here to give us the fence to wait upon
> for a particular point
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the
On Thu, Jun 25, 2020 at 1:58 PM Shawn Guo wrote:
>
> From: Shawn Guo
>
> The msm/mdp5 driver uses drm_private_obj as its global atomic state,
> which keeps the assignment of hwpipe to plane. With drm_private_obj
> missing from duplicate state call, mdp5 suspend works with no problem
> only for
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.
dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the timeline. The timeline progresses only
when all the
This displays a console on the simplefb framebuffer. The default
framebuffer format is being used.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simplekms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simplekms.c b/drivers/gpu/drm/tiny/simplekms.c
ver for simple-framebuffer platform devices"
+#define DRIVER_DATE"20200625"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+/*
+ * Assume a monitor resolution of 96 dpi to
+ * get a somewhat reasonable screen size.
+ */
+#define RES_MM(d) \
+ (((d)
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kickout the simplekms
driver before taking over the device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/Kconfig | 1 +
drivers/gpu/drm/tiny/simplekms.c | 94
Platform devices might operate on firmware framebuffers, such as VESA or
EFI. Before a native driver for the graphics hardware can take over the
device, it has to remove any platform driver that operates on the firmware
framebuffer. Platform helpers provide the infrastructure for platform
drivers
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simplekms.c | 84
1 file changed, 84 insertions(+)
diff --git
The blitter functions copy a framebuffer to I/O memory using one of
the existing conversion functions.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c | 87 +
include/drm/drm_format_helper.h | 8 +++
2 files changed, 95 insertions(+)
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
---
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simplekms.c | 108
This patchset adds support for simple-framebuffer platform devices and
a handover mechanism for native drivers to take-over control of the
hardware.
The new driver, called simplekms, binds to a simple-frambuffer platform
device. The kernel's boot code creates such devices for firmware-provided
The memcpy's destination buffer might have a different pitch than the
source. Support different pitches as function argument.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_format_helper.c| 9 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c
From: Shawn Guo
The msm/mdp5 driver uses drm_private_obj as its global atomic state,
which keeps the assignment of hwpipe to plane. With drm_private_obj
missing from duplicate state call, mdp5 suspend works with no problem
only for the very first time. Any subsequent suspend will hit the
On Thu, Jun 25, 2020 at 10:36:28AM +0200, Maarten Lankhorst wrote:
> Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> > From: Stanislav Lisovskiy
> >
> > Added epoch counter checking to intel_encoder_hotplug
> > in order to be able process all the connector changes,
> > besides connection status.
On Thu, Jun 25, 2020 at 12:32 PM Pekka Paalanen wrote:
>
> On Thu, 25 Jun 2020 09:57:44 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote:
> > >
> > > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> > > > On Wed, Jun 24, 2020 at 3:31 PM
On Thu, 25 Jun 2020, Daniel Thompson wrote:
> On Wed, Jun 24, 2020 at 03:57:16PM +0100, Lee Jones wrote:
> > Kerneldoc syntax is used, but not complete. Descriptions required.
> >
> > Prevents warnings like:
> >
> > drivers/video/backlight/ili922x.c:116: warning: Function parameter or
> >
On Thu, 25 Jun 2020 09:57:44 +0200
Daniel Vetter wrote:
> On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> > > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 5:24 PM
On 25.06.2020 10:41, Andy Shevchenko wrote:
> On Wed, Jun 24, 2020 at 10:40 PM Andrzej Hajda wrote:
>> On 24.06.2020 17:16, Robin Murphy wrote:
> ...
>
>> I have proposed such thing in my previous iteration[1], except it was
>> macro because of variadic arguments.
> You may have a function with
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #17 from Andrew Ammerlaan (andrewammerl...@riseup.net) ---
(In reply to Alex Deucher from comment #16)
> When the GPU is in reset all reads to the MMIO BAR return 1s so you are just
> getting all ones until the reset succeeds. 511 is
On Thu, Jun 25, 2020 at 11:50 AM Christian König
wrote:
>
> I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next.
>
> Only VMGFX and Nouveau are missing and I'm pretty close to just push
> them with my Acked-by since they should not contain any functional change.
>
> Any
I've pushed patches #1, #2 and #5-#8 of this series to drm-misc-next.
Only VMGFX and Nouveau are missing and I'm pretty close to just push
them with my Acked-by since they should not contain any functional change.
Any objections?
Thanks,
Christian.
Am 24.06.20 um 20:26 schrieb Nirmoy Das:
On Wed, Jun 24, 2020 at 03:57:21PM +0100, Lee Jones wrote:
> Fixes W=1 warnings:
>
> drivers/video/backlight/qcom-wled.c:1294:34: warning: ‘wled4_string_cfg’
> defined but not used [-Wunused-const-variable=]
> 1294 | static const struct wled_var_cfg wled4_string_cfg = {
> | ^~~~
>
On Wed, Jun 24, 2020 at 03:57:20PM +0100, Lee Jones wrote:
> unsigned ints 'sources' and 'bank' cannot be less than LM3630A_SINK_0 (0)
> and LM3630A_BANK_0 (0) respecitively, so change the logic to only check
> for thier two possible valid values.
>
> Fixes W=1 warnings:
>
>
On Wed, Jun 24, 2020 at 03:57:18PM +0100, Lee Jones wrote:
> Kerneldoc syntax is used, but not complete. Descriptions required.
>
> Prevents warnings like:
>
> drivers/video/backlight/ili922x.c:298: warning: Function parameter or member
> 'spi' not described in 'ili922x_reg_dump'
>
> Cc:
>
On Wed, Jun 24, 2020 at 03:57:19PM +0100, Lee Jones wrote:
> Kerneldoc syntax is used, but not complete. Descriptions required.
>
> Prevents warnings like:
>
> drivers/video/backlight/backlight.c:329: warning: Function parameter or
> member 'reason' not described in 'backlight_force_update'
>
On Wed, Jun 24, 2020 at 03:57:17PM +0100, Lee Jones wrote:
> Kerneldoc is for documenting function arguments and return values.
>
> Prevents warnings like:
>
> drivers/video/backlight/ili922x.c:127: warning: cannot understand function
> prototype: 'int ili922x_id = 1; '
>
On Wed, Jun 24, 2020 at 03:57:16PM +0100, Lee Jones wrote:
> Kerneldoc syntax is used, but not complete. Descriptions required.
>
> Prevents warnings like:
>
> drivers/video/backlight/ili922x.c:116: warning: Function parameter or member
> 's' not described in 'CHECK_FREQ_REG'
>
On Wed, Jun 24, 2020 at 03:57:15PM +0100, Lee Jones wrote:
> This has been missing since the conversion to 'struct device' in 2007.
>
> Cc:
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Jamey Hicks
> Cc: Andrew Zabolotny
> Signed-off-by: Lee Jones
Reviewed-by: Daniel Thompson
> ---
>
On 6/25/20 1:33 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_submit_relocation {
/* [in] Index of GATHER or GATHER_UPTR command in commands. */
__u32 gather_command_index;
/*
* [in] Mapping handle (obtained through
On Wed, Jun 24, 2020 at 03:57:14PM +0100, Lee Jones wrote:
> W=1 kernel build reports:
>
> drivers/video/backlight/lms501kf03.c:96:28: warning: ‘seq_sleep_in’ defined
> but not used [-Wunused-const-variable=]
> 96 | static const unsigned char seq_sleep_in[] = {
> | ^~~~
>
On 6/25/20 3:47 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
#define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0)
#define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1)
The sync object shouldn't be created by the kernel driver and we
shouldn't need the
On 6/25/20 2:23 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
struct drm_tegra_channel_submit {
__u32 channel_id;
__u32 flags;
/**
* [in] Timeout in microseconds after which the kernel may
* consider the job to have hung
On 6/24/20 11:55 PM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
...
* Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present.
Not sure if they are still needed.
Hello Mikko!
A quick comment for the starter. Switching away from the Tegra-specific
GEM IOCTLs
On 6/25/20 2:11 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
/* Command is an opcode gather from a GEM handle */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
/* Command is an opcode gather from a user pointer */
#define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR
Hi Sam,
On Tue, 2020-06-23 at 20:55 +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> On Tue, May 26, 2020 at 04:14:38AM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series converts the R-Car DU driver to use the DRM
> > bridge
> > connector helper drm_bridge_connector_init().
> >
>
On Wed, Jun 24, 2020 at 10:40 PM Andrzej Hajda wrote:
> On 24.06.2020 17:16, Robin Murphy wrote:
...
> I have proposed such thing in my previous iteration[1], except it was
> macro because of variadic arguments.
You may have a function with variadic arguments. Macros are beasts and
make in
Op 23-06-2020 om 20:57 schreef Kunal Joshi:
> From: Stanislav Lisovskiy
>
> Added epoch counter checking to intel_encoder_hotplug
> in order to be able process all the connector changes,
> besides connection status. Also now any change in connector
> would result in epoch counter change, so no
Hi Dave and Daniel,
there's the PR for the current patches in drm-misc-fixes. Besides the fixes
there's also a merge of v.5.8-rc1.
Best regards
Thomas
drm-misc-fixes-2020-06-25:
Short summary of fixes pull (less than what git shortlog provides):
* In mcde, set up fbdev after device
On Wed, 24 Jun 2020, Sam Ravnborg wrote:
> Hi Lee.
>
> On Wed, Jun 24, 2020 at 04:43:21PM +0100, Lee Jones wrote:
> > On Wed, 24 Jun 2020, Sam Ravnborg wrote:
> >
> > > Hi Lee.
> > >
> > > On Wed, Jun 24, 2020 at 03:57:13PM +0100, Lee Jones wrote:
> > > > Attempting to clean-up W=1 kernel
On Thu, Jun 25, 2020 at 9:56 AM Daniel Vetter wrote:
>
> On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> > On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> > >
> > > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 3:23 AM
On Wed, Jun 24, 2020 at 03:40:42PM -0400, Alex Deucher wrote:
> On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher wrote:
> > >
> > > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 04:12:09AM
On Wed, Jun 24, 2020 at 03:08:22PM +, Yannick FERTRE wrote:
> Hello Angelo,
> thank for patch.
>
> Reviewed-by: Yannick Fertre
Patch applied, thanks.
-Daniel
>
>
>
> On 4/3/20 3:30 PM, Angelo Ribeiro wrote:
> > dw-mipi-dsi does not use any definition from drm_probe_helper.
> >
> >
23.06.2020 15:09, Mikko Perttunen пишет:
> struct drm_tegra_channel_submit {
> __u32 channel_id;
> __u32 flags;
>
> /**
> * [in] Timeout in microseconds after which the kernel may
> * consider the job to have hung and may reap it and
> *
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar.
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c
23.06.2020 15:09, Mikko Perttunen пишет:
> #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE (1<<0)
> #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ (1<<1)
The sync object shouldn't be created by the kernel driver and we
shouldn't need the sync-file FD.
Please consider this example of how
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
On Fri, Jun 12, 2020 at 06:00:53PM +0200, Daniel Vetter wrote:
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
>
> Signed-off-by: Daniel Vetter
> Cc: Eric
Switch over to GEM VRAM's implementation to retrieve bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10
This change enables dither block for primary interface
in display.
Enabled for 6bpc in the current version.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 66 +
On Fri, Jun 12, 2020 at 06:00:49PM +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
23.06.2020 15:09, Mikko Perttunen пишет:
> /* Command is an opcode gather from a GEM handle */
> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER 0
> /* Command is an opcode gather from a user pointer */
> #define DRM_TEGRA_SUBMIT_COMMAND_GATHER_UPTR 1
I'm a bit dubious about whether we
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c |
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++--
On 6/24/20 4:21 PM, Rafael J. Wysocki wrote:
On Wed, Jun 10, 2020 at 12:12 PM Lukasz Luba wrote:
Add support for other devices than CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been
23.06.2020 15:09, Mikko Perttunen пишет:
>
> struct drm_tegra_channel_submit {
> __u32 channel_id;
> __u32 flags;
>
> /**
> * [in] Timeout in microseconds after which the kernel may
> * consider the job to have hung and may reap it and
> *
Quoting Harigovindan P (2020-02-17 00:58:42)
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 388f50ad4fde..349db8fe78a5 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -232,6
1 - 100 of 105 matches
Mail list logo
