On 10/17/2013 02:55 PM, Tomi Valkeinen wrote:
> On 17/10/13 15:26, Andrzej Hajda wrote:
>
>> I am not sure what exactly the encoder performs, if this is only image
>> transport from dispc to panel CDF pipeline in both cases should look like:
>> dispc > panel
>> The only difference is that panel
On 17/10/13 15:26, Andrzej Hajda wrote:
> I am not sure what exactly the encoder performs, if this is only image
> transport from dispc to panel CDF pipeline in both cases should look like:
> dispc > panel
> The only difference is that panels will be connected via different Linux bus
> adapter
On 10/17/2013 10:18 AM, Tomi Valkeinen wrote:
> On 17/10/13 10:48, Andrzej Hajda wrote:
>
>> The main function of DSI is to transport pixels from one IP to another IP
>> and this function IMO should not be modeled by display entity.
>> "Power, clocks, etc" will be performed via control bus accordin
On 17/10/13 10:48, Andrzej Hajda wrote:
> The main function of DSI is to transport pixels from one IP to another IP
> and this function IMO should not be modeled by display entity.
> "Power, clocks, etc" will be performed via control bus according to
> panel demands.
> If 'DSI chip' has additional
Hi Tomi,
Sorry for delayed response.
On 10/11/2013 04:45 PM, Tomi Valkeinen wrote:
> On 11/10/13 17:16, Andrzej Hajda wrote:
>
>> Picture size, content and format is the same on input and on output of DSI.
>> The same bits which enters DSI appears on the output. Internally bits
>> order can
>> b
On 11/10/13 17:16, Andrzej Hajda wrote:
> Picture size, content and format is the same on input and on output of DSI.
> The same bits which enters DSI appears on the output. Internally bits
> order can
> be different but practically you are configuring DSI master and slave
> with the same format.
On 10/11/2013 02:30 PM, Tomi Valkeinen wrote:
> On 11/10/13 14:19, Andrzej Hajda wrote:
>> On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
>>> The minimum bta-timeout should be deducable from the DSI bus speed,
>>> shouldn't it? Thus there's no need to define it anywhere.
>> Hmm, specification says "
On 11/10/13 14:19, Andrzej Hajda wrote:
> On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
>> The minimum bta-timeout should be deducable from the DSI bus speed,
>> shouldn't it? Thus there's no need to define it anywhere.
> Hmm, specification says "This specified period shall be longer then
> the ma
On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
> On 09/10/13 17:08, Andrzej Hajda wrote:
>
>> As I have adopted existing internal driver for MIPI-DSI bus, I did not
>> take too much
>> care for DT. You are right, 'bta-timeout' is a configuration parameter
>> (however its
>> minimal value is determin
On 09/10/13 17:08, Andrzej Hajda wrote:
> As I have adopted existing internal driver for MIPI-DSI bus, I did not
> take too much
> care for DT. You are right, 'bta-timeout' is a configuration parameter
> (however its
> minimal value is determined by characteristic of the DSI-slave). On the
> other
On 10/02/2013 03:24 PM, Tomi Valkeinen wrote:
> Hi Andrzej,
>
> On 02/10/13 15:23, Andrzej Hajda wrote:
>
>>> Using Linux buses for DBI/DSI
>>> =
>>>
>>> I still don't see how it would work. I've covered this multiple times in
>>> previous posts so I'm not going into mor
Hi Andrzej,
On 02/10/13 15:23, Andrzej Hajda wrote:
>> Using Linux buses for DBI/DSI
>> =
>>
>> I still don't see how it would work. I've covered this multiple times in
>> previous posts so I'm not going into more details now.
>>
>> I implemented DSI (just command mode
Hi Tomi,
On 09/30/2013 03:48 PM, Tomi Valkeinen wrote:
> On 09/08/13 20:14, Laurent Pinchart wrote:
>> Hi everybody,
>>
>> Here's the third RFC of the Common Display Framework.
>
>
> Hi,
>
> I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
> some notes here about what
On 09/08/13 20:14, Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the third RFC of the Common Display Framework.
Hi,
I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
some notes here about what I've discovered or how I see things. Some of these I
have mentioned ear
On 21/08/13 15:22, Rob Clark wrote:
> And just to be clear, part of my negative experience about this is the
> omapdss/omapdrm split. I just see cfd outside of drm as encouraging
> others to make the same mistake.
Feel free to disagree, but I think the omapdss/omapdrm split is a bit
different ma
On 09/09/13 17:17, Rob Clark wrote:
> On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen wrote:
>> On 21/08/13 15:22, Rob Clark wrote:
>>
>>> And just to be clear, part of my negative experience about this is the
>>> omapdss/omapdrm split. I just see cfd outside of drm as encouraging
>>> others to ma
On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen wrote:
> On 21/08/13 15:22, Rob Clark wrote:
>
>> And just to be clear, part of my negative experience about this is the
>> omapdss/omapdrm split. I just see cfd outside of drm as encouraging
>> others to make the same mistake.
>
> Feel free to disag
On Mon, Sep 9, 2013 at 10:58 AM, Tomi Valkeinen wrote:
> On 09/09/13 17:17, Rob Clark wrote:
>> On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen wrote:
>>> On 21/08/13 15:22, Rob Clark wrote:
>>>
And just to be clear, part of my negative experience about this is the
omapdss/omapdrm split.
Hi Rob and Sascha,
On Wednesday 21 August 2013 08:22:59 Rob Clark wrote:
> On Wed, Aug 21, 2013 at 3:09 AM, Sascha Hauer wrote:
> > On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
> >> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart wrote:
> >> > Hi Rob,
> >> >
> >> >> Or maybe, put
On 09/08/13 20:14, Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the third RFC of the Common Display Framework.
>
> I won't repeat all the background information from the versions one and two
> here, you can read it at http://lwn.net/Articles/512363/ and
> http://lwn.net/Articles/526965/.
>
On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
> wrote:
> > Hi Rob,
> >
> >> Or maybe, put another way, I still think we should still optimize for the
> >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP
> >> b
On Wed, Aug 21, 2013 at 3:09 AM, Sascha Hauer wrote:
> On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
>> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
>> wrote:
>> > Hi Rob,
>> >
>> >> Or maybe, put another way, I still think we should still optimize for the
>> >> common case. I
On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
> wrote:
> > Hi Rob,
> >
> >> Or maybe, put another way, I still think we should still optimize for the
> >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP
> >> b
On Wed, Aug 21, 2013 at 3:09 AM, Sascha Hauer wrote:
> On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote:
>> On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
>> wrote:
>> > Hi Rob,
>> >
>> >> Or maybe, put another way, I still think we should still optimize for the
>> >> common case. I
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
>> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
>> > Hi everybody,
>> >
>> > Here's the third RFC of the Common Display Framework.
>> >
>> > I won't repeat all the
Hi Rob,
On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Here's the third RFC of the Common Display Framework.
> >
> > I won't repeat all the background information from the versions one and
> > two here, you
Hi Rob,
On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Here's the third RFC of the Common Display Framework.
> >
> > I won't repeat all the background information from the versions one and
> > two here, you
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 13 August 2013 20:43:50 Rob Clark wrote:
>> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
>> > Hi everybody,
>> >
>> > Here's the third RFC of the Common Display Framework.
>> >
>> > I won't repeat all the
On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> Here's the third RFC of the Common Display Framework.
>
> I won't repeat all the background information from the versions one and two
> here, you can read it at http://lwn.net/Articles/512363/ and
> http://lwn.net/Articles
On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> Here's the third RFC of the Common Display Framework.
>
> I won't repeat all the background information from the versions one and two
> here, you can read it at http://lwn.net/Articles/512363/ and
> http://lwn.net/Articles
Hi everybody,
Here's the third RFC of the Common Display Framework.
I won't repeat all the background information from the versions one and two
here, you can read it at http://lwn.net/Articles/512363/ and
http://lwn.net/Articles/526965/.
This RFC isn't final. Given the high interest in CDF and t
Hi everybody,
Here's the third RFC of the Common Display Framework. This is a resent, the
series I've sent earlier seems not to have made it to the vger mailing lists,
possibly due to a too long list of CCs (the other explanation being that CDF
has been delayed for so long that vger considers it a
Hi everybody,
Here's the third RFC of the Common Display Framework.
I won't repeat all the background information from the versions one and two
here, you can read it at http://lwn.net/Articles/512363/ and
http://lwn.net/Articles/526965/.
This RFC isn't final. Given the high interest in CDF and t
Hi everybody,
Here's the third RFC of the Common Display Framework. This is a resent, the
series I've sent earlier seems not to have made it to the vger mailing lists,
possibly due to a too long list of CCs (the other explanation being that CDF
has been delayed for so long that vger considers it a
34 matches
Mail list logo
