Insert a parameterized test for the drm_rect_rotate() to ensure
correctness and prevent future regressions.
All possible rotation modes are covered by the test.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_rect_test.c | 72 +++
1 file changed, 72
Insert parameterized test for the drm_rect_calc_vscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the exceptions.
It uses the same struct from drm_rect_calc_hscale().
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_rect_test.c
Insert parameterized test for the drm_rect_calc_hscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the exceptions.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_rect_test.c | 72 +++
1 file changed, 72
Insert parameterized tests for the drm_rect_intersect() to ensure
correctness and prevent future regressions.
Also, create a helper for testing if two drm_rects are equal.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/tests/drm_rect_test.c | 148 ++
1 file changed,
This patchset seeks to add unit tests for the rest of the functions on
the drm_rect.c.
The test coverage report generated by the gcov[1] tool states that this
set reaches 100% of coverage on the drm_rect.c file. This would be
very good for future development on the file.
Thanks for reviewing!
On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote:
> Stolen memory is not usable for MTL A0 stepping beyond
> certain access size and we have no control over userspace
> access size of /dev/fb which can be backed by stolen memory.
> So disable stolen memory backed fb by setting
> -Original Message-
> From: Das, Nirmoy
> Sent: Tuesday, April 4, 2023 11:14 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Das, Nirmoy ;
> Auld, Matthew ; Andi Shyti
> ; Ceraolo Spurio, Daniele
> ; De Marchi, Lucas
> ; Sripada, Radhakrishna
>
>
On 4/4/23 15:10, Christian König wrote:
Am 04.04.23 um 14:54 schrieb Thomas Hellström:
Hi, Christian,
On 4/4/23 11:09, Christian König wrote:
Am 04.04.23 um 02:22 schrieb Matthew Brost:
From: Thomas Hellström
For long-running workloads, drivers either need to open-code
completion
Stolen memory is not usable for MTL A0 stepping beyond
certain access size and we have no control over userspace
access size of /dev/fb which can be backed by stolen memory.
So disable stolen memory backed fb by setting i915->dsm.usable_size
to zero.
v2: remove hsdes reference and fix commit
On Tue, Apr 04, 2023 at 12:02:03PM -0600, Zeng, Oak wrote:
> Hi Matt, Thomas,
>
> Some very bold out of box thinking in this area:
>
> 1. so you want to use drm scheduler and dma-fence for long running workload.
> Why you want to do this in the first place? What is the benefit? Drm
> scheduler
Hi Matt, Thomas,
Some very bold out of box thinking in this area:
1. so you want to use drm scheduler and dma-fence for long running workload.
Why you want to do this in the first place? What is the benefit? Drm scheduler
is pretty much a software scheduler. Modern gpu has scheduler built at
Hi Dave,
On Thu, Mar 30, 2023 at 3:31 PM Dave Stevenson
wrote:
>
> Hi Jagan
>
> On Thu, 30 Mar 2023 at 07:56, Jagan Teki wrote:
> >
> > On Wed, Mar 29, 2023 at 10:16 PM Maxime Ripard wrote:
> > >
> > > On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote:
> > > > On Wed, 29 Mar 2023
Hi Andi,
On 4/4/2023 6:57 PM, Andi Shyti wrote:
Hi Nirmoy,
[...]
+int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct
*vma)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct drm_device *dev = >drm;
+ struct i915_mmap_offset *mmo
On 04/04/2023 14:52, Matthew Brost wrote:
On Tue, Apr 04, 2023 at 10:43:03AM +0100, Tvrtko Ursulin wrote:
On 04/04/2023 01:22, Matthew Brost wrote:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as
On 08/03/2023 17:53, Rob Clark wrote:
From: Rob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
v2: Comment typo fix (danvet)
v3: If there are multiple CRTCs, consider the time of the soonest vblank
On Tue, 4 Apr 2023 at 19:04, Geert Uytterhoeven wrote:
>
> Hi Daniel,
>
> On Tue, Apr 4, 2023 at 5:55 PM Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 16:51, Geert Uytterhoeven
> > wrote:
> > > On Tue, Apr 4, 2023 at 4:19 PM Daniel Vetter wrote:
> > > > On Tue, Apr 04, 2023 at 03:59:12PM
On 4/3/2023 5:33 PM, Dmitry Baryshkov wrote:
On 04/04/2023 00:38, Jessica Zhang wrote:
On 4/2/2023 4:21 AM, Dmitry Baryshkov wrote:
On 31/03/2023 21:49, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
-
Hi Daniel,
On Tue, Apr 4, 2023 at 5:55 PM Daniel Vetter wrote:
> On Tue, 4 Apr 2023 at 16:51, Geert Uytterhoeven wrote:
> > On Tue, Apr 4, 2023 at 4:19 PM Daniel Vetter wrote:
> > > On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 04, 2023 at 03:53:09PM +0200,
Hi Nirmoy,
[...]
> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct
> *vma)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct drm_device *dev = >drm;
> + struct i915_mmap_offset *mmo = NULL;
> + enum i915_mmap_type mmap_type;
On 3/31/2023 5:36 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
Wait for VPU to be idle in ivpu_pm_suspend_cb() before powering off
the device, so jobs are not lost and TDRs are not triggered after
resume.
Fixes: 852be13f3bd3 ("accel/ivpu: Add PM support")
Signed-off-by: Jacek
Hi Nirmoy,
On Tue, Apr 04, 2023 at 04:30:57PM +0200, Nirmoy Das wrote:
> Framebuffer is exposed to userspace so make sure we set
> proper flags for it. Set I915_BO_PREALLOC for prealloced
> fb so that ttm won't clear existing data.
>
> Cc: Matthew Auld
> Cc: Andi Shyti
> Cc: Andrzej Hajda
>
On 04/04/2023 19:29, Jessica Zhang wrote:
On 4/3/2023 5:33 PM, Dmitry Baryshkov wrote:
On 04/04/2023 00:38, Jessica Zhang wrote:
On 4/2/2023 4:21 AM, Dmitry Baryshkov wrote:
On 31/03/2023 21:49, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
Hi,
On Fri, Mar 31, 2023 at 04:16:36PM +0200, Andrzej Hajda wrote:
> From: Chris Wilson
>
> There may be a disconnect between the GT used by the engine and the GT
> used for the VM, requiring us to hold a wakeref on both while the GPU is
> active with this request.
>
> v2: added explanation to
On 4/3/2023 5:33 PM, Dmitry Baryshkov wrote:
On 04/04/2023 00:38, Jessica Zhang wrote:
On 4/2/2023 4:21 AM, Dmitry Baryshkov wrote:
On 31/03/2023 21:49, Jessica Zhang wrote:
Introduce MSM-specific DSC helper methods, as some calculations are
common between DP and DSC.
Changes in v2:
-
From: Michael Williamson
If the I2C bus is connected on the TFP410, then use the register
status bit to determine connection state. This is needed, in particular,
for polling the state when the Hot Plug detect is not connected to
a controlling CPU via GPIO/IRQ lane.
Signed-off-by: Michael
From: Michael Williamson
The logic to configure polling (vs async/irq notification) of hot-plug
events was not correct. If the connected bridge requires polling,
then inform the upstream bridge we also require polling.
Fixes: 5cafa0f1853b ("drm/bridge: tfp410: Replace manual connector handling
From: Michael Williamson
The TFP410 driver does not support I2C. As such, the device remains in
Power Down if the I2C is enabled by the bootstrap pins.
Add basic support for the I2C interface, and provide support to take
the device out of power down when enabled. Also read the bootstrap mode
The TFP410 driver does not support I2C. As such, the device remains in
Power Down if the I2C is enabled by the bootstrap pins.
Add basic support for the I2C interface, and provide support to take
the device out of power down when enabled. Also read the bootstrap mode
pins via the CTL_1_MODE
Hi Maxime,
On 4/4/23 18:04, Maxime Ripard wrote:
> On Fri, Mar 31, 2023 at 11:36:43AM +0200, Michael Riesch wrote:
>> On 3/30/23 16:58, Maxime Ripard wrote:
>>> On Wed, Mar 29, 2023 at 12:08:50PM +0200, Michael Riesch wrote:
On 3/29/23 11:16, Maxime Ripard wrote:
> On Thu, Mar 16, 2023
On 3/31/2023 5:36 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
Currently job->done_fence is added to every BO handle within a job. If job
handle (command buffer) is shared between multiple submits, KMD will add
the fence in each of them. Then bo_wait_ioctl() executed on command buffer
Hi Nirmoy,
On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
> Add a mechanism to keep existing data when creating
> a ttm object with I915_BO_ALLOC_USER flag.
why do we need this mechanism? What was the logic behind? These
are all questions people might have when checking this commit.
On 4/3/2023 6:15 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
VPU on MTL has hardware optimizations and does not require 10ms
D0 - D3hot transition delay imposed by PCI specification (PCIe
r6.0, sec 5.9.) .
The delay removal is traditionally done by adding PCI ID to
On 04/04/2023 17:00, Andi Shyti wrote:
Hi Tvrtko,
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6
> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO
> creation
>
> On 01/04/2023 09:38, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> To comply with the design that buffer objects shall have immutable
>> cache setting through out its life cycle, {set, get}_caching
> From: Daniel Vetter
> Sent: Tuesday, April 4, 2023 6:21 AM
> ...
> On Sat, 2 Jan 2021 at 07:03, Deepak Rawat wrote:
> > +/*
> > + * PCI/vmbus interface
> > + */
> > +
> > +static int hyperv_pci_probe(struct pci_dev *pdev,
> > + const struct pci_device_id *ent)
> > +{
On Fri, Mar 31, 2023 at 11:36:43AM +0200, Michael Riesch wrote:
> On 3/30/23 16:58, Maxime Ripard wrote:
> > On Wed, Mar 29, 2023 at 12:08:50PM +0200, Michael Riesch wrote:
> >> On 3/29/23 11:16, Maxime Ripard wrote:
> >>> On Thu, Mar 16, 2023 at 11:29:53PM +0100, Michael Riesch wrote:
> Hi
Hi Tvrtko,
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index 0a8d553da3f439..48f888c3da083b 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -14,6 +14,7 @@
On 04/04/2023 16:39, Andi Shyti wrote:
Hi Andrzej,
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6
On Tue, 4 Apr 2023 at 16:51, Geert Uytterhoeven wrote:
>
> CC linux-fbdev
>
> On Tue, Apr 4, 2023 at 4:19 PM Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Apr 4,
Hi Andrzej,
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 0a8d553da3f439..48f888c3da083b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -14,6 +14,7 @@
> #include
On 04.04.2023 16:30, Nirmoy Das wrote:
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
---
On Tue, Apr 04, 2023 at 12:11:33PM +0200, Maxime Ripard wrote:
> The tlv320aic32x4 clkin clock implements a mux with a set_parent hook,
> but doesn't provide a determine_rate implementation.
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock.
Hi Daniel,
On Tue, Aug 9, 2022 at 5:03 PM Daniel Vetter wrote:
> On Sat, Jul 02, 2022 at 08:05:54PM +0200, Helge Deller wrote:
> > On 6/29/22 12:56, Geert Uytterhoeven wrote:
> > > The DRM fbdev emulation layer does not support pushing back
> > > changes to fb_var_screeninfo to KMS.
> > >
> > >
On Tue, 4 Apr 2023 at 08:13, wrote:
>
> From: Qiang Yu
>
> Upstream has reverted the dependant commit
> df622729ddbf ("drm/scheduler: track GPU active time per entity""),
> but this patchset has been pushed to drm-misc-next which still
> has that commit. To avoid other branch build fail after
> > Hi Andrew
> >
> >>
> >>
> >> Okay, will split for v2.
> >>
> >>
> >
> > Was there a follow-up v2 of this patchset? AFAICT this series did not
> > make it into the mainline kernel.
> > Do you have any plans to work on it? If not I would like to help out
> > as we have a use case where we want
CC linux-fbdev
On Tue, Apr 4, 2023 at 4:41 PM Thomas Zimmermann wrote:
> Am 04.04.23 um 16:19 schrieb Daniel Vetter:
> > On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> >>> CC vkmsdrm maintainer
> >>>
> >>>
CC linux-fbdev
On Tue, Apr 4, 2023 at 4:19 PM Daniel Vetter wrote:
> On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Apr 4, 2023 at 2:36 PM Daniel Vetter
> > > wrote:
> > > > There's a few
Hi,
FYI I have merged patches 1, 6 and 7 of this patchset. They look fine
and are worthwhile fixes on their own.
Best regards
Thomas
Am 11.01.23 um 16:41 schrieb Daniel Vetter:
It's just open coded and matches.
Note that Thomas said that his version apparently failed for some
reason, but
Hi
Am 04.04.23 um 16:19 schrieb Daniel Vetter:
On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
Hi Daniel,
CC vkmsdrm maintainer
Thanks for your patch!
On Tue, Apr 4, 2023 at 2:36 PM Daniel Vetter wrote:
If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will
Add a helper function to retrieve struct intel_fbdev from
struct drm_fb_helper.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
Reviewed-by: Jani Nikula
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
---
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15
Implement i915_gem_fb_mmap() to enable fb_ops.fb_mmap()
callback for i915's framebuffer objects.
v2: add a comment why i915_gem_object_get() needed(Andi).
v3: mmap also ttm objects.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
Framebuffer is exposed to userspace so make sure we set
proper flags for it. Set I915_BO_PREALLOC for prealloced
fb so that ttm won't clear existing data.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
---
On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > CC vkmsdrm maintainer
> >
> > Thanks for your patch!
> >
> > On Tue, Apr 4, 2023 at 2:36 PM Daniel Vetter wrote:
> > > There's a few
Hello Hans,
On Wed, 29 Mar 2023 13:16:22 +0200
Hans Verkuil wrote:
> Hi Luca,
>
> I finally found the time to test this series. It looks OK, except for this
> patch.
Thank you very much for taking the time!
> The list of supported formats really has to be the intersection of what the
>
Greetings Sui Jingfeng,
I haven't been around drm-land for a while and this is the first
driver I skim through in a few years. So take the following
suggestions with a healthy pinch of salt.
Hope that helps o/
On Mon, 3 Apr 2023 at 18:13, Sui Jingfeng wrote:
> v7 -> v8:
>1) Zero a
On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> CC vkmsdrm maintainer
>
> Thanks for your patch!
>
> On Tue, Apr 4, 2023 at 2:36 PM Daniel Vetter wrote:
> > There's a few reasons the kernel should not spam dmesg on bad
> > userspace ioctl input:
> > - at
The Tegra super clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Tegra periph clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The STM32 composite clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The ST Flexgen clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Spreadtrum composite clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The Ingenic TCU clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Ingenic CGU clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The TI DA8xx USB0 clk48 clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The iMX SCU clocks implements a mux with a set_parent hook, but doesn't
provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The SI5351 clkout clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
On Fri, Mar 31, 2023 at 5:00 AM Neil Armstrong
wrote:
>
> Hi,
>
> On 20/02/2023 23:10, Jonathan Cormier wrote:
> > From: Michael Williamson
> >
> > The logic to configure polling (vs async/irq notification) of hot-plug
> > events was not correct. If the connected bridge requires polling,
> >
Hi Daniel,
CC vkmsdrm maintainer
Thanks for your patch!
On Tue, Apr 4, 2023 at 2:36 PM Daniel Vetter wrote:
> There's a few reasons the kernel should not spam dmesg on bad
> userspace ioctl input:
> - at warning level it results in CI false positives
> - it allows userspace to drown dmesg
On Tue, Apr 04, 2023 at 10:43:03AM +0100, Tvrtko Ursulin wrote:
>
> On 04/04/2023 01:22, Matthew Brost wrote:
> > Hello,
> >
> > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
> > have been asked to merge our common DRM scheduler patches first as well
> > as develop a
On 4/4/23 00:55, Paul Cercueil wrote:
[...]
+ priv = attach->importer_priv;
+ list_del_init(>entry);
+
+ iio_buffer_dmabuf_put(attach);
+ iio_buffer_dmabuf_put(attach);
+
Is this intended? Looks suspicious...
It is intended, yes. You want to release the
On Tue, Apr 4, 2023 at 2:45 PM Maxime Ripard wrote:
> The UX500 PRCMU "clkout" clock implements a mux with a set_parent hook,
> but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent of a clock.
On Tue, Apr 04, 2023 at 11:48:36AM +0200, Christian König wrote:
> Am 04.04.23 um 11:43 schrieb Tvrtko Ursulin:
> >
> > On 04/04/2023 01:22, Matthew Brost wrote:
> > > Hello,
> > >
> > > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
> > > have been asked to merge our
The SI5351 msynth clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The cdce706 clkout clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The SI5351 PLL clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The SI5341 output clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The cdce706 divider clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
On Tue, Apr 04, 2023 at 11:13:28AM +0200, Christian König wrote:
> Hi,
>
> Am 04.04.23 um 02:22 schrieb Matthew Brost:
> > Hello,
> >
> > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
> > have been asked to merge our common DRM scheduler patches first as well
> > as
The AXI clkgen clocks implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Atmel SAM9x5 SMD clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
On Mon, Apr 3, 2023 at 6:07 PM Rob Clark wrote:
> From: Rob Clark
>
> This should fix a crash that was reported on ast (and possibly other
> drivers which do not initialize vblank).
>
>fbcon: Taking over console
>Unable to handle kernel NULL pointer dereference at virtual address
>
The tlv320aic32x4 clkin clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The Actions composite divider clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change
The Actions composite factor clocks implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change
The Allwinner sun6i RTC clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
From: Thierry Reding
On Fri, 31 Mar 2023 13:21:59 -0500, Rob Herring wrote:
> Cleanup bindings dropping unneeded quotes. Once all these are fixed,
> checking for this can be enabled in yamllint.
>
>
Applied, thanks!
[1/1] dt-bindings: arm: nvidia: Drop unneeded quotes
commit:
The TI J721e Wiz clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The TI AM654 SerDes clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The Cadence Torrent refclk clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is
On Tue, Apr 04, 2023 at 11:04:54AM +0200, Christian König wrote:
> Please make sure to CC Luben on scheduler patches.
>
Sure, figured I was missing a few people.
Matt
> Regards,
> Christian.
>
> Am 04.04.23 um 02:22 schrieb Matthew Brost:
> > Hello,
> >
> > As a prerequisite to merging the
Yeah way late reply, but I just stumbled over this and got a bit puzzled ...
On Sat, 2 Jan 2021 at 07:03, Deepak Rawat wrote:
> +/*
> + * PCI/vmbus interface
> + */
> +
> +static int hyperv_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> +
Am 04.04.23 um 14:54 schrieb Thomas Hellström:
Hi, Christian,
On 4/4/23 11:09, Christian König wrote:
Am 04.04.23 um 02:22 schrieb Matthew Brost:
From: Thomas Hellström
For long-running workloads, drivers either need to open-code completion
waits, invent their own synchronization primitives
Drop the version comparison macros from dpu_hw_catalog.h, they are
unused.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 42 ---
1 file changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
In email discussion it was noted that there can be different SoC device
having slightly different SoC features, but sharing the same DPU hw
revision. Stop fetching catalog data using core_rev and use platform's
match data instead.
Signed-off-by: Dmitry Baryshkov
---
To ease review and reuse rename CTL feature masks to contain base DPU
version since which this mask is used.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 10 +-
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 10
To ease review and reuse rename MERGE_3D feature masks to contain base
DPU version since which this mask is used.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
To ease review and reuse rename MIXER feature masks to contain base DPU
version since which this mask is used.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 12 ++--
To ease review and reuse rename VIG and DMA feature masks to contain
base DPU version since which this mask is used.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 16 +++
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 16
101 - 200 of 341 matches
Mail list logo
