[PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hello,

This patch set simply adds all available VSP1 devices to the r8a7790 and
r8a7791 .dtsi.

Laurent Pinchart (2):
  ARM: shmobile: r8a7790: Add VSP1 devices to DT
  ARM: shmobile: r8a7791: Add VSP1 devices to DT

 arch/arm/boot/dts/r8a7790.dtsi | 51 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi | 39 ++++++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Cao Minh Hiep]

Hi Laurent,

We are testing the upstream linux version on Lager.
I have tried to test VSP1 driver on r8a7790(Lager).
But I don't know how to test it.
Could you please tell the method to test it?

Best Regards,
Jinso/Cao Minh Hiep.

On 2014年09月14日 08:36, Laurent Pinchart wrote:
> Hello,
>
> This patch set simply adds all available VSP1 devices to the r8a7790 and
> r8a7791 .dtsi.
>
> Laurent Pinchart (2):
>    ARM: shmobile: r8a7790: Add VSP1 devices to DT
>    ARM: shmobile: r8a7791: Add VSP1 devices to DT
>
>   arch/arm/boot/dts/r8a7790.dtsi | 51 ++++++++++++++++++++++++++++++++++++++++++
>   arch/arm/boot/dts/r8a7791.dtsi | 39 ++++++++++++++++++++++++++++++++
>   2 files changed, 90 insertions(+)
>

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

Hi Cao Minh,

On Tuesday 30 September 2014 13:47:32 Cao Minh Hiep wrote:
> Hi Laurent,
> 
> We are testing the upstream linux version on Lager.
> I have tried to test VSP1 driver on r8a7790(Lager).
> But I don't know how to test it.
> Could you please tell the method to test it?

Sure.

I've attached the test script I use to configure the VSP1 pipeline to this e-
mail.

Syntax: vsp1.sh dev cmd [...]

Supported commands:
 - m2d | m2d-bru | m2d-crop | m2d-scale | m2m | m2m-crop | m2m-scale infmt 
outfmt
 - input index infmt
 - output index outfmt

"dev" should be the media device name without the /dev/ prefix. For the first 
VSP1 that would thus be "media0".

"cmd" is one of the values listed above. m2d stands for memory to display 
(using out of tree patches for the DRM driver) and m2m stands for memory to 
memory. The *-bru command configures the BRU to blend two inputs, the *-crop 
commands will perform cropping on the input and the -scale commands will 
include the scaler (UDS) in the pipeline.

All the m2d and m2m commands perform pipeline configuration. They take two 
arguments, the input format and the output format. They should both be one of 
BGR24, BGR32, ABGR32, XBGR32, RGB24, RGB32, ARGB32, XRGB32, RGB332, RGB555, 
RGB565, NV12M, NV16M, NV21M, NV61M, UYVY, VYUY, YUV420M, YUYV or YVYU.

The input and output commands will invoke yavta to capture images from a WPF 
(output) or stream images to an RPF (input). You can find a tarball with the 
test frames I use at http://www.ideasonboard.org/frame-reference.tar.bz2, but 
you can replace them with any binary test image.

The script requires the media-ctl and yavta utilities. The former is now part 
of the v4l-utils project, available at http://git.linuxtv.org/cgit.cgi/v4l-utils.git/. The latter can be found at http://git.ideasonboard.org/yavta.git.

I realize this probably lacks details, so please come back with any question 
you might have and I'll do my best to answer them.

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: vsp1.sh --]
[-- Type: application/x-shellscript, Size: 7283 bytes --]

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Cao Minh Hiep]

Hi Laurent,

Thank you for your help!

On 2014年10月01日 07:56, Laurent Pinchart wrote:
> Hi Cao Minh,
>
> On Tuesday 30 September 2014 13:47:32 Cao Minh Hiep wrote:
>> Hi Laurent,
>>
>> We are testing the upstream linux version on Lager.
>> I have tried to test VSP1 driver on r8a7790(Lager).
>> But I don't know how to test it.
>> Could you please tell the method to test it?
> Sure.
>
> I've attached the test script I use to configure the VSP1 pipeline to this e-
> mail.
>
> Syntax: vsp1.sh dev cmd [...]
>
> Supported commands:
>   - m2d | m2d-bru | m2d-crop | m2d-scale | m2m | m2m-crop | m2m-scale infmt
> outfmt
>   - input index infmt
>   - output index outfmt
>
> "dev" should be the media device name without the /dev/ prefix. For the first
> VSP1 that would thus be "media0".
I'll try to do it as you are showing me.
Please let's me ask you again if I have any problem.


