From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752360AbcEGMq5 (ORCPT ); Sat, 7 May 2016 08:46:57 -0400 Received: from smtp.domeneshop.no ([194.63.252.55]:45847 "EHLO smtp.domeneshop.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751930AbcEGMq4 (ORCPT ); Sat, 7 May 2016 08:46:56 -0400 Subject: Re: [PATCH 4/4] drm/panel: Add helper for simple panel connector To: Daniel Vetter References: <1462454674-2246-1-git-send-email-noralf@tronnes.org> <1462454674-2246-5-git-send-email-noralf@tronnes.org> <20160506140347.GB4641@ulmo.ba.sec> <20160506140816.GD27098@phenom.ffwll.local> <20160506141532.GC4641@ulmo.ba.sec> <20160506144318.GA15076@ulmo.ba.sec> <3123f353-439d-fbdd-22c8-38c3e4eb3717@tronnes.org> Cc: Thierry Reding , Thierry Reding , Linux Kernel Mailing List , dri-devel From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: <4c42bed9-e987-2b0d-2578-ae096939e5e0@tronnes.org> Date: Sat, 7 May 2016 14:46:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 07.05.2016 11:59, skrev Daniel Vetter: > On Fri, May 6, 2016 at 9:45 PM, Noralf Trønnes wrote: >> In the discussion following the "no more fbdev drivers" call, someone >> pointed me to drm_panel. It had function hooks that I needed, so I built >> tinydrm around it. If this is misusing drm_panel, it shouldn't be too >> difficult to drop it. >> >> Actually I could just do this: >> >> struct tinydrm_funcs { >> int (*prepare)(struct tinydrm_device *tdev); >> int (*unprepare)(struct tinydrm_device *tdev); >> int (*enable)(struct tinydrm_device *tdev); >> int (*disable)(struct tinydrm_device *tdev); >> int (*dirty)(struct drm_framebuffer *fb, void *vmem, unsigned flags, >> unsigned color, struct drm_clip_rect *clips, >> unsigned num_clips); >> }; >> >> >> When it comes to the simple connector, one solution could be to extend >> drm_simple_display_pipe to embed a connector with (optional) modes: >> >> struct drm_simple_display_pipe { >> - struct drm_connector *connector; >> + struct drm_connector connector; >> + const struct drm_display_mode *modes; >> + unsigned int num_modes; >> }; >> >> And maybe optional detect and get_modes hooks: >> >> struct drm_simple_display_pipe_funcs { >> + enum drm_connector_status detect(struct drm_connector *connector, >> + bool force); >> + int (*get_modes)(struct drm_connector *connector); >> }; >> >> int drm_simple_display_pipe_init(struct drm_device *dev, >> struct drm_simple_display_pipe *pipe, >> struct drm_simple_display_pipe_funcs >> *funcs, >> const uint32_t *formats, >> unsigned int format_count, >> - struct drm_connector *connector); >> + int connector_type); > Tbh I really like that simple_display_pipe is split after the encoder. > This allows us to easily splice in a drm_bridge (which will register > the drm_connector itself) with very little work. And even if there's > not a full-blown bridge you might have different connectors and > things. > >> Another solution is to create a simple connector with modes: >> >> struct drm_simple_connector { >> struct drm_connector connector; >> const struct drm_display_mode *modes; >> unsigned int num_modes; >> }; >> >> struct drm_connector *drm_simple_connector_create(struct drm_device *dev, >> const struct drm_display_mode *modes, unsigned int num_modes, >> int connector_type); > Yeah, this makes more sense to me, but then we're kinda reinventing > something like simple-panel.c with this. Otoh right now with > smple_display_pipe it's not possible to wire up the panel callbacks > easily, so maybe it should be a drm_bridge. Or we just leave this code > in tinydrm and extract it when someone else has a need for it? Yes, since there's no obvious use for such a simple controller I'll just put it in tinydrm. Noralf.