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