From: Arnd Bergmann <arnd@arndb.de>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
linux-arm-kernel@lists.infradead.org,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Krzysztof Kozlowski <k.kozlowski@samsung.com>,
linux-samsung-soc@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Kukjin Kim <kgene@kernel.org>
Subject: Re: [PATCH 5/7] [media] mipi-csis: make sparse happy
Date: Mon, 05 Oct 2015 13:07:20 +0200 [thread overview]
Message-ID: <30256208.KbAtSBWnKO@wuerfel> (raw)
In-Reply-To: <56124FE8.8070400@samsung.com>
On Monday 05 October 2015 12:24:40 Sylwester Nawrocki wrote:
> On 03/10/15 00:25, Arnd Bergmann wrote:
> > On Thursday 01 October 2015 19:17:27 Mauro Carvalho Chehab wrote:
> >> > diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
> >> > index d74e1bec3d86..4b85105dc159 100644
> >> > --- a/drivers/media/platform/exynos4-is/mipi-csis.c
> >> > +++ b/drivers/media/platform/exynos4-is/mipi-csis.c
> >> > @@ -706,7 +706,8 @@ static irqreturn_t s5pcsis_irq_handler(int irq, void *dev_id)
> >> > else
> >> > offset = S5PCSIS_PKTDATA_ODD;
> >> >
> >> > - memcpy(pktbuf->data, state->regs + offset, pktbuf->len);
> >> > + memcpy(pktbuf->data, (u8 __force *)state->regs + offset,
> >> > + pktbuf->len);
> >> > pktbuf->data = NULL;
> >> >
> >
> > I think this is what memcpy_toio() is meant for.
>
> Exactly memcpy_fromio(). But it's implementation is inefficient on
> ARCH=arm, memcpy_fromio() will be translated to a loop of readb(),
> only if an arm sub-architecture provides a processor instruction
> to access memory by byte. Each readb() also involves a memory barrier.
> That's all what we wanted to avoid. AFAIR using memcpy_fromio() was
> causing increase of the copy operation several times comparing to
> memcpy(). On arm64 it looks better, but this driver is currently
> used only on arm32.
>
> I would prefer to add (void __force *) instead:
>
> memcpy(pktbuf->data, (void __force *)state->regs + offset, pktbuf->len);
>
> Alternatively, the memset could just be replaced by a loop of
> u32 reads - __raw_readl();
You are right for old kernels, but this was fixed in 7ddfe625cb ("ARM:
optimize memset_io()/memcpy_fromio()/memcpy_toio()") at least for
little-endian kernels and should be fine now on ARM just like
everywhere else.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/7] [media] mipi-csis: make sparse happy
Date: Mon, 05 Oct 2015 13:07:20 +0200 [thread overview]
Message-ID: <30256208.KbAtSBWnKO@wuerfel> (raw)
In-Reply-To: <56124FE8.8070400@samsung.com>
On Monday 05 October 2015 12:24:40 Sylwester Nawrocki wrote:
> On 03/10/15 00:25, Arnd Bergmann wrote:
> > On Thursday 01 October 2015 19:17:27 Mauro Carvalho Chehab wrote:
> >> > diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
> >> > index d74e1bec3d86..4b85105dc159 100644
> >> > --- a/drivers/media/platform/exynos4-is/mipi-csis.c
> >> > +++ b/drivers/media/platform/exynos4-is/mipi-csis.c
> >> > @@ -706,7 +706,8 @@ static irqreturn_t s5pcsis_irq_handler(int irq, void *dev_id)
> >> > else
> >> > offset = S5PCSIS_PKTDATA_ODD;
> >> >
> >> > - memcpy(pktbuf->data, state->regs + offset, pktbuf->len);
> >> > + memcpy(pktbuf->data, (u8 __force *)state->regs + offset,
> >> > + pktbuf->len);
> >> > pktbuf->data = NULL;
> >> >
> >
> > I think this is what memcpy_toio() is meant for.
>
> Exactly memcpy_fromio(). But it's implementation is inefficient on
> ARCH=arm, memcpy_fromio() will be translated to a loop of readb(),
> only if an arm sub-architecture provides a processor instruction
> to access memory by byte. Each readb() also involves a memory barrier.
> That's all what we wanted to avoid. AFAIR using memcpy_fromio() was
> causing increase of the copy operation several times comparing to
> memcpy(). On arm64 it looks better, but this driver is currently
> used only on arm32.
>
> I would prefer to add (void __force *) instead:
>
> memcpy(pktbuf->data, (void __force *)state->regs + offset, pktbuf->len);
>
> Alternatively, the memset could just be replaced by a loop of
> u32 reads - __raw_readl();
You are right for old kernels, but this was fixed in 7ddfe625cb ("ARM:
optimize memset_io()/memcpy_fromio()/memcpy_toio()") at least for
little-endian kernels and should be fine now on ARM just like
everywhere else.
Arnd
next prev parent reply other threads:[~2015-10-05 11:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 22:17 [PATCH 0/7] Fix most sparse warnings Mauro Carvalho Chehab
2015-10-01 22:17 ` [PATCH 1/7] [media] media-entity.c: get rid of var length arrays Mauro Carvalho Chehab
2015-10-01 22:17 ` [PATCH 2/7] [media] s5c73m3: fix a sparse warning Mauro Carvalho Chehab
2015-10-01 22:17 ` [PATCH 3/7] [media] netup_unidvb: remove most of the sparse warnings Mauro Carvalho Chehab
2015-10-01 22:17 ` [PATCH 4/7] [media] netup_unidvb_ci: Fix dereference of noderef expression Mauro Carvalho Chehab
2015-10-01 22:17 ` [PATCH 5/7] [media] mipi-csis: make sparse happy Mauro Carvalho Chehab
2015-10-01 22:17 ` Mauro Carvalho Chehab
2015-10-02 22:25 ` Arnd Bergmann
2015-10-02 22:25 ` Arnd Bergmann
2015-10-05 10:24 ` Sylwester Nawrocki
2015-10-05 10:24 ` Sylwester Nawrocki
2015-10-05 11:07 ` Arnd Bergmann [this message]
2015-10-05 11:07 ` Arnd Bergmann
2015-10-05 12:23 ` Sylwester Nawrocki
2015-10-05 12:23 ` Sylwester Nawrocki
2015-10-01 22:17 ` [PATCH 6/7] [media] c8sectpfe: fix namespace on memcpy/memset Mauro Carvalho Chehab
2015-10-01 22:17 ` Mauro Carvalho Chehab
2015-10-02 22:27 ` Arnd Bergmann
2015-10-02 22:27 ` Arnd Bergmann
2015-10-01 22:17 ` [PATCH 7/7] [media] rcar_jpu: Fix namespace for two __be16 vars Mauro Carvalho Chehab
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=30256208.KbAtSBWnKO@wuerfel \
--to=arnd@arndb.de \
--cc=k.kozlowski@samsung.com \
--cc=kgene@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=s.nawrocki@samsung.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.