On Thu, Jun 04, 2020 at 10:15:55AM -0500, Jassi Brar wrote: > On Thu, Jun 4, 2020 at 4:20 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > On Wed, Jun 03, 2020 at 01:32:42PM -0500, Jassi Brar wrote: > > > On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > > > > > On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote: > > > > > On 28-05-20, 13:20, Rob Herring wrote: > > > > > > Whether Linux > > > > > > requires serializing mailbox accesses is a separate issue. On that side, > > > > > > it seems silly to not allow driving the h/w in the most efficient way > > > > > > possible. > > > > > > > > > > That's exactly what we are trying to say. The hardware allows us to > > > > > write all 32 bits in parallel, without any hardware issues, why > > > > > shouldn't we do that ? The delay (which Sudeep will find out, he is > > > > > facing issues with hardware access because of lockdown right now) > > > > > > > > OK, I was able to access the setup today. I couldn't reach a point > > > > where I can do measurements as the system just became unusable with > > > > one physical channel instead of 2 virtual channels as in my patches. > > > > > > > > My test was simple. Switch to schedutil and read sensors periodically > > > > via sysfs. > > > > > > > > arm-scmi firmware:scmi: message for 1 is not expected! > > > > > > > This sounds like you are not serialising requests on a shared channel. > > > Can you please also share the patch? > > > > OK, I did try with a small patch initially and then realised we must hit > > issue with mainline as is. Tried and the behaviour is exact same. All > > I did is removed my patches and use bit[0] as the signal. It doesn't > > matter as writes to the register are now serialised. Oh, the above > > message comes when OS times out in advance while firmware continues to > > process the old request and respond. > > > > The trace I sent gives much better view of what's going on. > > > BTW, you didn't even share 'good' vs 'bad' log for me to actually see > if the api lacks. > > Let us look closely ... > > >> bash-1019 [005] 1149.452340: scmi_xfer_begin: > transfer_id=1537 msg_id=7 protocol_id=19 seq=0 poll=1 > >> bash-1019 [005] 1149.452407: scmi_xfer_end: > transfer_id=1537 msg_id=7 protocol_id=19 seq=0 status=0 > > > This round trip took 67usecs. (log shows some at even 3usecs) > That includes mailbox api overhead, memcpy and the time taken by > remote to respond. This is DVFS request which firmware acknowledges quickly and expected to at most 100us. > So the api is definitely capable of much faster transfers than you require. > I am not complaining about that. The delay is mostly due to the load on the mailbox and parallelising helps is the focus here. > >> bash-1526 [000] 1149.472553: scmi_xfer_begin: transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0 > >> <idle>-0 [001] 1149.472733: scmi_xfer_begin: transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1 > > > Here another request is started before the first is finished. Ah, the prints are when the client requested. It is not when the mailbox started it. So this just indicates the beginning of the transfer from the client. I must have mentioned that earlier. Some request timeout before being picked up by mailbox if the previous request is not acknowledge quickly. E.g. Say a sensor command started which may take upto 1ms, almost 5-6 DVFS request after that will timeout. > If you want this to work you have to serialise access to the single > physical channel and/or run the remote firmware in asynchronous mode - > that is, the firmware ack the bit as soon as it sees and starts > working in the background, so that we return in ~3usec always, while > the data returns whenever it is ready. Yes it does that for few requests like DVFS while it uses synchronous mode for few others. While ideally I agree everything in asynchronous most is better, I don't know there may be reasons for such design. Also the solution given is to use different bits as independent channels which hardware allows. Anyways it's open source SCP project[1]. -- Regards, Sudeep [1] https://github.com/ARM-software/SCP-firmware
