Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932214AbbHFMWv (ORCPT ); Thu, 6 Aug 2015 08:22:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49906 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755143AbbHFMWu (ORCPT ); Thu, 6 Aug 2015 08:22:50 -0400 Subject: Re: [PATCH] QEMU fw_cfg DMA interface documentation To: Stefan Hajnoczi , =?UTF-8?Q?Marc_Mar=c3=ad?= References: <1438858816-29385-1-git-send-email-markmb@redhat.com> <1438858987-29566-1-git-send-email-markmb@redhat.com> Cc: linux-kernel , Drew , "Kevin O'Connor" , Gerd Hoffmann From: Laszlo Ersek Message-ID: <55C35194.60308@redhat.com> Date: Thu, 6 Aug 2015 14:22:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3607 Lines: 92 On 08/06/15 14:12, Stefan Hajnoczi wrote: > On Thu, Aug 6, 2015 at 12:03 PM, Marc Marí wrote: >> Add fw_cfg DMA interface specfication in the fw_cfg documentation. >> >> Signed-off-by: Marc Marí >> --- >> Documentation/devicetree/bindings/arm/fw-cfg.txt | 36 ++++++++++++++++++++++++ >> 1 file changed, 36 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt b/Documentation/devicetree/bindings/arm/fw-cfg.txt >> index 953fb64..c880eec 100644 >> --- a/Documentation/devicetree/bindings/arm/fw-cfg.txt >> +++ b/Documentation/devicetree/bindings/arm/fw-cfg.txt >> @@ -49,6 +49,41 @@ The guest kernel is not expected to use these registers (although it is > > Please update the "=== Revision (Key 0x0001, FW_CFG_ID) ===" section > to say that currently the revision is 2. Sorry I haven't started reading the series yet, but this caught my eye -- can we agree that this field should be a bitmap instead, and not a counter-like value? I don't insist of course, because for the current use case both approaches will work. But, for "future proofing", I think it is useful to express features independently of each other. (See eg. virtio feature flags.) Just an idea. Thanks Laszlo > >> certainly allowed to); the device tree bindings are documented here because >> this is where device tree bindings reside in general. >> >> +Starting from revision 2, a DMA interface has also been added. This can be used >> +through a write-only, 64-bit wide address register. >> + >> +In this register, a pointer to a FWCfgDmaAccess structure can be written, in > > s/pointer/physical RAM address/ is clearer > >> +big endian mode. This is the format of the FWCfgDmaAccess structure: > > Please be explicit about the *order* of 32-bit writes to the 64-bit > DMA register. > > Big-endian only defines the layout of bits but it doesn't say in which > order the two 32-bit sub-registers need to be written. > >> +typedef struct FWCfgDmaAccess { >> + uint64_t address; >> + uint32_t length; >> + uint32_t control; >> +} FWCfgDmaAccess; >> + >> +Once the address to this structure has been written, an DMA operation is >> +started. If the "control" field has value 2, a read operation will be performed. >> +"length" bytes for the current selector and offset will be mapped into the >> +address specified by the "address" field. > > "mapped" might be confusing. "Copied" or "DMAed" is clearer. > >> +If the field "address" has value 0, the read is considered a skip, and >> +the data is not copied anywhere, but the offset is still incremented. >> + >> +To check result, read the control register: > > FWCfgDmaAccess.control is not a register, it's a field. > > s/register/field/ > >> + error bit set -> something went wrong. > > Which bit number is the error bit? > >> + all bits cleared -> transfer finished successfully. >> + otherwise -> transfer still in progress (doesn't happen >> + today due to implementation not being async, >> + but may in the future). >> + >> +Target address goes up and transfer length goes down as the transfer >> +happens, so after a successful transfer the length register is zero >> +and the address register points right after the memory block written. > > s/register/field/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/