On 26/09/17 22:54, Dmitry Osipenko wrote:
> On 27.09.2017 00:25, Jon Hunter wrote:
>>
>> On 26/09/17 21:54, Jon Hunter wrote:
>>>
>>> On 25/09/17 23:35, Dmitry Osipenko wrote:
>>>> Currently efuse driver requests DMA channel from an arbitrary DMA device,
>>>> it is not a problem since there is only one DMA provider for Tegra20 yet,
>>>> but it will become troublesome once another provider would be added.
>>>>
>>>> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
>>>> ---
>>>> arch/arm/boot/dts/tegra20.dtsi | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
>>>> index fb485a5e63d7..f1579c9a7ef4 100644
>>>> --- a/arch/arm/boot/dts/tegra20.dtsi
>>>> +++ b/arch/arm/boot/dts/tegra20.dtsi
>>>> @@ -600,6 +600,8 @@
>>>> clock-names = "fuse";
>>>> resets = <&tegra_car 39>;
>>>> reset-names = "fuse";
>>>> + dmas = <&apbdma 0>;
>>>> + dma-names = "fuse";
>>>> };
>>>>
>>>> pcie@80003000 {
>>>>
>>>
>>> Acked-by: Jon Hunter <jonathanh@xxxxxxxxxx>
>>
>> Actually, request-id '0' is a valid request. Does this work ok?
>>
>
> It works fine, I have verified that reading on CPU == reading by DMA. The
> REQ_SEL 0 is "Not Assigned" and seems acts as DRQ=1. I know that it is not
> entirely correct, but APB DMA driver is hardcoded to the master mode, while we
> need slave mode.
Looking at the TRM I see that it is 'CNTR_REQ' so I am not sure if this
is a timer/counter that is driving this.
Jon
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
