On 02/12/2013 11:45 PM, St?phane Marchesin wrote:
>> - Do we need to support chaining several encoders ? We can come up with
>> > several theoretical use cases, some of them probably exist in real
>> > hardware,
>> > but the details are still a bit fuzzy.
> So, a part which is completely
On 02/12/2013 11:45 PM, Stéphane Marchesin wrote:
- Do we need to support chaining several encoders ? We can come up with
several theoretical use cases, some of them probably exist in real hardware,
but the details are still a bit fuzzy.
So, a part which is completely omitted in this thread
Den 12 feb 2013 23:02 skrev "Greg KH" :
>
> On Tue, Feb 12, 2013 at 04:04:53PM +0100, Marcus Lorentzon wrote:
> > 3) Daniel V hinted that multiple parents (or multiple busses) is
> > something that has been discussed as a limitation of device driver
> >
On 02/12/2013 04:53 PM, Tomi Valkeinen wrote:
> On 2013-02-12 17:04, Marcus Lorentzon wrote:
>
>> Now we have some different types of panels which are attached on a
>> combination of busses:
>>
>> a) control:DBI, data:DBI
>> b) control:I2C/SPI, data:I2C/SPI
Hi Greg,
at FOSDEM we had a session on CDF (Common Display Framework). You can
read more details about this in the posts from Laurent Pinchart on dridevel:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
Hi Greg,
at FOSDEM we had a session on CDF (Common Display Framework). You can
read more details about this in the posts from Laurent Pinchart on dridevel:
http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html
On 02/12/2013 04:53 PM, Tomi Valkeinen wrote:
On 2013-02-12 17:04, Marcus Lorentzon wrote:
Now we have some different types of panels which are attached on a
combination of busses:
a) control:DBI, data:DBI
b) control:I2C/SPI, data:I2C/SPI
c) control:static setup, data:DPI
d) control:I2C/SPI
On 02/11/2013 09:21 AM, Tomi Valkeinen wrote:
> On 2013-02-08 16:54, Marcus Lorentzon wrote:
>> On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
>>> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>>>
>>>> When we do that we stop->setup->start during blanki
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>
>> When we do that we stop->setup->start during blanking. So our "DSS" is
>> optimized to be able to do that without getting blocked. All DSI video
>> mode panel
On 02/08/2013 02:04 PM, Tomi Valkeinen wrote:
> On 2013-02-08 14:40, Marcus Lorentzon wrote:
>
>> I agree, but I think it should be
>> setup->enable->video_on->video_off->disable->setup->...
>> I don't think there is any interface parameters that
On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
> On 2013-02-04 12:05, Marcus Lorentzon wrote:
>
>> As discussed at FOSDEM I will give DSI bus with full feature set a
>> try.
> Please do, but as a reminder I want to raise the issues I see with a DSI
> bus:
>
> - A dev
On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-02-03 21:17, Tomasz Figa wrote:
>> Hi Laurent,
>>
>> On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
>>> Hi Tomasz,
>>>
>>> Thank you for your RFC.
>>>
>>> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
Hi,
On 2013-02-03 21:17, Tomasz Figa wrote:
Hi Laurent,
On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
Hi Tomasz,
Thank you for your RFC.
On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
Changes done to Tomi's edition
On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
On 2013-02-04 12:05, Marcus Lorentzon wrote:
As discussed at FOSDEM I will give DSI bus with full feature set a
try.
Please do, but as a reminder I want to raise the issues I see with a DSI
bus:
- A device can be a child of only one bus. So
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had
On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
> Hi Marcus,
>
> On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
>> On 01/08/2013 05:36 PM, Tomasz Figa wrote:
>>> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[...]
>>>> But it is not
On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
Hi Marcus,
On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[...]
But it is not perfect. After a couple of products we
On 01/29/2013 04:50 PM, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetter
> wrote:
> Ok, in the interest of pre-heating the discussion a bit I've written down
> my thoughts about display slave drivers. Adding a few more people and
> lists to make sure I haven't missed anyone
On 01/29/2013 04:50 PM, Daniel Vetter wrote:
On Tue, Jan 29, 2013 at 3:19 PM, Daniel Vetterdaniel.vet...@ffwll.ch wrote:
Ok, in the interest of pre-heating the discussion a bit I've written down
my thoughts about display slave drivers. Adding a few more people and
lists to make sure I haven't
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
> On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
>> On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
>>> On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
>>>>> On Monday 24 of December 201
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
> On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
>> > On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
>>> > > On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> > > On Tuesday 18 of December 2012 08:31:30
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
On 01/08/2013 09:18 AM, Laurent Pinchart wrote:
On Thursday 27 December 2012 15:43:34 Tomasz Figa wrote:
On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
On Friday
On 12/18/2012 06:04 AM, Dave Airlie wrote:
>> Many developers showed interest in the first RFC, and I've had the
>> opportunity
>> to discuss it with most of them. I would like to thank (in no particular
>> order) Tomi Valkeinen for all the time he spend helping me
On 12/18/2012 06:04 AM, Dave Airlie wrote:
Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his
On 04/18/2012 06:06 PM, Ville Syrj?l? wrote:
>> > If you smash everything into one ioctl, I imagine you have plenty of fun
>> > implementing all this. Which is why I prefer to split this up.
> I don't think there's that much differnce. You build up the full device
> state, check it, and when
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
> This means that there should be (at least) three separate actions:
> * page flipping: buffers -> planes at next vblank, for a list of
> buffer(s) and plane tuples.
> * setplanes: colour format, position, scaling, ordering, rotation, color
> key, crtc
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>>> Last time around I've discussed with people we've ended up with 2 new
>>> ioctls:
>>>
>>&
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> Last time around I've discussed with people we've ended up with 2 new
> ioctls:
>
> - atomic modeset, to configure the output state on more than one crtc at
>the same time. This is useful to get pll assignement, memory bandwidth
>constrains
On 04/18/2012 04:26 PM, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 02:25 PM, Rob Clark wrote:
>>> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>>> wrote:
>>>> On 04/18/2012 05:46 PM, Da
On 04/18/2012 02:25 PM, Rob Clark wrote:
> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> wrote:
>> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shimjy0922.s...@samsung.com
wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more than one crtc at
the same time. This is useful to get pll assignement, memory bandwidth
constrains and similar
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
This means that there should be (at least) three separate actions:
* page flipping: buffers - planes at next vblank, for a list of
buffer(s) and plane tuples.
* setplanes: colour format, position, scaling, ordering, rotation, color
key, crtc
On 04/18/2012 06:06 PM, Ville Syrjälä wrote:
If you smash everything into one ioctl, I imagine you have plenty of fun
implementing all this. Which is why I prefer to split this up.
I don't think there's that much differnce. You build up the full device
state, check it, and when you're ready
On 03/30/2012 12:37 PM, Ville Syrj?l? wrote:
> On Thu, Mar 29, 2012 at 08:15:48PM -0500, Rob Clark wrote:
>> On Thu, Mar 29, 2012 at 8:02 PM, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> A bitmask property is similar to an enum. The enum value is a bit
>>> position (0-63), and valid property
On 03/30/2012 12:37 PM, Ville Syrjälä wrote:
On Thu, Mar 29, 2012 at 08:15:48PM -0500, Rob Clark wrote:
On Thu, Mar 29, 2012 at 8:02 PM, Rob Clarkrob.cl...@linaro.org wrote:
From: Rob Clarkr...@ti.com
A bitmask property is similar to an enum. The enum value is a bit
position (0-63), and
On 03/30/2012 12:12 PM, Ville Syrjälä wrote:
+#define DRM_FORMAT_NV12MT fourcc_code('T', 'M', '1', '2') /* 2x2
subsampled Cr:Cb plane 64x32 macroblocks */
This one is more difficult. Until now tiling was always handled in
driver specific manner. OTOH if this format is really supported by
Hi Paulo,
thanks for a quick response posting the patches.
In my use of CRTC rotation properties, I need the change to be
synchronized with modeset. Your implementation activate the property
change immediately instead of staging it for next modeset. Do you think
it is ok for different drivers
Hi Paulo,
thanks for a quick response posting the patches.
In my use of CRTC rotation properties, I need the change to be
synchronized with modeset. Your implementation activate the property
change immediately instead of staging it for next modeset. Do you think
it is ok for different drivers
On 03/19/2012 05:56 PM, Alan Cox wrote:
>> display controller will be reading the front buffer, but the GPU
>> > might also need to read that front buffer. So perhaps adding
>> > "read-only"& "read-write" access flags to prepare could also be
>> > interpreted as shared& exclusive accesses, if
On 03/19/2012 05:56 PM, Alan Cox wrote:
display controller will be reading the front buffer, but the GPU
might also need to read that front buffer. So perhaps adding
read-only read-write access flags to prepare could also be
interpreted as shared exclusive accesses, if we went down this
On 03/15/2012 02:32 AM, Rob Clark wrote:
> From: Rob Clark
> [snip]
> In all cases, the mmap() call is allowed to fail, and the associated
> dma_buf_ops are optional (mmap() will fail if at least the mmap()
> op is not implemented by the exporter, but in either case the
> {prepare,finish}_access()
On 03/15/2012 02:32 AM, Rob Clark wrote:
From: Rob Clarkr...@ti.com
[snip]
In all cases, the mmap() call is allowed to fail, and the associated
dma_buf_ops are optional (mmap() will fail if at least the mmap()
op is not implemented by the exporter, but in either case the
On 2 March 2012 15:23, Heiko St?bner wrote:
> Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart:
> [...]
> > For DSI, a possible abstraction level would be a DCS (Display Command
> > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be
> > implemented as DCS drivers.
On 2 March 2012 15:23, Heiko Stübner he...@sntech.de wrote:
Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart:
[...]
For DSI, a possible abstraction level would be a DCS (Display Command
Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be
implemented as DCS
On 06/22/2011 03:09 AM, Rob Clark wrote:
> But I'm at least under the impression that some of the other SoC's
> have similar flexibility to use video planes as either primary or
> overlay layers. So I figure it is at least worth trying to handle
> this in a more generic way if it doesn't cause
On 06/22/2011 03:09 AM, Rob Clark wrote:
But I'm at least under the impression that some of the other SoC's
have similar flexibility to use video planes as either primary or
overlay layers. So I figure it is at least worth trying to handle
this in a more generic way if it doesn't cause too much
On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> This version adds both source and dest rect params to the set_plane
> ioctl, and makes the source fixed point to support hardware that needs
> it.
>
> I haven't changed the name of the SNB implementation yet (per Chris's
> suggestions) but will before
On 06/20/2011 10:11 PM, Jesse Barnes wrote:
This version adds both source and dest rect params to the set_plane
ioctl, and makes the source fixed point to support hardware that needs
it.
I haven't changed the name of the SNB implementation yet (per Chris's
suggestions) but will before it gets
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
> On Wed, 8 Jun 2011 11:41:17 +0200
> Marcus Lorentzon wrote:
>
>
>> On 06/07/2011 11:01 PM, Jesse Barnes wrote:
>>
>>> On Tue, 7 Jun 2011 13:07:39 -0700
>>> Jesse Barnes wrote:
>>>
>
On 06/08/2011 08:54 PM, Jesse Barnes wrote:
On Wed, 8 Jun 2011 11:41:17 +0200
Marcus Lorentzonmarcus.xm.lorent...@stericsson.com wrote:
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnesjbar...@virtuousgeek.org wrote:
+/* Planes
On 06/07/2011 11:01 PM, Jesse Barnes wrote:
> On Tue, 7 Jun 2011 13:07:39 -0700
> Jesse Barnes wrote:
>
>
>> +/* Planes blend with or override other bits on the CRTC */
>> +struct drm_mode_set_plane {
>> +__u32 plane_id;
>> +__u32 crtc_id;
>> +__u32 fb_id; /* contains surface
On 03/12/2011 04:59 PM, Rob Clark wrote:
> On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetter wrote:
>
>> On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
>>
>>> This doesn't seem that different from the graphics chips we support
>>> with kms. I don't think it would require
On 03/12/2011 04:59 PM, Rob Clark wrote:
On Sun, Dec 5, 2010 at 5:28 AM, Daniel Vetterdan...@ffwll.ch wrote:
On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote:
This doesn't seem that different from the graphics chips we support
with kms. I don't think it would require
On 12/17/2010 12:22 PM, Arnd Bergmann wrote:
>>> * When I talk about a bus, I mean 'struct bus_type', which identifies
>>> all devices with a uniform bus interface to their parent device
>>> (think: PCI, USB, I2C). You seem to think of a bus as a specific
>>> instance of that bus type,
On 12/17/2010 12:22 PM, Arnd Bergmann wrote:
* When I talk about a bus, I mean 'struct bus_type', which identifies
all devices with a uniform bus interface to their parent device
(think: PCI, USB, I2C). You seem to think of a bus as a specific
instance of that bus type, i.e. the
On 11/26/2010 12:24 PM, Arnd Bergmann wrote:
> [dri people: please have a look at the KMS discussion way below]
>
> On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote:
>
>>> -Original Message-
>>> From: Arnd Bergmann [mailto:arnd at arndb.de]
>
On 11/26/2010 12:24 PM, Arnd Bergmann wrote:
[dri people: please have a look at the KMS discussion way below]
On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote:
-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: den 25 november 2010 17:48
To: Marcus
60 matches
Mail list logo
