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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DA08C001DC for ; Mon, 17 Jul 2023 11:19:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230144AbjGQLTE (ORCPT ); Mon, 17 Jul 2023 07:19:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229887AbjGQLTC (ORCPT ); Mon, 17 Jul 2023 07:19:02 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7084E48; Mon, 17 Jul 2023 04:19:00 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-993d1f899d7so635098066b.2; Mon, 17 Jul 2023 04:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689592739; x=1692184739; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QijUibtG40+t5LDtP3Zsswxs5UnjGxpVCNjyPMZLJl8=; b=iq1FnouNw8hu78GVyoQBK0Cv8f50DC2LDmg0E/jmuE7TL2mhCtlpiBtRW3xMyfbiCP s7Um1pL125YQciF26uaBkmJ7Sv3OseJHp+TXcKplLPdFIksRY7LGvs4h6XDKkhAqJKDj 1cVJkAHafFI9I8eVtDFdAzjoVq2BV2qTegcJh80HbIKh1fcXi0mXS4gUINK9gDtvx9lb 1BggqdiatGURBcKH9MqIzGcMqrzDA2HmJ7LZg+Uxd42pdVngIwYZvd3bvSUzc6gp29zu /wppIfELH8hKqxugJ7ig069072Mlua7HtiKIVE8l/eAqlH7Pv/Qwk3sVouIZ+OkJGU3J ehGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689592739; x=1692184739; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QijUibtG40+t5LDtP3Zsswxs5UnjGxpVCNjyPMZLJl8=; b=W46qXIbH2njzUpLEszAq3bgHyfQdUEWZ105JAZP8xBBxVbj3ebpx7hkXv+JRBaes/g +ESS1577aGyyPhjT9KTZnVT0Sz/E0RPNCR9DPa2fB80mfnf2Mv9xYWEFDj9Y/3YFaeB5 pnyJwwE0A6jj03e+1v3rc1LbgObf6ezpmEBoN88p6m0QHkuCT2fsPUeC8ujkfRN4BapQ HeRsO7z7+93eg2/5URrz6cDiFPAp9FRP9vgivlmNdjdfc5DlvMl7BsdbifPbtlqNJ80T IGj1FRmbHmmSUEuIkdORJdh79d9j7dJgVG962ZrAEPop12gfCf2cXdWtUiE1vVHpxn9L oCwQ== X-Gm-Message-State: ABy/qLYfzUUYvqzaqrV3AziMI0w5S7GfquJLC6NyGxmL0SNzwNUrYcLc rXSs2K/nbCSIZEhSaMfr67T6R6NOAVy7W3j1dOw= X-Google-Smtp-Source: APBJJlFgxJ9kqESM2vJO7AKAUkjY4G9ICt4eSFqnKKc+eDe0rOvAKel/IRN6zzvlQGEnfjkZIXlQpd77OnW6Y8Ra2Yo= X-Received: by 2002:a17:906:e213:b0:992:48b7:99e3 with SMTP id gf19-20020a170906e21300b0099248b799e3mr10396878ejb.63.1689592739105; Mon, 17 Jul 2023 04:18:59 -0700 (PDT) MIME-Version: 1.0 References: <20230715010407.1751715-1-fabrizio.castro.jz@renesas.com> <20230715010407.1751715-8-fabrizio.castro.jz@renesas.com> In-Reply-To: From: Andy Shevchenko Date: Mon, 17 Jul 2023 14:18:22 +0300 Message-ID: Subject: Re: [PATCH 07/10] spi: rzv2m-csi: Switch to using {read,write}s{b,w} To: Fabrizio Castro Cc: Geert Uytterhoeven , Mark Brown , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Chris Paterson , Biju Das , Prabhakar Mahadev Lad , "linux-renesas-soc@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org On Mon, Jul 17, 2023 at 1:36=E2=80=AFPM Fabrizio Castro wrote: > > From: Geert Uytterhoeven > > Subject: Re: [PATCH 07/10] spi: rzv2m-csi: Switch to using > > {read,write}s{b,w} > > On Sat, Jul 15, 2023 at 3:04=E2=80=AFAM Fabrizio Castro > > wrote: ... > > According to the hardware documentation[1], the access size for both > > the > > CSI_OFIFO and CSI_IFIFO registers is 32 bits, so you must use writel() > > resp. readl(). So please check with the hardware people first. > > > > [1] RZ/V2M User's Manual Hardware, Rev. 1.30. > > You are right, access is 32 bits (and although this patch works fine, > we should avoid accessing those regs any other way). Now I remember > why I decided to go for the bespoke loops in the first place, writesl > and readsl provide the right register access, but the wrong pointer > arithmetic for this use case. > For this patch I ended up selecting writesw/writesb/readsw/readsb to > get the right pointer arithmetic, but the register access is not as > per manual. > > I can either fallback to using the bespoke loops (I can still > remove the unnecessary u8* and u16* casting ;-) ), or I can add > new APIs for this sort of access to io.h (e.g. writesbl, writeswl, > readsbl, readswl, in order to get the pointer arithmetic right for > the type of array handled, while keeping memory access as expected). > > What are your thoughts on that? I think that you need to use readsl() / writesl() on the custom buffer with something like *_sparse() / *_condence() APIs added (perhaps locally to this driver) as they may be reused by others in the future. Having all flavours of read*()/write*() does not scale in my opinion. --=20 With Best Regards, Andy Shevchenko