On Wed, 21 Sep 2022 18:43:46 +0800
Kevin Tian wrote:
> The idea is to let vfio core manage the vfio_device life cycle instead
> of duplicating the logic cross drivers. Besides cleaner code in driver
> side this also allows adding struct device to vfio_device as the first
> step toward adding cdev
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. Besides cleaner code in driver
side this also allows adding struct device to vfio_device as the first
step toward adding cdev uAPI in the future. Another benefit is that
user can now look
> On DG2, HuC loading is performed by the GSC, via a PXP command. The load
> operation itself is relatively simple (just send a message to the GSC with the
> physical address of the HuC in LMEM), but there are timing changes that
> requires special attention. In particular, to send a PXP command
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to
Please ignore this cover letter, I've only realized I was missing a
title and aborted the git-send after sending it. Proper series coming in
a couple of mins.
Daniele
On 9/8/2022 5:10 PM, Daniele Ceraolo Spurio wrote:
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
op
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
Hi Hans,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
> On 7/9/20 4:14 PM, Sam Ravnborg wrote:
> > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> > > Here is v4 of my patch series converting the i915 driver's code for
> > > controlling the panel's backlight with
Hi,
On 7/11/20 8:19 AM, Uwe Kleine-König wrote:
Hi Hans,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
On 7/9/20 4:14 PM, Sam Ravnborg wrote:
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
Here is v4 of my patch series converting the i915 driver's code for
c
Hi,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
> Hi,
>
> On 7/9/20 4:14 PM, Sam Ravnborg wrote:
> > Hi Hans.
> >
> > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> > > Hi All,
> > >
> > > Here is v4 of my patch series converting the i915 driver's code for
>
Hi,
On 7/9/20 4:14 PM, Sam Ravnborg wrote:
Hi Hans.
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
Hi All,
Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below
Hi Hans.
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v4 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.
Why is it that i
Hi All,
Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to supp
v4 of https://patchwork.freedesktop.org/series/69540/
Added patches 7 and 14 (by Vandita) to improve state checking. We may
still need to improve the checks for horizontal timings due to potential
round-trip errors, but we're progressing. Otherwise mostly unchanged
from v3.
BR,
Jani.
Jani Nikul
This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.
First 2 patches, comple
Updates based on latest review feedback from Matthew and Lionel and includes an
update to the TestOa register config for SKL GT2 compared the last series (based
on the latest XML files from VPG)
Although the _[SUB]SLICE_MASK GETPARM patches were reviewed, it's worth
mentioning there was a TODO com
16 matches
Mail list logo
