Re: [PATCH, V4, 2/5] spi: bcm-qspi: Add SPI flash and MSPI driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/28/2016 11:28 AM, Mark Brown wrote:
> On Wed, Jul 20, 2016 at 12:41:11PM -0700, Florian Fainelli wrote:
> 
>> Now, as to whether it makes sense to model the IDM enable/disable
>> (intr_regs resource) and the 7 32-bits interrupt status/acknowledge
>> words at the end of the MSPI+BSPI block (intr_status_regs resource) as
>> an interrupt controller makes sense or not, it is kind of hard to say,
>> because really the IDM IO_CONTROL aggregates more than just interrupt
>> enable/disable bits here, but the overall ownership of this IDM
>> IO_CONTROL is clear and it belongs to the SPI function of the system.
> 
> TBH if that's all it's doing then I'm surprised it's not simple to
> handle it with irq_setup_generic_chip() - have you looked at that at
> all?

The generic IRQ chip model assumes that the mask/unmask/ack logic will
operate against the same register base address, which won't be the case
for the NS/NSP/NS2 platforms where the mask/unmask is in one register
set (coined IDM), and the ack is in another one (actually 7 * 32-bits
words).

You would need to write a custom irq_chip implementation to suppor that
which is not a great fit because it is not dealing with just pure
interrupt enable/disable bits, but manages a 32-bits word of register
space which has other controls, and another set of 32-bits words which
functionally belongs in the SPI controller for interrupt statuses.

In that case, my personal preference is to abstract that within a
SoC-specific glue layer, ala brcmnand, where the SoC that needs this
glue has full control and clear ownership of this 32-bits word of
register space. This keeps the SoC-specific logic clean and separate,
reasonably well abstracted, while making the core SPI driver deal with
the ideal situation and not knowing how the SoC glues things together.

So yes, we actually did put some thought into this.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux