Re: linux-next: build failure after merge of the drm-msm tree

On Mon, Jul 23, 2018 at 12:50 AM, Stephen Rothwell wrote: > Hi Rob, > > [Dave, this will presumably soon turn up in the drm tree] > > After merging the drm-msm tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c: In function

Re: linux-next: build failure after merge of the drm-msm tree

On Mon, Jul 23, 2018 at 12:50 AM, Stephen Rothwell wrote: > Hi Rob, > > [Dave, this will presumably soon turn up in the drm tree] > > After merging the drm-msm tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c: In function

Re: [PATCH v5 1/8] interconnect: Add generic on-chip interconnect API

On Tue, Jun 26, 2018 at 4:57 PM, Evan Green wrote: > Hi Georgi. Thanks for the new spin of this. > > On Wed, Jun 20, 2018 at 5:11 AM Georgi Djakov > wrote: >> >> This patch introduce a new API to get requirements and configure the >> interconnect buses across the entire chipset to fit with the

Re: [PATCH v5 1/8] interconnect: Add generic on-chip interconnect API

On Tue, Jun 26, 2018 at 4:57 PM, Evan Green wrote: > Hi Georgi. Thanks for the new spin of this. > > On Wed, Jun 20, 2018 at 5:11 AM Georgi Djakov > wrote: >> >> This patch introduce a new API to get requirements and configure the >> interconnect buses across the entire chipset to fit with the

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

gt;>> >>>> On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 04/04/2018 08:58 AM, Daniel Vetter wrote: >>>>>> >>>>>> On Wed, Apr 4, 2018 at 12

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

n Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 04/04/2018 08:58 AM, Daniel Vetter wrote: >>>>>> >>>>>> On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark >>&

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 1:41 PM, Noralf Trønnes <nor...@tronnes.org> wrote: > > > Den 04.04.2018 00.42, skrev Rob Clark: >> >> Add an atomic helper to implement dirtyfb support. This is needed to >> support DSI command-mode panels with x11 userspace (ie. w

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 1:41 PM, Noralf Trønnes wrote: > > > Den 04.04.2018 00.42, skrev Rob Clark: >> >> Add an atomic helper to implement dirtyfb support. This is needed to >> support DSI command-mode panels with x11 userspace (ie. when we can't >> rel

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 8:26 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark <robdcl...@gmail.com> wrote: >> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst >> <maarten.lankho...@linux.intel.com> wrote: >>> Op 04-04-

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 8:26 AM, Daniel Vetter wrote: > On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark wrote: >> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst >> wrote: >>> Op 04-04-18 om 13:37 schreef Rob Clark: >>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten L

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 8:16 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Wed, Apr 04, 2018 at 07:40:32AM -0400, Rob Clark wrote: >> On Wed, Apr 4, 2018 at 5:56 AM, Daniel Vetter <dan...@ffwll.ch> wrote: >> > On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellst

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 8:16 AM, Daniel Vetter wrote: > On Wed, Apr 04, 2018 at 07:40:32AM -0400, Rob Clark wrote: >> On Wed, Apr 4, 2018 at 5:56 AM, Daniel Vetter wrote: >> > On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote: >> >> On 04/04/2018

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst <maarten.lankho...@linux.intel.com> wrote: > Op 04-04-18 om 13:37 schreef Rob Clark: >> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst >> <maarten.lankho...@linux.intel.com> wrote: >>> Op 04-04-18 om 12:21 sch

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst wrote: > Op 04-04-18 om 13:37 schreef Rob Clark: >> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst >> wrote: >>> Op 04-04-18 om 12:21 schreef Daniel Vetter: >>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Da

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

> Hi, >> > > >> > > On 04/04/2018 08:58 AM, Daniel Vetter wrote: >> > > > On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark <robdcl...@gmail.com> wrote: >> > > > > Add an atomic helper to implement dirtyfb support. This is needed

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

> >> > > On 04/04/2018 08:58 AM, Daniel Vetter wrote: >> > > > On Wed, Apr 4, 2018 at 12:42 AM, Rob Clark wrote: >> > > > > Add an atomic helper to implement dirtyfb support. This is needed to >> > > > > support DSI command-mode

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst <maarten.lankho...@linux.intel.com> wrote: > Op 04-04-18 om 12:21 schreef Daniel Vetter: >> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote: &

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst wrote: > Op 04-04-18 om 12:21 schreef Daniel Vetter: >> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote: >>>> Add an atomic helpe

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 6:21 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote: >> > Add an atomic helper to implement dirtyfb support. This is needed to

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Wed, Apr 4, 2018 at 6:21 AM, Daniel Vetter wrote: > On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote: >> > Add an atomic helper to implement dirtyfb support. This is needed to >> > supp

[RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

didn't change, the drm_atomic_state::dirty flag is added. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- Background: there are a number of different folks working on getting upstream kernel working on various different phones/tablets with qcom SoC's.. many of them have command mode pane

[RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

didn't change, the drm_atomic_state::dirty flag is added. Signed-off-by: Rob Clark --- Background: there are a number of different folks working on getting upstream kernel working on various different phones/tablets with qcom SoC's.. many of them have command mode panels, so we kind of need a way

Re: [RFC 4/4] drm/msm/mdp5: writeback support

On Fri, Feb 23, 2018 at 11:30 AM, Sean Paul <seanp...@chromium.org> wrote: > On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote: >> In a way, based on the original writeback patch from Jilai Wang, but a >> lot has shifted around since then. >> >>

Re: [RFC 4/4] drm/msm/mdp5: writeback support

On Fri, Feb 23, 2018 at 11:30 AM, Sean Paul wrote: > On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote: >> In a way, based on the original writeback patch from Jilai Wang, but a >> lot has shifted around since then. >> >> Signed-off-by: Rob Clark >> ---

Re: [RFC 1/4] drm: Add writeback connector type

On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul wrote: > > Have we considered hiding writeback behind a client cap instead? It is kinda *almost* unneeded, since the connector reports itself as disconnected. I'm not sure what the reason was to drop the cap, but I think it

Re: [RFC 1/4] drm: Add writeback connector type

On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul wrote: > > Have we considered hiding writeback behind a client cap instead? It is kinda *almost* unneeded, since the connector reports itself as disconnected. I'm not sure what the reason was to drop the cap, but I think it would be better to have a

Re: [RFC 1/4] drm: Add writeback connector type

On Fri, Feb 23, 2018 at 9:00 AM, Liviu Dudau <liviu.du...@arm.com> wrote: > Hi Rob, > > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote: >> From: Brian Starkey <brian.star...@arm.com> >> >> Writeback connectors represent writeback engines which c

Re: [RFC 1/4] drm: Add writeback connector type

On Fri, Feb 23, 2018 at 9:00 AM, Liviu Dudau wrote: > Hi Rob, > > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote: >> From: Brian Starkey >> >> Writeback connectors represent writeback engines which can write the >> CRTC output to a memory framebuffe

[RFC 4/4] drm/msm/mdp5: writeback support

In a way, based on the original writeback patch from Jilai Wang, but a lot has shifted around since then. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 23 +- drivers/gpu/drm/msm/dis

[RFC 4/4] drm/msm/mdp5: writeback support

In a way, based on the original writeback patch from Jilai Wang, but a lot has shifted around since then. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 23 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 38

[RFC 2/4] drm: writeback: Add out-fences for writeback connectors

anas...@arm.com> Signed-off-by: Liviu Dudau <liviu.du...@arm.com> Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/drm_atomic.c| 99 drivers/gpu/drm/drm_writeback.c | 109 +++- include

[RFC 2/4] drm: writeback: Add out-fences for writeback connectors

out_fence fd (change out_fence_ptr to s32 __user *, for real this time.) - Update documentation around WRITEBACK_OUT_FENCE_PTR Signed-off-by: Brian Starkey [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov Signed-off-by: Liviu Dudau Signed-off-by: Rob Clark --- drivers/gpu/drm

[RFC 3/4] drm/msm/mdp5: add config for writeback pipes

headers (since rnndb register docs for WB had been merged long ago). Also fixes LM3 offset. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h | 2 -- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 17 +++-- drivers/gpu/drm/msm/disp/mdp5/mdp5

[RFC 3/4] drm/msm/mdp5: add config for writeback pipes

headers (since rnndb register docs for WB had been merged long ago). Also fixes LM3 offset. Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h | 2 -- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 17 +++-- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h | 11

[RFC 1/4] drm: Add writeback connector type

-off-by: Mihail Atanassov <mihail.atanas...@arm.com> Signed-off-by: Liviu Dudau <liviu.du...@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdcl...@gmail.com> --- Documentation/gpu/drm-kms.rst| 9 ++ drivers/gpu/d

[RFC 1/4] drm: Add writeback connector type

sed and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark --- Documentation/gpu/drm-kms.rst| 9 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 130 drivers/gpu/drm/drm_atomic_helper.c |

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Thu, Feb 22, 2018 at 3:13 AM, Tomasz Figa wrote: > On Fri, Feb 16, 2018 at 9:13 AM, Tomasz Figa wrote: >> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy wrote: >>> On 15/02/18 04:17, Tomasz Figa wrote: >>> [...] > > Could

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Thu, Feb 22, 2018 at 3:13 AM, Tomasz Figa wrote: > On Fri, Feb 16, 2018 at 9:13 AM, Tomasz Figa wrote: >> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy wrote: >>> On 15/02/18 04:17, Tomasz Figa wrote: >>> [...] > > Could you elaborate on what kind of locking you are concerned about?

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 11:36 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >> > On Wed, Feb 21,

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 11:36 AM, Ville Syrjälä wrote: > On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä >> wrote: >> > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote: >> >> On Wed, Feb

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >> > On Wed, Feb 21,

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä wrote: > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä >> wrote: >> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote: >> >> On Wed, Feb

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >> > On Wed, Feb 21,

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä wrote: > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä >> wrote: >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote: >> >> On Wed, Fe

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä >> <ville.syrj...@linux.intel.com> wrote: >> > On Wed, Feb 21,

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä wrote: > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote: >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä >> wrote: >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote: >> >> Follow the s

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote: >> Follow the same pattern of locking as with other state objects. This >> avoids boilerplate in the driver. > > I'm no

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä wrote: > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote: >> Follow the same pattern of locking as with other state objects. This >> avoids boilerplate in the driver. > > I'm not sure we really want to do this. Wha

[PATCH 3/4] drm/msm/mdp5: Use the new private_obj state

lock alredy taken. - References to "mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Signed-off-by: Archit Taneja <arch...@codeaurora.org> Signed-off-by: Rob Clark

[PATCH 4/4] drm/msm: Don't subclass drm_atomic_state anymore

his state within drm_atomic_state itself using the private objects. Remove the infrastructure that allowed subclassing of drm_atomic_state in the driver. Signed-off-by: Archit Taneja <arch...@codeaurora.org> Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/m

[PATCH 3/4] drm/msm/mdp5: Use the new private_obj state

uot;mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Signed-off-by: Archit Taneja Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 10

[PATCH 4/4] drm/msm: Don't subclass drm_atomic_state anymore

self using the private objects. Remove the infrastructure that allowed subclassing of drm_atomic_state in the driver. Signed-off-by: Archit Taneja Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 46 drivers/gpu/drm/msm/disp/mdp5/mdp5_

[PATCH 2/4] drm/msm/mdp5: Add global state as a private atomic object

around it. These will be removed later once we mdp5_global_state is put to use everywhere. Signed-off-by: Archit Taneja <arch...@codeaurora.org> Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 79 drivers/gpu

[PATCH 2/4] drm/msm/mdp5: Add global state as a private atomic object

later once we mdp5_global_state is put to use everywhere. Signed-off-by: Archit Taneja Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 79 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 24 ++ 2 files changed, 103 insertions(+) diff

[PATCH 1/4] drm/atomic: integrate modeset lock with private objects

Follow the same pattern of locking as with other state objects. This avoids boilerplate in the driver. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/drm_atomic.c | 9 - include/drm/drm_atomic.h | 5 + 2 files changed, 13 insertions(+), 1 deletion(-)

[PATCH 1/4] drm/atomic: integrate modeset lock with private objects

Follow the same pattern of locking as with other state objects. This avoids boilerplate in the driver. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_atomic.c | 9 - include/drm/drm_atomic.h | 5 + 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Wed, Feb 14, 2018 at 11:09 PM, Tomasz Figa <tf...@chromium.org> wrote: > On Thu, Feb 15, 2018 at 1:12 AM, Rob Clark <robdcl...@gmail.com> wrote: >> On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse <jcro...@codeaurora.org> >> wrote: >>> On Wed, Feb 14, 2

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Wed, Feb 14, 2018 at 11:09 PM, Tomasz Figa wrote: > On Thu, Feb 15, 2018 at 1:12 AM, Rob Clark wrote: >> On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse >> wrote: >>> On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote: >>>> >>>> - Whe

Re: [RFT PATCH] drm/msm: Trigger fence completion from GPU

On Wed, Feb 14, 2018 at 1:46 AM, Bjorn Andersson wrote: > Interrupt commands causes the CP to trigger an interrupt as the command > is processed, regardless of the GPU being done processing previous > commands. This is seen by the interrupt being delivered before the >

Re: [RFT PATCH] drm/msm: Trigger fence completion from GPU

On Wed, Feb 14, 2018 at 1:46 AM, Bjorn Andersson wrote: > Interrupt commands causes the CP to trigger an interrupt as the command > is processed, regardless of the GPU being done processing previous > commands. This is seen by the interrupt being delivered before the > fence is written on 8974

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse wrote: > On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote: >> >> - When submitting commands to the GPU, the GPU driver will >> pm_runtime_get_sync() on the GPU device, which will automatically do >> the same on all

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Wed, Feb 14, 2018 at 10:48 AM, Jordan Crouse wrote: > On Wed, Feb 14, 2018 at 12:31:29PM +0900, Tomasz Figa wrote: >> >> - When submitting commands to the GPU, the GPU driver will >> pm_runtime_get_sync() on the GPU device, which will automatically do >> the same on all the linked suppliers,

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa <tf...@chromium.org> wrote: > On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark <robdcl...@gmail.com> wrote: >> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa <tf...@chromium.org> wrote: >>> Hi Vivek, >>> >>&g

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote: > On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote: >> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: >>> Hi Vivek, >>> >>> Thanks for the patch. Please see my comments inline. >>> >

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: > Hi Vivek, > > Thanks for the patch. Please see my comments inline. > > On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam > wrote: >> While handling the concerned iommu, there should not be a >> need

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote: > Hi Vivek, > > Thanks for the patch. Please see my comments inline. > > On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam > wrote: >> While handling the concerned iommu, there should not be a >> need to power control the drm devices from iommu

Re: [PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference

On Fri, Feb 2, 2018 at 11:30 AM, Jordan Crouse wrote: > On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote: >> _minor_ is being dereferenced before it is null checked, hence there >> is a potential null pointer dereference. Fix this by moving the pointer

Re: [PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference

On Fri, Feb 2, 2018 at 11:30 AM, Jordan Crouse wrote: > On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote: >> _minor_ is being dereferenced before it is null checked, hence there >> is a potential null pointer dereference. Fix this by moving the pointer >> dereference after

Re: [PATCH 2/2] drm/msm/adreno: fix nvmem related link error

On Mon, Jan 15, 2018 at 11:14 AM, Arnd Bergmann wrote: > When NVMEM is configured as a loadable module, and adreno > is built-in, we get a link failure: > > drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init': > a5xx_gpu.c:(.text+0x15cc): undefined reference to

Re: [PATCH 2/2] drm/msm/adreno: fix nvmem related link error

On Mon, Jan 15, 2018 at 11:14 AM, Arnd Bergmann wrote: > When NVMEM is configured as a loadable module, and adreno > is built-in, we get a link failure: > > drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_init': > a5xx_gpu.c:(.text+0x15cc): undefined reference to `nvmem_cell_get' >

[PATCH] drm/vmwgfx: fix memory corruption with legacy/sou connectors

From: Rob Clark <rcl...@redhat.com> It looks like in all cases 'struct vmw_connector_state' is used. But only in stdu connectors, was atomic_{duplicate,destroy}_state() properly subclassed. Leading to writes beyond the end of the allocated connector state block and all sorts of fun

[PATCH] drm/vmwgfx: fix memory corruption with legacy/sou connectors

From: Rob Clark It looks like in all cases 'struct vmw_connector_state' is used. But only in stdu connectors, was atomic_{duplicate,destroy}_state() properly subclassed. Leading to writes beyond the end of the allocated connector state block and all sorts of fun memory corruption related

Re: [PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr

On Sat, Jan 6, 2018 at 10:59 AM, Rob Clark <robdcl...@gmail.com> wrote: > Fixes broken dp on GF119: > > Call Trace: >? nvkm_dp_train_drive+0x183/0x2c0 [nouveau] >nvkm_dp_acquire+0x4f3/0xcd0 [nouveau] >nv50_disp_super_2_2+0x5d/0x470 [nouveau] >? nv

Re: [PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr

On Sat, Jan 6, 2018 at 10:59 AM, Rob Clark wrote: > Fixes broken dp on GF119: > > Call Trace: >? nvkm_dp_train_drive+0x183/0x2c0 [nouveau] >nvkm_dp_acquire+0x4f3/0xcd0 [nouveau] >nv50_disp_super_2_2+0x5d/0x470 [nouveau] >? nvkm_devinit_pll_

[PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr

-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c index a2978a37b4f3..700fc754f28a

[PATCH] drm/nouveau/disp/gf119: add missing drive vfunc ptr

-off-by: Rob Clark --- drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c index a2978a37b4f3..700fc754f28a 100644 --- a/drivers/gpu/drm

Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API

On Fri, Sep 8, 2017 at 1:18 PM, Georgi Djakov wrote: > This patch introduce a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current demand. > > The API is using a consumer/provider-based model, where the

Re: [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API

On Fri, Sep 8, 2017 at 1:18 PM, Georgi Djakov wrote: > This patch introduce a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current demand. > > The API is using a consumer/provider-based model, where the providers are > the

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On Tue, Nov 28, 2017 at 8:43 AM, Vivek Gautam <vivek.gau...@codeaurora.org> wrote: > > > On 11/28/2017 05:13 AM, Rob Clark wrote: >> >> On Mon, Nov 27, 2017 at 5:22 PM, Stephen Boyd<sb...@codeaurora.org> >> wrote: >>> >>> On 11/15, Vivek

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On Tue, Nov 28, 2017 at 8:43 AM, Vivek Gautam wrote: > > > On 11/28/2017 05:13 AM, Rob Clark wrote: >> >> On Mon, Nov 27, 2017 at 5:22 PM, Stephen Boyd >> wrote: >>> >>> On 11/15, Vivek Gautam wrote: >>>> >>>> Hi, >>>&g

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On Mon, Nov 27, 2017 at 5:22 PM, Stephen Boyd <sb...@codeaurora.org> wrote: > On 11/15, Vivek Gautam wrote: >> Hi, >> >> >> On Mon, Aug 7, 2017 at 5:59 PM, Rob Clark <robdcl...@gmail.com> wrote: >> > On Mon, Aug 7, 2017 at 4:27 AM, Vivek

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On Mon, Nov 27, 2017 at 5:22 PM, Stephen Boyd wrote: > On 11/15, Vivek Gautam wrote: >> Hi, >> >> >> On Mon, Aug 7, 2017 at 5:59 PM, Rob Clark wrote: >> > On Mon, Aug 7, 2017 at 4:27 AM, Vivek Gautam >> > wrote: >> >> On Thu, Jul 13,

Re: [PATCH 2/3] ARM: qcom_defconfig: enable MSM IOMMU for display

On Mon, Nov 27, 2017 at 9:34 AM, Jonathan Neuschäfer wrote: > Hi, > > On Mon, Nov 27, 2017 at 11:44:57AM +, srinivas.kandaga...@linaro.org > wrote: >> From: Srinivas Kandagatla >> >> MSM IOMMU is required for apq8064 display, so enable

Re: [PATCH 2/3] ARM: qcom_defconfig: enable MSM IOMMU for display

On Mon, Nov 27, 2017 at 9:34 AM, Jonathan Neuschäfer wrote: > Hi, > > On Mon, Nov 27, 2017 at 11:44:57AM +, srinivas.kandaga...@linaro.org > wrote: >> From: Srinivas Kandagatla >> >> MSM IOMMU is required for apq8064 display, so enable it by default. > > What exactly do you mean by

Re: [PATCH] reservation: don't wait when timeout=0

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > Quoting Rob Clark (2017-11-21 14:08:46) >> If we are testing if a reservation object's fences have been >> signaled with timeout=0 (non-blocking), we need to pass 0 for >> timeou

Re: [PATCH] reservation: don't wait when timeout=0

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson wrote: > Quoting Rob Clark (2017-11-21 14:08:46) >> If we are testing if a reservation object's fences have been >> signaled with timeout=0 (non-blocking), we need to pass 0 for >> timeout to dma_fence_wait_timeout(). >

[PATCH] reservation: don't wait when timeout=0

If we are testing if a reservation object's fences have been signaled with timeout=0 (non-blocking), we need to pass 0 for timeout to dma_fence_wait_timeout(). Plus bonus spelling correction. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/dma-buf/reservation.c | 11

[PATCH] reservation: don't wait when timeout=0

If we are testing if a reservation object's fences have been signaled with timeout=0 (non-blocking), we need to pass 0 for timeout to dma_fence_wait_timeout(). Plus bonus spelling correction. Signed-off-by: Rob Clark --- drivers/dma-buf/reservation.c | 11 +-- 1 file changed, 9

[PATCH] dt-bindings: remove file that was added accidentally

I think this snuck in when I applied the patch for f97decac5f4c (didn't apply cleanly, required some manual applying + git-add). It is unused and shouldn't be here. My bad. Fixes: f97decac5f4c "drm/msm: Support multiple ringbuffers" Signed-off-by: Rob Clark <robdcl...@gmail.com>

[PATCH] dt-bindings: remove file that was added accidentally

I think this snuck in when I applied the patch for f97decac5f4c (didn't apply cleanly, required some manual applying + git-add). It is unused and shouldn't be here. My bad. Fixes: f97decac5f4c "drm/msm: Support multiple ringbuffers" Signed-off-by: Rob Clark --- include/dt-bindings/m

Re: [git pull] drm for v4.15

On Wed, Nov 15, 2017 at 11:59 PM, Linus Torvalds wrote: > On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: >> >> There is some code touched on sound/soc, but I think the sound tree >> should have the same commits from the same base,so this may

Re: [git pull] drm for v4.15

On Wed, Nov 15, 2017 at 11:59 PM, Linus Torvalds wrote: > On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: >> >> There is some code touched on sound/soc, but I think the sound tree >> should have the same commits from the same base,so this may luck different >> if you pulled it as I generated

Re: linux-next: build warning after merge of the drm-msm tree

On Tue, Oct 31, 2017 at 11:46 PM, Stephen Rothwell wrote: > Hi Rob, > > After merging the drm-msm tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > In file included from include/drm/drm_mm.h:49:0, > from

Re: linux-next: build warning after merge of the drm-msm tree

On Tue, Oct 31, 2017 at 11:46 PM, Stephen Rothwell wrote: > Hi Rob, > > After merging the drm-msm tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > In file included from include/drm/drm_mm.h:49:0, > from include/drm/drmP.h:73, >

[PATCH v2] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark <robdcl...@gmail.com>

[PATCH v2] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark --- v2: add back a hunk

[PATCH] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark <robdcl...@gmail.

[PATCH] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark --- drivers/iommu

[PATCH 2/6] drm/msm: add special _get_vaddr_active() for cmdstream dumps

not apply. (But of course the bo should definitely not be in the PURGED state!) Signed-off-by: Rob Clark <robdcl...@gmail.com> --- drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gem.c | 22 -- drivers/gpu/drm/msm/msm_rd.c | 2 +- 3 files changed, 22 inse

[PATCH 2/6] drm/msm: add special _get_vaddr_active() for cmdstream dumps

not apply. (But of course the bo should definitely not be in the PURGED state!) Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gem.c | 22 -- drivers/gpu/drm/msm/msm_rd.c | 2 +- 3 files changed, 22 insertions(+), 3 deletions(-) diff

<    2   3   4   5   6   7   8   9   10   11   >