Hi,
On 19/01/2022 13:28, Neil Armstrong wrote:
When the dw-hdmi bridge is in first place of the bridge chain, this
means there is no way to select an input format of the dw-hdmi HW
component.
Since introduction of display-connector, negotiation was broken since
the dw-hdmi negotiation code only
Hi Daniel,
Thanks for your patch!
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
Can't the actual frame buffer driver (which one?) used on olpc export
a pointer to its fb_i
Hi Helge,
Thanks for your patch!
On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote:
> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
> enable bitblt and fillrect hardware acceleration in the framebuffer
> console. If disabled, such acceleration will not be used, even if it
On 03/02/2022 18:07, Verdun, Jean-Marie wrote:
>
>> Maybe it does not look like, but this is actually a v2. Nick was asked
>> to change the naming for the nodes already in v1. Unfortunately it did
>> not happen, so we have vuart, spifi, vic and more.
>
>> It is a waste of reviewer
On Wed, Jan 19, 2022 at 9:35 PM wrote:
>
> From: Rodrigo Vivi
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to c
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There'
Hi everyone,
Since some operations can then lead to recursive handling nesting
dma_fence containers into each other is only allowed under some
restrictions.
dma_fence_array containers can be attached to dma_fence_chain
containers and dma_fence_chain containers by chaining them together.
In all o
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
include/linux/dma-fence-array.h | 15 +
It's not allowed to nest another dma_fence container into a dma_fence_array
or otherwise we can run into recursion.
Warn about that when we create a dma_fence_array.
v2: fix comment style and typo in the warning pointed out by Thomas
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Re
Drivers should not add containers as shared fences to the dma_resv
object, instead each fence should be added individually.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Hellström
---
drivers/dma-buf/dma-resv.c | 5 +
1 file changed, 5 insertions(+)
diff --
It's a reoccurring pattern that we need to extract the fence
from a dma_fence_chain object. Add a helper for this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 6 ++
include/linux/dma-fence-chain.h | 15 +++
2 files changed, 17 insertions(+), 4 deleti
Instead of manually extracting the fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index f7d8487799b2..
Chaining of dma_fence_chain objects is only allowed through the prev
fence and not through the contained fence.
Warn about that when we create a dma_fence_chain.
v2: fix comment style
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Reviewed-by: Thomas Hellström
---
drivers/dma-buf/
Hello Geert,
On 2/4/22 09:37, Geert Uytterhoeven wrote:
> On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote:
>> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
>> enable bitblt and fillrect hardware acceleration in the framebuffer
>> console. If disabled, such acceleration w
Hi Helge,
On Fri, Feb 4, 2022 at 11:17 AM Helge Deller wrote:
> On 2/4/22 09:37, Geert Uytterhoeven wrote:
> > On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote:
> >> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
> >> enable bitblt and fillrect hardware acceleration in th
On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote:
> Consolidate the wrapper functions to check for dma_fence
> subclasses in the dma_fence header.
>
> This makes it easier to document and also check the different
> requirements for fence containers in the subclasses.
>
> Signed-off-by: Ch
On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote:
> It's a reoccurring pattern that we need to extract the fence
> from a dma_fence_chain object. Add a helper for this.
>
> Signed-off-by: Christian König
I thought I'd reviewed this one already, but in case I didn't
Reviewed-by: Thomas H
On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote:
> Hi everyone,
>
> Since some operations can then lead to recursive handling nesting
> dma_fence containers into each other is only allowed under some
> restrictions.
>
> dma_fence_array containers can be attached to dma_fence_chain
> cont
On 28/01/22 7:48 pm, Matthew Auld wrote:
> On Thu, 27 Jan 2022 at 14:11, Arunpravin
> wrote:
>>
>> - Remove drm_mm references and replace with drm buddy functionalities
>> - Add res cursor support for drm buddy
>>
>> v2(Matthew Auld):
>> - replace spinlock with mutex as we call kmem_cache_zal
On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
> The DP 2.0 errata completely overhauls the 128b/132b link training, with
> no provisions for backward compatibility with the original DP 2.0
> specification.
>
> The changes are too intrusive to consider reusing the same code for both
Hi,
On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote:
> diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
> new file mode 100644
> index ..8b0a91234df4
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARCH_HPE_GXP
On Fri, 2022-02-04 at 12:05 +, Russell King (Oracle) wrote:
> On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote:
[]
> > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
[]
> > +static irqreturn_t gxp_time_interrupt(int irq, void *dev_id)
> > +{
> > +
On Fri, Feb 04, 2022 at 04:18:24AM -0800, Joe Perches wrote:
> On Fri, 2022-02-04 at 12:05 +, Russell King (Oracle) wrote:
> > On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote:
> > > + if (readb_relaxed(timer->control) & MASK_TCS_TC) {
> > > + writeb_relaxed(MASK_TCS
Am 04.02.22 um 11:40 schrieb Thomas Hellström:
On Fri, 2022-02-04 at 11:04 +0100, Christian König wrote:
Hi everyone,
Since some operations can then lead to recursive handling nesting
dma_fence containers into each other is only allowed under some
restrictions.
dma_fence_array containers ca
Am 04.02.22 um 12:22 schrieb Arunpravin:
On 28/01/22 7:48 pm, Matthew Auld wrote:
On Thu, 27 Jan 2022 at 14:11, Arunpravin
wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
v2(Matthew Auld):
- replace spinlock with mutex as
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> It's normal to list all linux/ includes before asm/ includes. Please
> rearrange.
Hi Nick
Since you are new to the kernel, please let me point out, you should
consider Russell comments fo
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 fb emulation, all the tests from Geert Uytterhoeven's fbtest
(https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes:
Add support to convert XR24 and 8-bit grayscale to reversed monochrome for
drivers that control monochromatic panels, that only have 1 bit per pixel.
The drm_fb_gray8_to_mono_reversed() helper was based on the function that
does the same in the drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-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
Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
controllers that can be programmed via an I2C interface. This is a port
of the ssd1307fb driver that already supports these devices.
A Device Tree binding is not added because the DRM driver is compatible
with the existing bin
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
On Fri, Feb 04, 2022 at 02:43:46PM +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
On Fri, 2022-02-04 at 12:31 +, Russell King (Oracle) wrote:
> On Fri, Feb 04, 2022 at 04:18:24AM -0800, Joe Perches wrote:
> > On Fri, 2022-02-04 at 12:05 +, Russell King (Oracle) wrote:
> > > On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote:
> > > > + if (readb_re
On Wed, 19 Jan 2022 at 13:28, Neil Armstrong wrote:
>
> When the dw-hdmi bridge is in first place of the bridge chain, this
> means there is no way to select an input format of the dw-hdmi HW
> component.
>
> Since introduction of display-connector, negotiation was broken since
> the dw-hdmi negot
Hello Andy,
On 2/4/22 14:57, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 02:43:46PM +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 fo
On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
> controllers that can be programmed via an I2C interface. This is a port
> of the ssd1307fb driver that already supports these devices.
>
> A Device
Hi,
On 04/02/2022 15:05, Robert Foss wrote:
On Wed, 19 Jan 2022 at 13:28, Neil Armstrong wrote:
When the dw-hdmi bridge is in first place of the bridge chain, this
means there is no way to select an input format of the dw-hdmi HW
component.
Since introduction of display-connector, negotiatio
On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote:
> On 2/4/22 14:57, Andy Shevchenko wrote:
> > On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote:
...
> > Stray change?
>
> Sigh, I'm not sure how added that change. Just ignore it, I'll fix it
> on v
Hi Javier,
On Fri, Feb 4, 2022 at 2:43 PM Javier Martinez Canillas
wrote:
> 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.
[...]
> This is a v2 that addresses all the issues pointed in v1, th
On 2/4/22 15:28, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote:
>> On 2/4/22 14:57, Andy Shevchenko wrote:
>>> On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>> Stray change?
>>
>> Sigh, I'm not sure how add
When the dw-hdmi bridge is in first place of the bridge chain, this
means there is no way to select an input format of the dw-hdmi HW
component.
Since introduction of display-connector, negotiation was broken since
the dw-hdmi negotiation code only worked when the dw-hdmi bridge was
in last positi
Hello Geert,
On 2/4/22 15:31, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Fri, Feb 4, 2022 at 2:43 PM Javier Martinez Canillas
> wrote:
>> 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.
>
On Fri, Feb 4, 2022 at 5:04 AM Christian König
wrote:
>
> Instead of manually extracting the fence.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drive
Hi
Am 04.02.22 um 14:43 schrieb Javier Martinez Canillas:
Add support to convert XR24 and 8-bit grayscale to reversed monochrome for
drivers that control monochromatic panels, that only have 1 bit per pixel.
The drm_fb_gray8_to_mono_reversed() helper was based on the function that
does the same
Am 04.02.22 um 16:52 schrieb Thomas Zimmermann:
[...]
+/**
+ * drm_fb_xrgb_to_mono_reversed - Convert XRGB to reversed
monochrome
+ * @dst: reversed monochrome destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines
within dst
+ * @src: XRGB source bu
Am 2022-02-04 um 02:13 schrieb Christian König:
Am 04.02.22 um 04:11 schrieb Rajneesh Bhardwaj:
Noticed the below warning while running a pytorch workload on vega10
GPUs. Change to trylock to avoid conflicts with already held reservation
locks.
[ +0.03] WARNING: possible recursive lockin
Am 04.02.22 um 17:23 schrieb Felix Kuehling:
Am 2022-02-04 um 02:13 schrieb Christian König:
Am 04.02.22 um 04:11 schrieb Rajneesh Bhardwaj:
Noticed the below warning while running a pytorch workload on vega10
GPUs. Change to trylock to avoid conflicts with already held
reservation
locks.
[
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
Replace all occurance of cache_clflush_range with
drm_clflush_virt_range. This will prevent compile errors on non-x86
platforms.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Signed-of
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added
more patches to convert addi
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/driv
Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
Over time dma-buf-map grew up to more functionality than the one used by
dma-buf: in fact it's just a shim layer to abstract system memory, that
can be accessed via regular load and store, from IO memory that needs to
be acessed
Hi Geert,
On 2/4/22 11:24, Geert Uytterhoeven wrote:
> On Fri, Feb 4, 2022 at 11:17 AM Helge Deller wrote:
>> On 2/4/22 09:37, Geert Uytterhoeven wrote:
>>> On Wed, Feb 2, 2022 at 8:05 PM Helge Deller wrote:
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable b
The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding instructions on the nomination process to membership in the
near future.
Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
2nd version of https://patchwork.freedesktop.org/series/99378/
As first patch I'm including the dma-buf-map rename to iosys-map for
completeness and to allow the other patches to be reviewed. However the
first patch was also sent by itself.
I think all the feedback from v1 was incorporated in thi
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
- iosys_map_memcpy_from(): we may need to copy data from I/O
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
driv
Add a variant of shmem_read() that takes a iosys_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use iosys_map as destination.
Reworking __shmem_rw() to share the implement
Convert intel_guc_ads_create() and initialization to use iosys_map
rather than plain pointer and save it in the guc struct. This will help
with additional updates to the ads_blob after the
creation/initialization by abstracting the IO vs system memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Dan
Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
Over time dma-buf-map grew up to more functionality than the one used by
dma-buf: in fact it's just a shim layer to abstract system memory, that
can be accessed via regular load and store, from IO memory that needs to
be acessed
Add helpers on top of iosys_map_read_field() /
iosys_map_write_field() functions so they always use the right
arguments and make code easier to read.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De M
Use iosys_map to write the policies update so access to IO and system
memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Use iosys_map to write the fields system_info.mapping_table[][].
Since we already have the info_map around where needed, just use it
instead of going through guc->ads_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Sig
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
Use iosys_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_
In the other places in this function, guc->ads_map is being protected
from access when it's not yet set. However the last check is actually
about guc->ads_golden_ctxt_size been set before. These checks should
always match as the size is initialized on the first call to
guc_prep_golden_context(), b
Now we have the access to content of GuC ADS either using iosys_map
API or using a temporary buffer. Remove guc->ads_blob as there shouldn't
be updates using the bare pointer anymore.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo
Use iosys_map_memset() to zero the private data as ADS may be either
on system or IO memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c |
Now that the regset list is prepared, convert guc_mmio_reg_state_init()
to use iosys_map to copy the array to the final location and
initialize additional fields in ads.reg_state_list.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraol
Use iosys_map to write the fields ads.capture_*.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
1 file changed, 5 insertions(
Currently guc_mmio_reg_add() relies on having enough memory available in
the array to add a new slot. It uses
`GEM_BUG_ON(count >= regset->size);` to protect going above the
threshold.
In order to allow guc_mmio_reg_add() to handle the memory allocation by
itself, it must return an error in case o
Now that all the called functions from __guc_ads_init() are converted to
use ads_map, stop using ads_blob in __guc_ads_init().
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu
Use the saved ads_map to prepare the golden context. One difference from
the init context is that this function can be called before there is a
gem object (and thus the guc->ads_map) to calculare the size of the
golden context that should be allocated for that object.
So in this case the function
The suballocation manager itself is not dependent on any implementation detail,
and can be made generic. I want to potentially use it inside i915, as it looks
like a clean implementation to do so. :)
Looking for feedback and some testing, as I don't have a amdgpu/radeon myself.
Only compile tested
Use the generic suballocation helper lifted from amdgpu.
Note that the generic suballocator only allows a single alignment,
so we may waste a few more bytes for radeon_semaphore, shouldn't
be a big deal, could be re-added if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/rad
Now that the suballocation helper is generic, we can use it in amdgpu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 21 +-
drivers/gpu/drm/amd/amdgpu/am
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Makefile | 4 +-
drivers/gpu/drm/drm_suballoc.c | 424 +
include/drm/drm_suballoc.h |
It seems that some laptops will report having both an eDP and LVDS
connector, even though only the LVDS connector is actually hooked up. This
can lead to issues with backlight registration if the eDP connector ends up
getting registered before the LVDS connector, as the backlight device will
then b
Oh, that's on my TODO list for years!
Am 04.02.22 um 18:48 schrieb Maarten Lankhorst:
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Makefile | 4 +-
drivers/gpu/drm
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kern
split into 3 patches
1) widebus timing engine programming
2) dsc timing engine
3) enable widebus feature base on chip hardware revision
Kuogee Hsieh (3):
drm/msm/dp: revise timing engine programming to support widebus
feature
drm/msm/dp: revise timing engine programming to support compre
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal wid
Divides horizontal width by 3 at timing engine of interface. There are
major part of compression (DSC) programming have to be done at DSC
controller which is not covered by this patch.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 22 ++
drive
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled base on chip's
hardware revisi
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.
On 2/4/2022 01:55, Daniel Vetter wrote:
On Wed, Jan 19, 2022 at 9:35 PM wrote:
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and variou
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
- iosys_map_memcpy
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
Add a variant of shmem_read() that takes a iosys_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use iosys_map as destina
Hello Andy,
Thanks for your feedback.
On 2/4/22 15:26, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
>> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
>> controllers that can be programmed via an I2C interface. This is
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Dan
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
Use iosys_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas D
On Fri, Feb 04, 2022 at 07:48:10PM +0100, Thomas Zimmermann wrote:
Hi
Am 04.02.22 um 18:44 schrieb Lucas De Marchi:
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zi
Hello Thomas,
Thanks a lot for your feedback.
On 2/4/22 16:52, Thomas Zimmermann wrote:
[snip]
>> +static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
>> size_t pixels)
>> +{
>> +unsigned int xb, i;
>> +
>> +for (xb = 0; xb < pixels / 8; xb++) {
>
> In practice, all
Currently we can get a warning on systems with eDP backlights like so:
nv_backlight: invalid backlight type
WARNING: CPU: 4 PID: 454 at drivers/video/backlight/backlight.c:420
backlight_device_register+0x226/0x250
This happens as a result of us not filling out props.type for the eDP
backl
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> No idea why con2fb_acquire_newinfo() initializes much less than
> fbcon_startup(), but so be it. From a quick look most of the
> un-initialized stuff should be fairly harmless, but who knows.
>
> Signed-off-by: Daniel Vetter
> Cc: D
Hi
Am 04.02.22 um 19:29 schrieb Christian König:
Oh, that's on my TODO list for years!
Am 04.02.22 um 18:48 schrieb Maarten Lankhorst:
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
driver
On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote:
> Now we get to the real motiviation, because fbmem.c insists that
> that's the right lock for these.
>
> Ofc fbcon.c has a lot more places where it probably should call
> lock_fb_info(). But looking at fbmem.c at least most of these s
1 - 100 of 155 matches
Mail list logo
