From: Ye Guojin
Since the variables named is_end_of_payload and hpd_status are already
bool type, the ?: conditional operator is unnecessary any more.
Clean them up here.
Reported-by: Zeal Robot
Signed-off-by: Ye Guojin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
drivers/g
On Tue, 02 Nov 2021, He Ying wrote:
> 在 2021/11/1 21:02, Jani Nikula 写道:
>> On Mon, 01 Nov 2021, He Ying wrote:
>>> From the comments of drm_for_each_connector_iter(), we know
>>> that "connector is only valid within the list body, if you
>>> want to use connector after calling drm_connector_lis
Hi Maíra,
On Sat, Oct 30, 2021 at 3:35 PM Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
Thanks for your patch!
> --- a/drivers/video/backlight/lp855x_bl.c
> +++ b/drivers/video/back
On Tue, 02 Nov 2021, "Yuan, Perry" wrote:
> [AMD Official Use Only]
>
> Hi Jani:
> Thanks for your comments.
>
>> -Original Message-
>> From: Jani Nikula
>> Sent: Monday, November 1, 2021 9:07 PM
>> To: Yuan, Perry ; Maarten Lankhorst
>> ; Maxime Ripard ;
>> Thomas Zimmermann ; David Airl
>From the comments of drm_for_each_connector_iter(), we know
that "connector is only valid within the list body, if you
want to use connector after calling drm_connector_list_iter_end()
then you need to grab your own reference first using
drm_connector_get()". So fix the wrong use of connector
acco
On 01/11/2021 18:38, Thomas Hellström wrote:
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move
Reviewed-by: Simon Ser
Am 25.10.21 um 09:57 schrieb Javier Martinez Canillas:
The logic to remove the conflicting frame buffers for fbdev devices that
use a given memory range is only compiled if CONFIG_FB option is enabled.
But having an ifdefery in drm_aperture_remove_conflicting_framebuffers()
makes the function
If the bridge cannot get powered on, there's no reason to try to
communicate with it: change the ps8640_bridge_poweron function to
return an error value to the caller, so that we can avoid calling
ps8640_bridge_vdo_control() in ps8640_pre_enable() if the poweron
sequence fails.
Signed-off-by: Ange
In preparation for varying the poweron error handling in function
ps8640_bridge_poweron(), move function ps8640_bridge_poweroff() up
and also move the actual logic to power off the chip to a new
__ps8640_bridge_poweroff() function.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/b
In function ps8640_bridge_poweron(), in case of a failure not relative
to the regulators enablement, the code was disabling the regulators but
the gpio changes that happened during the poweron sequence were not
being reverted back to a clean poweroff state.
Since it is expected that, when we enter
The sc7280 eDP sink that supports downspread will fail link training
if source does not enable SSC / downspread. This change will set the
downspread bit in the DP sink if supported and indicate SSC support
to the DP PHY driver.
Signed-off-by: Sankeerth Billakanti
Reviewed-by: Stephen Boyd
---
d
From: Sankeerth Billakanti
The Qualcomm SC7280 platform supports one eDP controller
and a DP controller. This change will add the compatible
string for both eDP and DP to msm dp-controller binding.
Signed-off-by: Sankeerth Billakanti
changes in v3:
- Modify the subject (Doug Anderson)
This series will add eDP controller support for Qualcomm SC7280
platform. These patches are baseline changes with which we can enable
eDP display on sc7280. The sc7280 eDP controller driver can also support
additional features such as no_hpd detection, PSR, etc. which will be
enabled in sub
The eDP controller on SC7280 is similar to the eDP/DP controllers
supported by the current driver implementation.
SC7280 supports one EDP and one DP controller which can operate
concurrently.
This change adds the support for eDP and DP controller on sc7280.
Signed-off-by: Sankeerth Billakanti
Add a macro to check for the max_downspread capability in
drm_dp_helper.
Signed-off-by: Sankeerth Billakanti
Reviewed-by: Stephen Boyd
changes in v4:
- Return 1 for DPCD version >= v1.1 (Stephen Boyd)
---
include/drm/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git
The eDP sink on sc7280 supports ASSR and dp driver will
enable ASSR in the source hardware. The driver needs to
enable the ASSR field in the DPCD configuration register
to avoid screen corruption. This change will enable ASSR
if supported in the sink device.
Signed-off-by: Sankeerth Billakanti
Re
On 01/11/2021 23:11, Andi Shyti wrote:
Hi Matt and Tvrtko,
[...]
static int
intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
phys_addr)
we don't actually need 'id', it's gt->info.id. It's introduced in
patch 3 with the value '0' but it's not needed.
I have a sus
On 10/30/21 11:24, PGNet Dev wrote:
Is that kernel/modconfig config incorrect?
Not relevant to the problem?
Something else(where) needed?
fwiw,
AMD Global Customer Care's response to question about this 'purple' issue:
"...
Please be informed that Ryzen 5600G APU is supported only on Windows
From: Jean-Jacques Hiblot
This patch adds support for an "enable GPIO".
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Corentin LABBE
---
drivers/video/backlight/led_bl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/bac
https://bugzilla.kernel.org/show_bug.cgi?id=214901
--- Comment #5 from spassw...@web.de ---
This commit leads to a freeze when starting
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/amd/amdgpu?id=714d9e4574d54596973ee3b0624ee4a16264d700
After reverting it
This patch series prepares error capture for asynchronous migration,
where the vma pages may not reflect the pages the GPU is currently
executing from but may be several migrations ahead.
The first patch introduces vma state snapshots that record the vma state
at request submission time.
It also t
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
The capture code is typically run entirely in the fence signalling
critical path. Recently added lockdep annotation reveals a lockdep splat
similar to the below one.
Fix the splats and the associated potential deadlocks using
__GFP_KSWAPD_RECLAIM (which is the same as GFP_WAIT, but open-coded for
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error capture).
When a vma is
On Tue, 2 Nov 2021 at 02:56, Xin Ji wrote:
>
> On Mon, Nov 01, 2021 at 11:16:15AM +0800, Jitao Shi wrote:
> > Hi Xin,
> >
> > Please help to review the changes in anx7625.c
> >
> > On Thu, 2021-09-16 at 06:31 +0800, Jitao Shi wrote:
> > > This device requires the packets on lanes aligned at the en
On Tue, Nov 02, 2021 at 10:04:55AM +, Corentin LABBE wrote:
> From: Jean-Jacques Hiblot
>
> This patch adds support for an "enable GPIO".
Before taking this kind of change is there a good reason why backlight
should manage the GPIO? I thought that the LED subsystem was a sub
system for LEDs
On Tue, Nov 02, 2021 at 11:19:42AM +, Daniel Thompson wrote:
> On Tue, Nov 02, 2021 at 10:04:55AM +, Corentin LABBE wrote:
> > From: Jean-Jacques Hiblot
> >
> > This patch adds support for an "enable GPIO".
>
> Before taking this kind of change is there a good reason why backlight
> shou
Hi Tvrtko,
> > [...]
> >
> > > static int
> > > intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
> > > phys_addr)
> >
> > we don't actually need 'id', it's gt->info.id. It's introduced in
> > patch 3 with the value '0' but it's not needed.
>
> I have a suspicion code g
From: mwezdeck
The idea behind the commit:
1. not pin the pages during resource_create ioctl
2. pin the pages on the first use during:
- transfer_*_host ioctl
- map ioctl
3. introduce new ioctl for pinning pages on demand
This change has no impact on user space.
Signed-off
https://bugzilla.kernel.org/show_bug.cgi?id=214901
--- Comment #6 from t...@siduction.org ---
Looks like the same problem as i stated here:
https://bugzilla.kernel.org/show_bug.cgi?id=214859
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching
On Mon, Nov 01, 2021 at 07:55:17PM +0100, Hans de Goede wrote:
> The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated LP8556 backlight
> controller for its LCD-panel, with a Xiaomi specific ACPI HID of
> "XMCC0001", add support for this.
>
> Note the new "if (id)" check also fixes a NULL pointer der
On Mon, Nov 01, 2021 at 07:55:16PM +0100, Hans de Goede wrote:
> Add a dev local variable to the lp855x_probe(), to replace "&cl->dev"
> and "lp->dev" in various places.
>
> Also switch to dev_err_probe() in one case which takes care of not
> printing -EPROBE_DEFER errors for us.
>
> This is most
On Mon, Nov 01, 2021 at 07:55:15PM +0100, Hans de Goede wrote:
> Move the setting of the lp->cfg pointer to the chip specific
> lp855x_device_config struct from lp855x_configure() to
> lp855x_probe(), before calling lp855x_parse_dt().
>
> This is a preperation patch for adding ACPI enumeration sup
On Mon, Oct 25, 2021 at 12:17:37AM +0200, Claudio Suarez wrote:
[...]
No new comments about this, I suppose everything is fine.
I'm going to send the patch with this changes. Thanks to all and
special thanks to you, Ville. Hope this helps the kernel.
Don't hesitate to ask new changes if necessary
Commit a92d083d08b0 created the new flag is_hdmi in drm_display_info
which is set when sink compliant with CEA-861 (EDID) will be treated
as an HDMI sink.
>From that day, this value can be used in some cases instead of
calling drm_detect_hdmi_monitor() and a second parse is avoided
because drm_det
On Tue, Nov 02, 2021 at 12:31:39PM +0100, Maksym Wezdecki wrote:
> From: mwezdeck
>
> The idea behind the commit:
> 1. not pin the pages during resource_create ioctl
> 2. pin the pages on the first use during:
> - transfer_*_host ioctl
> - map ioctl
i.e. basically lazy pinning.
Entering suspend while the display attached to this bridge is still on
makes the resume sequence to resume the bridge first, display last:
when this happens, we get a timeout while resuming the bridge, as its
MCU will get stuck due to the display being unpowered.
On the other hand, on mt8173-elm,
On Fri, Oct 29, 2021 at 11:55:25AM +0800, Yunfei Dong wrote:
> Adds decoder dt-bindings for mt8192.
>
> Signed-off-by: Yunfei Dong
> ---
> v8: fix yaml file check fail
> ---
> .../media/mediatek,vcodec-comp-decoder.yaml | 273 ++
> 1 file changed, 273 insertions(+)
> create mo
On 01/11/2021 18:38, Thomas Hellström wrote:
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async callback that checks the
blit f
On Tue, Nov 02, 2021 at 08:05:34AM +0100, Christoph Hellwig wrote:
> Remove the separately included Makefile and just use the relative
> reference from the main i915 Makefile as for source files in other
> subdirectories.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/Makefile
On 02/11/2021 11:26, Andi Shyti wrote:
Hi Tvrtko,
[...]
static int
intel_gt_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
phys_addr)
we don't actually need 'id', it's gt->info.id. It's introduced in
patch 3 with the value '0' but it's not needed.
I have a suspicion
On Wed, Oct 27, 2021 at 07:28:45AM +0900, Inki Dae wrote:
> Hi,
>
> 21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> > drm_detect_hdmi_monitor() is le
Thanks for reviewing Matt,
On 11/2/21 14:55, Matthew Auld wrote:
On 01/11/2021 18:38, Thomas Hellström wrote:
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Int
From: Krishna Manikandan
Add mdss and mdp DT nodes for sc7280.
Signed-off-by: Krishna Manikandan
Reported-by: kernel test robot
Reviewed-by: Stephen Boyd
Reported-by: kernel test robot
Signed-off-by: Sankeerth Billakanti
---
Changes in v3:
None
Changes in v2:
- Rename display dt n
From: Krishna Manikandan
Add DSI controller and PHY nodes for sc7280.
Signed-off-by: Rajeev Nandan
Signed-off-by: Krishna Manikandan
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Stephen Boyd
Signed-off-by: Sankeerth Billakanti
---
Changes in v3:
- Add the dsi_phy clocks (Kuogee Hsieh)
Add edp controller and phy DT nodes for sc7280.
Signed-off-by: Krishna Manikandan
Reviewed-by: Stephen Boyd
Signed-off-by: Sankeerth Billakanti
---
Changes in v3:
- Add one clock cell per line (Stephen Boyd)
- Unit address should match first reg property (Stephen Boyd)
- Remove new
On Tue, 02 Nov 2021, Christoph Hellwig wrote:
> Remove the separately included Makefile and just use the relative
> reference from the main i915 Makefile as for source files in other
> subdirectories.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Make
Hi,
This is a follow-up of the work to support the interactions between the hotplug
and the scrambling support for vc4:
https://lore.kernel.org/dri-devel/20210507150515.257424-11-max...@cerno.tech/
https://lore.kernel.org/dri-devel/20211025152903.1088803-10-max...@cerno.tech/
Ville feedback was
Most drivers supporting the HDMI scrambling seem to have the HDMI 1.4
maximum frequency open-coded, and a function to test whether a display
mode is above that threshold to control whether or not scrambling should
be enabled.
Let's create a common define and helper for drivers to reuse.
Cc: Emma
A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their
driver to test whether the resolutions are supported or if the
scrambling needs to be enabled.
Let's create a common define for everyone to use it.
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: Andrzej Hajda
Cc: Benjam
All the drivers that implement the HDMI scrambling setup (dw-hdmi, i915,
tegra, vc4) duplicate the same logic to see if the TMDS ratio or the
scrambling state needs to be modified depending on the current connector
state and CRTC mode.
Since it's basically the same logic everywhere, let's put thes
The hdmi_monitor flag in the vc4_hdmi_encoder structure is redundant
with the is_hdmi flag in the drm_display_info structure.
Let's convert all the users.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 16 ++--
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 -
2 files change
There's some interactions between the SCDC setup and the disconnection /
reconnection of displays. Let's document it and a solution.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_scdc_helper.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_scdc_help
We recently introduced a new mutex to protect concurrent execution of
ALSA and KMS hooks, and the concurrent access to some of vc4_hdmi
fields.
However, using it in the detect hook was creating a reentrency issue
with CEC code. Indeed, calling cec_s_phys_addr_from_edid from detect
might call the C
During a hotplug cycle (such as a TV going out of suspend, or when the
cable is disconnected and reconnected), the expectation is that the same
state used before the disconnection is reused until the next commit.
However, the HDMI scrambling requires that some flags are set in the
monitor, and tho
Our detect callback has a bunch of operations to perform depending on
the current and last status of the connector, such a setting the CEC
physical address or enabling the scrambling again.
This is currently dealt with a bunch of if / else statetements that make
it fairly difficult to read and ext
We'll need the locking context in future patch, so let's convert .detect
to .detect_ctx.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
inde
When we have the entire DRM state, retrieving the connector state only
requires the drm_connector pointer. Fortunately for us, we have
allocated it as a part of the vc4_hdmi structure, so we can retrieve get
a pointer by simply accessing our field in that structure.
Signed-off-by: Maxime Ripard
-
Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it
never uses it. Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/v
Enabling the scrambling on reconnection seems to work so far but breaks
the HDMI2.0 specification and has introduced some issues in the past
with i915.
Let's do a mode set on the connector instead to follow the
specification.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 7 +
Now that we have a generic helper to fill the scrambling status, let's
use it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 32 ++--
drivers/gpu/drm/vc4/vc4_hdmi.h | 6 ++
2 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drive
Hi,
On Tue, Nov 02, 2021 at 04:46:28AM -0400, He Ying wrote:
> From the comments of drm_for_each_connector_iter(), we know
> that "connector is only valid within the list body, if you
> want to use connector after calling drm_connector_list_iter_end()
> then you need to grab your own reference fir
Hi,
On Thu, Oct 28, 2021 at 06:13:27PM -0400, Julian Braha wrote:
> When PHY_SUN6I_MIPI_DPHY is selected, and RESET_CONTROLLER
> is not selected, Kbuild gives the following warning:
>
> WARNING: unmet direct dependencies detected for PHY_SUN6I_MIPI_DPHY
> Depends on [n]: (ARCH_SUNXI [=n] || COM
On Tue, Nov 02, 2021 at 08:05:35AM +0100, Christoph Hellwig wrote:
> THIS_MODULE always is reference when a symbol called by it is used, so
> don't bother with the additional reference.
heh, these functions are only called from a module init/exit even
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Nov 02, 2021 at 08:05:36AM +0100, Christoph Hellwig wrote:
> The only supported hypervisor is KVM, so don't bother with dead code
> enumerating hypervisors.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.c | 17 +--
> drivers/gpu/drm/i915/gvt/gvt.h
On Tue, Nov 02, 2021 at 08:05:37AM +0100, Christoph Hellwig wrote:
> Free the intel_vgpu_ops symbol name for something that fits better.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Jason
On Tue, Nov 2, 2021 at 6:07 AM Gerd Hoffmann wrote:
>
> On Tue, Nov 02, 2021 at 12:31:39PM +0100, Maksym Wezdecki wrote:
> > From: mwezdeck
> >
> > The idea behind the commit:
> > 1. not pin the pages during resource_create ioctl
> > 2. pin the pages on the first use during:
> > - trans
On Mon, Nov 01, 2021 at 10:19:21AM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
> ---
> V1 -> V2: Initialize variable and simply conditional loop
> V2 -> V3: Fix assignment of
On Tue, Nov 02, 2021 at 08:05:39AM +0100, Christoph Hellwig wrote:
> Remove these pointless indirect alls by just calling the only instance
> of each method directly.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.c | 20 +--
> drivers/gpu/drm/i915/gv
On Tue, Nov 02, 2021 at 08:05:40AM +0100, Christoph Hellwig wrote:
> The map_gfn_to_mfn and set_trap_area ops are never defined, so remove
> them and clean up code that depends on them in the callers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/cfg_space.c | 89 ++--
On Tue, Nov 02, 2021 at 08:05:41AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
> drivers/gpu/drm/i915/gvt/mpt.h | 12
> 3 files changed, 19 deletions(
On Tue, Nov 02, 2021 at 08:05:42AM +0100, Christoph Hellwig wrote:
> Move towards having only a single structure for the per-VGPU state.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 31 ++-
> drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
> drivers/gpu/drm/
On Tue, Nov 02, 2021 at 08:05:43AM +0100, Christoph Hellwig wrote:
> Consolidate the per-VGPU structures into a single one.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 8 +++
> drivers/gpu/drm/i915/gvt/kvmgt.c | 117 ---
> 2 files
dma_fence_wait expects a boolean for whether it should be interruptible,
not a timeout value.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/dr
On Tue, Nov 02, 2021 at 08:05:44AM +0100, Christoph Hellwig wrote:
> Always pass the actual vgpu structure instead of encoding it as a
> "handle" and add a bool flag to denote if a VGPU is attached.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 3 +-
> dri
On 11/2/21 16:50, Matthew Auld wrote:
dma_fence_wait expects a boolean for whether it should be interruptible,
not a timeout value.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
On Tue, Nov 02, 2021 at 08:05:45AM +0100, Christoph Hellwig wrote:
> Just call the VFIO functions directly instead of through the method
> table.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 +--
> drivers/gpu/drm/i915/gvt/execlist.c | 12 -
>
On Tue, Nov 02, 2021 at 08:05:46AM +0100, Christoph Hellwig wrote:
> Just open code the calls to the VFIO APIs.
>
> Signed-off-by: Christoph Hellwig
> drivers/gpu/drm/i915/gvt/dmabuf.c| 12 ++-
> drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2
On Tue, Nov 02, 2021 at 08:05:47AM +0100, Christoph Hellwig wrote:
> Just call the code to setup the opregions and EDID data directly.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 3 +++
> drivers/gpu/drm/i915/gvt/hypercall.h | 3 ---
> drivers/gpu/drm/i9
On Tue, Nov 02, 2021 at 08:05:48AM +0100, Christoph Hellwig wrote:
> Just call the function directly.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 1 +
> drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +--
> driver
On Tue, Nov 02, 2021 at 08:05:49AM +0100, Christoph Hellwig wrote:
> Just open code the MSI injection in a single place instead of going
> through the method table.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
> drivers/gpu/drm/i915/gvt/interrupt.c |
On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
wrote:
>
> Resetting will clear the CONTEXT_VALID_BIT, so wait until after that to test.
>
AFAIK this seems to be fixing something earlier in the series(maybe
patch 7?) i.e without this patch we seem to trigger the BUG_ON. If so,
this needs to be mu
On Tue, Nov 02, 2021 at 08:05:50AM +0100, Christoph Hellwig wrote:
> Just call the code directly and move towards the callers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 20 ++--
> drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
> drivers/gpu
On Tue, Nov 02, 2021 at 08:05:51AM +0100, Christoph Hellwig wrote:
> Just open code it in the only caller.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 9 +
> drivers/gpu/drm/i915/gvt/hypercall.h | 1 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 16
On Tue, Nov 02, 2021 at 08:05:52AM +0100, Christoph Hellwig wrote:
> Just call the kvmgt functions directly.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.h| 3 +++
> drivers/gpu/drm/i915/gvt/hypercall.h | 2 --
> drivers/gpu/drm/i915/gvt/kvmgt.c | 6
On Mon, 25 Oct 2021 at 16:29, Maxime Ripard wrote:
>
> Prior to commit 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod"), in the
> detect hook, if we had an HPD GPIO we would only rely on it and return
> whatever state it was in.
>
> However, that commit changed that by mistake to only consider the
On Tue, Nov 02, 2021 at 08:05:53AM +0100, Christoph Hellwig wrote:
> Just call the functions directly. Also remove a pointless wrapper.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c| 10 ++
> drivers/gpu/drm/i915/gvt/gtt.c | 20 +---
On Tue, Nov 02, 2021 at 08:05:54AM +0100, Christoph Hellwig wrote:
> Just call the function directly and remove a pointless wrapper.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c| 14 +-
> drivers/gpu/drm/i915/gvt/gvt.h | 1 +
> drivers/gpu
On Tue, Nov 02, 2021 at 08:05:55AM +0100, Christoph Hellwig wrote:
> Just call the initializion and exit functions directly and remove
> this abstraction entirely.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/gvt.c | 11 -
> drivers/gpu/drm/i915/gvt/gvt.h
On Tue, Nov 02, 2021 at 08:05:56AM +0100, Christoph Hellwig wrote:
> All the dmabufs are torn down when th VGPU is released, so there is
> no need for extra refcounting here.
>
> Based on an patch from Jason Gunthorpe.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/dmabuf
On Tue, Nov 02, 2021 at 08:05:57AM +0100, Christoph Hellwig wrote:
> Initialize variables at declaration time, avoid pointless gotos and
> cater for the fact that intel_gvt_create_vgpu can't return NULL.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 28 +
On Tue, Nov 02, 2021 at 08:05:58AM +0100, Christoph Hellwig wrote:
> Pass the structure we actually care about instead of deriving it from
> the mdev_device in the lower level code.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 28 ++--
>
On Mon, 25 Oct 2021 at 16:29, Maxime Ripard wrote:
>
> We'll need that function in vc4_kms to compute the core clock rate
> requirements.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 8
> drivers/gpu/drm/vc4/vc4_drv.h | 5
On Mon, 25 Oct 2021 at 16:29, Maxime Ripard wrote:
>
> vc4_crtc_config_pv() retrieves the encoder again, even though its only
> caller, vc4_crtc_atomic_enable(), already did.
>
> Pass the encoder pointer as an argument instead of going through all the
> connectors to retrieve it again.
>
> Signed-
On Mon, 25 Oct 2021 at 16:29, Maxime Ripard wrote:
>
> It turns out the encoder retrieval code, in addition to being
> unnecessarily complicated, has a bug when only the planes and crtcs are
> affected by a given atomic commit.
>
> Indeed, in such a case, either drm_atomic_get_old_connector_state
On Mon, 25 Oct 2021 at 16:29, Maxime Ripard wrote:
>
> The encoder retrieval code has been a source of bugs and glitches in the
> past and the crtc <-> encoder association been wrong in a number of
> different ways.
>
> Add some logging to quickly spot issues if they occur.
>
> Signed-off-by: Maxi
On Tue, Nov 02, 2021 at 08:05:59AM +0100, Christoph Hellwig wrote:
> Merge these into their only callers.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 129 ++-
> 1 file changed, 60 insertions(+), 69 deletions(-)
Reviewed-by: Jason G
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason[1], and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So aft
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move code out and since we will have to change the
1 - 100 of 138 matches
Mail list logo
