On 10/30/2015 11:33 PM, Jon Masters wrote:
Hi Andy,
On 10/30/2015 04:15 PM, Andy Shevchenko wrote:
On Fri, Oct 30, 2015 at 10:08 PM, Al Stone <al.stone@xxxxxxxxxx> wrote:
On 10/30/2015 01:01 PM, Mark Rutland wrote:
On Fri, Oct 30, 2015 at 02:48:06PM -0400, Sinan Kaya wrote:
The CSRT is listed under "Want", not "Never" or "Don't Care", so Linaro
have certainly not said that CSRT will not be supported. If anything,
they have stated that the table should be supported.
"Want" means interesting, and probably useful, but no clear indication that
anyone actually needs it. At one point, we thought we might use the CSRT
for describing DMA, but it turns out we have not needed to.
Then you are going to have either 1 or 0 DMAC for slave devices, right?
I believe what Al means is that such hardware has not appeared
(publicly) until this time and so such situation was theoretical and
thus not covered by the Linaro wiki. Linaro had not prioritized CSRT
because it didn't seem that the need to support it would arise soon.
The CSRT, unfortunately, the only way how to enumerate DMAC to be used
by slave devices.
You may look into drivers/dma/acpi-dma.c for usage in Linux.
Yes, I know about _DSD, but I don't think it will provide soon any
other official mechanisms to what we have now. Better to ask Rafael
and Mika.
Thanks for the feedback. I agree that generally the plan is to use
existing tables from x86 on arm64 when possible. Please see below.
However, let's make sure we're saying the same thing: the CSRT table is
properly defined in the kernel include/acpi/actbl2.h file so one can read
such a table and use it if they so choose. Nothing that we have done at
Linaro in the arm64 part of the kernel relies on any of the content from
the CSRT, nor does it preclude someone relying on that content. So, the
CSRT is defined, and is usable, but is just not being used -- by Linaro --
at present.
This sounds clear.
If that needs to change, let me know; no one has asked us to use the CSRT
for a DMA engine, and we have not been provided any hardware that requires
it.
See above.
Here's, what I believe to be the summary:
1). QCOM are not implementing slave device support in their current
HIDMA hardware, therefore the requirement for CSRT does not exist *at
present* for this specific driver to be merged and the discussion in
this sub-thread pertains only to a situation not affecting HIDMA.
2). A requirement upon the CSRT should be clarified in the various
specifications. The SBBR[0] currently "recommends" CSRT but does not
necessarily provide guidance about what kinds of system resources would
be covered by that, and so there is a potential for this to be missed.
As one of the lead authors of certain ARM server specifications, I will
contact those involved in such and ensure that this is addressed with a
clarification in a future release.
Thanks for raising the concern,
Jon.
[0]
http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf
Apologies for creating confusion.
I tried using the dma-acpi.c implementation at the beginning. It didn't
quite play well with what I was trying to do with HIDMA. Since the file
header said Intel, I assumed it was an Intel specific implementation.
To confirm my suspicion, I looked at the Linaro wiki. I haven't seen
CSRT in MUST tables.
I considered WANT meaning some spec work required similar to DMAR vs.
IORT table.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
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
