On Wed, Jun 26, 2024 at 09:54:40AM +0200, Johan Hovold wrote: > On Mon, Jun 24, 2024 at 02:58:39PM -0700, Doug Anderson wrote: > > 1. The function is named qcom_geni_serial_clear_tx_fifo() which > > implies that when it finishes that the hardware FIFO will have nothing > > in it. ...but how does your code ensure this? > > Yeah, I realised after I sent out the series that this may not be the > case. I was under the impression that cancelling a command would discard > the data in the FIFO (e.g. when starting the next command) but that was > probably an error in my mental model. I went back and did some more reverse engineering and have now confirmed that the hardware works as I assumed for v1, that is, that cancelling a command leaves data in the fifo, which is later discarded when a new command is issued. > > 3. On my hardware you're setting the FIFO level to 16 here. The docs I > > have say that if the FIFO level is "less than" the value you set here > > then the interrupt will go off and further clarifies that if you set > > the register to 1 here then you'll get interrupted when the FIFO is > > empty. So what happens with your solution if the FIFO is completely > > full? In that case you'd have to set this to 17, right? ...but then I > > could believe that might confuse the interrupt handler which would get > > told to start transmitting when there is no room for anything. > > Indeed. I may implicitly be relying on the absence of hardware flow > control as well so that waiting for one character to be sent is what > makes this work. I'm keeping the watermark level unchanged in v2 and instead restart tx by issuing a short transfer command to clear any stale data from the fifo which could prevent the watermark interrupt from firing. Johan
