From: Marek Vasut <marex@denx.de>
To: Michal Suchanek <hramrach@gmail.com>
Cc: "Vinod Koul" <vinod.koul@intel.com>,
"Brian Norris" <computersforpeace@gmail.com>,
"Richard Cochran" <richardcochran@gmail.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Krzysztof Kozlowski" <k.kozlowski@samsung.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"MTD Maling List" <linux-mtd@lists.infradead.org>,
"Alison Chaiken" <alison_chaiken@mentor.com>,
"Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"Russell King" <linux@arm.linux.org.uk>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Kukjin Kim" <kgene@kernel.org>,
"Ben Hutchings" <ben@decadent.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Pawel Moll" <pawel.moll@arm.com>,
"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
"Kumar Gala" <galak@codeaurora.org>,
"Mark Brown" <broonie@kernel.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"grmoore@altera.com" <grmoore@altera.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
"Huang Shijie" <b32955@freescale.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Han Xu" <han.xu@freescale.com>,
"Knut Wohlrab" <knut.wohlrab@de.bosch.com>,
dmaengine <dmaengine@vger.kernel.org>,
"David Woodhouse" <dwmw2@infradead.org>
Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
Date: Wed, 22 Jul 2015 09:33:19 +0200 [thread overview]
Message-ID: <201507220933.19752.marex@denx.de> (raw)
In-Reply-To: <CAOMqctQH4MnKMthOnuPgB-A5k6PCOAmhwHzJfn7gE3R4w8bufg@mail.gmail.com>
On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote:
> On 22 July 2015 at 06:49, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote:
> >> > Or alternatively we could publish the limitations of the channel using
> >> > capabilities so SPI knows I have a dmaengine channel and it can
> >> > transfer max N length transfers so would be able to break rather than
> >> > guessing it or coding in DT. Yes it may come from DT but that should
> >> > be dmaengine driver rather than client driver :)
> >> >
> >> > This can be done by dma_get_slave_caps(chan, &caps)
> >> >
> >> > And we add max_length as one more parameter to existing set
> >> >
> >> > Also all this could be handled in generic SPI-dmaengine layer so that
> >> > individual drivers don't have to code it in
> >> >
> >> > Let me know if this idea is okay, I can push the dmaengine bits...
> >>
> >> It would be ok if there was a fixed limit. However, the limit depends
> >> on SPI slave settings. Presumably for other buses using the dmaengine
> >> the limit would depend on the bus or slave settings as well. I do not
> >> see a sane way of passing this all the way to the dmaengine driver.
> >
> > I don't see why this should be client (SPI) dependent. The max length
> > supported is a dmaengine constraint, typically flowing from max
> > blocks/length it can transfer. Know this limit can allow clients to split
> > transfers.
>
> In practice on the board I have the maximum transfer length before it
> fails depends on SPI bus speed which is set up per slave. I did not
> try searching the space of possible settings thorougly and settled for
> a setting that gives reasonable speed and transfer length.
This looks more like a signal integrity issue though.
> However, if this was not tied to the particular slave setting picked
> in the current DT a formula would be needed that translates arbitrary
> client settings to transfer size limit and there would be need to
> somehow get the client settings to the formula in the dmaengine
> driver.
>
> Thanks
>
> Michal
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Michal Suchanek <hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Vinod Koul" <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Brian Norris"
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Richard Cochran"
<richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Geert Uytterhoeven"
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
"Mark Rutland" <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"Krzysztof Kozlowski"
<k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
"Geert Uytterhoeven"
<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>,
"MTD Maling List"
<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"Alison Chaiken"
<alison_chaiken-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>,
"Bean Huo 霍斌斌 (beanhuo)"
<beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org>,
"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Russell King" <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
"Rafał Miłecki" <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Kukjin Kim" <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Ben Hutchings" <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Pawel Moll" <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
"Ian Campbell"
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
"Kumar Gala" <galak@codeaurora>
Subject: Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
Date: Wed, 22 Jul 2015 09:33:19 +0200 [thread overview]
Message-ID: <201507220933.19752.marex@denx.de> (raw)
In-Reply-To: <CAOMqctQH4MnKMthOnuPgB-A5k6PCOAmhwHzJfn7gE3R4w8bufg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote:
> On 22 July 2015 at 06:49, Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> > On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote:
> >> > Or alternatively we could publish the limitations of the channel using
> >> > capabilities so SPI knows I have a dmaengine channel and it can
> >> > transfer max N length transfers so would be able to break rather than
> >> > guessing it or coding in DT. Yes it may come from DT but that should
> >> > be dmaengine driver rather than client driver :)
> >> >
> >> > This can be done by dma_get_slave_caps(chan, &caps)
> >> >
> >> > And we add max_length as one more parameter to existing set
> >> >
> >> > Also all this could be handled in generic SPI-dmaengine layer so that
> >> > individual drivers don't have to code it in
> >> >
> >> > Let me know if this idea is okay, I can push the dmaengine bits...
> >>
> >> It would be ok if there was a fixed limit. However, the limit depends
> >> on SPI slave settings. Presumably for other buses using the dmaengine
> >> the limit would depend on the bus or slave settings as well. I do not
> >> see a sane way of passing this all the way to the dmaengine driver.
> >
> > I don't see why this should be client (SPI) dependent. The max length
> > supported is a dmaengine constraint, typically flowing from max
> > blocks/length it can transfer. Know this limit can allow clients to split
> > transfers.
>
> In practice on the board I have the maximum transfer length before it
> fails depends on SPI bus speed which is set up per slave. I did not
> try searching the space of possible settings thorougly and settled for
> a setting that gives reasonable speed and transfer length.
This looks more like a signal integrity issue though.
> However, if this was not tied to the particular slave setting picked
> in the current DT a formula would be needed that translates arbitrary
> client settings to transfer size limit and there would be need to
> somehow get the client settings to the formula in the dmaengine
> driver.
>
> Thanks
>
> Michal
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
Date: Wed, 22 Jul 2015 09:33:19 +0200 [thread overview]
Message-ID: <201507220933.19752.marex@denx.de> (raw)
In-Reply-To: <CAOMqctQH4MnKMthOnuPgB-A5k6PCOAmhwHzJfn7gE3R4w8bufg@mail.gmail.com>
On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote:
> On 22 July 2015 at 06:49, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote:
> >> > Or alternatively we could publish the limitations of the channel using
> >> > capabilities so SPI knows I have a dmaengine channel and it can
> >> > transfer max N length transfers so would be able to break rather than
> >> > guessing it or coding in DT. Yes it may come from DT but that should
> >> > be dmaengine driver rather than client driver :)
> >> >
> >> > This can be done by dma_get_slave_caps(chan, &caps)
> >> >
> >> > And we add max_length as one more parameter to existing set
> >> >
> >> > Also all this could be handled in generic SPI-dmaengine layer so that
> >> > individual drivers don't have to code it in
> >> >
> >> > Let me know if this idea is okay, I can push the dmaengine bits...
> >>
> >> It would be ok if there was a fixed limit. However, the limit depends
> >> on SPI slave settings. Presumably for other buses using the dmaengine
> >> the limit would depend on the bus or slave settings as well. I do not
> >> see a sane way of passing this all the way to the dmaengine driver.
> >
> > I don't see why this should be client (SPI) dependent. The max length
> > supported is a dmaengine constraint, typically flowing from max
> > blocks/length it can transfer. Know this limit can allow clients to split
> > transfers.
>
> In practice on the board I have the maximum transfer length before it
> fails depends on SPI bus speed which is set up per slave. I did not
> try searching the space of possible settings thorougly and settled for
> a setting that gives reasonable speed and transfer length.
This looks more like a signal integrity issue though.
> However, if this was not tied to the particular slave setting picked
> in the current DT a formula would be needed that translates arbitrary
> client settings to transfer size limit and there would be need to
> somehow get the client settings to the formula in the dmaengine
> driver.
>
> Thanks
>
> Michal
Best regards,
Marek Vasut
next prev parent reply other threads:[~2015-07-22 7:33 UTC|newest]
Thread overview: 242+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 21:26 [PATCH 00/11] Enable access to SPI NOR flash on Samsung Snow board Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` [PATCH 01/11] ARM: dt: Add SPI CS " Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-04 2:05 ` Krzysztof Kozlowski
2015-06-04 2:05 ` Krzysztof Kozlowski
2015-06-04 2:05 ` Krzysztof Kozlowski
2015-06-04 2:05 ` Krzysztof Kozlowski
[not found] ` <d47abe28c751b54b839d9340269a2c06a6e23a6c.1433364398.git.hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-06-04 2:05 ` Krzysztof Kozlowski
2015-06-04 6:52 ` Javier Martinez Canillas
2015-06-04 6:52 ` Javier Martinez Canillas
2015-06-04 6:52 ` Javier Martinez Canillas
2015-06-04 6:52 ` Javier Martinez Canillas
2015-06-03 21:26 ` [PATCH 02/11] mtd: spi-nor: Add GD25LQ32C 1.8V SPI NOR flash ID Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` [PATCH 05/11] mtd: mtdpart: Do not fail mtd probe when parsing partitions fails Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` [PATCH 04/11] mtd: ofpart: do not fail probe when no partitions exist Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 22:58 ` Marek Vasut
2015-06-03 22:58 ` Marek Vasut
2015-06-03 22:58 ` Marek Vasut
2015-06-03 22:58 ` Marek Vasut
2015-06-04 4:54 ` Michal Suchanek
2015-06-04 4:54 ` Michal Suchanek
2015-06-04 4:54 ` Michal Suchanek
2015-06-04 4:54 ` Michal Suchanek
2015-06-04 4:54 ` Michal Suchanek
2015-06-04 15:28 ` Marek Vasut
2015-06-04 15:28 ` Marek Vasut
2015-06-04 15:28 ` Marek Vasut
2015-06-04 15:28 ` Marek Vasut
2015-06-04 15:40 ` Michal Suchanek
2015-06-04 15:40 ` Michal Suchanek
2015-06-04 15:40 ` Michal Suchanek
2015-06-04 15:40 ` Michal Suchanek
2015-06-04 15:40 ` Michal Suchanek
2015-06-05 14:13 ` Marek Vasut
2015-06-05 14:13 ` Marek Vasut
2015-06-05 14:13 ` Marek Vasut
2015-06-05 14:13 ` Marek Vasut
2015-06-23 18:26 ` Brian Norris
2015-06-23 18:26 ` Brian Norris
2015-06-23 18:26 ` Brian Norris
2015-06-23 18:26 ` Brian Norris
2015-06-03 21:26 ` [PATCH 03/11] mtd: add debug prints to mtdpart partition parser Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 23:03 ` Marek Vasut
2015-06-03 23:03 ` Marek Vasut
2015-06-03 23:03 ` Marek Vasut
2015-06-03 23:03 ` Marek Vasut
2015-06-04 4:31 ` Michal Suchanek
2015-06-04 4:31 ` Michal Suchanek
2015-06-04 4:31 ` Michal Suchanek
2015-06-04 4:31 ` Michal Suchanek
2015-06-04 4:31 ` Michal Suchanek
2015-06-04 15:15 ` Marek Vasut
2015-06-04 15:15 ` Marek Vasut
2015-06-04 15:15 ` Marek Vasut
2015-06-04 15:15 ` Marek Vasut
2015-06-04 6:42 ` Geert Uytterhoeven
2015-06-04 6:42 ` Geert Uytterhoeven
2015-06-04 6:42 ` Geert Uytterhoeven
2015-06-04 6:42 ` Geert Uytterhoeven
2015-06-04 8:31 ` Michal Suchanek
2015-06-04 8:31 ` Michal Suchanek
2015-06-04 8:31 ` Michal Suchanek
2015-06-04 8:31 ` Michal Suchanek
2015-06-04 17:15 ` Richard Cochran
2015-06-04 17:15 ` Richard Cochran
2015-06-04 17:15 ` Richard Cochran
2015-06-04 17:15 ` Richard Cochran
2015-07-15 9:45 ` Michal Suchanek
2015-07-15 9:45 ` Michal Suchanek
2015-07-15 9:45 ` Michal Suchanek
2015-07-15 11:52 ` Marek Vasut
2015-07-15 11:52 ` Marek Vasut
2015-07-15 11:52 ` Marek Vasut
2015-07-15 15:59 ` Brian Norris
2015-07-15 15:59 ` Brian Norris
2015-07-15 15:59 ` Brian Norris
2015-07-15 15:59 ` Brian Norris
2015-07-15 17:15 ` Marek Vasut
2015-07-15 17:15 ` Marek Vasut
2015-07-15 17:15 ` Marek Vasut
2015-07-16 1:19 ` Brian Norris
2015-07-16 1:19 ` Brian Norris
2015-07-16 1:19 ` Brian Norris
2015-07-16 1:44 ` Marek Vasut
2015-07-16 1:44 ` Marek Vasut
2015-07-16 1:44 ` Marek Vasut
2015-07-19 19:01 ` Michal Suchanek
2015-07-19 19:01 ` Michal Suchanek
2015-07-19 19:01 ` Michal Suchanek
2015-07-21 4:29 ` Vinod Koul
2015-07-21 4:29 ` Vinod Koul
2015-07-21 4:29 ` Vinod Koul
2015-07-21 8:14 ` Michal Suchanek
2015-07-21 8:14 ` Michal Suchanek
2015-07-21 8:14 ` Michal Suchanek
2015-07-22 4:49 ` Vinod Koul
2015-07-22 4:49 ` Vinod Koul
2015-07-22 4:49 ` Vinod Koul
2015-07-22 7:30 ` Michal Suchanek
2015-07-22 7:30 ` Michal Suchanek
2015-07-22 7:30 ` Michal Suchanek
2015-07-22 7:33 ` Marek Vasut [this message]
2015-07-22 7:33 ` Marek Vasut
2015-07-22 7:33 ` Marek Vasut
2015-07-22 7:45 ` Michal Suchanek
2015-07-22 7:45 ` Michal Suchanek
2015-07-22 7:45 ` Michal Suchanek
2015-07-22 7:58 ` Marek Vasut
2015-07-22 7:58 ` Marek Vasut
2015-07-22 7:58 ` Marek Vasut
2015-07-22 8:18 ` Michal Suchanek
2015-07-22 8:18 ` Michal Suchanek
2015-07-22 8:18 ` Michal Suchanek
2015-07-22 8:24 ` Marek Vasut
2015-07-22 8:24 ` Marek Vasut
2015-07-22 8:24 ` Marek Vasut
2015-07-22 8:38 ` Michal Suchanek
2015-07-22 8:38 ` Michal Suchanek
2015-07-22 8:38 ` Michal Suchanek
2015-07-22 9:01 ` Marek Vasut
2015-07-22 9:01 ` Marek Vasut
2015-07-22 9:01 ` Marek Vasut
2015-07-23 16:46 ` Michal Suchanek
2015-07-23 16:46 ` Michal Suchanek
2015-07-23 17:03 ` Michal Suchanek
2015-07-23 17:03 ` Michal Suchanek
2015-07-24 8:34 ` Marek Vasut
2015-07-24 8:34 ` Marek Vasut
2015-07-24 11:20 ` Michal Suchanek
2015-07-24 11:20 ` Michal Suchanek
2015-07-27 9:46 ` Michal Suchanek
2015-07-27 9:46 ` Michal Suchanek
2015-07-27 9:46 ` Michal Suchanek
2015-07-27 17:43 ` Marek Vasut
2015-07-27 17:43 ` Marek Vasut
2015-07-27 20:43 ` Michal Suchanek
2015-07-27 20:43 ` Michal Suchanek
2015-07-27 20:43 ` Michal Suchanek
2015-07-30 11:24 ` Marek Vasut
2015-07-30 11:24 ` Marek Vasut
2015-07-30 12:18 ` Michal Suchanek
2015-07-30 12:18 ` Michal Suchanek
2015-07-30 12:33 ` Marek Vasut
2015-07-30 12:33 ` Marek Vasut
2015-07-30 12:33 ` Marek Vasut
2015-06-03 21:26 ` [PATCH 09/11] dma: pl330: fix wording in mcbufsz message Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-04 2:10 ` Krzysztof Kozlowski
2015-06-04 2:10 ` Krzysztof Kozlowski
2015-06-04 2:10 ` Krzysztof Kozlowski
2015-06-04 2:10 ` Krzysztof Kozlowski
2015-06-08 11:07 ` Vinod Koul
2015-06-08 11:07 ` Vinod Koul
2015-06-08 11:07 ` Vinod Koul
2015-06-08 11:07 ` Vinod Koul
2015-06-03 21:26 ` [PATCH 07/11] mtd: spi-nor: rework write loop Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` [PATCH 06/11] mtd: spi-nor: rework spi nor read and write Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` [PATCH 11/11] dt: Exynos: add Snow SPI NOR node Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-04 2:04 ` Krzysztof Kozlowski
2015-06-04 2:04 ` Krzysztof Kozlowski
2015-06-04 2:04 ` Krzysztof Kozlowski
2015-06-04 15:20 ` Marek Vasut
2015-06-04 15:20 ` Marek Vasut
2015-06-04 15:20 ` Marek Vasut
2015-06-04 15:20 ` Marek Vasut
2015-06-04 15:20 ` Marek Vasut
2015-06-17 12:19 ` Pavel Machek
2015-06-17 12:19 ` Pavel Machek
2015-06-17 12:19 ` Pavel Machek
2015-06-17 12:19 ` Pavel Machek
[not found] ` <3234c12c90eabbeeb6d33604a324231937e309ec.1433364398.git.hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-06-04 2:04 ` Krzysztof Kozlowski
2015-06-03 21:26 ` [PATCH 10/11] spi: add more debug prints in s3c64xx Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 21:26 ` Michal Suchanek
2015-06-03 23:04 ` Marek Vasut
2015-06-03 23:04 ` Marek Vasut
2015-06-03 23:04 ` Marek Vasut
2015-06-03 23:04 ` Marek Vasut
2015-06-04 9:16 ` Mark Brown
2015-06-04 9:16 ` Mark Brown
2015-06-04 9:16 ` Mark Brown
2015-06-04 9:16 ` Mark Brown
2015-06-04 9:30 ` Geert Uytterhoeven
2015-06-04 9:30 ` Geert Uytterhoeven
2015-06-04 9:30 ` Geert Uytterhoeven
2015-06-04 9:30 ` Geert Uytterhoeven
2015-06-04 9:42 ` Mark Brown
2015-06-04 9:42 ` Mark Brown
2015-06-04 9:42 ` Mark Brown
2015-06-04 9:42 ` Mark Brown
2015-06-04 9:33 ` Michal Suchanek
2015-06-04 9:33 ` Michal Suchanek
2015-06-04 9:33 ` Michal Suchanek
2015-06-04 9:33 ` Michal Suchanek
2015-06-04 9:33 ` Michal Suchanek
2015-06-04 10:26 ` Mark Brown
2015-06-04 10:26 ` Mark Brown
2015-06-04 10:26 ` Mark Brown
2015-06-04 10:26 ` Mark Brown
2015-06-04 10:52 ` Michal Suchanek
2015-06-04 10:52 ` Michal Suchanek
2015-06-04 10:52 ` Michal Suchanek
2015-06-04 10:52 ` Michal Suchanek
2015-06-04 10:52 ` Michal Suchanek
2015-06-04 10:56 ` Mark Brown
2015-06-04 10:56 ` Mark Brown
2015-06-04 10:56 ` Mark Brown
2015-06-04 10:56 ` Mark Brown
2015-06-03 22:53 ` [PATCH 00/11] Enable access to SPI NOR flash on Samsung Snow board Marek Vasut
2015-06-03 22:53 ` Marek Vasut
2015-06-03 22:53 ` Marek Vasut
2015-06-03 22:53 ` Marek Vasut
2015-06-04 4:21 ` Michal Suchanek
2015-06-04 4:21 ` Michal Suchanek
2015-06-04 4:21 ` Michal Suchanek
2015-06-04 4:21 ` Michal Suchanek
2015-06-04 4:21 ` Michal Suchanek
2015-06-04 15:29 ` Marek Vasut
2015-06-04 15:29 ` Marek Vasut
2015-06-04 15:29 ` Marek Vasut
2015-06-04 15:29 ` Marek Vasut
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=201507220933.19752.marex@denx.de \
--to=marex@denx.de \
--cc=alison_chaiken@mentor.com \
--cc=b32955@freescale.com \
--cc=beanhuo@micron.com \
--cc=ben@decadent.org.uk \
--cc=broonie@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=grmoore@altera.com \
--cc=han.xu@freescale.com \
--cc=hramrach@gmail.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=k.kozlowski@samsung.com \
--cc=kgene@kernel.org \
--cc=knut.wohlrab@de.bosch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
--cc=vinod.koul@intel.com \
--cc=zajec5@gmail.com \
/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.