On Fri, Jul 22, 2022 at 07:09:01PM -0600, Alex Williamson wrote:
> > So, I think that I should send a v4, given that the patches aren't
> > officially applied?
>
> Yep, please rebase on current vfio next branch. Thanks,
Sent. And they are on Github, basing on linux-vfio next too:
https://github
The vfio_ap_ops code maintains both nib address and its PFN, which
is redundant, merely because vfio_pin/unpin_pages API wanted pfn.
Since vfio_pin/unpin_pages() now accept "iova", change "saved_pfn"
to "saved_iova" and remove pfn in the vfio_ap_validate_nib().
Reviewed-by: Jason Gunthorpe
Review
A PFN is not secure enough to promise that the memory is not IO. And
direct access via memcpy() that only handles CPU memory will crash on
S390 if the PFN is an IO PFN, as we have to use the memcpy_to/fromio()
that uses the special S390 IO access instructions. On the other hand,
a "struct page *" i
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
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 "pages" list, to
simplify callers. This
Following the updated vfio_pin/unpin_pages(), use the simpler "iova".
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Tested-by: Terrence Xu
Tested-by: Eric Farman
Signed-off-by: Nicolin Chen
---
drivers/vfio/vfio.c | 6 +++---
include/linux/vfio.h | 2 +
The vfio_ccw_cp code maintains both iova and its PFN list because the
vfio_pin/unpin_pages API wanted pfn list. Since vfio_pin/unpin_pages()
now accept "iova", change to maintain only pa_iova list and rename all
"pfn_array" strings to "page_array", so as to simplify the code.
Reviewed-by: Jason Gu
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
There's only one caller that checks its return value with a WARN_ON_ONCE,
while all other callers don't check the return value at all. Above that,
an undo function should not fail. So, simplify the API to return void by
embedding similar WARN_ONs.
Also for users to pinpoint which condition fails,
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".
Re
It's a bit redundant for the maths here using roundup.
Suggested-by: Jason Gunthorpe
Tested-by: Terrence Xu
Signed-off-by: Nicolin Chen
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu
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
On Fri, 22 Jul 2022 17:38:25 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 06:18:00PM -0600, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, 22 Jul 2022 16:12:19 -0700
> > Nicolin Chen wrote:
> >
> > > On Fri, Jul 22, 2022 at 04:
On Fri, Jul 22, 2022 at 06:18:00PM -0600, Alex Williamson wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, 22 Jul 2022 16:12:19 -0700
> Nicolin Chen wrote:
>
> > On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
> >
> > > GVT-g explodes for me with
On Fri, 22 Jul 2022 16:12:19 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
>
> > GVT-g explodes for me with this series on my Broadwell test system,
> > continuously spewing the following:
>
> Thank you for running additional tests.
>
> > [ 47
On 7/22/22 15:35, Doug Anderson wrote:
> Hi,
>
> On Fri, Jul 22, 2022 at 12:48 AM Javier Martinez Canillas
> wrote:
>>
>> If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
>> ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
>>
>> But this path also pr
On Fri, Jul 22, 2022 at 2:23 PM Jason Baron wrote:
>
>
>
> On 7/20/22 11:32, Jim Cromie wrote:
> > DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
> > opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
> >
> >:#> echo class DRM_UT_KMS +p > /proc/dynamic
On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
> GVT-g explodes for me with this series on my Broadwell test system,
> continuously spewing the following:
Thank you for running additional tests.
> [ 47.348778] WARNING: CPU: 3 PID: 501 at
> drivers/vfio/vfio_iommu_type1.c:978
On Tue, 19 Jul 2022 21:02:47 -0300
Jason Gunthorpe wrote:
> This is the last notifier toward the drivers, replace it with a simple op
> callback in the vfio_device_ops.
>
> v4:
> - Rebase over the CCW series
> v3:
> https://lore.kernel.org/r/0-v3-7593f297c43f+56ce-vfio_unmap_notif_...@nvidia.c
On Fri, 8 Jul 2022 15:44:18 -0700
Nicolin Chen wrote:
> 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
>
drm_crtc_vblank_off increments the refcount to prevent vblank from
getting enabled during modeset, but this causes the refcount elsewhere
to be off if they call drm_vblank_get without checking the return and
do a drm_vblank_put later. This can be reproduced by toggling vrr mode
on amdgpu.
Since dr
Acquire vbl_lock before accessing vblank refcount in drm_vblank_put,
just like everywhere else that access the refcount.
Signed-off-by: Yunxiang Li
---
drivers/gpu/drm/drm_vblank.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/driv
On 2022-07-20 18:54, Melissa Wen wrote:
On 07/17, Tales Lelo da Aparecida wrote:
On 16/07/2022 19:25, Melissa Wen wrote:
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and ca
On 7/20/22 11:32, Jim Cromie wrote:
> DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
> opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
>
>:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
>
> This is just the setup; following commits de
On 7/20/22 11:32, Jim Cromie wrote:
> Add kernel_param_ops and callbacks to apply a class-map to a
> sysfs-node, which then can control classes defined in that class-map.
> This supports uses like:
>
> echo 0x3 > /sys/module/drm/parameters/debug
>
> IE add these:
>
> - int param_set_dyndbg
Add comments to document gfx_off related members of struct amdgpu_gfx.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/a
Add documentation explaining those two new files.
Signed-off-by: André Almeida
---
Documentation/gpu/amdgpu/thermal.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/gpu/amdgpu/thermal.rst
b/Documentation/gpu/amdgpu/thermal.rst
index 997231b6adcf..c31f94c6c68
Implement functions to get and set GFXOFF's entry count and residency
for vangogh.
Signed-off-by: André Almeida
---
.../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +-
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 92 +++
Add debugfs interface to log GFXOFF statistics:
- Read amdgpu_gfxoff_count to get the total GFXOFF entry count at the
time of query since system power-up
- Write 1 to amdgpu_gfxoff_residency to start logging, and 0 to stop.
Read it to get average GFXOFF residency % multiplied by 100
during
This series adds new logging features for GFXOFF available for vangogh
and documentation for it.
I've created a small userspace program to interact with this new debugfs
interface and it can be found at:
https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool
André Almeida (4):
drm/amd: Add de
The pull request you sent on Fri, 22 Jul 2022 14:15:37 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-07-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8e65afba6baaa1317efc4038cbced1268c6e2f6b
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On 7/12/2022 16:31, john.c.harri...@intel.com wrote:
From: Chris Wilson
Use a temporary page and mempy_from_wc to reduce the time it takes to
dump the guc log to debugfs.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 +
Hi Biju,
On Fri, Jul 22, 2022 at 08:19:23PM +0100, Biju Das wrote:
> The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
> can operate in DSI mode, with up to four data lanes.
>
> Signed-off-by: Biju Das
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
> Reviewe
Hi Biju,
driver looks good - you can add my:
Acked-by: Sam Ravnborg
I have one general question - that is not related to this driver, but is
directed to the bridge people on this mail.
> +static void rzg2l_mipi_dsi_atomic_enable(struct drm_bridge *bridge,
> +
Hi Krzysztof
On Fri, Jul 22, 2022 at 09:15:39PM +0200, Krzysztof Kozlowski wrote:
> The spi-cpha and spi-cpol properties are device specific and should be
> accepted only if device really needs them. Drop them from common
> spi-peripheral-props.yaml schema, mention in few panel drivers which use
On 7/19/2022 02:56, Tvrtko Ursulin wrote:
On 19/07/2022 01:13, John Harrison wrote:
On 7/18/2022 05:35, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The GuC needs a copy of a golden context for implementing watchdog
resets (aka media resets
This driver supports the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI mode only.
Signed-off-by: Biju Das
---
v3->v4:
* Updated error handling in rzg2l_mipi_dsi_startup() and
rzg2l_mipi_dsi_atomic_enable()
v2->v3:
* pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr
The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
can operate in DSI mode, with up to four data lanes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v3->v4:
* No change.
v2->v3:
* Added Rb tag from G
This patch series aims to support the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI mode only.
This unit supports MIPI Alliance Specification for Display Serial Interface
(DSI)
Specification. This unit provides a solution for transmitting MIPI DSI compliant
digital video and
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support blending of two picture layers and
raster operations (ROPs).
The DU part i
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timi
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD),
Video signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
This patch series aims to add basic display support on RZ/G2L SMARC EVK
platform. T
The spi-cpha and spi-cpol properties are device specific and should be
accepted only if device really needs them. Drop them from common
spi-peripheral-props.yaml schema, mention in few panel drivers which use
them and include instead in the SPI controller bindings. The controller
bindings will pr
Hi,
Rebased on Linus' master
Changes since v1
1. Rework patchset as Rob suggested, so there is only one patch - changing spi
and display/panel.
v1:
https://lore.kernel.org/all/20220721153155.245336-2-krzysztof.kozlow...@linaro.org/
Merging
===
I guess via DT or SPI tree.
On 7/21/2022 02:24, Tvrtko Ursulin wrote:
On 21/07/2022 01:54, John Harrison wrote:
On 7/19/2022 02:42, Tvrtko Ursulin wrote:
On 19/07/2022 01:05, John Harrison wrote:
On 7/18/2022 05:15, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
Remov
Applied. Thanks!
Alex
On Thu, Jul 21, 2022 at 3:26 AM Slark Xiao wrote:
>
> Replace 'the the' with 'the' in the comment.
>
> Signed-off-by: Slark Xiao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
> drivers/gpu/drm/amd/include/atombios.h| 4 ++--
> 2 files changed, 3 insertion
On 21/07/2022 21:30, Rob Herring wrote:
> On Thu, Jul 21, 2022 at 05:31:50PM +0200, Krzysztof Kozlowski wrote:
>> The spi-cpha and spi-cpol properties are device specific and should be
>> accepted only if device really needs them. Explicitly list them in
>> device bindings in preparation of their
On Fri, Jul 22, 2022 at 9:48 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar
> wrote:
> >
> > + sankeerth
> >
> > Hi Doug
> >
> > On 7/21/2022 3:23 PM, Douglas Anderson wrote:
> > > The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference
> > > board.
On 7/21/2022 2:08 AM, Akhil P Oommen wrote:
On 7/20/2022 11:36 PM, Rob Clark wrote:
On Tue, Jul 12, 2022 at 12:15 PM Akhil P Oommen
wrote:
On 7/12/2022 10:14 PM, Rob Clark wrote:
On Mon, Jul 11, 2022 at 10:05 PM Akhil P Oommen
wrote:
On 7/12/2022 4:52 AM, Doug Anderson wrote:
Hi,
On Fri,
Hi,
On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar wrote:
>
> + sankeerth
>
> Hi Doug
>
> On 7/21/2022 3:23 PM, Douglas Anderson wrote:
> > The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference
> > board. This panel supports 144 Hz and 60 Hz. In the EDID, the 144 Hz
> > mode is liste
+ sankeerth
Hi Doug
On 7/21/2022 3:23 PM, Douglas Anderson wrote:
The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference
board. This panel supports 144 Hz and 60 Hz. In the EDID, the 144 Hz
mode is listed first and thus is marked preferred. The EDID decode I
ran says:
First det
On Fri, Jul 22, 2022 at 08:04:51AM -0300, Maíra Canal wrote:
> On 7/22/22 07:35, Matthew Auld wrote:
> > On Fri, 8 Jul 2022 at 21:32, Maíra Canal wrote:
> >>
> >> From: Arthur Grillo
> >>
> >> Considering the current adoption of the KUnit framework, convert the
> >> DRM mm selftest to the KUnit A
Hi Jagan and Marek.
On Fri, 22 Jul 2022 at 16:35, Marek Szyprowski wrote:
>
> On 20.07.2022 17:52, Jagan Teki wrote:
> > Host transfer() in DSI master will invoke only when the DSI commands
> > are sent from DSI devices like DSI Panel or DSI bridges and this
> > host transfer wouldn't invoke for
Hi Tvrtko,
scratching my head what exactly is going on here.
I've build tested drm-tip a couple of test in the last week and it
always worked flawlessly.
It looks like that some conflict resolution is sometimes not applied
correctly, but I have no idea why.
Regards,
Christian.
Am 22.07.22
On 20.07.2022 17:52, Jagan Teki wrote:
> Host transfer() in DSI master will invoke only when the DSI commands
> are sent from DSI devices like DSI Panel or DSI bridges and this
> host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
>
> Handling DSI host initialization in transfer calls m
On Thu, Jul 21, 2022 at 9:04 AM Akhil P Oommen wrote:
>
> On 7/20/2022 11:34 AM, Akhil P Oommen wrote:
> > On 7/19/2022 3:26 PM, Rajendra Nayak wrote:
> >>
> >>
> >> On 7/19/2022 12:49 PM, Stephen Boyd wrote:
> >>> Quoting Akhil P Oommen (2022-07-18 23:37:16)
> On 7/19/2022 11:19 AM, Stephen
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is
On 22/07/2022 16:03, Christoph Hellwig wrote:
+ return max_t(size_t, UINT_MAX, dma_max_mapping_size(dev));
Shouldn't this be a min?
eugh! yes. Stand by for v3
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is
On 14/07/2022 09:45, Thomas Zimmermann wrote:
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
Seemed like an
In dss_init_ports() and __dss_uninit_ports(), we should call
of_node_put() for the reference returned by of_graph_get_port_by_id()
in fail path or when it is not used anymore.
Fixes: 09bffa6e5192 ("drm: omap: use common OF graph helpers")
Signed-off-by: Liang He
---
drivers/gpu/drm/omapdrm/dss/d
On 7/22/22 03:24, ChiaEn Wu wrote:
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver,
Hi,
On Fri, Jul 22, 2022 at 12:48 AM Javier Martinez Canillas
wrote:
>
> If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
> ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
>
> But this path also prints an error message, which pollutes the kernel log
Yuji Ishikawa writes:
No changelog?
> Signed-off-by: Yuji Ishikawa
> ---
> v1 -> v2:
> - newly added documents
> ---
> Documentation/driver-api/visconti/common.rst | 115 ++
> Documentation/driver-api/visconti/dnn.rst| 394 +++
> 2 files changed, 509 insertions(+)
>
On 22.07.2022 09:47, Javier Martinez Canillas wrote:
If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
But this path also prints an error message, which pollutes the kernel log
since is printed on e
HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.
In case of deferred FB setup core can try to create new
framebuffer. Disallow it if hpd_suspended flag is set.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drive
HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.
It should fix following GPF:
[272.634530] general protection fault, probably for non
i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.
I
Hi Jani, Ville, Arun,
This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements
Komeda driver relies on the generic DRM atomic helper functions to handle
commits. It only implements an atomic_commit_tail hook for the
mode_config_helper_funcs and even that one is pretty close to the generic
implementation with the exception of additional dma_fence signalling.
What the generic
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:13PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Prepare for supporting more TLB invalidation scenarios by moving
> the current MMIO invalidation to its own file.
>
> Signed-off-by: Chris Wilson
> Cc: Fei Yang
> Signed-off-by: Mauro Car
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:10PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Skip all further TLB invalidations once the device is wedged and
> had been reset, as, on such cases, it can no longer process instructions
> on the GPU and the user no longer has access to
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:09PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Don't flush TLBs when the buffer is only used in the GGTT under full
> control of the kernel, as there's no risk of concurrent access
> and stale access from prefetch.
>
> We only need to i
Hi Mauro and Chris,
On Thu, Jul 14, 2022 at 01:06:08PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Ensure that the TLB of the OA unit is also invalidated
> on gen12 HW, as just invalidating the TLB of an engine is not
> enough.
>
> Cc: sta...@vger.kernel.org
> Fixes: 7938d61591
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:06PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Check if the device is powered down prior to any engine activity,
> as, on such cases, all the TLBs were already invalidated, so an
> explicit TLB invalidation is not needed, thus reducing t
Hi,
On 7/1/22 12:02, Dmitry Osipenko wrote:
> This patchset fixes two problems in the common GEM code. First fixed problem
> is the bogus lockdep splat that complicates debugging of DRM drivers. Second
> problem is the inconsistency in behaviour and improper handling of mapping
> the imported GEMs
On 7/22/22 07:35, Matthew Auld wrote:
> On Fri, 8 Jul 2022 at 21:32, Maíra Canal wrote:
>>
>> From: Arthur Grillo
>>
>> Considering the current adoption of the KUnit framework, convert the
>> DRM mm selftest to the KUnit API.
>
> Is there a plan to convert the corresponding selftest IGT that was
Il 22/07/22 12:24, ChiaEn Wu ha scritto:
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED d
Il 22/07/22 12:24, ChiaEn Wu ha scritto:
From: Alice Chen
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
LED current sources, a RGB LED driv
On Fri, 8 Jul 2022 at 21:32, Maíra Canal wrote:
>
> From: Arthur Grillo
>
> Considering the current adoption of the KUnit framework, convert the
> DRM mm selftest to the KUnit API.
Is there a plan to convert the corresponding selftest IGT that was
responsible for running this (also drm_buddy) to
From: ChiaEn Wu
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and
From: Alice Chen
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display b
From: ChiaEn Wu
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and
From: ChiaEn Wu
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display b
From: ChiYuan Huang
This adds support for the MediaTek MT6370 SubPMIC. MediaTek MT6370 is a
SubPMIC consisting of a single cell battery charger with ADC monitoring,
RGB LEDs, dual channel flashlight, WLED backlight driver, display bias
voltage supply, one general purpose LDO, and the USB Type-C &
From: ChiYuan Huang
Add MediaTek MT6370 binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Krzysztof Kozlowski
---
.../devicetree/bindings/mfd/mediatek,mt6370.yaml | 280 +
include/dt-bindings/iio/adc/mediatek,mt6370_adc.h | 18 ++
2 files changed, 298 in
From: ChiYuan Huang
Add MT6370 backlight binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Rob Herring
---
.../leds/backlight/mediatek,mt6370-backlight.yaml | 92 ++
1 file changed, 92 insertions(+)
create mode 100644
Documentation/devicetree/bindings/led
From: Alice Chen
Add MediaTek MT6370 flashlight binding documentation.
Signed-off-by: Alice Chen
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/leds/mediatek,mt6370-flashlight.yaml | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/
From: ChiYuan Huang
Add MediaTek MT6370 current sink type LED indicator binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Krzysztof Kozlowski
---
v6
- Add 'reg' property of led of multi-led to prevent checking error.
---
.../bindings/leds/mediatek,mt6370-indicator.yaml | 81
From: ChiaEn Wu
Add MediaTek MT6370 Charger binding documentation.
Signed-off-by: ChiaEn Wu
Reviewed-by: Krzysztof Kozlowski
---
.../power/supply/mediatek,mt6370-charger.yaml | 88 ++
1 file changed, 88 insertions(+)
create mode 100644
Documentation/devicetree/bindi
From: ChiYuan Huang
Add MediaTek MT6370 TCPC binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/usb/mediatek,mt6370-tcpc.yaml | 36 ++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/
From: ChiaEn Wu
This patch series add MediaTek MT6370 PMIC support. The MT6370 is a
highly-integrated smart power management IC, which includes a single
cell Li-Ion/Li-Polymer switching battery charger, a USB
Type-C & Power Delivery (PD) controller, dual Flash LED current sources,
a RGB LED drive
On 22/07/2022 10:58, Christoph Hellwig wrote:
On Fri, Jul 22, 2022 at 10:45:54AM +0100, Tvrtko Ursulin wrote:
- unsigned int size = swiotlb_max_segment();
-
- if (size == 0)
- size = UINT_MAX;
On a more detailed look, there was a CI failure which makes me think thi
On Mon, Jul 11, 2022 at 09:52:02AM +0200, Johan Hovold wrote:
> Add an eDP panel entry for AUO B133UAN02.1.
>
> Due to lack of documentation, use the delay_200_500_e50 timings like
> some other AUO entries for now.
>
> Signed-off-by: Johan Hovold
Any comments to this one?
It looks like it hasn
On 21/07/2022 18:43, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer
On 21/07/2022 18:43, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer
On 22/07/2022 09:47, Javier Martinez Canillas wrote:
If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
But this path also prints an error message, which pollutes the kernel log
since is printed on ever
1 - 100 of 108 matches
Mail list logo
