Hi Jon,
On Tue, Nov 14, 2017 at 7:56 AM, Jon Hunter wrote:
>
> Hi Shawn,
>
> On 26/09/17 16:40, Jon Hunter wrote:
> > On 26/09/17 00:15, Shawn N wrote:
>
> ...
>
> >> From: Shawn Nematbakhsh
> >> Date: Mon, 25 Sep 2017 14:32:38 -0700
> >> Subject: [PATCH] mfd: cros ec: spi: Fix "in progress" err
Hi Shawn,
On 26/09/17 16:40, Jon Hunter wrote:
> On 26/09/17 00:15, Shawn N wrote:
...
>> From: Shawn Nematbakhsh
>> Date: Mon, 25 Sep 2017 14:32:38 -0700
>> Subject: [PATCH] mfd: cros ec: spi: Fix "in progress" error signaling
>>
>> For host commands that take a long time to process, cros ec c
Hi,
On Wed, Nov 8, 2017 at 2:20 AM, Jon Hunter wrote:
> Hi Doug,
>
> On 07/11/17 17:22, Doug Anderson wrote:
>> On Tue, Nov 7, 2017 at 3:28 AM, Jon Hunter wrote:
>>> On 10/10/17 17:52, Doug Anderson wrote:
>>>
>>> ...
>>>
> I'm still not clear on why we see an error only on the first
> t
Hi Doug,
On 07/11/17 17:22, Doug Anderson wrote:
> On Tue, Nov 7, 2017 at 3:28 AM, Jon Hunter wrote:
>> On 10/10/17 17:52, Doug Anderson wrote:
>>
>> ...
>>
I'm still not clear on why we see an error only on the first
transaction after boot. In this case, the embedded controller
pr
Hi,
On Tue, Nov 7, 2017 at 3:28 AM, Jon Hunter wrote:
>
> On 10/10/17 17:52, Doug Anderson wrote:
>
> ...
>
>>> I'm still not clear on why we see an error only on the first
>>> transaction after boot. In this case, the embedded controller
>>> previously handled host commands from firmware just fi
On 10/10/17 17:52, Doug Anderson wrote:
...
>> I'm still not clear on why we see an error only on the first
>> transaction after boot. In this case, the embedded controller
>> previously handled host commands from firmware just fine, and the
>> handoff between firmware and the kernel shouldn't b
Hi,
On Tue, Oct 10, 2017 at 8:33 AM, Shawn N wrote:
>> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi
>> b/arch/arm/boot/dts/tegra124-nyan.dtsi
>> index 5cf987b5401e..0baa6bfc0f36 100644
>> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
>> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
>> @@ -317,6 +
On Tue, Oct 10, 2017 at 6:35 AM, Jon Hunter wrote:
>
> On 26/09/17 00:15, Shawn N wrote:
>> On Wed, Sep 20, 2017 at 1:22 PM, Shawn N wrote:
>>> On Tue, Sep 19, 2017 at 11:13 PM, Brian Norris
>>> wrote:
Hi,
On Tue, Sep 19, 2017 at 11:05:38PM -0700, Shawn N wrote:
> This is fai
On 26/09/17 00:15, Shawn N wrote:
> On Wed, Sep 20, 2017 at 1:22 PM, Shawn N wrote:
>> On Tue, Sep 19, 2017 at 11:13 PM, Brian Norris
>> wrote:
>>> Hi,
>>>
>>> On Tue, Sep 19, 2017 at 11:05:38PM -0700, Shawn N wrote:
This is failing because our EC_CMD_GET_PROTOCOL_INFO host command is
On 26/09/17 00:15, Shawn N wrote:
> On Wed, Sep 20, 2017 at 1:22 PM, Shawn N wrote:
>> On Tue, Sep 19, 2017 at 11:13 PM, Brian Norris
>> wrote:
>>> Hi,
>>>
>>> On Tue, Sep 19, 2017 at 11:05:38PM -0700, Shawn N wrote:
This is failing because our EC_CMD_GET_PROTOCOL_INFO host command is
On Wed, Sep 20, 2017 at 1:22 PM, Shawn N wrote:
> On Tue, Sep 19, 2017 at 11:13 PM, Brian Norris
> wrote:
>> Hi,
>>
>> On Tue, Sep 19, 2017 at 11:05:38PM -0700, Shawn N wrote:
>>> This is failing because our EC_CMD_GET_PROTOCOL_INFO host command is
>>> getting messed up, or the reply buffer is g
On Tue, Sep 19, 2017 at 11:13 PM, Brian Norris wrote:
> Hi,
>
> On Tue, Sep 19, 2017 at 11:05:38PM -0700, Shawn N wrote:
>> This is failing because our EC_CMD_GET_PROTOCOL_INFO host command is
>> getting messed up, or the reply buffer is getting corrupted somehow.
>>
>>ec_dev->prot
Hi,
On Tue, Sep 19, 2017 at 11:05:38PM -0700, Shawn N wrote:
> This is failing because our EC_CMD_GET_PROTOCOL_INFO host command is
> getting messed up, or the reply buffer is getting corrupted somehow.
>
>ec_dev->proto_version =
> min(EC_HOST_REQUEST_VERSI
This is failing because our EC_CMD_GET_PROTOCOL_INFO host command is
getting messed up, or the reply buffer is getting corrupted somehow.
ec_dev->proto_version =
min(EC_HOST_REQUEST_VERSION,
fls(proto_info->protocol_ver
Hi Jon,
On Tue, Sep 19, 2017 at 05:39:56PM +0100, Jon Hunter wrote:
> On 19/09/17 15:09, Shawn N wrote:
> > On Tue, Sep 19, 2017 at 6:44 AM, Jon Hunter wrote:
> >> Tegra124 Nyan-Big is currently crashing during boot with -next [0] and
> >> bisect is pointing to this commit. Reverting the above on
On Tue, Sep 19, 2017 at 9:39 AM, Jon Hunter wrote:
>
>
> On 19/09/17 15:09, Shawn N wrote:
>> On Tue, Sep 19, 2017 at 6:44 AM, Jon Hunter wrote:
>>>
>>> Hi Brian,
>>>
>>> On 08/09/17 21:50, Brian Norris wrote:
From: Shawn Nematbakhsh
pkt_xfer should be used for protocol v3, and cm
On 19/09/17 15:09, Shawn N wrote:
> On Tue, Sep 19, 2017 at 6:44 AM, Jon Hunter wrote:
>>
>> Hi Brian,
>>
>> On 08/09/17 21:50, Brian Norris wrote:
>>> From: Shawn Nematbakhsh
>>>
>>> pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
>>> one instance of these functions cor
On Tue, Sep 19, 2017 at 6:44 AM, Jon Hunter wrote:
>
> Hi Brian,
>
> On 08/09/17 21:50, Brian Norris wrote:
> > From: Shawn Nematbakhsh
> >
> > pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
> > one instance of these functions correct, but not the second, fall-back
> > ca
Hi Brian,
On 08/09/17 21:50, Brian Norris wrote:
> From: Shawn Nematbakhsh
>
> pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
> one instance of these functions correct, but not the second, fall-back
> case. We use the fall-back only when the first command returns an
> IN
Hi Brian,
On Fri, Sep 08, 2017 at 01:50:11PM -0700, Brian Norris wrote:
> From: Shawn Nematbakhsh
>
> pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
> one instance of these functions correct, but not the second, fall-back
> case. We use the fall-back only when the first
20 matches
Mail list logo
