linux-kernel - Re: [PATCH v1 0/2] rsnd: dts: change to use extended audio dmac register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <021012f9-f522-0efd-4bb2-c56917623266@mentor.com>
Date:   Fri, 22 Feb 2019 12:05:02 +0900
From:   jiada <jiada_wang@...tor.com>
To:     Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Simon Horman <horms@...ge.net.au>,
        Magnus Damm <magnus.damm@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/2] rsnd: dts: change to use extended audio dmac
 register

Hi Geert


On 2019/02/20 17:10, Kuninori Morimoto wrote:
> 
> Hi Geert
> 
>>> According to user reference manual for R-CAR H3 and M3-W SoCs,
>>> in order to access busif4 ~ busif7, extended audio dmac registers
>>> (PDMASAREn, PDMADAREn, PDMACHCREn)
>>> need to be used, rather than basic audio dmac registers
>>> (PDMASARn, PDMADARn, PDMACHCRn)
>>>
>>> This patch set updates H3 (= r8a7795) and M3-W (= r8a7796)
>>> to use extended audio dmac registers
>>
>> The same change should be applied for M3-N and RZ/G2M, right?
>>
Currently only H3 and M3-W support to use busif other than busif0,
I feel currently it's only necessary to use extended audio dmac register 
for these SoCs

>> R-Car E3 and RZ/G2E already use the extended register set, as they do not
>> have the basic set.
>>
>> For SoCs having both, this feels a bit like describing software policy, instead
>> of hardware, to me. Would it make sense to extend the audio bindings, and
>> allow describing both the basic and extended register sets, and let the driver
>> make the decision which one to use?
> 
> I don't think we need to use basic register.
> This means extended register only is very enough.
> I'm not sure why datasheet is indicating basic...
> 
Extended audio dmac registers covers all function of basic ones,
so there is no need to use basic registers

Thanks,
Jiada

> Best regards
> ---
> Kuninori Morimoto
>