From patchwork Mon Nov 8 00:08:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Guillaume Ranquet X-Patchwork-Id: 12607105 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B86CC433EF for ; Mon, 8 Nov 2021 00:10:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CC1AA61378 for ; Mon, 8 Nov 2021 00:10:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CC1AA61378 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=Ckf/wSCLhP9YEsemCViVIco3syJCkoYU6f0Tqj8VPSA=; b=IvUllhClr76ZRr hn3X6v53q1lGCXGm8EwUuicg/zGsEa8xoPeEOSg/SKCQ0VDBL0h3k3/TGToPg+msk5yEM3C6nASnM vtIIy8lFCaSxuTJfqYhUSHUHxJ3ddp5DqrQkgeuLLuG4B5v9R7WOtCM6TIhBV/UlJHo/ZrlS5Iqu+ vsVIabEyYNv/X1E+npJGR4G3LXOS9kapGezGVb+Asw6d0oGfpdlFwUPPtVOBZC75G7dEdCc5VEc+g hIQXeZ6peGG4mBvXw1GQpC4D85Lma1lii5DPHm2cEiWhDpL07gVnALfCAgby57vnE9FIB4uj0fdG0 XgBGxJjqalAewFYfOdTQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mjsDj-00F3rA-MX; Mon, 08 Nov 2021 00:09:07 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mjsDe-00F3ps-LQ for linux-arm-kernel@lists.infradead.org; Mon, 08 Nov 2021 00:09:04 +0000 Received: by mail-wm1-x343.google.com with SMTP id j128-20020a1c2386000000b003301a98dd62so13842263wmj.5 for ; Sun, 07 Nov 2021 16:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=PhZFGqY0zH/NSvPsKdWPPUF4NDL5AM7YBSNSnwu5lDM=; b=4rUNazAqhT/jtutRvM48m+nIXlRE+TG6A3Bq8x8xB6loMdtevnbgaAHyFjUIK0xzyi V/6OGUWdS4rL0en1axAg6C5QwB8WD+TMyh+tYE5A0wLB7+2xGqPWrXKU84fvPyC0ygGS 6c/7o6T4RpNaJ+3M8GI8iV8nj7bH/jKJ8VoNdEWjFbFTzSzUX1hSjQHMjMIEEKlZsHNS PM0hXyO161CsJyn7cyGJRqg6ZbcxKFWpAhBt+aot/FjDmxZwx4FIJbBEcfQcK9oSZNff nnBUMOdi3EBR5PqULsADqNGHxBPGh5YXtpxXDSbWlTlzBYKftT8zMtz67YpP/J0ZczGs 2jXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=PhZFGqY0zH/NSvPsKdWPPUF4NDL5AM7YBSNSnwu5lDM=; b=KPhcQdCxFMIGgoDnhj5QBX+Sm18g0WGod4xAsDBMVfPE1L9QbrF/id8pl69H63iITV cAaoqdYerHyUiheTJTjzg8FuiOH0qDhQUw46B5UOOhXdfJFHo1QAc884Ho+MCSBllX3y 7a9Ra0TU+VBjhVqlaOcMxkpkppaxEAugUMyMTiZ/si9wiz0V8LVOYDND3InnORilxCD1 L5qqnqD9A88aIim11INTIg3Vr0qxNdQFWTPkht8z6VW4Kg1A2FpZXQPLHiQdu5FYjuNj rbDEh23ASEiPqtQmff6pT351+z0dAZP/cgwPSl/sPA8P3tZLECB6JBukBHNVQJCtlLbD LGng== X-Gm-Message-State: AOAM532e/VLzq/OaQmT1SlE7QVoRivrpl3CwUGvRWyyxDwejihPtGsqF ZHda9O4cCkarRH8lTGIPG+kzL9AHD58lDBRt X-Google-Smtp-Source: ABdhPJymyhJiIWmugMw1/8khRjoCxJXIpO4FLFuB0QzdX5vsnG8J18gqY7Eg4H0XtUyDQ8uK5U2KWg== X-Received: by 2002:a1c:4c06:: with SMTP id z6mr32598598wmf.185.1636330139694; Sun, 07 Nov 2021 16:08:59 -0800 (PST) Received: from localhost.localdomain (2a02-8440-6241-67da-3074-96af-9642-0002.rev.sfr.net. [2a02:8440:6241:67da:3074:96af:9642:2]) by smtp.gmail.com with ESMTPSA id a1sm17344278wri.89.2021.11.07.16.08.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Nov 2021 16:08:59 -0800 (PST) From: Guillaume Ranquet To: Matthias Brugger Cc: linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [RFC PATCH 0/2] drm/mediatek/hdmi : split legacy driver and add mt8195 Date: Mon, 8 Nov 2021 01:08:45 +0100 Message-Id: <20211108000847.14320-1-granquet@baylibre.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211107_160902_801235_816D221B X-CRM114-Status: GOOD ( 25.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Following the review of "[v1,4/4] drm/mediatek: add mt8195 hdmi TX support" [1] , I've been asked to try to merge the "legacy HDMI driver with the "new" mt8195 HDMI driver. Though the registers and IPs are rather different, I've made an attempt at the excercise on which I would like some comments before submitting a new version of the patchset. I've created a new mtk_hdmi_common.{c,h} which contains what I could identify as common enough to be added in there. I have not renamed the mtk_hdmi.{c,h} driver to something else yet. I've then added mtk8195 hdmi driver on top of this work. The code is still rather sketchy and I have some questions on best practices for that kind of exercices? In no particular order, here's a bunch of random questions: 1 would you rather have: - as presented here: a boolean with a bunch of if/else in the common code to handle the discrepencies between the two drivers - function pointers, with an "ops" structure set in the drvdata... though the ops are a bit random and wouldn't really make sense to be grouped together? 2 I'm not really happy with how the mt8195 driver and ddc are sharing the same __iomem regs and not sure how to exactly handle this now that both hdmi drivers are tied together... it was hackish from the begining, but now I'm a bit out of solutions to handle this peculiar "feature" of the mt8195 hdmi/ddc driver. any hints would be appreciated. 3 Should the "legacy" and mt8195 drivers be under the same menu entry? 4 I'm looking into the clock framework and I'm wondering if there would be benefits to switch to the "bulk" interface? as both driver seem to request them all once and for all? the code might end up easier to read. 5 Would it be beneficial to further split the driver with audio on one side and video on the other? from what I understood, the main complaint was that the driver was too big to review... that could help with that at least? Thx for your patience... any further comment is welcome. Thx, Guillaume. [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210929094425.745-5-granquet@baylibre.com/