From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFF01C433FE for ; Wed, 15 Sep 2021 21:57:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3BF661131 for ; Wed, 15 Sep 2021 21:57:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232415AbhIOV7F (ORCPT ); Wed, 15 Sep 2021 17:59:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbhIOV7E (ORCPT ); Wed, 15 Sep 2021 17:59:04 -0400 Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC765C061574 for ; Wed, 15 Sep 2021 14:57:44 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id b7so5452272iob.4 for ; Wed, 15 Sep 2021 14:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TzpBTwqbvFq/TilgQetFLjjI03dWCIPzcsLrYptjiKc=; b=K6TMOauirSkiFMCwCeX2VqFIOB5bE6uQEXKKkqTILVEQ91KLpfHsDFwiS5d9bhVgbZ IXMsjXJ8tPickITCEI9YSB4pK1mF2nWDXBajTRZ9yYTPo08FP5w5PSgK1EJiKI+9MxtD flsuvMHCXjN2ePJgCg7E55UUs+Skjlpgj+9KM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TzpBTwqbvFq/TilgQetFLjjI03dWCIPzcsLrYptjiKc=; b=5597ebV1PPTQ8Q2jOo4Av5Djl7hm13i5ArunqxVwHoZtHGZIurTQD9xNv8j/uL9C2x jqRbGfcuzmfy7Y7564YEhHA8gkV18/he2G+tgXyZ9qz0hqBp7lKPiaen3NX+0jbzLIQF WTPfdsetBKMhJvmkRCJfYMMdTqIPXzwVvUCbWrh/Cm5DIbQHZjM9gSQmxyG6muKUp8Ct s7tB6gB1ciRm8ifNv7NHp3HlT4Q7TjVMx1Eqz0H2jt+q3GUkWI50wYhJlQ6xric3LZSr z2Ke5V7e/HiZdJXHDoFglkwDKKg9L9Gf98J8nFxbZ99SXVnZsR5BaYJapA6w1Wv8+IBp //Mw== X-Gm-Message-State: AOAM532mTxvkj/vrKafWqaRB1ZvW/4QpLoTHl6uo8of/46iJbCyjRqcp 6MKylHYVcaWK2OJ1BHjC11G6oatYCiZEBQ== X-Google-Smtp-Source: ABdhPJyOxkBvW5/czybj3Os2hx6RG+xVr0/ts5ekVehqIz33FbHDH6cEhkhPB9k+VnOj/RCIjGUPjg== X-Received: by 2002:a05:6638:22d1:: with SMTP id j17mr1761184jat.129.1631743064103; Wed, 15 Sep 2021 14:57:44 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. [209.85.166.50]) by smtp.gmail.com with ESMTPSA id g14sm668816ila.28.2021.09.15.14.57.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Sep 2021 14:57:43 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id j18so5387324ioj.8 for ; Wed, 15 Sep 2021 14:57:43 -0700 (PDT) X-Received: by 2002:a02:6d59:: with SMTP id e25mr1826747jaf.68.1631743062700; Wed, 15 Sep 2021 14:57:42 -0700 (PDT) MIME-Version: 1.0 References: <20210913143255.RFC.v2.1.I8ad7a535bb18a1f41f3858f83379beedb397a9db@changeid> <20210913143255.RFC.v2.2.I2f55fee564b0008908d8a25a8825117119c80c4a@changeid> In-Reply-To: From: Doug Anderson Date: Wed, 15 Sep 2021 14:57:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 2/2] drm/bridge: parade-ps8640: Add support for AUX channel To: Philip Chen Cc: LKML , Stephen Boyd , Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Neil Armstrong , Robert Foss , dri-devel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Sep 14, 2021 at 5:28 PM Philip Chen wrote: > > > > Changes in v2: > > > - Handle the case where an AUX transaction has no payload > > > - Add a reg polling for p0.0x83 to confirm AUX cmd is issued and > > > read data is returned > > > - Replace regmap_noinc_read/write with looped regmap_read/write, > > > as regmap_noinc_read/write doesn't read one byte at a time unless > > > max_raw_read/write is set to 1. > > > > What about if you set val_bytes? I think you just need to set that to > > "1" and it'll work? > I think val_bytes is already set to 1 as we set val_bits to 8. See: > map->format.val_bytes = DIV_ROUND_UP(config->val_bits, 8); To me that feels like a bug in the regmap API, then. I can't see how it would make any sense for this function not to take val_bytes into account... I wonder if other users are somehow getting lucky today. Maybe users that are using this for MMIO get lucky because max_raw_read is set properly. ...and maybe other i2c users get lucky because some peripherals are OK w/ this bug? AKA, maybe this actually works in most cases for FIFOs: write address of bridge chip on i2c bus write R/W bit on i2c bus write FIFO register address on i2c bus read byte read byte read byte ... read byte read byte end transaction Normally for i2c you assume that the other side will read from subsequent register addresses for each "read byte", but I suppose it's possible that some i2c devices are setup to realize that if the register address was the address of a FIFO that it shouldn't read from the next register address but should just read the next byte in the FIFO? In any case, it's fine to do it with a loop like you're doing but it still seems weird that you'd need to. -Doug From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5728C433EF for ; Wed, 15 Sep 2021 21:57:47 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 9A0D960E08 for ; Wed, 15 Sep 2021 21:57:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9A0D960E08 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C6C0C6EA6E; Wed, 15 Sep 2021 21:57:46 +0000 (UTC) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1056B6EA6E for ; Wed, 15 Sep 2021 21:57:46 +0000 (UTC) Received: by mail-io1-xd2c.google.com with SMTP id g9so5412406ioq.11 for ; Wed, 15 Sep 2021 14:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TzpBTwqbvFq/TilgQetFLjjI03dWCIPzcsLrYptjiKc=; b=K6TMOauirSkiFMCwCeX2VqFIOB5bE6uQEXKKkqTILVEQ91KLpfHsDFwiS5d9bhVgbZ IXMsjXJ8tPickITCEI9YSB4pK1mF2nWDXBajTRZ9yYTPo08FP5w5PSgK1EJiKI+9MxtD flsuvMHCXjN2ePJgCg7E55UUs+Skjlpgj+9KM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TzpBTwqbvFq/TilgQetFLjjI03dWCIPzcsLrYptjiKc=; b=PR2TVR1aT3/uydrc1AHDwEnO151KriMVRONx1BmBiqk+UNgkcXsr8CluDPQOakSCif AngqJdSHbmE2oyL9Z09Jb/pdpjgWfTIvSRGF4gOS8+MMYXzXvRDw04G0R8QS2IZZAYsf fQETA6ZILlo+8VVIjL1tD8c2lj2KylDrrtZscRQY4bF9FSVMneluALKsME3xQIeEawPi C1uXUqajwR6maBw/039GylpVmppf0/UGPnTEJ9icyluH+BmKWVZQUIsgV+QRmu9UWvsw 0ToYwj6gTLru9gP9ip9hHz5w+EHXPKlzQoqm847whvY4dnMkfBic4qLEGHgDlVk0K1aR u5fA== X-Gm-Message-State: AOAM531McfiB2NUopnXQ3asy3lVDwf7hnpuw6mYEB2NfrIS5whiVK1+j PGyPeSxYzypJCoHk6W0z8u93sqxzI78MvQ== X-Google-Smtp-Source: ABdhPJwhW0EnfuXfrNNt5JlPUk2lv0Z5g8k457DifbHHvNf/vvLA1HnLa2cYDYroQCsHOwK0zkF5eA== X-Received: by 2002:a05:6638:1613:: with SMTP id x19mr1772020jas.77.1631743065008; Wed, 15 Sep 2021 14:57:45 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com. [209.85.166.46]) by smtp.gmail.com with ESMTPSA id h9sm560152ioz.30.2021.09.15.14.57.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Sep 2021 14:57:43 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id a15so5447393iot.2 for ; Wed, 15 Sep 2021 14:57:43 -0700 (PDT) X-Received: by 2002:a02:6d59:: with SMTP id e25mr1826747jaf.68.1631743062700; Wed, 15 Sep 2021 14:57:42 -0700 (PDT) MIME-Version: 1.0 References: <20210913143255.RFC.v2.1.I8ad7a535bb18a1f41f3858f83379beedb397a9db@changeid> <20210913143255.RFC.v2.2.I2f55fee564b0008908d8a25a8825117119c80c4a@changeid> In-Reply-To: From: Doug Anderson Date: Wed, 15 Sep 2021 14:57:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v2 2/2] drm/bridge: parade-ps8640: Add support for AUX channel To: Philip Chen Cc: LKML , Stephen Boyd , Andrzej Hajda , Daniel Vetter , David Airlie , Jernej Skrabec , Jonas Karlman , Laurent Pinchart , Neil Armstrong , Robert Foss , dri-devel Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Tue, Sep 14, 2021 at 5:28 PM Philip Chen wrote: > > > > Changes in v2: > > > - Handle the case where an AUX transaction has no payload > > > - Add a reg polling for p0.0x83 to confirm AUX cmd is issued and > > > read data is returned > > > - Replace regmap_noinc_read/write with looped regmap_read/write, > > > as regmap_noinc_read/write doesn't read one byte at a time unless > > > max_raw_read/write is set to 1. > > > > What about if you set val_bytes? I think you just need to set that to > > "1" and it'll work? > I think val_bytes is already set to 1 as we set val_bits to 8. See: > map->format.val_bytes = DIV_ROUND_UP(config->val_bits, 8); To me that feels like a bug in the regmap API, then. I can't see how it would make any sense for this function not to take val_bytes into account... I wonder if other users are somehow getting lucky today. Maybe users that are using this for MMIO get lucky because max_raw_read is set properly. ...and maybe other i2c users get lucky because some peripherals are OK w/ this bug? AKA, maybe this actually works in most cases for FIFOs: write address of bridge chip on i2c bus write R/W bit on i2c bus write FIFO register address on i2c bus read byte read byte read byte ... read byte read byte end transaction Normally for i2c you assume that the other side will read from subsequent register addresses for each "read byte", but I suppose it's possible that some i2c devices are setup to realize that if the register address was the address of a FIFO that it shouldn't read from the next register address but should just read the next byte in the FIFO? In any case, it's fine to do it with a loop like you're doing but it still seems weird that you'd need to. -Doug