All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Rob Herring <robh+dt@kernel.org>, Robin Murphy <robin.murphy@arm.com>
Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	devicetree@vger.kernel.org, Matthias Brugger <mbrugger@suse.com>,
	Frank Rowand <frowand.list@gmail.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	etnaviv@lists.freedesktop.org,
	"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 
	<dmaengine@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Stefan Wahren <wahrenst@gmx.net>,
	james.quinlan@broadcom.com, linux-pci@vger.kernel.org,
	linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org,
	Dan Williams <dan.j.williams@intel.com>,
	freedreno <freedreno@lists.freedesktop.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Thu, 26 Sep 2019 12:44:53 +0200	[thread overview]
Message-ID: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> (raw)
In-Reply-To: <CAL_JsqKKYcHPnA80ZwLY=Sk3e5MqrimedUhWQ5+iuPZXQxYHdA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

> > > > Robin, have you looked into supporting multiple dma-ranges? It's the
> > > > next thing
> > > > we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in
> > > > the
> > > > works already.
> > > 
> > > Multiple dma-ranges as far as configuring inbound windows should work
> > > already other than the bug when there's any parent translation. But if
> > > you mean supporting multiple DMA offsets and masks per device in the
> > > DMA API, there's nothing in the works yet.

Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make
it with a single DMA mask though.

> > There's also the in-between step of making of_dma_get_range() return a
> > size based on all the dma-ranges entries rather than only the first one
> > - otherwise, something like [1] can lead to pretty unworkable default
> > masks. We implemented that when doing acpi_dma_get_range(), it's just
> > that the OF counterpart never caught up.
> 
> Right. I suppose we assume any holes in the ranges are addressable by
> the device but won't get used for other reasons (such as no memory
> there). However, to be correct, the range of the dma offset plus mask
> would need to be within the min start and max end addresses. IOW,
> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next
> power of 2, the 'correct' thing to do is round down.

IIUC I also have this issue on my list. The RPi4 PCIe block has an integration
bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000
you get a 32bit DMA mask wich is not what you need. So far I faked it in the
device-tree but I guess it be better to add an extra check in
of_dma_configure(), decrease the mask and print some kind of warning stating
that DMA addressing is suboptimal.

Regards,
Nicolas

[1] https://lkml.org/lkml/2018/9/19/641


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne-l3A5Bk7waGM@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Matthias Brugger <mbrugger-IBi9RG/b67k@public.gmane.org>,
	linux-arm-msm
	<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-wireless
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	etnaviv-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Florian Fainelli
	<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Stefan Wahren <wahrenst-hi6Y0CQ0nG0@public.gmane.org>,
	james.quinlan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
	<dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org,
	Dan Williams
	<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	freedreno
	<freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Frank Rowand
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Linux Media Mailing List
	<linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Thu, 26 Sep 2019 12:44:53 +0200	[thread overview]
Message-ID: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> (raw)
In-Reply-To: <CAL_JsqKKYcHPnA80ZwLY=Sk3e5MqrimedUhWQ5+iuPZXQxYHdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

> > > > Robin, have you looked into supporting multiple dma-ranges? It's the
> > > > next thing
> > > > we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in
> > > > the
> > > > works already.
> > > 
> > > Multiple dma-ranges as far as configuring inbound windows should work
> > > already other than the bug when there's any parent translation. But if
> > > you mean supporting multiple DMA offsets and masks per device in the
> > > DMA API, there's nothing in the works yet.

Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make
it with a single DMA mask though.

> > There's also the in-between step of making of_dma_get_range() return a
> > size based on all the dma-ranges entries rather than only the first one
> > - otherwise, something like [1] can lead to pretty unworkable default
> > masks. We implemented that when doing acpi_dma_get_range(), it's just
> > that the OF counterpart never caught up.
> 
> Right. I suppose we assume any holes in the ranges are addressable by
> the device but won't get used for other reasons (such as no memory
> there). However, to be correct, the range of the dma offset plus mask
> would need to be within the min start and max end addresses. IOW,
> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next
> power of 2, the 'correct' thing to do is round down.

IIUC I also have this issue on my list. The RPi4 PCIe block has an integration
bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000
you get a 32bit DMA mask wich is not what you need. So far I faked it in the
device-tree but I guess it be better to add an extra check in
of_dma_configure(), decrease the mask and print some kind of warning stating
that DMA addressing is suboptimal.

Regards,
Nicolas

