2014-03-19 6:23 GMT+09:00 Dave Airlie :
> On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter wrote:
>> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
>>> >> I think now drm_bridge couldn't
2014-03-19 13:07 GMT+09:00 Inki Dae :
> 2014-03-19 2:37 GMT+09:00 Daniel Vetter :
>> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
>>> >> I think now drm_bridge couldn't do what we wan
2014-03-19 2:37 GMT+09:00 Daniel Vetter :
> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
>> >> I think now drm_bridge couldn't do what we want for embedded systems
>> >> as long as drm_
Hi,
I have already proposed to reuse drm_panel infrastructure to
implement bridges in my RFC [1] and I have implemented DSI/LVDS bridge
in this way [2]. I guess this discussion is a result of my discussion
with Inki in thread [1]. More comments below.
[1]: http://permalink.gmane.org/gmane.linux.k
On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
>> >> I think now drm_bridge couldn't do what we want for embedded systems
>> >> as
2014-03-18 22:29 GMT+09:00 Rob Clark :
> On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae wrote:
>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>>> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
I think now drm_bridge couldn't do what we want for embedded systems
as long as drm_encoder has dr
2014-03-18 21:47 GMT+09:00 Daniel Vetter :
> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
>> I think now drm_bridge couldn't do what we want for embedded systems
>> as long as drm_encoder has drm_bridge.
>> See the blow hardware pipeline,
>> Display Controller-Image Enhancement chip-MI
2014-03-18 21:22 GMT+09:00 Daniel Vetter :
> On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark wrote:
>> I think the question is how to go from zero or one
>> bridge/hwblock/widget/whatever to zero or more..
>>
>> an alternate set of helpers is one option. But it didn't turn out to
>> be too intrusive t
Thanks for comments,
2014-03-18 19:27 GMT+09:00 Daniel Vetter :
> On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote:
>> Hello all,
>>
>> The purpose of this email is for discussion to how we could support
>> various hardware blocks such as LVDS bridges, Image Enhancement chips
>> and parall
On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote:
> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
> > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
> >> I think now drm_bridge couldn't do what we want for embedded systems
> >> as long as drm_encoder has drm_bridge.
> >> See the blow hardwa
Hello all,
The purpose of this email is for discussion to how we could support
various hardware blocks such as LVDS bridges, Image Enhancement chips
and parallel panels in drm driver.
Now we have drm_panel framework for controlling parallel panels, and
drm_bridge for controlling LVDS bridge devic
On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
> I think now drm_bridge couldn't do what we want for embedded systems
> as long as drm_encoder has drm_bridge.
> See the blow hardware pipeline,
> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
> LVDS Bridge-LCD Panel
>
>
On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark wrote:
> I think the question is how to go from zero or one
> bridge/hwblock/widget/whatever to zero or more..
>
> an alternate set of helpers is one option. But it didn't turn out to
> be too intrusive to the existing helpers to add bridge in the first
On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark wrote:
>> What's the difference here compared to an encoder_slave? I don't really
>> see the point of adding yet another such thing to the drm core ...
>
> so I think at one point the rough idea was to add additional fxn ptrs
> to bridge as the need arose
On Tue, Mar 18, 2014 at 11:22 AM, Inki Dae wrote:
> 2014-03-18 22:29 GMT+09:00 Rob Clark :
>> On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae wrote:
>>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
> I think now drm_bridge couldn't do what we wan
On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote:
> Hello all,
>
> The purpose of this email is for discussion to how we could support
> various hardware blocks such as LVDS bridges, Image Enhancement chips
> and parallel panels in drm driver.
>
> Now we have drm_panel framework for contr
On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae wrote:
> 2014-03-18 21:47 GMT+09:00 Daniel Vetter :
>> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote:
>>> I think now drm_bridge couldn't do what we want for embedded systems
>>> as long as drm_encoder has drm_bridge.
>>> See the blow hardware pipeline,
On Tue, Mar 18, 2014 at 4:26 AM, Inki Dae wrote:
>
> enum {
> DRM_HW_BLOCK_PANEL,
> DRM_HW_BLOCK_BRIDGE,
> DRM_HW_BLOCK_ENHANCE,
> };
>
> struct drm_hw_block {
> unsigned int type;
> struct device *dev;
just fyi, drop the 'struct device' ptr.. that sort of
On Tue, Mar 18, 2014 at 6:27 AM, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote:
>> Hello all,
>>
>> The purpose of this email is for discussion to how we could support
>> various hardware blocks such as LVDS bridges, Image Enhancement chips
>> and parallel panels
19 matches
Mail list logo
