All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: "Lin, Wayne" <Wayne.Lin@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "imre.deak@intel.com" <imre.deak@intel.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"Zuo,  Jerry" <Jerry.Zuo@amd.com>,
	"Wentland, Harry" <Harry.Wentland@amd.com>,
	"ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Subject: RE: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new message
Date: Fri, 09 Jun 2023 11:53:17 +0300	[thread overview]
Message-ID: <871qilrp8i.fsf@intel.com> (raw)
In-Reply-To: <CO6PR12MB548948F83852B367F228F9A9FC51A@CO6PR12MB5489.namprd12.prod.outlook.com>

>> > bool *handled)
>> > +int drm_dp_mst_hpd_irq_handle_event(struct drm_dp_mst_topology_mgr
>> *mgr, const u8 *esi,
>> > +                               u8 *ack, bool *handled)
>> >  {
>> >     int ret = 0;
>> >     int sc;
>> > @@ -4078,18 +4089,47 @@ int drm_dp_mst_hpd_irq(struct
>> drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl
>> >     if (esi[1] & DP_DOWN_REP_MSG_RDY) {
>> >             ret = drm_dp_mst_handle_down_rep(mgr);
>> >             *handled = true;
>> > +           *ack |= DP_DOWN_REP_MSG_RDY;
>>
>> My idea was that esi and ack would be the same size buffers, so the caller
>> wouldn't have to worry where exactly to point ack to.
>>
>> I think the asymmetry here is misleading, with ack and esi having to point at
>> different locations.
>>
> Thanks, Jani.
>
> But Event status Indicator Files (DPCD 0x2000h ~ 0x21FFH) are not all designed
> to be ack clear, e.g. esi[0] here. My thought is to be precise about what is handled
> and what is going to be ack clear. Otherwise, write ack[0] to DPCD 0x2002h is
> not reasonable.

The point is that you have the same indexes everywhere, even if ack[0]
ends up being unused.

Handle esi[1] & DP_DOWN_REP_MSG_RDY, set ack[1] |= DP_DOWN_REP_MSG_RDY.

Similar pattern everywhere, drm core and drivers. The only place that
needs to know the difference is where the ack is written back to DPCD.

If we end up adding more helpers for drm core handling ESI, we'll keep
repeating the same pattern, instead of passing individual u8 acks
everywhere, with the driver having to figure out what pointers to pass.

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: "Lin, Wayne" <Wayne.Lin@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "lyude@redhat.com" <lyude@redhat.com>,
	"ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
	"imre.deak@intel.com" <imre.deak@intel.com>,
	"Wentland, Harry" <Harry.Wentland@amd.com>,
	"Zuo, Jerry" <Jerry.Zuo@amd.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new message
Date: Fri, 09 Jun 2023 11:53:17 +0300	[thread overview]
Message-ID: <871qilrp8i.fsf@intel.com> (raw)
In-Reply-To: <CO6PR12MB548948F83852B367F228F9A9FC51A@CO6PR12MB5489.namprd12.prod.outlook.com>

>> > bool *handled)
>> > +int drm_dp_mst_hpd_irq_handle_event(struct drm_dp_mst_topology_mgr
>> *mgr, const u8 *esi,
>> > +                               u8 *ack, bool *handled)
>> >  {
>> >     int ret = 0;
>> >     int sc;
>> > @@ -4078,18 +4089,47 @@ int drm_dp_mst_hpd_irq(struct
>> drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl
>> >     if (esi[1] & DP_DOWN_REP_MSG_RDY) {
>> >             ret = drm_dp_mst_handle_down_rep(mgr);
>> >             *handled = true;
>> > +           *ack |= DP_DOWN_REP_MSG_RDY;
>>
>> My idea was that esi and ack would be the same size buffers, so the caller
>> wouldn't have to worry where exactly to point ack to.
>>
>> I think the asymmetry here is misleading, with ack and esi having to point at
>> different locations.
>>
> Thanks, Jani.
>
> But Event status Indicator Files (DPCD 0x2000h ~ 0x21FFH) are not all designed
> to be ack clear, e.g. esi[0] here. My thought is to be precise about what is handled
> and what is going to be ack clear. Otherwise, write ack[0] to DPCD 0x2002h is
> not reasonable.

The point is that you have the same indexes everywhere, even if ack[0]
ends up being unused.

Handle esi[1] & DP_DOWN_REP_MSG_RDY, set ack[1] |= DP_DOWN_REP_MSG_RDY.

Similar pattern everywhere, drm core and drivers. The only place that
needs to know the difference is where the ack is written back to DPCD.

If we end up adding more helpers for drm core handling ESI, we'll keep
repeating the same pattern, instead of passing individual u8 acks
everywhere, with the driver having to figure out what pointers to pass.

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: "Lin, Wayne" <Wayne.Lin@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "stable@vger.kernel.org" <stable@vger.kernel.org>,
	"Zuo, Jerry" <Jerry.Zuo@amd.com>
Subject: RE: [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new message
Date: Fri, 09 Jun 2023 11:53:17 +0300	[thread overview]
Message-ID: <871qilrp8i.fsf@intel.com> (raw)
In-Reply-To: <CO6PR12MB548948F83852B367F228F9A9FC51A@CO6PR12MB5489.namprd12.prod.outlook.com>

>> > bool *handled)
>> > +int drm_dp_mst_hpd_irq_handle_event(struct drm_dp_mst_topology_mgr
>> *mgr, const u8 *esi,
>> > +                               u8 *ack, bool *handled)
>> >  {
>> >     int ret = 0;
>> >     int sc;
>> > @@ -4078,18 +4089,47 @@ int drm_dp_mst_hpd_irq(struct
>> drm_dp_mst_topology_mgr *mgr, u8 *esi, bool *handl
>> >     if (esi[1] & DP_DOWN_REP_MSG_RDY) {
>> >             ret = drm_dp_mst_handle_down_rep(mgr);
>> >             *handled = true;
>> > +           *ack |= DP_DOWN_REP_MSG_RDY;
>>
>> My idea was that esi and ack would be the same size buffers, so the caller
>> wouldn't have to worry where exactly to point ack to.
>>
>> I think the asymmetry here is misleading, with ack and esi having to point at
>> different locations.
>>
> Thanks, Jani.
>
> But Event status Indicator Files (DPCD 0x2000h ~ 0x21FFH) are not all designed
> to be ack clear, e.g. esi[0] here. My thought is to be precise about what is handled
> and what is going to be ack clear. Otherwise, write ack[0] to DPCD 0x2002h is
> not reasonable.

The point is that you have the same indexes everywhere, even if ack[0]
ends up being unused.

Handle esi[1] & DP_DOWN_REP_MSG_RDY, set ack[1] |= DP_DOWN_REP_MSG_RDY.

Similar pattern everywhere, drm core and drivers. The only place that
needs to know the difference is where the ack is written back to DPCD.

If we end up adding more helpers for drm core handling ESI, we'll keep
repeating the same pattern, instead of passing individual u8 acks
everywhere, with the driver having to figure out what pointers to pass.

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-06-09 13:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08 11:43 [PATCH v4] drm/dp_mst: Clear MSG_RDY flag before sending new message Wayne Lin
2023-06-08 11:43 ` Wayne Lin
2023-06-08 11:43 ` Wayne Lin
2023-06-08 12:26 ` Jani Nikula
2023-06-08 12:26   ` Jani Nikula
2023-06-08 12:26   ` Jani Nikula
2023-06-09  2:45   ` Lin, Wayne
2023-06-09  2:45     ` Lin, Wayne
2023-06-09  2:45     ` Lin, Wayne
2023-06-09  8:53     ` Jani Nikula [this message]
2023-06-09  8:53       ` Jani Nikula
2023-06-09  8:53       ` Jani Nikula
2023-06-09  9:23       ` Lin, Wayne
2023-06-09  9:23         ` Lin, Wayne
2023-06-09  9:23         ` Lin, Wayne

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=871qilrp8i.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=Harry.Wentland@amd.com \
    --cc=Jerry.Zuo@amd.com \
    --cc=Wayne.Lin@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imre.deak@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=ville.syrjala@linux.intel.com \
    /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.