On Fri, Oct 30, 2015 at 8:08 PM, Sinan Kaya <okaya@xxxxxxxxxxxxxx> wrote: >> The ACPI tables DSDT and CSRT (more info here: >> http://www.acpi.info/links.htm) defines properties. >> >> DSDT: >> per DMAC: the resources >> per client: FixedDMA descriptor that contains channel / request line >> pair. >> >> CSRT: >> necessary table to map which DMAC provides which request line, thus >> request line numbering are global on platform. >> >> When DMAC driver is probed in the running system it should call as >> well registration function from acpi-dma.c. >> >> All clients when use new DMA slave API gets channel automatically >> based on their FixedDMA property. >> >> So, above is how it should be done. Didn't actually checked what this >> driver does. >> > I was going to reply to all the questions in one pass but let me handle > piece by piece. > > Here are some facts. > - This hardware supports memcpy and memset only. > - Memset feature was removed from the kernel sometime around 3.14. So no > memset support in this driver either. > - The hardware does not support DMA slave support > - The goal is to provide an interface to DMA engine framework for memcpy > optimization so that the rest of the kernel drivers and applications make > use of the hardware. > > CSRT is an Intel specific ACPI table for slave devices. Wrong. It was designed by Microsoft to support multiple controllers, in particular DMACs. Have you read that document I posted link to? > It was decided by > Linaro that CSRT will not be supported for ARM64. Interesting, ARM64 platforms are not going to have more than one DMAC per system? > There were some discussions in ACPI forums to define a similar table for > ARM64 but we are not there today and this hardware does not support slave > interface. > > ACPI enumeration is just like any other platform device. The driver gets > looked up by a QCOM specific HID and the driver gets probed with the rest of > the arguments in DSM object similar to device-tree attributes. The code uses > device functions so the driver is not aware of where the parameters are > coming from. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