Thank you!
Jinso/Cao Minh Hiep

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Devendra Talegaonkar]

Hi,
Thanks for the information about vsp1.sh script. But I unable to run it on
the target. Can you please give the sample command to run the script and
information about the options we are giving on command line. My LCD
resolution is 1024x768 and I am trying with the image files you have
supplied with this message.
Thanks in advance,

Regards,
Devendra 

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Devendra Talegaonkar]

Laurent Pinchart <laurent.pinchart <at> ideasonboard.com> writes:

> 
> Hi Cao Minh,
> 
> On Tuesday 30 September 2014 13:47:32 Cao Minh Hiep wrote:
> > Hi Laurent,
> > 
> > We are testing the upstream linux version on Lager.
> > I have tried to test VSP1 driver on r8a7790(Lager).
> > But I don't know how to test it.
> > Could you please tell the method to test it?
> 
> Sure.
> 
> I've attached the test script I use to configure the VSP1 pipeline to this e-
> mail.
> 
> Syntax: vsp1.sh dev cmd [...]
> 
> Supported commands:
>  - m2d | m2d-bru | m2d-crop | m2d-scale | m2m | m2m-crop | m2m-scale infmt 
> outfmt
>  - input index infmt
>  - output index outfmt
> 
>> 
> The input and output commands will invoke yavta to capture images from a WPF 
> (output) or stream images to an RPF (input). You can find a tarball with the 
> test frames I use at http://www.ideasonboard.org/frame-reference.tar.bz2, but 
> you can replace them with any binary test image.
> 
>
Hello,
I am testing VSP1 on lager board. You have mentioned that by invoking input
command, file can be streamed to RPF. Does that mean, If we stream the file
via input command we can seee it on LCD via VSPD0. If my understanding is
correct can you explain how to test that by setting plane priority? Because
VSPD0 can out put the data on predefined plane.
As I am stuck here, awaiting for the earliest response.

Regards, 
Devendra Talegaonkar

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hi Devendra,

On Monday 15 December 2014 03:42:59 Devendra Talegaonkar wrote:
> Laurent Pinchart writes:
> > On Tuesday 30 September 2014 13:47:32 Cao Minh Hiep wrote:
> > > Hi Laurent,
> > > 
> > > We are testing the upstream linux version on Lager.
> > > I have tried to test VSP1 driver on r8a7790(Lager).
> > > But I don't know how to test it.
> > > Could you please tell the method to test it?
> > 
> > Sure.
> > 
> > I've attached the test script I use to configure the VSP1 pipeline to this
> > e- mail.
> > 
> > Syntax: vsp1.sh dev cmd [...]
> > 
> > Supported commands:
> >  - m2d | m2d-bru | m2d-crop | m2d-scale | m2m | m2m-crop | m2m-scale infmt
> > 
> > outfmt
> > 
> >  - input index infmt
> >  - output index outfmt
> > 
> > The input and output commands will invoke yavta to capture images from a
> > WPF (output) or stream images to an RPF (input). You can find a tarball
> > with the test frames I use at
> > http://www.ideasonboard.org/frame-reference.tar.bz2, but you can replace
> > them with any binary test image.
> 
> Hello,
> I am testing VSP1 on lager board. You have mentioned that by invoking input
> command, file can be streamed to RPF. Does that mean, If we stream the file
> via input command we can seee it on LCD via VSPD0. If my understanding is
> correct can you explain how to test that by setting plane priority? Because
> VSPD0 can out put the data on predefined plane.
> As I am stuck here, awaiting for the earliest response.

