On 12/10/18 3:47 AM, james qian wang (Arm Technology China) wrote:
> On Wed, Dec 05, 2018 at 06:08:38PM -0800, Randy Dunlap wrote:
>> On 12/5/18 2:25 AM, james qian wang (Arm Technology China) wrote:
>>> Signed-off-by: James (Qian) Wang <james.qian.wang@xxxxxxx>
>>> ---
>>> Documentation/gpu/drivers.rst | 1 +
>>> Documentation/gpu/komeda-kms.rst | 483 +++++++++++++++++++++++++++++++
>>> 2 files changed, 484 insertions(+)
>>> create mode 100644 Documentation/gpu/komeda-kms.rst
>>
>> Hi,
>>
>> I have some editing changes for you to consider, although I did have a few
>> problems with reading the text.
>>
>
> Thank you Randy, I'll correct the doc according to your comments in the next version.
>
Hi James,
>>> diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
>>> new file mode 100644
>>> index 000000000000..8af925ca0869
>>> --- /dev/null
>>> +++ b/Documentation/gpu/komeda-kms.rst
>>> @@ -0,0 +1,483 @@
>>> +.. SPDX-License-Identifier: GPL-2.0
>>> +
>>> +==============================
>>> + drm/komeda ARM display driver
>>> +==============================
>>> +
>>> +The drm/komeda driver supports for the ARM display processor D71 and later
>>
>> driver supports the ARM
>>
>>> +IPs, this document is for giving a brief overview of driver design: how it
>>
>> IPs. This document gives a brief overview of the driver design:
>>
>> (although I hate using "IPs" like that.)
>
> How about "Product" or "Chipset"
Yes, much better IMO.
>>> +works and why design it like that.
>>> +
>>> +Overview of D71 like display IPs
>>> +================================
>>> +
>>> +From D71, Arm display IP begins to adopt a flexible and modularized
>>
>> ARM
>
> Sorry my fault, I used "ARM" in the initial lines which misleads you, but after
> Arm reband last year, the "Arm" is the right version.
>
> And I'll unify all the usage to "Arm" in the next version.
I thought that you would know more about that than I do.
[snip]
>> So above, I tried to write what I thought you meant, but saying that Layer_Split
>> needs to be handled in user mode ... and then saying that if it is handled in the
>> kernel, it would be smooth and simple -- that seems to be contradictory to me,
>> so I guess I didn't understand it very well.
>>
>
> Sorry, I need to reorganize my sentence. maybe like below:
>
> Layer_Split is quite complicated feature, which splits a big image into
> two parts and handle it by two layers and scalers individually.
handles
> But it imports a edge problem or effect in the middle of image after the split.
an middle of the image
> To avoid such problem, need a complicated Split calculation and some special
such a problem, it needs a complicated
> configurationes to the layer and scaler.
configurations
> We'd better hide such HW related complexity to user mode.
thanks,
--
~Randy
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
