On Fri, Sep 13, 2024 at 09:46:12AM GMT, Sandor Yu wrote:
> > Subject: Re: [EXT] Re: [PATCH v16 4/8] drm: bridge: Cadence: Add MHDP8501
> > DP/HDMI driver
> >
> > On Fri, Sep 06, 2024 at 02:50:08AM GMT, Sandor Yu wrote:
> > > > On Tue, Sep 03, 2024 at 06:07:25AM GMT, Sandor Yu wrote:
> > > > > > -----Original Message-----
> > > > > > From: dri-devel <dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On
> > > > > > Behalf Of Maxime Ripard
> > > > > > Sent: 2024年7月2日 21:25
> > > > > > To: Sandor Yu <sandor.yu@xxxxxxx>
> > > > > > Cc: dmitry.baryshkov@xxxxxxxxxx; andrzej.hajda@xxxxxxxxx;
> > > > > > neil.armstrong@xxxxxxxxxx; Laurent Pinchart
> > > > > > <laurent.pinchart@xxxxxxxxxxxxxxxx>; jonas@xxxxxxxxx;
> > > > > > jernej.skrabec@xxxxxxxxx; airlied@xxxxxxxxx; daniel@xxxxxxxx;
> > > > > > robh+dt@xxxxxxxxxx; krzysztof.kozlowski+dt@xxxxxxxxxx;
> > > > > > shawnguo@xxxxxxxxxx; s.hauer@xxxxxxxxxxxxxx;
> > festevam@xxxxxxxxx;
> > > > > > vkoul@xxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx;
> > > > > > devicetree@xxxxxxxxxxxxxxx;
> > > > > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> > > > > > linux-kernel@xxxxxxxxxxxxxxx; linux-phy@xxxxxxxxxxxxxxxxxxx;
> > > > > > kernel@xxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>; Oliver
> > > > > > Brown <oliver.brown@xxxxxxx>; alexander.stein@xxxxxxxxxxxxxxx;
> > > > > > sam@xxxxxxxxxxxx
> > > > > > Subject: [EXT] Re: [PATCH v16 4/8] drm: bridge: Cadence: Add
> > > > > > MHDP8501 DP/HDMI driver
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > There's still the scrambler issue we discussed on v15, but I
> > > > > > have some more comments.
> > > > > >
> > > > > > On Tue, Jul 02, 2024 at 08:22:36PM GMT, Sandor Yu wrote:
> > > > > > > +enum drm_connector_status cdns_mhdp8501_detect(struct
> > > > > > > +cdns_mhdp8501_device *mhdp) {
> > > > > > > + u8 hpd = 0xf;
> > > > > > > +
> > > > > > > + hpd = cdns_mhdp8501_read_hpd(mhdp);
> > > > > > > + if (hpd == 1)
> > > > > > > + return connector_status_connected;
> > > > > > > + else if (hpd == 0)
> > > > > > > + return connector_status_disconnected;
> > > > > > > +
> > > > > > > + dev_warn(mhdp->dev, "Unknown cable status, hdp=%u\n",
> > hpd);
> > > > > > > + return connector_status_unknown; }
> > > > > > > +
> > > > > > > +static void hotplug_work_func(struct work_struct *work) {
> > > > > > > + struct cdns_mhdp8501_device *mhdp = container_of(work,
> > > > > > > + struct cdns_mhdp8501_device,
> > > > > > > + hotplug_work.work);
> > > > > > > + enum drm_connector_status status =
> > > > cdns_mhdp8501_detect(mhdp);
> > > > > > > +
> > > > > > > + drm_bridge_hpd_notify(&mhdp->bridge, status);
> > > > > > > +
> > > > > > > + if (status == connector_status_connected) {
> > > > > > > + /* Cable connected */
> > > > > > > + DRM_INFO("HDMI/DP Cable Plug In\n");
> > > > > > > + enable_irq(mhdp->irq[IRQ_OUT]);
> > > > > > > + } else if (status == connector_status_disconnected) {
> > > > > > > + /* Cable Disconnected */
> > > > > > > + DRM_INFO("HDMI/DP Cable Plug Out\n");
> > > > > > > + enable_irq(mhdp->irq[IRQ_IN]);
> > > > > > > + }
> > > > > > > +}
> > > > > >
> > > > > > You shouldn't play with the interrupt being enabled here:
> > > > > > hotplug interrupts should always enabled.
> > > > > >
> > > > > > If you can't for some reason, the reason should be documented in
> > > > > > your
> > > > driver.
> > > > >
> > > > > iMX8MQ have two HPD interrupters, one for plugout and the other
> > > > > for plugin, because they could not be masked, so we have to enable
> > > > > one and
> > > > disable the other.
> > > > > I will add more comments here.
> > > >
> > > > Right, but why do you need to enable and disable them? Do you get
> > > > spurious interrupts?
> > >
> > > They don't have status registers and cannot be masked. If they are not
> > > disabled, they will continuously generate interrupts. Therefore, I have to
> > disable one and enable the other.
> >
> > Sorry, I still don't get it. How can it be useful to detect hotplug interrupts if it
> > constantly sends spurious interrupts when it's enabled?
>
> Yes, this interrupt is different from a normal one; it's likely a design flaw.
> For instance, the plugin interrupt is continuously generated as long as the cable is plugged in,
> only stopping when the cable is unplugged.
>
> That's why two interrupts are used to detect cable plugout and plugin
> separately. If interrupts aren't used, the only option is polling.
Urgh. Ok. At least, you should document that in your code then.
> > > > > > > + /* Mailbox protect for HDMI PHY access */
> > > > > > > + mutex_lock(&mhdp->mbox_mutex);
> > > > > > > + ret = phy_init(mhdp->phy);
> > > > > > > + mutex_unlock(&mhdp->mbox_mutex);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "Failed to initialize PHY: %d\n", ret);
> > > > > > > + goto clk_disable;
> > > > > > > + }
> > > > > > > +
> > > > > > > + /* Mailbox protect for HDMI PHY access */
> > > > > > > + mutex_lock(&mhdp->mbox_mutex);
> > > > > > > + ret = phy_set_mode(mhdp->phy, phy_mode);
> > > > > > > + mutex_unlock(&mhdp->mbox_mutex);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "Failed to configure PHY: %d\n", ret);
> > > > > > > + goto clk_disable;
> > > > > > > + }
> > > > > >
> > > > > > Why do you need a shared mutex between the phy and HDMI
> > controller?
> > > > >
> > > > > Both PHY and HDMI controller could access to the HDMI firmware by
> > > > > mailbox, So add mutex to avoid race condition.
> > > >
> > > > That should be handled at either the phy or mailbox level, not in
> > > > your hdmi driver.
> > >
> > > In both HDMI driver and PHY driver, every mailbox access had protected
> > > by its owns mutex. However, this mutex can only protect each mailbox
> > > access within their respective drivers, and it cannot provide
> > > protection for access between the HDMI and PHY drivers.
> > >
> > > The PHY driver only provides two API functions, and these functions
> > > are only called in the HDMI driver. Therefore, when accessing these
> > > functions, we use a mutex to protect them. This ensures that mailbox
> > > access is protected across different PHY and HDMI drivers.
> >
> > It's really about abstraction. You're using a publicly defined API, and change
> > the semantics for your driver only, and that's not ok.
> >
> > Why can't the mailbox driver itself serialize the accesses from any user, HDMI
> > and PHY drivers included?
>
> In the current code implementation, cdns-mhdp-helper.c isn't a
> standalone driver but rather a library. It provides fundamental
> mailbox access functions and basic register read/write operations that
> rely on the mailbox. These functions are highly reusable across
> MHDP8501 and MHDP8546 and can be leveraged by future MHDP versions.
>
> However, most MHDP firmware interactions involve a sequence of mailbox
> accesses, including sending commands and receiving firmware responses.
> These commands constitute a significant portion of all firmware
> interactions, encompassing operations like EDID reading and DP link
> training. Unfortunately, these commands cannot be reused between
> MHDP8501 and MHDP8546.
>
> Creating a dedicated mailbox driver with its own mutex would
> effectively address race conditions. However, this would necessitate
> relocating all mailbox-related functions to this driver. Including
> these non-reusable functions would defeat the purpose of code reuse.
>
> To strike a balance between code reusability and race condition
> mitigation, adding mutexes to PHY access functions seems like a
> reasonable solution.
No, it's really not. You need to address this in some other way. Why
can't you put the mutex in cdns-mhdp-helper.c calls?
Maxime
Attachment:
signature.asc
Description: PGP signature
