[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1421861078.1222.271.camel@xylophone.i.decadent.org.uk>
Date: Wed, 21 Jan 2015 17:24:38 +0000
From: Ben Hutchings <ben.hutchings@...ethink.co.uk>
To: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>,
Mitsuhiro Kimura <mitsuhiro.kimura.kc@...esas.com>,
Hisashi Nakamura <hisashi.nakamura.ak@...esas.com>,
Yoshihiro Kaneko <ykaneko0929@...il.com>
Cc: netdev@...r.kernel.org,
ct-linux-kernel <linux-kernel@...ethink.co.uk>
Subject: Questions about the sh_eth driver and hardware
I found several more bugs in the sh_eth driver, but for some of them I'm
really unsure what to do. I only have a manual for the R8A7790 (R-Car
H2) and I don't know how all the other supported chips will behave.
Maybe you can answer some of these questions.
1. When freeing packet buffers, we currently try to stop the DMA engines
by clearing EDRRR and EDTRR but we *don't* wait after that. This seems
unsafe because in general register writes are not serialised with DMA.
The R8A7790 (R-Car H2) manual specifically says that the R bit of EDTRR
(aka CXR2) cannot be cleared by writing to it. I think that we could
stop TX DMA by clearing the active flags of all the descriptors and then
polling the R bit until it clears. What do you think?
As for RX DMA, I think we should wait some time after clearing the R bit
that we can be sure is long enough to transfer one packet. Do you know
how long that could be?
2. In case of a Receive Descriptor Empty error (RDE), we currently read
the RDFAR register to find the next descriptor the DMA engine will use.
But this register is not documented for the R8A7790 and the driver does
not define an offset for it on R-Car chips. The manual doesn't say how
to set the address of the next descriptor to use. Maybe we should
assume that R-Car chips will never skip descriptors after RDE?
Ben.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists