From: Viresh Kumar <viresh.kumar@linaro.org> To: Jassi Brar <jassisinghbrar@gmail.com> Cc: Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Frank Rowand <frowand.list@gmail.com>, Bjorn Andersson <bjorn.andersson@linaro.org>, Vincent Guittot <vincent.guittot@linaro.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Sudeep Holla <sudeep.holla@arm.com>, Devicetree List <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU Date: Fri, 29 May 2020 11:57:09 +0530 [thread overview] Message-ID: <20200529062709.tjmlguu5ovhk4t7o@vireshk-i7> (raw) In-Reply-To: <CABb+yY3KKpDHTsTBescW_rXmqmLzJh-Ogaotk2n=nYRkfHy2cg@mail.gmail.com> On 29-05-20, 00:20, Jassi Brar wrote: > The fact that all these bits are backed by one physical signal makes I believe that within the IP itself, there must be 32 signals, just that only one comes out of it all OR'd together. Maybe that can be verified by writing 0x01 to it multiple times and it should generate the interrupt only once on the first instance. i.e. writing 1 to any big again won't raise the interrupt. > the firmware implement its own mux-demux'ing scheme. Similar to how the interrupt controllers do it in the kernel, they receive a single interrupt and then go check its registers/bits to see which peripheral raised it. > So the choice was > between demux and single signal at a time. Well, the demux is on the firmware side and the kernel may not need to worry about that, let the platform do it ? > Had there been one signal > per bit, the implementation would have definitely been 'efficient'. I will say 'More efficient', it will still be 'efficient' if we implement doorbell. > And the first platform the driver was developed on, required message > passing over the registers. I think it was correctly done at that point of time. No doubt about that. > So now my approach is to make do with what > we have...unless it shows in numbers. ARM's office is closed (lock-down) and he doesn't have remote access to the board and so was unable to do it until now. Numbers or no numbers, I don't think there is a question here about what is the most efficient way of doing it. Doing it in parallel (when the hardware allows) is surely going to be more efficient. Sending a signal, getting it processed by the firmware, doing something with it and then sending an Ack and that being received by kernel will take time. Why make a queue on the kernel side when we don't have to. :) > Anyways, if it comes to that, I'd rather a separate "doorbell' driver > than a driver working in two s/w modes. I think that would be fine with everyone, if you are fine with that now (based on plain logic and no numbers), maybe we can get that done now? -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: Jassi Brar <jassisinghbrar@gmail.com> Cc: Rob Herring <robh@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Devicetree List <devicetree@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Sudeep Holla <sudeep.holla@arm.com>, Frank Rowand <frowand.list@gmail.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU Date: Fri, 29 May 2020 11:57:09 +0530 [thread overview] Message-ID: <20200529062709.tjmlguu5ovhk4t7o@vireshk-i7> (raw) In-Reply-To: <CABb+yY3KKpDHTsTBescW_rXmqmLzJh-Ogaotk2n=nYRkfHy2cg@mail.gmail.com> On 29-05-20, 00:20, Jassi Brar wrote: > The fact that all these bits are backed by one physical signal makes I believe that within the IP itself, there must be 32 signals, just that only one comes out of it all OR'd together. Maybe that can be verified by writing 0x01 to it multiple times and it should generate the interrupt only once on the first instance. i.e. writing 1 to any big again won't raise the interrupt. > the firmware implement its own mux-demux'ing scheme. Similar to how the interrupt controllers do it in the kernel, they receive a single interrupt and then go check its registers/bits to see which peripheral raised it. > So the choice was > between demux and single signal at a time. Well, the demux is on the firmware side and the kernel may not need to worry about that, let the platform do it ? > Had there been one signal > per bit, the implementation would have definitely been 'efficient'. I will say 'More efficient', it will still be 'efficient' if we implement doorbell. > And the first platform the driver was developed on, required message > passing over the registers. I think it was correctly done at that point of time. No doubt about that. > So now my approach is to make do with what > we have...unless it shows in numbers. ARM's office is closed (lock-down) and he doesn't have remote access to the board and so was unable to do it until now. Numbers or no numbers, I don't think there is a question here about what is the most efficient way of doing it. Doing it in parallel (when the hardware allows) is surely going to be more efficient. Sending a signal, getting it processed by the firmware, doing something with it and then sending an Ack and that being received by kernel will take time. Why make a queue on the kernel side when we don't have to. :) > Anyways, if it comes to that, I'd rather a separate "doorbell' driver > than a driver working in two s/w modes. I think that would be fine with everyone, if you are fine with that now (based on plain logic and no numbers), maybe we can get that done now? -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-29 6:27 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-15 5:17 [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU Viresh Kumar 2020-05-15 5:17 ` Viresh Kumar 2020-05-15 16:46 ` Jassi Brar 2020-05-15 16:46 ` Jassi Brar 2020-05-18 7:35 ` Viresh Kumar 2020-05-18 7:35 ` Viresh Kumar 2020-05-19 0:53 ` Jassi Brar 2020-05-19 0:53 ` Jassi Brar 2020-05-19 4:39 ` Viresh Kumar 2020-05-19 4:39 ` Viresh Kumar 2020-05-19 1:29 ` Bjorn Andersson 2020-05-19 1:29 ` Bjorn Andersson 2020-05-19 3:40 ` Viresh Kumar 2020-05-19 3:40 ` Viresh Kumar 2020-05-19 4:05 ` Jassi Brar 2020-05-19 4:05 ` Jassi Brar 2020-06-03 18:31 ` Sudeep Holla 2020-06-03 18:31 ` Sudeep Holla 2020-06-03 18:42 ` Jassi Brar 2020-06-03 18:42 ` Jassi Brar 2020-06-03 18:28 ` Sudeep Holla 2020-06-03 18:28 ` Sudeep Holla 2020-05-28 19:20 ` Rob Herring 2020-05-28 19:20 ` Rob Herring 2020-05-29 4:07 ` Viresh Kumar 2020-05-29 4:07 ` Viresh Kumar 2020-06-03 18:04 ` Sudeep Holla 2020-06-03 18:04 ` Sudeep Holla 2020-06-03 18:17 ` Sudeep Holla 2020-06-03 18:17 ` Sudeep Holla 2020-06-04 5:59 ` Viresh Kumar 2020-06-04 5:59 ` Viresh Kumar 2020-06-04 8:28 ` Sudeep Holla 2020-06-04 8:28 ` Sudeep Holla 2020-06-03 18:32 ` Jassi Brar 2020-06-03 18:32 ` Jassi Brar 2020-06-04 9:20 ` Sudeep Holla 2020-06-04 9:20 ` Sudeep Holla 2020-06-04 15:15 ` Jassi Brar 2020-06-04 15:15 ` Jassi Brar 2020-06-05 4:56 ` Sudeep Holla 2020-06-05 4:56 ` Sudeep Holla 2020-06-05 6:30 ` Jassi Brar 2020-06-05 6:30 ` Jassi Brar 2020-06-05 8:58 ` Sudeep Holla 2020-06-05 15:42 ` Jassi Brar 2020-06-05 15:42 ` Jassi Brar 2020-06-10 9:33 ` Viresh Kumar 2020-06-10 9:33 ` Viresh Kumar 2020-06-11 10:00 ` Sudeep Holla 2020-06-11 10:00 ` Sudeep Holla 2020-06-12 0:34 ` Jassi Brar 2020-06-12 0:34 ` Jassi Brar 2020-06-12 5:28 ` Viresh Kumar 2020-06-12 5:28 ` Viresh Kumar 2020-09-08 9:14 ` Arnd Bergmann 2020-09-08 9:14 ` Arnd Bergmann 2020-09-08 9:27 ` Viresh Kumar 2020-09-08 9:27 ` Viresh Kumar 2020-09-08 13:26 ` Sudeep Holla 2020-09-08 13:26 ` Sudeep Holla 2020-09-09 3:23 ` Jassi Brar 2020-09-09 3:23 ` Jassi Brar 2020-09-09 4:46 ` Viresh Kumar 2020-09-09 4:46 ` Viresh Kumar 2020-09-09 9:31 ` Sudeep Holla 2020-09-09 9:31 ` Sudeep Holla 2020-05-29 5:20 ` Jassi Brar 2020-05-29 5:20 ` Jassi Brar 2020-05-29 6:27 ` Viresh Kumar [this message] 2020-05-29 6:27 ` Viresh Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200529062709.tjmlguu5ovhk4t7o@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=arnd@arndb.de \ --cc=bjorn.andersson@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=jassisinghbrar@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robh@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=vincent.guittot@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.