linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 7/8] usb: typec: ucsi: glink: merge pmic_glink_altmode driver
Date: Thu, 16 May 2024 11:18:20 +0300	[thread overview]
Message-ID: <ZkXBTCfMCkl07/sl@kuha.fi.intel.com> (raw)
In-Reply-To: <f2bqgtoll3j6pseg6hzvwtyqiwfwcaepuhcnq4nrshux2bnluh@rte67mi7zcey>

Hi Dmitry,

On Wed, May 15, 2024 at 06:01:48PM +0300, Dmitry Baryshkov wrote:
> > I have played with the DP AltMode driver. I got it somewhat working,
> > but I think I'm facing a control issue.
> > Basically, the altmode driver wants to control pin assignment on its
> > own. It works with the software TCPM, as we control it.
> > It works with the normal UCSI, because it still can configure pin
> > config. However with PMIC GLINK implementation there is no way to
> > control pin assignment from the Linux side. The firmware does that for
> > us.
> > What would be the recommended way to handle it? Is it okay to override
> > status_update to return just the selected pin config? Or is there any
> > other (better) way to handle such an issue?
> 
> Any suggestions or further comments? Is it better to extend the
> DisplayPort Altmode driver with the 'forced' transitions? Or it would be
> fine to just register a partner device, emulate the userspace events,
> but completely ignore the existing displayport driver?

I may have to look at the DP alt mode with the TI host interface
(drivers/usb/typec/tipd/) at some point, because on some systems the
firmware does not seem to automatically enter the mode, but the forced
transition option would probable work there as well...

I would prefer that we don't ignore the DP alt mode driver, but just
to be clear, I'm also not completely against it if you feel that would
be the most reasonable option in your case.

br,

-- 
heikki

  reply	other threads:[~2024-05-16  8:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16  2:20 [PATCH 0/8] usb: typec: ucsi: glink: merge in altmode support Dmitry Baryshkov
2024-04-16  2:20 ` [PATCH 1/8] usb: typec: Handle retimers in typec_set_mode() Dmitry Baryshkov
2024-04-16 14:30   ` Konrad Dybcio
2024-04-16 17:26   ` Neil Armstrong
2024-04-22  8:00   ` Heikki Krogerus
2024-04-16  2:20 ` [PATCH 2/8] usb: typec: altmode: add low level altmode configuration helper Dmitry Baryshkov
2024-04-16 14:32   ` Konrad Dybcio
2024-04-16 14:48     ` Dmitry Baryshkov
2024-04-16 14:57       ` Konrad Dybcio
2024-04-16 15:20         ` Dmitry Baryshkov
2024-04-16  2:20 ` [PATCH 3/8] usb: typec: ucsi: glink: check message data sizes Dmitry Baryshkov
2024-04-16 14:33   ` Konrad Dybcio
2024-04-16 14:49     ` Dmitry Baryshkov
2024-04-16  2:20 ` [PATCH 4/8] usb: typec: ucsi: glink: use le32 for message data Dmitry Baryshkov
2024-04-16 14:34   ` Konrad Dybcio
2024-04-16 17:28   ` Neil Armstrong
2024-04-22 10:29   ` Heikki Krogerus
2024-04-16  2:20 ` [PATCH 5/8] usb: typec: ucsi: glink: simplify notification handling Dmitry Baryshkov
2024-04-16 14:36   ` Konrad Dybcio
2024-04-16 15:15     ` Dmitry Baryshkov
2024-04-16  2:20 ` [PATCH 6/8] usb: typec: ucsi: add ucsi_registered() callback Dmitry Baryshkov
2024-04-16  2:20 ` [PATCH 7/8] usb: typec: ucsi: glink: merge pmic_glink_altmode driver Dmitry Baryshkov
2024-04-22 10:59   ` Heikki Krogerus
2024-04-22 12:45     ` Dmitry Baryshkov
2024-04-22 15:02       ` Heikki Krogerus
2024-04-22 15:22         ` Dmitry Baryshkov
2024-05-04  6:49         ` Dmitry Baryshkov
2024-05-15 15:01           ` Dmitry Baryshkov
2024-05-16  8:18             ` Heikki Krogerus [this message]
2024-04-16  2:20 ` [PATCH 8/8] soc: qcom: pmic-glink: drop separate altmode driver support Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZkXBTCfMCkl07/sl@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=andersson@kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).