From: Pengyu Luo <mitltlatltl@gmail.com>
To: dmitry.baryshkov@linaro.org
Cc: andersson@kernel.org, bryan.odonoghue@linaro.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, hdegoede@redhat.com,
heikki.krogerus@linux.intel.com, ilpo.jarvinen@linux.intel.com,
konradybcio@kernel.org, krzk+dt@kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, linux-usb@vger.kernel.org,
mitltlatltl@gmail.com, nikita@trvn.ru,
platform-driver-x86@vger.kernel.org, robh@kernel.org,
sre@kernel.org
Subject: Re: [PATCH 3/5] usb: typec: ucsi: add Huawei Matebook E Go (sc8280xp) ucsi driver
Date: Mon, 6 Jan 2025 17:22:17 +0800 [thread overview]
Message-ID: <20250106092224.251115-1-mitltlatltl@gmail.com> (raw)
In-Reply-To: <h4icxzxk5fzgkdhhk6disrervqmb4dqe3xlc432k7pgyzsk77u@pyfrrtyjslpo>
Please ignore the last email, I sent the wrong archive.
On Mon, Jan 6, 2025 at 11:33 AM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> On Sun, Dec 29, 2024 at 05:05:47PM +0800, Pengyu Luo wrote:
> > On Sun, Dec 29, 2024 at 12:40 PM Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> > > On Sat, Dec 28, 2024 at 01:13:51AM +0800, Pengyu Luo wrote:
> > > > The Huawei Matebook E Go (sc8280xp) tablet provides implements UCSI
> > > > interface in the onboard EC. Add the glue driver to interface the
> > > > platform's UCSI implementation.
> > > >
> > > > Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> > > > ---
> > > > drivers/usb/typec/ucsi/Kconfig | 9 +
> > > > drivers/usb/typec/ucsi/Makefile | 1 +
> > > > drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 481 ++++++++++++++++++++
> > > > 3 files changed, 491 insertions(+)
> > > > create mode 100644 drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> > > >
> > > > diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
> > > > index 680e1b87b..0d0f07488 100644
> > > > --- a/drivers/usb/typec/ucsi/Kconfig
> > > > +++ b/drivers/usb/typec/ucsi/Kconfig
> > > > @@ -78,4 +78,13 @@ config UCSI_LENOVO_YOGA_C630
> > > > To compile the driver as a module, choose M here: the module will be
> > > > called ucsi_yoga_c630.
[...]
> > > > +
> > > > + spin_lock_irqsave(&port->lock, flags);
> > > > +
> > > > + port->ccx = FIELD_GET(GAOKUN_CCX_MASK, dcc);
> > > > + port->mux = FIELD_GET(GAOKUN_MUX_MASK, dcc);
> > > > + port->mode = FIELD_GET(GAOKUN_DPAM_MASK, ddi);
> > > > + port->hpd_state = FIELD_GET(GAOKUN_HPD_STATE_MASK, ddi);
> > > > + port->hpd_irq = FIELD_GET(GAOKUN_HPD_IRQ_MASK, ddi);
> > > > +
> > > > + switch (port->mux) {
> > > > + case USBC_MUX_NONE:
> > > > + port->svid = 0;
> > > > + break;
> > > > + case USBC_MUX_USB_2L:
> > > > + port->svid = USB_SID_PD;
> > > > + break;
> > > > + case USBC_MUX_DP_4L:
> > > > + case USBC_MUX_USB_DP:
> > > > + port->svid = USB_SID_DISPLAYPORT;
> > > > + if (port->ccx == USBC_CCX_REVERSE)
> > > > + port->mode -= 6;
> > >
> > > I'd prefer it this were more explicit about what is happening.
> > >
> >
> > If orientation is reverse, then we should minus 6, EC's logic.
> > I will add a comment for it. Actually, this field is unused, I don't
> > find the mux yet, so I cannot set it with this field. But I don't want
> > to make things imcomplete, so keep it.
>
> Which values are you expecting / getting there? The -6 is a pure magic.
> Please replace this with a switch-case or something more obvious.
>
In v2, I have deduced their meaning, with a switch to map them.
> > Let me go off the topic, on my device, I can just use drm_aux_hpd_bridge_notify
> > to enable altmode, usb functions well after I pluged out, I don't need set mode
> > switch(orientation switch is required if orientation is reverse), which is quiet
> > similar to Acer aspire 1. Is mux controlled also by QMP combo phy(see [1])?
> >
> > > > + break;
> > > > + default:
> > > > + break;
> > > > + }
> > > > +
> > > > + spin_unlock_irqrestore(&port->lock, flags);
> > > > +}
> > > > +
> > > > +static int gaokun_ucsi_refresh(struct gaokun_ucsi *uec)
> > > > +{
> > > > + struct gaokun_ucsi_reg ureg;
> > > > + int ret, idx;
> > > > +
> > > > + ret = gaokun_ec_ucsi_get_reg(uec->ec, (u8 *)&ureg);
> > > > + if (ret)
> > > > + return -EIO;
> > > > +
> > > > + uec->port_num = ureg.port_num;
> > > > + idx = GET_IDX(ureg.port_updt);
> > > > +
> > > > + if (idx >= 0 && idx < ureg.port_num)
> > > > + gaokun_ucsi_port_update(&uec->ports[idx], ureg.port_data);
> > > > +
> > > > + return idx;
> > > > +}
> > > > +
> > > > +static void gaokun_ucsi_handle_altmode(struct gaokun_ucsi_port *port)
> > > > +{
> > > > + struct gaokun_ucsi *uec = port->ucsi;
> > > > + int idx = port->idx;
> > > > +
> > > > + if (idx >= uec->ucsi->cap.num_connectors || !uec->ucsi->connector) {
> > > > + dev_warn(uec->ucsi->dev, "altmode port out of range: %d\n", idx);
> > > > + return;
> > > > + }
> > > > +
> > > > + /* UCSI callback .connector_status() have set orientation */
> > > > + if (port->bridge)
> > > > + drm_aux_hpd_bridge_notify(&port->bridge->dev,
> > > > + port->hpd_state ?
> > > > + connector_status_connected :
> > > > + connector_status_disconnected);
> > >
> > > Does your platform report any altmodes? What do you see in
> > > /sys/class/typec/port0/port0.*/ ?
> > >
> >
> > /sys/class/typec/port0/port0.0:
> > active mode mode1 power svid uevent vdo
> >
> > /sys/class/typec/port0/port0.1:
> > active mode mode1 power svid uevent vdo
> >
> > /sys/class/typec/port0/port0.2:
> > active mode mode1 power svid uevent vdo
> >
> > /sys/class/typec/port0/port0.3:
> > active mode mode2 power svid uevent vdo
> >
> > /sys/class/typec/port0/port0.4:
> > active mode mode3 power svid uevent vdo
>
> please:
>
> cat /sys/class/typec/port0/port0*/svid
> cat /sys/class/typec/port0/port0*/vdo
>
svid:
8087
ff01
12d1
12d1
12d1
vdo:
0xff000001
0xff1c1c46
0xff000001
0xff000002
0xff000003
> If DP is reported as one the altmodes, then it should be using the
> DisplayPort AltMode driver, as suggested by Heikki.
>
But this paltform cannot access to the partner device, related API
requires a partner.
BTW, it is unnecessary that implementing/call a DP Altmode driver for
this platform. Currently, we can enter altmode with a HPD event notify.
This point is quiet similar to Acer aspire 1. I mentioned this when we
last talked about minus 6.
> > > > +
> > > > + gaokun_ec_ucsi_pan_ack(uec->ec, port->idx);
> > > > +}
> > > > +
> > > > +static void gaokun_ucsi_altmode_notify_ind(struct gaokun_ucsi *uec)
> > > > +{
> > > > + int idx;
> > > > +
> > > > + idx = gaokun_ucsi_refresh(uec);
> > > > + if (idx < 0)
> > > > + gaokun_ec_ucsi_pan_ack(uec->ec, idx);
> > > > + else
> > > > + gaokun_ucsi_handle_altmode(&uec->ports[idx]);
> > > > +}
> > > > +
> > > > +/*
> > > > + * USB event is necessary for enabling altmode, the event should follow
> > > > + * UCSI event, if not after timeout(this notify may be disabled somehow),
> > > > + * then force to enable altmode.
> > > > + */
> > > > +static void gaokun_ucsi_handle_no_usb_event(struct gaokun_ucsi *uec, int idx)
> > > > +{
> > > > + struct gaokun_ucsi_port *port;
> > > > +
> > > > + port = &uec->ports[idx];
> > > > + if (!wait_for_completion_timeout(&port->usb_ack, 2 * HZ)) {
> > > > + dev_warn(uec->dev, "No USB EVENT, triggered by UCSI EVENT");
> > > > + gaokun_ucsi_altmode_notify_ind(uec);
> > > > + }
> > > > +}
> > > > +
[...]
> > > > +
> > > > +static void gaokun_ucsi_register_worker(struct work_struct *work)
> > > > +{
> > > > + struct gaokun_ucsi *uec;
> > > > + struct ucsi *ucsi;
> > > > + int ret;
> > > > +
> > > > + uec = container_of(work, struct gaokun_ucsi, work);
> > > > + ucsi = uec->ucsi;
> > > > +
> > > > + ucsi->quirks = UCSI_NO_PARTNER_PDOS | UCSI_DELAY_DEVICE_PDOS;
> > >
> > > Does it crash in the same way as GLINK crashes (as you've set
> > > UCSI_NO_PARTNER_PDOS)?
> > >
> >
> > Yes, no partner can be detected, I checked. I think it is also handled by
> > the firmware As you said in [2]
> > > In some obscure cases (Qualcomm PMIC Glink) altmode is completely
> > > handled by the firmware. Linux does not get proper partner altmode info.
>
> This is a separate topic. Those two flags were added for a very
> particular reason:
>
> - To workaround firmware crash on requesting PDOs for a partner
> - To delay requeting PDOs for the device because in the unconnected
> state the GET_PDOS returns incorrect information
>
> Are you sure that those two flags are necessary for your platform?
>
Alright, I think I got things mixed up. Actually PDO requires UCSI only,
not a partner device.
I think I will remove it in v3 if it works well during the time. Rencetly,
this platform works well without it. Thanks for pointing out.
> >
> > > > +
> > > > + ssleep(3); /* EC can't handle UCSI properly in the early stage */
> > > > +
> > > > + ret = gaokun_ec_register_notify(uec->ec, &uec->nb);
> > > > + if (ret) {
> > > > + dev_err_probe(ucsi->dev, ret, "notifier register failed\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + ret = ucsi_register(ucsi);
> > > > + if (ret)
> > > > + dev_err_probe(ucsi->dev, ret, "ucsi register failed\n");
> > > > +}
> > > > +
> > > > +static int gaokun_ucsi_register(struct gaokun_ucsi *uec)
> > >
> > > Please inline
> > >
> >
> > I see.
> >
> > Best wishes
> > Pengyu
> >
> > [1] https://elixir.bootlin.com/linux/v6.12.5/source/drivers/phy/qualcomm/phy-qcom-qmp-combo.c#L2679
> > [2] https://lore.kernel.org/lkml/20240416-ucsi-glink-altmode-v1-0-890db00877ac@linaro.org
Best Wishes,
Pengyu
next prev parent reply other threads:[~2025-01-06 9:23 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-27 17:13 [PATCH 0/5] platform: arm64: Huawei Matebook E Go embedded controller Pengyu Luo
2024-12-27 17:13 ` [PATCH 1/5] dt-bindings: platform: Add Huawei Matebook E Go EC Pengyu Luo
2024-12-27 18:18 ` Rob Herring (Arm)
2024-12-28 9:54 ` Krzysztof Kozlowski
2024-12-28 10:50 ` Pengyu Luo
2024-12-29 9:50 ` Krzysztof Kozlowski
2024-12-29 10:12 ` Pengyu Luo
2024-12-30 7:28 ` Aiqun(Maria) Yu
2024-12-30 7:35 ` Krzysztof Kozlowski
2024-12-30 9:10 ` Aiqun(Maria) Yu
2024-12-30 8:00 ` Pengyu Luo
2025-01-01 5:57 ` Pengyu Luo
2024-12-27 17:13 ` [PATCH 2/5] platform: arm64: add Huawei Matebook E Go (sc8280xp) EC driver Pengyu Luo
2024-12-27 18:21 ` Maya Matuszczyk
2024-12-28 5:42 ` Pengyu Luo
2024-12-28 9:58 ` Krzysztof Kozlowski
2024-12-28 11:34 ` [PATCH 1/5] dt-bindings: platform: Add Huawei Matebook E Go EC Pengyu Luo
2024-12-29 4:08 ` Dmitry Baryshkov
2024-12-29 9:04 ` [PATCH 2/5] platform: arm64: add Huawei Matebook E Go (sc8280xp) EC driver Pengyu Luo
2024-12-29 9:44 ` Krzysztof Kozlowski
2024-12-29 9:43 ` [PATCH 1/5] dt-bindings: platform: Add Huawei Matebook E Go EC Krzysztof Kozlowski
2024-12-29 10:28 ` Pengyu Luo
2024-12-29 21:45 ` Krzysztof Kozlowski
2024-12-28 12:33 ` [PATCH 2/5] platform: arm64: add Huawei Matebook E Go (sc8280xp) EC driver Bryan O'Donoghue
2024-12-28 13:51 ` Pengyu Luo
2024-12-29 15:32 ` Ilpo Järvinen
2024-12-29 15:55 ` Pengyu Luo
2024-12-29 14:49 ` Markus Elfring
2024-12-30 9:04 ` Aiqun(Maria) Yu
2024-12-30 10:44 ` Pengyu Luo
2024-12-31 5:00 ` Aiqun(Maria) Yu
2024-12-31 7:44 ` Pengyu Luo
2024-12-31 11:09 ` Bryan O'Donoghue
2025-01-03 5:38 ` Dmitry Baryshkov
2025-01-03 7:19 ` Pengyu Luo
2025-01-01 11:27 ` Pengyu Luo
2024-12-27 17:13 ` [PATCH 3/5] usb: typec: ucsi: add Huawei Matebook E Go (sc8280xp) ucsi driver Pengyu Luo
2024-12-28 13:06 ` Bryan O'Donoghue
2024-12-28 14:38 ` Pengyu Luo
2024-12-29 14:51 ` Bryan O'Donoghue
2024-12-29 16:25 ` Pengyu Luo
2024-12-29 4:40 ` Dmitry Baryshkov
2024-12-29 9:05 ` Pengyu Luo
2025-01-06 3:33 ` Dmitry Baryshkov
2025-01-06 9:20 ` [PATCH 1/5] dt-bindings: platform: Add Huawei Matebook E Go EC Pengyu Luo
2025-01-06 9:22 ` Pengyu Luo [this message]
2024-12-29 16:15 ` [PATCH 3/5] usb: typec: ucsi: add Huawei Matebook E Go (sc8280xp) ucsi driver Markus Elfring
2024-12-27 17:13 ` [PATCH 4/5] power: supply: add Huawei Matebook E Go (sc8280xp) psy driver Pengyu Luo
2024-12-27 17:13 ` [PATCH 5/5] arm64: dts: qcom: gaokun3: Add Embedded Controller node Pengyu Luo
2024-12-30 14:53 ` Konrad Dybcio
2024-12-30 16:22 ` Pengyu Luo
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=20250106092224.251115-1-mitltlatltl@gmail.com \
--to=mitltlatltl@gmail.com \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nikita@trvn.ru \
--cc=platform-driver-x86@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sre@kernel.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).