[1] https://lkml.org/lkml/2018/9/19/641


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Rob Herring <robh+dt@kernel.org>, Robin Murphy <robin.murphy@arm.com>
Cc: devicetree@vger.kernel.org, Matthias Brugger <mbrugger@suse.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Stefan Wahren <wahrenst@gmx.net>,
	james.quinlan@broadcom.com, linux-pci@vger.kernel.org,
	"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
	<dmaengine@vger.kernel.org>,
	xen-devel@lists.xenproject.org,
	Dan Williams <dan.j.williams@intel.com>,
	freedreno <freedreno@lists.freedesktop.org>,
	Frank Rowand <frowand.list@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Thu, 26 Sep 2019 12:44:53 +0200	[thread overview]
Message-ID: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> (raw)
In-Reply-To: <CAL_JsqKKYcHPnA80ZwLY=Sk3e5MqrimedUhWQ5+iuPZXQxYHdA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

> > > > Robin, have you looked into supporting multiple dma-ranges? It's the
> > > > next thing
> > > > we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in
> > > > the
> > > > works already.
> > > 
> > > Multiple dma-ranges as far as configuring inbound windows should work
> > > already other than the bug when there's any parent translation. But if
> > > you mean supporting multiple DMA offsets and masks per device in the
> > > DMA API, there's nothing in the works yet.

Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make
it with a single DMA mask though.

> > There's also the in-between step of making of_dma_get_range() return a
> > size based on all the dma-ranges entries rather than only the first one
> > - otherwise, something like [1] can lead to pretty unworkable default
> > masks. We implemented that when doing acpi_dma_get_range(), it's just
> > that the OF counterpart never caught up.
> 
> Right. I suppose we assume any holes in the ranges are addressable by
> the device but won't get used for other reasons (such as no memory
> there). However, to be correct, the range of the dma offset plus mask
> would need to be within the min start and max end addresses. IOW,
> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next
> power of 2, the 'correct' thing to do is round down.

IIUC I also have this issue on my list. The RPi4 PCIe block has an integration
bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000
you get a 32bit DMA mask wich is not what you need. So far I faked it in the
device-tree but I guess it be better to add an extra check in
of_dma_configure(), decrease the mask and print some kind of warning stating
that DMA addressing is suboptimal.

Regards,
Nicolas

[1] https://lkml.org/lkml/2018/9/19/641


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Rob Herring <robh+dt@kernel.org>, Robin Murphy <robin.murphy@arm.com>
Cc: devicetree@vger.kernel.org, Matthias Brugger <mbrugger@suse.com>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Stefan Wahren <wahrenst@gmx.net>,
	james.quinlan@broadcom.com, linux-pci@vger.kernel.org,
	"open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
	<dmaengine@vger.kernel.org>,
	xen-devel@lists.xenproject.org,
	Dan Williams <dan.j.williams@intel.com>,
	freedreno <freedreno@lists.freedesktop.org>,
	Frank Rowand <frowand.list@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Thu, 26 Sep 2019 12:44:53 +0200	[thread overview]
Message-ID: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> (raw)
In-Reply-To: <CAL_JsqKKYcHPnA80ZwLY=Sk3e5MqrimedUhWQ5+iuPZXQxYHdA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1872 bytes --]

> > > > Robin, have you looked into supporting multiple dma-ranges? It's the
> > > > next thing
> > > > we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in
> > > > the
> > > > works already.
> > > 
> > > Multiple dma-ranges as far as configuring inbound windows should work
> > > already other than the bug when there's any parent translation. But if
> > > you mean supporting multiple DMA offsets and masks per device in the
> > > DMA API, there's nothing in the works yet.

Sorry, I meant supporting multiple DMA offsets[1]. I think I could still make
it with a single DMA mask though.

> > There's also the in-between step of making of_dma_get_range() return a
> > size based on all the dma-ranges entries rather than only the first one
> > - otherwise, something like [1] can lead to pretty unworkable default
> > masks. We implemented that when doing acpi_dma_get_range(), it's just
> > that the OF counterpart never caught up.
> 
> Right. I suppose we assume any holes in the ranges are addressable by
> the device but won't get used for other reasons (such as no memory
> there). However, to be correct, the range of the dma offset plus mask
> would need to be within the min start and max end addresses. IOW,
> while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next
> power of 2, the 'correct' thing to do is round down.

IIUC I also have this issue on my list. The RPi4 PCIe block has an integration
bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0000
you get a 32bit DMA mask wich is not what you need. So far I faked it in the
device-tree but I guess it be better to add an extra check in
of_dma_configure(), decrease the mask and print some kind of warning stating
that DMA addressing is suboptimal.

Regards,
Nicolas

