linux-kernel - Re: [PATCH v5 1/2] dt-bindings: dma: Add bindings for intel LGM SOC

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Sep 2020 23:03:22 +0800
From:   "Reddy, MallikarjunaX" <mallikarjunax.reddy@...ux.intel.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Rob Herring <robh@...nel.org>, dmaengine@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        andriy.shevchenko@...el.com, cheol.yong.kim@...el.com,
        qi-ming.wu@...el.com, chuanhua.lei@...ux.intel.com,
        malliamireddy009@...il.com
Subject: Re: [PATCH v5 1/2] dt-bindings: dma: Add bindings for intel LGM SOC

Hi Vinod,
Thanks for the review, please see my comments inline.

On 8/31/2020 7:00 PM, Vinod Koul wrote:
> On 31-08-20, 16:06, Reddy, MallikarjunaX wrote:
>> Hi Vinod,
>>
>> Thanks for the review. Please see my comment inline.
>>
>> On 8/28/2020 6:45 PM, Vinod Koul wrote:
>>> On 27-08-20, 17:54, Reddy, MallikarjunaX wrote:
>>>> Hi Vinod,
>>>> Thanks for the review comments.
>>>>
>>>> On 8/25/2020 7:21 PM, Vinod Koul wrote:
>>>>> On 18-08-20, 15:00, Reddy, MallikarjunaX wrote:
>>>>>
>>>>>>>> +
>>>>>>>> +            intel,chans:
>>>>>>>> +              $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>>>> +              description:
>>>>>>>> +                 The channels included on this port. Format is channel start
>>>>>>>> +                 number and how many channels on this port.
>>>>>>> Why does this need to be in DT? This all seems like it can be in the dma
>>>>>>> cells for each client.
>>>>>> (*ABC)
>>>>>> Yes. We need this.
>>>>>> for dma0(lgm-cdma) old SOC supports 16 channels and the new SOC supports 22
>>>>>> channels. and the logical channel mapping for the peripherals also differ
>>>>>> b/w old and new SOCs.
>>>>>>
>>>>>> Because of this hardware limitation we are trying to configure the total
>>>>>> channels and port-channel mapping dynamically from device tree.
>>>>>>
>>>>>> based on port name we are trying to configure the default values for
>>>>>> different peripherals(ports).
>>>>>> Example: burst length is not same for all ports, so using port name to do
>>>>>> default configurations.
>>>>> Sorry that does not make sense to me, why not specify the values to be
>>>>> used here instead of defining your own name scheme!
>>>> OK. Agreed. I will remove port name from DT and only use intel,chans
>>> what is intel,chans, why not use dma-channels?
>>   The intel,chans says about the channels included on the correspondng port.
> What do you mean by a port here?
Here Port is nothing but Peripheral(SPI, HSNAND...)
>
>> Format is channel start number and how many channels on this port.
> It is perfectly reasonable to have 16 channels but linux not use use all, lets
> say from 5th channel channel onwards
>
> So you need to use standard dma-channels also with dma-channel-mask to
> specify which channels linux can use
Ok, let me verify and use the standard dma-channels also dma-channel-mask.
>
>>   The reasong behind using this attribute instead of standrad dma-channels
>> is...
>>
>>
>> DMA_VER22 HW supports 22 channels. But there is a hole in HW, total it can
>> use only 16.
>>
>> Old soc supports 4ports and 16 channels.
>> New soc supports 6ports and 22 channels.
>> (old and new soc carry the same version VER22)
>>
>> port channel mapping for the old and new soc also not the same.
>> old soc: logical channels:(Rx, Tx)
>> 0, 1 - SPI0
>> 2, 3 - SPI1
>> 4, 5 - HSNAND
>> 12, 14, 13, 15 - Memcopy
>>
>> New soc: Logical channels(Rx, Tx)
>> 0, 1 - SPI0
>> 2, 3 - SPI1
>> 4, 5 - SPI2
>> 6, 7 - SPI3
>> 8, 9 - HSNAND
>> 10 to 21 - Mcopy
> Mapping is different, client can set that channel required in dmas
> property and use a specific required channel.
OK.
>
>> Because of these reasons we are trying to use "intel,chans" attribute, and
>> reading then number of channels from the dt.
>> Advantaage:
>> 1. we can map the channels correspondign to port
>> 2. Dynamically configure the channels (due to hw limitation)
>>
>> If this is not ok, please suggest us the better way to handle this.