On Wed, Mar 18, 2020 at 3:57 AM Akash Asthana <akashast@xxxxxxxxxxxxxx> wrote: > > Hi Evan > > On 3/18/2020 12:38 AM, Evan Green wrote: > > On Tue, Mar 17, 2020 at 3:58 AM Akash Asthana <akashast@xxxxxxxxxxxxxx> wrote: > >> Hi Matthias, > >> > >> On 3/14/2020 2:14 AM, Matthias Kaehlcke wrote: > >>> Hi Akash, > >>> > >>> On Fri, Mar 13, 2020 at 06:42:09PM +0530, Akash Asthana wrote: > >>>> V1 patch@https://patchwork.kernel.org/patch/11386469/ caused SC7180 system > >>>> to reset at boot time. > >>> The v1 patch isn't relevant in the commit message, please just describe the > >>> problem. Also the crash only occurs when earlycon is used. > >> ok > >>>> As QUP core clock is shared among all the SE drivers present on particular > >>>> QUP wrapper, the reset seen is due to earlycon usage after QUP core clock > >>>> is put to 0 from other SE drivers before real console comes up. > >>>> > >>>> As earlycon can't vote for it's QUP core need, to fix this add ICC > >>>> support to common/QUP wrapper driver and put vote for QUP core from > >>>> probe on behalf of earlycon and remove vote during sys suspend. > >>> Only removing the vote on suspend isn't ideal, the system might never get > >>> suspended. That said I don't have a really good alternative suggestion. > >>> > >>> One thing you could possibly do is to launch a delayed work, check > >>> console_device() every second or so and remove the vote when it returns > >>> non-NULL. Not claiming this would be a great solution ... > >>> > >>> The cleanest solution might be a notifier when the early console is > >>> unregistered, it seems somewhat over-engineered though ... Then again > >>> other (future) uart drivers with interconnect support might run into > >>> the same problem. > >> We are hitting this problem because QUP core clocks are shared among all > >> the SE driver present in particular QUP wrapper, if other HW controllers > >> has similar architecture we will hit this issue. > >> > >> How about if we expose an API from common driver(geni-se) for putting > >> QUP core BW vote to 0. > >> > >> We call this from console probe just after uart_add_one_port call > >> (console resources are enabled as part of this call) to put core quota > >> to 0 on behalf of earlyconsole? > > +Georgi > > > > Hm, these boot proxy votes are annoying, since the whole house of > > cards comes down if you replace these votes in the wrong order. > > > > I believe consensus in the other patches was to consolidate most of > > the interconnect support into the common SE code, right? > > I think what Matthias suggested is to maintain ICC functions defined > across I2C, SPI and UART as a library in common SE code. > > Still every SE driver will interact with ICC framework individually > rather than using common SE driver as a bridge. Right, I'm sort of proposing a blend here, where the individual drivers pass through the SE library, which looks at some shared state, and may defer sending the votes during boot time. I was thinking consolidating this into SE engine library code may make it easier for you to peek at that shared state. > > > Would that > > help you with these boot proxy votes? What I'm thinking is something > > along the lines of: > > * SPI, I2C, UART all call into the new common geni_se_icc_on/off() > > (or whatever it's called) > > * If geni_se_icc_off() sees that console UART hasn't voted yet, save > > the votes but don't actually call icc_set(0) now. > > * Once uart votes for the first time, call icc_set() on all of SPI, > > I2C, UART to get things back in sync. > > IIUC, you are suggesting to enhancing ICC > design@https://patchwork.kernel.org/patch/10774897/ [The very first ICC > patch posted during sdm845 timeframe]. > > Where common SE driver aggregate real time BW requirement from all the > SE driver and put net request to ICC framework. > > We received comments on that version of ICC to move voting to individual > SE driver from common driver. Hence we updated the design accordingly. I think most of the reaction to that original series came from the fact that the common SE code was doing aggregation work, which is something the interconnect core was designed to do. In the solution I'm proposing, the SE library either passes through votes as-is, or delays them until the console UART has voted, at which time it passes them all down as they were. You could still make the case this is something the interconnect core should help us with, which is why I was brainstorming about the provider propping up votes until some probe-finished deadline, maybe just a 30 second timer :) -Evan
