From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Linux I2C <linux-i2c@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
gregkh <gregkh@linuxfoundation.org>,
Przemyslaw Sroka <psroka@cadence.com>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
Cyprian Wronka <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
Rafal Ciepiela <rafalc@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
DTML <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vitor Soares <Vitor.Soares@synopsys.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Linus Walleij <linus.walleij@linaro.org>,
Xiang Lin <Xiang.Lin@synaptics.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Sekhar Nori <nsekhar@ti.com>, Przemyslaw Gaj <pgaj@cadence.com>,
Peter Rosin <peda@axentia.se>,
Mike Shettel <mshettel@codeaurora.org>,
Stephen Boyd <swboyd@chromium.org>, Joe Perches <joe@perches.com>
Subject: Re: [PATCH v9 6/9] i3c: master: Add driver for Cadence IP
Date: Fri, 26 Oct 2018 09:57:07 +0200 [thread overview]
Message-ID: <20181026095707.3cd9b511@bbrezillon> (raw)
In-Reply-To: <CAK8P3a0WDRpukjDBm1rGPnZiH2FJRpquWhEknOBg=CphNOYOwg@mail.gmail.com>
Hi Arnd,
On Fri, 26 Oct 2018 09:43:25 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Oct 25, 2018 at 6:30 PM Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Thu, 25 Oct 2018 18:13:51 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thu, Oct 25, 2018 at 6:07 PM Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> > > > On Thu, 25 Oct 2018 17:30:26 +0200
> > > > Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On 10/24/18, Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> > > > > > On Mon, 22 Oct 2018 15:34:01 +0200
> > > > I guess I could dynamically allocate the payload, but that requires
> > > > going over all users of i3c_send_ccc_cmd() to patch them.
> > >
> > > This reminds me that Wolfram mentioned in his ELC talk that the
> > > buffers on i3c should all be DMA capable to make life easier for
> > > i3c master drivers that want to implement DMA transfers.
> >
> > And this is the case for all buffers passed to
> > i3c_device_do_priv_xfers() (and soon i3c_device_send_hdr_cmd()),
> > but I did not enforce that for the internal
> > i3c_master_send_ccc_cmd_locked() helper, maybe I should...
> > It was just convenient to place the object to be transmitted/received on
> > the stack.
>
> Ok. Is i3c_master_send_ccc_cmd_locked() what implements the public
> interfaces then, or is this something else?
i3c_master_send_ccc_cmd_locked() calls master->ops->send_ccc_cmd(), so
it's part of the master controller interface.
>
> If you place a buffer on the stack, it is not DMA capable, but
> it is guaranteed to be at least 32-bit word aligned, and should
> not cause an exception in readsl(), unless it starts with a couple of
> (not multiple of four) extra bytes that are not sent to the devices.
> Is that what happens here?
Here is the report I received from Vitor:
"
Hi Boris,
I'm trying this new patch-set version but I get some issues when use
readsl() function.
Basically the system complain about memory alignment.
As exemple when I try to read the PID from the device
> +static int i3c_master_getpid_locked(struct i3c_master_controller *master,
> + struct i3c_device_info *info)
> +{
> + struct i3c_ccc_getpid getpid;
at this point the getpid struct it is already unaligned with
i3c_master_getpid_locked:1129 getpid_add=0x9a249c7a
> + struct i3c_ccc_cmd_dest dest = {
> + .addr = info->dyn_addr,
> + .payload.len = sizeof(struct i3c_ccc_getpid),
> + .payload.data = &getpid,
> + };
> + struct i3c_ccc_cmd cmd = {
> + .rnw = true,
> + .id = I3C_CCC_GETPID,
> + .dests = &dest,
> + .ndests = 1,
> + };
> + int ret, i;
> +
> + ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
> + if (ret)
> + return ret;
> +
> + info->pid = 0;
> + for (i = 0; i < sizeof(getpid.pid); i++) {
> + int sft = (sizeof(getpid.pid) - i - 1) * 8;
> +
> + info->pid |= (u64)getpid.pid[i] << sft;
> + }
> +
> + return 0;
> +}
> +
and them when
static void dw_i3c_master_read_rx_fifo(struct dw_i3c_master *master,
u8 *bytes, int nbytes)
{
readsl(master->regs + RX_TX_DATA_PORT, bytes, nbytes / 4);
...
}
the system crash.
Misaligned Access
Path: (null)
CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1 #88
[ECR ]: 0x00230400 => Misaligned r/w from 0x9a249c7a
[EFA ]: 0x9a249c7a
[BLINK ]: dw_i3c_master_irq_handler+0x200/0x2fc [dw_i3c_master]
[ERET ]: dw_i3c_master_irq_handler+0x224/0x2fc [dw_i3c_master]
[STAT32]: 0x00000a4c : K DE A1 E2
BTA: 0x70038e44 SP: 0x8071fe58 FP: 0x00000000
LPS: 0x8060e63e LPE: 0x8060e642 LPC: 0x00000000
r00: 0x00000033 r01: 0x00000004 r02: 0x00000000
r03: 0xd0002014 r04: 0x00000006 r05: 0x00000000
r06: 0x9a249c7a r07: 0x39307260 r08: 0xe10b6900
r09: 0x00000013 r10: 0x00000000 r11: 0x000000c9
r12: 0x0a613763
Do you have any idea about this?
Best regards,
Vitor Soares
"
>
> > > If we have buffers here that are not aligned to cache lines
> > > (or even just 32 bit words), doesn't that also mean that the
> > > same buffers are not DMA capable either?
> >
> > Yep, if it's not cache-line-aligned (and on the stack), it's not
> > DMA-able.
>
> This sounds like a more fundamental problem to solve first
> then. Obviously it is incredibly /useful/ to be able to put short
> i2c or i3c messages on the stack, but allowing that in general
> also prevents the use of DMA without bounce buffers.
Actually, we have the same problem in MTD (UBI passes vmalloced
buffers to the MTD stack), so I understand this concern very well,
and I agree that enforcing all buffers passed to the controller to
be DMA capable is the right thing to do.
I guess I just didn't think about internal APIs when I made this
modification which explains why CCC cmds were left behind.
>
> One way to address this might be to always bounce any
> messages that are less than a cache line through a
> (pre-)kmallocated buffer, and require any longer messages
> to be cache capable. This could also solve the issue with
> readsl(), but it would be a rather confusing user interface.
>
> Another option might be to have separate interfaces for
> "short" and "long" messages at the API level and have
> distinct rules for those: short would always be bounced
> by the i3c code, and long puts restrictions on the buffer
> location.
Hm, let's keep the API simple. I'll just mandate that all payload bufs
passed to i3c_master_send_ccc_cmd_locked() be dynamically allocated.
Thanks for your feedback.
Boris
next prev parent reply other threads:[~2018-10-26 7:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 13:33 [PATCH v9 0/9] Add the I3C subsystem Boris Brezillon
2018-10-22 13:33 ` [PATCH v9 1/9] i3c: Add core I3C infrastructure Boris Brezillon
2018-10-22 13:33 ` [PATCH v9 2/9] docs: driver-api: Add I3C documentation Boris Brezillon
2018-10-22 13:33 ` [PATCH v9 3/9] i3c: Add sysfs ABI spec Boris Brezillon
2018-10-22 13:33 ` [PATCH v9 4/9] dt-bindings: i3c: Document core bindings Boris Brezillon
2018-10-22 20:45 ` Rob Herring
2018-10-22 13:34 ` [PATCH v9 5/9] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon
2018-10-22 13:34 ` [PATCH v9 6/9] i3c: master: Add driver for Cadence IP Boris Brezillon
2018-10-24 18:20 ` Boris Brezillon
2018-10-24 20:25 ` Grygorii Strashko
2018-10-24 21:04 ` Boris Brezillon
2018-10-24 22:43 ` Grygorii Strashko
2018-10-24 22:52 ` Boris Brezillon
2018-10-25 15:30 ` Arnd Bergmann
2018-10-25 16:07 ` Boris Brezillon
2018-10-25 16:13 ` Arnd Bergmann
2018-10-25 16:30 ` Boris Brezillon
2018-10-26 7:43 ` Arnd Bergmann
2018-10-26 7:57 ` Boris Brezillon [this message]
2018-10-26 10:01 ` Arnd Bergmann
2018-10-26 12:46 ` Boris Brezillon
2018-10-26 13:21 ` Arnd Bergmann
2018-10-22 13:34 ` [PATCH v9 7/9] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2018-10-22 13:34 ` [PATCH v9 8/9] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon
2018-10-22 13:34 ` [PATCH v9 9/9] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon
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=20181026095707.3cd9b511@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Vitor.Soares@synopsys.com \
--cc=Xiang.Lin@synaptics.com \
--cc=adouglas@cadence.com \
--cc=agolec@cadence.com \
--cc=alicja@cadence.com \
--cc=arnd@arndb.de \
--cc=bfolta@cadence.com \
--cc=corbet@lwn.net \
--cc=cwronka@cadence.com \
--cc=devicetree@vger.kernel.org \
--cc=dkos@cadence.com \
--cc=galak@codeaurora.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=joe@perches.com \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mshettel@codeaurora.org \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=pawel.moll@arm.com \
--cc=peda@axentia.se \
--cc=pgaj@cadence.com \
--cc=psroka@cadence.com \
--cc=rafalc@cadence.com \
--cc=robh+dt@kernel.org \
--cc=sureshp@cadence.com \
--cc=swboyd@chromium.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wsa@the-dreams.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).