Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp714116ybx; Thu, 7 Nov 2019 01:29:33 -0800 (PST) X-Google-Smtp-Source: APXvYqxisiWJScO6r5g764Eht3l63hPtcUG7q2KLPfNRuu0upqpVpIlWVjmuyZcuRm+kF/nHd+wu X-Received: by 2002:a05:6402:1049:: with SMTP id e9mr2380671edu.91.1573118972919; Thu, 07 Nov 2019 01:29:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573118972; cv=none; d=google.com; s=arc-20160816; b=TM0/uWyC0kvBqMOyNRmSiQs99R33nd5Xi6LHb7AsRlLcXxgKvie/rx1jTzhTpdIxtM OSBMHQVAWV4zeAwlm6yjFZJYtNP37yNasggpnI80seJhj8uGbvYwUiezJD+5D+6i/2+G rBvbvNV/2Mvl2UqgfQ4146SKNk2ug51Tvx5QZkPENXmIHcfIwidPMmtCdp97Lh4GWoZr bj5d/EqFVfU3uk/UkKaI14uEzn69LUaF5quWON9IB+TDYNJCWlLQL0TcEqhkmr04sk2+ vc0Kti1iD8x0tIX3X2F2RwXBrtgvrtC6Jhu6Q3B6WsjKFBdqPZEPMxAEzhENkvoIg3Pu KgqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=zxL2pu+aN0ZYRh9GalkED+BEbSMbqeXyiC5lDAJbwEg=; b=xA7taw5N0F+r84g8FhPuC34aIXayiHciFaDSbeh8TZCO0tER0QfvRMfoZ2inKRXt5K XZyPblz30id/DOSJ016JsD8Iybe5QLe4wFhEqiejN+tYfKZZqtUTqw3HxgUb/CRmtnN6 7AMdL0leLIFJFKZ6ysuF8fpQfnj0qeD0Cbb1v2aGPraCRcVK6QxkAyyAcV2N8SSqKj8j hFen8iHzsGAoY5OYCJdzXMVKf3uk7vKTuRHGkzPQk5iBWYQuFfO/4l7aSHHSIRQg6tH4 e9oAr9Kd3EqTXJ8920QLQPaq5bPxoiElcRvSsq4er7fZKWO4sesK4QPom2K5mHbAdWmC l7jw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@antmicro.com header.s=google header.b=VrcATMyU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6si1075029ejx.0.2019.11.07.01.29.09; Thu, 07 Nov 2019 01:29:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@antmicro.com header.s=google header.b=VrcATMyU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733189AbfKGJ1e (ORCPT + 99 others); Thu, 7 Nov 2019 04:27:34 -0500 Received: from mail-il1-f194.google.com ([209.85.166.194]:36298 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728051AbfKGJ1d (ORCPT ); Thu, 7 Nov 2019 04:27:33 -0500 Received: by mail-il1-f194.google.com with SMTP id s75so1182261ilc.3 for ; Thu, 07 Nov 2019 01:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antmicro.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zxL2pu+aN0ZYRh9GalkED+BEbSMbqeXyiC5lDAJbwEg=; b=VrcATMyUB9gM2h1qTNrx6x5YrZ3FNEr1qyLafDIYgxlmwfFjsqta2N4xNBRvzebR+4 BZ3b3ah/Aw87W/t81zuVu4SsbGYEc6gc/g3/b3VjTmzUOqhQFl7D+E5qWKRTrPltUdRM c22lL2pQqtbbN65Pi32E5QEG0JL5LgZ8ontZIBqmZWmVIKDPQ3L0XTyw7OsSWCPxdwHH UPNBZscOeDxelrb8gBYlPKFsz9v6R+VMitxFN4+NwB+Y4Ov2NigkJLa5vffsWwXNqK9b 98zr3ITZjSGkhmeaQznpVGjKnMOZCIGDEnzsK4cCvLGgaud2Du0pSch5zggw9hrntqT5 a+nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zxL2pu+aN0ZYRh9GalkED+BEbSMbqeXyiC5lDAJbwEg=; b=jYFhAyW4Y0zBUu/b46MSe42AVF+KnxuNw8ezsuQCS/UFqa9F4HRbxTLn9sHHprdbWW 6gGdwjgiLMrSNncP3oMbyU8Bg8nMwij8Fb/P2gEcGnUFlyWCKPF2+3YEAGh+oCNgunkI SQKzUjubDv9AwC3N+iNj1D5Je8peOoCrw8f4D6GItZnkU2V1dnhYDApYZ/35Lj282r/n dXzVHkDqoek6cvmzKiULjCsX4OOahX8CSD1lur4RzDSQvP35cDQF/JsjPDs4u96yAVPj HX0HQU1puCrnclnZ4GUD4pKXJN2OYIjRdmkft0MalulNwcWnhgnvR7jGZvrnCGJAll0/ prBA== X-Gm-Message-State: APjAAAXEcpWnAiWE+Bb7tk0/gRqvqHNcLv/FRzv6IJl4eCwXvv3fhlqJ YuRRmCwacF/9cJlm3uAH4hUB+EL+0swZOEhN3cA+Hw== X-Received: by 2002:a92:3b9a:: with SMTP id n26mr3239330ilh.82.1573118850734; Thu, 07 Nov 2019 01:27:30 -0800 (PST) MIME-Version: 1.0 References: <20191023114634.13657-0-mholenko@antmicro.com> <20191023114634.13657-2-mholenko@antmicro.com> <20191026000345.GA10810@bogus> In-Reply-To: <20191026000345.GA10810@bogus> From: Mateusz Holenko Date: Thu, 7 Nov 2019 10:27:19 +0100 Message-ID: Subject: Re: [PATCH v2 2/4] litex: add common LiteX header To: Rob Herring Cc: Mark Rutland , Greg Kroah-Hartman , Jiri Slaby , devicetree@vger.kernel.org, "open list:SERIAL DRIVERS" , Stafford Horne , Karol Gugala , Mauro Carvalho Chehab , "David S. Miller" , "Paul E. McKenney" , Filip Kokosinski , Joel Stanley , Jonathan Cameron , Maxime Ripard , Shawn Guo , Heiko Stuebner , Sam Ravnborg , Icenowy Zheng , Laurent Pinchart , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org sob., 26 pa=C5=BA 2019 o 02:03 Rob Herring napisa=C5=82(a= ): > > On Wed, Oct 23, 2019 at 11:47:04AM +0200, Mateusz Holenko wrote: > > It provides helper CSR access functions used by all > > LiteX drivers. > > > > Signed-off-by: Mateusz Holenko > > --- > > This commit has been introduced in v2 of the patchset. > > > > MAINTAINERS | 6 +++++ > > include/linux/litex.h | 59 +++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 65 insertions(+) > > create mode 100644 include/linux/litex.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 296de2b51c83..eaa51209bfb2 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9493,6 +9493,12 @@ F: Documentation/misc-devices/lis3lv02d.rst > > F: drivers/misc/lis3lv02d/ > > F: drivers/platform/x86/hp_accel.c > > > > +LITEX PLATFORM > > +M: Karol Gugala > > +M: Mateusz Holenko > > +S: Maintained > > +F: include/linux/litex.h > > + > > LIVE PATCHING > > M: Josh Poimboeuf > > M: Jiri Kosina > > diff --git a/include/linux/litex.h b/include/linux/litex.h > > new file mode 100644 > > index 000000000000..e793d2d7c881 > > --- /dev/null > > +++ b/include/linux/litex.h > > @@ -0,0 +1,59 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Common LiteX header providing > > + * helper functions for accessing CSRs. > > + * > > + * Copyright (C) 2019 Antmicro > > + */ > > + > > +#ifndef _LINUX_LITEX_H > > +#define _LINUX_LITEX_H > > + > > +#include > > +#include > > +#include > > + > > +#define LITEX_REG_SIZE 0x4 > > +#define LITEX_SUBREG_SIZE 0x1 > > +#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8) > > + > > +#ifdef __LITTLE_ENDIAN > > +# define LITEX_READ_REG(addr) ioread32(addr) > > +# define LITEX_READ_REG_OFF(addr, off) ioread32(addr + off) > > +# define LITEX_WRITE_REG(val, addr) iowrite32(val, addr) > > +# define LITEX_WRITE_REG_OFF(val, addr, off) iowrite32(val, addr + o= ff) > > +#else > > +# define LITEX_READ_REG(addr) ioread32be(addr) > > +# define LITEX_READ_REG_OFF(addr, off) ioread32be(addr + off) > > +# define LITEX_WRITE_REG(val, addr) iowrite32be(val, addr) > > +# define LITEX_WRITE_REG_OFF(val, addr, off) iowrite32be(val, addr += off) > > Defining custom accessors makes it harder for others to understand > the code. The __raw_readl/writel accessors are native endian, so use > those. One difference though is they don't have a memory barrier, but > based on the below functions, you may want to do your own barrier > anyways. And if DMA is not involved you don't need the barriers either. LiteX CSRs are always little endian (even when combined with a big endian C= PU), so using just __raw_readl/writel won't work in all cases. This is the reaso= n why we proposed a custom accessors defined based on host CPU endianness. Would adding a comment explaining this be enough or do you have other ideas= ? > The _OFF variants don't add anything. LITEX_READ_REG(addr + off) is just > as easy to read if not easier than LITEX_READ_REG_OFF(addr, off). I agree, LITEX_READ_REG/LITEX_WRITE_REG is enough. > > +#endif > > + > > +/* Helper functions for manipulating LiteX registers */ > > + > > +static inline void litex_set_reg(void __iomem *reg, u32 reg_size, u32 = val) > > +{ > > + u32 shifted_data, shift, i; > > + > > + for (i =3D 0; i < reg_size; ++i) { > > + shift =3D ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT); > > + shifted_data =3D val >> shift; > > + LITEX_WRITE_REG(shifted_data, reg + (LITEX_REG_SIZE * i))= ; > > + } > > +} > > The problem with this is it hides whether you need to do any locking. > Normally, you would assume a register access is atomic when it's not > here. You could add locking in this function, but then you're doing > locking even when not needed. > > It doesn't look like you actually use this in your series, so maybe > remove until you do. That's right. I added those functions in advance, having in mind further drivers, but maybe it will be better to drop them for now and re-introduce later. > > + > > +static inline u32 litex_get_reg(void __iomem *reg, u32 reg_size) > > +{ > > + u32 shifted_data, shift, i; > > + u32 result =3D 0; > > + > > + for (i =3D 0; i < reg_size; ++i) { > > + shifted_data =3D LITEX_READ_REG(reg + (LITEX_REG_SIZE * i= )); > > + shift =3D ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT); > > + result |=3D (shifted_data << shift); > > + } > > + > > + return result; > > +} > > + > > +#endif /* _LINUX_LITEX_H */ > > -- > > 2.23.0 -- Mateusz Holenko Antmicro Ltd | www.antmicro.com Roosevelta 22, 60-829 Poznan, Poland