From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
Javier Martinez Canillas
<javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Issues with cros_ec and "spi: rockchip: check return value of dmaengine_prep_slave_sg"
Date: Sat, 02 Apr 2016 15:37:43 +0200 [thread overview]
Message-ID: <32438337.LoARtRoxf0@phil> (raw)
In-Reply-To: <56FF9741.4040304-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi Shawn,
Am Samstag, 2. April 2016, 17:56:17 schrieb Shawn Lin:
> 在 2016/4/2 7:52, Heiko Stuebner 写道:
> > it looks like commit ea9849113343 ("spi: rockchip: check return value of
> > dmaengine_prep_slave_sg") negatively affects the cros_ec spi backend.
> >
> > During boot on the most recent mainline kernel I get:
> >
> > [ 1.025480] cros-ec-spi spi0.0: Chrome EC device registered
> > [ 1.641636] input: cros_ec as
> > /devices/platform/ff110000.spi/spi_master/spi0/spi0.0/ff110000.spi:ec@0
> > :keyboard-controller/input/input0 [ 2.340214] cros-ec-spi spi0.0: EC
> > failed to respond in time
> > [ 2.357735] cros-ec-spi spi0.0: packet too long (249 bytes, expected
> > 4) [ 2.470353] cros-ec-spi spi0.0: EC failed to respond in time
> > [ 2.508495] cros-ec-spi spi0.0: packet too long (249 bytes, expected
> > 4) [ 2.620176] cros-ec-spi spi0.0: EC failed to respond in time
> > [ 2.637345] cros-ec-spi spi0.0: packet too long (249 bytes, expected
> > 4) [ 2.750245] cros-ec-spi spi0.0: EC failed to respond in time
> > [ 2.767519] cros-ec-spi spi0.0: packet too long (249 bytes, expected
> > 4)
> >
> > The cros-ec works ok after boot without further errors [aka keyboard
> > and everything working correctly] and I haven't been able to figure out
> > what goes wrong, but was able to bisect the issue down to the commit
> > mentioned above.
>
> Which Soc I can reproduce it?
I can see that on both a veyron-pinky as well as a veyron-jerry, so the
rk3288-based devices.
> I'm not able to find out how this commit to break the cros-ec. So I
> prone to think this commit just expose some issues rather than
> introducing negatively affects. I guess, before this commit, cros-ec
> always get successful transfer, but the reality is that the tranfer
> does failed in the early booting stage but spi-rockchip doesn't log out
> anything. If that is the case, that means spi-rockchip fails to prepare
> sg for some unknown reasons?
That is a possibility.
I haven't had much experience with both spi and cros-ec and it seems I've
forgotten to also include Javier in my Cc-list who die the cros-ec
mainlining. I've corrected that now and maybe he has some additional idea
what may go wrong there.
> > Reverting the patch silences the cros-ec again. I'll try to look into it
> > further, but maybe you also have an idea what might go wrong.
--
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
next prev parent reply other threads:[~2016-04-02 13:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 23:52 Issues with cros_ec and "spi: rockchip: check return value of dmaengine_prep_slave_sg" Heiko Stuebner
2016-04-02 9:56 ` Shawn Lin
[not found] ` <56FF9741.4040304-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-04-02 13:37 ` Heiko Stuebner [this message]
2016-04-11 17:54 ` Javier Martinez Canillas
[not found] ` <CABxcv=kotgZosaLBKV0f1NpwYH8w57k+RT0fS2QL5ZpNWtU-yA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-17 0:07 ` Heiko Stübner
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=32438337.LoARtRoxf0@phil \
--to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.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 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).