On 2/10/22 13:13, Matthew Auld wrote:
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 spac
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 userspace allocations should be placed in the non-mappable portion
of LMEM. Note that
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 userspace allocations should be placed in the non-mappable portion
> > of LMEM. Note that dumb buffers are not includ
On 2/10/22 13:13, 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
Fbdev's deferred I/O sorts all dirty pages by default, which incurs a
significant overhead. Make the sorting step optional and update the few
drivers that require it. Use a FIFO list by default.
Most fbdev drivers with deferred I/O build a bounding rectangle around
the dirty pages or simply flush
Return early if a page is already in the list of dirty pages for
deferred I/O. This can be detected if the page's list head is not
empty. Keep the list head initialized while the page is not enlisted
to make this work reliably.
v2:
* update comment and fix spelling (Sam)
Signed-off-by: Th
Remove the bubble sort from fbdev defered-I/O page tracking. Most
drivers only want to know which pages have been written to. The exact
order is not important.
Tested on simpledrm.
v2:
* make sorted page lists the special case (Sam)
* improve several comments (Sam)
Thomas Zimmerm
On 2/11/22 04:27, zhaoxiao wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypassed the hierarchical setup and
On 2/10/22 13:13, Matthew Auld wrote:
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
On 2/10/22 13:13, Matthew Auld wrote:
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-b
Am 11.02.22 um 10:19 schrieb Javier Martinez Canillas:
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
On 2/10/22 13:13, Matthew Auld wrote:
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
On 2/10/22 13:13, Matthew Auld wrote:
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 th
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
Hi,
On 2/11/22 10:00, Yehezkel Bernat wrote:
> On Fri, Feb 11, 2022 at 12:43 AM Mario Limonciello
> wrote:
>>
>> Currently `pci_is_thunderbolt_attached` is used to indicate a device
>> is connected externally.
>>
>> The PCI core now marks such devices as removable and downstream drivers
>> can us
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
On 2/10/22 13:13, Matthew Auld wrote:
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
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
---
Changes in v4:
- Remove unnecessary casting (Geert Uytterhoeven)
- Remove redundant blank lines (Andy
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
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
---
(no changes since v3)
Changes in v3:
- Add a drm_fb_xr
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.
On 10/02/22 9:40 pm, Matthew Auld wrote:
> On 27/01/2022 14:11, Arunpravin wrote:
>> - Make drm_buddy_alloc a single function to handle
>>range allocation and non-range allocation demands
>>
>> - Implemented a new function alloc_range() which allocates
>>the requested power-of-two block
Hi Sam
Am 10.02.22 um 22:00 schrieb Sam Ravnborg:
Hi Thomas,
On Thu, Feb 10, 2022 at 03:11:11PM +0100, Thomas Zimmermann wrote:
Return early if a page is already in the list of dirty pages for
deferred I/O. This can be detected if the page's list head is not
empty. Keep the list head initializ
On Fri, Feb 11, 2022 at 12:43 AM Mario Limonciello
wrote:
>
> Currently `pci_is_thunderbolt_attached` is used to indicate a device
> is connected externally.
>
> The PCI core now marks such devices as removable and downstream drivers
> can use this instead.
>
> Signed-off-by: Mario Limonciello
>
On 10/02/2022 21:47, john.c.harri...@intel.com wrote:
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational (because it is still useful to know that
resets are
On 2/9/22 17:26, Javier Martinez Canillas wrote:
> On 2/9/22 17:08, Andy Shevchenko wrote:
>
> [snip]
>
>>> Agreed, as mentioned I'll give it a try to sending all the data as a
>>> bulk write with regmap.
>>
>> Ah, it might be that it should be noinc bulk op. Need to be checked anyway.
>>
>
> Ye
Hi,
On 2/10/22 23:43, Mario Limonciello wrote:
> Currently `pci_is_thunderbolt_attached` is used to indicate a device
> is connected externally.
>
> The PCI core now marks such devices as removable and downstream drivers
> can use this instead.
>
> Signed-off-by: Mario Limonciello
Thanks, this
On 2/9/22 13:37, Javier Martinez Canillas wrote:
[snip]
>
>> There is still an issue with the cursor, though.
>> After doing "echo hello > /dev/tty0", the text appears, but the cursor
>> is gone. "clear > /dev/tty0" brings it back.
>>
>
> Hmm, I was able to reproduce this too. Thanks for pointi
On 2022-01-27 00:29:37 [+0100], Mario Kleiner wrote:
> Hi, first thank you for implementing these preempt disables according to
Hi Mario,
> the markers i left long ago. And sorry for the rather late reply.
>
> I had a look at the code, as of Linux 5.16, and did also a little test run
> (of a stan
Hi
Am 11.02.22 um 08:58 schrieb Dan Carpenter:
On Thu, Feb 10, 2022 at 10:16:45PM +0100, Sam Ravnborg wrote:
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index 3727b1ca87b1..1f672cf253b2 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/vi
Hi Sam
Am 10.02.22 um 22:16 schrieb Sam Ravnborg:
Hi Thomas,
On Thu, Feb 10, 2022 at 03:11:13PM +0100, Thomas Zimmermann wrote:
Fbdev's deferred I/O sorts all dirty pages by default, which incurs a
significant overhead. Make the sorting step optional and update the few
drivers that require it.
On Fri, Feb 11, 2022 at 11:19:03AM +0530, Ramalingam C wrote:
> From: Matt Roper
>
> DG2 is the first platform, that supports TC but not TBT.
> interrupt code is updated to avoid trying to process
> TBT-specific bits and registers.
Is that a real concern?
>
> Cc: Swathi Dhanavanthri
> Signed-
Hi,
On Fri, 4 Feb 2022 15:33:37 +0100, 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-hd
201 - 234 of 234 matches
Mail list logo