The direct connection between the VSPD and the DU isn't supported in the 
mainline kernel I'm afraid. I've implemented it in out-of-tree patches, but 
they would require extensions to the DRM API that I'm not happy with in their 
current form (so I don't expect the DRM developers to be happy either).

I've rebased the patches on a recent kernel, you can find them at

	git://linuxtv.org/pinchartl/fbdev.git vsp1/devel

Please note that I haven't had time to test the rebased version yet.

You can find a patched version of the modetest utility at

	git://git.ideasonboard.com/renesas/drm.git live

You might need to update the kernel headers, ioctl numbers might have changed 
when I've rebased the kernel patches.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hi Devendra,

Please don't drop the linux-sh list when replying.

On Tuesday 16 December 2014 06:48:33 Devendra Talegaonkar wrote:
> Hi,
>
> Thanks for the reply. I have applied the patches & now I am in the process
> of testing the same on the R-car board. But I have one problem. You have
> mentioned that for "vsp1.sh" script, "input" command streams the image data
> to RPF. Does that means, the RGB binaries which you have tested
> (http://www.ideasonboard.org/frame-reference.tar.bz2) can be streamed with
> the script and its output can be seen on DU?

That's correct. You need to use one of the m2d* (m2d, m2d-bru, m2d-crop or 
m2d-scale) commands to the vsp1.sh script.

You will also need to configure the DU using the modetest utility from the 
drm.git repository I've pointed to, using the -P argument to display the plane 
associated with the VSP1 and configuring it with the same size and format as 
the VSP1 LIF output.

> Also I am going to test the BRU with the script you have provided. Can you
> please let us know how to use the same?
> 
> On Tuesday, December 16, 2014 5:19 AM Laurent Pinchart wrote:
> > On Monday 15 December 2014 03:42:59 Devendra Talegaonkar wrote:
> >> Laurent Pinchart writes:
> >>> On Tuesday 30 September 2014 13:47:32 Cao Minh Hiep wrote:
> >>>> Hi Laurent,
> >>>> 
> >>>> We are testing the upstream linux version on Lager.
> >>>> I have tried to test VSP1 driver on r8a7790(Lager).
> >>>> But I don't know how to test it.
> >>>> Could you please tell the method to test it?
> >>> 
> >>> Sure.
> >>> 
> >>> I've attached the test script I use to configure the VSP1 pipeline
> >>> to this e-mail.
> >>> 
> >>> Syntax: vsp1.sh dev cmd [...]
> >>> 
> >>> Supported commands:
> >>>  - m2d | m2d-bru | m2d-crop | m2d-scale | m2m | m2m-crop | m2m-scale
> >>> infmt outfmt
> >>>  - input index infmt
> >>>  - output index outfmt
> >>> 
> >>> The input and output commands will invoke yavta to capture images
> >>> from a WPF (output) or stream images to an RPF (input). You can find
> >>> a tarball with the test frames I use at
> >>> http://www.ideasonboard.org/frame-reference.tar.bz2, but you can
> >>> replace them with any binary test image.
> >> 
> >> Hello,
> >> I am testing VSP1 on lager board. You have mentioned that by invoking
> >> input command, file can be streamed to RPF. Does that mean, If we
> >> stream the file via input command we can seee it on LCD via VSPD0. If
> >> my understanding is correct can you explain how to test that by
> >> setting plane priority? Because VSPD0 can out put the data on predefined
> >> plane.
> >> As I am stuck here, awaiting for the earliest response.
> >
> > The direct connection between the VSPD and the DU isn't supported in the
> > mainline kernel I'm afraid. I've implemented it in out-of-tree patches,
> > but they would require extensions to the DRM API that I'm not happy with
> > in their current form (so I don't expect the DRM developers to be happy
> > either).
> > 
> > I've rebased the patches on a recent kernel, you can find them at
> > 
> > git://linuxtv.org/pinchartl/fbdev.git vsp1/devel
> > 
> > Please note that I haven't had time to test the rebased version yet.
> > 
> > You can find a patched version of the modetest utility at
> > 
> > git://git.ideasonboard.com/renesas/drm.git live
> > 
> > You might need to update the kernel headers, ioctl numbers might have
> > changed when I've rebased the kernel patches. 

-- 
Regards,

Laurent Pinchart

RE: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Devendra Talegaonkar]

Hi,
Thanks for the reply. I could successfully stream file data to display via media link.
Now on Lager board, I am trying to stream live video data captured from camera ( VIN1 input via ADV7180 decoder, RGB565 )  to display. I am using yavta to capture data from camera and streaming it to rpf.0. But I am not able to see data on VGA. I am using following commands to establish media link
./vsp1.sh media1 m2d ARGB565 ARGB32
Then yavta to capture and stream data with following command:
"./yavta -c -n 4 -f RGB565 -s 400x200 /dev/video1 /dev/video10" ( video10 being associated dev for rpf.0)
modetest command as follows:
"./modetest -M rcar-du -s 17@11:1024x768@AR24 -d -P '11@32:1024x768@XR24"

