How to support various hardware blocks in drm driver
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 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 >>> >> >>> >> In above hardware pipeline, Display controller is controlled by crtc, >>> >> and Image Enhancement chip receives output from display controller. >>> >> So the use of existing drm_bridge would be suitable to only bridge >>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement >>> >> chip. >>> >> >>> >> For such hardware, drm_panel infrastructure is more reasonable to me, >>> >> and that is why I try to integrate drm_panel and drm_bridge to one >>> >> integrated framework which has infrastructure same as existing >>> >> drm_panel. >>> >> The important thing is to free this integrated framework from >>> >> drm_encoder so that crtc device can also use this framework. >>> > >>> > Hm, what is this image enhancement chip? Is that some IP block on the >>> > SoC? Is it optional? Can it be attached to different crtcs? >>> >>> In case of Exynos, this chip is in SoC, and can be only attached to >>> one crtc, display controller. But I'm not sure other SoC have similar >>> chip. >>> >>> > >>> > I think we have similar things on intel hardware, but without details >>> > on what it does and how it works I can't really say how to best expose >>> > it to userspace and how to best handle it internally in the driver. >>> > -Daniel >>> >>> Simply saying, the image enhancement chip can enhance image data from >>> display controller, i.e. saturation enhancement, color reproduction, >>> dithering, and so on. >>> And this chip receives image data through hardware wired lines >>> connected internally between display controller and this chip. >> >> To me this sounds like you simply need to expose all these capabilities to >> userspace as crtc properties. Which addresses one part of this issue. >> >> The other side is how you are going to track this in the driver, and there >> you can do whatever you want - just add a pointer/structure to the exynos >> crtc structure for the display enhancement block. >> >> The MIPI DSI block would then be treated as a drm_encoder, and all the >> later stages as drm_bridges up to the very last (the actual lvds panel) >> which would be a simple drm_panel. >> >> I don't really see what additional complexity you need here. Especially >> since this image enhancer is on your SoC (and I guess a samgsung IP block >> not shared with any other SoC manufacture) you can easily keep the driver >> code for it in the exynos driver. So really no need to have a generic >> interface here. > > I'm with Daniel, this does sound like its just part of the "crtc" > object, just write code in the driver > to support it and tie it into the crtc. > That is really what I try to do just using generic framework, the integrated drm_bridge framework. We have really been using drm_panel, drm_bridge and maybe encoder_slave for this. But they are not perfect yet so I am trying to enhance these frameworks. Thanks, Inki Dae > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to support various hardware blocks in drm driver
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 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
>>> >>
>>> >> In above hardware pipeline, Display controller is controlled by crtc,
>>> >> and Image Enhancement chip receives output from display controller.
>>> >> So the use of existing drm_bridge would be suitable to only bridge
>>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
>>> >> chip.
>>> >>
>>> >> For such hardware, drm_panel infrastructure is more reasonable to me,
>>> >> and that is why I try to integrate drm_panel and drm_bridge to one
>>> >> integrated framework which has infrastructure same as existing
>>> >> drm_panel.
>>> >> The important thing is to free this integrated framework from
>>> >> drm_encoder so that crtc device can also use this framework.
>>> >
>>> > Hm, what is this image enhancement chip? Is that some IP block on the
>>> > SoC? Is it optional? Can it be attached to different crtcs?
>>>
>>> In case of Exynos, this chip is in SoC, and can be only attached to
>>> one crtc, display controller. But I'm not sure other SoC have similar
>>> chip.
>>>
>>> >
>>> > I think we have similar things on intel hardware, but without details
>>> > on what it does and how it works I can't really say how to best expose
>>> > it to userspace and how to best handle it internally in the driver.
>>> > -Daniel
>>>
>>> Simply saying, the image enhancement chip can enhance image data from
>>> display controller, i.e. saturation enhancement, color reproduction,
>>> dithering, and so on.
>>> And this chip receives image data through hardware wired lines
>>> connected internally between display controller and this chip.
>>
>> To me this sounds like you simply need to expose all these capabilities to
>> userspace as crtc properties. Which addresses one part of this issue.
>
> No, what I want is really not to expose some capabilities to
> suerspace. If you think so, there might be your missing point.
>
>>
>> The other side is how you are going to track this in the driver, and there
>> you can do whatever you want - just add a pointer/structure to the exynos
>> crtc structure for the display enhancement block.
>
> Hm.. that is what I try to do extending existing drm_panel and
> drm_bridge frameworks. As you may know, now existing drm_bridge could
> support only bridge device of encoder side.
> So now I am trying for this drm_bridge can support both sides of crtc
> and encoder.
>
>>
>> The MIPI DSI block would then be treated as a drm_encoder, and all the
>> later stages as drm_bridges up to the very last (the actual lvds panel)
>> which would be a simple drm_panel.
>>
>
> Existing drm_panel only supports real panel device, and existing
> drm_bridge only supports bridge device between encoder and panel.
> In here, the problem is that there can be other bridge devices between
> crtc and encoder. So crtc driver would want to control such bridge
> device in timely manner.
> How the crtc driver could control this bridge between crtc and encoder?
>
> See the below a example that is what I try to do for this,
>
> struct drm_bridge { <- just change name from drm_hw_block to drm_bridge
> ...
> struct drm_panel *panel;<- existing drm_panel
> struct drm_lvds *lvds;<- existing drm_bridge
> struct drm_enhancer *enhander; < - new one
> ...
> };
>
> Or,
>
> struct drm_panel {<- existing drm_panel
>...
> };
>
> No change for drm_panel.
>
> struct drm_bridge {
> ...
> struct drm_lvds *lvds; <- existing drm_bridge
> struct drm_enhancer *enhancer; <- new one
> };
>
> My idea is to extend existing drm_bridge so that this drm_bridge could
> support both of them, one between crtc and encoder, and another one
> between encoder and panel.
>
> Display controller - bridge1 - mipi dsi - bridge2 - panel
> /|\
> /|\/|\
>|
>| |
> drm_enhancer drm_lvds
> drm_panel
>
Oops, sorry for broken diagram.
bridge1 -> drm_enhancer
bridge2 -> drm_lvds
panel -> drm_panel
> And now is just ready for supporting such bridge later. So this
> integrated drm_bridge would have drm_panel and drm_lvds. For Image
> Enhancer, later.
>
>> I don't really see what additional complexity you need here. Especially
>> since this image enhancer is on your SoC (and I guess a samgsung IP block
>> not shared with any other SoC
How to support various hardware blocks in drm driver
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_encoder has drm_bridge.
>> >> See the blow hardware pipeline,
>> >> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>> >> LVDS Bridge-LCD Panel
>> >>
>> >> In above hardware pipeline, Display controller is controlled by crtc,
>> >> and Image Enhancement chip receives output from display controller.
>> >> So the use of existing drm_bridge would be suitable to only bridge
>> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement
>> >> chip.
>> >>
>> >> For such hardware, drm_panel infrastructure is more reasonable to me,
>> >> and that is why I try to integrate drm_panel and drm_bridge to one
>> >> integrated framework which has infrastructure same as existing
>> >> drm_panel.
>> >> The important thing is to free this integrated framework from
>> >> drm_encoder so that crtc device can also use this framework.
>> >
>> > Hm, what is this image enhancement chip? Is that some IP block on the
>> > SoC? Is it optional? Can it be attached to different crtcs?
>>
>> In case of Exynos, this chip is in SoC, and can be only attached to
>> one crtc, display controller. But I'm not sure other SoC have similar
>> chip.
>>
>> >
>> > I think we have similar things on intel hardware, but without details
>> > on what it does and how it works I can't really say how to best expose
>> > it to userspace and how to best handle it internally in the driver.
>> > -Daniel
>>
>> Simply saying, the image enhancement chip can enhance image data from
>> display controller, i.e. saturation enhancement, color reproduction,
>> dithering, and so on.
>> And this chip receives image data through hardware wired lines
>> connected internally between display controller and this chip.
>
> To me this sounds like you simply need to expose all these capabilities to
> userspace as crtc properties. Which addresses one part of this issue.
No, what I want is really not to expose some capabilities to
suerspace. If you think so, there might be your missing point.
>
> The other side is how you are going to track this in the driver, and there
> you can do whatever you want - just add a pointer/structure to the exynos
> crtc structure for the display enhancement block.
Hm.. that is what I try to do extending existing drm_panel and
drm_bridge frameworks. As you may know, now existing drm_bridge could
support only bridge device of encoder side.
So now I am trying for this drm_bridge can support both sides of crtc
and encoder.
>
> The MIPI DSI block would then be treated as a drm_encoder, and all the
> later stages as drm_bridges up to the very last (the actual lvds panel)
> which would be a simple drm_panel.
>
Existing drm_panel only supports real panel device, and existing
drm_bridge only supports bridge device between encoder and panel.
In here, the problem is that there can be other bridge devices between
crtc and encoder. So crtc driver would want to control such bridge
device in timely manner.
How the crtc driver could control this bridge between crtc and encoder?
See the below a example that is what I try to do for this,
struct drm_bridge { <- just change name from drm_hw_block to drm_bridge
...
struct drm_panel *panel;<- existing drm_panel
struct drm_lvds *lvds;<- existing drm_bridge
struct drm_enhancer *enhander; < - new one
...
};
Or,
struct drm_panel {<- existing drm_panel
...
};
No change for drm_panel.
struct drm_bridge {
...
struct drm_lvds *lvds; <- existing drm_bridge
struct drm_enhancer *enhancer; <- new one
};
My idea is to extend existing drm_bridge so that this drm_bridge could
support both of them, one between crtc and encoder, and another one
between encoder and panel.
Display controller - bridge - mipi dsi - bridge - panel
/|\
/|\/|\
|
| |
drm_enhancer drm_lvds
drm_panel
And now is just ready for supporting such bridge later. So this
integrated drm_bridge would have drm_panel and drm_lvds. For Image
Enhancer, later.
> I don't really see what additional complexity you need here. Especially
> since this image enhancer is on your SoC (and I guess a samgsung IP block
> not shared with any other SoC manufacture) you can easily keep the driver
> code for it in the exynos driver. So really no need to have a generic
> interface here.
Yes, that might be the point. As I already mentioned, I'm not sure
this device exists only on Exynos SoC. But I guess there could be
other SoC with image enhancer now or later.
To other
How to support various hardware blocks in drm driver
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.kernel.samsung-soc/27044 [2]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 On 03/18/2014 06:37 PM, 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 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 In above hardware pipeline, Display controller is controlled by crtc, and Image Enhancement chip receives output from display controller. So the use of existing drm_bridge would be suitable to only bridge devices between MIPI DSI and LCD Panel, but not to Image Enhancement chip. For such hardware, drm_panel infrastructure is more reasonable to me, and that is why I try to integrate drm_panel and drm_bridge to one integrated framework which has infrastructure same as existing drm_panel. The important thing is to free this integrated framework from drm_encoder so that crtc device can also use this framework. >>> >>> Hm, what is this image enhancement chip? Is that some IP block on the >>> SoC? Is it optional? Can it be attached to different crtcs? >> >> In case of Exynos, this chip is in SoC, and can be only attached to >> one crtc, display controller. But I'm not sure other SoC have similar >> chip. >> >>> >>> I think we have similar things on intel hardware, but without details >>> on what it does and how it works I can't really say how to best expose >>> it to userspace and how to best handle it internally in the driver. >>> -Daniel >> >> Simply saying, the image enhancement chip can enhance image data from >> display controller, i.e. saturation enhancement, color reproduction, >> dithering, and so on. >> And this chip receives image data through hardware wired lines >> connected internally between display controller and this chip. > > To me this sounds like you simply need to expose all these capabilities to > userspace as crtc properties. Which addresses one part of this issue. > > The other side is how you are going to track this in the driver, and there > you can do whatever you want - just add a pointer/structure to the exynos > crtc structure for the display enhancement block. > > The MIPI DSI block would then be treated as a drm_encoder, and all the > later stages as drm_bridges up to the very last (the actual lvds panel) > which would be a simple drm_panel. > > I don't really see what additional complexity you need here. Especially > since this image enhancer is on your SoC (and I guess a samgsung IP block > not shared with any other SoC manufacture) you can easily keep the driver > code for it in the exynos driver. So really no need to have a generic > interface here. > -Daniel > But what you proposes is complex. Blocks will be implemented as: 1. drm_encoder, 2. drm_bridge, 3. drm_panel, 4. another 'framework' to implement image enhancers, which are after crtc. But these blocks are just 'video consumers' which can be implemented using drm_panel framework and 'video producers' (except real panels) which can be implemented as drm_panel clients. Of course drm_panel should be renamed to sth like drm_video_input and its ops should be extended. Anyway instead of 4 or more different frameworks we will have only one framework. In general I think it would be better to model just device interfaces instead of modeling whole devices. Btw this approach will allow to model such monsters as TC358710XBG hub [3]. [3]: http://www.toshiba-components.com/prpdf/5992e.pdf Regards Andrzej
How to support various hardware blocks in drm driver
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 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 >> >> >> >> In above hardware pipeline, Display controller is controlled by crtc, >> >> and Image Enhancement chip receives output from display controller. >> >> So the use of existing drm_bridge would be suitable to only bridge >> >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement >> >> chip. >> >> >> >> For such hardware, drm_panel infrastructure is more reasonable to me, >> >> and that is why I try to integrate drm_panel and drm_bridge to one >> >> integrated framework which has infrastructure same as existing >> >> drm_panel. >> >> The important thing is to free this integrated framework from >> >> drm_encoder so that crtc device can also use this framework. >> > >> > Hm, what is this image enhancement chip? Is that some IP block on the >> > SoC? Is it optional? Can it be attached to different crtcs? >> >> In case of Exynos, this chip is in SoC, and can be only attached to >> one crtc, display controller. But I'm not sure other SoC have similar >> chip. >> >> > >> > I think we have similar things on intel hardware, but without details >> > on what it does and how it works I can't really say how to best expose >> > it to userspace and how to best handle it internally in the driver. >> > -Daniel >> >> Simply saying, the image enhancement chip can enhance image data from >> display controller, i.e. saturation enhancement, color reproduction, >> dithering, and so on. >> And this chip receives image data through hardware wired lines >> connected internally between display controller and this chip. > > To me this sounds like you simply need to expose all these capabilities to > userspace as crtc properties. Which addresses one part of this issue. > > The other side is how you are going to track this in the driver, and there > you can do whatever you want - just add a pointer/structure to the exynos > crtc structure for the display enhancement block. > > The MIPI DSI block would then be treated as a drm_encoder, and all the > later stages as drm_bridges up to the very last (the actual lvds panel) > which would be a simple drm_panel. > > I don't really see what additional complexity you need here. Especially > since this image enhancer is on your SoC (and I guess a samgsung IP block > not shared with any other SoC manufacture) you can easily keep the driver > code for it in the exynos driver. So really no need to have a generic > interface here. I'm with Daniel, this does sound like its just part of the "crtc" object, just write code in the driver to support it and tie it into the crtc. Dave.
How to support various hardware blocks in drm driver
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 drm_bridge. See the blow hardware pipeline, Display Controller-Image Enhancement chip-MIP DSI-MIPI TO LVDS Bridge-LCD Panel In above hardware pipeline, Display controller is controlled by crtc, and Image Enhancement chip receives output from display controller. So the use of existing drm_bridge would be suitable to only bridge devices between MIPI DSI and LCD Panel, but not to Image Enhancement chip. For such hardware, drm_panel infrastructure is more reasonable to me, and that is why I try to integrate drm_panel and drm_bridge to one integrated framework which has infrastructure same as existing drm_panel. The important thing is to free this integrated framework from drm_encoder so that crtc device can also use this framework. >>> >>> Hm, what is this image enhancement chip? Is that some IP block on the >>> SoC? Is it optional? Can it be attached to different crtcs? >> >> In case of Exynos, this chip is in SoC, and can be only attached to >> one crtc, display controller. But I'm not sure other SoC have similar >> chip. >> >>> >>> I think we have similar things on intel hardware, but without details >>> on what it does and how it works I can't really say how to best expose >>> it to userspace and how to best handle it internally in the driver. >>> -Daniel >> >> Simply saying, the image enhancement chip can enhance image data from >> display controller, i.e. saturation enhancement, color reproduction, >> dithering, and so on. >> And this chip receives image data through hardware wired lines >> connected internally between display controller and this chip. > > I suppose in some sense it doesn't really matter if it is internal > block or external chip.. > > but I'm still a bit confused about why you think drm_panel is a better > fit.. could you explain that part? > As I already mentioned, see the below hardware pipeline, Display Controller-Image Enhancement chip-MIPI DSI-MIPI TO LVDS Bridge-LCD Panel In above pipeline, the only place drm_bridge can exist is in MIPI DSI driver because drm_encoder and drm_connector should be implemented in MIPI DSI driver like we did using super node, at least in case of exynos - it seems that this way is reasonable to me according to super device and video-interface document. However, there could be Image Enhancement chip between display controller and MIPI DSI, and that means we need other thing for controlling this chip because existing drm_bridge cannot be used for this. In the other hands, drm_panel infrastructure could be used by all device types, crtc or encoder/connector because drm_panel could belong to any device types. So I thought it'd better to use existing framework with a little change than using new one, and we could integrate these two frameworks, drm_bridge and drm_panel to one framework. I am planning to integrate them to one framework, and remove existing drm_bridge. As a result, it would exist only one integrated drm_bridge. Is there any way that can control such chip using existing drm_bridge contained in drm_encoder? if other better way, please give me your idea. Thanks, Inki Dae > BR, > -R > >> Thanks, >> Inki Dae >> >>> -- >>> Daniel Vetter >>> Software Engineer, Intel Corporation >>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to support various hardware blocks in drm driver
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-MIP DSI-MIPI TO >> LVDS Bridge-LCD Panel >> >> In above hardware pipeline, Display controller is controlled by crtc, >> and Image Enhancement chip receives output from display controller. >> So the use of existing drm_bridge would be suitable to only bridge >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement >> chip. >> >> For such hardware, drm_panel infrastructure is more reasonable to me, >> and that is why I try to integrate drm_panel and drm_bridge to one >> integrated framework which has infrastructure same as existing >> drm_panel. >> The important thing is to free this integrated framework from >> drm_encoder so that crtc device can also use this framework. > > Hm, what is this image enhancement chip? Is that some IP block on the > SoC? Is it optional? Can it be attached to different crtcs? In case of Exynos, this chip is in SoC, and can be only attached to one crtc, display controller. But I'm not sure other SoC have similar chip. > > I think we have similar things on intel hardware, but without details > on what it does and how it works I can't really say how to best expose > it to userspace and how to best handle it internally in the driver. > -Daniel Simply saying, the image enhancement chip can enhance image data from display controller, i.e. saturation enhancement, color reproduction, dithering, and so on. And this chip receives image data through hardware wired lines connected internally between display controller and this chip. Thanks, Inki Dae > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to support various hardware blocks in drm driver
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 to the existing helpers to add bridge in the first >> place, so I'm not sure it will be necessary. > > I guess we could allow bridges to chain up and have multiple > child-bridges or something like that. Plus a helper which finds a > suitable routing through this network (it should be a tree after all, > so no ambiguity) given a drm_connector/drm_encoder pair. Or maybe I > misunderstand what you mean by going from 1 bridge to multiple bridges > ... Daniel, 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 In above hardware pipeline, Display controller is controlled by crtc, and Image Enhancement chip receives output from display controller. So the use of existing drm_bridge would be suitable to only bridge devices between MIPI DSI and LCD Panel, but not to Image Enhancement chip. For such hardware, drm_panel infrastructure is more reasonable to me, and that is why I try to integrate drm_panel and drm_bridge to one integrated framework which has infrastructure same as existing drm_panel. The important thing is to free this integrated framework from drm_encoder so that crtc device can also use this framework. Thanks, Inki Dae > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to support various hardware blocks in drm driver
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 parallel panels in drm driver.
>>
>> Now we have drm_panel framework for controlling parallel panels, and
>> drm_bridge for controlling LVDS bridge devices.
>> However, drm_panel has only some callbacks, enable, disable and
>> get_modes, and drm_bridge has some callbacks only for bridge devices
>> so these seems like only for their devices.
>>
>> However, some SoC could have other type of hardware blocks. i.e. Image
>> Enhancement blocks.
>> So it seems that these frameworks don't cover all hardware blocks that
>> can be placed between Display controller and LCD Panel device.
>>
>> Below shows various hardware pipe lines for Exynos SoC,
>>
>> Display Controller-LCD Panel
>> Display Controller-LVDS Bridge-LCD Panel
>> Display Controller-MIP DSI-MIPI TO LVDS Bridge-LCD Panel
>> Display Controller-Image Enhancement chip-LCD Panel
>> Display Controller-Image Enhancement chip-LVDS Bridge-LCD Panel
>> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>> LVDS Bridge-LCD Panel
>> ...
>>
>> As you know, these hardware blocks should be probed without the probe
>> order issue, and also these hardware blocks should be controlled by
>> crtc and connector drivers.
>> However, it seems that there is no any good way for this yet. So I
>> think we would need a common framework, and for this, we could
>> integrate these two frameworks, drm_panel and drm_bridge to one
>> integrated framework.
>> This integrated framework could be used commonly for other hardware blocks.
>>
>> Below is just pseudo structure for this,
>>
>> enum {
>> DRM_HW_BLOCK_PANEL,
>> DRM_HW_BLOCK_BRIDGE,
>> DRM_HW_BLOCK_ENHANCE,
>> };
>>
>> struct drm_hw_block {
>> unsigned int type;
>> struct device *dev;
>> struct drm_device *drm;
>>
>> /* Used commonly. */
>> int (*disable)(struct drm_hw_block *block);
>> int (*enable)(struct drm_hw_block *block);
>>
>> /* For parallel panels. */
>> struct drm_connector *connector;
>> int (*get_modes)(struct drm_hw_block *block);
>>
>> /* For LVDS bridge devices. */
>> void (*mode_fixup)(struct drm_hw_block *block);
>> void (*mode_set)(struct drm_hw_block *block);
>>
>>
>> /* For Image Enhancement devices. */
>>
>>
>> struct list_head list;
>> };
>
> 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 ...
>
> If you don't like the helper libraries provided by the drm core then
> either try to improve them, or just roll your own (like i915 does for
> modesetting).
>
Can the encoder_slave provide interfaces for controlling block devices
that receive output of crtc device? I don't see this encoder_slave can
do it. And my opinion is just to extend existing common frameworks,
drm_panel and drm_bridge. They have already been merged to mainline,
aren't they?
And I understood the encoder_slave is useful for external I2C encoders
so I think it wouldn't be a proper framework for supporting various hw
blocks between display controller and lcd panel, and It seems that the
encoder_slave is specific to desktop device, graphics card.
I really hope you would look into entire contents of my email and give
me your opinion if not yet.
And if there is my missing point, please kindly let me know.
Thanks,
Inki Dae
> Cheers, Daniel
>
>>
>> Of course, we could separate above callbacks to each structure like below,
>>
>> struct drm_panel_funcs {
>> ...
>> };
>>
>> struct drm_bridge_funcs {
>> ...
>> };
>>
>> struct drm_enhance_funcs {
>> ...
>> };
>>
>> struct drm_hw_block {
>> unsigned int type;
>> ...
>> struct drm_panel_funcs *panel_funcs;
>> struct drm_bridge_funcs *bridge_funcs;
>> struct drm_enhance_funcs *enhance_funcs;
>> ...
>> };
>>
>>
>> And then what we should consider is how dt of these blocks should be
>> bound, and how crtc and connector drivers should control these blocks.
>>
>> Below is my idea based on super device concept[1] and video interface
>> concept[2],
>>
>> In case of below hardware pipeline:
>> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>> LVDS Bridge-LCD Panel
>>
>>
>> 1. Bind dt of crtc, connector and block devices, and probe their
>> drivers without the probe order issue using below super node and
>> component framework,
>>
>> exynos-drm {
>> crtcs = <_controller>;
>> connectors = <_dsi>;
>> blocks = <_enhancement>, <>;
>> };
>>
>> In this pipeline, LCD Panel is a client of MIPI DSI
How to support various hardware blocks in drm driver
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 hardware pipeline, > >> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO > >> LVDS Bridge-LCD Panel > >> > >> In above hardware pipeline, Display controller is controlled by crtc, > >> and Image Enhancement chip receives output from display controller. > >> So the use of existing drm_bridge would be suitable to only bridge > >> devices between MIPI DSI and LCD Panel, but not to Image Enhancement > >> chip. > >> > >> For such hardware, drm_panel infrastructure is more reasonable to me, > >> and that is why I try to integrate drm_panel and drm_bridge to one > >> integrated framework which has infrastructure same as existing > >> drm_panel. > >> The important thing is to free this integrated framework from > >> drm_encoder so that crtc device can also use this framework. > > > > Hm, what is this image enhancement chip? Is that some IP block on the > > SoC? Is it optional? Can it be attached to different crtcs? > > In case of Exynos, this chip is in SoC, and can be only attached to > one crtc, display controller. But I'm not sure other SoC have similar > chip. > > > > > I think we have similar things on intel hardware, but without details > > on what it does and how it works I can't really say how to best expose > > it to userspace and how to best handle it internally in the driver. > > -Daniel > > Simply saying, the image enhancement chip can enhance image data from > display controller, i.e. saturation enhancement, color reproduction, > dithering, and so on. > And this chip receives image data through hardware wired lines > connected internally between display controller and this chip. To me this sounds like you simply need to expose all these capabilities to userspace as crtc properties. Which addresses one part of this issue. The other side is how you are going to track this in the driver, and there you can do whatever you want - just add a pointer/structure to the exynos crtc structure for the display enhancement block. The MIPI DSI block would then be treated as a drm_encoder, and all the later stages as drm_bridges up to the very last (the actual lvds panel) which would be a simple drm_panel. I don't really see what additional complexity you need here. Especially since this image enhancer is on your SoC (and I guess a samgsung IP block not shared with any other SoC manufacture) you can easily keep the driver code for it in the exynos driver. So really no need to have a generic interface here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
How to support various hardware blocks in drm driver
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 devices.
However, drm_panel has only some callbacks, enable, disable and
get_modes, and drm_bridge has some callbacks only for bridge devices
so these seems like only for their devices.
However, some SoC could have other type of hardware blocks. i.e. Image
Enhancement blocks.
So it seems that these frameworks don't cover all hardware blocks that
can be placed between Display controller and LCD Panel device.
Below shows various hardware pipe lines for Exynos SoC,
Display Controller-LCD Panel
Display Controller-LVDS Bridge-LCD Panel
Display Controller-MIP DSI-MIPI TO LVDS Bridge-LCD Panel
Display Controller-Image Enhancement chip-LCD Panel
Display Controller-Image Enhancement chip-LVDS Bridge-LCD Panel
Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
LVDS Bridge-LCD Panel
...
As you know, these hardware blocks should be probed without the probe
order issue, and also these hardware blocks should be controlled by
crtc and connector drivers.
However, it seems that there is no any good way for this yet. So I
think we would need a common framework, and for this, we could
integrate these two frameworks, drm_panel and drm_bridge to one
integrated framework.
This integrated framework could be used commonly for other hardware blocks.
Below is just pseudo structure for this,
enum {
DRM_HW_BLOCK_PANEL,
DRM_HW_BLOCK_BRIDGE,
DRM_HW_BLOCK_ENHANCE,
};
struct drm_hw_block {
unsigned int type;
struct device *dev;
struct drm_device *drm;
/* Used commonly. */
int (*disable)(struct drm_hw_block *block);
int (*enable)(struct drm_hw_block *block);
/* For parallel panels. */
struct drm_connector *connector;
int (*get_modes)(struct drm_hw_block *block);
/* For LVDS bridge devices. */
void (*mode_fixup)(struct drm_hw_block *block);
void (*mode_set)(struct drm_hw_block *block);
/* For Image Enhancement devices. */
struct list_head list;
};
Of course, we could separate above callbacks to each structure like below,
struct drm_panel_funcs {
...
};
struct drm_bridge_funcs {
...
};
struct drm_enhance_funcs {
...
};
struct drm_hw_block {
unsigned int type;
...
struct drm_panel_funcs *panel_funcs;
struct drm_bridge_funcs *bridge_funcs;
struct drm_enhance_funcs *enhance_funcs;
...
};
And then what we should consider is how dt of these blocks should be
bound, and how crtc and connector drivers should control these blocks.
Below is my idea based on super device concept[1] and video interface
concept[2],
In case of below hardware pipeline:
Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
LVDS Bridge-LCD Panel
1. Bind dt of crtc, connector and block devices, and probe their
drivers without the probe order issue using below super node and
component framework,
exynos-drm {
crtcs = <_controller>;
connectors = <_dsi>;
blocks = <_enhancement>, <>;
};
In this pipeline, LCD Panel is a client of MIPI DSI driver so LCD
Panel will be controlled by mipi dsi driver internally.
In case of not using MIPI DSI device, connector could be panel like below,
Display Controller-Image Enhancement chip-LCD Panel
exynos-drm {
crtc = <_controller>;
connectors = <>;
blocks = <_enhancement>
};
2. Attach block drivers to their corresponding crtc and connector
drivers using below video interface nodes so that crtc and connector
drivers can control these block drivers using drm_hw_block object.
panel {
...
port {
...
panel_0: endpoint {
remote-endpoint=<_bridge_1>;
};
};
};
lvds-bridge {
...
port at 1 {
...
lvds_bridge_0: endpoint {
remote-endpoint=<_dsi_1>;
};
port at 2 {
lvds_bridge_1: endpoint {
remote-endpoint=<_0>;
};
};
};
mipi-dsi {
...
port at 1 {
...
mipi_dsi_0: endpoint {
remote-endpoint=<_enhancement_1>;
};
};
port at 2 {
...
mipi_dsi_1: endpoint {
remote-endpoint=<_bridge_0>;
};
};
};
image_enhancement {
port at 1 {
image_enhancement_0: endpoint {
remote-endpoint=<_controller_0>;
};
};
port at 2 {
image_enhancement_1:
How to support various hardware blocks in drm driver
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 > > In above hardware pipeline, Display controller is controlled by crtc, > and Image Enhancement chip receives output from display controller. > So the use of existing drm_bridge would be suitable to only bridge > devices between MIPI DSI and LCD Panel, but not to Image Enhancement > chip. > > For such hardware, drm_panel infrastructure is more reasonable to me, > and that is why I try to integrate drm_panel and drm_bridge to one > integrated framework which has infrastructure same as existing > drm_panel. > The important thing is to free this integrated framework from > drm_encoder so that crtc device can also use this framework. Hm, what is this image enhancement chip? Is that some IP block on the SoC? Is it optional? Can it be attached to different crtcs? I think we have similar things on intel hardware, but without details on what it does and how it works I can't really say how to best expose it to userspace and how to best handle it internally in the driver. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
How to support various hardware blocks in drm driver
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 > place, so I'm not sure it will be necessary. I guess we could allow bridges to chain up and have multiple child-bridges or something like that. Plus a helper which finds a suitable routing through this network (it should be a tree after all, so no ambiguity) given a drm_connector/drm_encoder pair. Or maybe I misunderstand what you mean by going from 1 bridge to multiple bridges ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
How to support various hardware blocks in drm driver
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. While I still need to give a closer read > to the original msg, but seems like if you s/drm_hw_block/drm_bridge/g > it is basically the same thing. (Not saying "bridge" is the best > name.. it was just one of those things where no one had a better > suggestion at the time ;-)) Erhm yeah, drm_bridge is what I've meant ;-) Somehow our efforts in i915-land to port our dsi driver over to it have stalled a bit, so I didn't have any examples at hand. Like Rob said, the plan should be to add necessary functionality to drm_bridge or provide convenience helper functions to e.g. wire this up with the new componentized device driver helpers. But in the end you can subclass drm_bridge within exynos and add fancy stuff yourself if needed. We even talked about how we could still allow back-end drivers to be shared between drivers with different drm_bridge subclassing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
How to support various hardware blocks in drm driver
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 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 > > In above hardware pipeline, Display controller is controlled by crtc, > and Image Enhancement chip receives output from display controller. > So the use of existing drm_bridge would be suitable to only bridge > devices between MIPI DSI and LCD Panel, but not to Image Enhancement > chip. > > For such hardware, drm_panel infrastructure is more reasonable to me, > and that is why I try to integrate drm_panel and drm_bridge to one > integrated framework which has infrastructure same as existing > drm_panel. > The important thing is to free this integrated framework from > drm_encoder so that crtc device can also use this framework. Hm, what is this image enhancement chip? Is that some IP block on the SoC? Is it optional? Can it be attached to different crtcs? >>> >>> In case of Exynos, this chip is in SoC, and can be only attached to >>> one crtc, display controller. But I'm not sure other SoC have similar >>> chip. >>> I think we have similar things on intel hardware, but without details on what it does and how it works I can't really say how to best expose it to userspace and how to best handle it internally in the driver. -Daniel >>> >>> Simply saying, the image enhancement chip can enhance image data from >>> display controller, i.e. saturation enhancement, color reproduction, >>> dithering, and so on. >>> And this chip receives image data through hardware wired lines >>> connected internally between display controller and this chip. >> >> I suppose in some sense it doesn't really matter if it is internal >> block or external chip.. >> >> but I'm still a bit confused about why you think drm_panel is a better >> fit.. could you explain that part? >> > > As I already mentioned, see the below hardware pipeline, > Display Controller-Image Enhancement chip-MIPI DSI-MIPI TO > LVDS Bridge-LCD Panel > > In above pipeline, the only place drm_bridge can exist is in MIPI DSI > driver because drm_encoder and drm_connector should be implemented in > MIPI DSI driver like we did using super node, at least in case of > exynos - it seems that this way is reasonable to me according to super > device and video-interface document. > > However, there could be Image Enhancement chip between display > controller and MIPI DSI, and that means we need other thing for > controlling this chip because existing drm_bridge cannot be used for > this. I guess I'm not entirely clear on why each couldn't be a drm_bridge.. I mean, there are probably some other parameters between them, ie. the mipi2lvds bridge would somehow (via phandle, I assume) get a link to the 'struct mipi_dsi_device' ptr from the mipi-dsi node. Obviously we need to add a way to chain up multiple "bridges", but that was already the rough plan, and just waiting for an upstream use-case and someone to implement it ;-) > In the other hands, drm_panel infrastructure could be used by all > device types, crtc or encoder/connector because drm_panel could belong > to any device types. > So I thought it'd better to use existing framework with a little > change than using new one, and we could integrate these two > frameworks, drm_bridge and drm_panel to one framework. > > I am planning to integrate them to one framework, and remove existing > drm_bridge. As a result, it would exist only one integrated > drm_bridge. well, I'm having trouble coming to grips with what it means to have a .get_modes() fxn ptr on something which isn't at the end of the chain. This is what makes me prefer keeping drm_panel as it's own thing. Possibly drm_panel could be a subclass of drm_bridge/hwblock.. not sure if that buys us anything or not. But other than this, and the name (bridge vs hwblock), it sounds like we are pretty much describing the same thing. (and I don't really care about the name.. I'll let someone else paint that bikeshed) BR, -R > Is there any way that can control such chip using existing drm_bridge > contained in drm_encoder? if other better way, please give me your > idea. > > Thanks, > Inki Dae > >> BR, >> -R >> >>> Thanks, >>> Inki Dae >>> -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel at lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel >>>
How to support various hardware blocks in drm driver
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 controlling parallel panels, and
> drm_bridge for controlling LVDS bridge devices.
> However, drm_panel has only some callbacks, enable, disable and
> get_modes, and drm_bridge has some callbacks only for bridge devices
> so these seems like only for their devices.
>
> However, some SoC could have other type of hardware blocks. i.e. Image
> Enhancement blocks.
> So it seems that these frameworks don't cover all hardware blocks that
> can be placed between Display controller and LCD Panel device.
>
> Below shows various hardware pipe lines for Exynos SoC,
>
> Display Controller-LCD Panel
> Display Controller-LVDS Bridge-LCD Panel
> Display Controller-MIP DSI-MIPI TO LVDS Bridge-LCD Panel
> Display Controller-Image Enhancement chip-LCD Panel
> Display Controller-Image Enhancement chip-LVDS Bridge-LCD Panel
> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
> LVDS Bridge-LCD Panel
> ...
>
> As you know, these hardware blocks should be probed without the probe
> order issue, and also these hardware blocks should be controlled by
> crtc and connector drivers.
> However, it seems that there is no any good way for this yet. So I
> think we would need a common framework, and for this, we could
> integrate these two frameworks, drm_panel and drm_bridge to one
> integrated framework.
> This integrated framework could be used commonly for other hardware blocks.
>
> Below is just pseudo structure for this,
>
> enum {
> DRM_HW_BLOCK_PANEL,
> DRM_HW_BLOCK_BRIDGE,
> DRM_HW_BLOCK_ENHANCE,
> };
>
> struct drm_hw_block {
> unsigned int type;
> struct device *dev;
> struct drm_device *drm;
>
> /* Used commonly. */
> int (*disable)(struct drm_hw_block *block);
> int (*enable)(struct drm_hw_block *block);
>
> /* For parallel panels. */
> struct drm_connector *connector;
> int (*get_modes)(struct drm_hw_block *block);
>
> /* For LVDS bridge devices. */
> void (*mode_fixup)(struct drm_hw_block *block);
> void (*mode_set)(struct drm_hw_block *block);
>
>
> /* For Image Enhancement devices. */
>
>
> struct list_head list;
> };
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 ...
If you don't like the helper libraries provided by the drm core then
either try to improve them, or just roll your own (like i915 does for
modesetting).
Cheers, Daniel
>
> Of course, we could separate above callbacks to each structure like below,
>
> struct drm_panel_funcs {
> ...
> };
>
> struct drm_bridge_funcs {
> ...
> };
>
> struct drm_enhance_funcs {
> ...
> };
>
> struct drm_hw_block {
> unsigned int type;
> ...
> struct drm_panel_funcs *panel_funcs;
> struct drm_bridge_funcs *bridge_funcs;
> struct drm_enhance_funcs *enhance_funcs;
> ...
> };
>
>
> And then what we should consider is how dt of these blocks should be
> bound, and how crtc and connector drivers should control these blocks.
>
> Below is my idea based on super device concept[1] and video interface
> concept[2],
>
> In case of below hardware pipeline:
> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
> LVDS Bridge-LCD Panel
>
>
> 1. Bind dt of crtc, connector and block devices, and probe their
> drivers without the probe order issue using below super node and
> component framework,
>
> exynos-drm {
> crtcs = <_controller>;
> connectors = <_dsi>;
> blocks = <_enhancement>, <>;
> };
>
> In this pipeline, LCD Panel is a client of MIPI DSI driver so LCD
> Panel will be controlled by mipi dsi driver internally.
> In case of not using MIPI DSI device, connector could be panel like below,
> Display Controller-Image Enhancement chip-LCD Panel
>
> exynos-drm {
>crtc = <_controller>;
>connectors = <>;
>blocks = <_enhancement>
> };
>
>
> 2. Attach block drivers to their corresponding crtc and connector
> drivers using below video interface nodes so that crtc and connector
> drivers can control these block drivers using drm_hw_block object.
>
> panel {
> ...
> port {
> ...
> panel_0: endpoint {
> remote-endpoint=<_bridge_1>;
> };
> };
> };
>
> lvds-bridge {
>...
>port at 1 {
> ...
> lvds_bridge_0: endpoint {
>remote-endpoint=<_dsi_1>;
> };
How to support various hardware blocks in drm driver
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, >>> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO >>> LVDS Bridge-LCD Panel >>> >>> In above hardware pipeline, Display controller is controlled by crtc, >>> and Image Enhancement chip receives output from display controller. >>> So the use of existing drm_bridge would be suitable to only bridge >>> devices between MIPI DSI and LCD Panel, but not to Image Enhancement >>> chip. >>> >>> For such hardware, drm_panel infrastructure is more reasonable to me, >>> and that is why I try to integrate drm_panel and drm_bridge to one >>> integrated framework which has infrastructure same as existing >>> drm_panel. >>> The important thing is to free this integrated framework from >>> drm_encoder so that crtc device can also use this framework. >> >> Hm, what is this image enhancement chip? Is that some IP block on the >> SoC? Is it optional? Can it be attached to different crtcs? > > In case of Exynos, this chip is in SoC, and can be only attached to > one crtc, display controller. But I'm not sure other SoC have similar > chip. > >> >> I think we have similar things on intel hardware, but without details >> on what it does and how it works I can't really say how to best expose >> it to userspace and how to best handle it internally in the driver. >> -Daniel > > Simply saying, the image enhancement chip can enhance image data from > display controller, i.e. saturation enhancement, color reproduction, > dithering, and so on. > And this chip receives image data through hardware wired lines > connected internally between display controller and this chip. I suppose in some sense it doesn't really matter if it is internal block or external chip.. but I'm still a bit confused about why you think drm_panel is a better fit.. could you explain that part? BR, -R > Thanks, > Inki Dae > >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to support various hardware blocks in drm driver
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 thing shouldn't
be in the base struct.
(and it should subclass 'struct drm_mode_object base' too)
> struct drm_device *drm;
>
> /* Used commonly. */
> int (*disable)(struct drm_hw_block *block);
> int (*enable)(struct drm_hw_block *block);
>
> /* For parallel panels. */
> struct drm_connector *connector;
> int (*get_modes)(struct drm_hw_block *block);
so, other than this part, the rest is already in drm_bridge_funcs.
But seems like something that only makes sense at the end of the chain
(ie. connector/panel end of things).. to me it makes sense to instead
just keep panel as it's own thing.
> /* For LVDS bridge devices. */
> void (*mode_fixup)(struct drm_hw_block *block);
> void (*mode_set)(struct drm_hw_block *block);
>
>
> /* For Image Enhancement devices. */
>
>
> struct list_head list;
> };
>
> Of course, we could separate above callbacks to each structure like below,
yup callbacks should be split out (and normally in a 'const' data
structure if possible)
BR,
-R
How to support various hardware blocks in drm driver
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 in drm driver.
>>
>> Now we have drm_panel framework for controlling parallel panels, and
>> drm_bridge for controlling LVDS bridge devices.
>> However, drm_panel has only some callbacks, enable, disable and
>> get_modes, and drm_bridge has some callbacks only for bridge devices
>> so these seems like only for their devices.
>>
>> However, some SoC could have other type of hardware blocks. i.e. Image
>> Enhancement blocks.
>> So it seems that these frameworks don't cover all hardware blocks that
>> can be placed between Display controller and LCD Panel device.
>>
>> Below shows various hardware pipe lines for Exynos SoC,
>>
>> Display Controller-LCD Panel
>> Display Controller-LVDS Bridge-LCD Panel
>> Display Controller-MIP DSI-MIPI TO LVDS Bridge-LCD Panel
>> Display Controller-Image Enhancement chip-LCD Panel
>> Display Controller-Image Enhancement chip-LVDS Bridge-LCD Panel
>> Display Controller-Image Enhancement chip-MIP DSI-MIPI TO
>> LVDS Bridge-LCD Panel
>> ...
>>
>> As you know, these hardware blocks should be probed without the probe
>> order issue, and also these hardware blocks should be controlled by
>> crtc and connector drivers.
>> However, it seems that there is no any good way for this yet. So I
>> think we would need a common framework, and for this, we could
>> integrate these two frameworks, drm_panel and drm_bridge to one
>> integrated framework.
>> This integrated framework could be used commonly for other hardware blocks.
>>
>> Below is just pseudo structure for this,
>>
>> enum {
>> DRM_HW_BLOCK_PANEL,
>> DRM_HW_BLOCK_BRIDGE,
>> DRM_HW_BLOCK_ENHANCE,
>> };
>>
>> struct drm_hw_block {
>> unsigned int type;
>> struct device *dev;
>> struct drm_device *drm;
>>
>> /* Used commonly. */
>> int (*disable)(struct drm_hw_block *block);
>> int (*enable)(struct drm_hw_block *block);
>>
>> /* For parallel panels. */
>> struct drm_connector *connector;
>> int (*get_modes)(struct drm_hw_block *block);
>>
>> /* For LVDS bridge devices. */
>> void (*mode_fixup)(struct drm_hw_block *block);
>> void (*mode_set)(struct drm_hw_block *block);
>>
>>
>> /* For Image Enhancement devices. */
>>
>>
>> struct list_head list;
>> };
>
> 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. While I still need to give a closer read
to the original msg, but seems like if you s/drm_hw_block/drm_bridge/g
it is basically the same thing. (Not saying "bridge" is the best
name.. it was just one of those things where no one had a better
suggestion at the time ;-))
> If you don't like the helper libraries provided by the drm core then
> either try to improve them, or just roll your own (like i915 does for
> modesetting).
>
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
place, so I'm not sure it will be necessary.
> Cheers, Daniel
>
