From: Alyssa Rosenzweig
The IDVS group size feature was missing. It is used on some Bifrost and
Valhall GPUs, and is the last kernel-relevant Bifrost feature we're
missing.
This feature adds an extra IDVS group size field to the JM_CONFIG
register. In kbase, the value is configurable via the dev
The ssd130x DRM driver also makes use of this Device Tree binding to allow
existing users of the fbdev driver to migrate without the need to change
their Device Trees.
Add myself as another maintainer of the binding, to make sure that I will
be on Cc when patches are proposed for it.
Suggested-by
To make sure that tools like the get_maintainer.pl script will suggest
to Cc me if patches are posted for this driver.
Also include the Device Tree binding for the old ssd1307fb fbdev driver
since the new DRM driver was made compatible with the existing binding.
Signed-off-by: Javier Martinez Can
This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
OLED display controllers.
It's only the core part of the driver and a bus specific driver is needed
for each transport interface supported by the display controllers.
Signed-off-by: Javier Martinez Canillas
---
Changes in
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over I2C.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
---
Changes in v5:
- Add Andy Shevchenko's Reviewed-by tag to patch #4.
Cha
Pull the per-line conversion logic into a separate helper function.
This will allow to do line-by-line conversion in other helpers that
convert to a gray8 format.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes in v5:
- Add Th
Add support to convert from XR24 to reversed monochrome for drivers that
control monochromatic display panels, that only have 1 bit per pixel.
The function does a line-by-line conversion doing an intermediate step
first from XR24 to 8-bit grayscale and then to reversed monochrome.
The drm_fb_gray
This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
Using the DRM fbdev emulation, all the tests from Geert Uytterhoeven repo
(https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes.
Den 11.02.2022 14.27, skrev Maxime Ripard:
> On Fri, Feb 11, 2022 at 02:04:32PM +0100, Noralf Trønnes wrote:
>> Add binding for MIPI DBI compatible SPI panels.
>>
>> v3:
>> - Move properties to Device Tree (Maxime)
>> - Use contains for compatible (Maxime)
>> - Add backlight property to example
On 11/02/2022 02:31, Abhinav Kumar wrote:
On 2/10/2022 1:32 AM, Dmitry Baryshkov wrote:
On 10/02/2022 03:25, Abhinav Kumar wrote:
On 1/21/2022 1:06 PM, Dmitry Baryshkov wrote:
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_e
Dear Zhouyi,
Am 10.02.22 um 07:58 schrieb Zhouyi Zhou:
In function do_remove_conflicting_framebuffers, if device is NULL, there
will be null pointer reference. The patch add a check to the if expression.
Signed-off-by: Zhouyi Zhou
---
Dear Linux folks
I discover this bug in the PowerPC VM pr
On 2022-02-07 at 11:52:48 +, Matthew Auld wrote:
> On 07/02/2022 11:48, Matthew Auld wrote:
> > On Fri, 28 Jan 2022 at 18:52, Ramalingam C wrote:
> > >
> > > An indirect ctx wabb is implemented as per Wa_22011450934 to avoid rcs
> > > restore hang during context restore of a preempted context
On Thu, 10 Feb 2022, Michael Cheng wrote:
> Move wbvind_on_all_cpus to intel_gt.h. This will allow other wbind_on_all_cpus
> calls to benefit from the #define logic, and prevent compiler errors
> when building for non-x86 architectures.
>
> Signed-off-by: Michael Cheng
> ---
> drivers/gpu/drm/i9
On 2022-02-07 at 08:55:20 -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 1/28/2022 10:52 AM, Ramalingam C wrote:
> > From: Stuart Summers
> >
> > The driver is set currently to fail modprobe when GuC is disabled
> > (enable_guc=0) after GuC has been loaded on a previous modprobe.
> > For GuC dep
The tsc2046 is an ADC used as touchscreen controller. To share as mach
code as possible, we should use it as actual ADC + virtual touchscreen
controller.
With this patch we make use of the new kernel IIO and HID infrastructure.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-plym2m.dt
Add Innolux G070Y2-T02 panel to the Protonic VT7 board.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
b/arch/arm/bo
From: Robin van der Gracht
Add missing tvp5150 video decoder node to make composite video input
work.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 42 +
1 file changed, 42 insertions(+)
diff --git a/ar
Add thermal zones and hwmon connected to the ADC-touchscreen controller.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-plym2m.dts | 74 -
arch/arm/boot/dts/imx6dl-prtvt7.dts | 57 ++
arch/arm/boot/dts/imx6dl-victgo.dts | 62 +++
changes v3:
- add missing SoB and commit message
changes v2:
- add missing new lines
- rename adc label to adc_ts
- add thermal zones patch
Oleksij Rempel (4):
ARM: dts: imx6dl-prtvt7: Add display and panel nodes
ARM: dts: imx6qdl-vicut1: add CAN termination support
ARM: dts: imx6dl: plym2m
The gpio1 0 pin is controlling CAN termination, not USB H1 VBUS. So,
remove wrong regulator and assign this gpio to new DT CAN termnation
property.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --
On Mon, 31 Jan 2022 17:47:23 +0100, quentin.sch...@theobroma-systems.com wrote:
> From: Quentin Schulz
>
> The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving
> controller is a Himax HX8394-F, slightly different from LTK050H3146W by
> its init sequence, mode details and mode flags
On Fri, Feb 11, 2022 at 02:04:34PM +0100, Noralf Trønnes wrote:
> Add a driver that will work with most MIPI DBI compatible SPI panels.
> This avoids adding a driver for every new MIPI DBI compatible controller
> that is to be used by Linux. The 'compatible' Device Tree property with
> a '.bin' suf
On Fri, Feb 11, 2022 at 02:04:33PM +0100, Noralf Trønnes wrote:
> devm_drm_dev_alloc() can't allocate structures that embed a structure
> which then again embeds drm_device. Workaround this by adding a
> driver_private pointer to struct mipi_dbi_dev which the driver can use for
> its additional sta
On Fri, Feb 11, 2022 at 02:04:32PM +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
>
> v3:
> - Move properties to Device Tree (Maxime)
> - Use contains for compatible (Maxime)
> - Add backlight property to example
> - Flesh out description
>
> v2:
> - Fix path for p
On Mon, Jan 31, 2022 at 11:28:38AM +0100, Oleksij Rempel wrote:
> From: Robin van der Gracht
>
> Signed-off-by: Robin van der Gracht
Please write up some commit log. Also your SoB is missing.
Shawn
> ---
> arch/arm/boot/dts/imx6dl-prtvt7.dts | 42 +
> 1 file chan
Add binding for MIPI DBI compatible SPI panels.
v3:
- Move properties to Device Tree (Maxime)
- Use contains for compatible (Maxime)
- Add backlight property to example
- Flesh out description
v2:
- Fix path for panel-common.yaml
- Use unevaluatedProperties
- Drop properties which are in the allO
devm_drm_dev_alloc() can't allocate structures that embed a structure
which then again embeds drm_device. Workaround this by adding a
driver_private pointer to struct mipi_dbi_dev which the driver can use for
its additional state.
v3:
- Add documentation
Signed-off-by: Noralf Trønnes
---
includ
Add a driver that will work with most MIPI DBI compatible SPI panels.
This avoids adding a driver for every new MIPI DBI compatible controller
that is to be used by Linux. The 'compatible' Device Tree property with
a '.bin' suffix will be used to load a firmware file that contains the
controller co
Hi,
This patchset adds a driver that will work with most MIPI DBI compatible
SPI panels out there.
Maxime gave[1] a good overview of the situation with these displays and
proposed to make a driver that works with all MIPI DBI compatible
controllers and use a firmware file to provide the controlle
It fixes typo and updates outdated struct and API names that are currently
deprecated or in use but have changed on the kernel documents of DRM section
and comments.
Signed-off-by: Gwan-gyeong Mun
---
Documentation/gpu/drm-mm.rst | 8
drivers/gpu/drm/drm_file.c| 10
Add an usage for submissions independent of implicit sync but still
interesting for memory management.
v2: cleanup the kerneldoc a bit
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 2 +-
drivers/dma-buf/st-dma-resv.c| 2 +-
drivers/g
We have previously done that in the individual drivers but it is
more defensive to move that into the common code.
Dynamic attachments should wait for map operations to complete by themselves.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 18 +++---
Get the write fence using dma_resv_for_each_fence instead of accessing
it manually.
Signed-off-by: Christian König
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
We can now add multiple writers to the dma_resv object.
Also enable the check for not adding containers in dma_resv.c again.
Signed-off-by: Christian König
Cc: amd-...@lists.freedesktop.org
---
drivers/dma-buf/dma-resv.c | 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.h |
Add an usage for kernel submissions. Waiting for those
are mandatory for dynamic DMA-bufs.
Signed-off-by: Christian König
---
drivers/dma-buf/st-dma-resv.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 2 +-
drivers/
We can get the excl fence together with the shared ones as well.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 1 -
drivers/gpu/drm/etnaviv
Makes the code a bit more simpler.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdg
Use dma_resv_get_singleton() here to eventually get more than one write
fence as single fence.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Lyude Paul
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/
This is now handled by the DMA-buf framework in the dma_resv obj.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 7 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c| 11 +++---
drivers/gpu/drm/amd
That should now be handled by the common dma_resv framework.
Signed-off-by: Christian König
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 29 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 5 ++--
drivers/gpu/drm/i915/gem/i915_gem_tt
So far we had the approach of using a directed acyclic
graph with the dma_resv obj.
This turned out to have many downsides, especially it means
that every single driver and user of this interface needs
to be aware of this restriction when adding fences. If the
rules for the DAG are not followed th
This change adds the dma_resv_usage enum and allows us to specify why a
dma_resv object is queried for its containing fences.
Additional to that a dma_resv_usage_rw() helper function is added to aid
retrieving the fences for a read or write userspace submission.
This is then deployed to the diffe
Use dma_resv_get_singleton() here to eventually get more than one write
fence as single fence.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gp
On 2/11/22 12:34, Matthew Auld wrote:
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't im
Drivers should never touch this directly.
v2: fix rebase clash
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 6 ++
include/linux/dma-resv.h | 17 -
2 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-b
Instead of distingting between shared and exclusive fences specify
the fence usage while adding fences.
Rework all drivers to use this interface instead and deprecate the old one.
v2: some kerneldoc comments suggested by Daniel
v3: fix a missing case in radeon
v4: rebase on nouveau changes, fix l
Audit all the users of dma_resv_add_excl_fence() and make sure they
reserve a shared slot also when only trying to add an exclusive fence.
This is the next step towards handling the exclusive fence like a
shared one.
v2: fix missed case in amdgpu
v3: and two more radeon, rename function
Signed-o
Use dma_resv_wait() instead of extracting the exclusive fence and
waiting on it manually.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Leon Romanovsky
Cc: Maor Gottlieb
Cc: Gal Pressman
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
--
Add a function to simplify getting a single fence for all the fences in
the dma_resv object.
v2: fix ref leak in error handling
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 52 ++
include/linux/dma-resv.h | 2 ++
2 files changed, 54 inse
Instead use the new dma_resv_get_singleton function.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_di
Instead use the new dma_resv_get_singleton function.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(
Instead use the new dma_resv_get_singleton function.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Cc: VMware Graphics
Cc: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgf
Drivers should never touch this directly.
v2: drop kerneldoc for now internal handling
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/dma-buf/dma-resv.c | 11 +++
include/linux/dma-resv.h | 26 +-
2 files changed, 12 insertions(+), 25 de
This function allows to replace fences from the shared fence list when
we can gurantee that the operation represented by the original fence has
finished or no accesses to the resources protected by the dma_resv
object any more when the new fence finishes.
Then use this function in the amdkfd code
Hi guys,
by now that should be a rather well known set of changes.
The basic idea is that instead of the fixed exclusive/shared classes we now
attach an usage to each fence in the dma_resv object describing how the
operation represented by the fence is using the resources protected by
the dma_res
On 2/11/22 12:34, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU ac
Hi
Am 11.02.22 um 10:19 schrieb Javier Martinez Canillas:
Add support to convert from XR24 to reversed monochrome for drivers that
control monochromatic display panels, that only have 1 bit per pixel.
The function does a line-by-line conversion doing an intermediate step
first from XR24 to 8-bi
Hi
Am 11.02.22 um 10:19 schrieb Javier Martinez Canillas:
...
+
+static void ssd130x_display_pipe_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
+
Hi Jani,
On Fri, Feb 11, 2022 at 1:06 PM Jani Nikula wrote:
> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> > Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
> >> On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> >>> On 2/11/22 11:28, Andy Shevchenko wrote:
> On Fr
Hello Geert,
On 2/11/22 13:23, Geert Uytterhoeven wrote:
[snip]
+if (IS_ERR(bl)) {
>>>
+ret = PTR_ERR(bl);
+dev_err_probe(dev, ret, "Unable to register backlight
device\n");
+return ERR_PTR(ret);
>>>
>>> dev_err_prob
Hi Javier,
On Fri, Feb 11, 2022 at 1:06 PM Javier Martinez Canillas
wrote:
> On 2/11/22 12:33, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
> >> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
> >> OLED display contr
https://bugzilla.kernel.org/show_bug.cgi?id=201957
Ilia (infer...@gmail.com) changed:
What|Removed |Added
CC||infer...@gmail.com
--- Commen
Hello Jani,
On 2/11/22 13:05, Jani Nikula wrote:
[snip]
I don't see why a while loop would be an improvement here TBH.
>>>
>>> Less letters to parse when reading the code.
>>
>> It's a simple refactoring of code that has worked well so far. Let's
>> leave it as-is for now.
>
> IMO *always
On 2/11/22 12:33, Andy Shevchenko wrote:
> On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
>> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
>> OLED display controllers.
>>
>> It's only the core part of the driver and a bus specific driver is need
On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> Hi
>
> Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
>> On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
>>> On 2/11/22 11:28, Andy Shevchenko wrote:
On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wro
Hi
Am 11.02.22 um 12:10 schrieb Andy Shevchenko:
On Fri, Feb 11, 2022 at 10:19:23AM +0100, Javier Martinez Canillas wrote:
Add support to convert from XR24 to reversed monochrome for drivers that
control monochromatic display panels, that only have 1 bit per pixel.
The function does a line-by-
Hi
Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
On 2/11/22 11:28, Andy Shevchenko wrote:
On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
...
+static void drm_fb_xrgb_to_gray8_line(u8 *d
Hello Andy,
Thanks for your feedback.
On 2/11/22 12:10, Andy Shevchenko wrote:
[snip]
>> +static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
>> unsigned int pixels,
>> + unsigned int start_offset,
>> unsigned int end_len)
>> +{
>>
On Fri, Feb 11, 2022 at 10:22:53AM +0100, Javier Martinez Canillas wrote:
> The ssd130x DRM driver also makes use of this Device Tree binding to allow
> existing users of the fbdev driver to migrate without the need to change
> their Device Trees.
>
> Add myself as another maintainer of the bindin
On Fri, Feb 11, 2022 at 10:21:57AM +0100, Javier Martinez Canillas wrote:
> To make sure that tools like the get_maintainer.pl script will suggest
> to Cc me if patches are posted for this driver.
>
> Also include the Device Tree binding for the old ssd1307fb fbdev driver
> since the new DRM drive
If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill the
object into system memory if we can't make space.
XXX: Still needs IGTs. Including now j
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't impact DG1.
v2(Reported-by: kernel test rob
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU access. We choose to just
always set GPU_ONL
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable pla
If we need to make room for some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we hope
On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
> OLED display controllers.
>
> It's only the core part of the driver and a bus specific driver is needed
> for each transport interface supported by
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/gem/s
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will re
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftest
Differentiate between mappable vs non-mappable resources, also if this
is an actual range allocation ensure we set res->start as the starting
pfn. Later when we need to do non-mappable -> mappable moves then we
want TTM to see that the current placement is not compatible, which
should result in an
If the user doesn't require CPU access for the buffer, then
ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the
non-mappable portion of LMEM, on devices with small BAR.
v2(Thomas):
- The BO_ALLOC_TOPDOWN naming here is poor, since this is pure lies on
systems that don't e
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hells
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per-resource visible usage
will be useful for
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we will introduce a new
flag to override thi
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas Hell
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This series
On Fri, Feb 11, 2022 at 10:19:25AM +0100, Javier Martinez Canillas wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over I2C.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Javier Martinez Canill
On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 11:28, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
...
> >> +static void drm_fb_xrgb_to_gray8_line(u8 *dst, const u32 *src,
> >> unsigned int pixels
On Fri, Feb 11, 2022 at 10:19:23AM +0100, Javier Martinez Canillas wrote:
> Add support to convert from XR24 to reversed monochrome for drivers that
> control monochromatic display panels, that only have 1 bit per pixel.
>
> The function does a line-by-line conversion doing an intermediate step
>
On Tue, Feb 08, 2022 at 05:55:18PM -0800, Abhinav Kumar wrote:
> Hi Johannes
>
> On 2/8/2022 1:54 PM, Johannes Berg wrote:
> > On Tue, 2022-02-08 at 13:40 -0800, Abhinav Kumar wrote:
> > > >
> > > I am checking what usermode sees and will get back ( I didnt see an
> > > error do most likely it wa
On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
> There are cases where depending on the size of the devcoredump and the speed
> at which the usermode reads the dump, it can take longer than the current 5
> mins
> timeout.
>
> This can lead to incomplete dumps as the device is dele
From: Raphael Gallais-Pou
This patch adds the CRC hashing feature supported by some recent hardware
versions of the LTDC. This is useful for test suite such as IGT-GPU-tools
[1] where a CRTC output frame can be compared to a test reference frame
thanks to their respective CRC hash.
[1] https://c
Hello Andy,
On 2/11/22 11:28, Andy Shevchenko wrote:
> On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
>> Pull the per-line conversion logic into a separate helper function.
>>
>> This will allow to do line-by-line conversion in other helpers that
>> convert to a gray8 fo
On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
> Pull the per-line conversion logic into a separate helper function.
>
> This will allow to do line-by-line conversion in other helpers that
> convert to a gray8 format.
...
> +static void drm_fb_xrgb_to_gray8_line(u8
On 2/11/22 11:00, Matthew Auld wrote:
On Fri, 11 Feb 2022 at 09:56, Thomas Hellström
wrote:
On 2/11/22 10:52, Matthew Auld wrote:
On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
wrote:
On 2/10/22 13:13, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by defa
On Wed, 09 Feb 2022, Ville Syrjälä wrote:
> On Wed, Feb 09, 2022 at 11:09:41AM +0200, Jani Nikula wrote:
>> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
>> > On Thu, Feb 03, 2022 at 11:03:55AM +0200, Jani Nikula wrote:
>> >> Abstract link status check to a function that takes 128b/132b and 8b/10b
>>
On 2/10/22 13:13, Matthew Auld wrote:
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed
On 2/10/22 13:13, Matthew Auld wrote:
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't im
On Fri, 11 Feb 2022 at 09:56, Thomas Hellström
wrote:
>
>
> On 2/11/22 10:52, Matthew Auld wrote:
> > On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
> > wrote:
> >>
> >> On 2/10/22 13:13, Matthew Auld wrote:
> >>> Starting from DG2+, when dealing with LMEM, we assume that by default
> >>> all use
101 - 200 of 234 matches
Mail list logo
