On 01/09/2023 11:06 AM, Mark Brown wrote:
> On Fri, Jan 06, 2023 at 07:35:59PM -0800, William Zhang wrote:
>> On 01/06/2023 01:47 PM, Mark Brown wrote:
>>> On Fri, Jan 06, 2023 at 12:07:59PM -0800, William Zhang wrote:
> 
>>>> When interrupt is not defined in the HSSPI dts node, driver switches to
>>>> polling mode for controller SPI message processing.  Also add driver
>>>> banner message when the driver is loaded successfully.
> 
>>> This should not be something the user selects via the DT, if the polling
>>> mode is better then the driver should just use it regardless of there
>>> being an interrupt wired up.  Generally there's some point at which the
>>> benefits of polling become minimal (and the costs more impactful) but if
>>> the DMA setup is as bad as it sounds then the driver should just ignore
>>> the interrupt.
> 
>> I agree but this is more for backward compatibility as the original driver
>> uses interrupt to work with MIPS based SoC and I do not want to change that
>> behavior.  For newer devices I added, they work in polling mode by default
>> with the dts I supplied.  IMHO it is also good to have this fallback option
>> to use interrupt in case user is sensitive to cpu usage.
> 
> You can put whatever logic is needed in the code - for something like
> this an architecture based define isn't ideal but is probably good
> enough if need be (though I'd not be surprised if it turned out that
> there was also some performance benefit for the MIPS systems too, at
> least for smaller transfers).
> 
I just don't know what other logic I can put in the driver to select 
interrupt or polling mode.  Only the end user know if performance or cpu 
usage is more important to their application.