Am I missing something or doing something wrong?

Thanks & Regards,
Devendra Talegaonkar - Automotive & Engineering | KPIT Cummins Infosystems Ltd | Ph: + 91 20 6652 5000 | M: +91 9822860528

-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
Sent: Wednesday, December 17, 2014 5:05 AM
To: Devendra Talegaonkar
Cc: linux-sh@vger.kernel.org
Subject: Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

Hi Devendra,

Please don't drop the linux-sh list when replying.

On Tuesday 16 December 2014 06:48:33 Devendra Talegaonkar wrote:
> Hi,
>
> Thanks for the reply. I have applied the patches & now I am in the
> process of testing the same on the R-car board. But I have one
> problem. You have mentioned that for "vsp1.sh" script, "input" command
> streams the image data to RPF. Does that means, the RGB binaries which
> you have tested
> (http://www.ideasonboard.org/frame-reference.tar.bz2) can be streamed
> with the script and its output can be seen on DU?

That's correct. You need to use one of the m2d* (m2d, m2d-bru, m2d-crop or
m2d-scale) commands to the vsp1.sh script.

You will also need to configure the DU using the modetest utility from the drm.git repository I've pointed to, using the -P argument to display the plane associated with the VSP1 and configuring it with the same size and format as the VSP1 LIF output.

> Also I am going to test the BRU with the script you have provided. Can
> you please let us know how to use the same?
>
> On Tuesday, December 16, 2014 5:19 AM Laurent Pinchart wrote:
> > On Monday 15 December 2014 03:42:59 Devendra Talegaonkar wrote:
> >> Laurent Pinchart writes:
> >>> On Tuesday 30 September 2014 13:47:32 Cao Minh Hiep wrote:
> >>>> Hi Laurent,
> >>>>
> >>>> We are testing the upstream linux version on Lager.
> >>>> I have tried to test VSP1 driver on r8a7790(Lager).
> >>>> But I don't know how to test it.
> >>>> Could you please tell the method to test it?
> >>>
> >>> Sure.
> >>>
> >>> I've attached the test script I use to configure the VSP1 pipeline
> >>> to this e-mail.
> >>>
> >>> Syntax: vsp1.sh dev cmd [...]
> >>>
> >>> Supported commands:
> >>>  - m2d | m2d-bru | m2d-crop | m2d-scale | m2m | m2m-crop |
> >>> m2m-scale infmt outfmt
> >>>  - input index infmt
> >>>  - output index outfmt
> >>>
> >>> The input and output commands will invoke yavta to capture images
> >>> from a WPF (output) or stream images to an RPF (input). You can
> >>> find a tarball with the test frames I use at
> >>> http://www.ideasonboard.org/frame-reference.tar.bz2, but you can
> >>> replace them with any binary test image.
> >>
> >> Hello,
> >> I am testing VSP1 on lager board. You have mentioned that by
> >> invoking input command, file can be streamed to RPF. Does that
> >> mean, If we stream the file via input command we can seee it on LCD
> >> via VSPD0. If my understanding is correct can you explain how to
> >> test that by setting plane priority? Because VSPD0 can out put the
> >> data on predefined plane.
> >> As I am stuck here, awaiting for the earliest response.
> >
> > The direct connection between the VSPD and the DU isn't supported in
> > the mainline kernel I'm afraid. I've implemented it in out-of-tree
> > patches, but they would require extensions to the DRM API that I'm
> > not happy with in their current form (so I don't expect the DRM
> > developers to be happy either).
> >
> > I've rebased the patches on a recent kernel, you can find them at
> >
> > git://linuxtv.org/pinchartl/fbdev.git vsp1/devel
> >
> > Please note that I haven't had time to test the rebased version yet.
> >
> > You can find a patched version of the modetest utility at
> >
> > git://git.ideasonboard.com/renesas/drm.git live
> >
> > You might need to update the kernel headers, ioctl numbers might
> > have changed when I've rebased the kernel patches.

--
Regards,

Laurent Pinchart

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hi Devendra,

