Hi Greg
On 2/11/2022 11:04 PM, Greg KH wrote:
On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
Hi Greg
Thanks for the response.
On 2/11/2022 3:09 AM, Greg KH wrote:
On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
There are cases where depending on the size of th
On Fri, Feb 11, 2022 at 04:18:29PM +, T.J. Mercier wrote:
> This patch introduces a buffer flag BINDER_BUFFER_FLAG_SENDER_NO_NEED
> that a process sending an fd array to another process over binder IPC
> can set to relinquish ownership of the fds being sent for memory
> accounting purposes. If
On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote:
> Hi Greg
>
> Thanks for the response.
>
> On 2/11/2022 3:09 AM, Greg KH wrote:
> > On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
> > > There are cases where depending on the size of the devcoredump and the
> > > spe
Applied to drm-misc-next.
On Wed, Feb 9, 2022 at 5:37 PM Erico Nunes wrote:
>
> Currently when users try to run an application with lima and that hits
> an issue such as a timeout, a message saying "fail to save task state"
> and "error task list is full" is shown in dmesg.
>
> The error task dum
On 2/11/22 18:51, Alistair Popple wrote:
...
@@ -1888,15 +1942,40 @@ static long check_and_migrate_movable_pages(unsigned
long nr_pages,
continue;
prev_head = head;
/*
-* If we get a movable page, since we are going to be pi
On Saturday, 12 February 2022 1:10:29 PM AEDT John Hubbard wrote:
> On 2/6/22 20:26, Alistair Popple wrote:
> > Currently any attempts to pin a device coherent page will fail. This is
> > because device coherent pages need to be managed by a device driver, and
> > pinning them would prevent a drive
On 2/6/22 20:26, Alistair Popple wrote:
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinni
On Tue, Feb 1, 2022 at 2:42 AM Ramalingam C wrote:
>
> From: Mika Kahola
>
> DG2 clear color render compression uses Tile4 layout. Therefore, we need
> to define a new format modifier for uAPI to support clear color rendering.
>
> v2:
> Display version is fixed. [Imre]
> KDoc is enhanced for
On Tue, Feb 1, 2022 at 2:42 AM Ramalingam C wrote:
>
> From: Matt Roper
>
> DG2 unifies render compression and media compression into a single
> format for the first time. The programming and buffer layout is
> supposed to match compression on older gen12 platforms, but the actual
> compression
On 2/11/2022 5:47 AM, Dmitry Baryshkov wrote:
On 11/02/2022 02:31, Abhinav Kumar wrote:
On 2/10/2022 1:32 AM, Dmitry Baryshkov wrote:
On 10/02/2022 03:25, Abhinav Kumar wrote:
On 1/21/2022 1:06 PM, Dmitry Baryshkov wrote:
INTF blocks are not really handled by resource manager, they are
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational (because it is still useful to know that
resets are happening even if they are being ignored).
v2: Better wo
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
All physical encoders used by virtual encoder share the same connector,
so pull the connector field from dpu_encoder_phys into dpu_encoder_virt
structure.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dis
On 2/11/2022 4:08 PM, Dmitry Baryshkov wrote:
On 12/02/2022 02:23, Kuogee Hsieh wrote:
intf_audio_select() callback function use to configure
HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP
interface. HDMI is obsoleted at newer chipset. To keep supporting
legacy hdmi applicati
From: Bjorn Andersson
dpu_kms_debugfs_init() is invoked for each minor being registered. Most
of the files created are unrelated to the minor, so there's no reason to
present them per minor.
The exception to this is the DisplayPort code, which ends up invoking
dp_debug_get() for each minor, each
On 12/02/2022 03:17, Abhinav Kumar wrote:
On 2/11/2022 4:05 PM, Dmitry Baryshkov wrote:
On 12/02/2022 02:38, Abhinav Kumar wrote:
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to
guess,
which intf type we mean, pass INTF_DSI/I
On 2/11/2022 4:05 PM, Dmitry Baryshkov wrote:
On 12/02/2022 02:38, Abhinav Kumar wrote:
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to guess,
which intf type we mean, pass INTF_DSI/INTF_DP directly.
Typically, I am only se
On 12/02/2022 02:23, Kuogee Hsieh wrote:
intf_audio_select() callback function use to configure
HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP
interface. HDMI is obsoleted at newer chipset. To keep supporting
legacy hdmi application, intf_audio_select call back function have
to b
On 12/02/2022 02:38, Abhinav Kumar wrote:
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to guess,
which intf type we mean, pass INTF_DSI/INTF_DP directly.
Typically, I am only seeing a 1:1 mapping like
DRM_MODE_ENCODER_DSI mean
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Make dpu_encoder use atomic_mode_set to receive connector and CRTC
states as arguments rather than finding connector and CRTC by manually
looping through the respective lists.
Signed-off-by: Dmitry Baryshkov
Nice cleanup !!
Reviewed-by: Abhina
On 12/02/2022 02:53, Abhinav Kumar wrote:
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Both cmd and vid backends provide no atomic_check() callbacks and
useless mode_fixup() callbacks. Drop support for both of them.
Signed-off-by: Dmitry Baryshkov
We can drop mode_fixup() but I am using a
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Both cmd and vid backends provide no atomic_check() callbacks and
useless mode_fixup() callbacks. Drop support for both of them.
Signed-off-by: Dmitry Baryshkov
We can drop mode_fixup() but I am using atomic_check() for WB to
validate whether
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
We do not use MSM bus client, so drop bus_scaling_client field from
dpu_encoder_virt.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 --
1 file changed, 2 deletions(-)
diff --
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Stop caching msm_dp instance in dpu_encoder_virt since it's not used
now.
Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable and
disable")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/
On 2/3/2022 12:26 AM, Dmitry Baryshkov wrote:
Rather than passing DRM_MODE_ENCODER_* and letting dpu_encoder to guess,
which intf type we mean, pass INTF_DSI/INTF_DP directly.
Typically, I am only seeing a 1:1 mapping like
DRM_MODE_ENCODER_DSI means DSI
DRM_MODE_ENCODER_VIRTUAL means WB
S
On Sat, 12 Feb 2022 at 02:23, Kuogee Hsieh wrote:
>
> intf_audio_select() callback function use to configure
> HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP
> interface. HDMI is obsoleted at newer chipset. To keep supporting
> legacy hdmi application, intf_audio_select call back
intf_audio_select() callback function use to configure
HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP
interface. HDMI is obsoleted at newer chipset. To keep supporting
legacy hdmi application, intf_audio_select call back function have
to be populated base on hardware chip capabilit
Currently DP driver will allocate panel bridge for eDP panels. This
supports only the following topology:
- eDP encoder ⇒ eDP panel (wrapped using panel-bridge)
Simplify this code to just check if there is any next bridge in the
chain (be it a panel bridge or regular bridge). Rename panel_bridge
It is possible to supply display-connector (bridge) to the DP interface,
add support for parsing it too.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_parser.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parse
dp_bridge's functions are thin wrappers around the msm_dp_display_*
family. Squash dp_bridge callbacks into respective msm_dp_display
functions, removing the latter functions from public space.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 54 +++---
d
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display
enable and disable") the DP driver received a drm_bridge instance, which
is always attached to the encoder as a root bridge. However it conflicts
with the panel_bridge support for eDP panels. The panel bridge attaches
to the e
There is little point in having both connector and root bridge
implementation in the same driver. Move connector's functionality to the
bridge to let next bridge in chain to override it.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 22 +++---
drivers/gpu/drm/msm/dp/
I noticed that commit 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for
display
enable and disable") conflicts with the panel-edp (panel bridge)
support. Both bridges will try to attach directly to the drm encoder
itself without forming a proper bridge chain.
Initially I started writing leng
Hi Mario,
On Thu, Feb 10, 2022 at 04:43:23PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute is currently a dumping ground for a
> variety of things.
>
> Instead use the driver core removable attribute to indicate the
> detail a device is attached to a thunderbolt or USB4 chain.
Hi Mario,
On Thu, Feb 10, 2022 at 04:43:24PM -0600, Mario Limonciello wrote:
> USB4 class devices are also removable like Intel Thunderbolt devices.
>
> Drivers of downstream devices use this information to declare functional
> differences in how the drivers perform by knowing that they are conne
On Thu, Feb 10, 2022 at 04:43:21PM -0600, Mario Limonciello wrote:
> This PCI class definition of the USB4 device is currently located only in
> the thunderbolt driver.
>
> It will be needed by a few other drivers for upcoming changes. Move it into
> the common include file.
>
> Acked-by: Alex De
Make the subject specific, not just "appropriately." I think you're
marking something *removable*, so include that.
On Fri, Feb 11, 2022 at 01:32:45PM -0600, Mario Limonciello wrote:
> Discrete USB4 controllers won't have ACPI nodes specifying which
> PCIe or XHCI port they are linked with.
>
>
Hi Dave, Daniel,
New stuff for 5.18.
The following changes since commit 4efdddbce7c1329f00c458e85dcaf105aebdc0ed:
Merge tag 'amd-drm-next-5.17-2022-01-12' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-01-14 15:42:28
+0100)
are available in the Git repository at:
https
On 2/11/2022 15:35, Bjorn Helgaas wrote:
On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote:
`pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
controller to indicate that D3 is possible. As this is used solely
for older Apple systems, move it into a quirk tha
On Fri, Feb 11, 2022 at 01:32:44PM -0600, Mario Limonciello wrote:
> USB4 class devices are also removable like Intel Thunderbolt devices.
Spec reference, please.
> Drivers of downstream devices use this information to declare functional
> differences in how the drivers perform by knowing that th
On Fri, Feb 11, 2022 at 01:32:43PM -0600, Mario Limonciello wrote:
> The root port used for PCIe tunneling should be marked as removable to
> ensure that the entire chain is marked removable.
>
> This can be done by looking for the device property specified in
> the ACPI tables `usb4-host-interfac
On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote:
> `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
> controller to indicate that D3 is possible. As this is used solely
> for older Apple systems, move it into a quirk that enumerates across
> all Intel TBT co
Update subject to something like:
PCI: pciehp: Quirk broken Command Completed support on Intel Thunderbolt
controllers
On Fri, Feb 11, 2022 at 01:32:40PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` check is currently used to indicate the lack of
> command completed support for a num
On Fri, Feb 11, 2022 at 01:32:39PM -0600, Mario Limonciello wrote:
> This PCI class definition of the USB4 device is currently located only in
> the thunderbolt driver.
>
> It will be needed by a few other drivers for upcoming changes. Move it into
> the common include file.
>
> Acked-by: Alex De
On Fri, Feb 11, 2022 at 3:55 PM Andrey Grodzovsky
wrote:
>
> Update function name.
>
> Signed-off-by: Andrey Grodzovsky
> Reported-by: kernel test robot
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
Update function name.
Signed-off-by: Andrey Grodzovsky
Reported-by: kernel test robot
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index
From: Alyssa Rosenzweig
The most important Valhall-specific quirks have been handled, so add the
Valhall compatible and probe.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.
From: Alyssa Rosenzweig
Add the features, issues, and GPU ID for Mali-G57, a first-generation
Valhall GPU. Other first- and second-generation Valhall GPUs should be
similar.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_features.h | 12
drivers/gpu/drm/pan
From: Alyssa Rosenzweig
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually
tried to port the logic from kbase, trivial jobs raised Data Invalid
Faults, so this may depend on other coherency details. It's still useful
to have the bit to record the feature bit when adding new mo
From: Alyssa Rosenzweig
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs
define slightly different MAX_READS and MAX_WRITES fields, which
throttle outstanding reads and writes when set to non-zero values. When
left as zero, reads and writes are not throttled.
Both kbase a
From: Alyssa Rosenzweig
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
from kbase. kbase lists this workaround as used on Mali-G57.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_gpu.c| 3 +++
drivers/gpu/drm/panfrost/panfrost_issues.h | 3 +++
From: Alyssa Rosenzweig
TTRX_3485 requires the infamous "dummy job" workaround. I have this
workaround implemented in a local branch, but I have not yet hit a case
that requires it so I cannot test whether the implementation is correct.
In the mean time, add the quirk bit so we can document which
From: Alyssa Rosenzweig
Some Valhall GPUs require resets when encountering bus faults due to
occlusion query writes. Add the issue bit for this and handle it.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_device.c | 9 +++--
drivers/gpu/drm/panfrost/panfrost_issues
From: Alyssa Rosenzweig
Logically, this function is free of side effects, so any pointers it
takes should be const. Needed to avoid a warning in the next patch.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_issues.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Alyssa Rosenzweig
>From the kernel's perspective, pre-CSF Valhall is more or less
compatible with Bifrost, although they differ to userspace. Add a
compatible for Valhall to the existing Bifrost bindings documentation.
Signed-off-by: Alyssa Rosenzweig
Cc: devicet...@vger.kernel.org
---
D
From: Alyssa Rosenzweig
This patch series adds preliminary support for Mali "Valhall" GPUs into
the Panfrost kernel driver. The series has been tested on the Mali-G57
on a MediaTek MT8192 system. However, that system requires additional
MediaTek-specific patches [1] as well as core mainlining for
On 2/11/2022 11:37 AM, Dmitry Baryshkov wrote:
On 18/01/2022 23:03, Dmitry Baryshkov wrote:
On Tue, 18 Jan 2022 at 22:29, Abhinav Kumar
wrote:
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typica
The pull request you sent on Fri, 11 Feb 2022 13:46:47 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c3ee3a9e4fa6b1d249b5abff2d4c7dab5a47d522
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On 18/01/2022 23:03, Dmitry Baryshkov wrote:
On Tue, 18 Jan 2022 at 22:29, Abhinav Kumar wrote:
On 12/7/2021 2:29 PM, Dmitry Baryshkov wrote:
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typically DSI device bridge drivers expect to be
able to
[Public]
> -Original Message-
> From: Mika Westerberg
> Sent: Friday, February 11, 2022 04:24
> To: Limonciello, Mario
> Cc: Bjorn Helgaas ; Andreas Noever
> ; open list:PCI SUBSYSTEM p...@vger.kernel.org>; open list:THUNDERBOLT DRIVER u...@vger.kernel.org>; open list:RADEON and AMDGPU
[Public]
> -Original Message-
> From: Mika Westerberg
> Sent: Friday, February 11, 2022 04:35
> To: Limonciello, Mario
> Cc: Bjorn Helgaas ; Andreas Noever
> ; open list:PCI SUBSYSTEM p...@vger.kernel.org>; open list:THUNDERBOLT DRIVER u...@vger.kernel.org>; open list:RADEON and AMDG
USB4 class devices are also removable like Intel Thunderbolt devices.
Drivers of downstream devices use this information to declare functional
differences in how the drivers perform by knowing that they are connected
to an upstream TBT/USB4 port.
Reviewed-by: Macpaul Lin
Signed-off-by: Mario Lim
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
1 file changed, 2 inse
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
As all drivers now look at the removable attribute, drop this function.
Signed-off-by: Mario Limonciello
---
include/linux/pci.h | 22 --
1 file changed, 22 deletions(-)
diff --git
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
drivers/gpu/drm/radeo
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Acked-by: Hans de Goede
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/apple-gmux.c | 2 +-
1 f
Discrete USB4 controllers won't have ACPI nodes specifying which
PCIe or XHCI port they are linked with.
In order to set the removable attribute appropriately, use the
USB4 DVSEC extended capabability set on these root ports to determine
if they are located on a discrete USB4 controller.
Suggeste
The `is_thunderbolt` attribute is currently a dumping ground for a
variety of things.
Instead use the driver core removable attribute to indicate the
detail a device is attached to a thunderbolt or USB4 chain.
Signed-off-by: Mario Limonciello
---
drivers/pci/probe.c | 20 +++--
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Reviewed-by: Macpaul Lin
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2
The root port used for PCIe tunneling should be marked as removable to
ensure that the entire chain is marked removable.
This can be done by looking for the device property specified in
the ACPI tables `usb4-host-interface`.
Suggested-by: Mika Westerberg
Link:
https://docs.microsoft.com/en-us/w
`pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
controller to indicate that D3 is possible. As this is used solely
for older Apple systems, move it into a quirk that enumerates across
all Intel TBT controllers.
Suggested-by: Mika Westerberg
Signed-off-by: Mario Limonciello
This PCI class definition of the USB4 device is currently located only in
the thunderbolt driver.
It will be needed by a few other drivers for upcoming changes. Move it into
the common include file.
Acked-by: Alex Deucher
Acked-by: Mika Westerberg
Signed-off-by: Mario Limonciello
---
drivers/
The `is_thunderbolt` check is currently used to indicate the lack of
command completed support for a number of older Thunderbolt devices.
This however is heavy handed and should have been done via a quirk. Move
the affected devices outlined in commit 493fb50e958c ("PCI: pciehp: Assume
NoCompl+ fo
Various drivers in the kernel use `is_thunderbolt` or
`pci_is_thunderbolt_attached` to designate behaving differently
from a device that is internally in the machine. This relies upon checks
for a specific capability only set on Intel controllers.
Non-Intel USB4 designs should also match this desi
On Wed, 9 Feb 2022 22:55:44 +0100, Michael Riesch wrote:
> This series aims to bring the GPU support for the RK356x mainline. In
> conjunction with the VOP2/HDMI TX patches v4 [0]) it has been tested
> successfully on a RK3568 EVB1 with weston and glmark2-es2-wayland.
>
> It should be noted that o
On Wed, 9 Feb 2022 22:55:44 +0100, Michael Riesch wrote:
> This series aims to bring the GPU support for the RK356x mainline. In
> conjunction with the VOP2/HDMI TX patches v4 [0]) it has been tested
> successfully on a RK3568 EVB1 with weston and glmark2-es2-wayland.
>
> It should be noted that o
Hello Andy,
On 2/11/22 17:13, Andy Shevchenko wrote:
[snip]
>
>> +#define SSD130X_SET_COM_PINS_CONFIG1_MASK GENMASK(4, 4)
>
> BIT(4)
>
>> +#define SSD130X_SET_COM_PINS_CONFIG1_SET(val)
>> FIELD_PREP(SSD130X_SET_COM_PINS_CONFIG1_MASK, (!val))
>> +#define SSD130X_SET_COM_PINS_CONFIG2_M
Hi Greg
Thanks for the response.
On 2/11/2022 3:09 AM, Greg KH wrote:
On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote:
There are cases where depending on the size of the devcoredump and the speed
at which the usermode reads the dump, it can take longer than the current 5 mins
tim
On Fri, Feb 11, 2022 at 06:25:17PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Andy Shevchenko
> wrote:
> > On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
> >> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> >> > Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
> >> >> On Fri, Fe
On Wed, 09 Feb 2022 22:55:45 +0100, Michael Riesch wrote:
> From: Alex Bee
>
> The Bifrost GPU in Rockchip RK356x SoCs has a core and a bus clock.
> Reflect this in the SoC specific part of the binding.
>
> Signed-off-by: Alex Bee
> [move the changes to the SoC section]
> Signed-off-by: Michael
Am 2022-02-11 um 11:39 schrieb David Hildenbrand:
On 11.02.22 17:15, David Hildenbrand wrote:
On 01.02.22 16:48, 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 o
Am 2022-02-11 um 11:15 schrieb David Hildenbrand:
On 01.02.22 16:48, 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. H
On Fri, Feb 11, 2022 at 05:49:08PM +0100, David Hildenbrand wrote:
> On 11.02.22 17:45, Jason Gunthorpe wrote:
> > On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
> >
> >> ... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages
> >
> > Currently the only way to get a DEVICE
On 2/11/2022 10:39 AM, David Hildenbrand wrote:
On 11.02.22 17:15, David Hildenbrand wrote:
On 01.02.22 16:48, 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
On 11.02.22 17:45, Jason Gunthorpe wrote:
> On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
>
>> ... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages
>
> Currently the only way to get a DEVICE_PRIVATE page out of the page
> tables is via hmm_range_fault() and that doesn'
On Fri, Feb 11, 2022 at 05:15:25PM +0100, David Hildenbrand wrote:
> ... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages
Currently the only way to get a DEVICE_PRIVATE page out of the page
tables is via hmm_range_fault() and that doesn't manipulate any ref
counts.
Jason
On 11.02.22 17:15, David Hildenbrand wrote:
> On 01.02.22 16:48, 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. H
On Mon, 07 Feb 2022 23:39:11 +0100, David Heidelberg wrote:
> Inherit valid properties from the dsi-controller.
>
> Reviewed-by: Dmitry Osipenko
> Signed-off-by: David Heidelberg
> ---
> v2:
> - added $ref ../dsi-controller.yaml# instead copying properties (Dmitry)
> - additionalProperties ->
On Fri, 11 Feb 2022, Andy Shevchenko wrote:
> On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
>> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
>> > Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
>> >> On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
>> >>> On
On 11/02/2022 13:33, Jani Nikula wrote:
On Thu, 10 Feb 2022, Michael Cheng wrote:
Move wbvind_on_all_cpus to intel_gt.h. This will allow other wbind_on_all_cpus
calls to benefit from the #define logic, and prevent compiler errors
when building for non-x86 architectures.
Signed-off-by: Michae
On 01.02.22 16:48, 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
On Fri, Feb 11, 2022 at 03:33:55PM +0100, Javier Martinez Canillas wrote:
> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
> OLED display controllers.
>
> It's only the core part of the driver and a bus specific driver is needed
> for each transport interface supported by
On Fri, Feb 11, 2022 at 03:33:54PM +0100, Javier Martinez Canillas wrote:
> Add support to convert from XR24 to reversed monochrome for drivers that
> control monochromatic display panels, that only have 1 bit per pixel.
>
> The function does a line-by-line conversion doing an intermediate step
>
Thanks for the feedback! Another idea I had that kind of align to what you are
suggesting is adding a wrapper for wbinvd_on_all_cpus within drm_cache.h, then
having it be included in the three files that calls this function. Thoughts on
that?
From: Jani Nikula
On Fri, Feb 11, 2022 at 03:33:53PM +0100, Javier Martinez Canillas wrote:
> Pull the per-line conversion logic into a separate helper function.
>
> This will allow to do line-by-line conversion in other helpers that
> convert to a gray8 format.
for-loop vs. while-loop is not critical, so
Reviewed
On Fri, Feb 11, 2022 at 12:50:04PM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 12:10, Andy Shevchenko wrote:
...
> >> + for (xb = 0; xb < pixels; xb++) {
> >> + unsigned int start = 0, end = 8;
> >> + u8 byte = 0x00;
> >
> >> + if (xb == 0 && start_offset)
> >
On Fri, Feb 11, 2022 at 01:05:57PM +0100, Javier Martinez Canillas wrote:
> On 2/11/22 12:33, Andy Shevchenko wrote:
> > On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
...
> >> + * Helper to write command (SSD130X_COMMAND). The fist variadic argument
> >> + * is the com
On Sun, Feb 06, 2022 at 09:00:11AM +0100, Andreas Kemnade wrote:
> Add a binding for the Electrophoretic Display Controller found at least
> in the i.MX6.
The first version was in i.MX50 (I helped design the register
interface). Is that version compatible?
> The timing subnode is directly here t
On Thu, 2022-02-10 at 18:30 -0800, Qing Wang wrote:
> From: Wang Qing
>
> It is better to use time_xxx() directly instead of jiffies judgment
> for understanding.
>
> Signed-off-by: Wang Qing
Acked-by: Srinivas Pandruvada
> ---
> drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +-
> 1 file changed,
On Fri, Feb 11, 2022 at 02:05:56PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Thomas Zimmermann wrote:
> > Am 11.02.22 um 12:12 schrieb Andy Shevchenko:
> >> On Fri, Feb 11, 2022 at 11:40:13AM +0100, Javier Martinez Canillas wrote:
> >>> On 2/11/22 11:28, Andy Shevchenko wrote:
> On Fri
On 11/02/2022 14:58, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> The IDVS group size feature was missing. It is used on some Bifrost and
> Valhall GPUs, and is the last kernel-relevant Bifrost feature we're
> missing.
>
> This feature adds an extra IDVS group size field
1 - 100 of 234 matches
Mail list logo
