Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp2809447imc; Sat, 23 Feb 2019 11:38:54 -0800 (PST) X-Google-Smtp-Source: AHgI3IYyyfSnegMDAi105FsKrxLxI6uIhYG2k/ELo1rQUhPSHxpJk+Kev8WIjY5J4YVuUOEX0O7x X-Received: by 2002:a17:902:850a:: with SMTP id bj10mr10685625plb.91.1550950734550; Sat, 23 Feb 2019 11:38:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550950734; cv=none; d=google.com; s=arc-20160816; b=Rackw5sEEA+x2NDJ5kZWNGJLoCtjSAwvV9VIDAoDlkCLvV9KTo25KZfrm5FcArr9yU UhnmFtZlLAm6hRT4QIo3GKcy6bbDQxqo94hr0kFooSgtHTISyGCHa7vHeSviqzERwrVU uhlan6O2yQ9MCTm6O5WKZv1assklIfWD5uKbtwEtSH0HbYhEkObyHcQtB17bY6SAYNeO xxThivCd9FAoTIfEPlNG64S5DdxTSt/n5mqJ5+f7Zkp8ulmJk+jmx2RBtCCOyH6ixeed mnZWAFMSqFE9ZUcF5tte9ssvDNd98Rk5CuK69AZSUw8yly7o5xS41yUNaVYrA7U8FQGB UoKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Ld4KqyhrfNgOFX1yqDzxY/gp6ZgZHUfohci3i1u/n0M=; b=hEjgu9RRpwIoj2Qx3neO6qPMacGJEU+tqUPF/OHemTI+5xvWaXwYeoY5hFIPALQyZA Rlh7z6bW4GK9HqWR5hPabVXVE6CPS/CSlbliyXl1xDRKd7cAYHrGsZJ8wq0umJbepcgS xOdMvwhZ6xftyIVGWq0LQOk/Jah0kMTmviO/CSl1HsBUYLbG2X5aYJPP7VawtNlFkv84 wTbasHAupXo4ltzGZb2wYyHxKPJaeSzLUlKAwl/BkfI93qc+wHgwQnzKGEAbW/Eb0K2U 7BszqAsJDUund+ws5R6cVG3DkCC9Vjam2JwPM5ohVLsq4O6dtvHdgd0e/OvCrJn6foSR 1QEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m188si4639498pfb.266.2019.02.23.11.38.37; Sat, 23 Feb 2019 11:38:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727795AbfBWTiL (ORCPT + 99 others); Sat, 23 Feb 2019 14:38:11 -0500 Received: from asavdk4.altibox.net ([109.247.116.15]:40371 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726846AbfBWTiL (ORCPT ); Sat, 23 Feb 2019 14:38:11 -0500 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by asavdk4.altibox.net (Postfix) with ESMTPS id 3F11A8032A; Sat, 23 Feb 2019 20:38:07 +0100 (CET) Date: Sat, 23 Feb 2019 20:38:05 +0100 From: Sam Ravnborg To: Peter Ujfalusi Cc: thierry.reding@gmail.com, airlied@linux.ie, daniel@ffwll.ch, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, tomi.valkeinen@ti.com Subject: Re: [PATCH v2 4/4] drm/panel: Add OSD101T2587-53TS driver Message-ID: <20190223193805.GA21790@ravnborg.org> References: <20190222131618.20520-1-peter.ujfalusi@ti.com> <20190222131618.20520-5-peter.ujfalusi@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190222131618.20520-5-peter.ujfalusi@ti.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=UpRNyd4B c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=kj9zAlcOel0A:10 a=7gkXJVJtAAAA:8 a=sozttTNsAAAA:8 a=Wcm_UQoWY5c6ZXSZm6oA:9 a=CjuIK1q_8ugA:10 a=E9Po1WZjFZOl8hwRPBS3:22 a=aeg5Gbbo78KNqacMgKqU:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter. Driver looks to be in good shape now. With the few comments below addressed you can add my: Reviewed-by: Sam Ravnborg Sam On Fri, Feb 22, 2019 at 03:16:18PM +0200, Peter Ujfalusi wrote: > The panel is similar to OSD101T2045-53TS (which is handled by panel-simple) > with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL > message to be sent from the host to be operational and thus can not be > handled by panel-simple. > > Signed-off-by: Peter Ujfalusi > --- > drivers/gpu/drm/panel/Kconfig | 6 + > drivers/gpu/drm/panel/Makefile | 1 + > .../drm/panel/panel-osd-osd101t2587-53ts.c | 254 ++++++++++++++++++ > 3 files changed, 261 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 3e070153ef21..351661920838 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -122,6 +122,12 @@ config DRM_PANEL_ORISETECH_OTM8009A > Say Y here if you want to enable support for Orise Technology > otm8009a 480x800 dsi 2dl panel. > > +config DRM_PANEL_OSD_OSD101T2587_53TS > + tristate "OSD OSD101T2587-53TS DSI 1920x1200 video mode panel" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE Please add a help-text > + > +static int osd101t2587_panel_unprepare(struct drm_panel *panel) > +{ > + struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel); > + > + if (!osd101t2587->prepared) > + return 0; > + > + regulator_disable(osd101t2587->supply); > + osd101t2587->prepared = false; > + > + return 0; > +} > + > +static int osd101t2587_panel_prepare(struct drm_panel *panel) > +{ > + struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel); > + int ret; > + > + if (osd101t2587->prepared) > + return 0; > + > + ret = regulator_enable(osd101t2587->supply); > + if (!ret) > + osd101t2587->prepared = true; Logic is wrong here. regulator_enable() will return a negative value on error and 0 in the good case. So osd101t2587->prepared is set to true only in the error case, not in the good case. > + > + ret = mipi_dsi_attach(dsi); > + if (ret) > + drm_panel_remove(&osd101t2587->base); I do not see panel-simple.c do a drm_panel_remove() if mipi_dsi_attach() fails. Maybe the driver core will call remove() is probe fails? Or maybe panel-simple() should call drm_panel_remove() Keep the above as is - I just wanted to express that this looks different from the panle-simple() driver. > +static int osd101t2587_panel_remove(struct mipi_dsi_device *dsi) > +{ > + struct osd101t2587_panel *osd101t2587 = mipi_dsi_get_drvdata(dsi); > + int ret; > + > + ret = osd101t2587_panel_disable(&osd101t2587->base); > + if (ret < 0) > + dev_warn(&dsi->dev, "failed to disable panel\n"); This is already warned in lower layers and I think you could drop the dev_warn(). > + > + osd101t2587_panel_unprepare(&osd101t2587->base); > + > + drm_panel_remove(&osd101t2587->base); > + > + ret = mipi_dsi_detach(dsi); > + if (ret < 0) > + dev_warn(&dsi->dev, "failed to detach from DSI host\n"); Add error code in logging.