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


Groups > linux.kernel > #1227351 > unrolled thread

[PATCH v2 0/3] Add __ioread32_copy() and use it

Started byStephen Boyd <sboyd@codeaurora.org>
First post2015-09-17 21:10 +0200
Last post2015-09-17 23:50 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v2 0/3] Add __ioread32_copy() and use it Stephen Boyd <sboyd@codeaurora.org> - 2015-09-17 21:10 +0200
    [PATCH v2 2/3] soc: qcom: smd: Use __ioread32_copy() instead of open-coding it Stephen Boyd <sboyd@codeaurora.org> - 2015-09-17 21:10 +0200
    Re: [PATCH v2 0/3] Add __ioread32_copy() and use it Andrew Morton <akpm@linux-foundation.org> - 2015-09-17 22:00 +0200
      Re: [PATCH v2 0/3] Add __ioread32_copy() and use it Andy Gross <agross@codeaurora.org> - 2015-09-17 23:50 +0200
        Re: [PATCH v2 0/3] Add __ioread32_copy() and use it Andrew Morton <akpm@linux-foundation.org> - 2015-09-17 23:50 +0200

#1227351 — [PATCH v2 0/3] Add __ioread32_copy() and use it

FromStephen Boyd <sboyd@codeaurora.org>
Date2015-09-17 21:10 +0200
Subject[PATCH v2 0/3] Add __ioread32_copy() and use it
Message-ID<q9MJb-4n2-5@gated-at.bofh.it>
The SMD driver is reading and writing chunks of data to iomem,
and there's an __iowrite32_copy() function for the writing part, but
no __ioread32_copy() function for the reading part. This series
adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
case this should go through the -mm tree. Otherwise the target
of this patch series is SMD, so I've sent it to Andy.

Note this patch series relies on a previous patch on the list that
changes the readl() to __raw_readl() in the smd driver[1].

Changes since v1:
 * Dropped weak from __ioread32_copy()

Stephen Boyd (3):
  lib: iomap_copy: Add __ioread32_copy()
  soc: qcom: smd: Use __ioread32_copy() instead of open-coding it
  FIRMWARE: bcm47xx_nvram: Use __ioread32_copy() instead of open-coding

 drivers/firmware/broadcom/bcm47xx_nvram.c | 11 +++--------
 drivers/soc/qcom/smd.c                    | 13 ++++---------
 include/linux/io.h                        |  1 +
 lib/iomap_copy.c                          | 21 +++++++++++++++++++++
 4 files changed, 29 insertions(+), 17 deletions(-)

[1] http://lkml.kernel.org/g/1441234011-4259-7-git-send-email-sboyd@codeaurora.org

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


#1227354 — [PATCH v2 2/3] soc: qcom: smd: Use __ioread32_copy() instead of open-coding it

