On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() de
On Wed, Aug 14, 2019 at 01:45:58PM -0700, Andrew Morton wrote:
> On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter
> wrote:
>
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debu
On Wed, Aug 14, 2019 at 09:46:41PM -0400, Sasha Levin wrote:
> On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote:
> > Hi Sasha,
> >
> > On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote:
> > > Hi,
> > >
> > > [This is an automated email]
> > >
> > > This commit has been pro
Hi Philipp,
On 19-08-14 17:10, Philipp Zabel wrote:
> Support is already implemented for the corresponding DRM formats,
> just hook up the remaining V4L2 pixel formats.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/ipu-v3/ipu-common.c | 16 ++--
> drivers/gpu/ipu-v3/ipu-cpmem
On Thu, Aug 15, 2019 at 1:35 AM Alex Hung wrote:
>
> On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote:
> >
> > This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291.
> >
> > This was never discussed with anybody Nouveau related and we would have
> > NACKed
> > this change immediately.
>
Hi Dave, Daniel,
A few fixes for 5.3. Nothing major.
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (2019-08-11 13:26:41 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.3-2019-08-14
for
On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote:
Hi Sasha,
On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking ar
Hi, Alexandre:
On Mon, 2019-07-29 at 14:33 +0900, Alexandre Courbot wrote:
> The default DMA segment size was used when importing PRIME buffers,
> which resulted in a chance of them not being contiguous in the virtual
> IO space of the device and mtk_gem_prime_import_sg_table() complaining
> that
pm8941 is missing the 5vs2 regulator node so let's add it since its
needed to get the external display working. This regulator was already
configured in the interrupts property on the parent node.
Note that this regulator is referred to as mvs2 in the downstream MSM
kernel sources.
Signed-off-by:
Silence a warning message due to an -EPROBE_DEFER error to help cleanup
the system boot log.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
b/drivers/gpu/drm/msm/
Add CONFIG_DRM_ANALOGIX_ANX78XX as a module so that the external display
can be used on the Nexus 5 phones.
Signed-off-by: Brian Masney
---
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index
Add support for the avdd33 regulator to the analogix-anx78xx driver.
Note that the regulator is currently enabled during driver probe and
disabled when the driver is removed. This is currently how the
downstream MSM kernel sources do this.
Let's not merge this upstream for the mean time until I ge
Silence two warning messages that occur due to -EPROBE_DEFER errors to
help cleanup the system boot log.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
Add HDMI tx and phy nodes to support an external display that can be
connected over the SlimPort. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
---
The hdmi-tx node in the downstream MSM sources:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/ms
Add support for the 7808 variant. While we're here, the of match table
was missing support for the 7812 and 7818 variants, so add them as well.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge
Add HDMI nodes and other supporting infrastructure in order to support
the external display. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
---
The hdmi-tx node in the downstream MSM sources:
https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/boot/dts/msm8974
When attempting to configure this driver on a Nexus 5 phone (msm8974),
setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
error. The downstream MSM kernel sources [1] shows that the proper value
for TX_P0 is 0x78, not 0x70, so correct the value to allow device
probing to succeed.
[
This patch series begins to add support for the external display over
HDMI that is supported on msm8974 SoCs. I'm testing this series on the
Nexus 5, and I'm able to communicate with the HDMI bridge via the
analogix-anx78xx driver, however the external display is not working
yet.
When I plug in th
Add support for the analogix,anx7808, analogix,anx7812, and
analogix,anx7818 variants.
Signed-off-by: Brian Masney
---
.../devicetree/bindings/display/bridge/anx7814.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/br
The i2c_new_dummy() function is deprecated since it returns NULL on
error. Change this to use the recommended replacement
i2c_new_dummy_device() that returns an error code that can be read with
PTR_ERR() and friends.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 15
On Wed, Aug 14, 2019 at 10:20:27PM +0200, Daniel Vetter wrote:
> Similar to the warning in the mmu notifer, warning if an hmm mirror
> callback gets it's blocking vs. nonblocking handling wrong, or if it
> fails with anything else than -EAGAIN.
>
> Cc: Jason Gunthorpe
> Cc: Ralph Campbell
> Cc:
On Wed, Aug 14, 2019 at 10:20:26PM +0200, Daniel Vetter wrote:
> This is a similar idea to the fs_reclaim fake lockdep lock. It's
> fairly easy to provoke a specific notifier to be run on a specific
> range: Just prep it, and then munmap() it.
>
> A bit harder, but still doable, is to provoke the
On 8/14/19 12:59 AM, Christoph Hellwig wrote:
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which starts revamping the
migrate_vma functionality. The prime idea is to export three slightly
lower level functions and thus avoid the need for migrate_vma_ops
callbacks.
Diffstat
On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() cal
On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> Th
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This series introduces a new registration flow for mmu_notifiers based on
the idea that the user would like to get a single refcounted piece of
memory for a mm, keyed to its use.
For instance many users of mmu_notifiers use an in
On 8/14/19 3:14 PM, Andrew Morton wrote:
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some
On Wed, Aug 14, 2019 at 03:14:47PM -0700, Andrew Morton wrote:
> On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter
> wrote:
>
> > Just a bit of paranoia, since if we start pushing this deep into
> > callchains it's hard to spot all places where an mmu notifier
> > implementation might fail when i
On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote:
>
> This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
>
> The original commit message didn't even make sense. AMD _does_ support it and
> it works with Nouveau as well.
>
> Also what was the issue being solved here? No references to any
From: Rob Clark
drm_cflush_pages() is no-op on arm/arm64. But instead we can use
arch_sync API.
Fixes failures with vgem_test.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/vgem/vgem_drv.c | 145 +---
1 file changed, 98 insertions(+), 47 deletions(-)
diff --git a/
From: Rob Clark
Use arch_sync_dma_for_{device,cpu}() rather than abusing the DMA API to
indirectly get at the arch_sync_dma code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 37 +++
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 m
From: Rob Clark
Signed-off-by: Rob Clark
---
arch/arm/Kconfig| 2 ++
arch/arm/mm/dma-mapping-nommu.c | 14 ++
arch/arm/mm/dma-mapping.c | 28
3 files changed, 44 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index
From: Rob Clark
Signed-off-by: Rob Clark
---
arch/powerpc/mm/dma-noncoherent.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/mm/dma-noncoherent.c
b/arch/powerpc/mm/dma-noncoherent.c
index c617282d5b2a..80d53b950821 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/
From: Rob Clark
Signed-off-by: Rob Clark
---
arch/arm64/mm/flush.c | 2 ++
arch/mips/mm/dma-noncoherent.c | 2 ++
drivers/gpu/drm/drm_cache.c| 20 +---
include/drm/drm_cache.h| 4
4 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/a
From: Rob Clark
Signed-off-by: Rob Clark
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 1d3f0b5a9940..ea5ae11d07f7 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@
From: Rob Clark
This is a replacement for a previous patches[1] that was adding arm64
support for drm_clflush. I've also added a patch to solve a similar
cache issue in vgem.
The first few patches just export arch_sync_dma_for_*(). Possibly
instead the EXPORT_SYMBOL_GPL() should be somewere ce
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() and mmu_notifier_call_srcu() no
longer have any users, they have all been converted to use
mmu_notifier_put().
So delete this difficult to use interface.
Signed-off-by: Jason Gunthorpe
Rev
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This is a significant simplification, it eliminates all the remaining
'hmm' stuff in mm_struct, eliminates krefing along the critical notifier
paths, and takes away all the ugly locking and abuse of page_table_lock.
mmu_notifier_
Hi Sam,
On Wed, Aug 14, 2019 at 10:28:01PM +0200, Sam Ravnborg wrote:
> On Wed, Aug 14, 2019 at 06:44:26PM +0200, Sam Ravnborg wrote:
> > On Tue, Aug 13, 2019 at 11:10:52PM +0300, Laurent Pinchart wrote:
> > > Hello everybody,
> > >
> > > This patch series adds DT bindings and drivers for 6 panel
Apperantly things go south if we suspend the device with a different PCIE
link speed set than it got booted with. Fixes runtime suspend on my gp107.
This all looks like some bug inside the pci subsystem and I would prefer a
fix there instead of nouveau, but maybe there is no real nice way of doing
v2: fixed compilation error
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
CC: Alex Hung
CC: Rafael J. Wysocki
CC: Dave Airlie
CC: Lyude Paul
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pci/pcie.c| 8
2 f
First three patches are removing ACPI workarounds which should have never
landed.
The last four are adding a workaround to nouveau which seem to help quite
a lot with the RTD3 issues with Nouveau, so let's discuss and get wider
testing of those and see if there is any fallout or laptops where the
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
CC: Alex Hung
CC: Rafael J. Wysocki
CC: Dave Airlie
CC: Lyude Paul
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 8
drivers/gpu/drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++
drivers/gpu/drm/nouveau/n
Signed-off-by: Karol Herbst
CC: Alex Hung
CC: Rafael J. Wysocki
CC: Dave Airlie
CC: Lyude Paul
CC: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
inde
This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291.
This was never discussed with anybody Nouveau related and we would have NACKed
this change immediately.
We have a better workaround, which makes it actually work with Nouveau. No idea
why the comment mentions the Nvidia driver and assu
This reverts commit 887532ca7ca59fcf0547a79211756791128030a3.
We have a better solution for this: b516ea586d717
And same as with the last commit: "NVidia Linux driver" that's Nouveau, any
out of tree driver does _not_ matter. And with Nouveau all of this works even
though it required a proper fix
This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
The original commit message didn't even make sense. AMD _does_ support it and
it works with Nouveau as well.
Also what was the issue being solved here? No references to any bugs and not
even explaining any issue at all isn't the way we
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Many places in the kernel have a flow where userspace will create some
object and that object will need to connect to the subsystem's
mmu_notifier subscription for the duration of its lifetime.
In this case the subsystem is usual
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #26 from mib...@gmx.at ---
Created attachment 145065
--> https://bugs.freedesktop.org/attachment.cgi?id=145065&action=edit
failed suspend log
Attached full log
--
You are receiving this mail because:
You are the assignee for the
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #9 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
I was able to reproduce.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing li
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This wi
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary")
made an attempt at doing this, but had to be reverted as calling
the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see
commit 35cfa2b0b491
Hi Laurent.
On Wed, Aug 14, 2019 at 06:44:26PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> On Tue, Aug 13, 2019 at 11:10:52PM +0300, Laurent Pinchart wrote:
> > Hello everybody,
> >
> > This patch series adds DT bindings and drivers for 6 panels used by
> > omapdrm. They are meant to replace th
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not al
Similar to the warning in the mmu notifer, warning if an hmm mirror
callback gets it's blocking vs. nonblocking handling wrong, or if it
fails with anything else than -EAGAIN.
Cc: Jason Gunthorpe
Cc: Ralph Campbell
Cc: John Hubbard
Cc: Dan Williams
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc: Ar
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job d
Hi all (but I guess mostly Jason),
Finally gotten around to rebasing the previous version, fixing the rebase
fail in there, update the commit message a bit and give this a spin with
some tests. Nicely caught a lockdep splat that we're now discussing in
i915, and seems to not have misfired anywhere
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return va
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This simplifies the code to not have so many one line functions and extra
logic. __mmu_notifier_register() simply becomes the entry point to
register the notifier, and the other one calls it under lock.
Also add a lockdep_assert
On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-08-14 19:24:01)
> > This reverts
> > 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> > dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> > 0e1d8083bddb ("dma-buf: further
Hi Xinliang, Rongrong, Xinwei, Chen
On Wed, Aug 14, 2019 at 06:46:36PM +, John Stultz wrote:
> Just wanted to resend this patch set so I didn't have to
> continue carrying it forever to keep the HiKey960 board running.
>
> This patchset contains one fix (in the front, so its easier to
> event
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #8 from Andreas Jackisch (andreas.jacki...@gmail.com) ---
Created attachment 284415
--> https://bugzilla.kernel.org/attachment.cgi?id=284415&action=edit
amdgpu firmware from ryzen system
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #7 from Andreas Jackisch (andreas.jacki...@gmail.com) ---
Created attachment 284413
--> https://bugzilla.kernel.org/attachment.cgi?id=284413&action=edit
lspci from ryzen system
--
You are receiving this mail because:
You are watchi
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #6 from Andreas Jackisch (andreas.jacki...@gmail.com) ---
Created attachment 284411
--> https://bugzilla.kernel.org/attachment.cgi?id=284411&action=edit
var_log_messages for amdgpu_ERROR
search fro "amdgpu" to see it fail after resu
On Wed, Aug 14, 2019 at 08:42:27PM +0200, Sam Ravnborg wrote:
> On Wed, Aug 14, 2019 at 07:51:37PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 07:36:55PM +0200, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 14-08-19 19:26, Daniel Vetter wrote:
> > > > On Tue, Aug 13, 2019 at 09:57:19AM
https://bugzilla.kernel.org/show_bug.cgi?id=204241
Andreas Jackisch (andreas.jacki...@gmail.com) changed:
What|Removed |Added
CC||andreas.ja
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #25 from Andrey Grodzovsky ---
(In reply to miba_c from comment #24)
> Having the same issue on a ThinkPad T495s (BIOS 1.06) with a Ryzen 7 PRO
> 3700U, Kernel 5.2.8-arch1-1-ARCH, Mesa 19.1.4-1 and running sway (wayland)
> as a windo
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Andrey Grodzovsky (andrey.grodzov...@amd.com) changed:
What|Removed |Added
CC||andrey.gro
https://bugs.freedesktop.org/show_bug.cgi?id=111402
Bug ID: 111402
Summary: amdgpu-pro-install fails to install on openSUSE Leap
15.1 due to insufficient checks of $ID [PATCH
included]
Product: DRI
Version: unspec
Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quot
Remove use of drmP.h in kirin driver
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Suggested-by: Sam Ravnborg
Signed-off-by: John Stultz
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 6 +-
drivers/gpu/drm/hisilicon/kirin/ki
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch removes the out_format
field in the struct ade_crtc, which was only ever set to
LDI_OUT_RGB_888.
Thus this patch removes the field and instead directly uses
LDI_OUT_RGB_888.
Cc: Ro
From: Xu YiPing
In a few functions, we pass in a struct ade_crtc, which we only
use to get to the underlying struct ade_hw_ctx.
Thus this patch refactors the functions to just take the
struct ade_hw_ctx directly.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-d
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames ade_data to
kirin_drm_private, and moves crtc_init and plane_init to
kirin drm drv too. Now that they are generic the functions
can be shared between the kirin620 and (to be
Just wanted to resend this patch set so I didn't have to
continue carrying it forever to keep the HiKey960 board running.
This patchset contains one fix (in the front, so its easier to
eventually backport), and a series of changes from YiPing to
refactor the kirin drm driver so that it can be used
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the max_width
and max_height values used in kirin_drm_mode_config_inita to
hardware specific driver data.
This will make it easier to add support for new devices
via a new kir
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
dev->driver_data to point to a drm_device, not ade_data.
Thus we set the driver data to drm device after alloc.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the crtc
and plane funcs/helper_funcs to the struct kirin_drm_data.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Rongrong Z
The workqueue used to reset the display when we hit an LDI
underflow error is ADE specific, so since this patch series
works to make the kirin_crtc structure more generic, move the
workqueue to the ade_hw_ctx structure instead.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vette
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_plane to kirin_plane.
The struct kirin_plane will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a f
The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin
driver, so cut out the middleman and condense the config
logic down.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
Signed-off-by: John Stultz
---
drive
From: Da Lv
The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the offset%4).
After lots of analysis by HiSi de
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch adds a flag to the
device specific driver data so that we can conditionally
register the connectors at init.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the code
via a passed in driver_data pointer, rather than hardcoding
them via ade_driver_data variable.
This will allow those funcitons to be later moved to the
generic kiri
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the mode config
initialization values into the kirin_drm_data structure.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Rongr
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization function to dynamically allocate the ade_hw_ctx
structure previously kept as part of struct ade_data.
This is done so that later we can have the hw_ctx p
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the number of
planes and the primary plane value to the kirin_drm_data
structure
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
C
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames
ade_crtc/plane_init kirin_plane/crtc_init, as they will later be
moved to kirin drm drv and shared with the kirin960 hardware
support.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization routines so the devm_request_irq() function
is called as part of the allocation function.
This will be needed in the future when we will have different
a
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct kirin_dc_ops to struct kirin_drm_data and cleans
up the related variable names.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-d
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves some shared
structures and helpers to the common kirin_drm_drv.h
These structures will later used by both kirin620 and
future kirin960 driver
Cc: Rongrong Zou
Cc: Xinliang L
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the channel
format arrays into the kirin_drm_data structure.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Rongrong Zou
Cc:
The 'return 0' in kirin_drm_platform_probe() is unreachable
code, so remove it.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Reviewed-by: Sam Ravnborg
Suggested by: Xu YiPing
Signed-off-by: John Stultz
---
drivers/gpu/drm/hisilicon/k
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
alloc/clean_hw_ctx functions to be called via driver_data
specific funciton pointers.
This will allow the ade_drm_init to later be made generic and
moved to kirin_drm_dr
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_crtc to kirin_crtc.
The struct kirin_crtc will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a futu
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the driver_data
value to not be a global variable. Instead the driver_data value
is accessed via the of_device_get_match_data() when needed.
Cc: Rongrong Zou
Cc: Xinliang L
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the drm_driver
structure to be under device specific driver data.
This will allow us to more easily add support for kirin960
hardware with later patches.
Cc: Rongrong Zou
Cc
On Wed, Aug 14, 2019 at 07:51:37PM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 07:36:55PM +0200, Hans de Goede wrote:
> > Hi,
> >
> > On 14-08-19 19:26, Daniel Vetter wrote:
> > > On Tue, Aug 13, 2019 at 09:57:19AM +0200, Hans de Goede wrote:
> > > > Hi,
> > > >
> > > > On 13-08-19 08:2
1 - 100 of 229 matches
Mail list logo
