On Mon, Jul 01, 2019 at 09:33:04PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the hmm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> mm/hmm.c: In function 'hmm_get_or_create':
> mm/hmm.c:50:2: error: implicit declaration of function
> 'lockdep_assert
The PRIME callback functions in struct drm_driver are deprecated in
favor of their counterparts in struct drm_gem_object_funcs.
This patch set introduces GEM object functions for VRAM helpers and
converts over the free and PRIME functions. Drivers affected by this
change, namely bochs and hibmc, a
VRAM PRIME helpers are now called through GEM object functions. The
driver callback functions are obsolete.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/driv
PRIME functionality is now provided via the callback functions in
struct drm_gem_object_funcs. The driver-structure functions are obsolete.
As a side effect of this patch, VRAM-based drivers get basic PRIME
support automatically without having to set any flags or additional
fields.
v2:
- u
The vbox driver uses VRAM helpers for memory management. These helpers
provide a basic implmentation of PRIME functions, so the vbox driver's
empty implmentation can be removed. As a side effect of this change,
vbox can now use generic framebuffer emulation.
Signed-off-by: Thomas Zimmermann
---
PRIME functionality is now provided by GEM object functions. The driver
callback functions are obsolete. So this patch renames them and turns
them into static internal functions of the VRAM helper library. The
implementation of gem_prime_mmap is now unused and the patch removes it.
Signed-off-by:
The GEM object's free function is now called through struct
drm_gem_object_funcs.free. The function struct drm_driver.gem_prime_mmap
is now required for mmap'ing GEM objects to userspace.
v2:
* set drm_driver.gem_prime_mmap to drm_gem_prime_mmap()
Signed-off-by: Thomas Zimmermann
Acked-b
Hi
Am 28.06.19 um 18:55 schrieb Daniel Vetter:
> On Fri, Jun 28, 2019 at 02:26:58PM +0200, Thomas Zimmermann wrote:
>> The GEM object's free function is now called through
>> struct drm_gem_object_funcs.free.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_
On 2019-07-01 6:01 p.m., Timur Kristóf wrote:
> On Mon, 2019-07-01 at 16:54 +0200, Michel Dänzer wrote:
>> On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
>>> I haven't found a good way to measure the maximum PCIe throughput
>>> between the CPU and GPU,
>>
>> amdgpu.benchmark=3
>>
>> on the kernel co
On Mon, Jul 01, 2019 at 02:27:51PM +0200, Andrzej Hajda wrote:
> On 01.07.2019 11:58, Maxime Ripard wrote:
> > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> >> On 12.06.2019 17:20, Maxime Ripard wrote:
> I am not sure if I understand whole discussion here, but I also do not
On 25/06/2019 17:34, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Currently we can only probe devices that either use device tree or pass
platform data to probe(). Rename gpio_backlight_probe_dt() to
gpio_backlight_probe_prop() and use generic device properties instead
of OF specific he
On 25/06/2019 17:34, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Instead of dereferencing pdev each time, use a helper variable for
the associated device pointer.
Signed-off-by: Bartosz Golaszewski
No objections but I think this will need to be respun against
backlight-next (or v5
On 25/06/2019 17:34, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
There's no good reason to have the generic probing code in a separate
routine. This function is short and is inlined by the compiler anyway.
Move it into probe under the pdata-specific part.
Signed-off-by: Bartosz Golasz
On Fri, Jun 28, 2019 at 11:15:10AM +0100, Linus Walleij wrote:
> On Fri, Jun 28, 2019 at 11:03 AM Bartosz Golaszewski wrote:
>
> > From: Bartosz Golaszewski
> >
> > While working on my other series related to gpio-backlight[1] I noticed
> > that we could simplify the driver if we made the only u
Hi,
> +static void drm_gem_vram_object_free(struct drm_gem_object *gem)
> +{
> + struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> +
> + drm_gem_vram_put(gbo);
> +}
Hmm, seems git diff didn't figure it's the same func just renamed
(likewise pin/unpin/vmap/vunmap). Maybe "gi
The subject should've been "Armada updates for merge window". Sorry.
On Tue, Jul 02, 2019 at 10:13:13AM +0100, Russell King wrote:
> Hi David,
>
> The following changes since commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd:
>
> Linux 5.1 (2019-05-05 17:42:58 -0700)
>
> are available in the g
> [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for
> ArcticSand arcxcnn driver bindings
The "v2" is normally applied to the whole patchset (if you
prepare the patchset using git format-patch then you can use
the --subject-prefix argument for that).
On Sun, Jun 30, 2019 at 08:28:14PM -04
On 7/1/2019 10:48 AM, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
but it turns out that because we didn't filter valid gfp_t flags
on the DMA allocator, a bunch of drivers were
On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is mostly similar to
> pwm_bl except the driver uses a LED class driver to adjust the brightness
> in the HW.
>
> Signed-off-by: Tomi Valkeinen
On Mon, Jul 01, 2019 at 05:14:23PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> Add DT binding for led-backlight.
I think the patchset is in the wrong order; the DT bindings
documentation should appear *before* the binding is
implemented (amoung other things this prevent transien
On Tue, Jul 02, 2019 at 07:36:53AM +0100, Lee Jones wrote:
> On Mon, 01 Jul 2019, Sekhar Nori wrote:
>
> > Hi Lee, Daniel, Jingoo,
> >
> > On 25/06/19 10:04 PM, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > This is another small step on the path to liberating davinci fr
On Tue, 2 Jul 2019 at 10:20, Gerd Hoffmann wrote:
>
> Hi,
>
> > +static void drm_gem_vram_object_free(struct drm_gem_object *gem)
> > +{
> > + struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> > +
> > + drm_gem_vram_put(gbo);
> > +}
>
> Hmm, seems git diff didn't figure it's
> > > -/**
> > > - * drm_gem_vram_driver_gem_free_object_unlocked() - \
> > > - Implements &struct drm_driver.gem_free_object_unlocked
> > > - * @gem: GEM object. Refers to &struct drm_gem_vram_object.gem
> > > - */
> >
> > I think we should keep the documentation ...
> >
> > > -EXPORT_SYMB
Hi Daniel,
On 02/07/2019 11:54, Daniel Thompson wrote:
On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is mostly similar to
pwm_bl except the driver uses a LED class driver to adjust the brightnes
Hi Heiko,
On Fri, 2019-06-21 at 18:13 -0300, Ezequiel Garcia wrote:
> Let's support Gamma LUT configuration on RK3288 SoCs.
>
> In order to do so, this series adds a new and optional
> address resource.
>
> A separate address resource is required because on this RK3288,
> the LUT address is
https://bugs.freedesktop.org/show_bug.cgi?id=109941
--- Comment #4 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug
anymore.
--
You are receiving this mail because:
You are the assignee
PRIME functionality is now provided via the callback functions in
struct drm_gem_object_funcs. The driver-structure functions are obsolete.
As a side effect of this patch, VRAM-based drivers get basic PRIME
support automatically without having to set any flags or additional
fields.
v2:
- u
The PRIME callback functions in struct drm_driver are deprecated in
favor of their counterparts in struct drm_gem_object_funcs.
This patch set introduces GEM object functions for VRAM helpers and
converts over the free and PRIME functions. Drivers affected by this
change, namely bochs, hibmc and v
VRAM PRIME helpers are now called through GEM object functions. The
driver callback functions are obsolete.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/dr
PRIME functionality is now provided by GEM object functions. The driver
callback functions are obsolete. So this patch renames them and turns
them into static internal functions of the VRAM helper library. The
implementation of gem_prime_mmap is now unused and the patch removes it.
v3:
* k
The GEM object's free function is now called through struct
drm_gem_object_funcs.free. The function struct drm_driver.gem_prime_mmap
is now required for mmap'ing GEM objects to userspace.
v2:
* set drm_driver.gem_prime_mmap to drm_gem_prime_mmap()
Signed-off-by: Thomas Zimmermann
Acked-b
The vbox driver uses VRAM helpers for memory management. These helpers
provide a basic implementation of PRIME functions, so the vbox driver's
empty implmentation can be removed. As a side effect of this change,
vbox can now use generic framebuffer emulation.
Signed-off-by: Thomas Zimmermann
Revi
Hi,
> /**
> - * drm_gem_vram_driver_gem_free_object_unlocked() - \
> - Implements &struct drm_driver.gem_free_object_unlocked
> - * @gem: GEM object. Refers to &struct drm_gem_vram_object.gem
> + * drm_gem_vram_object_free() - \
> + Implements &struct drm_gem_object_funcs.free
> + *
From: Colin Ian King
There is a spelling mistake in a variable name, fix this by renaming
it to enable.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/d
On Mon, Jul 01, 2019 at 11:00:21AM +0300, Oleg Vasilev wrote:
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this inf
On Sun, Jun 30, 2019 at 1:36 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Now that we can deal gracefully with bootloader (firmware) initialized
> display on aarch64 laptops[1], the next step is to deal with the fact
> that the same model of laptop can have one of multiple different panels.
> (For
On Tue, Jul 02, 2019 at 12:59:53PM +0200, Jean-Jacques Hiblot wrote:
> Hi Daniel,
>
> On 02/07/2019 11:54, Daniel Thompson wrote:
> > On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
> > > From: Tomi Valkeinen
> > >
> > > This patch adds a led-backlight driver (led_bl), which
On Tue, Jul 02, 2019 at 07:21:29AM -0400, Brian Dodge wrote:
>
> On 7/2/19 5:26 AM, Daniel Thompson wrote:
> > > [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for
> > > ArcticSand arcxcnn driver bindings
> > The "v2" is normally applied to the whole patchset (if you
> > prepare the patchse
On Fri, Jun 28, 2019 at 02:43:18PM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 5:24 PM Daniel Vetter wrote:
> > On Thu, Jun 27, 2019 at 02:42:43PM -0400, Kenny Ho wrote:
> > > Um... I am going to get a bit philosophical here and suggest that the
> > > idea of sharing (especially uncontrolled
On Fri, Jun 28, 2019 at 03:49:28PM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 2:11 AM Daniel Vetter wrote:
> > I feel like a better approach would by to add a cgroup for the various
> > engines on the gpu, and then also account all the sdma (or whatever the
> > name of the amd copy engines i
On Sun, Jun 30, 2019 at 01:10:28AM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 3:24 AM Daniel Vetter wrote:
> > Another question I have: What about HMM? With the device memory zone
> > the core mm will be a lot more involved in managing that, but I also
> > expect that we'll have classic buff
https://bugs.freedesktop.org/show_bug.cgi?id=110730
emersion changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sun, Jun 30, 2019 at 08:19:19AM +0200, Sam Ravnborg wrote:
> The macro DRM_VRAM_MM_FILE_OPERATIONS referencs
> functions declared in other header files.
> Include these header files so this header files
> pulls in what it references.
>
> Signed-off-by: Sam Ravnborg
> Cc: Maarten Lankhorst
> C
Hi Oleg,
On Mon, 1 Jul 2019 at 09:00, Oleg Vasilev wrote:
>
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this inf
On Fri, Jun 28, 2019 at 7:32 PM Koenig, Christian
wrote:
>
> Am 28.06.19 um 18:40 schrieb Daniel Vetter:
> > On Fri, Jun 28, 2019 at 5:21 PM Koenig, Christian
> > wrote:
> >> Am 28.06.19 um 16:38 schrieb Daniel Vetter:
> >> [SNIP]
> >>> - when you submit command buffers, you _dont_ attach fen
On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo wrote:
>
> On 7/1/2019 12:58 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
> >>
> >> On 6/30/2019 9:01 AM, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Do an extra enable/disable cycle at init, to get the clks into
On 19.04.2019 10:19, Ronald Tschalär wrote:
> commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
> of RC_CORE) changed the driver to select both RC_CORE and INPUT.
> However, this causes problems with other drivers, in particular an input
> driver that depends on MFD_INTEL_LPSS_
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #52 from Talha Khan ---
(In reply to Ondrej Lang from comment #50)
> I tested this yesterday with kernel 5.1.8 and if the file raven_dmcu.bin is
> present in the /lib/firmware/amdgpu/ folder when you are updating the kernel
> (or man
Due to the tracking provided by the scheduler we know exactly which
submit is failing. Only dump this single submit and the required
auxiliary information. This cuts down the size of the devcoredumps
by only including relevant information.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/e
All callers pass no_wait = false.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 5 ++---
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
dif
Rework fencing workflow. Stop using ttm helpers, use the
virtio_gpu_array_* helpers instead.
Due to using the gem reservation object it is initialized and ready for
use before calling ttm_bo_init. So we can simply use the standard
fencing workflow and drop the tricky logic which checks whenever
No need to do the reservation dance,
we can just wait on the fence directly.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane
No users left.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 39 --
2 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/
No users left.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 1 -
drivers/gpu/drm/virtio/virtgpu_object.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/vi
Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl.
Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work
on the reservation objects directly) instead.
New workflow:
(1) All gem objects needed by a command are added to a
virtio_gpu_object_array.
(2) All res
With this gem and ttm will use the same reservation object,
so mixing and matching ttm / gem reservation helpers should
work fine.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 35 +++---
drivers/gpu/drm/virtio/virtgpu_vq.c| 8 --
3 files changed, 23 insertions(+), 23 de
Make sure we don't leak half-initialized fences outside the driver.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 70d6c4329778.
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 577a8103670e..78dc5a19a358 100644
--- a/drivers/gpu/drm/virt
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_gem.c | 24 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 ++
3 files changed, 19 insertions(+), 19 delet
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/vi
virtio-gpu basically needs a sg_table for the bo, to tell the host where
the backing pages for the object are. So the gem shmem helpers are a
perfect fit. Some drm_gem_object_funcs need thin wrappers to update the
host state, but otherwise the helpers handle everything just fine.
Once the fencin
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
v4: check for EINTR only.
v3: check for EINTR too.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Some helper functions to manage an array of gem objects.
v6:
- add ticket to struct virtio_gpu_object_array.
- add virtio_gpu_array_{lock,unlock}_resv helpers.
- add virtio_gpu_array_add_fence helper.
v5: some small optimizations (Chia-I Wu).
v4: make them virtio-private instead of generic help
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
v5: handle lookup failure.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index d99c54abd090..23670109d167 100644
--- a/drivers/gpu/dr
ttm increasingly gets into the way while hacking on virtio-gpu memory
management. It also overkill for what virtio-gpu needs. Lets get rid
of it.
v6:
- largely rewrite fencing logic, using the virtio_gpu_array_* helpers
- add more patches to the series.
v5:
- fence bugfixes.
- minor optimiza
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 43 --
drivers/gpu/drm/virtio/virtgpu_vq.c| 5 ++-
3 files changed, 25 insertions(+), 25 deleti
On Fri, 28 Jun 2019 at 17:45, Daniel Vetter wrote:
>
> On Fri, Jun 28, 2019 at 06:01:14PM +0200, Andrzej Pietrasiewicz wrote:
> > It is difficult for a user to know which of the i2c adapters is for which
> > drm connector. This series addresses this problem.
> >
> > The idea is to have a symbolic
On Fri, 28 Jun 2019 12:39:05 +0200
Arnd Bergmann wrote:
> mode->name is a character array in a structure, checking it's
> address is pointless and causes a warning with some compilers:
>
> drivers/gpu/drm/drm_connector.c:144:15: error: address of array 'mode->name'
> will always evaluate to 'tr
Daniel,
On 02/07/2019 15:04, Daniel Thompson wrote:
On Tue, Jul 02, 2019 at 12:59:53PM +0200, Jean-Jacques Hiblot wrote:
Hi Daniel,
On 02/07/2019 11:54, Daniel Thompson wrote:
On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a led-ba
Hi Rob,
Thank you for the patch.
On Sun, Jun 30, 2019 at 08:01:43AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Request the enable gpio ASIS to avoid disabling bridge during probe, if
> already enabled. And if already enabled, defer enabling runpm until
> attach to avoid cutting off the powe
On Tue, Jul 02, 2019 at 12:30:14AM +0530, Jagan Teki wrote:
> On Tue, Jun 25, 2019 at 8:07 PM Maxime Ripard
> wrote:
> > > > > > > > > BSP has tcon_div and dsi_div. dsi_div is dynamic which
> > > > > > > > > depends on
> > > > > > > > > bpp/lanes and it indeed depends on PLL computation (not
>
From the comments , "we will loop GPUs that already be processed (with
lower value of proximity_domain) ", the device should already been
added into the topology_device_list. So in this case ,
kfd_topology_device_by_proximity_domain will not return a NULL pointer.
If you really get the nu
On Tue, Jul 2, 2019 at 8:20 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Sun, Jun 30, 2019 at 08:01:43AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Request the enable gpio ASIS to avoid disabling bridge during probe, if
> > already enabled. And if already e
On Tue, Jul 2, 2019 at 8:59 PM Maxime Ripard wrote:
>
> On Tue, Jul 02, 2019 at 12:30:14AM +0530, Jagan Teki wrote:
> > On Tue, Jun 25, 2019 at 8:07 PM Maxime Ripard
> > wrote:
> > > > > > > > > > BSP has tcon_div and dsi_div. dsi_div is dynamic which
> > > > > > > > > > depends on
> > > > > >
From: Rob Clark
The bridge has pretty good docs, lets add a link to make them easier to
find.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
in
From: Rob Clark
Noticed while comparing register dump of how bootloader configures DSI
vs how kernel configures. It seems the bridge still works either way,
but fixing this clears the 'CHA_DATATYPE_ERR' error status bit.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +
From: Rob Clark
Add a debugfs file to show status registers.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index
From: Rob Clark
In process of debugging panel on my lenovo yoga c630, I noticed some
errors in the dsi->mode_flags, which I guess were just cargo-cult'd?
Since dumping the status regs was useful to notice this problem, I
cleaned it up and turned it into debugfs. The last patch corrects the
mode
Add devm_clk_get call to retrieve reference to master clock.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Olivier Moysan
---
drivers/gpu/drm/bridge/sii902x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/driver
The master clock on i2s bus is not mandatory,
as sii902X internal PLL can be used instead.
Make use of mclk optional.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Olivier Moysan
---
drivers/gpu/drm/bridge/sii902x.c | 39 +++
Fix audio master clock use for Silab sii902x HDMI transceiver.
Make audio master clock optional, as this clock is not mandatory.
Olivier Moysan (3):
drm/bridge: sii902x: fix missing reference to mclk clock
dt-bindings: display: sii902x: Change audio mclk binding
drm/bridge: sii902x: make aud
As stated in SiL9022/24 datasheet, master clock is not required for I2S.
Make mclk property optional in DT bindings.
Fixes: 3f18021f43a3 ("dt-bindings: display: sii902x: Add HDMI audio bindings")
Signed-off-by: Olivier Moysan
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 5
On 07/06/2019 20:35, Andrew F. Davis wrote:
Hello all,
So I've got a new IP on our new SoC I'm looking to make use of and would
like some help figuring out what framework best matches its function. The
IP is called a "Page-based Address Translator" or PAT. A PAT instance
(there are 5 of these th
On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Add a debugfs file to show status registers.
>
> Signed-off-by: Rob Clark
Reviewed-by: Jeffrey Hugo
On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Noticed while comparing register dump of how bootloader configures DSI
> vs how kernel configures. It seems the bridge still works either way,
> but fixing this clears the 'CHA_DATATYPE_ERR' error status bit.
>
> Signed-off-
On Tue, Jul 2, 2019 at 10:09 AM Jeffrey Hugo wrote:
>
> On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Noticed while comparing register dump of how bootloader configures DSI
> > vs how kernel configures. It seems the bridge still works either way,
> > but fixing
On Fri, 14 Jun 2019 at 19:02, Koenig, Christian
wrote:
>
> Am 14.06.19 um 19:33 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently the AMDGPU_CTX_PRIORITY_* defines are used in both
> > drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority.
> >
> > Extend the comment to mentio
On Tue, Jul 2, 2019 at 11:12 AM Rob Clark wrote:
>
> On Tue, Jul 2, 2019 at 10:09 AM Jeffrey Hugo wrote:
> >
> > On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
> > >
> > > - dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> > > MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> > > - MIP
On Wed, Jun 26, 2019 at 12:53 AM Brendan Higgins
wrote:
>
> On Tue, Jun 25, 2019 at 4:22 PM Luis Chamberlain wrote:
> >
> > On Mon, Jun 17, 2019 at 01:26:02AM -0700, Brendan Higgins wrote:
> > > diff --git a/kunit/example-test.c b/kunit/example-test.c
> > > new file mode 100644
> > > index 00
On 2019-07-01 03:29, d...@codeaurora.org wrote:
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu encode
I think this could happen if KFD initialization fails for a device.
Currently we'd add the device, and then remove it again. That may leave
a gap in the proximity domains. Oak just had a fix recently to clean
that up by only adding KFD devices to the topology after successful
initialization.
R
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Adrian Salido (1):
libdrm: reduce number of reallocations in drmModeAtomicAddProperty
Chunming Zhou (9):
add cs chunk for syncobj timeline
add timeline wait/query ioctl v2
wrap syncobj timeline query/wait APIs for amdgpu v3
On 2019-07-02 11:21, Jeykumar Sankaran wrote:
On 2019-07-01 03:29, d...@codeaurora.org wrote:
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder s
Hi,
On Tue, Jul 2, 2019 at 4:26 AM Ezequiel Garcia wrote:
>
> Hi Heiko,
>
> On Fri, 2019-06-21 at 18:13 -0300, Ezequiel Garcia wrote:
> > Let's support Gamma LUT configuration on RK3288 SoCs.
> >
> > In order to do so, this series adds a new and optional
> > address resource.
> >
> > A separate a
From: Rob Clark
One of the challenges we need to handle to enable the aarch64 laptops
upstream is dealing with the fact that the bootloader enables the
display and takes the corresponding SMMU context-bank out of BYPASS.
Unfortunately, currently, the IOMMU framework attaches a DMA (or
potentially
From: Rob Clark
Avoid attaching any non-driver managed domain if the driver indicates
that it manages the iommu directly.
This solves a couple problems that drm/msm + arm-smmu has with the iommu
framework:
1) In some cases the bootloader takes the iommu out of bypass and
enables the display.
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/dri
On Fri, Jun 28, 2019 at 12:31 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 70 ++-
> 1 file changed, 51 insertions(+), 19 deletions(-)
>
1 - 100 of 135 matches
Mail list logo