On Friday 19 December 2014 05:05:22 Devendra Talegaonkar wrote:
> Hi,
> Thanks for the reply. I could successfully stream file data to display via
> media link. Now on Lager board, I am trying to stream live video data
> captured from camera ( VIN1 input via ADV7180 decoder, RGB565 )  to
> display. I am using yavta to capture data from camera and streaming it to
> rpf.0. But I am not able to see data on VGA. I am using following commands
> to establish media link ./vsp1.sh media1 m2d ARGB565 ARGB32
> Then yavta to capture and stream data with following command:
> "./yavta -c -n 4 -f RGB565 -s 400x200 /dev/video1 /dev/video10" ( video10
> being associated dev for rpf.0) modetest command as follows:
> "./modetest -M rcar-du -s 17@11:1024x768@AR24 -d -P '11@32:1024x768@XR24"
> 
> Am I missing something or doing something wrong?

Yes. Or actually yavta is missing something :-) yavta is able to capture from 
a video node to file, or output the contents of a file to a video node, but 
doesn't have the ability to capture from one video node and feed the frames to 
another video node.

That would be an interesting addition to yavta though as it would allow 
exercising the dmabuf code paths, but I wonder whether it would really fit in 
yavta's original purpose as a low-level V4L2 test tool.

Sakari, you're somehow familiar with the code base, what would you think ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Sakari Ailus]

Hi Laurent,

On Sat, Dec 20, 2014 at 09:00:11PM +0200, Laurent Pinchart wrote:
> Hi Devendra,
> 
> On Friday 19 December 2014 05:05:22 Devendra Talegaonkar wrote:
> > Hi,
> > Thanks for the reply. I could successfully stream file data to display via
> > media link. Now on Lager board, I am trying to stream live video data
> > captured from camera ( VIN1 input via ADV7180 decoder, RGB565 )  to
> > display. I am using yavta to capture data from camera and streaming it to
> > rpf.0. But I am not able to see data on VGA. I am using following commands
> > to establish media link ./vsp1.sh media1 m2d ARGB565 ARGB32
> > Then yavta to capture and stream data with following command:
> > "./yavta -c -n 4 -f RGB565 -s 400x200 /dev/video1 /dev/video10" ( video10
> > being associated dev for rpf.0) modetest command as follows:
> > "./modetest -M rcar-du -s 17@11:1024x768@AR24 -d -P '11@32:1024x768@XR24"
> > 
> > Am I missing something or doing something wrong?
> 
> Yes. Or actually yavta is missing something :-) yavta is able to capture from 
> a video node to file, or output the contents of a file to a video node, but 
> doesn't have the ability to capture from one video node and feed the frames to 
> another video node.
> 
> That would be an interesting addition to yavta though as it would allow 
> exercising the dmabuf code paths, but I wonder whether it would really fit in 
> yavta's original purpose as a low-level V4L2 test tool.
> 
> Sakari, you're somehow familiar with the code base, what would you think ?

I propose to implement reading from and writing to a given file handle (or
just stdin/stdout). I don't think we currently have them at the moment, but
it'd fit well for yavta IMHO. This way you could pipe the data from one
yavta instance to another.

This is how I tested m2m devices using yavta; it takes the device file
handle as a parameter (--fd option) instead of opening it.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hi Sakari,

On Saturday 20 December 2014 23:46:00 Sakari Ailus wrote:
> On Sat, Dec 20, 2014 at 09:00:11PM +0200, Laurent Pinchart wrote:
> > On Friday 19 December 2014 05:05:22 Devendra Talegaonkar wrote:
> > > Hi,
> > > Thanks for the reply. I could successfully stream file data to display
> > > via media link. Now on Lager board, I am trying to stream live video
> > > data captured from camera ( VIN1 input via ADV7180 decoder, RGB565 )  to
> > > display. I am using yavta to capture data from camera and streaming it
> > > to rpf.0. But I am not able to see data on VGA. I am using following
> > > commands to establish media link ./vsp1.sh media1 m2d ARGB565 ARGB32
> > > Then yavta to capture and stream data with following command:
> > > "./yavta -c -n 4 -f RGB565 -s 400x200 /dev/video1 /dev/video10" (
> > > video10
> > > being associated dev for rpf.0) modetest command as follows:
> > > "./modetest -M rcar-du -s 17@11:1024x768@AR24 -d -P
> > > '11@32:1024x768@XR24"
> > > 
> > > Am I missing something or doing something wrong?
> > 
> > Yes. Or actually yavta is missing something :-) yavta is able to capture
> > from a video node to file, or output the contents of a file to a video
> > node, but doesn't have the ability to capture from one video node and
> > feed the frames to another video node.
> > 
> > That would be an interesting addition to yavta though as it would allow
> > exercising the dmabuf code paths, but I wonder whether it would really fit
> > in yavta's original purpose as a low-level V4L2 test tool.
> > 
> > Sakari, you're somehow familiar with the code base, what would you think ?
> 
> I propose to implement reading from and writing to a given file handle (or
> just stdin/stdout). I don't think we currently have them at the moment, but
> it'd fit well for yavta IMHO. This way you could pipe the data from one
> yavta instance to another.
> 
> This is how I tested m2m devices using yavta; it takes the device file
> handle as a parameter (--fd option) instead of opening it.

