On 1/20/2022 12:14 AM, Alistair Popple wrote:
On Tuesday, 11 January 2022 9:32:00 AM AEDT Alex Sierra wrote:
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Hi Lucas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20220125]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next linus/master airlied/drm-next
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that copies the struct and add the offset to the proper
address.
Well
On Tue, Jan 25, 2022 at 07:03:41PM +0200, Jani Nikula wrote:
> Add some of the new additions from DP 2.0 E11.
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> include/drm/dp/drm_dp_helper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
On Thu, Jan 27, 2022 at 08:24:04AM +0100, Christian König wrote:
> Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > In certain situations it's useful to be able to read or write to an
> > offset that is calculated by having the memory layout given by a struct
> > declaration. Usually we are going
On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that
Hi Dave, Daniel,
Fixes for 5.17.
The following changes since commit e783362eb54cd99b2cac8b3a9aeac942e6f6ac07:
Linux 5.17-rc1 (2022-01-23 10:12:53 +0200)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.17-2022-01-26
for you to
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
In certain situations it's useful to be able to read or write to an
offset that is calculated by having the memory layout given by a struct
declaration. Usually we are going to read/write a u8, u16, u32 or u64.
Add a pair of macros
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 23 +--
lib/test_hmm_uapi.h | 8
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
owned by a device that can be mapped into CPU page tables like
MEMORY_DEVICE_GENERIC and can also be migrated like
MEMORY_DEVICE_PRIVATE.
Christoph, the suggestion to incorporate Ralph Campbell’s refcount
cleanup patch into our
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results
Coherent device type memory on VRAM to RAM migration, has similar access
as System RAM from the CPU. This flag sets the source from the sender.
Which in Coherent type case, should be set as
MIGRATE_VMA_SELECT_DEVICE_COHERENT.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
Avoid long term pinning for Coherent device type pages. This could
interfere with their own device memory manager. For now, we are just
returning error for PIN_LONGTERM Coherent device type pages. Eventually,
these type of pages will get migrated to system memory, once the device
migration pages
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
Reviewed-by: Alistair Popple
---
v2:
Add more
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
---
v2:
condition added when migrations from device coherent pages.
---
include/linux/migrate.h | 1 +
If only linear modifier is advertised, since there are many drivers that
only linear supported, the DRM core should handle this rather than
open-coding in every driver. However, there are legacy drivers such as
radeon that do not support modifiers but infer the actual layout of the
underlying
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the DRM core should handle this
rather than open-coding in every driver.
In this patch series, these drivers expose format modifiers based on the
following
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/drm_plane.c | 23 +--
include/drm/drm_plane.h | 3 +++
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git
The allow_fb_modifiers flag is unnecessary since it has been replaced
with fb_modifiers_not_supported flag.
Signed-off-by: Tomohito Esaki
---
drivers/gpu/drm/selftests/test-drm_framebuffer.c | 1 -
include/drm/drm_mode_config.h| 16
2 files changed, 17
On Tue, Jan 25, 2022 at 2:25 PM Hsin-Yi Wang wrote:
>
> On Wed, Jan 19, 2022 at 11:36 PM Robert Foss wrote:
> >
> > Hey Hsin-Yi,
> >
> > While I can review this patch, I don't have the authority to merge it
> > since it is outside the scope of my maintainership. Rob Herring,
> > Daniel Vetter or
On 1/26/22 21:04, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2022-01-26-21-04 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
From: Oleksandr Suvorov
VESA Display Monitor Timing v1.13 has recommendations for the historical
VGA mode 640x480 60Hz. These parameters are compatible with EDT
ET057090DHU recommended timings.
Use VESA DMT timing parameters for EDT ET057090DHU panel.
Signed-off-by: Oleksandr Suvorov
Cc:
Adds decoder dt-bindings for mt8195.
Signed-off-by: Yunfei Dong
---
.../bindings/media/mediatek,vcodec-subdev-decoder.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
Adds compatible for mt8195 platform.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
Vp8 need to use MM21, but vp9 and h264 need to use HyFbc mode
for mt8195. Vp8/vp9/h264 use the same MM21 format for mt8192.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 41 +++
1 file changed, 41 insertions(+)
diff --git
Firstly, add mt8195 soc lat hardware and compatible, then add documents.
For vp8 only support MM21 mode, H264/vp9 support MT21C, need to separate
them. Next, initialize vp9 stateless decoder parameters. Lastly, enable
H264 inner racing mode to reduce hardware latency.
Patch 1~4 add mt8195 soc lat
Adds decoder dt-bindings for compatible "mediatek,mtk-vcodec-lat-soc".
Signed-off-by: Yunfei Dong
---
.../media/mediatek,vcodec-subdev-decoder.yaml | 49 +++
1 file changed, 49 insertions(+)
diff --git
Add lat soc compatible and to support lat soc power/clk helper.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 12 +---
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 2 ++
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 16
In order to reduce decoder latency, enable H264 inner racing mode.
Send lat trans buffer information to core when trigger lat to work,
need not to wait until lat decode done.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 +++
From: Tinghan Shen
When SCP timeout during playing video, kernel crashes with following
message. It's caused by accessing NULL pointer in vpu_dec_ipi_handler.
This patch doesn't solve the root cause of NULL pointer, but merely
prevent kernel crashed when encounter the NULL pointer.
After
Init some of VP9 frame decode params to default value.
Signed-off-by: Yunfei Dong
---
drivers/media/v4l2-core/v4l2-ctrls-core.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c
b/drivers/media/v4l2-core/v4l2-ctrls-core.c
index
On Wed, Jan 26, 2022 at 11:31:02PM +0100, Daniel Vetter wrote:
> dOn Wed, Jan 26, 2022 at 3:46 PM Dan Carpenter
> wrote:
> >
> > The other advantage of staging is the I don't think syzbot enables it.
> > I guess it's easier to persuade Dmitry to ignore STAGING than it was to
> > get him to
On Tue, Jan 25, 2022 at 07:03:43PM +0200, Jani Nikula wrote:
> +static bool
> +intel_dp_128b132b_lane_cds(struct intel_dp *intel_dp,
> +const struct intel_crtc_state *crtc_state,
> +int lttpr_count)
> +{
> + struct intel_encoder *encoder =
On Tue, Jan 25, 2022 at 07:03:44PM +0200, Jani Nikula wrote:
> Abstract link status check to a function that takes 128b/132b and 8b/10b
> into account, and use it. Also dump link status on failures.
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
>
On Thu, Jan 27, 2022 at 02:51:56PM +0800, tangmeng wrote:
> Replace disbale with disable and replace unavaibale with unavailable.
>
> Signed-off-by: tangmeng
> ---
> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
> drivers/pcmcia/rsrc_nonstatic.c
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
Just like memcpy_toio(), there is also need to write a direct value to a
memory block. Add dma_buf_map_memset() to abstract memset() vs memset_io()
Cc: Matt Roper
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc:
On Tue, Jan 25, 2022 at 07:03:39PM +0200, Jani Nikula wrote:
> The DP 2.0 errata changes DP_128B132B_TRAINING_AUX_RD_INTERVAL (DPCD
> 0x2216) completely. Add a new function to read that. Follow-up will need
> to clean up existing functions.
>
> v2: fix reversed interpretation of bit 7 meaning
Am 27.01.22 um 08:36 schrieb Matthew Brost:
[SNIP]
/**
* dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
* @dst: The dma-buf mapping structure
@@ -263,4 +304,44 @@ static inline void dma_buf_map_incr(struct dma_buf_map
*map, size_t incr)
map->vaddr += incr;
This series:
1. Enables support of GuC to execute error-
state-capture based on a list of MMIO
registers the driver registers and GuC will
dump and report back right before a GuC
triggered engine-reset event.
2. Updates the ADS blob creation to register lists
of global
On Tue, 25 Jan 2022 at 21:26, Kuogee Hsieh wrote:
>
>
> On 1/24/2022 5:50 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-01-24 14:44:52)
> >> DP driver is a generic driver which supports both eDP and DP.
> >> For debugging purpose it is required to have capabilities to
> >> differentiate
On 1/26/22 12:18, Javier Martinez Canillas wrote:
> On 1/26/22 11:59, Helge Deller wrote:
>> On 1/26/22 11:02, Andy Shevchenko wrote:
>
> [snip]
>
>>> P.S. For the record, I will personally NAK any attempts to remove that
>>> driver from the kernel. And this is another point why it's better not
On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
> On 1/26/22 12:18, Javier Martinez Canillas wrote:
> > On 1/26/22 11:59, Helge Deller wrote:
> >> On 1/26/22 11:02, Andy Shevchenko wrote:
> >
> > [snip]
> >
> >>> P.S. For the record, I will personally NAK any attempts to remove that
On 1/26/22 11:28, Dan Carpenter wrote:
> On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
>> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
>> wrote:
>>> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
>>> wrote:
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
>>
>> ...
On 1/26/22 9:37 AM, Maarten Lankhorst wrote:
set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221]
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 11:28, Dan Carpenter wrote:
> > On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
> >> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
> >> wrote:
> >>> On Wed, Jan 26, 2022 at 10:52 AM Thomas
On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 11:59, Helge Deller wrote:
> > On 1/26/22 11:02, Andy Shevchenko wrote:
>
> [snip]
>
> >> P.S. For the record, I will personally NAK any attempts to remove that
> >> driver from the kernel. And this is another
On Wed, Jan 26, 2022 at 02:19:37PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 13:56, Greg Kroah-Hartman wrote:
> >>fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?)
>
> This was a copy and paste error. It should had been:
>
>(DRM driver in
On 1/26/22 14:12, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
>> On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
>>> On 1/26/22 11:31, Daniel Vetter wrote:
>
> ...
>
>>> You are describing a transitioning over to DRM - which is Ok.
Am 25.01.22 um 17:37 schrieb Daniel Vetter:
On Mon, Jan 24, 2022 at 01:25:06PM +0100, Christian König wrote:
It makes sense to have this in the common manager for debugging and
accounting of how much resources are used.
v2: cleanup kerneldoc a bit
Signed-off-by: Christian König
Reviewed-by:
On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
> > > Since we got a maintainer for fbdev, I would like to
> > > unorphan fbtft (with the idea of
On 1/26/22 11:31, Daniel Vetter wrote:
> On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
> wrote:
>>
>> On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
>>> Let's maintain occasional fixes to the fbtft driver.
>>>
>>> Signed-off-by: Andy Shevchenko
>>> ---
>>> MAINTAINERS | 4
On 1/26/22 11:59, Helge Deller wrote:
> On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
>> P.S. For the record, I will personally NAK any attempts to remove that
>> driver from the kernel. And this is another point why it's better not
>> to be under the staging.
>
> I agree. Same as for me to
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
> On 1/26/22 11:31, Daniel Vetter wrote:
> > On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
> > wrote:
...
> > On the other hand ... why does it have to be resurrecting fbdev?
> > There's an entire community of people who really
On Wed, Jan 26, 2022 at 12:27:19PM +0100, Daniel Vetter wrote:
> On Wed, Jan 26, 2022 at 12:18 PM Helge Deller wrote:
> > On 1/26/22 11:31, Daniel Vetter wrote:
...
> > You are describing a transitioning over to DRM - which is Ok.
> > But on that way there is no need to ignore, deny or even
On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
> > On 1/26/22 11:31, Daniel Vetter wrote:
...
> > You are describing a transitioning over to DRM - which is Ok.
> > But on that way there is no need to ignore,
On Wed, Jan 26, 2022 at 12:31:40PM +0100, Thomas Zimmermann wrote:
> Am 26.01.22 um 12:17 schrieb Helge Deller:
...
> And none of those examples is out-ruled by DRM. In fact we do support
> devices that fall in those categories.
>
> This is last week's discussion all over again.
Fine, write a
On 1/26/22 13:56, Greg Kroah-Hartman wrote:
[snip]
>>fb_ili9341.c (DRM driver in drivers/gpu/drm/tiny/mi0283qt.c ?)
This was a copy and paste error. It should had been:
(DRM driver in drivers/gpu/drm/tiny/ili9341.c)
>>fb_ili9481.c
>>fb_ili9486.c (DRM driver in
On Wed, Jan 26, 2022 at 01:56:11PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
> > On 1/26/22 11:28, Dan Carpenter wrote:
...
> >fb_hx8347d.c (DRM driver in drivers/gpu/drm/tiny/hx8357d.c)
> >fb_hx8357d.c (DRM driver in
On 1/26/22 14:18, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 01:56:11PM +0100, Greg Kroah-Hartman wrote:
>> On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
>>> On 1/26/22 11:28, Dan Carpenter wrote:
>
> ...
>
>>>fb_hx8347d.c (DRM driver in
On 1/26/22 15:11, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
>> On 1/26/22 14:27, Andy Shevchenko wrote:
>>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
On 1/26/22 11:59, Helge Deller wrote:
> On 1/26/22
On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 15:11, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
> >> On 1/26/22 14:27, Andy Shevchenko wrote:
> >>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier
On Wed, Jan 26, 2022 at 11:03 AM Andy Shevchenko
wrote:
>
> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
> > > Since we got a maintainer for fbdev, I would like to
> > > unorphan fbtft (with the idea of sending PRs
On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi
> > >
> > > Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
> > > > Since we got a
On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
> On 1/26/22 11:31, Daniel Vetter wrote:
> > On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
> > wrote:
> >>
> >> On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
> >>> Let's maintain occasional fixes to the fbtft
On Wed, Jan 26, 2022 at 12:18 PM Helge Deller wrote:
>
> On 1/26/22 11:31, Daniel Vetter wrote:
> > On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
> > wrote:
> >>
> >> On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
> >>> Let's maintain occasional fixes to the fbtft driver.
Hi
Am 26.01.22 um 11:59 schrieb Helge Deller:
On 1/26/22 11:02, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann wrote:
Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
Since we got a maintainer for fbdev, I would like to
unorphan fbtft (with the idea of sending PRs to
On 1/26/22 12:38, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
>> On 1/26/22 12:18, Javier Martinez Canillas wrote:
>>> On 1/26/22 11:59, Helge Deller wrote:
On 1/26/22 11:02, Andy Shevchenko wrote:
>>>
>>> [snip]
>>>
> P.S. For the record, I
On Wed, Jan 26, 2022 at 11:31:45AM +0100, Daniel Vetter wrote:
> On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
> wrote:
> > On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
...
> > I'm ok with the files moving if the dri developers agree with it. It's
> > up to them, not
On Wed, Jan 26, 2022 at 12:15:48PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
> > wrote:
> > > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Jan 26,
On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
> Am 26.01.22 um 11:59 schrieb Helge Deller:
...
> It's always for the same reason: the hw is old and devs have moved on.
It's pity to have a working system with an old hardware that no one in
the kernel community gives a shit
On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 14:12, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 12:26:36PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Jan 26, 2022 at 12:17:08PM +0100, Helge Deller wrote:
> >>> On 1/26/22 11:31, Daniel Vetter
Hi,
On 1/26/22 14:47, Hans de Goede wrote:
> Hi All,
>
> On 1/23/22 10:10, Tong Zhang wrote:
>> when acpi=off is provided in bootarg, kernel crash with
>>
>> [1.252739] BUG: kernel NULL pointer dereference, address:
>> 0018
>> [1.258308] Call Trace:
>> [1.258490] ?
On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
wrote:
linux/string_helpers.h provides a helper to return "yes"/"no" strings.
Replace the open coded versions with str_yes_no(). The places were
oops, I replaced yesno() here
On 1/26/22 11:02, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> wrote:
>> Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
>>> Since we got a maintainer for fbdev, I would like to
>>> unorphan fbtft (with the idea of sending PRs to Helge)
>>> and move it out of
On Tue, Jan 25, 2022 at 8:44 PM Helge Deller wrote:
>
> On 1/25/22 20:17, Helge Deller wrote:
> > On 1/25/22 20:12, Helge Deller wrote:
> >> Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
> >> enable bitblt and fillrect hardware acceleration in the framebuffer
> >> console.
Hi
Am 26.01.22 um 12:31 schrieb Helge Deller:
On 1/26/22 12:18, Javier Martinez Canillas wrote:
On 1/26/22 11:59, Helge Deller wrote:
On 1/26/22 11:02, Andy Shevchenko wrote:
[snip]
P.S. For the record, I will personally NAK any attempts to remove that
driver from the kernel. And this is
Am 25.01.22 um 23:37 schrieb Andrey Grodzovsky:
Defined a reset_domain struct such that
all the entities that go through reset
together will be serialized one against
another. Do it for both single device and
XGMI hive cases.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Daniel Vetter
On Wed, Jan 26, 2022 at 12:51:46PM +0100, Helge Deller wrote:
> On 1/26/22 12:38, Greg Kroah-Hartman wrote:
> > On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote:
> >> On 1/26/22 12:18, Javier Martinez Canillas wrote:
> >>> On 1/26/22 11:59, Helge Deller wrote:
> On 1/26/22 11:02,
On Wed, Jan 26, 2022 at 12:54:13AM -0800, Joe Perches wrote:
> On Tue, 2022-01-25 at 22:21 +0200, Andy Shevchenko wrote:
> > Replace 'depends on FB_TFT' by 'if FB_TFT ... endif'
> > for the sake of deduplication.
> []
> > diff --git a/drivers/video/fbtft/Kconfig b/drivers/video/fbtft/Kconfig
> []
On Wed, Jan 26, 2022 at 11:52:16AM +0100, Daniel Vetter wrote:
> On Wed, Jan 26, 2022 at 11:47 AM Greg Kroah-Hartman
> wrote:
> > On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
> > > On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann
> > > wrote:
> > > > Am 25.01.22 um 21:21
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less
On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 14:27, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
> >> On 1/26/22 11:59, Helge Deller wrote:
> >>> On 1/26/22 11:02, Andy Shevchenko wrote:
...
>
Hi
Am 26.01.22 um 12:17 schrieb Helge Deller:
On 1/26/22 11:31, Daniel Vetter wrote:
On Wed, Jan 26, 2022 at 9:31 AM Greg Kroah-Hartman
wrote:
On Tue, Jan 25, 2022 at 10:21:14PM +0200, Andy Shevchenko wrote:
Let's maintain occasional fixes to the fbtft driver.
Signed-off-by: Andy
On Wed, Jan 26, 2022 at 02:43:45AM -0800, Lucas De Marchi wrote:
> On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
> > wrote:
...
> > > 411986 104906176 428652 68a6c drm.ko.old
> > > 411986 104906176 428652
On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
> On 1/26/22 11:28, Dan Carpenter wrote:
> > On Wed, Jan 26, 2022 at 12:04:26PM +0200, Andy Shevchenko wrote:
> >> On Wed, Jan 26, 2022 at 12:02 PM Andy Shevchenko
> >> wrote:
> >>> On Wed, Jan 26, 2022 at 10:52 AM Thomas
On 1/25/22 20:35, Robert Beckett wrote:
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for
On 1/25/22 20:35, Robert Beckett wrote:
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
> > On 1/26/22 14:12, Andy Shevchenko wrote:
...
> > I've just bought a SSD1306 (I2C) based one and will attempt to write a DRM
> > driver using
On 1/26/22 15:10, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
>> On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
>>> On 1/26/22 14:12, Andy Shevchenko wrote:
>
> ...
>
>>> I've just bought a SSD1306 (I2C) based one and will
On 2022-01-26 04:39, Lucas De Marchi wrote:
> Remove the local yesno() implementation and adopt the str_yes_no() from
> linux/string_helpers.h.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 14 +-
On Wed, Jan 26, 2022 at 5:25 PM Peter Geis wrote:
> +
> + ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE);
> + if (ret)
> + dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate:
> %d\n", ret);
You are setting the cec clock rate after it has
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
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(),
Use dma_buf_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
---
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,
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
---
1 - 100 of 271 matches
Mail list logo
