t shmem_sg_free_table() to use a folio_batch")
Signed-off-by: Brian Geffon
Suggested-by: Tomasz Figa
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/
On Mon, Jan 27, 2025 at 1:47 PM Ville Syrjälä
wrote:
>
> On Thu, Jan 16, 2025 at 10:53:40AM -0500, Brian Geffon wrote:
> > When converting to folios the cleanup path of shmem_get_pages() was
> > missed. When a DMA remap fails and the max segment size is greater than
> > P
On Wed, Jan 22, 2025 at 10:07 PM Srinivas, Vidya
wrote:
>
> Hello Brian, Many thanks for the fix. I am adding my tested-by.
> Tested-by: Vidya Srinivas
Thanks for testing Vidya.
Can we get a maintainer to take a look?
>
>
> > -Original Message-
> > From:
rnel.org/lkml/20250116135636.410164-1-bgef...@google.com/
Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch")
Signed-off-by: Brian Geffon
Suggested-by: Tomasz Figa
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +--
drivers/gpu/drm/i915/gem
On Thu, Jan 16, 2025 at 9:38 AM Ville Syrjälä
wrote:
>
> On Thu, Jan 16, 2025 at 04:24:26PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> > > When converting to folios the cleanup path of shmem_get_pages() was
> > >
On Thu, Jan 16, 2025 at 9:24 AM Ville Syrjälä
wrote:
>
> On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> > When converting to folios the cleanup path of shmem_get_pages() was
> > missed. When a DMA remap fails and the max segment size is greater than
> > P
On Thu, Jan 16, 2025 at 9:24 AM Ville Syrjälä
wrote:
>
> On Thu, Jan 16, 2025 at 08:56:36AM -0500, Brian Geffon wrote:
> > When converting to folios the cleanup path of shmem_get_pages() was
> > missed. When a DMA remap fails and the max segment size is greater than
> > P
isn't handling compound pages correctly.
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13487
Fixes: 0b62af28f249 ("i915: convert shmem_sg_free_table() to use a folio_batch")
Signed-off-by: Brian Geffon
Suggested-by: Tomasz Figa
---
drivers/gpu/drm/i915/gem/i
el raised. That
needs addressing.
On Thu, Dec 19, 2024 at 07:33:07PM +, Marek Olšák wrote:
> On Thu, Dec 19, 2024 at 5:32 AM Brian Starkey wrote:
>
> > On Wed, Dec 18, 2024 at 09:53:56PM +, Marek Olšák wrote:
>
> The pitch doesn't always describe the layout. In prac
On Wed, Dec 18, 2024 at 09:53:56PM +, Marek Olšák wrote:
> On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
>
> > On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > >
> > > For that reason I think linear modifiers with explicit pitch/size
&g
t is a "special"
constraint (in that it's really a description of the buffer layout),
and that constraints in-general shouldn't be exposed via modifiers?
Cheers,
-Brian
On Tue, Dec 17, 2024 at 11:13:05AM +, Michel Dänzer wrote:
> On 2024-12-17 10:14, Brian Starkey wrote:
> > On Sun, Dec 15, 2024 at 03:53:14PM +, Marek Olšák wrote:
> >> The comment explains the problem with DRM_FORMAT_MOD_LINEAR.
> >>
> >> Signed-off-by:
y - it's a device
constraint. It feels out of place to overload modifiers with it.
I'm not saying we don't need a way to describe constraints to
allocators, but I question if modifiers the right mechanism to
communicate them?
Cheers,
-Brian
o prevent the issue, make the framebuffer_core driver to not register a
> platform device if the global struct screen_info data has been filled.
>
> Reported-by: Brian Norris
> Link:
> https://lore.kernel.org/all/ZuCG-DggNThuF4pj@b20ea791c01f/T/#ma7fb65acbc1a56042258adac910992bb225a2
rs should be switched to use PLATFORM_DEVID_AUTO? Or at least one
of them. Or they should use different base names.
I'm not really sure what the best option is (does anyone rely on or care
about the device naming?), and I don't actually use this driver. But
here's an untested dif
ngle frames for static-screen and testing purposes, and there wasn't
a consensus on how to make a streaming API, so we didn't do it.
> Note, in my humble opinion, it should be perfectly possible to setup
> writeback as a clone to the existing connector (if a clone mode is
> su
ew writeback every frame. It
drains out the last of the data during vblank, before starting on the
next frame. That doesn't help the "general case" though.
>
>If we already have devices where you can use writeback together with real
>outputs, then I guess that counts as an oopsie :-/
Well "works fine" fits into the "undefined behaviour" bucket, just as
well as "corrupts your fb" does :-)
-Brian
>
>Cheers, Sima
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
Vishwanathapura
Cc: Matthew Brost
Cc: Thomas Hellström
Cc: Brian Welty
---
drivers/gpu/drm/xe/xe_gt_pagefault.c | 7 ++
drivers/gpu/drm/xe/xe_svm.c | 116 +++
drivers/gpu/drm/xe/xe_svm.h | 6 ++
drivers/gpu/drm/xe/xe_svm_range.c| 43 ++
4
When the power domains cannot be parsed, the message is incorrectly
logged as an info message. Let's change this to an error since an error
is returned.
Fixes: 92a511a568e4 ("fbdev/simplefb: Add support for generic power-domains")
Signed-off-by: Brian Masney
---
drivers/video/f
-0700, Welty, Brian wrote:
Hi Christian / Thomas,
Wanted to ask if you have explored or thought about adding support in
TTM
such that a ttm_bo could have more than one underlying backing store
segment
(that is, to have a tree of ttm_resources)?
We already use something similar on amdgpu where
BO
Or is the thinking that workloads should use SVM/HMM instead of
GEM_CREATE if they want above benefits?
Is this something you are open to seeing an RFC series that starts
perhaps with just extending ttm_bo_validate() to see how this might
shape up?
-Brian
/a650_zap.mdt");
> +MODULE_FIRMWARE("qcom/a660_gmu.bin");
> +MODULE_FIRMWARE("qcom/a660_sqe.fw");
> +MODULE_FIRMWARE("qcom/a660_zap.mdt");
> +MODULE_FIRMWARE("qcom/leia_pfp_470.fw");
> +MODULE_FIRMWARE("qcom/leia_pm4_470.fw");
> +MODULE_FIRMWARE("qcom/yamato_pfp.fw");
> +MODULE_FIRMWARE("qcom/yamato_pm4.fw");
You should rebase this on top of the latest -next since the a690 needs
to be added as well.
Brian
PSR enabled state.
> + */
> + if (status == DP_PSR_SINK_ACTIVE_RFB) {
> + if ((reg == DP_PSR_SINK_ACTIVE_RFB) &&
> + ((store == DP_PSR_SINK_ACTIVE_SINK_SYNCED) ||
> + (store == DP_PSR_SINK_AC
> clk_prepare_enable(dp->clock);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> - dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
> + dp->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, NULL);
Rather than a NULL 3rd
f course.
v3:
* no update
v2:
* skip unnecessary lock/unlock
Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Cc:
Link: https://lore.kernel.org/dri-devel/y5itf0+yniqa6...@sirena.org.uk/
Reported-by: "kernelci.org bot"
Signed-off-by: Brian Norris
---
drivers/gpu/
lf-refresh
* describe failing test case and relation to drm/rockchip patch better
Cc: # dependency for "drm/rockchip: vop: Leave
# vblank enabled in self-refresh"
Signed-off-by: Brian Norris
---
drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
1 file chang
On Fri, Jan 6, 2023 at 5:23 PM Brian Norris wrote:
> v2:
> * add 'ret != 0' warning case for self-refresh
> * describe failing test case and relation to drm/rockchip patch better
Ugh, there's always something you remember right after you hit send: I
forgot to better sum
"drm/rockchip: Use the helpers for PSR")
Cc:
Link: https://lore.kernel.org/dri-devel/y5itf0+yniqa6...@sirena.org.uk/
Reported-by: "kernelci.org bot"
Signed-off-by: Brian Norris
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8
1 file changed, 4 insertions
add 'ret != 0' warning case for self-refresh
* describe failing test case and relation to drm/rockchip patch better
Cc: # dependency for "drm/rockchip: vop: Leave
# vblank enabled in self-refresh"
Signed-off-by: Brian Norris
---
drivers/gpu/drm/dr
On Fri, Jan 06, 2023 at 12:42:54PM +0100, Michel Dänzer wrote:
> On 1/6/23 02:40, Brian Norris wrote:
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -719,11 +719,11 @@ static void vop_crtc_atomic_disable(struc
On Fri, Jan 06, 2023 at 09:30:56PM +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 11:33:06AM -0800, Brian Norris wrote:
> > On Fri, Jan 06, 2023 at 07:17:53PM +0100, Daniel Vetter wrote:
> > > - check that drivers which use self_ref
y notice that this is "broken". I suppose
it would only be IGT tests that notice.
5. I fixed up various upstream PSR bugs are part of #3 [0],
along the way I unborked PSR enough that KernelCI finally caught the
bug. See my explanation in [1] for why the vblank bug was masked, and
On Fri, Jan 06, 2023 at 07:20:40PM +0100, Daniel Vetter wrote:
> On Fri, Jan 06, 2023 at 10:08:53AM -0800, Brian Norris wrote:
> > OK! Then that sounds like it at least ACKs my general idea for this
> > series. (Michel and I poked at a few ideas in the thread at [1] and
> > l
Hi Daniel,
On Fri, Jan 06, 2023 at 06:53:49PM +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2023 at 05:40:17PM -0800, Brian Norris wrote:
> > The self-refresh helper framework overloads "disable" to sometimes mean
> > "go into self-refresh mode," and this mo
On Thu, Jan 05, 2023 at 04:59:55PM -0800, Brian Norris wrote:
> On Wed, Jan 04, 2023 at 10:11:46AM +0100, Michel Dänzer wrote:
> > On 1/4/23 03:11, Brian Norris wrote:
> > > On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
> > >> On 12/21/22 23:02,
p on self refresh") as well.
We also need the previous patch ("drm/atomic: Allow vblank-enabled +
self-refresh "disable""), of course.
Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Cc:
Link: https://lore.kernel.org/dri-devel/y5itf0+yniqa6...@sire
Cs to be "disabled" (with
self-refresh active) with vblank interrupts still enabled.
Cc: # dependency for subsequent patch
Signed-off-by: Brian Norris
---
drivers/gpu/drm/drm_atomic_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/d
On Wed, Jan 04, 2023 at 10:11:46AM +0100, Michel Dänzer wrote:
> On 1/4/23 03:11, Brian Norris wrote:
> > On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
> >> On 12/21/22 23:02, Brian Norris wrote:
> >
> >>> 3. leave vblank enabled even in the
Hi Michel,
Thanks for your thoughts. I'll give my attempt at weighing my and your
options, with the caveat that I'm still not much of a DRM expert.
On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
> On 12/21/22 23:02, Brian Norris wrote:
> > So how to fix this?
Hi Mark, Sean, (and dri-devel)
On Wed, Dec 14, 2022 at 07:04:37PM -0800, Brian Norris wrote:
> On Tue, Dec 13, 2022 at 04:51:11PM +, Mark Brown wrote:
> > On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
> >
> > The KernelCI bisection bot found regression
8
In that case, there was actually an underlying kernel regression due to:
846c7dfc1193 drm/atomic: Try to preserve the crtc enabled state in
drm_atomic_remove_fb, v2.
But our tests were broken too (assuming an initial state that wasn't
guaranteed), so we just fixed the tests.
Anyway, I&
ch can in turn
> trigger a warning if we try to register a new debug offset at the same
> address on driver reload.
>
> To fix the issue, make sure to always run the cleanup code.
>
> Reported-by: Tvrtko Ursulin
> Reported-by: Brian Norris
> Fixes: 27536e03271d ("drm
PMU. I realized the one I tested on
doesn't actually hit this code path... and this would be getting a
little less obvious/trivial.
> Other than that, the patch looks good to me.
Thanks for looking!
Brian
achable.
And lastly, drop the unreachable return; we'd do better to let the
compiler complain if we start hitting this unexpectedly.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a
ny cross-device dependencies or racy accesses
to global state, so this should be safe.
This driver was pinpointed as part of a survey of top slowest initcalls
(i.e., are built in, and probing synchronously) on a lab of ChromeOS
systems.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv
If there are multiple amdgpu devices, this list processing can be racy.
We're really treating this like a per-device list, so make that explicit
and remove the global list.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4
drivers/gpu/drm/amd/a
i915: Allow delayed i915 audio
component binding")
Signed-off-by: Brian Norris
---
drivers/gpu/drm/i915/i915_pci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 38460a0bd7cb..1cb1f87aea8
chronous probe, at least until this driver learns some
appropriate locking for dual-DSI initialization.
Cc:
Signed-off-by: Brian Norris
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/dr
to hit when enabling asynchronous probe on a
duel-DSI system (such as RK3399 Gru/Scarlet), such that we're more
likely to fail dw_mipi_dsi_rockchip_find_second() the first time.
Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead
of full dsi")
Cc:
Signed-off-by:
On 9/27/2022 11:19 PM, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.
Signed-off-by: Ni
On Tue, Sep 13, 2022 at 04:36:57PM +0100, Liviu Dudau wrote:
> On Tue, Sep 13, 2022 at 03:43:06PM +0100, Brian Starkey wrote:
> > These formats are not subsampled, but that means hsub and vsub should be
> > 1, not 0.
> >
> > Fixes: 94b292b27734 ("drm: drm_fourcc:
These formats are not subsampled, but that means hsub and vsub should be
1, not 0.
Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats")
Reported-by: George Kennedy
Reported-by: butt3rflyh4ck
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_fourcc.c | 8 +
On Thu, Aug 25, 2022 at 11:06 AM Brian Norris wrote:
> On Thu, Aug 25, 2022 at 10:37 AM Doug Anderson wrote:
> > Given that this is _not_ an area that I'm an expert in nor is it an
> > area where the consequences are super easy to analyze, I'm a little
> > hesitant
use the up-to-date MAINTAINERS / .mailmap when generating CC
lists), in case he's one such expert.
Brian
fail.
So remove the superfluous, possibly-harmful suspend()/resume() handling
of panel state.
Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add panel prepare/unprepare in
suspend/resume time")
Link: https://lore.kernel.org/all/yv2cpbd3picg%2f...@google.com/
Signed-off-by: Brian Norris
uot;)
> Signed-off-by: Zhang Zekun
Reviewed-by: Brian Norris
Hi,
On Wed, Aug 17, 2022 at 05:05:25PM -0700, Brian Norris wrote:
> Hmm, actually I'm going to have to retract that now that I've given it
> some more testing locally. I happen to have a system where I commonly
> hit this error case, and I'm thinking commit 211f276ed3d9
On Wed, Aug 17, 2022 at 01:34:13PM -0700, Brian Norris wrote:
> On Mon, Aug 15, 2022 at 11:46 PM Zhang Zekun wrote:
> >
> > Add the missing clk_disable_unprepare() before return from
> > analogix_dp_resume() in the error handling case.
> >
> > Fixes: 211f276ed3d
On Tue, Aug 16, 2022 at 11:20:50AM +, Olivier Masse wrote:
> On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> > > On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > > > On F
Hi,
On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> Hi Brian,
>
> On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > Caution: EXT Email
> >
> > Hi Olivier,
> >
> > Thanks, I think this is looking much better.
> >
>
+Rob and devicetree list.
I don't know if this should be "linaro" or something more generic,
and also where previous discussions got to about DMA heaps in DT.
Cheers,
-Brian
On Fri, Aug 05, 2022 at 03:53:29PM +0200, Olivier Masse wrote:
> DMABUF Reserved memory definition for
name_len = 0;
> + const char *s = rmem->name;
> +
> + secure_data[secure_data_count].base = rmem->base;
> + secure_data[secure_data_count].size = rmem->size;
> +
> + while (name_len < MAX_HEAP_NAME_LEN) {
> + if ((*s == '@') || (*s == '\0'))
> + break;
> + name_len++;
> + s++;
> + }
> + if (name_len == MAX_HEAP_NAME_LEN)
> + name_len--;
> +
> + strncpy(secure_data[secure_data_count].name, rmem->name,
> name_len);
I think it would be good to explicitly do:
secure_data[secure_data_count].name[name_len] = '\0'
I know it's zero-initialised, but that's done on a line far away, so
may be best to be defensive.
> +
> + rmem->ops = &rmem_dma_ops;
> + pr_info("Reserved memory: DMA buf secure pool %s at %pa, size
> %ld MiB\n",
> + secure_data[secure_data_count].name,
> + &rmem->base, (unsigned long)rmem->size / SZ_1M);
nit: What if rmem->size < SZ_1M, or not 1M-aligned
> +
> + secure_data_count++;
> + return 0;
> + }
> + WARN_ONCE(1, "Cannot handle more than %u secure heaps\n",
> MAX_SECURE_HEAP);
> + return -EINVAL;
> +}
> +
> +RESERVEDMEM_OF_DECLARE(secure_heap, "linaro,secure-heap",
> rmem_secure_heap_setup);
Is there anything linaro-specific about this? Could it be
linux,secure-heap?
Thanks,
-Brian
> +
> +module_init(secure_heap_create);
> +MODULE_LICENSE("GPL v2");
> --
> 2.25.0
>
f a shrinker for that implementation may cause
> additional low-memory kills
>
> TODO: Take another pass at trying to unify this w/ the ttm pool
>
> Thoughts and feedback would be greatly appreciated!
Did I miss something, or is this not actually used anywhere?
Thanks,
-Brian
Hi,
On Wed, Aug 03, 2022 at 11:07:54AM +, Olivier Masse wrote:
> Hi Brian,
>
> Thanks for your comments, please find my reply below.
>
> On mar., 2022-08-02 at 15:39 +0100, Brian Starkey wrote:
> > Caution: EXT Email
> >
> > Hi Olivier,
> >
> >
o free_pages;
> + }
> +
> + return dmabuf;
> +
> +free_pages:
> + sg_free_table(table);
> +
> +free_pool:
> + gen_pool_free(info->pool, phy_addr, size);
> +
> +free_buffer:
> + mutex_destroy(&buffer->lock);
> + kfree(buffer);
> +
On Thu, Jun 30, 2022 at 07:48:46AM -0400, Brian Foster wrote:
> On Wed, Jun 29, 2022 at 01:43:11PM -0700, Kalesh Singh wrote:
> > On Wed, Jun 29, 2022 at 5:23 AM Brian Foster wrote:
> > >
> > > On Tue, Jun 28, 2022 at 03:38:02PM -0700, Kalesh Singh wrote:
> > &g
On Wed, Jun 29, 2022 at 01:43:11PM -0700, Kalesh Singh wrote:
> On Wed, Jun 29, 2022 at 5:23 AM Brian Foster wrote:
> >
> > On Tue, Jun 28, 2022 at 03:38:02PM -0700, Kalesh Singh wrote:
> > > On Tue, Jun 28, 2022 at 4:54 AM Brian Foster wrote:
> > > >
> &
On Tue, Jun 28, 2022 at 03:38:02PM -0700, Kalesh Singh wrote:
> On Tue, Jun 28, 2022 at 4:54 AM Brian Foster wrote:
> >
> > On Thu, Jun 23, 2022 at 03:06:06PM -0700, Kalesh Singh wrote:
> > > To be able to account the amount of memory a process is keeping pinned
> >
not sure if it matters that much for your use case, but something
worth noting at least with shmem is that one can do something like:
# cat /proc/meminfo | grep Shmem:
Shmem: 764 kB
# xfs_io -fc "falloc -k 0 10m" ./file
# ls -alh file
-rw---. 1 root root 0 Jun 28 07:22 file
# s
est, everything with a Fixes tag goes
there.) Maybe?
Anyway, if you want to "blame" anything, this commit actually dropped
the safety check:
4e257d9eee23 drm/rockchip: get rid of rockchip_drm_crtc_mode_config
Brian
[1] But I'm not omniscient. So maybe it's good to have anyway.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 74562d40f639..daf192881353 100644
--- a/drivers/gpu/drm/rockchip/roc
's not even funny.
>
What about dma-buf heaps? That should be a shorter route to getting a
dma-buf fd if that's all that's needed.
Cheers,
-Brian
ic: Force bridge self-refresh-exit on CRTC switch
> ca871659ec16 drm/bridge: analogix_dp: Support PSR-exit to disable transition
And thanks, Doug.
Brian
On Thu, Mar 10, 2022 at 3:50 PM Brian Norris wrote:
> On Mon, Feb 28, 2022 at 12:25 PM Brian Norris
> wrote:
> Ping for review? Sean, perhaps? (You already reviewed this on the
> Chromium tracker.)
Ping
Hi Robin,
On Tue, Apr 05, 2022 at 03:11:18PM +0100, Robin Murphy wrote:
> iommu_get_domain_for_dev() is already perfectly happy to return NULL
> if the given device has no IOMMU. Drop the unnecessary check.
>
> Signed-off-by: Robin Murphy
LGTM, Acked-by: Brian Starkey
I'll
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
> Cc: Dave Airlie
> Cc: Thierry Reding
This patch fixes the build error that I see with qcom_defconfig in
linux-next.
Tested-by: Brian Masney
On Mon, Feb 28, 2022 at 12:25 PM Brian Norris wrote:
>
> Hi,
>
> I've been investigating several eDP issues on a Rockchip RK3399 system
> and have two proposed bugfixes. RK3399 has two CRTCs, either of which
> can be used for eDP output. For both fixes, we have bugs du
DP AUX transactions can consist of many short operations. There's no
need to power things up/down in short intervals.
I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
RK3399), runtime-PM transitions only take a few microseconds.
Signed-off-by: Brian Norris
---
Cha
t; the panel.
Don't force any panel power-up, etc., because that can be intrusive, and
that's not what other drivers do (see
drivers/gpu/drm/bridge/ti-sn65dsi86.c and
drivers/gpu/drm/bridge/parade-ps8640.c.)
Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code&qu
On Tue, Feb 22, 2022 at 2:10 PM Doug Anderson wrote:
> On Thu, Feb 17, 2022 at 2:42 PM Brian Norris wrote:
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -1121,7 +1121,7 @@ static int analogi
ing PSR at the same time as a CRTC switch.
(Thanks Liu Ying)
Cc: Liu Ying
Cc:
Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
drivers")
Signed-off-by: Brian Norris
---
drivers/gpu/drm/drm_atomic_helper.c | 16 +---
1 file changed, 13 insertions(
a while. It may predate the "PSR helpers"
refactor, but the code looked very different before that, and it's
probably not worth rewriting the fix.
Cc:
Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Signed-off-by: Brian Norris
---
(no changes since v1)
..
en't explained issues well, or the proposals look
fishy.
Regards,
Brian
Changes in v2:
- Drop "->enable" condition in crtc_needs_disable(); this could possibly
be "->active" to reflect the intended hardware state, but it also is a
little over-specific. We want to
Hi Liu,
On Mon, Feb 28, 2022 at 1:02 AM Liu Ying wrote:
> On Tue, 2022-02-15 at 15:54 -0800, Brian Norris wrote:
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1011,9 +1011,19 @@ crtc_needs_disable(struct drm_
DP AUX transactions can consist of many short operations. There's no
need to power things up/down in short intervals.
I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
RK3399), runtime-PM transitions only take a few microseconds.
Signed-off-by: Brian Norris
---
Cha
t; the panel.
Don't force any panel power-up, etc., because that can be intrusive, and
that's not what other drivers do (see
drivers/gpu/drm/bridge/ti-sn65dsi86.c and
drivers/gpu/drm/bridge/parade-ps8640.c.)
Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code&qu
On Tue, Feb 15, 2022 at 3:46 PM Doug Anderson wrote:
> On Tue, Feb 15, 2022 at 2:52 PM Brian Norris wrote:
> > It still makes me wonder what the point
> > of the /dev/drm_dp_aux interface is though, because it seems like
> > you're pretty much destined to not have
a while. It may predate the "PSR helpers"
refactor, but the code looked very different before that, and it's
probably not worth rewriting the fix.
Cc:
Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Signed-off-by: Brian Norris
---
.../drm/br
/drm/bridge/analogix/analogix_dp_core.c.
Cc:
Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
drivers")
Signed-off-by: Brian Norris
---
drivers/gpu/drm/drm_atomic_helper.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
en't explained issues well, or the proposals look
fishy.
Regards,
Brian
Brian Norris (2):
drm/bridge: analogix_dp: Support PSR-exit to disable transition
drm/atomic: Force bridge self-refresh-exit on CRTC switch
.../drm/bridge/analogix/analogix_dp_core.c| 42 +--
On Tue, Feb 15, 2022 at 1:31 PM Doug Anderson wrote:
>
> Hi,
Hi!
> On Fri, Oct 1, 2021 at 2:50 PM Brian Norris wrote:
> >
> > If the display is not enable()d, then we aren't holding a runtime PM
> > reference here. Thus, it's easy to accidentally caus
ity according to the RK3399 TRM and fixed them up.
This fixes IOMMU issues (and display errors) when testing with BG24
color formats.
Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc")
Cc: Andrzej Pietrasiewicz
Cc:
Signed-off-by: Brian Norris
---
I'd appreciate notes or testi
Hi Chen-Yu,
On Mon, Jan 17, 2022 at 05:01:52PM +0800, Chen-Yu Tsai wrote:
> On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
> >
> > Now that the cdn-dp driver supports plug-change callbacks, let's wire it
> > up.
> >
> > Signed-off-by: Brian Norris
Now that the cdn-dp driver supports plug-change callbacks, let's wire it
up.
Signed-off-by: Brian Norris
---
(no changes since v1)
sound/soc/rockchip/rk3399_gru_sound.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
b/soun
Some audio servers like to monitor a jack device (perhaps combined with
EDID, for audio-presence info) to determine DP/HDMI audio presence.
Signed-off-by: Brian Norris
---
(no changes since v1)
drivers/gpu/drm/rockchip/cdn-dp-core.c | 28 ++
drivers/gpu/drm/rockchip
d by a different function (on scarlet), which causes probe
failures (!!)
Fixes: b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
Signed-off-by: Brian Norris
---
Changes in v2:
- (Un)set pinctrl, because the default assumes we're routing out to
external pi
never upstreamed, because the hdmi-codec
dependencies were still being worked out when this platform was first
supported.
Patches cover a few subsystems. Perhaps this is something for arm-soc?
Changes in v2:
- (Un)set pinctrl, because the default assumes we're routing out to
external p
Sorry to send a self-reply so quickly, but I noticed an error and want
to make sure this doesn't get merged _too_ quickly before I get to
send a revision! See below:
On Fri, Jan 14, 2022 at 12:17 PM Brian Norris wrote:
>
> Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound
Some audio servers like to monitor a jack device (perhaps combined with
EDID, for audio-presence info) to determine DP/HDMI audio presence.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 28 ++
drivers/gpu/drm/rockchip/cdn-dp-core.h | 4
Now that the cdn-dp driver supports plug-change callbacks, let's wire it
up.
Signed-off-by: Brian Norris
---
sound/soc/rockchip/rk3399_gru_sound.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
b/sound/soc/roc
1 - 100 of 942 matches
Mail list logo
