> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Refactoring of the group control code will soon require more iteration
> over the available groups. Simplify this process by introducing a group
> iteration helper.
>
> Signed-off-by: Kieran Bingham
>
On Fri, Jun 14, 2019 at 10:35:55PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: Shawn Guo
Acked-by: Shawn Guo
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 2 --
>
On Tue, Jun 18, 2019 at 2:31 PM Chris Wilson wrote:
> Quoting Daniel Vetter (2019-06-14 21:36:04)
> > It looks like this was done purely to get a consistent place to look
> > up the reservation object pointer. With the drm_prime.c helper code
> > now also setting gem_object->resv for imported obje
The copy_from_user() function returns the number of bytes remaining
to be copied but we want to return a negative error code. Otherwise
the callers treat it as a successful copy.
Signed-off-by: Dan Carpenter
---
v2: The first version was missing a chunk
drivers/gpu/drm/drm_bufs.c | 5 -
d
On Tue, Jun 18, 2019 at 3:13 PM Laurent Pinchart
wrote:
>
> The recommended way to specify GEM object functions is to provide a
> drm_gem_object_funcs structure instance and set the GEM object to point
> to it. The drm_cma_gem_create_object_default_funcs() function provided
> by the GEM CMA helpe
Hi Daniel,
On Tue, Jun 18, 2019 at 03:21:55PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 3:13 PM Laurent Pinchart
> wrote:
> >
> > The recommended way to specify GEM object functions is to provide a
> > drm_gem_object_funcs structure instance and set the GEM object to point
> > to it.
On Tue, Jun 18, 2019 at 03:08:01PM +0200, Thomas Hellstrom wrote:
> On 6/18/19 2:19 PM, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
> > > Hi Thomas,
> > >
> > > On 2019/06/18, Thomas Hellström (VMware) wrote:
> > > > From: Thomas Hellstrom
> > > >
> > >
On 6/18/19 12:54 PM, Emil Velikov wrote:
Hi Thomas,
On 2019/06/18, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
TTM provides a means to assign eviction priorities to buffer object. This
means that all buffer objects with a lower priority will be evicted first
on memory pressure.
Us
This patch-set contains the DRM panel driver and dt-bindings documentation
for the DSI driven panel: Raydium RM67191.
Changes since v1:
- Fixed 'reset-gpio' to 'reset-gpios' property naming
- Changed the state of the reset gpio to active low and fixed how it is
handled in driver
- Fixed copyrigh
Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras
---
.../bindings/display/panel/raydium,rm67191.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
protocol).
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 709 ++
There are three left-overs from the recent file renames,
probably due to some other conflicting patch.
Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
This patch is against today's next-20190617 branch. Not sure if it
will apply cleanly at -docs tree. If not, Please let me know for me to
sp
On Thu, 2019-06-13 at 15:36 -0400, Ilia Mirkin wrote:
> Note that userspace may provide any size of gamma lut. Have a look at
> i915/intel_color.c:intel_color_check which filters out only the
> allowed sizes. Consider having a special allowance for 256-sized LUTs
> since that's what most legacy use
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Create a new private state object for the DU groups, and move the
> initialisation of a group object to a new function rcar_du_group_init().
>
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent P
On Fri, 2019-06-14 at 13:05 -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 13, 2019 at 12:23 PM Ezequiel Garcia
> wrote:
> > @@ -1744,6 +1793,41 @@ int rockchip_drm_wait_vact_end(struct drm_crtc
> > *crtc, unsigned int mstimeout)
> > }
> > EXPORT_SYMBOL(rockchip_drm_wait_vact_end);
> >
>
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote:
> There are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
Thanks!
Acked-by: Wolfram Sang
signature.asc
Description:
Hi Ulrich,
On Tue, Jun 18, 2019 at 02:32:13PM +0200, Ulrich Hecht wrote:
> > On June 17, 2019 at 11:09 PM Laurent Pinchart
> > wrote:
> >
> > From: Kieran Bingham
> >
> > Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
> > API. The existing vsp1_du_setup_lif() API call
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> From: Kieran Bingham
>
> Create rcar_du_group_atomic_check() and rcar_du_group_atomic_setup()
> functions to track and apply group state through the DRM atomic state.
> The use_count field is moved from the rcar_du_group structu
Den 18.06.2019 15.13, skrev Laurent Pinchart:
> The recommended way to specify GEM object functions is to provide a
> drm_gem_object_funcs structure instance and set the GEM object to point
> to it. The drm_cma_gem_create_object_default_funcs() function provided
> by the GEM CMA helper does so wh
On Tue, Jun 18, 2019 at 04:26:51PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tue, Jun 18, 2019 at 03:21:55PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 3:13 PM Laurent Pinchart
> > wrote:
> > >
> > > The recommended way to specify GEM object functions is to provide a
> > >
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote:
> There are three left-overs from the recent file renames,
> probably due to some other conflicting patch.
>
> Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> This patch is against today's next-20190617 branch.
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --g
Use gem reservation helpers and direct reservation_object_* calls
instead of ttm.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 36 --
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/dri
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 +++---
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 --
All callers pass no_wait = false.
Signed-off-by: Gerd Hoffmann
---
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(-)
diff --git a/drivers/gpu/drm/vi
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
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
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.
cheers,
Gerd
Gerd Hoffmann (12):
drm/virtio: pass gem reservation object to ttm init
drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper.
No users left.
Signed-off-by: Gerd Hoffmann
---
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/virtio/virtgpu_drv.h
inde
Use gem reservation helpers and direct reservation_object_* calls
instead of ttm.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 28 +++--
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/dri
Now with ttm initialization being out of the way we can simplify
virtio_gpu_object_create fencing even more. No need to check whenever
the command is still running after ttm_bo_init() returned. We have a
fully initialized gem bo before we kick off the resource creation
command, so we can simply a
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
I rushed merging this a bit too much, and Noralf pointed out that
we're a lot better already and have made great progress.
Let's try again.
Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
On Tue, Jun 18, 2019 at 03:58:10PM +0200, Gerd Hoffmann wrote:
> Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
> This also makes the ioctl run lockless.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
Nit: Missing the v2 changelog here.
-Daniel
> ---
> driver
On Tue, Jun 18, 2019 at 03:58:14PM +0200, Gerd Hoffmann wrote:
> Call reservation_object_* directly instead
> of using ttm_bo_{reserve,unreserve}.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -
Thank you for your patch.
> On June 17, 2019 at 11:09 PM Laurent Pinchart
> wrote:
>
>
> Routing configuration for the DU is complex. Depending on the SoC
> generation various routing options are available:
>
> - The VSP to DU routing is not available on Gen1, is configurable on
> Gen2 and
On 6/18/19 3:27 PM, Daniel Vetter wrote:
On Tue, Jun 18, 2019 at 03:08:01PM +0200, Thomas Hellstrom wrote:
On 6/18/19 2:19 PM, Daniel Vetter wrote:
On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
Hi Thomas,
On 2019/06/18, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
Den 18.06.2019 16.02, skrev Daniel Vetter:
> I rushed merging this a bit too much, and Noralf pointed out that
> we're a lot better already and have made great progress.
>
> Let's try again.
>
> Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> Cc: Greg Kroah-Hartman
> Cc: Daniel Vetter
On Tue, Jun 18, 2019 at 03:58:15PM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 36 --
> 1 file changed, 17 insertions(+)
On Tue, Jun 18, 2019 at 3:27 AM Krzysztof Kozlowski wrote:
>
> On Sat, 15 Jun 2019 at 01:57, Joseph Kogut wrote:
> >
> > Add device tree node for mali gpu on Odroid XU3 SoCs.
> >
> > Signed-off-by: Joseph Kogut
> > ---
> >
> > Changes v1 -> v2:
> > - Use interrupt name ordering from binding doc
On Tue, Jun 18, 2019 at 04:16:04PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 03:58:15PM +0200, Gerd Hoffmann wrote:
> > Use gem reservation helpers and direct reservation_object_* calls
> > instead of ttm.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > drivers/gpu/drm/virtio/virtgp
On Tue, Jun 18, 2019 at 03:58:16PM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 28 +++--
> 1 file changed, 8 insertions(+),
On Tue, Jun 18, 2019 at 04:14:27PM +0200, Thomas Hellstrom wrote:
> On 6/18/19 3:27 PM, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 03:08:01PM +0200, Thomas Hellstrom wrote:
> > > On 6/18/19 2:19 PM, Daniel Vetter wrote:
> > > > On Tue, Jun 18, 2019 at 11:54:08AM +0100, Emil Velikov wrote:
> >
Hi Ulrich,
On Tue, Jun 18, 2019 at 04:12:01PM +0200, Ulrich Hecht wrote:
> > On June 17, 2019 at 11:09 PM Laurent Pinchart wrote:
> >
> > Routing configuration for the DU is complex. Depending on the SoC
> > generation various routing options are available:
> >
> > - The VSP to DU routing is not
https://bugs.freedesktop.org/show_bug.cgi?id=110944
Bug ID: 110944
Summary: [Bisected] Blender 2.8 crashes when closing certain
windows
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Tue, Jun 18, 2019 at 8:11 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki
> > wrote:
> > >
> > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, Jun 14, 2019 at 12:03:13PM +05
On Tue, 18 Jun 2019 at 16:18, Rob Herring wrote:
>
> On Tue, Jun 18, 2019 at 3:27 AM Krzysztof Kozlowski wrote:
> >
> > On Sat, 15 Jun 2019 at 01:57, Joseph Kogut wrote:
> > >
> > > Add device tree node for mali gpu on Odroid XU3 SoCs.
> > >
> > > Signed-off-by: Joseph Kogut
> > > ---
> > >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110944
--- Comment #1 from Pierre-Eric Pelloux-Prayer
---
Can you test the commit from
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1071? I think it should
fix this issue.
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=110944
--- Comment #2 from Sebastian Parborg ---
Yes that patch seems to solve the issue!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
On Tue, Jun 18, 2019 at 02:17:11PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 02:01:35PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 14, 2019 at 05:37:58PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Fri, Jun
Document RZ/G2M (R8A774A1) SoC bindings.
Signed-off-by: Fabrizio Castro
---
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
b/Docume
Dear All,
this series adds HDMI support to the HiHope RZ/G2M board.
Thanks,
Fab
Fabrizio Castro (3):
dt-bindings: display: renesas: Add r8a774a1 support
arm64: dts: renesas: r8a774a1: Add HDMI encoder instance
arm64: dts: renesas: hihope-common: Add HDMI support
.../bindings/display/brid
On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> Greg is busy already, but maybe he won't do everything ...
>
> Cc: Greg Kroah-Hartman
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/gpu
On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> On Mon, May 20, 2019 at 11:39:42PM +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 Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > Greg is busy already, but maybe he won't do everything ...
> >
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/todo.
Ah crap. I need to fix copy_one_buf32() as well. I will sent a v2.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jun 18, 2019 at 2:13 AM Boris Brezillon
wrote:
>
> mmu_ops->unmap() will fail when called on a BO that has not been
> previously mapped, and the error path in panfrost_ioctl_create_bo()
> can call drm_gem_object_put_unlocked() (which in turn calls
> panfrost_mmu_unmap()) on a BO that has n
On Tue, Jun 18, 2019 at 2:16 AM Boris Brezillon
wrote:
>
> Hello,
>
> This a new version of the panfrost perfcnt series, this time exposing
> this functionality through 2 ioctls instead of the debugfs approach
> used in v2.
>
> I also went for Emil's suggestion to expose those ioctls only when
> t
On 18/06/2019 16:19, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
>> Greg is busy already, but maybe he won't do everything ...
>>
>> Cc: Greg Kroah-Hartman
>> Signed-off-by: Daniel Vetter
>> ---
>> Documentation/gpu/todo.rst | 3 +++
>> 1 file chan
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212 ms
Hi Noralf,
On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
> Den 18.06.2019 15.13, skrev Laurent Pinchart:
> > The recommended way to specify GEM object functions is to provide a
> > drm_gem_object_funcs structure instance and set the GEM object to point
> > to it. The drm_cma_gem_
Hi Fabrizio,
Thank you for the patch.
On Tue, Jun 18, 2019 at 04:18:37PM +0100, Fabrizio Castro wrote:
> Document RZ/G2M (R8A774A1) SoC bindings.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
I don't have pending changes for this file for this kernel release. As
your serie
On Tue, Jun 18, 2019 at 10:26:52AM +0300, Laurent Pinchart wrote:
> Hi Sean,
>
> Thank you for the patch.
>
> On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > drm_atomic_get_crtc_state() returns an error pointer when it fails, so
> > the null check is doing
On Tue, Jun 18, 2019 at 9:36 AM Ezequiel Garcia wrote:
>
> On Thu, 2019-06-13 at 15:36 -0400, Ilia Mirkin wrote:
> > Note that userspace may provide any size of gamma lut. Have a look at
> > i915/intel_color.c:intel_color_check which filters out only the
> > allowed sizes. Consider having a specia
On Tue, Jun 18, 2019 at 04:18:43PM +0300, Dan Carpenter wrote:
> The copy_from_user() function returns the number of bytes remaining
> to be copied but we want to return a negative error code. Otherwise
> the callers treat it as a successful copy.
>
> Signed-off-by: Dan Carpenter
Thanks Dan, I'
Hi Laurent,
On 17/06/2019 22:09, Laurent Pinchart wrote:
> Hello everybody,
>
> This patch series refactors atomic commit tail handling in the R-Car DU
> driver to simplify the code flow, and open the door to further
> optimisations. It takes over Kieran's "[PATCH v2 0/6] drm: rcar-du:
> Rework C
Den 18.06.2019 18.35, skrev Laurent Pinchart:
> Hi Noralf,
>
> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
>> Den 18.06.2019 15.13, skrev Laurent Pinchart:
>>> The recommended way to specify GEM object functions is to provide a
>>> drm_gem_object_funcs structure instance and
Hi!
Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
> Let's add some better support for HDMI audio to dw_hdmi.
> Specifically:
>
> 1. For 44.1 kHz audio the old code made the assumption that an N of
> 6272 was right most of the time. That wasn't true and the new table
On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
wrote:
> On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > Greg is busy already, but maybe he won't do everything ...
> > >
> > > Cc: Greg Kroah-Hartman
>
https://bugzilla.kernel.org/show_bug.cgi?id=201539
Sean Birkholz (supas...@hotmail.com) changed:
What|Removed |Added
CC||supas...@hotmail.co
Den 17.06.2019 16.51, skrev Maxime Ripard:
> Rotations and reflections setup are needed in some scenarios to initialise
> properly the initial framebuffer. Some drivers already had a bunch of
> quirks to deal with this, such as either a private kernel command line
> parameter (omapdss) or on the
On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> wrote:
> > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > > Greg is busy already, bu
On Tuesday, 2019-06-18 16:02:41 +0200, Daniel Vetter wrote:
> I rushed merging this a bit too much, and Noralf pointed out that
> we're a lot better already and have made great progress.
>
> Let's try again.
>
> Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> Cc: Greg Kroah-Hartman
> Cc
On Tue, 2019-06-18 at 02:15 -0300, Ezequiel Garcia wrote:
> On Mon, 2019-06-17 at 12:06 +0200, Jacopo Mondi wrote:
> > Hi Ezequiel,
> >one small question, as I'm working on supporting gamma LUT for
> > rcar-du as well, and there's one point not totally clear to me
> >
> >
> > On Thu, Jun 13,
Mark long numbers with ULL to silence the Smatch warning:
drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1 is
so big it is long long
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/lima/lima_vm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
There is no point to print deferred probe (and its failures to get
resources) as an error.
In case of multiple probe tries this would pollute the dmesg.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/panfrost/panfrost_device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
di
There is no point to print deferred probe (and its failures to get
resources) as an error. For example getting a regulator causes three
unneeded error messages:
lima 1300.gpu: failed to get regulator: -517
lima 1300.gpu: regulator init fail -517
lima 1300.gpu: Fatal error
Add nodes for GPU (Mali 400) to Exynos3250. This is still limited and
not tested:
1. No dynamic voltage and frequency scaling,
2. Not sure what to do with CLK_G3D clock responsible for gating entire
IP block (it is now being disabled as unused).
Signed-off-by: Krzysztof Kozlowski
---
arch/ar
Add vendor compatibles for specific implementation of Mali Utgard
(Exynos3250, Exynos4-family) and Midgard (Exynos5433, Exynos7).
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt |
Hi,
Inspired by patch from Joseph Kogut [1], let's add support for Mali GPUs
to most of other boards. However it was tested only on Odroid U3
(Exynos4412) and not fully because requirement of special Mesa drivers
with Lima support.
Even without tests it brings full description of hardware and re
Correct language typo and wrong indentation.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index b491c345b2e8..ea0e043cd2b
Add ID and gate for bus clock for GPU (Mali 400) on Exynos4412.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos4.c | 1 +
include/dt-bindings/clock/exynos4.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk
Add nodes for GPU (Mali T760) to Exynos5433. Missing element is the
cooling device. Not tested on HW.
Signed-off-by: Krzysztof Kozlowski
---
.../dts/exynos/exynos5433-tm2-common.dtsi | 5 ++
arch/arm64/boot/dts/exynos/exynos5433.dtsi| 51 +++
2 files changed, 56 insert
Add nodes for GPU (Mali T760) to Exynos7. Current support for Exynos7
misses a lot, including proper clocks, power domains, frequency and
voltage scaling and cooling. However this still can provide basic GPU
description. Not tested on HW.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot
Add nodes for GPU (Mali 400) to Exynos4210 and Exynos4412. Describe the
GPU as much as possible however still few elements are missing:
1. Exynos4210 bus clock is not described in hardware manual therefore
the IP gate clock was provided,
2. Exynos4412: Not sure what to do with CLK_G3D clock res
Enable support for Mali GPU with Panfrost driver, e.g. for Exynos5433
and Exynos7 (having Mali T760).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfi
Enable support for Mali GPU with Panfrost and LIMA drivers. Most of
Exynos chipsets come with Mali GPUs:
1. Mali 400 (Exynos3250, Exynos4210, Exynos4412),
2. Mali T7xx (Exynos542x).
As Mali GPU is quite popular among ARM vendors, other platforms will
benefit as well.
Signed-off-by: Krzysztof Koz
Enable support for Mali GPU with Panfrost and LIMA drivers. Most of
Exynos chipsets come with Mali GPUs:
1. Mali 400 (Exynos3250, Exynos4210, Exynos4412),
2. Mali T7xx (Exynos542x).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/configs/exynos_defconfig | 3 ++-
1 file changed, 2 insertions(+)
On Tue, 18 Jun 2019 at 19:42, Joseph Kogut wrote:
> > >
> > > > > + reg = <0x1180 0x5000>;
> > > > > + interrupts = ,
> > > > > + ,
> > > > > + ;
> > > > > + interrupt-names = "job", "mmu", "gpu";
> > > > > +
On Fri, 14 Jun 2019 at 03:52, Andres Rodriguez wrote:
>
> DisplayID blocks allow embedding of CEA blocks. The payloads are
> identical to traditional top level CEA extension blocks, but the header
> is slightly different.
>
> This change allows the CEA parser to find a CEA block inside a DisplayID
On Mon, Jun 17, 2019 at 5:28 AM Christoph Hellwig wrote:
>
> The functionality is identical to the one currently open coded in
> device-dax.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/dax/dax-private.h | 4
> drivers/dax/device.c | 43 ---
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> Hi Dan, Jérôme and Jason,
>
> below is a series that cleans up the dev_pagemap interface so that
> it is more easily usable, which removes the need to wrap it in hmm
> and thus allowing to kill a lot of code
>
> Note: this series is on t
On Mon, Jun 17, 2019 at 04:47:30PM +0300, Serge Semin wrote:
> Hello folks,
>
> Any updates of this patch status? It has been here for about two months.
>
Sorry for the mixup, looks like this one just fell through the cracks. I've
applied it to drm-misc-next with the attached Ack and Review.
Se
From: Rob Clark
Most of this is a resend of things that have already been posted to
list. I've rebased the DPU patches, which was somewhat conflicty due to
other changes and refactoring in the DPU code.
Abhinav Kumar (1):
drm/msm/dpu: add icc voting in dpu_mdss_init
Georgi Djakov (1):
drm/
From: Jayant Shekhar
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- None
Changes in v3:
- Remove common property defi
From: Jayant Shekhar
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various d
From: Abhinav Kumar
dpu_mdss_destroy() can get called not just from
msm_drm_uninit() but also from msm_drm_bind() in case
of any failures.
dpu_mdss_destroy() removes the icc voting by calling
icc_put. This could accidentally remove the voting
done by pm_runtime_enable.
To make the voting balanc
From: Jayant Shekhar
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line (S
101 - 200 of 265 matches
Mail list logo