[1] https://lkml.org/lkml/2018/9/19/641


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-09-26 10:45 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 18:12 [PATCH 00/11] of: Fix DMA configuration for non-DT masters Nicolas Saenz Julienne
2019-09-24 18:12 ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12 ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 01/11] of: address: clean-up unused variable in of_dma_get_range() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 02/11] of: base: introduce __of_n_*_cells_parent() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 03/11] of: address: use parent DT node in bus->count_cells() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 04/11] of: address: introduce of_translate_dma_address_parent() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 05/11] of: expose __of_get_dma_parent() to OF subsystem Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 06/11] of: address: use parent OF node in of_dma_get_range() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 07/11] dts: arm64: layerscape: add dma-ranges property to qoric-mc node Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-10-14  8:28   ` Shawn Guo
2019-10-14  8:28     ` [Xen-devel] " Shawn Guo
2019-10-14  8:28     ` Shawn Guo
2019-10-14 10:00     ` Nicolas Saenz Julienne
2019-10-14 10:00       ` [Xen-devel] " Nicolas Saenz Julienne
2019-10-14 10:00       ` Nicolas Saenz Julienne
2019-10-14 11:09       ` Shawn Guo
2019-10-14 11:09         ` [Xen-devel] " Shawn Guo
2019-10-14 11:09         ` Shawn Guo
2019-10-14 11:09         ` Shawn Guo
2019-09-24 18:12 ` [PATCH 08/11] dts: arm64: layerscape: add dma-ranges property to pcie nodes Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-10-14  8:29   ` Shawn Guo
2019-10-14  8:29     ` [Xen-devel] " Shawn Guo
2019-10-14  8:29     ` Shawn Guo
2019-09-24 18:12 ` [PATCH 09/11] of: device: remove comment in of_dma_configure() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 10/11] of: device: introduce of_dma_configure_parent() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 11/11] of: simplify of_dma_config()'s arguments Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 21:59 ` [PATCH 00/11] of: Fix DMA configuration for non-DT masters Rob Herring
2019-09-24 21:59   ` [Xen-devel] " Rob Herring
2019-09-24 21:59   ` Rob Herring
2019-09-24 21:59   ` Rob Herring
2019-09-25 14:52   ` Nicolas Saenz Julienne
2019-09-25 14:52     ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-25 14:52     ` Nicolas Saenz Julienne
2019-09-25 14:52     ` Nicolas Saenz Julienne
2019-09-25 15:09     ` Robin Murphy
2019-09-25 15:09       ` [Xen-devel] " Robin Murphy
2019-09-25 15:09       ` Robin Murphy
2019-09-25 15:09       ` Robin Murphy
2019-09-25 15:30       ` Nicolas Saenz Julienne
2019-09-25 15:30         ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-25 15:30         ` Nicolas Saenz Julienne
2019-09-25 15:30         ` Nicolas Saenz Julienne
2019-09-25 16:16         ` Rob Herring
2019-09-25 16:16           ` [Xen-devel] " Rob Herring
2019-09-25 16:16           ` Rob Herring
2019-09-25 16:16           ` Rob Herring
2019-09-25 16:52           ` Robin Murphy
2019-09-25 16:52             ` [Xen-devel] " Robin Murphy
2019-09-25 16:52             ` Robin Murphy
2019-09-25 16:52             ` Robin Murphy
2019-09-25 21:33             ` Rob Herring
2019-09-25 21:33               ` [Xen-devel] " Rob Herring
2019-09-25 21:33               ` Rob Herring
2019-09-25 21:33               ` Rob Herring
2019-09-26 10:44               ` Nicolas Saenz Julienne [this message]
2019-09-26 10:44                 ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-26 10:44                 ` Nicolas Saenz Julienne
2019-09-26 10:44                 ` Nicolas Saenz Julienne
2019-09-26 11:20                 ` Robin Murphy
2019-09-26 11:20                   ` [Xen-devel] " Robin Murphy
2019-09-26 11:20                   ` Robin Murphy
2019-09-26 11:20                   ` Robin Murphy
2019-10-02 18:28                   ` Florian Fainelli
2019-10-02 18:28                     ` [Xen-devel] " Florian Fainelli
2019-10-02 18:28                     ` Florian Fainelli
2019-10-02 18:28                     ` Florian Fainelli
2019-09-25 16:07     ` Rob Herring
2019-09-25 16:07       ` [Xen-devel] " Rob Herring
2019-09-25 16:07       ` Rob Herring
2019-09-25 16:07       ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=f.fainelli@gmail.com \
    --cc=freedreno@lists.freedesktop.org \
    --cc=frowand.list@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mbrugger@suse.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=wahrenst@gmx.net \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.