On Thu, Jun 9, 2022 at 3:27 PM Hsin-Yi Wang wrote:
>
> Panels usually call drm_connector_set_panel_orientation(), which is
> later than drm/kms driver calling drm_dev_register(). This leads to a
> WARN()[1].
>
> The orientation property is known earlier. For example, some panels
> parse the
If the component driver fails to bind, or is unbound, the driver data
for the top-level platform device points to a freed drm_device. If the
system is then suspended, the driver passes this dangling pointer to
drm_mode_config_helper_suspend(), which crashes.
Fix this by only setting the driver
Now that the PHY ops are separated, sort them topologically, with the
common sun8i_hdmi_phy_set_polarity helper at the top. No function
contents are changed in this commit.
Signed-off-by: Samuel Holland
---
(no changes since v1)
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 67
The D1 SoC comes with a new custom HDMI PHY, which does not share any
registers with the existing custom PHY. So it needs a new set of ops.
Instead of providing a flag in the variant structure, provide the ops
themselves.
Signed-off-by: Samuel Holland
---
(no changes since v1)
Since the driver already needs to support multiple sets of ops, we can
drop the mid-layer used by the A83T and H3 PHYs. They share only a small
amount of code; factor this out as sun8i_hdmi_phy_set_polarity.
For clarity, this commit keeps the existing function order.
Signed-off-by: Samuel
Now that the HDMI PHY is using a platform driver, it can use device-
managed resources. Use these, as well as the dev_err_probe helper, to
simplify the probe function and get rid of the remove function.
Signed-off-by: Samuel Holland
---
Changes in v2:
- Move error handling inside variant
The struct resource is not used for anything else, so we can simplify
the code a bit by using the helper function.
Signed-off-by: Samuel Holland
---
(no changes since v1)
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
Now that the HDMI PHY is using a platform driver, we can use the usual
helper function for getting the variant structure.
Signed-off-by: Samuel Holland
---
(no changes since v1)
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 11 ++-
2 files
This series prepares the sun8i HDMI PHY driver for supporting the new
custom PHY in the Allwinner D1 SoC. No functional change intended here.
This series was tested on D1, H3, and H6.
Changes in v2:
- Move error handling inside variant checks in probe function
Samuel Holland (6):
drm/sun4i:
[Public]
> -Original Message-
> From: Lyude Paul
> Sent: Wednesday, June 8, 2022 3:29 AM
> To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Cc: Lin, Wayne ; Ville Syrjälä
> ; Zuo, Jerry ; Jani Nikula
> ; Imre Deak ; Daniel Vetter
>
[Public]
Thank you Lyude for addressing this!
VCPI is also a confusing naming to me at first glance since it stands for
Virtual Channel Payload Identification which is just an ID number ( we can
look up these payload IDs In DPCD 0x2C1 ~0x2FF).
I also look up left VCPI terms in rest of the
On Tue, 2022-06-14 at 14:11 -0600, Rob Herring wrote:
> On Sat, Jun 11, 2022 at 10:14:12PM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp display pixel link.
> >
> > Signed-off-by: Liu Ying
> > ---
> > v8->v9:
> > * Add 'fsl,dc-id' and 'fsl,dc-stream-id' properties.
Hi Christian,
Friendly ping on the comments here. Are you okay with me re-spinning
the series with a fixed patch 1 or do we need further discussion on
the approach here?
Thanks,
Bas
On Mon, Jun 6, 2022 at 1:00 PM Bas Nieuwenhuizen
wrote:
>
> On Mon, Jun 6, 2022 at 12:35 PM Christian König
>
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] -- unicast read from any non-terminated
instance
*
Multicast/replicated (MCR) registers on Intel hardware are a purely
GT-specific concept. Rather than leaving MCR register handling spread
across several places throughout the driver (intel_uncore.c, intel_gt.c,
etc.) with confusing combinations of handler functions living in
different namespaces,
Handling of multicast/replicated registers is spread across intel_gt.c
and intel_uncore.c today. As multicast handling and the related
steering logic gets more complicated with the addition of new platforms
and new rules it makes sense to centralize it all in one place.
For now the existing
This is an SMMU for the adreno gpu, and adding this compatible lets
the driver use per-fd page tables, which are required for security
between GPU clients.
Signed-off-by: Emma Anholt
---
Tested with a full deqp-vk run on RB5, which did involve some iommu faults.
Required for turning on per-process page tables for the GPU.
Signed-off-by: Emma Anholt
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index
On 6/14/2022 2:59 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-06-14 14:05:02)
Display resolution change is implemented through drm modeset. Older
modeset (resolution) has to be disabled first before newer modeset
(resolution) can be enabled. Display disable will turn off both
pixel
On 6/14/2022 2:59 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-06-14 14:05:02)
Display resolution change is implemented through drm modeset. Older
modeset (resolution) has to be disabled first before newer modeset
(resolution) can be enabled. Display disable will turn off both
pixel
Quoting Kuogee Hsieh (2022-06-14 14:05:02)
> Display resolution change is implemented through drm modeset. Older
> modeset (resolution) has to be disabled first before newer modeset
> (resolution) can be enabled. Display disable will turn off both
> pixel clock and main link clock so that main
Hi,
On Thu, Jun 2, 2022 at 8:12 AM Dmitry Baryshkov
wrote:
>
> On 18/04/2022 20:17, Douglas Anderson wrote:
> > Let's add support for being able to read the HPD pin even if it's
> > hooked directly to the controller. This will allow us to get more
> > accurate delays also lets us take away the
This implements the callback added by the patch ("drm/dp: Add
wait_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use wait_hpd_asserted(), we no longer need to have an long delay in
the AUX transfer function. It's up to the
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will let us take away the
waiting in the AUX transfer functions of the eDP controller drivers.
Signed-off-by: Douglas Anderson
---
Changes in v4:
- Reorganized logic as per Dmitry's
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will allow us to get more
accurate delays also lets us take away the waiting in the AUX transfer
functions of the eDP controller drivers.
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry
This is the 2nd four patches from my RFC series ("drm/dp: Improvements
for DP AUX channel") [1]. I've broken the series in two so we can make
progress on the two halves separately.
v2 of this series changes to add wait_hpd_asserted() instead of
is_hpd_asserted(). This allows us to move the extra
Sometimes it's useful for users of the DP AUX bus (like panels) to be
able to poll HPD. Let's add a callback that allows DP AUX busses
drivers to provide this.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
---
Changes in v4:
- Comments now
Thanks,
Oak
> -Original Message-
> From: dri-devel On Behalf Of
> Zeng, Oak
> Sent: June 14, 2022 5:13 PM
> To: Vishwanathapura, Niranjana ;
> Landwerlin, Lionel G
> Cc: Intel GFX ; Wilson, Chris P
> ; Hellstrom, Thomas
> ; Maling list - DRI developers de...@lists.freedesktop.org>;
Add support for writing CRC values for the interface block to
the debugfs by calling the necessary MISR setup/collect methods.
Changes since V1:
- Set values_cnt to only include phys with backing hw_intf
- Loop over all drm_encs connected to crtc
Signed-off-by: Jessica Zhang
---
Add support for setting MISR registers within the interface
Changes since V1:
- Replaced dpu_hw_intf collect_misr and setup_misr implementations with
calls to dpu_hw_utils helper methods
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 19 ++-
Refactor existing CRC code for layer mixer and add CRC support for interface
blocks
Changes since V1:
- Create helper methods for collect_misr and setup_misr in dpu_hw_util.c
- Move common bitmasks into dpu_hw_util.h
- Update copyrights
- Create a dynamically allocated crcs array in
Move layer mixer-specific section of dpu_crtc_get_crc() into a separate
helper method. This way, we can make it easier to get CRCs from other HW
blocks by adding other get_crc helper methods.
Changes since V1:
- Moved common bitmasks to dpu_hw_util.h
- Moved common CRC methods to dpu_hw_util.c
-
Thanks,
Oak
> -Original Message-
> From: Vishwanathapura, Niranjana
> Sent: June 14, 2022 1:02 PM
> To: Landwerlin, Lionel G
> Cc: Zeng, Oak ; Intel GFX g...@lists.freedesktop.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Hellstrom, Thomas
> ; Wilson, Chris P ;
>
On 2022-06-14 14:48, Thomas Zimmermann wrote:
Hi
Am 14.06.22 um 15:04 schrieb Robin Murphy:
The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0
for some time now, which works nicely as an early framebuffer. However,
once the HDLCD driver probes and takes over the hardware,
Display resolution change is implemented through drm modeset. Older
modeset (resolution) has to be disabled first before newer modeset
(resolution) can be enabled. Display disable will turn off both
pixel clock and main link clock so that main link have to be
re-trained during display enable to
On 14/06/2022 12:34, Prashant Malani wrote:
> Analogix 7625 can be used in systems to switch USB Type-C DisplayPort
> alternate mode lane traffic between 2 Type-C ports.
>
> Update the binding to accommodate this usage by introducing a switch
> property.
>
> Reviewed-by: Nícolas F. R. A. Prado
On 6/14/2022 1:38 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-06-13 14:48:37)
During display resolution changes display have to be disabled first
followed by display enabling with new resolution. Display disable
will turn off both pixel clock and main link clock so that main link
have
On Mon, Jun 13, 2022 at 02:48:30PM +0800, Bo-Chen Chen wrote:
> From: Markus Schneider-Pargmann
>
> DP_INTF is similar to DPI but does not have the exact same feature set
> or register layouts.
>
> DP_INTF is the sink of the display pipeline that is connected to the
> DisplayPort controller and
On Fri, Jun 10, 2022 at 06:55:13PM +0800, Bo-Chen Chen wrote:
> From: Markus Schneider-Pargmann
>
> This controller is present on several mediatek hardware. Currently
> mt8195 and mt8395 have this controller without a functional difference,
> so only one compatible field is added.
>
> The
On Sat, Jun 11, 2022 at 10:14:12PM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qm/qxp display pixel link.
>
> Signed-off-by: Liu Ying
> ---
> v8->v9:
> * Add 'fsl,dc-id' and 'fsl,dc-stream-id' properties. (Laurent)
Why? Isn't the graph sufficient for determining the connections?
On Tue, 14 Jun 2022 09:28:14 -0700, Dixit, Ashutosh wrote:
> On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>
> > @@ -481,12 +481,14 @@ static int wait_for_ct_request_update(struct
> > ct_request *req, u32 *status)
> > #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
> > #define
From: Pin-Yen Lin
Add the callback function when the driver receives state
changes of the Type-C port. The callback function configures the
crosspoint switch of the anx7625 bridge chip, which can change the
output pins of the signals according to the port state.
Reviewed-by: Nícolas F. R. A.
When the DT node has "switches" available, register a Type-C mode-switch
for each listed "switch". This allows the driver to receive state
information about what operating mode a Type-C port and its connected
peripherals are in, as well as status information (like VDOs) related to
that state.
The
Parse the "switches" node, if available, and count and store the number
of Type-C switches within it. Since we currently don't do anything with
this info, no functional changes are expected from this change.
This patch sets a foundation for the actual registering of Type-C
switches with the
Analogix 7625 can be used in systems to switch USB Type-C DisplayPort
alternate mode lane traffic between 2 Type-C ports.
Update the binding to accommodate this usage by introducing a switch
property.
Reviewed-by: Nícolas F. R. A. Prado
Tested-by: Nícolas F. R. A. Prado
Signed-off-by: Prashant
Introduce a binding which represents a component that can control the
routing of USB Type-C data lines as well as address data line
orientation (based on CC lines' orientation).
Reviewed-by: Nícolas F. R. A. Prado
Tested-by: Nícolas F. R. A. Prado
Signed-off-by: Prashant Malani
---
Changes
There are some drivers that can use the Type C mux API, but don't have
to. Introduce CONFIG guards for the mux functions so that drivers can
include the header file and not run into compilation errors on systems
which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
the Type C
Loosen the typec_mux_match() requirements so that searches where an
alt mode is not specified, but the target mux device lists the
"mode-switch" property, return a success.
This is helpful in Type C port drivers which would like to get a pointer
to the mux switch associated with a Type C port,
This series introduces a binding for Type-C data lane switches. These
control the routing and operating modes of USB Type-C data lanes based
on the PD messaging from the Type-C port driver regarding connected
peripherals.
The first patch introduces a change to the Type-C mux class mode-switch
Remove the hard-coded limit for writeback and lets start using
the one from catalog instead.
Fixes: d7d0e73f7de3 ("introduce the dpu_encoder_phys_* for writeback")
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 6 ++
1 file changed, 2 insertions(+), 4
Writeback block for sm8250 was using the default maxlinewidth
of 2048. But this is not right as it supports upto 4096.
This should have no effect on most resolutions as we are
still limiting upto maxlinewidth of SSPP for adding the modes.
Fix the maxlinewidth for writeback block on sm8250.
intf and wb resources are not dependent on the rm global
state so need not be allocated during dpu_encoder_virt_atomic_mode_set().
Move the allocation of intf and wb resources to dpu_encoder_setup_display()
so that we can utilize the hw caps even during atomic_check() phase.
Since
On Thu, Jun 09, 2022 at 06:24:43AM +0200, Gerd Hoffmann wrote:
> On Fri, Jun 03, 2022 at 02:18:49PM -0700, Dongwon Kim wrote:
> > Having one fence for a vgfb would cause conflict in case there are
> > multiple planes referencing the same vgfb (e.g. Xorg screen covering
> > two displays in extended
Do not use reserved requests for virtual engines as this is only
needed for kernel contexts.
Signed-off-by: Ramalingam C
Suggested-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_request.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
From: Niranjana Vishwanathapura
This reverts commit 1e98d8c52ed5dfbaf273c4423c636525c2ce59e7.
The problem with this patch is that it makes i915_request to hold a
reference to intel_context, which in turn holds a reference on the VM.
This strong back referencing can lead to reference loops which
Thanks for all comments, I will update code and prepare for next version.
Regards,
Zhanjun
-Original Message-
From: Dixit, Ashutosh
Sent: June 14, 2022 12:28 PM
To: Dong, Zhanjun
Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Teres
Alexis, Alan Previn ;
From: Niranjana Vishwanathapura
In i915_fence_get_driver_name(), user may not hold a
reference to rq->engine. Hence do not access it. Instead,
store required device private pointer in 'rq->i915' and use it.
Signed-off-by: Niranjana Vishwanathapura
Suggested-by: Matthew Brost
---
The i915_request holds a reference to intel_context, which in
turn holds a reference on the VM. But the dma-resv update for
VM_BIND feature would require VM hold a reference to the
i915_request through dma-resv fences of VM_PRIVATE objects
(which share a per VM dma-resv object).
Thus, we have a
On 6/14/22 20:09, José Expósito wrote:
> Hi Javier,
>
> On Tue, Jun 14, 2022 at 02:58:29PM +0200, Javier Martinez Canillas wrote:
>> Hello José,
>>
>> On 6/13/22 19:17, José Expósito wrote:
>>
>> [snip]
>>
>>> +KUnit (Kernel unit testing framework) provides a common framework for unit
>>> tests
On Tue, Jun 14, 2022 at 1:22 AM AngeloGioacchino Del Regno
wrote:
>
> Il 09/06/22 20:09, Prashant Malani ha scritto:
> > Parse the "switches" node, if available, and count and store the number
> > of Type-C switches within it. Since we currently don't do anything with
> > this info, no functional
Hi Javier,
On Tue, Jun 14, 2022 at 02:58:29PM +0200, Javier Martinez Canillas wrote:
> Hello José,
>
> On 6/13/22 19:17, José Expósito wrote:
>
> [snip]
>
> > +KUnit (Kernel unit testing framework) provides a common framework for unit
> > tests
> > +within the Linux kernel.
> > +
>
> I think
On 6/14/22 10:45, Harry Wentland wrote:
> On 2022-06-14 11:57, Randy Dunlap wrote:
>> Fix build error when CONFIG_DEBUG_FS is not enabled by adding a
>> stub function for crtc_debugfs_init().
>>
>> Eliminates this build error:
>>
>>
On 2022-06-14 11:57, Randy Dunlap wrote:
> Fix build error when CONFIG_DEBUG_FS is not enabled by adding a
> stub function for crtc_debugfs_init().
>
> Eliminates this build error:
>
> ../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> ‘amdgpu_dm_crtc_late_register’:
Le lundi 13 juin 2022 à 16:10 -0400, Nicolas Dufresne a écrit :
> Le jeudi 12 mai 2022 à 11:46 +0800, Yunfei Dong a écrit :
> > Firstly, add mt8186 compatible and private data, then add document for
> > compatible "mediatek,mt8186-vcodec-dec". For mt8186 is single core
> > architecture, need to
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> The current code uses a device-managed function to retrieve the next bridge
> downstream.
>
> However, that means that it will be removed at unbind time, where the DRM
> device is still very much live and might still have some applications
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> The current code will call drm_encoder_cleanup() when the device is
> unbound. However, by then, there might still be some references held to
> that encoder, including by the userspace that might still have the DRM
> device open.
>
> Let's
On Tue, Jun 14, 2022 at 10:04:00AM +0300, Lionel Landwerlin wrote:
On 13/06/2022 21:02, Niranjana Vishwanathapura wrote:
On Mon, Jun 13, 2022 at 06:33:07AM -0700, Zeng, Oak wrote:
Regards,
Oak
-Original Message-
From: Intel-gfx On
Behalf Of Niranjana
Vishwanathapura
Sent: June
On Tue, 14 Jun 2022 at 16:11, Dave Stevenson
wrote:
>
> Hi Maxime
>
> On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
> >
> > Whenever the device and driver are unbound, the main device and all the
> > subdevices will be removed by calling their unbind() method.
> >
> > However, the DRM
On Tue, Jun 14, 2022 at 2:08 AM Pin-yen Lin wrote:
>
> Hi AngeloGioacchino,
>
>
> On Tue, Jun 14, 2022 at 4:15 PM AngeloGioacchino Del Regno
> wrote:
> >
> > Il 09/06/22 20:09, Prashant Malani ha scritto:
> > > From: Pin-Yen Lin
> > >
> > > Add the callback function when the driver receives
On Tue, Jun 14, 2022 at 1:18 AM AngeloGioacchino Del Regno
wrote:
>
> Il 09/06/22 20:09, Prashant Malani ha scritto:
> > When the DT node has "switches" available, register a Type-C mode-switch
> > for each listed "switch". This allows the driver to receive state
> > information about what
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Our current code now mixes some resources whose lifetime are tied to the
> device (clocks, IO mappings, etc.) and some that are tied to the DRM device
> (encoder, bridge).
>
> The device one will be freed at unbind time, but the DRM one will
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> The current code uses a device-managed function to retrieve the next bridge
> downstream.
>
> However, that means that it will be removed at unbind time, where the DRM
> device is still very much live and might still have some applications
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> The current code will call drm_encoder_cleanup() when the device is
> unbound. However, by then, there might still be some references held to
> that encoder, including by the userspace that might still have the DRM
> device open.
>
> Let's
Hi Maxime.
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Adding a device-managed action will make the error path easier, so let's
> create one to disable our clock.
The DPI block has two clocks (core and pixel), and this is only
affecting one of them (the core clock).
(I'm actually
On Tue, Jun 14, 2022 at 05:07:37PM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 17:02, Tvrtko Ursulin wrote:
On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 00:39, Matthew Brost wrote:
On Mon, Jun 13, 2022
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Since we have a managed call to create our panel_bridge instance, the call
> to drm_of_panel_bridge_remove() at unbind is both redundant and dangerous
> since it might lead to a use-after-free.
>
> Signed-off-by: Maxime Ripard
Reviewed-by:
On 6/14/2022 3:09 AM, Dmitry Baryshkov wrote:
On 14/06/2022 13:07, Miaoqian Lin wrote:
Hi, Abhinav
On 2022/6/11 7:20, Abhinav Kumar wrote:
On 6/7/2022 4:08 AM, Miaoqian Lin wrote:
of_graph_get_remote_node() returns remote device node pointer with
refcount incremented, we should use
On Thu, 02 Jun 2022 10:21:19 -0700, Zhanjun Dong wrote:
>
Hi Zhanjun,
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be
On Thu, 02 Jun 2022, Zhanjun Dong wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
>
> This patch will handle
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> If we fail to enable the DPI clock, we just ignore the error and moves
> forward. Let's return an error instead.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 -
> 1 file
On Tue, Jun 14, 2022 at 09:27:05AM +0300, Lionel Landwerlin wrote:
On 10/06/2022 11:53, Matthew Brost wrote:
On Fri, Jun 10, 2022 at 12:07:11AM -0700, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
Signed-off-by: Niranjana Vishwanathapura
---
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> The current code will call drm_crtc_cleanup() when the device is
> unbound. However, by then, there might still be some references held to
> that CRTC, including by the userspace that might still have the DRM
> device open.
>
> Let's switch
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Our internal structure that stores the DRM entities structure is allocated
> through a device-managed kzalloc.
>
> This means that this will eventually be freed whenever the device is
> removed. In our case, the most like source of removal is
On 02.06.2022 19:21, Zhanjun Dong wrote:
> We are seeing error message of "No response for request". Some cases happened
> while waiting for response and reset/suspend action was triggered. In this
> case, no response is not an error, active requests will be cancelled.
>
> This patch will
On 14/06/2022 17:02, Tvrtko Ursulin wrote:
On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 00:39, Matthew Brost wrote:
On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:
On 13/06/2022 18:49,
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> The VC4 DPI driver private structure contains only a pointer to the
> encoder it implements. This makes the overall structure somewhat
> inconsistent with the rest of the driver, and complicates its
> initialisation without any apparent gain.
On 14/06/2022 16:43, Niranjana Vishwanathapura wrote:
On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 00:39, Matthew Brost wrote:
On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:
On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:
On Mon,
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> There's no user for that pointer so let's just get rid of it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_dpi.c | 7 ---
> drivers/gpu/drm/vc4/vc4_drv.h | 1 -
> 2 files changed, 8
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> All the CRTCs, including the TXP, have a debugfs file and name so we can
> consolidate it into vc4_crtc_data.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
I was sort of expecting the vc4_debugfs_add_regset32 call to move
Fix build error when CONFIG_DEBUG_FS is not enabled by adding a
stub function for crtc_debugfs_init().
Eliminates this build error:
../drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
‘amdgpu_dm_crtc_late_register’:
Dne torek, 14. junij 2022 ob 09:31:00 CEST je Samuel Holland napisal(a):
> commit 6de79dd3a920 ("drm/bridge: display-connector: add ddc-en gpio
> support") added a consumer for this GPIO in the HDMI connector device.
> This new consumer conflicts with the pre-existing GPIO consumer in the
> sun8i
On Tue, Jun 14, 2022 at 08:16:41AM +0100, Tvrtko Ursulin wrote:
On 14/06/2022 00:39, Matthew Brost wrote:
On Mon, Jun 13, 2022 at 07:09:06PM +0100, Tvrtko Ursulin wrote:
On 13/06/2022 18:49, Niranjana Vishwanathapura wrote:
On Mon, Jun 13, 2022 at 05:22:02PM +0100, Tvrtko Ursulin wrote:
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Our internal structure that stores the DRM entities structure is allocated
> through a device-managed kzalloc.
>
> This means that this will eventually be freed whenever the device is
> removed. In our case, the most like source of removal is
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Let's switch to drmm_universal_plane_alloc() for our plane allocation and
> initialisation to make the driver a bit simpler.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 12
On Mon, 13 Jun 2022 at 23:49, Rob Clark wrote:
>
> From: Rob Clark
>
> Misc small cleanup I noticed. Not called from another object file since
> 3c9edd9c85f5 ("drm/msm: Introduce GEM object funcs")
>
> Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
> ---
>
Can't see anything wrong with this.
I consider this only a NIT, so feel : not sure if -ECANCELLED is reflective of
the "ct service being temporarily down"
as opposed to the "requester cancelling". Perhaps a -EPIPE or -EAGAIN (if we
got this far, we know we are probably mid-
reset) ?? (if not
On 6/14/2022 1:38 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-06-13 14:48:37)
During display resolution changes display have to be disabled first
followed by display enabling with new resolution. Display disable
will turn off both pixel clock and main link clock so that main link
have
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> vc4_plane_init() currently initialises the plane with no possible CRTCs,
> and will expect the caller to set it up by itself.
>
> Let's change that logic a bit to follow the syntax of
> drm_universal_plane_init() and pass the possible CRTCs
Hi Maxime
On Fri, 10 Jun 2022 at 10:30, Maxime Ripard wrote:
>
> Whenever the device and driver are unbound, the main device and all the
> subdevices will be removed by calling their unbind() method.
>
> However, the DRM device itself will only be freed when the last user will
> have closed it.
On 10.06.2022 20:37, Ville Syrjälä wrote:
On Fri, Jun 10, 2022 at 06:00:24PM +0200, Andrzej Hajda wrote:
Handling HPD during driver removal is pointless, and can cause different
use-after-free/concurrency issues:
1. Setup of deferred fbdev after fbdev unregistration.
2. Access to DP-AUX after
1 - 100 of 169 matches
Mail list logo
