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

2018-12-11 Thread 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 
>>> ---
>>>  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 ..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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2018-12-10 Thread james qian wang (Arm Technology China)
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 
> > ---
> >  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.

> 
> > diff --git a/Documentation/gpu/komeda-kms.rst 
> > b/Documentation/gpu/komeda-kms.rst
> > new file mode 100644
> > index ..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"

> 
> > +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.
> 
> > +architecture. A display pipeline is made up of multiple individual and
> > +functional pipeline stages called components, and every component has some
> > +specific capabilities that can give the flowed pipeline pixel data a
> > +particular processing.
> > +
> > +Typical D71 components:
> > +
> > +Layer
> > +-
> > +Layer is the first pipeline stage, which is for preparing the pixel data
> > +for the next stage. It fetches the pixel from memory, decodes it if it's
> > +AFBC, rotates the source image, unpacks or converts YUV pixels to the 
> > device
> > +internal RGB pixels, then adjust the color_space of pixels if need.
> 
>  adjusts  if needed.
> 
> 
> > +
> > +Scaler
> > +--
> > +As its name, scaler is taking responsability for scaling, and D71 also
> 
>   As its name suggests, scaler takes (or has) responsibility for
> 
> > +supports image enhancements by scaler.
> > +The usage of scaler is very flexible and can be connected to layer output
> > +for layer scaling, or connected to compositor and scale the whole display
> > +frame and then feed the output data into wb_layer which will then write it
> > +into memory.
> > +
> > +Compositor (compiz)
> > +---
> > +Compositor is for blending multiple layers or pixel data flows into one
> > +single display frame, and its output frame can be fed into post image
> > +processor and then on the monitor or fed into wb_layer and written to 
> > memory
> > +at the same time. And user also can insert a scaler between compositor and
> > +wb_layer to down scale the display frame first and then writing to memory.
> 
>   and then write to memory.
> 
> > +
> > +Writeback Layer (wb_layer)
> > +--
> > +Writeback layer do the opposite things of Layer, Which connect to compiz 
> > and try
> 
>does which
> 
> > +to write the composition result to memory.
> > +
> > +Post image processor (improc)
> > +-
> > +Post image processor is for adjusting frame data like gamma and color space
> > +to fit the requirements of the monitor.
> > +
> > +Timing controller (timing_ctrlr)
> > +
> > +Final stage of display pipeline, Timing controller is not for the pixel
> > +handling, but only for controlling the display timing.
> > +
> > +Merger
> > +--
> > +D71 scaler mostly only has half the horizontal input/output capabilities 
> > compare
> 
> 
> compared
> 
> > +with Layer, Like if Layer supports 4K input size, the scaler only can 
> > supports
> 
>like  
> support
> 
> > +2K input/output in some time. To achieve the fully frame scaling, D71 
> > introduce
> 
> full 
> introduces
> 
> > +Layer Split, which split the whole image to two half part and feed them to 
> > two
> 
>   splitsparts and feeds
> 
> > +Layers A