[PATCH v1 8/9] drm/doc: Add initial komeda driver documentation

[Randy Dunlap]

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 at arm.com>
>>> ---
>>>  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