Received: by 2002:a89:48b:0:b0:1f5:f2ab:c469 with SMTP id a11csp950641lqd; Thu, 25 Apr 2024 01:20:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUc1rC1VZPeJPuo4sD8avj0ziXlVbGGSiPHPBtY8kV2rcet8DDlwRcRgD6e4yMcDYX4tJoeZdfWrMC3hzqcjX9vfOr83W9UdjCf8dhjow== X-Google-Smtp-Source: AGHT+IElMxEl0OWzbGpnOJu/aOnNfE7+beZb0NHdySAR18QiF1om0Eii05MuL4Ho9GIbSd1/9+28 X-Received: by 2002:a05:6359:2781:b0:186:c06f:437c with SMTP id ly1-20020a056359278100b00186c06f437cmr4566288rwb.14.1714033203541; Thu, 25 Apr 2024 01:20:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714033203; cv=pass; d=google.com; s=arc-20160816; b=iwXaXeDDhSI4XXHq8c3u6Ktidibf8ATAaKTn1TJUCXFeqrLkWEaYwe2mJFT6SZJLJY HEKkAvg2q/4vYSjaFMvIfxTtff70yIWpijgCcRdupdROCsduQOFK2VTKQodu/r7vVPxK oh2SZz0yEYzyv8td4a2Gtom+I46nkt8xREFIYgwbgXhCDyzVo81UrKynXcxACmBL3K8B L4Y+9IcFKvNaFCjIFj5mFcKPsRr02ufyFkvbBzZZnJLsU4+cRCfL0s3kioBg3p+2E4fu +eNVa7xBWFebhm+GJlxdfoYFxRFXRGaZOpJ+kaveAiiPzj4ESZicEFURAJ/XamR7sToh HhBQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:date:references:organization:in-reply-to:subject:cc:to :from:dkim-signature; bh=XaNzEUcQiSUiwNHBwQnIhPlY4ZvYQ274kpRsC8fwLog=; fh=ksNxIs36Ojrvz/yFM9BPryWHQdK54fEK11JkPzabm+Q=; b=O03TmFw5G6KoRTs/fKdGTAAHecDgBItL6+Dl8bANFzph/XuPK/obRwi7H1PkziTpH9 xo8RDO2mHgfwFV4fT3bEOywQKxZWiGXRGaDXdQc0vs+fz3cd4F9ngHoO7JjDwfmUUmCJ cT9XLOaoiNsiGS04McJqbObuvI5ZNYRN2ouS1RYD4oJxl2Sjqxtsxc7xSf1d9IrY1Wyw TbO61ANjSepAoq0hnFHn3L8f5+KKcGCX49ifzheRCnNI/grjJyKg41oZoypziwUSEYYc uaQZkvt433AZun2In0kPhSdNX748CRA/FPKIV7YaZfi0zyJVvEbgS8SPWXZA3Jvxbxof SOqQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=I6KCWD+1; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-158187-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-158187-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id by14-20020a056a02058e00b005f8076c6729si10268086pgb.379.2024.04.25.01.20.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Apr 2024 01:20:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-158187-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=I6KCWD+1; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-158187-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-158187-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 257A7281C73 for ; Thu, 25 Apr 2024 08:20:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 68CD56EB7C; Thu, 25 Apr 2024 08:19:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="I6KCWD+1" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF3E72D60A for ; Thu, 25 Apr 2024 08:19:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714033197; cv=none; b=b4DPBxE3Vz8dCu2VfpHlPCPjfv6lJNhUOPlL1+M8Czxmo569P3og/dRLzJxpkDCHyzcnsnQBopVOwOUiC6WKLSD9dMAj4zDXR6WqWuy8iBwWVJzQrBKYT5yrcHAyxaKroXjEIFSNQnXpPNwCOaGi2RmEKs2ULfvVP4g6kueIht0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714033197; c=relaxed/simple; bh=X0LexaSUYca3KBoxilRdzCtdkjqHtHxgzOLPDEOLU4Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=uzHYTAR4iTRo9LGiQTmMscZrMy4mXOGN3QShr+zIWBIJ2Conna1F6DE1frKXrtGtE1RsYvmRcfxfakWLh060lcZ6VZQeA4+NDii8Qw737O2i8begPU60ZGo9I2MPERLFKTVkY5fYxlZFAuj+WVaYF1+Nuh0F6z/9fY8Tz+YZup0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=I6KCWD+1; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1714033195; x=1745569195; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=X0LexaSUYca3KBoxilRdzCtdkjqHtHxgzOLPDEOLU4Q=; b=I6KCWD+1iw5Vm6Nnjiwx6gMBCjQ587F552mwTwzrj6j1nA9MnvLKR1d6 pQvnJymvQMkKRLzaq+mZOlQSbBQjKrIH7+ku9sgigKQNvGhLJ4xpENQMJ k3e0YAKXpbog8xvhF24iW4x227obls/K773etBnbmSE5NF/DbVnBFxyBL giUi9nda+xyjZdyoWRl2gQKdXUlX2SJebdF103JTKLXCgHb3q5idnHpF+ 0TA1JE9ZGy+nE9D9/nSQ95NEwWHBZCGn3Az1sp/Qxx23tihegAqVDrb7M DjGRqpyBptb6NAz8W7QM7CvMDba0Pu8BmUEFHr4Wfdl5X9c1qN6YeGv5W Q==; X-CSE-ConnectionGUID: JJLMlsVJQwiq/wBxOCG7/g== X-CSE-MsgGUID: bAe3YfnyTpupxw+2yRv/Cw== X-IronPort-AV: E=McAfee;i="6600,9927,11054"; a="9815789" X-IronPort-AV: E=Sophos;i="6.07,228,1708416000"; d="scan'208";a="9815789" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2024 01:19:53 -0700 X-CSE-ConnectionGUID: 6XyZWAvmRVOwKqK+3DMurw== X-CSE-MsgGUID: NUqMB8tkRQuRepSk1h6YIg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,228,1708416000"; d="scan'208";a="24868019" Received: from scojocar-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.46.44]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2024 01:19:46 -0700 From: Jani Nikula To: Douglas Anderson , dri-devel@lists.freedesktop.org Cc: Javier Martinez Canillas , Neil Armstrong , Dmitry Baryshkov , linus.walleij@linaro.org, Cong Yang , lvzhaoxiong@huaqin.corp-partner.google.com, Hsin-Yi Wang , Sam Ravnborg , Douglas Anderson , Daniel Vetter , David Airlie , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq() In-Reply-To: <20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid> Date: Thu, 25 Apr 2024 11:19:43 +0300 Message-ID: <87pludq2g0.fsf@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, 24 Apr 2024, Douglas Anderson wrote: > The consensus of many DRM folks is that we want to move away from DSI > drivers defining tables of init commands. Instead, we want to move to > init functions that can use common DRM functions. The issue thus far > has been that using the macros mipi_dsi_generic_write_seq() and > mipi_dsi_dcs_write_seq() bloats the driver using them. > > Through a cooperative effort between Hsin-Yi Wang and Dmitry > Baryshkov, we have realized that the majority of the bloat is the fact > that we have the dev_err_ratelimited() directly in the macros. Let's > hoist this call into drm_mipi_dsi.c by adding a "chatty" version of > the functions that includes the print. > > Without any changes to clients this gives a dramatic savings. Building > with my build system shows one example: > > $ scripts/bloat-o-meter \ > .../before/panel-novatek-nt36672e.ko \ > .../after/panel-novatek-nt36672e.ko > > add/remove: 0/1 grow/shrink: 1/1 up/down: 6/-19652 (-19646) > Function old new delta > __UNIQUE_ID_vermagic520 64 70 +6 > nt36672e_1080x2408_60hz_init 16592 7260 -9332 > nt36672e_1080x2408_60hz_init._rs 10320 - -10320 > Total: Before=31503, After=11857, chg -62.36% > > Note that given the change in location of the print it's harder to > include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since, > theoretically, someone could call the new chatty function with a > zero-size array and it would be illegal to dereference data[0]. > There's a printk format to print the whole buffer and this is probably > more useful for debugging anyway. Given that we're doing this for > mipi_dsi_dcs_write_seq(), let's also print the buffer for > mipi_dsi_generic_write_seq() in the error case. > > Signed-off-by: Douglas Anderson > --- > The MIPI device I have in front of me (wormdingler) hasn't been > converted to use these functions yet, so this is just compile > tested. It's about my end of day so I'm sending this out since it's > pretty straightforward. Hopefully others can confirm it works well for > them and also saves space under their compilers. > > drivers/gpu/drm/drm_mipi_dsi.c | 54 ++++++++++++++++++++++++++++++++++ > include/drm/drm_mipi_dsi.h | 31 ++++++++----------- > 2 files changed, 67 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c > index 795001bb7ff1..5ded6aef38ed 100644 > --- a/drivers/gpu/drm/drm_mipi_dsi.c > +++ b/drivers/gpu/drm/drm_mipi_dsi.c > @@ -764,6 +764,33 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi, const void *payload, > } > EXPORT_SYMBOL(mipi_dsi_generic_write); > > +/** > + * mipi_dsi_generic_write_chatty() - mipi_dsi_generic_write() w/ an error log > + * @dsi: DSI peripheral device > + * @payload: buffer containing the payload > + * @size: size of payload buffer > + * > + * Just like mipi_dsi_generic_write() but includes a dev_err_ratelimited() > + * call for you. > + * > + * Return: The number of bytes transmitted on success or a negative error code > + * on failure. > + */ > +ssize_t mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi, > + const void *payload, size_t size) > +{ > + struct device *dev = &dsi->dev; > + int ret; > + > + ret = mipi_dsi_generic_write(dsi, payload, size); > + if (ret < 0) > + dev_err_ratelimited(dev, "sending generic data %*ph failed: %d\n", > + (int)size, payload, ret); Why does this even need to be ratelimited? See below. > + > + return ret; > +} > +EXPORT_SYMBOL(mipi_dsi_generic_write_chatty); > + > /** > * mipi_dsi_generic_read() - receive data using a generic read packet > * @dsi: DSI peripheral device > @@ -852,6 +879,33 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi, > } > EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer); > > +/** > + * mipi_dsi_dcs_write_buffer_chatty - mipi_dsi_dcs_write_buffer() w/ an error log > + * @dsi: DSI peripheral device > + * @data: buffer containing data to be transmitted > + * @len: size of transmission buffer > + * > + * Just like mipi_dsi_dcs_write_buffer() but includes a dev_err_ratelimited() > + * call for you. > + * > + * Return: The number of bytes successfully transmitted or a negative error > + * code on failure. > + */ > +ssize_t mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi, > + const void *data, size_t len) > +{ > + struct device *dev = &dsi->dev; > + int ret; > + > + ret = mipi_dsi_dcs_write_buffer(dsi, data, len); > + if (ret < 0) > + dev_err_ratelimited(dev, "sending dcs data %*ph failed: %d\n", > + (int)len, data, ret); > + > + return ret; > +} > +EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer_chatty); > + > /** > * mipi_dsi_dcs_write() - send DCS write command > * @dsi: DSI peripheral device > diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h > index 82b1cc434ea3..784e425dc4c8 100644 > --- a/include/drm/drm_mipi_dsi.h > +++ b/include/drm/drm_mipi_dsi.h > @@ -256,6 +256,8 @@ int mipi_dsi_picture_parameter_set(struct mipi_dsi_device *dsi, > > ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi, const void *payload, > size_t size); > +ssize_t mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi, > + const void *payload, size_t size); > ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi, const void *params, > size_t num_params, void *data, size_t size); > > @@ -279,6 +281,8 @@ enum mipi_dsi_dcs_tear_mode { > > ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi, > const void *data, size_t len); > +ssize_t mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi, > + const void *data, size_t len); > ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd, > const void *data, size_t len); > ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data, > @@ -317,14 +321,10 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, > #define mipi_dsi_generic_write_seq(dsi, seq...) \ > do { \ > static const u8 d[] = { seq }; \ > - struct device *dev = &dsi->dev; \ > int ret; \ > - ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \ > - if (ret < 0) { \ > - dev_err_ratelimited(dev, "transmit data failed: %d\n", \ > - ret); \ > + ret = mipi_dsi_generic_write_chatty(dsi, d, ARRAY_SIZE(d)); \ > + if (ret < 0) \ > return ret; \ > - } \ > } while (0) The one thing that I've always disliked about these macros (even if I've never actually used them myself) is that they hide control flow from the caller, i.e. return directly. You don't see that in the code, it's not documented, and if you wanted to do better error handling yourself, you're out of luck. Be that as it may, the combo of ratelimited error printing and return on errors does not make much sense to me. If there's something to print, you bail out, that's it. I suspect we never hit the ratelimit. You might even want to try *only* changing the ratelimited printing to a regular error message, and see if the compiler can combine the logging to a single exit point in the callers. Ratelimited it obviously can't because every single one of them is unique. BR, Jani. > > /** > @@ -333,18 +333,13 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, > * @cmd: Command > * @seq: buffer containing data to be transmitted > */ > -#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...) \ > - do { \ > - static const u8 d[] = { cmd, seq }; \ > - struct device *dev = &dsi->dev; \ > - int ret; \ > - ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \ > - if (ret < 0) { \ > - dev_err_ratelimited( \ > - dev, "sending command %#02x failed: %d\n", \ > - cmd, ret); \ > - return ret; \ > - } \ > +#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...) \ > + do { \ > + static const u8 d[] = { cmd, seq }; \ > + int ret; \ > + ret = mipi_dsi_dcs_write_buffer_chatty(dsi, d, ARRAY_SIZE(d)); \ > + if (ret < 0) \ > + return ret; \ > } while (0) > > /** -- Jani Nikula, Intel