Mason writes:
> On 11/12/2017 15:36, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I suppose I should test forcefully setting the enable bit to 0 in
>>> the driver, and see if hell breaks loose.
>>
>> You can't. When the enable bit is 1, writes to that register are
>> ignored. It goes back t
On 11/12/2017 15:36, Måns Rullgård wrote:
> Mason writes:
>
>> I suppose I should test forcefully setting the enable bit to 0 in
>> the driver, and see if hell breaks loose.
>
> You can't. When the enable bit is 1, writes to that register are
> ignored. It goes back to 0 automatically when the
Mason writes:
> + Mans
>
> On 09/12/2017 19:49, Florian Fainelli wrote:
>
>> Having any HW state machine requiring X number of clock cycles to
>> guarantee a full transition to a stopped state is not unusual, however,
>> the fact that you need to send 5 packets to guarantee an EOC descriptor
>> i
+ Mans
On 09/12/2017 19:49, Florian Fainelli wrote:
> Having any HW state machine requiring X number of clock cycles to
> guarantee a full transition to a stopped state is not unusual, however,
> the fact that you need to send 5 packets to guarantee an EOC descriptor
> is hit is completely unusua
On 12/07/2017 08:17 AM, Mason wrote:
> On 07/12/2017 00:00, Florian Fainelli wrote:
>
>> On 12/06/2017 11:25 AM, Mason wrote:
>>
>>> When we detect link down, we put the ethernet HW block in reset,
>>> and repeat initialization when the link comes back up.
>>>
>>> Hmmm, however, at the moment, I
On 07/12/2017 00:00, Florian Fainelli wrote:
> On 12/06/2017 11:25 AM, Mason wrote:
>
>> When we detect link down, we put the ethernet HW block in reset,
>> and repeat initialization when the link comes back up.
>>
>> Hmmm, however, at the moment, I only reset on an administrative
>> (user-request
On 12/06/2017 11:25 AM, Mason wrote:
> On 06/12/2017 20:07, Andrew Lunn wrote:
>
>> By chip, you mean the Ethernet controller? Not the whole SoC?
>
> Doh! Yes. Let me rephrase.
>
> When we detect link down, we put the ethernet HW block in reset,
> and repeat initialization when the link comes
On 06/12/2017 20:07, Andrew Lunn wrote:
> By chip, you mean the Ethernet controller? Not the whole SoC?
Doh! Yes. Let me rephrase.
When we detect link down, we put the ethernet HW block in reset,
and repeat initialization when the link comes back up.
Hmmm, however, at the moment, I only reset o
> When we detect link down, we put the chip in reset, so that we will
> repeat initialization when the link comes back up.
By chip, you mean the Ethernet controller? Not the whole SoC?
Andrew
On 06/12/2017 19:26, Andrew Lunn wrote:
> On 06/12/2017 19:03, Mason wrote:
>
>> The problem with this is the following mind-boggling quirk of
>> the hardware: once RX DMA is enabled, there is no supported
>> way to disable it! Thus, I'm trying to find a clean way to set
>> the control flow parame
> The problem with this is the following mind-boggling quirk of
> the hardware: once RX DMA is enabled, there is no supported
> way to disable it! Thus, I'm trying to find a clean way to set
> the control flow parameter BEFORE enabling the MAC.
There is no solution. I can pull the cable out, and p
On 06/12/2017 17:59, Andrew Lunn wrote:
> On Wed, Dec 06, 2017 at 05:39:00PM +0100, Mason wrote:
>
>> I've been trying to wrap my head around Ethernet auto-negotiation,
>> vs actual / real packets seen at the MAC layer. I found the relevant
>> Wikipedia article to be fairly informative:
>>
>>
On Wed, Dec 06, 2017 at 05:39:00PM +0100, Mason wrote:
> Hello,
>
> I've been trying to wrap my head around Ethernet auto-negotiation,
> vs actual / real packets seen at the MAC layer. I found the relevant
> Wikipedia article to be fairly informative:
>
> https://en.wikipedia.org/wiki/Autoneg
Hello,
I've been trying to wrap my head around Ethernet auto-negotiation,
vs actual / real packets seen at the MAC layer. I found the relevant
Wikipedia article to be fairly informative:
https://en.wikipedia.org/wiki/Autonegotiation
The reason I care is that my Ethernet HW does not allow cha
14 matches
Mail list logo
