From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= Subject: Re: Waiting for the PHY to complete auto-negotiation Date: Mon, 11 Dec 2017 14:36:54 +0000 Message-ID: References: <20171206165903.GM27063@lunn.ch> <20171206182633.GP27063@lunn.ch> <20171206190728.GC28774@lunn.ch> <31ba2a2d-99f4-64d7-b9e3-057cdaa1618c@gmail.com> <89c47196-fb02-267c-409f-db48a3d07b68@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Cc: Florian Fainelli , Andrew Lunn , netdev , David Miller To: Mason Return-path: Received: from unicorn.mansr.com ([81.2.72.234]:58794 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752598AbdLKOg5 (ORCPT ); Mon, 11 Dec 2017 09:36:57 -0500 In-Reply-To: (Mason's message of "Mon, 11 Dec 2017 15:29:20 +0100") Sender: netdev-owner@vger.kernel.org List-ID: 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 >> is hit is completely unusual. Ideally there is a single bit that tells >> the DMA engine: you are enabled, do your thing, or you are now disabled, >> and you must stop all accesses to DRAM *now*. That's how sane hardware works. This hardware is not sane. >> So what would be the correct way to quiesce that controller according to >> your HW folks? > > He (it's a single person) offered to run some RTL-level simulations, > but then moved on to more important tasks. At some point he wrote: > >> If you reset the DMA enable in the middle of a DMA, the hardware >> state machine doesn't return to the IDLE state if it has more >> descriptors to process. It should be noted that the RX DMA has been >> designed by our IP vendor with no intention of stopping the DMA in >> the middle of its operation. > > While the documentation for the IP states: > >> Receive DMA Channel Disabling >> >> When the entire receive frame has been read from the Receive FIFO and >> sent over the AMBA bus, the DMA operation ends, and the Receive DMA >> Channel is automatically disabled. To do this, hardware resets the >> Enable bit in the Receive Channel Control Register to "0" after the >> last data has been read from the Receive FIFO and sent over the AMBA >> bus. >> >> When operating in descriptor mode, upon completion of a receive frame >> DMA operation, if the descriptor chain has not ended when a receive >> frame DMA operation completes, the next receive frame DMA operation >> begins. The last descriptor in a descriptor chain is indicated by >> having its End Of Chain- EOC, flag set to "1". If this EOC flag is >> "0", to begin the next receive frame DMA operation, the next >> descriptor is automatically retrieved and used to configure the >> Receive DMA Channel. The Receive DMA Channel is then automatically >> re-enabled and the next receive frame DMA operation begins. >> >> In descriptor mode, an AMBA bus error can occur when reading receive >> descriptor data. If this happens, receive descriptor processing ends >> and the Receive DMA Channel is turned off. The Descriptor Error bit >> in the Receive Status Register is set to "1". > > I don't see how sending "fake" packets through the loop back would be > considered "resetting the DMA enable in the middle of a DMA". > (I'm afraid the HW dev didn't grasp what the driver is doing.) > > 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 hw runs out of descriptors. -- Måns Rullgård