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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.