Hi Javier, Tony,

On 22/12/15 23:18, Javier Martinez Canillas wrote:

>> But if the userspace is using any omapfb specific apps, then yes, update
>> is necessary.
> Yes but these people should have a migration plan anyways since omapfb
> (and fbdev in general) is going away right?

Well, I would guess most people don't know/care about that.

>> Ok. I think it's then best that I just update the defconfig to enable
>> omapfb as modules, as it is currently.
> In that case I think you should squash the defconfig changes with
> commit ("70ba4e05531f omapfb/displays: change CONFIG_DISPLAY_* to
> CONFIG_FB_OMAP2_*") to maintain bisectability.

Here's the diff to change the defconfig to enable the same items as before:

diff --git a/arch/arm/configs/omap2plus_defconfig
index c5e1943e5427..b9581f1f0536 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -290,24 +290,23 @@ CONFIG_FB=y

Tony, the diff above looks like something that's safe to merge via fbdev
tree. The context contains only display related configs. Is it ok if I
squash the above change to my series to keep bisectability?

> Alternatively, the current panel and encoders Kconfig symbols could
> remain for omapfb since that's the current ones used in
> omap2plus_defconfig where omapfb is the default and have new Kconfig
> symbols for omapdrm (i.e: CONFIG_DRM_OMAP_ENCODER_TFP410).

I want to change the config symbols, as the current ones are too generic
(e.g. CONFIG_DISPLAY_PANEL_DPI doesn't mention OMAP anywhere). I think
this is a good time to change them for omapfb. But this is probably a
good time to change them for omapdrm also, so I think I'll add that change.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to