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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 5A05BC433E2 for ; Thu, 17 Sep 2020 11:44:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A5BF21D7F for ; Thu, 17 Sep 2020 11:44:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600343045; bh=2kFT8juYwsoWVzI7Gq+GsE3itaIadnAkZ07YinPSRLM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=KQV8n8YvN5BBHj2qwpra0iknVUB+zkND2H6B2hNTJIYVUm8rrCKE45mVq/vjGWOoO Sk8YG5Dk8x+b3pWJ2x5xSUoeHy9jHfRtNt3Q7vzoHe8oMVj7i7r5YTMcFPCKUEQBJ1 gU4Flrhg6WbiF9mbGln0urzkX7RVpCZ7feuRUTD4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726829AbgIQLnJ (ORCPT ); Thu, 17 Sep 2020 07:43:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:56078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726790AbgIQLjQ (ORCPT ); Thu, 17 Sep 2020 07:39:16 -0400 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ECCB321734 for ; Thu, 17 Sep 2020 11:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600342752; bh=2kFT8juYwsoWVzI7Gq+GsE3itaIadnAkZ07YinPSRLM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tvlPHrWAbfHzeALQ3FScCd2/cS8WzS7Z+m1J15aLvYrV2REfj3RMU4vd5mUus+WjJ I+CLBi3DxCghZTVCPYty6KplFv7CXtwGO5Tm3o4iUme6OyGRORe5Km31cd1/wkomIV Goj980jY6gxYDQlcTyBWByd1ZJ04ZaTTFsSWJeLw= Received: by mail-lj1-f172.google.com with SMTP id b19so1706612lji.11 for ; Thu, 17 Sep 2020 04:39:11 -0700 (PDT) X-Gm-Message-State: AOAM530g7YEYyceWDj7OubtHT11TzuIfrhC8d+Mpt0od16XzFgsod+/J B4xXXoEJ8PVcm6t7d84JtopSx0E7LQH72faop/w= X-Google-Smtp-Source: ABdhPJwoHeTsp9Hl9XkIyBQug7suvujQKpXb1f1sRZCguXUEwXE3AQHbyb1VPFKzFK7Tn3JsTZrDVGbiWNqlu6j+f+M= X-Received: by 2002:a2e:a28b:: with SMTP id k11mr10380503lja.405.1600342750320; Thu, 17 Sep 2020 04:39:10 -0700 (PDT) MIME-Version: 1.0 References: <20200916160552.1062243-1-ribalda@kernel.org> <20200916162824.GC6374@sirena.org.uk> <20200917112203.GB4755@sirena.org.uk> In-Reply-To: <20200917112203.GB4755@sirena.org.uk> From: Ricardo Ribalda Delgado Date: Thu, 17 Sep 2020 13:38:53 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] regmap: Add support for 12/20 register formatting To: Mark Brown Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org HI Mark On Thu, Sep 17, 2020 at 1:22 PM Mark Brown wrote: > > On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote: > > On Wed, Sep 16, 2020 at 6:29 PM Mark Brown wrote: > > > > What exactly is the format you're trying to describe here? It sounds > > > like there's two blocks of padding in here (I'm assuing that's what > > > dummy means) but what's the exact arrangement here and what are the > > > commands? It sounds like this might not work ideally with things like > > > the cache code (if it makes things seems sparser than they are) and > > > might not be obvious to someone looking at the datsheet. > > > The format is > > > XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX > > > Where X is dont care, C is command, A is address and D is data bits. I > > > Shall I add this to the commit message? I want to send a V2 anyway, > > because I screwed up the identity (ribalda.com instead of kernel.org) > > Yes, please. I was fairly sure it worked, it was just a question of if > it was ideal for the format described. The only issue I can see with > the above is that the users will need to left shift their data - on the > face of it it would seem better to add a facility for padding the LSBs > of the data field to the core so that users can just use the data field > as documented. I was thinking also about that, the problem is that there are many devices on that family that are "software" compatible and it only changes the width of the data. Eg: DDDDDDDDDDDDDDDDXXXX DDDDDDDDDDDDXXXXXXXX DDDDDDDDXXXXXXXXXXXX So if we need to make a driver, we could use the same driver for all the chips on that family, saying to the user that the data size is always 20 bits.... I will send v2 ASAP with the updated doc. Thanks