From patchwork Fri Apr 26 08:30:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TWljaGFsIFZva8OhxI0=?= X-Patchwork-Id: 10918881 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8D14C92A for ; Fri, 26 Apr 2019 08:32:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A43E28B0A for ; Fri, 26 Apr 2019 08:32:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6BEC528CA1; Fri, 26 Apr 2019 08:32:08 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 08C9028B0A for ; Fri, 26 Apr 2019 08:32:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725993AbfDZIcC (ORCPT ); Fri, 26 Apr 2019 04:32:02 -0400 Received: from uho.ysoft.cz ([81.19.3.130]:56098 "EHLO uho.ysoft.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725923AbfDZIbn (ORCPT ); Fri, 26 Apr 2019 04:31:43 -0400 Received: from iota-build.ysoft.local (unknown [10.1.5.151]) by uho.ysoft.cz (Postfix) with ESMTP id E278FA6C67; Fri, 26 Apr 2019 10:31:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ysoft.com; s=20160406-ysoft-com; t=1556267499; bh=rfteiYZePnPw5S0WgEqmasakIxhk3q23CQyfb8DnLH0=; h=From:To:Cc:Subject:Date:From; b=ZkgiGeyLuxMYjnG1vmW1FM5QFBvuCziN+PNU9GE+c5Y6auQhSIBkd/rM/EbFh9TkC SoPm1UDkfHNNtovf5Flj4791/0tjSTvIpkjkecZVe84O4nBc2lyw4nRdDxDMQtYmPV fqt4JN9Qsc3RRISmhSxi0a4l3I1FOv0RivW8oE9k= From: =?utf-8?b?TWljaGFsIFZva8OhxI0=?= To: Dmitry Torokhov , Rob Herring Cc: Mark Rutland , Shawn Guo , Sascha Hauer , Fabio Estevam , linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Pengutronix Kernel Team , =?utf-8?b?TWljaGFsIFZva8Oh?= =?utf-8?b?xI0=?= Subject: [RFC PATCH 0/4] Input: mpr121-polled: Add polled driver for MPR121 Date: Fri, 26 Apr 2019 10:30:16 +0200 Message-Id: <1556267420-93219-1-git-send-email-michal.vokac@ysoft.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, I have to deal with a situation where we have a custom i.MX6 based platform in production that uses the MPR121 touchkey controller. Unfortunately the chip is connected using only the I2C interface. The interrupt line is not used. Back in 2015 (Linux v3.14), my colleague modded the existing mpr121_touchkey.c driver to use polling instead of interrupt. For quite some time yet I am in a process of updating the product from the ancient Freescale v3.14 kernel to the latest mainline and pushing any needed changes upstream. The DT files for our imx6dl-yapp4 platform already made it into v5.1-rc. I rebased and updated our mpr121 patch to the latest mainline. It is created as a separate driver, similarly to gpio_keys_polled. The I2C device is quite susceptible to ESD. An ESD test quite often causes reset of the chip or some register randomly changes its value. The [PATCH 3/4] adds a write-through register cache. With the cache this state can be detected and the device can be re-initialied. The main question is: Is there any chance that such a polled driver could be accepted? Is it correct to implement it as a separate driver or should it be done as an option in the existing driver? I can not really imagine how I would do that though.. There are also certain worries that the MPR121 chip may no longer be available in nonspecifically distant future. In case of EOL I will need to add a polled driver for an other touchkey chip. May it be already in mainline or a completely new one. I am also little bit confused from the dt-binding documentation. The MPR121 is mentioned in the trivial-devices.yaml but it also has its own binding documentation in input/mpr121_touchkey.txt. I thought that a certain device/compatible should be documented in just one place. The MPR121 device certainly needs more properties than just compatible, reg and interrupt so trivial-devices.yaml does not seem appropriate. I will appreciate any comments. Thank you in advance, Michal Michal Vokáč (4): dt-bindings: input: Add support for the MPR121 without interrupt line Input: mpr121-polled: Add polling variant of the MPR121 touchkey driver Input: mpr121-polled: Add write-through cache to detect corrupted registers ARM: dts: imx6dl-yapp4: Enable MPR121 touch keypad on Hydra .../bindings/input/mpr121-touchkey-polled.txt | 26 ++ arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 12 + arch/arm/boot/dts/imx6dl-yapp4-hydra.dts | 4 + drivers/input/keyboard/Kconfig | 13 + drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/mpr121_touchkey_polled.c | 493 +++++++++++++++++++++ 6 files changed, 549 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/mpr121-touchkey-polled.txt create mode 100644 drivers/input/keyboard/mpr121_touchkey_polled.c