Lyude Paul writes:
> Alright, dim's pushing it now. sorry about that!
Thanks, I see it in linux-next now.
cheers
> On Wed, 2022-06-08 at 16:48 -0400, Lyude Paul wrote:
>> Whoops, it totally may have. Thank you for the reminder, I will double check
>> and make sure this gets pushed today
>>
>>
Am 16.06.22 um 22:35 schrieb Alex Deucher:
Fixes:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9143:27: warning:
variable 'abo' set but not used [-Wunused-but-set-variable]
Fixes: 047de3f17a83 ("drm/amdgpu: switch DM to atomic fence helpers v2")
Signed-off-by: Alex Deucher
Rev
The pinned PFN list returned from vfio_pin_pages() is simply converted
using page_to_pfn() without protection, so direct access via memcpy()
will crash on S390 if the PFN is an IO PFN. Instead, the pages should
be touched using kmap_local_page().
Add kmap_local_page() before doing memcpy on "from"
This is a preparatory series for IOMMUFD v2 patches. It prepares for
replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
with IOMMUFD version.
There's a gap between these two versions: the vfio_iommu_type1 version
inputs a non-contiguous PFN list and outputs another PFN list for t
The ap_aqic() is called by vfio_ap_irq_enable() where it passes in a
virt value that's casted from a physical address "h_nib". Inside the
ap_aqic(), it does virt_to_phys() again.
Since ap_aqic() needs a physical address, let's just pass in a pa of
ind directly. So change the "ind" to "pa_ind".
Si
This driver is the only caller of vfio_pin/unpin_pages that might pass
in a non-contiguous PFN list, but in many cases it has a contiguous PFN
list to process. So letting VFIO API handle a non-contiguous PFN list
is actually counterproductive.
Add a pair of simple loops to pass in contiguous PFNs
The vfio_pin/unpin_pages() so far accepted arrays of PFNs of user IOVA.
Among all three callers, there was only one caller possibly passing in
a non-contiguous PFN list, which is now ensured to have contiguous PFN
inputs too.
Pass in the starting address with "iova" alone to simplify things, so
ca
Following the updated vfio_pin/unpin_pages(), use the simpler "iova".
Signed-off-by: Nicolin Chen
---
drivers/vfio/vfio.c | 6 +++---
include/linux/vfio.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 861594dd461a..e8dbb01
Reviewed-by: Vinay Simha BN
On Thu, Jun 16, 2022 at 3:55 AM Jiri Vanek wrote:
> Use the same PCLK divide option (divide DSI clock to generate pixel clock)
> which is set to LVDS Configuration Register (LVCFG) also for a VSync delay
> calculation. Without this change an auxiliary variable could
Reviewed-by: Vinay Simha BN
On Thu, Jun 16, 2022 at 3:55 AM Jiri Vanek wrote:
> Function for reading from i2c device register displays error message even
> if reading ends correctly. Add return to avoid falling through into
> the fail label.
>
> Signed-off-by: Jiri Vanek
> ---
> drivers/gpu/d
Most of the callers of vfio_pin_pages() want "struct page *" and the
low-level mm code to pin pages returns a list of "struct page *" too.
So there's no gain in converting "struct page *" to PFN in between.
Replace the output parameter phys_pfn list with a phys_page list, to
simplify callers. This
Hi Dave and Daniel,
here's the PR for drm-misc-next. AFAICT it contains mostly fixes and
cleanups. There's is one new driver for the LogiCVC display controller.
Best regards
Thomas
drm-misc-next-2022-06-17:
drm-misc-next for v5.20:
UAPI Changes:
Cross-subsystem Changes:
* dma-buf: Add sync-f
On Thu, Jun 16, 2022 at 03:32:56PM +0100, Charles Keepax wrote:
> Change the legacy DAI naming flag from opting in to the new scheme
> (non_legacy_dai_naming), to opting out of it (legacy_dai_naming).
> This driver appears to be on the CPU side of the DAI link and
> currently uses the legacy naming
The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver
(ver 1.21a),
with a custom glue managing the IP resets, clock and data input similar to the
DW-HDMI
glue on the same Amlogic SoCs.
This adds support for the glue managing the transceiver, mimicing the init flow
provided
The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver
(ver 1.21a),
with a custom glue managing the IP resets, clock and data input similar to the
DW-HDMI Glue
on the same Amlogic SoCs.
Signed-off-by: Neil Armstrong
Reviewed-by: Rob Herring
---
.../display/amlogic,meson-d
Add third port corresponding to the ENCL DPI encoder used to connect
to DSI or LVDS transceivers.
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/amlogic,meson-vpu.yaml | 5 +
1 file changed, 5 insertions(+)
The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver
1.21a),
with a custom glue managing the IP resets, clock and data input similar to the
DW-HDMI
Glue on other Amlogic SoCs.
This adds support for the Glue managing the transceiver, mimicing the init flow
provided
by Am
The DSI path used the ENCL pixel encoder, thus this adds a clock
config using the HDMI PLL in order to feed the ENCL encoder via the
VCLK2 path and the CTS_ENCL clock output.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_vclk.c | 47 ++
drivers/gpu/drm
This adds an encoder bridge designed to drive a MIPI-DSI display
by using the ENCL encoder through the internal MIPI DSI transceiver
connected to the output of the ENCL pixel encoder.
Signed-off-by: Neil Armstrong
Reviewed-by: Jagan Teki
---
drivers/gpu/drm/meson/Makefile| 2 +-
d
This adds supports for the ENCL encoder connected to a MIPI-DSI transceiver on
the
Amlogic AXG, G12A, G12B & SM1 SoCs.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_registers.h | 25 +++
drivers/gpu/drm/meson/meson_venc.c | 211 +++-
drivers/gpu/drm/mes
On 17.06.22 04:19, Andrew Morton wrote:
> On Tue, 31 May 2022 15:00:28 -0500 Alex Sierra wrote:
>
>> This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
>> for current 5.18.0
>
> I plan to move this series into the non-rebasing mm-stable branch in a
> few days. Unless sternly to
Add Ampire AM-800600P5TMQW-TB8H 8" TFT LCD panel compatible string.
Signed-off-by: Bastian Krause
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Documen
Add support for the Ampire AM-800600P5TMQW-TB8H 800x600 panel. Data
sheet is currently not publicly available, unfortunately.
Signed-off-by: Bastian Krause
---
drivers/gpu/drm/panel/panel-simple.c | 33
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/p
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by using
Like was done for read, provide the equivalent for write. Even if
current users are not in the hot path, this should future-proof it.
v2:
- Remove default from _Generic() - callers wanting to write more
than u64 should use iosys_map_memcpy_to()
- Add WRITE_ONCE() cases dereferencing the po
Add a warning that this UAPI wasn't such a good idea and shouldn't be
used by anybody.
That should give us a better chance to remove it at some point and
prevents others from running into the same issues.
Signed-off-by: Christian König
---
drivers/dma-buf/Kconfig | 6 +-
1 file changed, 5 i
Hi Randy,
Thanks for your helpful comments!
We will refine them in the next patch, thanks!
Randy Dunlap 於 2022年6月14日 週二 凌晨4:15寫道：
>
>
>
> On 6/13/22 04:11, ChiaEn Wu wrote:
> > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> > index cbe0f96ca342..dcb6866dab53 100644
> > ---
Hi Randy,
Thanks for your comment!
I apologize for any inconvenience caused when you decoded this help text.
I will refine this in the next patch, thanks!
Randy Dunlap 於 2022年6月14日 週二 凌晨4:17寫道：
>
> Hi,
>
> On 6/13/22 04:11, ChiaEn Wu wrote:
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/
Hi
Am 15.06.22 um 17:00 schrieb Nuno Gonçalves:
I am crashing the kernel by doing something I believe I am allowed to do.
Using mmap to write to /dev/fb0 as the compatibility layer for Tiny
DRM vot,v220hf01a-t (ili9225).
First it happens that because of the display resolution of 220*176 the
bu
Use ida_alloc_xxx()/ida_free() instead of
ida_simple_get()/ida_simple_remove().
The latter is deprecated and more verbose.
Signed-off-by: Bo Liu
---
drivers/gpu/drm/drm_connector.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b
Hi Daniel,
Thanks for your helpful feedback!
Daniel Thompson 於 2022年6月14日 週二 凌晨1:08寫道：
>
> On Mon, Jun 13, 2022 at 07:11:46PM +0800, ChiaEn Wu wrote:
> > +static int mt6370_init_backlight_properties(struct mt6370_priv *priv,
> > + struct backlight_properti
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, June 16, 2022 8:02 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Wilson, Chris P ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/rpm: Enable D3Cold VR
On 31.05.22 22:00, Alex Sierra wrote:
> 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 me
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, June 16, 2022 6:26 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Roper, Matthew D ; Nilawar, Badal
> ; Ewins, Jon ; Vivi, Rodrigo
> ; Ursulin, Tvrtko ; Tangudu,
> Tilak ;
On 31.05.22 22:00, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration
Hi,
On Thu, Jun 16, 2022 at 07:23:14PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
Hi,
On Thu, Jun 16, 2022 at 07:23:15PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from
On 05/04/2022 11:59, Thomas Hellström wrote:
When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However start
Hi Krzysztof,
Thanks for your helpful comments! I have so some questions want to ask
you below.
Krzysztof Kozlowski 於 2022年6月17日 週五 清晨5:05寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiaEn Wu
> >
> > Add Mediatek MT6370 Charger binding documentation.
> >
> > Signed-off-by: ChiaEn Wu
On 16/06/2022 23:49, Lucas De Marchi wrote:
Exporting the symbols like intel_gtt_* creates some confusion inside
i915 that has symbols named similarly. In an attempt to isolate
platforms needing intel-gtt.ko, commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch") moved way too m
On 30/05/2022 22:14, Fabien Parent wrote:
Add MT8365 binding documentation for all the display components that are
compatible with the compatible string from other SoCs.
Signed-off-by: Fabien Parent
Reviewed-by: Matthias Brugger
---
.../bindings/display/mediatek/mediatek,aal.yaml | 1
On 17/06/2022 07:50, CK Hu wrote:
Hi, Fabien:
On Mon, 2022-05-30 at 22:14 +0200, Fabien Parent wrote:
Add mutex support for MT8365 SoC.
Reviewed-by: CK Hu
Applied thanks!
Signed-off-by: Fabien Parent
---
drivers/soc/mediatek/mtk-mutex.c | 40
1 f
On 17/06/2022 07:53, CK Hu wrote:
Hi, Fabien:
On Mon, 2022-05-30 at 22:14 +0200, Fabien Parent wrote:
Right now only the DSI path connections are described in the mt8365
mmsys driver. The external path will be DPI/HDMI. This commit adds
the connections for DPI/HDMI.
Reviewed-by: CK Hu
Hi,
On Mon, May 23, 2022 at 4:37 PM Robert Foss wrote:
>
> On Mon, 23 May 2022 at 09:18, Chen-Yu Tsai wrote:
> >
> > On Mon, May 23, 2022 at 11:13 AM Xin Ji wrote:
> > >
> > > On Sat, May 21, 2022 at 06:28:42PM +0200, Daniel Vetter wrote:
> > > > On Sat, 21 May 2022 at 18:07, Daniel Vetter wro
Provide drm_atomic_helper_check_crtc_state() for validating a CRTC
state against common constraints. As many CRTC need a primary plane
to work correctly, add this as the first test.
The simple-KMS helpers already contain related code. Convert it
to the new helper. Also add this test to ast.
The s
As the CRTC requires a primary plane for display, ensure that the
primary plane is enabled with the CRTC.
Use drm_atomic_helper_check_crtc_state(). Add all affected planes
to the atomic state so that their state will be checked as well.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/a
Simple-KMS helpers guarantee that the CRTC and plane enable
flags are synchronized. Implement this with atomic helpers
drm_atomic_helper_check_crtc_state() on the CRTC side, and
drm_atomic_helper_check_plane_state() on the plane side.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_simp
Add drm_atomic_helper_check_crtc_state(), which contains tests common
to many CRTCs. The first added test verifies that an enabled CRTC has
at least one enabled primary plane.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_atomic_helper.c | 55 +
include/drm
On 16/06/2022 23:49, Lucas De Marchi wrote:
Re-do what was attempted in commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch"). The goal of that commit was to split the
handlers for older hardware that depend on intel-gtt.ko so i915 can
be built for non-x86 archs, after some mor
Hi Krzysztof,
Thanks for your helpful feedback, I have some questions want to
confirm with you below.
Krzysztof Kozlowski 於 2022年6月17日 週五 清晨5:13寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiYuan Huang
> >
> > Add mt6370 backlight binding documentation.
> >
> > Signed-off-by: ChiYua
On MSM8996 the HDMI PHY is the QMP PHY, it provides an HDMI PLL clock
used by the MMCC. Add support for providing this clock to the OF
framework by registerding the clock provider and adding #clock-cells
property to the DT node.
Dmitry Baryshkov (3):
dt-bindings: phy: qcom,hdmi-phy-qmp: add cloc
As the QMP HDMI PHY is a clock provider, add constant #clock-cells
property. For the compatibility with older DTs the property is not
marked as required.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml | 4
1 file changed, 4 insertions(+)
di
On MSM8996 the HDMI PHY provides the PLL clock to the MMCC. As we are
preparing to convert the MSM8996 to use DT clocks properties (rather
than global clock names), register the OF clock provider.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 15 ++-
Add #clock-cells property to the HDMI PHY device node to let other nodes
resolve the hdmipll clock.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/ms
Hi Rob,
Rob Herring 於 2022年6月13日 週一 晚上9:33寫道：
>
> On Mon, 13 Jun 2022 19:11:37 +0800, ChiaEn Wu wrote:
> > From: ChiYuan Huang
> >
> > Add Mediatek MT6370 binding documentation.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > .../bindings/mfd/mediatek,mt6370.yaml | 279 +++
Hi Krzysztof,
Krzysztof Kozlowski 於 2022年6月17日 週五 清晨5:15寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiYuan Huang
> >
> > Add Mediatek MT6370 binding documentation.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > .../bindings/mfd/mediatek,mt6370.yaml | 279
Hi John,
well, this warning is intentional.
The key point is that your random config results in a very suboptimal
situation where the graphics driver only barely work.
And radeon is pointing that out with this warning. That is totally
expected behavior.
Regards,
Christian.
Am 17.06.22 um
Hi John,
Am 17.06.22 um 13:52 schrieb John Garry:
Hi Christian,
well, this warning is intentional.
The key point is that your random config results in a very suboptimal
situation where the graphics driver only barely work.
ok
And radeon is pointing that out with this warning. That is t
Always run fbdev removal first to remove simpledrm via
sysfb_disable(). This clears the internal state. The later call
to drm_aperture_detach_drivers() then does nothing. Otherwise,
with drm_aperture_detach_drivers() running first, the call to
sysfb_disable() uses inconsistent state.
Example backt
[adding Zack and Alex to Cc list]
Hello Thomas,
Thanks a lot for tracking this down and figuring out the root cause!
On 6/17/22 14:10, Thomas Zimmermann wrote:
> Always run fbdev removal first to remove simpledrm via
> sysfb_disable(). This clears the internal state. The later call
> to drm_aper
On 5/25/22 20:43, Matthew Auld wrote:
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverab
Hi
Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:
[adding Zack and Alex to Cc list]
Hello Thomas,
Thanks a lot for tracking this down and figuring out the root cause!
On 6/17/22 14:10, Thomas Zimmermann wrote:
Always run fbdev removal first to remove simpledrm via
sysfb_disable(). Th
On Fri, 2022-06-17 at 14:41 +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:
> > [adding Zack and Alex to Cc list]
> >
> > Hello Thomas,
> >
> > Thanks a lot for tracking this down and figuring out the root cause!
> >
> > On 6/17/22 14:10, Thomas Z
Hi John,
Am 17.06.22 um 14:01 schrieb John Garry:
On 17/06/2022 12:57, Christian König wrote:
And/Or compile out the warning when "warnings = errors"?
That should be doable I think.
ok, if something can be done then I would appreciate it. I do much
randconfig builds as part of my upstream
On Wed, Jun 15, 2022 at 9:00 AM Christian König
wrote:
>
> Am 06.06.22 um 13:00 schrieb Bas Nieuwenhuizen:
> > On Mon, Jun 6, 2022 at 12:35 PM Christian König
> > wrote:
> >> [SNIP]
> >> That part won't work at all and would cause additional synchronization
> >> problems.
> >>
> >> First of all f
Am 17.06.22 um 15:03 schrieb Bas Nieuwenhuizen:
[SNIP]
BOOKKEEP can only be used by VM updates themselves. So that they don't
interfere with CS.
That is the point why we would go BOOKKEEP for explicit sync CS
submissions, no? Explicit submission shouldn't interfere with any
other CS submissions
trees.
I had a look on Linux next (next-20220617) and wasn't able to find the mtk_dsi.c
changes. What is the status of this?
Regards,
Matthias
Thanks.
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/
On Fri, 17 Jun 2022 14:41:01 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:
> > [adding Zack and Alex to Cc list]
> >
> > Hello Thomas,
> >
> > Thanks a lot for tracking this down and figuring out the root cause!
> >
> > On 6/17/22 14:10, Thomas
nd
> > in drm-misc. With this series applied, we can add this patch to give
> > the correct default orientation for mt8183 kukui devices.
> > I didn't send this patch again with the series, since they might land
> > in different trees.
> >
>
> I had a look o
On 5/25/22 20:43, Matthew Auld wrote:
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc:
On 5/25/22 20:43, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill
On Fri, Jun 17, 2022 at 06:57:20AM -0700, Harish Chegondi wrote:
> On Tue, Jun 14, 2022 at 05:10:19PM -0700, Matt Roper wrote:
> > Let's replace the assortment of intel_gt_* and intel_uncore_* functions
> > that operate on MCR registers with a cleaner set of interfaces:
> >
> > * intel_gt_mcr_re
On 5/25/22 20:43, Matthew Auld wrote:
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/intel_memory_regi
On 5/25/22 20:43, Matthew Auld wrote:
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jorda
Hi,
On Thu, Jun 16, 2022 at 05:31:05PM +0530, Anshuman Gupta wrote:
> From: Tvrtko Ursulin
>
> Store a pointer to respective local memory region in intel_gt so it can be
> used when memory local to a GT needs to be allocated.
>
> Cc: Andi Shyti
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by:
When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However starting with gen10, Write-combined
writing of scrat
On Fri, Jun 17, 2022 at 01:52:03AM -0700, Lucas De Marchi wrote:
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them po
Hi Lee,
Thanks for your helpful comments, we have some questions and replies below.
Lee Jones 於 2022年6月16日 週四 清晨6:49寫道：
>
> On Mon, 13 Jun 2022, ChiaEn Wu wrote:
>
> > From: ChiYuan Huang
> >
> > Add Mediatek MT6370 MFD support.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > drivers/mfd/Kc
On 6/17/2022 4:40 AM, David Hildenbrand wrote:
On 31.05.22 22:00, Alex Sierra wrote:
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. Howe
On 17.06.22 19:20, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 6/17/2022 4:40 AM, David Hildenbrand wrote:
>> On 31.05.22 22:00, Alex Sierra wrote:
>>> 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
tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Kuogee-Hsieh/force-link-training-for-display-resolution-change/20220617-00
b
On Tue, Jun 14, 2022 at 05:10:19PM -0700, Matt Roper wrote:
> Let's replace the assortment of intel_gt_* and intel_uncore_* functions
> that operate on MCR registers with a cleaner set of interfaces:
>
> * intel_gt_mcr_read -- unicast read from specific instance
> * intel_gt_mcr_read_any[_fw]
Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp
Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp
Handling the array of CRTC duplicate the struct msm_drm_private
duplicates a list of CRTCs in the drm_device. Drop it and use the
existing list for CRTC enumeration.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
drivers/gpu/
This patchseries replaces drm_handle_vblank() with
drm_crtc_handle_vblank(). As a bonus result of this conversion it is
possible to drop the stored array of allocated CRTCs and use the core
CRTC iterators.
Changes since v3:
- In msm_drm_init simplify the code by using an interim var for the
ev
Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp
Handling the array of CRTC duplicate the struct msm_drm_private
duplicates a list of CRTCs in the drm_device. Drop it and use the
existing list for CRTC enumeration.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
drivers/gpu/
Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp
On 16/06/2022 22:26, Abhinav Kumar wrote:
As explained in [1], using max_linewidth to limit the modes
does not seem to remove 4K modes on chipsets such as
sm8250 where the max_linewidth actually supports 4k.
This would have been alright if dual SSPP support was
present but otherwise fails the pe
This series refactors i915's stolen memory region to use ttm.
v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes
testing
dmesg warning regressions.
v3: rebase to latest drm-tip.
fix v2 code
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well after
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
Signed-of
During testing make can_mmap consider whether the region is private.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftest
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu
For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback op
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specif
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.
See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.
Signed-off-by: Robert
1 - 100 of 166 matches
Mail list logo
