From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759666AbbJ3SZu (ORCPT ); Fri, 30 Oct 2015 14:25:50 -0400 Received: from foss.arm.com ([217.140.101.70]:45244 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758766AbbJ3SZt (ORCPT ); Fri, 30 Oct 2015 14:25:49 -0400 Date: Fri, 30 Oct 2015 18:25:37 +0000 From: Mark Rutland To: Andy Shevchenko Cc: Sinan Kaya , dmaengine , timur@codeaurora.org, cov@codeaurora.org, jcm@redhat.com, Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , Vinod Koul , Dan Williams , devicetree , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver Message-ID: <20151030182537.GB30791@leverpostej> References: <1446174501-8870-1-git-send-email-okaya@codeaurora.org> <20151030150025.GF31073@leverpostej> <5633B207.5030505@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 30, 2015 at 08:18:49PM +0200, Andy Shevchenko wrote: > On Fri, Oct 30, 2015 at 8:08 PM, Sinan Kaya wrote: > > >> The ACPI tables DSDT and CSRT (more info here: > >> http://www.acpi.info/links.htm) defines properties. > >> > >> DSDT: > >> per DMAC: the resources > >> per client: FixedDMA descriptor that contains channel / request line > >> pair. > >> > >> CSRT: > >> necessary table to map which DMAC provides which request line, thus > >> request line numbering are global on platform. > >> > >> When DMAC driver is probed in the running system it should call as > >> well registration function from acpi-dma.c. > >> > >> All clients when use new DMA slave API gets channel automatically > >> based on their FixedDMA property. > >> > >> So, above is how it should be done. Didn't actually checked what this > >> driver does. > >> > > I was going to reply to all the questions in one pass but let me handle > > piece by piece. > > > > Here are some facts. > > - This hardware supports memcpy and memset only. > > - Memset feature was removed from the kernel sometime around 3.14. So no > > memset support in this driver either. > > - The hardware does not support DMA slave support > > - The goal is to provide an interface to DMA engine framework for memcpy > > optimization so that the rest of the kernel drivers and applications make > > use of the hardware. > > > > > CSRT is an Intel specific ACPI table for slave devices. > > Wrong. > It was designed by Microsoft to support multiple controllers, in > particular DMACs. > Have you read that document I posted link to? > > > It was decided by > > Linaro that CSRT will not be supported for ARM64. > > Interesting, ARM64 platforms are not going to have more than one DMAC > per system? I cannot imagine that being true, and I don't see why Linaro would decide such a thing. It does appear that it's not relevant to this device and driver, given the lack of clients, unless I've misunderstood? Thanks, Mark.