Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp334126imi; Thu, 21 Jul 2022 01:37:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v2B8SlxrWTmrg19FB8wytF2pLz5JJkuQctn+fQOalS/gTRmKHk09XjoQAl0q1yktm2Xc7P X-Received: by 2002:a17:90b:3e8a:b0:1f0:6e06:92e7 with SMTP id rj10-20020a17090b3e8a00b001f06e0692e7mr10162250pjb.155.1658392631365; Thu, 21 Jul 2022 01:37:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658392631; cv=none; d=google.com; s=arc-20160816; b=0SPm3KxXf48EYH6YKuUp3BB7+5hPUaLuDj6Q0kHqKReoE6wsGEaxqQS2RpsDyKGxKl t5l0a61DLty2QV0qknjqFx7Abh/NgA0AFLdzpBVO2WPcsP8ELCYJLjBEQ9bLYDKADi+R PqwOUdrvi8D417QZwk6kPBT7IdOGr6BE5fb9pyzNaUfHjjbTRnUgNQSxTihNsTOZhy+R jD21aKtgTfS6IBGsWZ4dvogzs9Ww4XG+dMGGyiSayUQpYksmjWz7doiEweBj+xJaVKGz 6u+cyEvAGtWQIrd5ujq+mwckMFiAC1K5s9N1Gis1I+h3fZzDK+9/6qwVmWYklQkmJHTw 1kDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=/zDqKrGl64ftCl/UtDpS3dJ8Z5FsjWvYjDB6txbpJn0=; b=ZF2d1EoY1TzBWygTsAk1vn4RYsorJMKPT9r/5cI0vAKJfuIOZ6seMa7wnj6uaFQV6W p3tgfdWSuiFMUUS/JPPjw8SAO7Cb1KkcEluwmPqT8A/KVq1NhnNRaeR7I2BcNJ+mZkF0 c3H3oorcdnpHEnXGVkNJp62qYL8ECJ7oYQVGf+ZJ3ePZJh8Ku+3bhQ3z8qrk1Kh//Flp 71oMPcLgWJsq4kG2pej6QlIFUVJADJM/Of+aTwAo2KBgT3nE5Q6I1ZXYhntsTJ4HTiis 4+zvNPn4n374InxI2WpiVzOfApNvvKS7EGsRjWPaVz1XI1nUdyUnKAYwptAfLxE7CeiM PYeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=XnCG4umu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id np12-20020a17090b4c4c00b001ed0f6f1010si1568400pjb.70.2022.07.21.01.36.56; Thu, 21 Jul 2022 01:37:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=XnCG4umu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230245AbiGUIeL (ORCPT + 99 others); Thu, 21 Jul 2022 04:34:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229780AbiGUIeG (ORCPT ); Thu, 21 Jul 2022 04:34:06 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D3757E02D; Thu, 21 Jul 2022 01:34:05 -0700 (PDT) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 1CACD66019C1; Thu, 21 Jul 2022 09:34:03 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1658392443; bh=4s0tOiWFTuRlGEPdBFkuxG1+Ao4VWz7RCDX8gPnsqMg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=XnCG4umuepYhRdJ3Fp56ynSd1atBas01yoGYPrNVO0nKWX7TYRomdsr2gc02ZSKTz 3kgfeCrifiFObqN6VamY4jSbtgqT2avh5Vc1TtM0uP/QTW5UhjMdb5d5kBC47eGB8K pED9e5UTcZBc11SDehoqwem45pj3qiDtsbyqj+g6dG/QDTDGLDE5A5HH6aAeD/Ql2q VCIK2kuxdV2nOWlCkLIuksn2X97F4cv3C4pB/5BR/0NoC4nrmV0IRABJKHFl7QcmxV 0c2FCZBqZbK3zTQS+NMhr2tK2ZD88nH94WGvycs+lmkH8kLUgmpiOEAzDKBERj9N0R 94x72jHWPrQZw== Message-ID: Date: Thu, 21 Jul 2022 10:34:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v1 4/6] Input: mt6779-keypad - support double keys matrix Content-Language: en-US To: Mattijs Korpershoek , Rob Herring , Krzysztof Kozlowski , Dmitry Torokhov , Matthias Brugger Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, Fabien Parent , devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, Fabien Parent , linux-arm-kernel@lists.infradead.org References: <20220720-mt8183-keypad-v1-0-ef9fc29dbff4@baylibre.com> <20220720-mt8183-keypad-v1-4-ef9fc29dbff4@baylibre.com> From: AngeloGioacchino Del Regno In-Reply-To: <20220720-mt8183-keypad-v1-4-ef9fc29dbff4@baylibre.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 20/07/22 16:48, Mattijs Korpershoek ha scritto: > MediaTek keypad has 2 modes of detecting key events: > - single key: each (row, column) can detect one key > - double key: each (row, column) is a group of 2 keys > > Double key support exists to minimize cost, since it reduces the number > of pins required for physical keys. > > Double key is configured by setting BIT(0) of the KP_SEL register. > > Enable double key matrix support based on the mediatek,double-keys > device tree property. > > Signed-off-by: Mattijs Korpershoek > Reviewed-by: Matthias Brugger > > diff --git a/drivers/input/keyboard/mt6779-keypad.c b/drivers/input/keyboard/mt6779-keypad.c > index bf447bf598fb..9a5dbd415dac 100644 > --- a/drivers/input/keyboard/mt6779-keypad.c > +++ b/drivers/input/keyboard/mt6779-keypad.c > @@ -18,6 +18,7 @@ > #define MTK_KPD_DEBOUNCE_MASK GENMASK(13, 0) > #define MTK_KPD_DEBOUNCE_MAX_MS 256 > #define MTK_KPD_SEL 0x0020 > +#define MTK_KPD_SEL_DOUBLE_KP_MODE BIT(0) > #define MTK_KPD_SEL_COL GENMASK(15, 10) > #define MTK_KPD_SEL_ROW GENMASK(9, 4) > #define MTK_KPD_SEL_COLMASK(c) GENMASK((c) + 9, 10) > @@ -31,6 +32,7 @@ struct mt6779_keypad { > struct clk *clk; > u32 n_rows; > u32 n_cols; > + bool double_keys; > DECLARE_BITMAP(keymap_state, MTK_KPD_NUM_BITS); > }; > > @@ -67,8 +69,13 @@ static irqreturn_t mt6779_keypad_irq_handler(int irq, void *dev_id) > continue; > > key = bit_nr / 32 * 16 + bit_nr % 32; > - row = key / 9; > - col = key % 9; > + if (keypad->double_keys) { > + row = key / 13; > + col = (key % 13) / 2; > + } else { > + row = key / 9; > + col = key % 9; > + } I don't fully like this if branch permanently evaluating true or false, as no runtime can actually change this result... In practice, it's fine, but I was wondering if anyone would disagree with the following proposal... struct mt6779_keypad { ....... void (*calc_row_col)(unsigned int *row, unsigned int *col); }; In mt6779_keypad_irq_handler: key = bit_nr / 32 * 16 + bit_nr % 32; keypad->calc_row_col(&row, &col); and below... > > scancode = MATRIX_SCAN_CODE(row, col, row_shift); > /* 1: not pressed, 0: pressed */ > @@ -150,6 +157,8 @@ static int mt6779_keypad_pdrv_probe(struct platform_device *pdev) > > wakeup = device_property_read_bool(&pdev->dev, "wakeup-source"); > > + keypad->double_keys = device_property_read_bool(&pdev->dev, "mediatek,double-keys"); > + > dev_dbg(&pdev->dev, "n_row=%d n_col=%d debounce=%d\n", > keypad->n_rows, keypad->n_cols, debounce); > > @@ -166,6 +175,10 @@ static int mt6779_keypad_pdrv_probe(struct platform_device *pdev) > regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE, > (debounce * (1 << 5)) & MTK_KPD_DEBOUNCE_MASK); > > + if (keypad->double_keys) keypad->calc_row_col = mt6779_keypad_calc_row_col_double_kp; > + regmap_update_bits(keypad->regmap, MTK_KPD_SEL, > + MTK_KPD_SEL_DOUBLE_KP_MODE, MTK_KPD_SEL_DOUBLE_KP_MODE); > + } else { keypad->calc_row_col = mt6779_keypad_calc_row_col_single_kp; } > regmap_update_bits(keypad->regmap, MTK_KPD_SEL, MTK_KPD_SEL_ROW, > MTK_KPD_SEL_ROWMASK(keypad->n_rows)); > regmap_update_bits(keypad->regmap, MTK_KPD_SEL, MTK_KPD_SEL_COL, what do you think? Cheers, Angelo