On Mon, Dec 10, 2018 at 3:22 PM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Sat, Dec 08, 2018 at 11:39:05AM +0530, Jassi Brar wrote: > > On Fri, Dec 7, 2018 at 5:02 PM Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > > > > > > > > Secondly, I don't understand why you think this is an emulated console. > > > > > It is emulated/virtual because Linux doesn't put characters on a > > physical bus. The data is simply handed forward to a remote entity. > > Okay, I understand. However, from a kernel point of view there's no > difference between the TCU and any physical UART. Once the data is > handed to the TCU TX mailbox, it's out of control of the TCU driver. > Whether there's a real UART behind that or some remote processor that > reads the data isn't really relevant. > That way there can be no virtual/emulated device ? > > > > The 'flush' api is going to have no use other than implement > > busy-waits. I am afraid people are simply going to take it easy and > > copy the busy-waits from the test/verification codes. > > "discouraging" seldom works because the developer comes with the > > failproof excuse "the h/w doesn't provide any other way". Frankly I > > would like to push back on such designs. > > I certainly approve of that stance. > > However, I'd like to reiterate that the TCU design does in fact support > "another way". If you look at the mailbox driver implementation (in the > drivers/mailbox/tegra-hsp.c driver), you'll see that it does support an > interrupt driven mode. After you had reviewed Mikko's earliest proposal > that was indeed implementing busy looping exclusively we both set out > to properly implement interrupt support. This took quite a while to do > because of some gaps in the documentation, but we eventually got it to > work properly. And then it was discovered that it was all a waste of > effort because the console driver couldn't make use of it anyway. Well, > I should say "waste of effort" because I'm still happy that the proper > implementation exists and we can use it under the right circumstances. > > So, at least in this particular case, it is not the hardware or firmware > design that's flawed or was taking any shortcuts. It's really just the > particular use-case of the console that doesn't allow us to make use of > the right implementation, which is why we have to resort to the inferior > method of busy-looping. > I am not complaining about the hardware, but the firmware. It is essential we dump logs during early boot but the platform(Linux) doesn't have access to serial port. All the firmware allows is 24bits per transfer!! We could do better. A smarter option could have been Linux simply placing characters in the shmem ring-buffer, while the remote consuming (and then poisoning) the ring buffer upon 'hint' from Linux. -Jassi
