linux-kernel - Re: [PATCH 07/16] spi: bcm63xx-hsspi: Add polling mode support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45f71d68-1cbb-a775-46f3-e07ccce4c8d8@broadcom.com>
Date:   Wed, 11 Jan 2023 14:57:31 -0800
From:   William Zhang <william.zhang@...adcom.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Linux SPI List <linux-spi@...r.kernel.org>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
        anand.gore@...adcom.com, tomer.yacoby@...adcom.com,
        dan.beygelman@...adcom.com, joel.peshkin@...adcom.com,
        f.fainelli@...il.com, jonas.gorski@...il.com,
        kursad.oney@...adcom.com, dregan@...l.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/16] spi: bcm63xx-hsspi: Add polling mode support



On 01/11/2023 02:41 PM, Mark Brown wrote:
> On Wed, Jan 11, 2023 at 12:13:43PM -0800, William Zhang wrote:
> 
>> Thanks for the explanation. I saw the spi-uniphier.c and spi-bcm2835.c doing
>> the trick you mentioned(thanks Kursad for pointing out).  In our case, even
>> the maximum fifo size usage(512bytes), the polling still have better
>> performance than interrupt. The MTD test result included in this patch is
>> based on maximum fifo usage. So there is no benefit to switch to interrupt
>> based on transfer size.
> 
>> Does the spi framework has any requirement on how much time that the
>> driver's transfer_one function can spend?  I can see the polling function
>> might take quite some time in busy loop if the clock is low, for example, at
>> 100Hz(slowest clock this controller can go), it takes 512x8/100Hz ~= 41ms to
>> complete.  If this is something in concern,  I can do the interrupt switch
>> based on a time limit value if interrupt is available.
> 
> There's no fixed limit, some hardware just doesn't have DMA.  Some
> doesn't even have interrupts which is even better.  If there's always a
> clear benefit for using PIO then just do that, perhaps creating a sysfs
> hook to allow people to switch to DMA if they need it (rather than
> requiring people to update their DT, this is really a runtime
> performance tradeoff rather than a description of the hardware).  If
> there's a point at which the performance is very similar then it's
> probably worth switching to DMA there to lower the CPU usage, but if
> it's always faster to use PIO then just defaulting to PIO seems like the
> best option.
> 
Sure. I will add the sysfs option. Interrupt node is now required in dts 
but by default it will still runs at polling mode until sysfs option is 
set to use interrupt.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4212 bytes)