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

[Javier Martinez Canillas]

Hello Heiko,

Sorry for the late response, I got this email while I was sick and
forgot to answer when I recovered.

On Sat, Apr 2, 2016 at 9:37 AM, Heiko Stuebner <heiko at sntech.de> wrote:
> 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 also agree with this theory. AFAICT the mentioned commit is only
adding some checks so it seems the problem is with on the spi-rockchip
driver.

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

Unfortunately I'm neither familiar with Rockchip platforms nor have
access to Rockchip based Chromebooks to reproduce this issue. But I
don't see this error on my Exynos based Chromebooks so that's another
sign that the issue may be in the spi-rockchip driver.

I've added to the cc list to Enric and Tomeu who were working on the
cros_ec drivers lately and AFAIK have access to some Rockchip
Chromebooks.

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

Best regards,
Javier