Issues with cros_ec and "spi: rockchip: check return value of dmaengine_prep_slave_sg"

Heiko Stuebner heiko at sntech.de
Sat Apr 2 06:37:43 PDT 2016


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





More information about the Linux-rockchip mailing list