On Mon, Feb 29, 2016 at 06:10:53PM +0100, Martin Sperl wrote: > > > On 14.01.2016, at 05:07, Vinod Koul <vinod.koul@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html