Hi，
在 2024-09-01 05:53:39，"Cristian Ciocaltea"
写道：
>On 8/31/24 4:58 PM, Heiko Stübner wrote:
>> Hi,
>>
>> Am Samstag, 31. August 2024, 08:16:26 CEST schrieb Krzysztof Kozlowski:
>>> On Sat, Aug 31, 2024 at 12:55:29AM +0300, Cristian Ciocaltea wrote:
>>
+ clocks:
+minItems: 4
>>
Some EC firmwares on Trogdor/Strongbad boards don't properly indicate
the state of DP HPD on a type-c port. Instead, the EC only indicates
that a type-c port has entered or exited DP mode. To make matters worse,
on these boards the DP signal is muxed between two USB type-c
connectors, so we can't u
Most ARM based chromebooks with two usb-c-connector nodes and one DP
controller are muxing the DP lanes between the two USB ports. This is
done so that the type-c ports are at least equal in capability if not
functionality. Either an analog mux is used to steer the DP signal to
one or the other por
We can imagine that logically the EC is a device that has some number of
DisplayPort (DP) connector inputs, some number of USB3 connector inputs,
and some number of USB type-c connector outputs. If you squint enough it
looks like a USB type-c dock. Logically there's a crossbar pin
assignment capabi
Add a DT graph binding to google,cros-ec-typec so that it can combine
DisplayPort (DP) and USB SuperSpeed (SS) data into a USB type-c endpoint
that is connected to the usb-c-connector node's SS endpoint. This also
allows us to connect the DP and USB nodes in the graph to the USB type-c
connectors,
This binding is about USB type-c control. Move the binding to the usb
directory as it's a better home than chrome.
Reviewed-by: Rob Herring (Arm)
Cc: Krzysztof Kozlowski
Cc: Conor Dooley
Cc: Lee Jones
Cc: Benson Leung
Cc: Guenter Roeck
Cc: Prashant Malani
Cc: Tzung-Bi Shih
Cc:
Cc:
Cc: Pi
Extend the usb-switch binding to support DisplayPort (DP) alternate
modes. A third port for the DP signal is necessary when a mode-switch is
muxing USB and DP together onto a usb type-c connector. Add data-lanes
to the usbc output node to allow a device using this binding to remap
the data lanes on
The usage of this match function is hard to understand at a glance.
Document the arguments and the return value so it is clear how to
implement the function.
Suggested-by: Andy Shevchenko
Signed-off-by: Stephen Boyd
---
include/linux/property.h | 21 +++--
1 file changed, 19 ins
Move the usb-switch endpoint bindings to defs so that they can be reused
by other bindings. Future users of this binding will have more than one
type-c output node when they're muxing a single DP signal to more than
one usb-c-connector. Add an example to show how this binding can be used
and accele
When a single DT node has a graph connected to more than one
usb-c-connector node we can't differentiate which typec switch
registered for the device is associated with the USB connector because
the devcon matcher code assumes a 1:1 relationship between remote node
and typec switch. Furthermore, we
The previous patch added support for no-hpd to drm_dp_typec_bridge code.
Allow users of this bridge to hook the HPD notification path of the
bridge chain so that they can be made aware of the connector status
changing. This helps HPD-less users of the bridge inject the HPD state
into their code by
Add support for HPD coming from somewhere else in the drm_bridge chain.
Skip signaling HPD sate when "no-hpd" is present in the DT node backing
the dp_typec bridge.
Add this support because some EC firmwares on Trogdor/Strongbad boards
don't properly indicate the state of the DP HPD level on a typ
Register an orientation switch for each type-c output node to support
flipping the lane mapping when the port is in reverse orientation. Only
do this when the orientation-switch property is present. This is mostly
useful for the case where the DP lanes are directly connected to the
usb-c-connector
Extend the aux-hpd bridge driver to support assigning DP lanes to USB
type-c pins based on typec mux state entry. Existing users of this
driver only need the HPD signaling support, so leave that in place and
wrap the code with a variant that supports more features of USB type-c
DP altmode, i.e. pin
Simplify driver error paths by adding devm_typec_switch_register() which
will unregister the typec switch when the parent device is unbound.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Cc:
Cc: Pin-yen Lin
Signed-off-by: Stephen Boyd
---
drivers/usb/typec/mux.c | 36 +
Simplify driver error paths by adding devm_typec_mux_register() which
will unregister the typec mux when the parent device is unbound.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Cc:
Cc: Pin-yen Lin
Signed-off-by: Stephen Boyd
---
drivers/usb/typec/mux.c | 35 +++
Verify during drm_atomic_bridge_check() that the lane assignment set in
a bridge's atomic_check() callback is going to be satisfied by the
previous bridge. If the next bridge is requiring something besides the
default 1:1 lane assignment on its input then there must be an output
lane assignment on
Ease driver development by adding stubs for the typec_switch APIs when
CONFIG_TYPEC=n. Copy the same method used for the typec_mux APIs to be
consistent.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Cc:
Cc: Pin-yen Lin
Signed-off-by: Stephen Boyd
---
include/linux/usb/typec_mux.h | 43
Add support to the DRM atomic logic to support lane remapping between
bridges, encoders and connectors. Typically lane mapping is handled
statically in firmware, e.g. on DT we use the data-lanes property to
assign lanes when connecting display bridges. Lane assignment is dynamic
with USB-C DisplayP
This series adds support for fully describing the USB/DP topology on
ChromeOS Trogdor devices in DT. Trogdor devices have a single DP phy in
the AP that is muxed to one of two usb type-c connectors depending on
which port asserts HPD first to the EC. We'd like to know which port is
connected to an
On 8/31/24 9:13 AM, Krzysztof Kozlowski wrote:
> On Sat, Aug 31, 2024 at 12:55:31AM +0300, Cristian Ciocaltea wrote:
>> Rockchip RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1
>> Quad-Pixel (QP) TX controller IP.
>>
>> Since this is a new IP block, quite different from those used in the
>>
On 8/31/24 4:58 PM, Heiko Stübner wrote:
> Hi,
>
> Am Samstag, 31. August 2024, 08:16:26 CEST schrieb Krzysztof Kozlowski:
>> On Sat, Aug 31, 2024 at 12:55:29AM +0300, Cristian Ciocaltea wrote:
>
>>> + clocks:
>>> +minItems: 4
>>> +maxItems: 6
>>> +items:
>>> + - description: Pe
Dear Leonard,
I installed KDE. First, I ran it with the my regular kernel without this
patch. The first interesting thing I notice is that the screen *does*
come back after resume. (The error messages are still present though.)
Ack. Do you mean that Rob Clark also uses Yoga Slim 7x but does
Dear György,
>> Do you observe this issue on every suspend-resume cycle?
>
> I just did 10 suspend/resume cycles in a row to double check, and without
> this patch the screen never comes back (always have to switch VT
> back-and-forth to bring it back). The
>
> [dpu error]connector not connect
Dear Leonard,
Do you observe this issue on every suspend-resume cycle?
I just did 10 suspend/resume cycles in a row to double check, and
without this patch the screen never comes back (always have to switch VT
back-and-forth to bring it back). The
[dpu error]connector not connected 3
[drm:
(Resend as there was an email SPF record issue)
Dear György,
On 8/30/24 13:36, György Kurucz wrote:
> For context, I have a Lenovo Yoga Slim 7x laptop, and was having issues with
> the display staying black after sleep. As a workaround, I could switch to a
> different VT and back.
Do you obser
The parameter dev_priv is actually not used in macro PORT_ALPM_CTL
and PORT_ALPM_LFPS_CTL,so remove it to simplify the code.
Signed-off-by: He Lugang
---
drivers/gpu/drm/i915/display/intel_alpm.c | 4 ++--
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
drivers/gpu/drm/i915/display/int
Dear György,
On 8/30/24 13:36, György Kurucz wrote:
> For context, I have a Lenovo Yoga Slim 7x laptop, and was having issues with
> the display staying black after sleep. As a workaround, I could switch to a
> different VT and back.
Do you observe this issue on every suspend-resume cycle? On s
On 8/30/24 10:25 PM, Rob Clark wrote:
On Fri, Aug 30, 2024 at 8:33 AM Antonino Maniscalco
wrote:
This patch implements preemption feature for A6xx targets, this allows
the GPU to switch to a higher priority ringbuffer if one is ready. A6XX
hardware as such supports multiple levels of preemptio
Hi,
Am Samstag, 31. August 2024, 08:16:26 CEST schrieb Krzysztof Kozlowski:
> On Sat, Aug 31, 2024 at 12:55:29AM +0300, Cristian Ciocaltea wrote:
> > + clocks:
> > +minItems: 4
> > +maxItems: 6
> > +items:
> > + - description: Peripheral/APB bus clock
> > + - description: E
Hi Maintainers
It has been 2 weeks but I still haven't received a single reply on this version
of the patch series. Consider this email as a friendly reminder.
> On 17 Aug 2024, at 5:15 PM, Aditya Garg wrote:
>
> Hi Maintainers
>
> The Touch Bars found on x86 Macs support two USB configurati
When it needs to get a value within a certain interval, using clamp()
makes the code easier to understand than min(max()).
Reviewed-by: Christian König
Signed-off-by: Li Zetao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Hi,
When it needs to get the value of a certain interval [min, max],
it is easier to understand using clamp(x, min, max) instead of
min(max(x, min), max). What needs to be determined is that min
should be smaller than max.
v1 -> v2: Change the title prefix of patch 3 to drm/nouveau/volt
v1: https
When it needs to get a value within a certain interval, using clamp()
makes the code easier to understand than min(max()).
Reviewed-by: Christian König
Signed-off-by: Li Zetao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
In IS_ERR, the unlikely is used for the input parameter,
so these is no need to use it again outside.
Signed-off-by: Hongbo Li
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/
When it needs to get a value within a certain interval, using clamp()
makes the code easier to understand than min(max()).
Reviewed-by: Lyude Paul
Signed-off-by: Li Zetao
---
v1 -> v2: Change the patch title prefix to drm/nouveau/volt
v1: https://lore.kernel.org/all/20240830012216.603623-4-lizet
On 30/08/2024 17:28, Shimrra Shai wrote:
> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml
>
> b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml
> new file mode 100644
> index 0..e71544ced
> --- /dev/nul
On 30/08/2024 17:28, Shimrra Shai wrote:
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> index 78c6d5b64..8fd539125 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> +++ b/Documentation/devi
On 30/08/2024 17:28, Shimrra Shai wrote:
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi-qp.yaml
> b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi-qp.yaml
> new file mode 100644
> index 0..141899ba2
What is this? Where is proper mess
Le 31/08/2024 à 12:30, Jinjie Ruan a écrit :
Switching to memdup_user(), which combines kmalloc() and copy_from_user(),
and it can simplfy code.
Signed-off-by: Jinjie Ruan
---
drivers/gpu/drm/imagination/pvr_context.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions
On 24/07/2024 18:01, Marc Gonzalez wrote:
From: Arnaud Vrac
Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC.
This code is mostly copy & paste of the vendor code from msm-4.4
kernel.lnx.4.4.r38-rel.
Signed-off-by: Arnaud Vrac
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Ma
On Tue, 27 Aug 2024 08:54:51 -0500
Rob Herring wrote:
> +Jonathan C for the naming
>
> On Mon, Aug 26, 2024 at 7:14 PM Kuninori Morimoto
> wrote:
> >
> >
> > Hi Rob
> >
> > > > We already have of_graph_get_next_endpoint(), but it is not
> > > > intuitive to use in some case.
> > >
> > > Can
Switching to memdup_user(), which combines kmalloc() and copy_from_user(),
and it can simplfy code.
Signed-off-by: Jinjie Ruan
---
drivers/gpu/drm/imagination/pvr_context.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/imagination/pvr
Switching to memdup_user(), which combines kmalloc() and copy_from_user(),
and it can simplfy code.
Signed-off-by: Jinjie Ruan
---
drivers/gpu/drm/imagination/pvr_job.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/imagination/pvr_job.c
b/dri
Switching to memdup_user(), which combines kmalloc() and copy_from_user(),
and it can simplfy code.
Signed-off-by: Jinjie Ruan
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_contex
Hi Jassi,
Am 21.08.24 um 23:40 schrieb Stefan Wahren:
During noirq suspend phase the Raspberry Pi power driver suffer of
firmware property timeouts. The reason is that the IRQ of the underlying
BCM2835 mailbox is disabled and rpi_firmware_property_list() will always
run into a timeout [1].
Sinc
rg/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240827161223.4152195-3-claudiu.beznea%40tuxon.dev
patch subject: [PATCH 2/3] drm/bridge: microchip-lvds: Drop unused headers
config: i386-allmodconfig
(https://download.01.org/0day-ci/archive/20240831/202408311600.hvive8ju-...
On Fri, Jun 28, 2024 at 02:48:43PM GMT, Abhinav Kumar wrote:
> In preparation to register a iommu fault handler for display
> related modules, register a fault handler for the backing
> mmu object of msm_kms.
>
> Currently, the fault handler only captures the display snapshot
> but we can expand t
On Fri, 30 Aug 2024 21:43:44 +
Matthew Brost wrote:
> On Fri, Aug 30, 2024 at 10:14:18AM +0200, Christian König wrote:
> > Am 29.08.24 um 19:12 schrieb Boris Brezillon:
> > > dma_fence objects created by an entity might outlive the
> > > drm_gpu_scheduler this entity was bound to if those f
Hi Matthew,
On Fri, 30 Aug 2024 22:28:19 +
Matthew Brost wrote:
> On Fri, Aug 30, 2024 at 12:40:57PM +0200, Boris Brezillon wrote:
> > dma_fence objects created by drm_sched might hit other subsystems, which
> > means the fence object might potentially outlive the drm_sched module
> > lifeti
50 matches
Mail list logo
