On Mon, May 2, 2022 at 9:37 AM Michael Kelley wrote:
>
> The DRM Hyper-V driver has special case code for running on the first
> released versions of Hyper-V: 2008 and 2008 R2/Windows 7. These versions
> are now out of support (except for extended security updates) and lack
> support for
On 5/3/22 02:31, Rob Herring wrote:
Hi,
[...]
.../bindings/display/bridge/fsl,ldb.yaml | 92 +++
1 file changed, 92 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
A little quick on the applying...
Right
diff
Add missing reg and reg-names properties for both 'LDB_CTRL'
and 'LVDS_CTRL' registers.
Fixes: 463db5c2ed4ae ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB
bridge")
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Peng Fan
Cc: Rob Herring
On 5/3/2022 5:44 PM, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
The EU priority register must be updated by the GuC rather than the
driver as it is context specific and only the GuC knows which context
is currently executing.
Cc: John Harrison
Cc: Matt Roper
Signed-off-by: Matthew
On 4/11/22 16:46, Robin Murphy wrote:
> @@ -1092,6 +1092,19 @@ static bool host1x_drm_wants_iommu(struct
> host1x_device *dev)
> struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
> struct iommu_domain *domain;
>
> + /* For starters, this is moot if no IOMMU is available
From: Matthew Brost
The EU priority register must be updated by the GuC rather than the
driver as it is context specific and only the GuC knows which context
is currently executing.
Cc: John Harrison
Cc: Matt Roper
Signed-off-by: Matthew Brost
Signed-off-by: Aravind Iddamsetty
---
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
Instead of querying the CTL for the flush mask (for SSPP, LM or DSPP),
storing the mask in the mixer configuration and then pushing the mask to
the CTL, tell CTL to cache the flush in place.
This follows the pattern of other
Hi,
On Mon, Apr 18, 2022 at 10:18 AM Douglas Anderson wrote:
>
> This is the 2nd four patches from my RFC series ("drm/dp: Improvements
> for DP AUX channel") [1]. I've broken the series in two so we can make
> progress on the two halves separately.
>
> v2 of this series changes to add
Hi,
On Mon, Apr 18, 2022 at 4:10 PM Doug Anderson wrote:
>
> > > 5. In general I've been asserting that it should be up to the panel to
> > > power things on and drive all AUX transactions. ...but clearly my
> > > model isn't reality. We certainly do AUX transactions from the DP
> > > driver
When doing DP AUX transfers there are two actors that need to be
powered in order for the DP AUX transfer to work: the DP source and
the DP sync. Commit bacbab58f09d ("drm: Mention the power state
requirement on side-channel operations") added some documentation
saying that the DP source is
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
There no more need for the dpu_plane_pipe() function, crtc code can
access pstate->pipe_hw.idx directly.
Signed-off-by: Dmitry Baryshkov
Perhaps this can be squashed with the previous change.
Otherwise,
Reviewed-by: Abhinav Kumar
---
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
There is no need to keep a separate function for calling into the ctl if
we already know all the details. Inline this function in the dpu_crtc.c
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
Hi,
On Mon, Apr 18, 2022 at 4:10 PM Doug Anderson wrote:
>
> So I guess where does that leave us? Maybe:
>
> 1. I'll add a WARN_ON() in of_dp_aux_populate_ep_devices() if there is
> more than one DP AUX endpoint with a comment explaining why we assume
> one DP AUX endpoint.
>
> 2. I'll create
While it works, for the most part, to assume that the panel has
finished probing when devm_of_dp_aux_populate_ep_devices() returns,
it's a bit fragile. This is talked about at length in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev").
When reviewing
As talked about in this patch in the kerneldoc of
of_dp_aux_populate_ep_device() and also in the past in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev"), it can be difficult for eDP controller drivers to
know when the panel has finished probing when
This patch is v2 of the first 2 patches from my RFC series ("drm/dp:
Improvements
for DP AUX channel") [1]. I've broken the series in two so we can make
progress on the two halves separately.
v2 of this series tries to incorporate all the feedback from v1. Hopefully
things are less confusing and
On 5/3/2022 3:11 PM, Dmitry Baryshkov wrote:
On 04/05/2022 00:34, Abhinav Kumar wrote:
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.
Change is fine by itself, but is it
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_pipe instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rather
than part of a plane (allocated during
On 04/05/2022 00:34, Abhinav Kumar wrote:
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.
Change is fine by itself, but is it really needed?
Wouldnt it be better to keep
Actually, there is another place we have to put this, we can spam
"SCHED_ERROR" things which are triggered within multiple
drivers/gpu/drm/nouveau/nvkm/engine/fifo/ files.
On Tue, May 3, 2022 at 9:23 PM Karol Herbst wrote:
>
> not able to hit any error on my machine, but regardless:
>
>
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
As SSPP blocks are now visible through dpu_kms->rm.sspp_blocks, move
SSPP debugfs creation from dpu_plane to dpu_kms.
Change is fine by itself, but is it really needed?
Wouldnt it be better to keep dpu_debugfs_sspp_init in dpu_plane.c?
On 5/3/2022 1:43 PM, Dmitry Baryshkov wrote:
Correct a typo in the address of the second DSI PHY in the SDM660 device
config.
Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660")
Cc: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
Typo indeed. 0xc996400 is the
On Tue, May 03, 2022 at 10:19:34PM +0200, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor function must
Correct a typo in the address of the second DSI PHY in the SDM660 device
config.
Fixes: 694dd304cc29 ("drm/msm/dsi: Add phy configuration for SDM630/636/660")
Cc: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 +-
1 file changed, 1
Hello Sam,
On 5/3/22 19:14, Sam Ravnborg wrote:
> Hi Javier,
>
[snip]
>>
>> int fb_deferred_io_fsync(struct file *file, loff_t start, loff_t end, int
>> datasync)
>> {
>> -struct fb_info *info = file->private_data;
>> +struct fb_info *info = fb_file_fb_info(file->private_data);
>
A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does sanity checking to make sure that the fb_info is valid.
not able to hit any error on my machine, but regardless:
Reviewed-by: Karol Herbst
I suspect there are more places where we could put it, but we can add
those later.
Anyway, I think it's valuable to push it through fixes, not sure how
far back we want to CC stable though.
On Fri, Apr 29, 2022
internal buffers should be shmem backed.
if a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
refactor internal buffer backend to allocate volatile pages via
ttm pool allocator
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 264 ---
drivers/gpu/drm/i915/gem/i915_gem_internal.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 12
reorder scratch page allocation so that memory regions are available
to allocate the buffers
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 20 ++--
drivers/gpu/drm/i915/gt/intel_gt_gmch.h | 6 ++
drivers/gpu/drm/i915/i915_driver.c | 16
Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 43 ++--
1 file changed, 40
This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.
Robert Beckett (4):
drm/i915: add gen6 ppgtt
On Tue, 3 May 2022 at 23:03, Alex Deucher wrote:
>
> On Tue, May 3, 2022 at 2:36 AM Christian König
> wrote:
> >
> > That hunk somehow got missing while solving the conflict between the TTM
> > and AMDGPU changes for drm-next.
> >
> > Signed-off-by: Christian König
>
> Acked-by: Alex Deucher
>
On 03.05.2022 11:27:38, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems when 'items' list is
> specified. This time it is in if/then schemas as the meta-schema was
> failing to check this case.
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with
On Thu, Apr 28, 2022 at 09:37:50PM +0800, Rex-BC Chen wrote:
> From: Xinlei Lee
>
> Convert mediatek,dsi.txt to mediatek,dsi.yaml format
>
> Signed-off-by: Xinlei Lee
> Signed-off-by: Rex-BC Chen
> ---
> .../display/mediatek/mediatek,dsi.txt | 62 -
>
Hi Javier,
On Tue, May 03, 2022 at 06:46:16PM +0200, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor
Dne torek, 03. maj 2022 ob 09:15:39 CEST je Javier Martinez Canillas
napisal(a):
> By default the bits per pixel for the emulated framebuffer device is set
> to dev->mode_config.preferred_depth, but some devices need another value.
>
> Since this second parameter is only used by a few drivers,
A reference to the framebuffer device struct fb_info is stored in the file
private data, but this reference could no longer be valid and must not be
accessed directly. Instead, the file_fb_info() accessor function must be
used since it does sanity checking to make sure that the fb_info is valid.
On Tue, May 03, 2022 at 11:27:38AM -0500, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems when 'items' list is
> specified. This time it is in if/then schemas as the meta-schema was
> failing to check this case.
Acked-by: Mark Brown
signature.asc
Description: PGP
Another round of removing redundant minItems/maxItems when 'items' list is
specified. This time it is in if/then schemas as the meta-schema was
failing to check this case.
If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
same size as the list is redundant and can be
Event thread supposed to exit from its while loop after kthread_stop().
However there may has possibility that event thread is pending in the
middle of wait_event due to condition checking never become true.
To make sure event thread exit its loop after kthread_stop(), this
patch OR
On 5/2/2022 6:13 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-05-02 16:04:28)
Event thread supposed to exit from its while loop after kthread_stop().
However there may has possibility that event thread is pending in the
middle of wait_event due to condition checking never become true.
On 5/2/22 15:50, Javier Martinez Canillas wrote:
> A reference to the framebuffer device struct fb_info is stored in the file
> private data, but this reference could no longer be valid and must not be
> accessed directly. Instead, the file_fb_info() accessor function must be
> used since it does
On Tue, May 03, 2022 at 07:50:16AM -0700, Saurabh Singh Sengar wrote:
> On Tue, Apr 12, 2022 at 05:06:07AM +, Dexuan Cui wrote:
> > > From: Saurabh Sengar
> > > Sent: Monday, April 11, 2022 9:29 PM
> > > ...
> > > Add error message when the size of requested framebuffer is more than
> > >
On 03/05/2022 15:56, Matt Roper wrote:
On Tue, May 03, 2022 at 09:21:04AM +0100, Tvrtko Ursulin wrote:
On 02/05/2022 17:34, Matt Roper wrote:
Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
compute-focused platform, PVC has compute engines and enhanced copy
engines,
On Tue, May 03, 2022 at 09:21:04AM +0100, Tvrtko Ursulin wrote:
>
> On 02/05/2022 17:34, Matt Roper wrote:
> > Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
> > compute-focused platform, PVC has compute engines and enhanced copy
> > engines, but no render engine (there
On Tue, Apr 12, 2022 at 05:06:07AM +, Dexuan Cui wrote:
> > From: Saurabh Sengar
> > Sent: Monday, April 11, 2022 9:29 PM
> > ...
> > Add error message when the size of requested framebuffer is more than
> > the allocated size by vmbus mmio region for framebuffer
>
> The line lacks a
From: Kefeng Wang
Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR().
Signed-off-by: Kefeng Wang
Reviewed-by: Jani Nikula
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
On 28/04/2022 12:11, Tvrtko Ursulin wrote:
On 28/04/2022 11:25, Matthew Auld wrote:
On 28/04/2022 09:55, Tvrtko Ursulin wrote:
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed
On 03/05/2022 17:27, Matthew Auld wrote:
On 03/05/2022 11:39, Lionel Landwerlin wrote:
On 03/05/2022 13:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi
On Tue, May 3, 2022 at 4:04 PM Guenter Roeck wrote:
> On 5/3/22 00:17, Arnd Bergmann wrote:
>
> > If you have a z2 specific config, that would probably not enable CONFIG_OF,
> > which is always turned on for multiplatform, but again that only adds around
> > 250KB in my builds (using gcc-11).
On 03/05/2022 11:39, Lionel Landwerlin wrote:
On 03/05/2022 13:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
-
On 2022-05-03 14:30, Dmitry Baryshkov wrote:
On Tue, 3 May 2022 at 13:57, Robin Murphy wrote:
On 2022-05-01 11:10, Dmitry Baryshkov wrote:
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained
On Tue, May 3, 2022 at 5:12 AM Lucas Stach wrote:
>
> Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Running the GPU without an IOMMU is not really a supported (or sane)
> > configuration. Yet it can be useful during SoC bringup (ie. if the
> > iommu
On 5/3/22 00:17, Arnd Bergmann wrote:
On Tue, May 3, 2022 at 4:55 AM Guenter Roeck wrote:
On 5/2/22 14:03, Arnd Bergmann wrote:
On Mon, May 2, 2022 at 10:35 PM Guenter Roeck wrote:
On 5/2/22 12:21, Arnd Bergmann wrote:
qemu puts initrd in the middle of available memory. With the image
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20220503]
[cannot apply to anholt/for-next v5.18-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note
On 5/3/22 14:03, Robert Foss wrote:
On Tue, 3 May 2022 at 02:31, Rob Herring wrote:
On Tue, Apr 26, 2022 at 09:36:44PM +0200, Marek Vasut wrote:
The i.MX8MP contains two syscon registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
which represents
On Tue, 3 May 2022 at 13:57, Robin Murphy wrote:
>
> On 2022-05-01 11:10, Dmitry Baryshkov wrote:
> > Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
> > This allows us to drop final bits of struct mdp5_cfg_platform which
> > remained from the pre-DT days.
> >
> >
On Tue, May 3, 2022 at 2:36 AM Christian König
wrote:
>
> That hunk somehow got missing while solving the conflict between the TTM
> and AMDGPU changes for drm-next.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 6 +-
> 1
Dear Daniel,
Am 03.05.22 um 14:25 schrieb Daniel Stone:
On Sun, 1 May 2022 at 08:08, Paul Menzel wrote:
Am 26.04.22 um 15:53 schrieb Gong, Richard:
I think so. We captured dmesg log.
Then the (whole) system did *not* freeze, if you could still log in
(maybe over network) and execute
On Sun, 1 May 2022 at 08:08, Paul Menzel wrote:
> Am 26.04.22 um 15:53 schrieb Gong, Richard:
> > I think so. We captured dmesg log.
>
> Then the (whole) system did *not* freeze, if you could still log in
> (maybe over network) and execute `dmesg`. Please also paste the
> amdgpu(?) error logs in
Il 03/05/22 12:23, Nancy.Lin ha scritto:
Add mtk_mmsys_write_reg API. Simplify code for writing mmsys reg.
It is a preparation for adding support for mmsys config API.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mmsys.c | 35 ++--
1 file changed, 15
Il 03/05/22 12:23, Nancy.Lin ha scritto:
Add mmsys for support 64 reset bits. It is a preparation for MT8195
vdosys1 HW reset. MT8195 vdosys1 has more than 32 reset bits.
1. Add the number of reset bits in mmsys private data
2. move the whole "reset register code section" behind the
"get
Il 03/05/22 12:23, Nancy.Lin ha scritto:
Add new mmsys component: ethdr_mixer and mdp_rdma. These components will
use in mt8195 vdosys1.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Il 03/05/22 12:23, Nancy.Lin ha scritto:
Add mtk-mutex DDP_COMPONENT_DP_INTF1 component. The MT8195 vdosys1 path
component contains ovl_adaptor, merge5, and dp_intf1. It is a preparation
for adding support for MT8195 vdosys1 path component.
Signed-off-by: Nancy.Lin
Reviewed-by:
On 2022-05-03 12:02, Heiko Stübner wrote:
Am Freitag, 22. April 2022, 09:28:28 CEST schrieb Sascha Hauer:
From: Douglas Anderson
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't
The BCM2711 has a separate driver for the v3d, and thus we can't call
into any of the driver entrypoints that rely on the v3d being there.
Let's add a bunch of checks and complain loudly if that ever happen.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 49
When doing an asynchronous page flip (PAGE_FLIP ioctl with the
DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
possible GPU buffer being rendered through a call to
vc4_queue_seqno_cb().
On the BCM2835-37, the GPU driver is part of the vc4 driver and that
function is defined in
The BCM2711 doesn't have a v3d GPU so we don't want to call into its BO
management code. Let's create an asynchronous page-flip handler for the
BCM2711 that just calls into the common code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 21 ++---
1 file
The function vc4_async_page_flip() handles asynchronous page-flips in
the vc4 driver.
However, it mixes some generic code with code that should only be run on
older generations that have the GPU handled by the vc4 driver.
Let's split the generic part out of vc4_async_page_flip() and into a
We'll soon introduce another completion callback source that won't need
to use the BO reference counting, so let's move it around to create a
function we will be able to share between both callbacks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 34
We'll need to extend the vc4_async_flip_state structure to rely on
another callback implementation, so let's move the current one into a
union.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git
On the BCM2711, we currently call the vc4_bo_cache_init() and
vc4_gem_init() functions. These functions initialize the BO and GEM
backends.
However, this code was initially created to accomodate the requirements
of the GPU on the older SoCs, while the BCM2711 has a separate driver
for it. So
On the BCM2711, our current definition of drm_plane_helper_funcs uses
the custom vc4_prepare_fb() and vc4_cleanup_fb().
Those functions rely on the buffer allocation path that was relying on
the GPU, and is no longer relevant.
Let's create another drm_plane_helper_funcs structure that we will
On the BCM2711, our current definition of drm_mode_config_funcs uses the
custom vc4_fb_create().
However, that function relies on the buffer allocation path that was
relying on the GPU, and is no longer relevant.
Let's create another drm_mode_config_funcs structure that we will
register on the
Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display
components of the SoC. It was thus a part of the vc4 driver.
However, with the BCM2711, it got split out and thus the v3d driver was
created. The vc4 driver now only handles the display part.
We didn't properly split out the
The vc4_bo_dumb_create() both fixes up the allocation arguments to match
the hardware constraints and actually performs the allocation.
Since we're going to introduce a new function that uses a different
allocator, let's split the arguments fixup to a separate function we
will be able to reuse.
We're going to add a new variant of the dumb BO allocation function, so
let's rename vc4_dumb_create() to something a bit more specific.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_bo.c | 6 +++---
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.h | 6 +++---
3
A new generation of controller has been introduced with the
BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over
time we've piled on a number of checks in most parts of the drivers.
All these checks are performed several times, and are not always
consistent. Let's create a
The vc4 planes are setup in hardware by creating a hardware descriptor
in a dedicated RAM. As part of the process to setup a plane in KMS, we
thus need to allocate some part of that dedicated RAM to store our
descriptor there.
The async update path will just reuse the descriptor already allocated
Hi,
Here's a series that fixes a significant issue we missed when adding support
for the BCM2711 / RaspberryPi4 in the vc4 driver.
Indeed, before the introduction of the BCM2711 support, the GPU was fairly
intertwined with the display hardware, and was thus supported by the vc4
driver. Among
Am Montag, dem 02.05.2022 um 10:29 -0700 schrieb Rob Clark:
> From: Rob Clark
>
> Running the GPU without an IOMMU is not really a supported (or sane)
> configuration. Yet it can be useful during SoC bringup (ie. if the
> iommu driver doesn't work yet).
>
> Lets limit it to users who already
On Tue, 3 May 2022 at 02:31, Rob Herring wrote:
>
> On Tue, Apr 26, 2022 at 09:36:44PM +0200, Marek Vasut wrote:
> > The i.MX8MP contains two syscon registers which are responsible
> > for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding
> > which represents this serializer as a
On Mon, May 02, 2022 at 09:36:27AM -0700, Michael Kelley wrote:
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more
On 03/05/2022 11:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks.
On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
>
> This series
Am Freitag, 22. April 2022, 09:28:28 CEST schrieb Sascha Hauer:
> From: Douglas Anderson
>
> The previous tables for mpll_cfg and curr_ctrl were created using the
> 20-pages of example settings provided by the PHY vendor. Those
> example settings weren't particularly dense, so there were places
On 2022-05-01 11:10, Dmitry Baryshkov wrote:
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.
Signed-off-by: Dmitry Baryshkov
---
On 03/05/2022 13:22, Matthew Auld wrote:
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks.
On 02/05/2022 09:53, Lionel Landwerlin wrote:
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture
On 20/04/2022 10:57, Karol Herbst wrote:
i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.
Instead the lock needs to be taken before actually checking.
v2: move struct declaration
Fix looks correct to me. In
On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
>
> This series
On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
>
> This series
On 03/05/2022 12:07, Matthew Auld wrote:
On 02/05/2022 19:03, Lionel Landwerlin wrote:
On 02/05/2022 20:58, Abodunrin, Akeem G wrote:
-Original Message-
From: Landwerlin, Lionel G
Sent: Monday, May 2, 2022 12:55 AM
To: Auld, Matthew ;
intel-...@lists.freedesktop.org
Cc:
On Fri, 22 Apr 2022 09:28:17 +0200, Sascha Hauer wrote:
> It's v11 time. There's only one small change to v10. Discussion seems to
> have settled now. Is there anything left that prevents the series from
> being merged? I'd really like to have it in during the next merge
> window.
>
> This series
On 02/05/2022 19:03, Lionel Landwerlin wrote:
On 02/05/2022 20:58, Abodunrin, Akeem G wrote:
-Original Message-
From: Landwerlin, Lionel G
Sent: Monday, May 2, 2022 12:55 AM
To: Auld, Matthew ;
intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Thomas Hellström
;
On 02/05/2022 08:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
On 02/05/2022 17:34, Matt Roper wrote:
From: John Harrison
PVC adds extra blitter engines (in the following patch). The reset
selftest has a local array on the stack which is sized by the number
of engines. The increase pushes the size of this array to the point
where it trips the 'stack too
On 5/3/2022 8:15 AM, Lucas De Marchi wrote:
Commit e4e806253003 ("drm/i915: Change shrink ordering to use locking
around unbinding.") changed the return type to int without changing the
return values or their meaning to "0 is success". Move it back to
boolean.
Signed-off-by: Lucas De Marchi
On 02/05/2022 17:34, Matt Roper wrote:
Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a
compute-focused platform, PVC has compute engines and enhanced copy
engines, but no render engine (there is no geometry pipeline) and no
display.
This is just a handful of early
1 - 100 of 116 matches
Mail list logo
