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:   Mon, 7 Nov 2016 11:17:45 +0100
From:   Benjamin Gaignard <benjamin.gaignard@...aro.org>
To:     Laura Abbott <labbott@...hat.com>
Cc:     Sumit Semwal <sumit.semwal@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        yudongbin@...ilicon.com, Chen Feng <puck.chen@...ilicon.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        kernel@...inux.com
Subject: Re: [PATCH 0/3] add ION driver for STIh4xx SoC

Hello Laura,

What are plumbers outputs for ION after your talk ?

Regards,
Benjamin

2016-10-27 1:25 GMT+02:00 Laura Abbott <labbott@...hat.com>:
> On 10/26/2016 08:05 AM, Benjamin Gaignard wrote:
>>
>> 2016-10-26 16:44 GMT+02:00 Sumit Semwal <sumit.semwal@...aro.org>:
>>>
>>> On 26 October 2016 at 20:11, Benjamin Gaignard
>>> <benjamin.gaignard@...aro.org> wrote:
>>>>
>>>> 2016-10-26 15:51 GMT+02:00 Sumit Semwal <sumit.semwal@...aro.org>:
>>>>>
>>>>> Hello Benjamin,
>>>>>
>>>>> On 26 October 2016 at 19:02, Benjamin Gaignard
>>>>> <benjamin.gaignard@...aro.org> wrote:
>>>>>>
>>>>>> It is more or less a copy of Hisilicon driver but with a heap
>>>>>> definition
>>>>>> fitting with STIH4xx SoC needs.
>>>>>> I have just chnage the some function prefix from "hi6220" to "sti".
>>>>>>
>>>>> Thanks for your patches!
>>>>>
>>>>> I was just wondering if you couldn't convert the HiSilicon driver into
>>>>> something like a 'simple-ion' driver, and have just the DT definitions
>>>>> as specifics? This would save a lot of code duplication, and keep it
>>>>> as a simple interface for common heaps like cma.
>>>>
>>>>
>>>> Create a simple-ion driver is a good idea but it means that heaps
>>>> (configuration, name, etc..)
>>>> will have to be describe into devicetree. I'm not sure if that will is
>>>> acceptable.
>>>>
>>>>>
>>>>> If there are any ST-specific requirements that are incompatible with
>>>>> the existing driver, it should be clearly documented out here I think.
>>>>
>>>>
>>>> heaps names and Ids aren't the same so I can't reuse hisilicon driver.
>>>>
>>> But I'd suspect both these are solvable with using something like
>>> 'generic,cma' instead of 'hisi,cma' or 'st,cma'?
>>
>>
>> yes, but it requires to describe the heaps in devicetree.
>> Hisilicon driver was doing like that until last month but Laura
>> convert it to common platform:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/android/ion/hisilicon?id=b6e336dbeda85585c3ba6d935753d8240e18baf1
>>
>> I bet she got good reasons do to that so I have implemented sti ION
>> driver in this mindset.
>>
>
> I agree that having common code would be useful. There are some
> generic bindings listed in drivers/staging/android/ion/devicetree.txt
> so we could go with linux,ion-heap-dma.
>
> The changes got merged and there were never mailing list objections
> but that's because the devicetree maintainers got busy and never
> actually looked at them and Arnd at least still didn't like the
> idea of Ion in devicetree. I'd like to wait until after plumbers
> next week to decide what to do.
>
>
>
>>>>
>>> Best,
>>> Sumit.
>>
>>
>>
>>
>
> Thanks,
> Laura



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