Hi,
John Youn writes:
> On 2/12/2016 2:05 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> John Youn writes:
>>> On 2/10/2016 1:07 PM, Felipe Balbi wrote:
John Youn writes:
>>> Basically assign all the resources in advance.
>>
>> I thought about that, but wouldn't this, essentially,
On 2/12/2016 2:05 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> On 2/10/2016 1:07 PM, Felipe Balbi wrote:
>>> John Youn writes:
>> Basically assign all the resources in advance.
>
> I thought about that, but wouldn't this, essentially, enable all
> endpoints unconditi
Hi,
John Youn writes:
> On 2/10/2016 1:07 PM, Felipe Balbi wrote:
>> John Youn writes:
> Basically assign all the resources in advance.
I thought about that, but wouldn't this, essentially, enable all
endpoints unconditionally ? This could, potentially, increase power
co
On 2/10/2016 1:07 PM, Felipe Balbi wrote:
> John Youn writes:
Basically assign all the resources in advance.
>>>
>>> I thought about that, but wouldn't this, essentially, enable all
>>> endpoints unconditionally ? This could, potentially, increase power
>>> consumption on some systems, right
John Youn writes:
>>> Basically assign all the resources in advance.
>>
>> I thought about that, but wouldn't this, essentially, enable all
>> endpoints unconditionally ? This could, potentially, increase power
>> consumption on some systems, right ? This could also cause "spurious"
>> interrupts
On 2/10/2016 2:11 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>
>
>>> If it wasn't for that flag, we would always allocate transfer resource 3
>>> for every newly enabled endpoint. Can you check with your RTL engineers
>>> if it's valid to *always* issue DEPSTARTCFG with a proper par
Hi,
John Youn writes:
>> If it wasn't for that flag, we would always allocate transfer resource 3
>> for every newly enabled endpoint. Can you check with your RTL engineers
>> if it's valid to *always* issue DEPSTARTCFG with a proper parameter
>> depending on endpoint number ? Basically, somet
On 2/10/2016 12:44 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>>> John Youn writes:
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fi
Hi,
John Youn writes:
>> John Youn writes:
>>> The assignement of EP transfer resources was not handled properly in the
>>> dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
>>> resource index on SET_INTERFACE") previously fixed one aspect of this
>>> where resources may be exhau
Hi John
>-Original Message-
>From: John Youn [mailto:john.y...@synopsys.com]
>Sent: Wednesday, February 10, 2016 1:25 AM
>To: Felipe Balbi; B, Ravi
>Cc: john.y...@synopsys.com; linux-usb@vger.kernel.org
>Subject: [PATCH] usb: dwc3: Fix assignment of EP transf
On 2/9/2016 12:06 PM, Felipe Balbi wrote:
>
> Hi John,
>
> John Youn writes:
>> The assignement of EP transfer resources was not handled properly in the
>> dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
>> resource index on SET_INTERFACE") previously fixed one aspect of this
>>
Hi John,
John Youn writes:
> The assignement of EP transfer resources was not handled properly in the
> dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
> resource index on SET_INTERFACE") previously fixed one aspect of this
> where resources may be exhausted with multiple calls
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduc
13 matches
Mail list logo
