Hi Dave, there are few comments from my side:
1. As UP replies also got to slots (even as mentioned in code it should not happen), we should clean them somewhere. For DOWN requests they are cleaned on DOWN reply when full reply received. However we will not receive interrupt when UP reply sent; 2. I am not sure if DRM process DOWN requests or UP reply with length more than 1 SB currently, though it does process DOWN replies. First SB is sent right away message is submit. Left part intended to be send in drm_dp_tx_work, which is scheduled from drm_dp_mst_hpd_irq, which should be called from DP short pulse interrupt. However short pulse will not come for the part of DOWN request, nor for part of UP reply. As I understand we do not have issues right now as there is no DOWN request or UP reply longer than 1 SB; 3. not sure if it is needed to use queue for UP replies. As soon as full UP request received, we should send full reply right away, processing AUX_DEFER just in case; 4. If above points right, sending of MST messages bigger than 1 SB should be addressed as a separate patch, not in topic patch. Please, let me know if points above make sense or I misunderstood code somewhere. Mykola From: Wentland, Harry Sent: Sunday, December 20, 2015 12:21 AM To: airlied at gmail.com; Lysenko, Mykola <Mykola.Lysenko at amd.com> Cc: dri-devel at lists.freedesktop.org Subject: Re: [PATCH 2/2] drm/dp/mst: always send reply for UP request Thanks, Dave. Do you have an example when the up reply would be too big to fit into one sideband message? We don't expect that to happen. Mykola, can you see if Dave's patch is a good alternative to your patch? Harry On Fri, Dec 18, 2015 at 7:57 PM -0800, "Dave Airlie" <airlied at gmail.com<mailto:airlied at gmail.com>> wrote: On 19 December 2015 at 08:14, Harry Wentland <harry.wentland at amd.com<mailto:harry.wentland at amd.com>> wrote: > From: Mykola Lysenko <Mykola.Lysenko at amd.com<mailto:Mykola.Lysenko at > amd.com>> > > We should always send reply for UP request in order > to make downstream device clean-up resources appropriately. > > Issue was that reply for UP request was sent only once. What happens though if the up reply is too big and needs to be cut into pieces, Since the return value of process_single_tx_qlock is -value - errno. 0 - part of msg sent 1 - all of msg sent Does the attached patch make any difference? It handles the queue like the down queue. Dave. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151221/c5ff7cd8/attachment-0001.html>
