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
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
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
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]:
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
>> >>
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
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
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
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
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
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
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
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
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
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
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