That won't help much here as the goal is to share buffers between two video 
nodes using dmabuf.

Following our private discussion I think one solution would be to pass buffers 
between two yavta instances using unix sockets. Defining a protocol would be 
needed. Oh, and implementing it in yavta of course :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hello,

On Tuesday 03 February 2015 09:41:23 Devendra Talegaonkar wrote:
> Hi Laurent,
> 
> This is altogether a different question & not sure if I am doing sense or
> not.
> 
> I am trying to access drmModeSetCrtc and drmModeSetPlane from 2 different
> processes. The scenario is:
> 
> * Process1 is creating frame buffer for CRTc & for specific plane & by
> calling drmModeSetPlane, overlaying on CRTc
> 
> * Process2 is also creating frame buffer for different plane & trying to
> overlay it on CRTc
>
> In the Process2 drmModeSetPlane is not showing anything on display.
> 
> Is it the desired behavior or I am doing something wrong here.

That doesn't sound like the desired behaviour to me. Note that KMS expects a 
single process to control mode setting. You can get around that by dropping 
master privileges in the first process after setting the CRTC mode, but you 
can't get master privileges back once you've dropped them (short of dropping 
master in the second process and then closing/reopening the device in the 
first process of course).

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Devendra Talegaonkar]

Thanks Laurent for your reply.
The problem we are facing is, we are planning to assign overlay planes to different modules in the system (processes) & depending on the system context we want to decide which overlay plane needs to bring forward and which overlay plane needs to hide. As you suggested in the previous mail,  handling XXSetPlane API would not be a desired option.

Can you please suggest any suitable mechanism for the same?

Thanks & Regards,
Devendra Talegaonkar

________________________________________
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Sent: Wednesday, February 4, 2015 2:50 PM
To: Devendra Talegaonkar
Cc: linux-sh@vger.kernel.org
Subject: Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

Hello,

On Tuesday 03 February 2015 09:41:23 Devendra Talegaonkar wrote:
> Hi Laurent,
>
> This is altogether a different question & not sure if I am doing sense or
> not.
>
> I am trying to access drmModeSetCrtc and drmModeSetPlane from 2 different
> processes. The scenario is:
>
> * Process1 is creating frame buffer for CRTc & for specific plane & by
> calling drmModeSetPlane, overlaying on CRTc
>
> * Process2 is also creating frame buffer for different plane & trying to
> overlay it on CRTc
>
> In the Process2 drmModeSetPlane is not showing anything on display.
>
> Is it the desired behavior or I am doing something wrong here.

That doesn't sound like the desired behaviour to me. Note that KMS expects a
single process to control mode setting. You can get around that by dropping
master privileges in the first process after setting the CRTC mode, but you
can't get master privileges back once you've dropped them (short of dropping
master in the second process and then closing/reopening the device in the
first process of course).

--
Regards,

Laurent Pinchart

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.

Re: [PATCH 0/2] Add VSP1 devices to DT for r8a7790 and r8a7791

[Laurent Pinchart]

Hello Devendra,

On Thursday 05 February 2015 00:28:26 Devendra Talegaonkar wrote:
> Thanks Laurent for your reply.
> The problem we are facing is, we are planning to assign overlay planes to
> different modules in the system (processes) & depending on the system
> context we want to decide which overlay plane needs to bring forward and
> which overlay plane needs to hide. As you suggested in the previous mail, 
> handling XXSetPlane API would not be a desired option.
> 
> Can you please suggest any suitable mechanism for the same?

This is something usually handled by the display server, i.e. X11 or Wayland.

-- 
Regards,

Laurent Pinchart