FromStephen Boyd <sboyd@codeaurora.org>
Date2015-09-17 21:10 +0200
Subject[PATCH v2 2/3] soc: qcom: smd: Use __ioread32_copy() instead of open-coding it
Message-ID<q9MJc-4n2-25@gated-at.bofh.it>
In reply to#1227351
Now that we have a generic library function for this, replace the
open-coded instance.

Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 drivers/soc/qcom/smd.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index e2f85a714243..e81eac28b5ce 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -434,20 +434,15 @@ static void smd_copy_to_fifo(void __iomem *dst,
 /*
  * Copy count bytes of data using 32bit accesses, if that is required.
  */
-static void smd_copy_from_fifo(void *_dst,
-			       const void __iomem *_src,
+static void smd_copy_from_fifo(void *dst,
+			       const void __iomem *src,
 			       size_t count,
 			       bool word_aligned)
 {
-	u32 *dst = (u32 *)_dst;
-	u32 *src = (u32 *)_src;
-
 	if (word_aligned) {
-		count /= sizeof(u32);
-		while (count--)
-			*dst++ = __raw_readl(src++);
+		__ioread32_copy(dst, src, count / sizeof(u32));
 	} else {
-		memcpy_fromio(_dst, _src, count);
+		memcpy_fromio(dst, src, count);
 	}
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


#1227370

FromAndrew Morton <akpm@linux-foundation.org>
Date2015-09-17 22:00 +0200
Message-ID<q9NvA-5kj-9@gated-at.bofh.it>
In reply to#1227351
On Thu, 17 Sep 2015 12:02:08 -0700 Stephen Boyd <sboyd@codeaurora.org> wrote:

> The SMD driver is reading and writing chunks of data to iomem,
> and there's an __iowrite32_copy() function for the writing part, but
> no __ioread32_copy() function for the reading part. This series
> adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
> case this should go through the -mm tree. Otherwise the target
> of this patch series is SMD, so I've sent it to Andy.
> 
> Note this patch series relies on a previous patch on the list that
> changes the readl() to __raw_readl() in the smd driver[1].

Well that's awkward.

"[PATCH v2 6/8] soc: qcom: smd: Handle big endian CPUs" is one patch in
an eight-patch series.  My usual approach would be to suck in the whole
series, stage it behind linux-next, drop patches if/when others merge
them into subsystem trees and thus retain all the dependencies for this
patch series in a maintainable-by-me fashion.

But that 8-patch series doesn't apply:

checking file drivers/soc/qcom/smd.c
Hunk #6 FAILED at 360.
Hunk #15 FAILED at 733.
Hunk #16 FAILED at 741.
3 out of 19 hunks FAILED
Failed to apply soc-qcom-smd-handle-big-endian-cpus


ho hum.  I think I'll go with plan B: merge just "lib: iomap_copy: Add
__ioread32_copy()" and send that into Linus promptly.  That way you
guys can sort out the driver patches in the usual fashion.

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


#1227422

FromAndy Gross <agross@codeaurora.org>
Date2015-09-17 23:50 +0200
Message-ID<q9Pe1-7Ti-7@gated-at.bofh.it>
In reply to#1227370
On Thu, Sep 17, 2015 at 12:56:51PM -0700, Andrew Morton wrote:
> On Thu, 17 Sep 2015 12:02:08 -0700 Stephen Boyd <sboyd@codeaurora.org> wrote:
> 
> > The SMD driver is reading and writing chunks of data to iomem,
> > and there's an __iowrite32_copy() function for the writing part, but
> > no __ioread32_copy() function for the reading part. This series
> > adds __ioread32_copy() and uses it in two places. Andrew is on Cc in
> > case this should go through the -mm tree. Otherwise the target
> > of this patch series is SMD, so I've sent it to Andy.
> > 
> > Note this patch series relies on a previous patch on the list that
> > changes the readl() to __raw_readl() in the smd driver[1].
> 
> Well that's awkward.
> 
> "[PATCH v2 6/8] soc: qcom: smd: Handle big endian CPUs" is one patch in
> an eight-patch series.  My usual approach would be to suck in the whole
> series, stage it behind linux-next, drop patches if/when others merge
> them into subsystem trees and thus retain all the dependencies for this
> patch series in a maintainable-by-me fashion.
> 
> But that 8-patch series doesn't apply:
> 
> checking file drivers/soc/qcom/smd.c
> Hunk #6 FAILED at 360.
> Hunk #15 FAILED at 733.
> Hunk #16 FAILED at 741.
> 3 out of 19 hunks FAILED
> Failed to apply soc-qcom-smd-handle-big-endian-cpus
> 
> 
> ho hum.  I think I'll go with plan B: merge just "lib: iomap_copy: Add
> __ioread32_copy()" and send that into Linus promptly.  That way you
> guys can sort out the driver patches in the usual fashion.
> 

I just pulled in the original 8 patches and rebased.  My plans were to stage
those in linux-next through my for-next.  Then add those on top just like you
specified.  But i could go either way.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


#1227426

FromAndrew Morton <akpm@linux-foundation.org>
Date2015-09-17 23:50 +0200
Message-ID<q9Pe2-7Ti-19@gated-at.bofh.it>
In reply to#1227422
On Thu, 17 Sep 2015 16:42:18 -0500 Andy Gross <agross@codeaurora.org> wrote:

> > ho hum.  I think I'll go with plan B: merge just "lib: iomap_copy: Add
> > __ioread32_copy()" and send that into Linus promptly.  That way you
> > guys can sort out the driver patches in the usual fashion.
> > 
> 
> I just pulled in the original 8 patches and rebased.  My plans were to stage
> those in linux-next through my for-next.  Then add those on top just like you
> specified.  But i could go either way.

OK, please do that.
--
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