On Mon, Jun 15, 2020 at 12:42:50PM -0700, Florian Fainelli wrote:
> Or how about this: we slightly re-structure the interrupt handler such
> that all possible interrupt conditions are explicitly handled and
> terminate with a return IRQ_HANDLED, and those which are not, including
> in the case of
On 6/15/2020 12:09 PM, Robin Murphy wrote:
> On 2020-06-08 12:41, Lukas Wunner wrote:
>> On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
>>> And all in code that has at least one obvious inefficiency left on
>>> the table either way.
>>
>> Care to submit a patch to overcome that in
On Mon, Jun 15, 2020 at 06:31:58PM +0100, Robin Murphy wrote:
> Now that I've been inclined to go and look up the documentation, are we sure
> this so-very-contentious check is even correct? From my reading of things
> we're checking whether the RXR interrupt function is *enabled*, which still
> s
On 2020-06-08 12:41, Lukas Wunner wrote:
On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
And all in code that has at least one obvious inefficiency left on
the table either way.
Care to submit a patch to overcome that inefficiency?
I'll have a quick go, but without any way to m
On 2020-06-15 18:04, Florian Fainelli wrote:
On 6/15/2020 10:00 AM, Mark Brown wrote:
On Mon, Jun 15, 2020 at 09:34:58AM -0700, Florian Fainelli wrote:
OK, so this has been dropped for spi/for-next right? How do we move from
there?
Well, I actually have it queued up for applying so unless
On Mon, Jun 15, 2020 at 10:04:46AM -0700, Florian Fainelli wrote:
> OK, how about I send you an increment patch (would a fixup be okay?)
> that adds __always_inline since we know from this thread that some
> compilers may mis-optimize the function inlining?
That's fine for me.
signature.asc
Des
On 6/15/2020 10:00 AM, Mark Brown wrote:
> On Mon, Jun 15, 2020 at 09:34:58AM -0700, Florian Fainelli wrote:
>
>> OK, so this has been dropped for spi/for-next right? How do we move from
>> there?
>
> Well, I actually have it queued up for applying so unless I pull it
> before my scripts get t
On Mon, Jun 15, 2020 at 09:34:58AM -0700, Florian Fainelli wrote:
> OK, so this has been dropped for spi/for-next right? How do we move from
> there?
Well, I actually have it queued up for applying so unless I pull it
before my scripts get that far through the stuff I queued over the merge
window
On 6/8/2020 4:28 AM, Mark Brown wrote:
> On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
>
>> Again, 2 cycles. The overhead of a static key alone is at least 50% of that.
>> And that's not even considering whether the change in code layout caused by
>> doubling up the IRQ handler
On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
> And all in code that has at least one obvious inefficiency left on
> the table either way.
Care to submit a patch to overcome that inefficiency?
> This thread truly epitomises Knuth's "premature optimisation" quote... ;)
The thread
On Mon, Jun 08, 2020 at 12:11:11PM +0100, Robin Murphy wrote:
> Again, 2 cycles. The overhead of a static key alone is at least 50% of that.
> And that's not even considering whether the change in code layout caused by
> doubling up the IRQ handler might affect I-cache or branch predictor
> behavi
On 2020-06-05 23:04, Florian Fainelli wrote:
On 6/5/2020 7:41 AM, Robin Murphy wrote:
On 2020-06-05 14:46, Robin Murphy wrote:
On 2020-06-05 14:20, Mark Brown wrote:
On Fri, Jun 05, 2020 at 12:34:36PM +0100, Robin Murphy wrote:
On 2020-06-04 22:28, Florian Fainelli wrote:
For the BCM2835 c
On 6/5/2020 7:41 AM, Robin Murphy wrote:
> On 2020-06-05 14:46, Robin Murphy wrote:
>> On 2020-06-05 14:20, Mark Brown wrote:
>>> On Fri, Jun 05, 2020 at 12:34:36PM +0100, Robin Murphy wrote:
On 2020-06-04 22:28, Florian Fainelli wrote:
>>>
> For the BCM2835 case which is deemed perform
On Fri, Jun 05, 2020 at 03:41:27PM +0100, Robin Murphy wrote:
> Ha, and in fact having checked a build out of curiosity, this patch as-is
> actually stands to make things considerably worse. At least with GCC 8.3 and
> bcm2835_defconfig, bcm2835_spi_interrupt_common() doesn't get inlined, which
>
On 2020-06-05 14:46, Robin Murphy wrote:
On 2020-06-05 14:20, Mark Brown wrote:
On Fri, Jun 05, 2020 at 12:34:36PM +0100, Robin Murphy wrote:
On 2020-06-04 22:28, Florian Fainelli wrote:
For the BCM2835 case which is deemed performance critical, we would
like
to continue using an interrupt
On 2020-06-05 14:20, Mark Brown wrote:
On Fri, Jun 05, 2020 at 12:34:36PM +0100, Robin Murphy wrote:
On 2020-06-04 22:28, Florian Fainelli wrote:
For the BCM2835 case which is deemed performance critical, we would like
to continue using an interrupt handler which does not have the extra
compa
On Fri, Jun 05, 2020 at 12:34:36PM +0100, Robin Murphy wrote:
> On 2020-06-04 22:28, Florian Fainelli wrote:
> > For the BCM2835 case which is deemed performance critical, we would like
> > to continue using an interrupt handler which does not have the extra
> > comparison on BCM2835_SPI_CS_INTR.
On Fri, Jun 05, 2020 at 12:14:07PM +0100, Mark Brown wrote:
> [1/1] spi: bcm2835: Enable shared interrupt support
> commit: ecfbd3cf3b8bb73ac6a80ddf430b5912fd4402a6
Eh, sorry - this was me fat fingering another fix. At the very least
this needs to wait for the end of the merge window.
si
On 2020-06-04 22:28, Florian Fainelli wrote:
The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
For the BCM2835 case which is deemed performance critical, we would like
to continue using an interrupt handler which
On Thu, 4 Jun 2020 14:28:19 -0700, Florian Fainelli wrote:
> The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
> SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
>
> For the BCM2835 case which is deemed performance critical, we would like
> to continue using an i
On Fri, 2020-06-05 at 10:46 +0200, Nicolas Saenz Julienne wrote:
> Hi Florian,
> Thanks for taking over this!
>
> On Thu, 2020-06-04 at 14:28 -0700, Florian Fainelli wrote:
> > The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
> > SPI4, SPI5 and SPI6) share the same interrupt
On Fri, Jun 05, 2020 at 10:46:57AM +0200, Nicolas Saenz Julienne wrote:
> > -static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
> > +static inline irqreturn_t bcm2835_spi_interrupt_common(struct
> > spi_controller
> > *ctlr,
> > + u32
On Thu, Jun 04, 2020 at 02:28:19PM -0700, Florian Fainelli wrote:
> The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
> SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
>
> For the BCM2835 case which is deemed performance critical, we would like
> to continue usi
Hi Florian,
Thanks for taking over this!
On Thu, 2020-06-04 at 14:28 -0700, Florian Fainelli wrote:
> The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
> SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
I think this isn't 100% correct. SPI0 has its own interrupt
The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
For the BCM2835 case which is deemed performance critical, we would like
to continue using an interrupt handler which does not have the extra
comparison on BCM2835_
25 matches
Mail list logo
