Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1237358 > unrolled thread

[PATCH v4] QEMU fw_cfg DMA interface documentation

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v4] QEMU fw_cfg DMA interface documentation Marc Marí <markmb@redhat.com> - 2015-10-01 14:20 +0200
    Re: [PATCH v4] QEMU fw_cfg DMA interface documentation Stefan Hajnoczi <stefanha@gmail.com> - 2015-10-05 10:30 +0200
      Re: [PATCH v4] QEMU fw_cfg DMA interface documentation Marc Marí <markmb@redhat.com> - 2015-10-05 12:10 +0200
        Re: [PATCH v4] QEMU fw_cfg DMA interface documentation Stefan Hajnoczi <stefanha@gmail.com> - 2015-10-05 12:20 +0200

#1237358 — [PATCH v4] QEMU fw_cfg DMA interface documentation

Add fw_cfg DMA interface specfication in the fw_cfg documentation.

Signed-off-by: Marc Marí <markmb@redhat.com>
---
 Documentation/devicetree/bindings/arm/fw-cfg.txt | 52 +++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt b/Documentation/devicetree/bindings/arm/fw-cfg.txt
index 953fb64..10cd81c 100644
--- a/Documentation/devicetree/bindings/arm/fw-cfg.txt
+++ b/Documentation/devicetree/bindings/arm/fw-cfg.txt
@@ -38,6 +38,9 @@ The presence of the registers can be verified by selecting the "signature" blob
 with key 0x0000, and reading four bytes from the data register. The returned
 signature is "QEMU".
 
+Additionaly, if the DMA interface is available then a read to the DMA Address
+will return 0x51454d5520434647 ("QEMU CFG" in big-endian format).
+
 The outermost protocol (involving the write / read sequences of the control and
 data registers) is expected to be versioned, and/or described by feature bits.
 The interface revision / feature bitmap can be retrieved with key 0x0001. The
@@ -45,6 +48,51 @@ blob to be read from the data register has size 4, and it is to be interpreted
 as a uint32_t value in little endian byte order. The current value
 (corresponding to the above outer protocol) is zero.
 
+If bit 1 of the feature bitmap is set, the DMA interface is present. This
+can be used through the 64-bit wide address register.
+
+The address register is in big-endian format. The value for the register is 0
+at startup and after an operation. A write to the lower half triggers an
+operation. This means, that operations with 32-bit addresses can be triggered
+with just one write, whereas operations with 64-bit addresses can be triggered
+with one 64-bit write or two 32-bit writes, starting with the higher part.
+
+In this register, the physical address of a FWCfgDmaAccess structure in RAM
+should be written. This is the format of the FWCfgDmaAccess structure:
+
+typedef struct FWCfgDmaAccess {
+    uint32_t control;
+    uint32_t length;
+    uint64_t address;
+} FWCfgDmaAccess;
+
+The fields of the structure are in big endian mode, and the field at the lowest
+address is the "control" field.
+
+The "control" field has the following bits:
+ - Bit 0: Error
+ - Bit 1: Read
+ - Bit 2: Skip
+ - Bit 3: Select. The upper 16 bits are the selected index.
+
+When an operation is triggered, if the "control" field has bit 3 set, the
+upper 16 bits are interpreted as an index of a firmware configuration item.
+This has the same effect as writing the selector register.
+
+If the "control" field has bit 1 set, a read operation will be performed.
+"length" bytes for the current selector and offset will be copied into the
+physical RAM address specified by the "address" field.
+
+If the "control" field has bit 2 set (and not bit 1), a skip operation will be
+performed. The offset for the current selector will be advanced "length" bytes.
+
+To check the result, read the "control" field:
+   error bit set        ->  something went wrong.
+   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).
+
 The guest kernel is not expected to use these registers (although it is
 certainly allowed to); the device tree bindings are documented here because
 this is where device tree bindings reside in general.
@@ -56,6 +104,8 @@ Required properties:
 - reg: the MMIO region used by the device.
   * Bytes 0x0 to 0x7 cover the data register.
   * Bytes 0x8 to 0x9 cover the selector register.
+  * With DMA interface enabled: Bytes 0x10 to 0x17 cover the DMA address
+    register.
   * Further registers may be appended to the region in case of future interface
     revisions / feature bits.
 
@@ -66,7 +116,7 @@ Example:
 	#address-cells = <0x2>;
 
 	fw-cfg@9020000 {
+		reg = <0x0 0x9020000 0x0 0x18>;
 		compatible = "qemu,fw-cfg-mmio";
-		reg = <0x0 0x9020000 0x0 0xa>;
 	};
 };
-- 
2.4.3

--
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/

[toc] | [next] | [standalone]

#1239344

On Thu, Oct 1, 2015 at 1:15 PM, Marc Marí <markmb@redhat.com> wrote:
> +Additionaly, if the DMA interface is available then a read to the DMA Address
> +will return 0x51454d5520434647 ("QEMU CFG" in big-endian format).

What does this mean?

Stefan
--
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/

[toc] | [prev] | [next] | [standalone]

#1239411

On Mon, 5 Oct 2015 09:20:55 +0100
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Thu, Oct 1, 2015 at 1:15 PM, Marc Marí <markmb@redhat.com> wrote:
> > +Additionaly, if the DMA interface is available then a read to the
> > DMA Address +will return 0x51454d5520434647 ("QEMU CFG" in
> > big-endian format).
> 
> What does this mean?
>

https://www.mail-archive.com/qemu-devel@nongnu.org/msg325546.html

Proposed by Kevin O'Connor in v3.

(I could not find this thread in gnu.org or gmane archives. It's
strange).

Thanks
Marc
--
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/

[toc] | [prev] | [next] | [standalone]

#1239419

On Mon, Oct 5, 2015 at 11:06 AM, Marc Marí <markmb@redhat.com> wrote:
> On Mon, 5 Oct 2015 09:20:55 +0100
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
>> On Thu, Oct 1, 2015 at 1:15 PM, Marc Marí <markmb@redhat.com> wrote:
>> > +Additionaly, if the DMA interface is available then a read to the
>> > DMA Address +will return 0x51454d5520434647 ("QEMU CFG" in
>> > big-endian format).
>>
>> What does this mean?
>>
>
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg325546.html
>
> Proposed by Kevin O'Connor in v3.
>
> (I could not find this thread in gnu.org or gmane archives. It's
> strange).

The following is clearer to me:

If the DMA interface is available, then reading the DMA Address
Register returns 0x51454d5520434647 ("QEMU CFG" in big-endian format).

Stefan
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web