[PATCH V2 3/8] dmaengine: bcm2835: use shared interrupt for channel 11 to 14.
Vinod Koul
vinod.koul at intel.com
Thu Mar 3 07:45:18 PST 2016
On Mon, Feb 29, 2016 at 06:10:53PM +0100, Martin Sperl wrote:
>
> > On 14.01.2016, at 05:07, Vinod Koul <vinod.koul at intel.com> wrote:
> >
> > On Wed, Jan 13, 2016 at 03:24:59PM +0100, Martin Sperl wrote:
> >>>> But that would be frowned upon, so I had to come up with the approach
> >>>> taken, which makes the following assumptions:
> >>>
> >>> DT was designed to move this info and hardcoding from kernel into
> >>> DT, so why cant we do that?
> >> We still need to be backwards-compatible - at least that is what
> >> everyone tells me, so I need to hard-code fallbacks for those values.
> >
> > IMO hard code for falling back is okay as that supports old cases and new
> > platforms use geric DT info and new devices can be supported generically,
> > please check with DT folks..
> >
> >>>> * the DT maps only the interrupts that are assigned to the HW block
> >>>> * the driver knows about the number of DMA channels in HW
> >> that could be a DT property, yes.
> >>>> * the driver knows about the mapping of shared interrupts
> >>>> (11-14 share irq).
> >> OK - how would you define that "mapping" in a "sane" manner in the DT
> >> that allows us to have multiple such mappings in the future?
> >
> > You are hard coding the flags for each channel, we can pass this for each
> > channel in the interrupt configi, a flag share/none..? Please run this thru
> > DT experts and I am not one of them..
>
> So here a “simple” approach with the following device tree addition (plus defaults):
> interrupts = <1 16>, /* dma 0 irq */
> <1 17>, /* dma 1 irq */
> ...
> <1 26>, /* dma 10 irq */
> <1 27>, /* dma 11-14 irq */
> <1 28>; /* dma all irq */
> brcm,dma-channel-mask = <0x7f35>;
> /* new properties below - also the defaults */
> brcm,dma-channel-shared-mask = <0x7800>;
> brcm,dma-shared-irq-index = <11>;
>
> Is this sufficient to move forward?
This looks okay to me for now, though am not a DT expert. Please send
patches and CC DT folks as relevant and we can discuss..
--
~Vinod
More information about the linux-rpi-kernel
mailing list