Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1515980 > unrolled thread

Re: [PATCH 0/3] add ION driver for STIh4xx SoC

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] add ION driver for STIh4xx SoC Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2016-11-07 11:20 +0100
    Re: [PATCH 0/3] add ION driver for STIh4xx SoC Laura Abbott <labbott@redhat.com> - 2016-11-07 23:20 +0100
      Re: [PATCH 0/3] add ION driver for STIh4xx SoC Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2016-11-08 10:20 +0100
        Re: [PATCH 0/3] add ION driver for STIh4xx SoC Laura Abbott <labbott@redhat.com> - 2016-11-09 06:00 +0100

#1515980 — 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@redhat.com>:
> On 10/26/2016 08:05 AM, Benjamin Gaignard wrote:
>>
>> 2016-10-26 16:44 GMT+02:00 Sumit Semwal <sumit.semwal@linaro.org>:
>>>
>>> On 26 October 2016 at 20:11, Benjamin Gaignard
>>> <benjamin.gaignard@linaro.org> wrote:
>>>>
>>>> 2016-10-26 15:51 GMT+02:00 Sumit Semwal <sumit.semwal@linaro.org>:
>>>>>
>>>>> Hello Benjamin,
>>>>>
>>>>> On 26 October 2016 at 19:02, Benjamin Gaignard
>>>>> <benjamin.gaignard@linaro.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

[toc] | [next] | [standalone]

#1516622

On 11/07/2016 02:17 AM, Benjamin Gaignard wrote:
> Hello Laura,
>
> What are plumbers outputs for ION after your talk ?
>
> Regards,
> Benjamin
>

We agreed to suspend work on new major Ion features and work
towards a more generic design being pushed by the graphics
team (see https://github.com/cubanismo/allocator). Platform/
devicetree support is more interesting because it will still
be needed for a more generic design but the existing
bindings still aren't acceptable to the DT maintainers. I
don't see much value in trying to convert another board to
a set of bindings that aren't actually acceptable or even
refactor existing code.

The objections to the bindings are that they are still too
linux specific and not platform specific enough. Most of
the reason why I went with this proposal had to do with
getting a device for CMA, otherwise there isn't much of a need
for anything in devicetree. I'll be giving this more thought,
if you have your own ideas, please feel free to submit them
for review.

Thanks,
Laura


> 2016-10-27 1:25 GMT+02:00 Laura Abbott <labbott@redhat.com>:
>> On 10/26/2016 08:05 AM, Benjamin Gaignard wrote:
>>>
>>> 2016-10-26 16:44 GMT+02:00 Sumit Semwal <sumit.semwal@linaro.org>:
>>>>
>>>> On 26 October 2016 at 20:11, Benjamin Gaignard
>>>> <benjamin.gaignard@linaro.org> wrote:
>>>>>
>>>>> 2016-10-26 15:51 GMT+02:00 Sumit Semwal <sumit.semwal@linaro.org>:
>>>>>>
>>>>>> Hello Benjamin,
>>>>>>
>>>>>> On 26 October 2016 at 19:02, Benjamin Gaignard
>>>>>> <benjamin.gaignard@linaro.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
>
>
>

[toc] | [prev] | [next] | [standalone]

#1516985

Ok so no more dev on ION but can we add ION drivers  like hisilicon does ?

[toc] | [prev] | [next] | [standalone]

#1517777

On 11/08/2016 01:18 AM, Benjamin Gaignard wrote:
> Ok so no more dev on ION but can we add ION drivers  like hisilicon does ?
> 

If we can agree upon bindings, yes I think it would make sense
to have more platform support. Ideally, it would translate over
to newer features as well.

Thanks,
Laura

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web