Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp386637ybl; Fri, 31 Jan 2020 00:30:08 -0800 (PST) X-Google-Smtp-Source: APXvYqyWhZS6l+Yy3dr0g83KY1gLwOSrYakumhSTfTsqs5smLKqdH+6kAvBwmtugZn5u6qi0+yXg X-Received: by 2002:a05:6830:16d0:: with SMTP id l16mr6892207otr.83.1580459408575; Fri, 31 Jan 2020 00:30:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580459408; cv=none; d=google.com; s=arc-20160816; b=MF8QOn7awRBnq+RUHPwFISEMW1VDrjk7YKAyJ1pGyNdZyZjb5ym/PI/SF7RSPty2TN QS3RBLmMb9txmTY2pCIC6KM4Ae9lFVBNxbn84IyuB3y75k1goMqkao4exIuoyjyAXae+ 0HQ0r0Gr5vIoSwLwGVPsMx5yFdgg2N9mvZMGSt+woqJZp9EAYIq5GBvPGQcVevbuf3uR ZBkmhjZXBQpGvDXTDVxZsTe0CZDsuTbz3C2ypS8kLLXTNFvjdu4cqGgrxuoZFpWQVa/H gyCQtzlC/mqbMSJS1b1AMoC4PQRFN0FOdTkHDp94iVCP+Srk3ngQjcgD2qWWhfVNmvCp 3ESg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Q6+uODC6UU0RZ60lAwhGLHFnFw4uX3uuIGYWRdW03N8=; b=Y9e+PPpGTpsjiLB7E8SMp/OKt4e6BnYY0TuwBCTi0wS9GLwhqR0oFS6YyB387TZG/c 8wI/+bjkquN84Aw/GMdiHan+cv7nK/M+adFYxFRA2eaCkQLbKqPXlQjJkOarX49ZVtga VQW4lIOKV5Ka4tQ0CFGNl0mLla7s3QxNQd0DZH+05THHltsXXwnCwgJ5Q45+BzUWDq0z 9wlJ5NttTR20U+Q0qCVy8A0ZfEDvjM15lVxZe54aouflW2XXFlvZtu2712Krhn3KL+oO qVSfBBcj9kS48515oxLMCsIJwGDbmVBdAYVDZpAY7KJSY4+Bei4AW11txJ3E7EJRmOtW YgsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=jT+scpwX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z7si4027043oid.150.2020.01.31.00.29.56; Fri, 31 Jan 2020 00:30:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=jT+scpwX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728192AbgAaI2q (ORCPT + 99 others); Fri, 31 Jan 2020 03:28:46 -0500 Received: from lelv0143.ext.ti.com ([198.47.23.248]:42586 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728099AbgAaI2p (ORCPT ); Fri, 31 Jan 2020 03:28:45 -0500 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 00V8SZds077240; Fri, 31 Jan 2020 02:28:35 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1580459315; bh=Q6+uODC6UU0RZ60lAwhGLHFnFw4uX3uuIGYWRdW03N8=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=jT+scpwXJ5spXLxOTFrgAUTD7cHyKsadc6D+HNBWJXgcYzPhmgOXA+YBHVfA5xDEX qee9RQh1Ngzy1+8AUpV7HK4ze+ir2gK7pawKiXCM8/jd1NJpJJJJjfu/+8foNXidLX cYUB+kD8dKYk9YTgXbewu0kObONgMaunBE3CKqz8= Received: from DLEE113.ent.ti.com (dlee113.ent.ti.com [157.170.170.24]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 00V8SZo6092704 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 31 Jan 2020 02:28:35 -0600 Received: from DLEE100.ent.ti.com (157.170.170.30) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Fri, 31 Jan 2020 02:28:34 -0600 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Fri, 31 Jan 2020 02:28:34 -0600 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 00V8SXkX022605; Fri, 31 Jan 2020 02:28:33 -0600 Subject: Re: [PATCH 2/2] dmaengine: Add basic debugfs support To: Geert Uytterhoeven CC: Vinod , , Linux Kernel Mailing List , Dan Williams References: <20200130114220.23538-1-peter.ujfalusi@ti.com> <20200130114220.23538-3-peter.ujfalusi@ti.com> From: Peter Ujfalusi Message-ID: Date: Fri, 31 Jan 2020 10:29:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On 30/01/2020 17.42, Geert Uytterhoeven wrote: > Hi Peter, > > On Thu, Jan 30, 2020 at 12:41 PM Peter Ujfalusi wrote: >> Via the /sys/kernel/debug/dmaengine users can get information about the >> DMA devices and the used channels. >> >> Example output on am654-evm with audio using two channels and after running >> dmatest on 6 channels: >> >> # cat /sys/kernel/debug/dmaengine >> dma0 (285c0000.dma-controller): number of channels: 96 >> >> dma1 (31150000.dma-controller): number of channels: 267 >> dma1chan0: 2b00000.mcasp:tx >> dma1chan1: 2b00000.mcasp:rx >> dma1chan2: in-use >> dma1chan3: in-use >> dma1chan4: in-use >> dma1chan5: in-use >> dma1chan6: in-use >> dma1chan7: in-use >> >> For slave channels we can show the device and the channel name a given >> channel is requested. >> For non slave devices the only information we know is that the channel is >> in use. >> >> DMA drivers can implement the optional dbg_show callback to provide >> controller specific information instead of the generic one. >> >> It is easy to extend the generic dmaengine_dbg_show() to print additional >> information about the used channels. >> >> I have taken the idea from gpiolib. >> >> Signed-off-by: Peter Ujfalusi > > Thanks for your patch! > > On Salvator-XS with R-Car H3 ES2.0: > > dma0 (ec700000.dma-controller): number of channels: 15 > > dma1 (ec720000.dma-controller): number of channels: 15 > > dma2 (e65a0000.dma-controller): number of channels: 2 > dma2chan0: e6590000.usb:ch0 > dma2chan1: e6590000.usb:ch1 > > dma3 (e65b0000.dma-controller): number of channels: 2 > dma3chan0: e6590000.usb:ch2 > dma3chan1: e6590000.usb:ch3 > > dma4 (e6460000.dma-controller): number of channels: 2 > dma4chan0: e659c000.usb:ch0 > dma4chan1: e659c000.usb:ch1 > > dma5 (e6470000.dma-controller): number of channels: 2 > dma5chan0: e659c000.usb:ch2 > dma5chan1: e659c000.usb:ch3 > > dma6 (e6700000.dma-controller): number of channels: 15 > > dma7 (e7300000.dma-controller): number of channels: 15 > dma7chan0: e6510000.i2c:tx > > dma8 (e7310000.dma-controller): number of channels: 15 > dma8chan0: e6550000.serial:tx > dma8chan1: e6550000.serial:rx You have lots of DMAs over there ;) >> --- a/drivers/dma/dmaengine.c >> +++ b/drivers/dma/dmaengine.c >> @@ -760,6 +761,13 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name) >> return chan ? chan : ERR_PTR(-EPROBE_DEFER); >> >> found: >> +#ifdef CONFIG_DEBUG_FS >> + chan->slave_name = kasprintf(GFP_KERNEL, "%s:%s", dev_name(dev), name); >> + if (!chan->slave_name) >> + dev_warn(dev, >> + "Cannot allocate memory for slave name (debugfs)\n"); > > No need to print a message, as the memory allocation core already takes > care of that. Right. > But, do you really need chan->slave_name? > You already have chan->slave and chan->name. The chan->name is prefixed with "dma:" it would not look right. In production this all go away as debugfs most likely disabled. But I will change the name to dbg_client_name. > >> +#endif >> + >> chan->name = kasprintf(GFP_KERNEL, "dma:%s", name); >> if (!chan->name) { >> dev_warn(dev, > >> @@ -1562,3 +1577,108 @@ static int __init dma_bus_init(void) >> return class_register(&dma_devclass); >> } >> arch_initcall(dma_bus_init); >> + >> +#ifdef CONFIG_DEBUG_FS >> +static void *dmaengine_seq_start(struct seq_file *s, loff_t *pos) >> +{ >> + struct dma_device *dma_dev = NULL; >> + loff_t index = *pos; >> + >> + s->private = ""; >> + >> + mutex_lock(&dma_list_mutex); >> + list_for_each_entry(dma_dev, &dma_device_list, global_node) >> + if (index-- == 0) { >> + mutex_unlock(&dma_list_mutex); >> + return dma_dev; > > Can the dma_device go away after unlocking the list? > Unlike dma_request_chan(), this doesn't increase a refcnt. It could, let me see what I can do. Probably locking the dma_device_list for the duration of the show. >> + } >> + mutex_unlock(&dma_list_mutex); >> + >> + return NULL; >> +} >> + >> +static void *dmaengine_seq_next(struct seq_file *s, void *v, loff_t *pos) >> +{ >> + struct dma_device *dma_dev = v; >> + void *ret = NULL; >> + >> + mutex_lock(&dma_list_mutex); >> + if (list_is_last(&dma_dev->global_node, &dma_device_list)) >> + ret = NULL; >> + else >> + ret = list_entry(dma_dev->global_node.next, >> + struct dma_device, global_node); >> + mutex_unlock(&dma_list_mutex); > > Likewise. > >> + >> + s->private = "\n"; >> + ++*pos; >> + >> + return ret; >> +} >> + >> +static void dmaengine_seq_stop(struct seq_file *s, void *v) >> +{ >> +} >> + >> +static void dmaengine_dbg_show(struct seq_file *s, struct dma_device *dma_dev) >> +{ >> + struct dma_chan *chan; >> + >> + list_for_each_entry(chan, &dma_dev->channels, device_node) { >> + if (chan->client_count) { >> + seq_printf(s, " dma%dchan%d:", dma_dev->dev_id, >> + chan->chan_id); >> + if (chan->slave_name) >> + seq_printf(s, "\t\t%s\n", chan->slave_name); >> + else >> + seq_printf(s, "\t\t%s\n", "in-use"); > > The truncated ternary operator might help here: > > seq_printf(s, "\t\t%s\n", chan->slave_name ?: "in-use"); > > However, you might as well just use dev_name(chan->slave) and chan->name > instead of chan->slave_name. "2b00000.mcasp" + "dma:tx" would be an awkward combination ;) > >> + } >> + } >> +} >> + >> +static int dmaengine_seq_show(struct seq_file *s, void *v) >> +{ >> + struct dma_device *dma_dev = v; >> + >> + seq_printf(s, "%sdma%d (%s): number of channels: %u\n", >> + (char *)s->private, dma_dev->dev_id, dev_name(dma_dev->dev), >> + dma_dev->chancnt); >> + >> + if (dma_dev->dbg_show) >> + dma_dev->dbg_show(s, dma_dev); > > So providing a custom .dbg_show() means replacing the standard info, not > augmenting it? Correct, if a DMA driver decides to implement it, then it is it's responsibility to show things after the "dma%d (%s): number of channels: %u\n" line. The standard infor is pretty minimal and not sure if it can be more verbose. Oh, I can add the router information if it is used. > >> + else >> + dmaengine_dbg_show(s, dma_dev); >> + >> + return 0; >> +} > > Gr{oetje,eeting}s, > > Geert > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki