DRM_AUX_HPD_BRIDGE")
> Signed-off-by: Nathan Chancellor
Shouldn't DRM_BRIDGE depend on/select OF instead?
Reviewed-by: Heikki Krogerus
> ---
> drivers/usb/typec/tcpm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/tcpm/Kconfig
[=y]=n) && DRM_BRIDGE [=y]
>
> Only select CONFIG_DRM_AUX_BRIDGE with both CONFIG_DRM_BRIDGE and
> CONFIG_OF to clear up the warning.
>
> Fixes: c5d296bad640 ("usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE")
> Signed-off-by: Nathan Chancellor
Reviewed-by
I'm sorry, I've completely missed this second typec patch.
Reviewed-by: Heikki Krogerus
> ---
> drivers/usb/typec/tcpm/Kconfig| 1 +
> drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 41 +++
> 2 files changed, 7 insertions(+), 35 deletions(-)
>
> di
On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> On 15 September 2023 15:14:35 EEST, Heikki Krogerus
> wrote:
> >Hi Dmitry,
> >
> >On Mon, Sep 04, 2023 at 12:41:50AM +0300, Dmitry Baryshkov wrote:
> >> In order to notify the userspace abo
Hi Dmitry,
On Mon, Sep 04, 2023 at 12:41:50AM +0300, Dmitry Baryshkov wrote:
> In order to notify the userspace about the DRM connector's USB-C port,
> export the corresponding port's name as the bridge's path field.
>
> Signed-off-by: Dmitry Baryshkov
> ---
>
Hi guys,
On Thu, Sep 14, 2023 at 01:40:49PM +0300, Dmitry Baryshkov wrote:
> On Thu, 14 Sept 2023 at 12:26, Heikki Krogerus
> wrote:
> >
> > Hi Dmitry,
> >
> > On Wed, Sep 13, 2023 at 04:47:12PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, 13 Sept 2023
Hi Dmitry,
On Wed, Sep 13, 2023 at 04:47:12PM +0300, Dmitry Baryshkov wrote:
> On Wed, 13 Sept 2023 at 16:15, Heikki Krogerus
> wrote:
> >
> > On Wed, Sep 13, 2023 at 01:26:14PM +0300, Dmitry Baryshkov wrote:
> > > Hi Heikki,
> > >
> > > O
On Wed, Sep 13, 2023 at 01:26:14PM +0300, Dmitry Baryshkov wrote:
> Hi Heikki,
>
> On Wed, 13 Sept 2023 at 12:27, Heikki Krogerus
> wrote:
> > On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> > > On 12/09/2023 14:05, Heikki Krogerus wrote:
> >
Hi Neil,
On Wed, Sep 13, 2023 at 11:38:19AM +0200, Neil Armstrong wrote:
> On new platforms (starting from SM8450) UCSI is mandatory to have
> pmic_glink_altmode events triggering.
You can also populate the typec devices conditionally, only if UCSI is
not supported.
However, I took a peek at
Hi Dmitry,
On Tue, Sep 12, 2023 at 08:39:45PM +0300, Dmitry Baryshkov wrote:
> On 12/09/2023 14:05, Heikki Krogerus wrote:
> > On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
> > > On 06/09/2023 16:38, Heikki Krogerus wrote:
> > > > On Wed, Se
On Tue, Sep 12, 2023 at 12:15:10AM +0300, Dmitry Baryshkov wrote:
> On 06/09/2023 16:38, Heikki Krogerus wrote:
> > On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
> > > wrote:
> > > >
On Wed, Sep 06, 2023 at 03:48:35PM +0300, Dmitry Baryshkov wrote:
> On Wed, 6 Sept 2023 at 15:44, Heikki Krogerus
> wrote:
> >
> > On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry Baryshkov wrote:
> > > Hi Heikki,
> > >
> > > On Tue, 5 Sep
On Tue, Sep 05, 2023 at 01:56:59PM +0300, Dmitry Baryshkov wrote:
> Hi Heikki,
>
> On Tue, 5 Sept 2023 at 11:50, Heikki Krogerus
> wrote:
> >
> > Hi Dmitry,
> >
> > On Mon, Sep 04, 2023 at 12:41:39AM +0300, Dmitry Baryshkov wrote:
> &g
Hi Dmitry,
On Mon, Sep 04, 2023 at 12:41:39AM +0300, Dmitry Baryshkov wrote:
> The kdev->fwnode pointer is never set in drm_sysfs_connector_add(), so
> dev_fwnode() checks never succeed, making the respective commit NOP.
That's not true. The dev->fwnode is assigned when the device is
created on
On Wed, Aug 02, 2023 at 04:18:45AM +0300, Dmitry Baryshkov wrote:
> Switch to using the new DRM_SIMPLE_BRIDGE helper to create the
> transparent DRM bridge device instead of handcoding corresponding
> functionality.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by:
On Mon, May 22, 2023 at 02:53:48PM -0700, Bjorn Andersson wrote:
> On Mon, May 22, 2023 at 03:51:01PM -0500, Bjorn Andersson wrote:
> > On Fri, Oct 08, 2021 at 03:38:21PM +0300, Heikki Krogerus wrote:
> > > Hi,
> > >
> > > On Thu, Oct 07, 2021 at 09:
; Signed-off-by: Pin-yen Lin
Reviewed-by: Heikki Krogerus
> ---
>
> Changes in v13:
> - Update the kernel doc of fwnode_connection_find_match
>
> Changes in v12:
> - Check the availability of the device node in fwnode_graph_devcon_matches
> - Ensured valid
Hi,
On Thu, Jan 12, 2023 at 12:20:58PM +0800, Pin-yen Lin wrote:
> Add helpers to register and unregister Type-C "switches" for bridges
> capable of switching their output between two downstream devices.
>
> The helper registers USB Type-C mode switches when the "mode-switch"
> and the
all the usb-c-connector nodes' absent suppliers. This eliminates
> the connector as a supplier for a switch and allows it to be probed.
>
> Signed-off-by: Prashant Malani
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Chen-Yu Tsai
FWIW:
Acked-by: Heikki Krogerus
Signed-off-by: Pin-yen Lin
> Reviewed-by: Chen-Yu Tsai
> Tested-by: Chen-Yu Tsai
Acked-by: Heikki Krogerus
> ---
>
> Changes in v10:
> - Collected Reviewed-by and Tested-by tags
>
> Changes in v6:
> - New in v6
>
> drivers/base/property.c | 15 ++
o
>
> Reviewed-by: Guenter Roeck
> Signed-off-by: ChiYuan Huang
> Signed-off-by: ChiaEn Wu
Reviewed-by: Heikki Krogerus
> ---
>
> v7
> - Revise 'devm_add_action_or_reset(dev, ...)' to one line
> - Revise 'return regmap_update_bits(...)' with using positi
@@ static int ucsi_ccg_remove(struct i2c_client *client)
> ucsi_unregister(uc->ucsi);
> ucsi_destroy(uc->ucsi);
> free_irq(uc->irq, uc);
> -
> - return 0;
> }
>
> static const struct i2c_device_id ucsi_ccg_device_id[] = {
> diff --git a/drivers/usb/typec/wusb3801.c b/drivers/usb/typec/wusb3801.c
> index e63509f8b01e..3cc7a15ecbd3 100644
> --- a/drivers/usb/typec/wusb3801.c
> +++ b/drivers/usb/typec/wusb3801.c
> @@ -399,7 +399,7 @@ static int wusb3801_probe(struct i2c_client *client)
> return ret;
> }
>
> -static int wusb3801_remove(struct i2c_client *client)
> +static void wusb3801_remove(struct i2c_client *client)
> {
> struct wusb3801 *wusb3801 = i2c_get_clientdata(client);
>
> @@ -411,8 +411,6 @@ static int wusb3801_remove(struct i2c_client *client)
>
> if (wusb3801->vbus_on)
> regulator_disable(wusb3801->vbus_supply);
> -
> - return 0;
> }
Reviewed-by: Heikki Krogerus
--
heikki
which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
> the Type C mux functions will be stub versions of the original calls.
>
> Reported-by: kernel test robot
> Reviewed-by: Nícolas F. R. A. Prado
> Tested-by: Nícolas F. R. A. Prado
> Signed-off-by: Prashan
Hi,
On Thu, Jun 09, 2022 at 06:09:41PM +, Prashant Malani wrote:
> 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
Type C port drivers which would like to get a pointer
> to the mux switch associated with a Type C port, but don't want to
> specify a particular alt mode.
>
> Signed-off-by: Prashant Malani
Reviewed-by: Heikki Krogerus
> ---
>
> Changes since v1:
> - No changes.
>
>
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
> state.
>
> Also push the test for unchanged state in the displayport altmode driver
> into the i915 driver, to allow other drivers to act upon each update.
>
> Signed-off-by: Bjorn Andersson
Acked-by: Heikki Kr
+Hans
Hans, do you have any comments?
On Mon, May 02, 2022 at 09:53:13AM -0700, Bjorn Andersson wrote:
> In some implementations, such as the Qualcomm platforms, the display
> driver has no way to query the current HPD state and as such it's
> impossible to distinguish between disconnect and
On Wed, Feb 09, 2022 at 04:51:44PM +0300, Pavel Skripkin wrote:
> Hi Heikki,
>
> On 2/9/22 16:42, Heikki Krogerus wrote:
> > On Tue, Feb 08, 2022 at 02:37:10AM -0800, syzbot wrote:
> > > syzbot has bisected this issue to:
> > >
> > > commit 8c67d06f3fd
On Tue, Feb 08, 2022 at 02:37:10AM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 8c67d06f3fd9639c44d8147483fb1c132d71388f
> Author: Heikki Krogerus
> Date: Thu Dec 23 08:23:49 2021 +
>
> usb: Link the ports to the connectors they are attac
+Hans and Imre
On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
> > On Wed, Oct 06, 2021 at 01:26:35PM -0700, Prashant Malani wrote:
> > > (CC+ Heikki)
> [..]
> > > On Wed, Oct 6, 2021 at 8:19
Hi,
On Thu, Oct 07, 2021 at 09:15:12AM -0700, Bjorn Andersson wrote:
> The one thing that I still don't understand though is, if the typec_mux
> is used by the typec controller to inform _the_ mux about the function
> to be used, what's up with the complexity in typec_mux_match()? This is
> what
Hi guys,
On Wed, Oct 06, 2021 at 01:26:35PM -0700, Prashant Malani wrote:
> (CC+ Heikki)
>
> Hi,
>
> On Wed, Oct 6, 2021 at 8:19 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Oct 5, 2021 at 7:27 PM Bjorn Andersson
> > wrote:
> > >
> > > > > For reference, this is how I thought one is
On Tue, May 11, 2021 at 10:05:26AM +0300, Heikki Krogerus wrote:
> On Wed, May 05, 2021 at 06:24:07PM +0200, Hans de Goede wrote:
> > Hi All,
> >
> > Here is v3 of my patchset making DP over Type-C work on devices where the
> > Type-C controller does not drive the HPD
On Wed, May 05, 2021 at 06:24:07PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v3 of my patchset making DP over Type-C work on devices where the
> Type-C controller does not drive the HPD pin on the GPU, but instead
> we need to forward HPD events from the Type-C controller to the DRM
On Wed, May 05, 2021 at 06:24:15PM +0200, Hans de Goede wrote:
> Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
> drivers know about DisplayPort over Type-C hotplug events.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
> ---
> Chang
On Wed, May 05, 2021 at 06:24:14PM +0200, Hans de Goede wrote:
> Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
> rather then having separate code-paths for this in various places
> which call it.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
Hi Hans,
On Mon, May 03, 2021 at 05:46:46PM +0200, Hans de Goede wrote:
> Use the new drm_connector_find_by_fwnode() and
> drm_connector_oob_hotplug_event() functions to let drm/kms drivers
> know about DisplayPort over Type-C hotplug events.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in
On Tue, May 04, 2021 at 05:35:49PM +0200, Hans de Goede wrote:
> Hi,
>
> On 5/4/21 5:10 PM, Heikki Krogerus wrote:
> >> +/**
> >> + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to
> >> connector
> >> + * @connector: connecto
uded in the event send to the DRM-subsystem, specifically sending
> the following info was requested:
>
> 1. Which DP connector on the GPU the event is for
> 2. How many lanes are available
> 3. Connector orientation
>
> This series is basically an entirely new approach, whic
> +/**
> + * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to
> connector
> + * @connector: connector to report the event on
> + * @data: data related to the event
> + *
> + * On some hardware a hotplug event notification may come from outside the
> display
> + * driver /
Hi Andy,
> > +/* NOTE: The connector order must be final before this is called. */
> > +void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915)
> > +{
> > + struct drm_connector_list_iter conn_iter;
> > + struct drm_device *drm_dev = >drm;
> > + struct device
On Mon, May 03, 2021 at 04:35:29PM +0200, Hans de Goede wrote:
> Hi,
>
> On 5/3/21 10:00 AM, Heikki Krogerus wrote:
> > Hi Hans,
> >
> > On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote:
> >> +/**
> >> + * struct drm_connector_o
Hi Hans,
On Wed, Apr 28, 2021 at 11:52:52PM +0200, Hans de Goede wrote:
> +/**
> + * struct drm_connector_oob_hotplug_event_data: OOB hotplug event data
> + *
> + * Contains data about out-of-band hotplug events, signalled through
> + * drm_connector_oob_hotplug_event().
> + */
> +struct
On Sat, Sep 21, 2019 at 02:12:28AM +0300, Laurent Pinchart wrote:
> Hi Dmitry,
>
> (CC'ing Heikki as the original author of software nodes support)
>
> Thank you for the patch.
>
> On Wed, Sep 11, 2019 at 12:52:10AM -0700, Dmitry Torokhov wrote:
> > Instead of fwnode_get_named_gpiod() that I
for a connector entry
straightforward (it's one-on-one mapping).
Signed-off-by: Heikki Krogerus
---
drivers/gpu/drm/i915/intel_display.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
case (those nodes do seem to be supplying
the connectors all kinds of resources, not only references to other
components), I'm proposing this now instead of waiting for the USB
Type-C patches.
thanks,
Heikki Krogerus (2):
drm: Add fwnode member to the struct drm_connector
drm/i915: Associate
CPI, the connector's sysfs directory will have a symlink
named "firmware_node" pointing to the node object directory in sysfs
if a node is associated with the connector.
Signed-off-by: Heikki Krogerus
---
drivers/gpu/drm/drm_sysfs.c | 49 +
include/
Hi Hans,
On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote:
> Hi Heikki,
>
> On 28-02-19 15:47, Heikki Krogerus wrote:
> > Hi Hans,
> >
> > On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
&
On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 27-02-19 12:16, Jani Nikula wrote:
> > On Wed, 27 Feb 2019, Heikki Krogerus
> > wrote:
> > > One thing that this series does not consider is the DP lane count
> > > problem. T
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> Hi,
>
> On 28-02-19 10:15, Heikki Krogerus wrote:
> > On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 27-02-19 12:16, Jani Nikula wrote:
&g
On Wed, Feb 27, 2019 at 01:16:27PM +0200, Jani Nikula wrote:
> On Wed, 27 Feb 2019, Heikki Krogerus wrote:
> > One thing that this series does not consider is the DP lane count
> > problem. The GPU drivers (i915 in this case) does not know is four,
> > two or one DP la
Hi Hans,
On Mon, Feb 25, 2019 at 02:20:34PM +0100, Hans de Goede wrote:
> Hi All,
>
> On some Cherry Trail devices, DisplayPort over Type-C is supported through
> a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
> datalines between USB-3 and DP (e.g. a pi3usb30532). The
On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:
> Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
> drm/kms drivers know about DisplayPort over Type-C hotplug events.
>
> Signed-off-by: Hans de Goede
I'm OK with this. I'll wait for the v2 and see if I can
On Wed, Apr 11, 2018 at 02:09:29PM +0300, Heikki Krogerus wrote:
> On Wed, Apr 11, 2018 at 08:28:44AM +, andrey.ara...@nixaid.com wrote:
> > Thank you for the insights, Heikki!
> >
> > Please find the acpi.dump.tgz file is a attached.
> >
> > I do not ha
On Mon, Mar 05, 2018 at 09:18:10AM +0100, Andrzej Hajda wrote:
> On 02.03.2018 14:13, Heikki Krogerus wrote:
> > Hi,
> >
> > On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
> >> +2. USB-C connector attached to CC controller (s2mm005), HS lines
Hi,
On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
> +DisplayPort video lines are routed to the connector via SS mux in USB3
On Sat, Aug 19, 2017 at 01:52:26PM +0530, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal <bhumi...@gmail.com>
Acked-by: Heikki K
57 matches
Mail list logo
