From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752843AbdKIH17 (ORCPT ); Thu, 9 Nov 2017 02:27:59 -0500 Received: from mga07.intel.com ([134.134.136.100]:15193 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752812AbdKIH1z (ORCPT ); Thu, 9 Nov 2017 02:27:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,368,1505804400"; d="scan'208";a="1241888335" Subject: Re: [PATCH V13 07/10] mmc: block: blk-mq: Add support for direct completion To: Linus Walleij Cc: Ulf Hansson , linux-mmc , linux-block , linux-kernel , Bough Chen , Alex Lemberg , Mateusz Nowak , Yuliy Izrailov , Jaehoon Chung , Dong Aisheng , Das Asutosh , Zhangfei Gao , Sahitya Tummala , Harjani Ritesh , Venu Byravarasu , Shawn Lin , Christoph Hellwig References: <1509715220-31885-1-git-send-email-adrian.hunter@intel.com> <1509715220-31885-8-git-send-email-adrian.hunter@intel.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: Date: Thu, 9 Nov 2017 09:27:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/11/17 11:28, Linus Walleij wrote: > On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote: > >> For blk-mq, add support for completing requests directly in the ->done >> callback. That means that error handling and urgent background operations >> must be handled by recovery_work in that case. >> >> Signed-off-by: Adrian Hunter > > I tried enabling this on my MMC host (mmci) but I got weird > DMA error messages when I did. > > I guess this has not been tested on a non-DMA-coherent > system? I don't see what DMA-coherence has to do with anything. Possibilities: - DMA unmapping doesn't work in an atomic context - requests' DMA operations have to be synchronized with each other > I think I might be seeing this because the .pre and .post > callbacks need to be strictly sequenced, and this is > maybe not taken into account here? I looked at mmci but that did not seem to be the case. > Isn't there as risk > that the .post callback of the next request is called before > the .post callback of the previous request has returned > for example? Of course, the requests are treated as independent. If the separate DMA operations require synchronization, that is for the host driver to fix.