linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gabriel L. Somlo" <gsomlo@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Linux MMC List <linux-mmc@vger.kernel.org>,
	Karol Gugala <kgugala@antmicro.com>,
	Mateusz Holenko <mholenko@antmicro.com>,
	Kamil Rakoczy <krakoczy@antmicro.com>,
	mdudek@internships.antmicro.com,
	Paul Mackerras <paulus@ozlabs.org>, Joel Stanley <joel@jms.id.au>,
	Stafford Horne <shorne@gmail.com>,
	david.abdurachmanov@sifive.com,
	Florent Kermarrec <florent@enjoy-digital.fr>,
	Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v2 3/3] mmc: Add driver for LiteX's LiteSDCard interface
Date: Thu, 9 Dec 2021 15:58:04 -0500	[thread overview]
Message-ID: <YbJt3NLU9KPO+ERu@errol.ini.cmu.edu> (raw)
In-Reply-To: <CAMuHMdV6fttX6Jn06WJacNh+1pLz1RfYf82B2fB1D+=Kb9FmMA@mail.gmail.com>

On Thu, Dec 09, 2021 at 09:31:49AM +0100, Geert Uytterhoeven wrote:
> Hi Gabriel,
> 
> On Wed, Dec 8, 2021 at 9:14 PM Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > I did *some* of this for v3, but since figured out how to use `pahole` :)
> 
> Right, pahole.
> 
> > On Mon, Dec 06, 2021 at 11:07:56AM +0100, Geert Uytterhoeven wrote:
> > > > +struct litex_mmc_host {
> > > > +       struct mmc_host *mmc;
> > > > +       struct platform_device *dev;
> > > > +
> > > > +       void __iomem *sdphy;
> > > > +       void __iomem *sdcore;
> > > > +       void __iomem *sdreader;
> > > > +       void __iomem *sdwriter;
> > > > +       void __iomem *sdirq;
> > > > +
> > > > +       u32 resp[4];
> > > > +       u16 rca;
> > > > +
> > > > +       void *buffer;
> > > > +       size_t buf_size;
> > > > +       dma_addr_t dma;
> > > > +
> > > > +       unsigned int freq;
> > > > +       unsigned int clock;
> > > > +       bool is_bus_width_set;
> > > > +       bool app_cmd;
> > > > +
> > > > +       int irq;
> > > > +       struct completion cmd_done;
> > >
> > > You may want to reorder the members to avoid implicit gaps
> > > (i.e. structs first, followed by integral types in decreasing size).
> >
> > So, for v4, I'll have it looking like this, which `pahole` says is
> > optimally packed:
> >
> > struct litex_mmc_host {
> >         struct mmc_host *          mmc;                  /*     0     8 */
> >         struct platform_device *   dev;                  /*     8     8 */
> >         void *                     sdphy;                /*    16     8 */
> >         void *                     sdcore;               /*    24     8 */
> >         void *                     sdreader;             /*    32     8 */
> >         void *                     sdwriter;             /*    40     8 */
> >         void *                     sdirq;                /*    48     8 */
> >         void *                     buffer;               /*    56     8 */
> >         /* --- cacheline 1 boundary (64 bytes) --- */
> >         size_t                     buf_size;             /*    64     8 */
> 
> size_t is 32-bit on RV32, so you may want to move it below cmd_done.
> 
> >         dma_addr_t                 dma;                  /*    72     8 */
> >         struct completion          cmd_done;             /*    80    32 */
> >         int                        irq;                  /*   112     4 */
> >         unsigned int               ref_clk;              /*   116     4 */
> >         unsigned int               sd_clk;               /*   120     4 */
> >         u32                        resp[4];              /*   124    16 */
> >         /* --- cacheline 2 boundary (128 bytes) was 12 bytes ago --- */
> >         u16                        rca;                  /*   140     2 */
> >         bool                       is_bus_width_set;     /*   142     1 */
> >         bool                       app_cmd;              /*   143     1 */
> >
> >         /* size: 144, cachelines: 3, members: 18 */
> >         /* last cacheline: 16 bytes */
> > };

After a bit of a fight, I managed to wrestle `pahole` to display useful
information for 32-bit (rv32imac) builds:

struct litex_mmc_host {
	struct mmc_host *          mmc;                  /*     0     4 */
	struct platform_device *   dev;                  /*     4     4 */
	void *                     sdphy;                /*     8     4 */
	void *                     sdcore;               /*    12     4 */
	void *                     sdreader;             /*    16     4 */
	void *                     sdwriter;             /*    20     4 */
	void *                     sdirq;                /*    24     4 */
	void *                     buffer;               /*    28     4 */
	size_t                     buf_size;             /*    32     4 */
	dma_addr_t                 dma;                  /*    36     4 */
	struct completion          cmd_done;             /*    40    16 */
	int                        irq;                  /*    56     4 */
	unsigned int               ref_clk;              /*    60     4 */
	/* --- cacheline 1 boundary (64 bytes) --- */
	unsigned int               sd_clk;               /*    64     4 */
	u32                        resp[4];              /*    68    16 */
	u16                        rca;                  /*    84     2 */
	bool                       is_bus_width_set;     /*    86     1 */
	bool                       app_cmd;              /*    87     1 */

	/* size: 88, cachelines: 2, members: 18 */
	/* last cacheline: 24 bytes */
};

Looks like even with `size_t buf_size` where it is right now, there
still are no holes. I like it where it is, as it's related to the
field immediately preceding it (`buffer`). I'd rather not move it,
particularly since we're not actually eliminating any additional
holes.

What do you think (i.e., is there a configuration where there's still
a chance we may run into trouble)?

Thanks,
--Gabriel

  reply	other threads:[~2021-12-09 20:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-04 20:41 [PATCH v2 0/3] mmc: Add LiteSDCard mmc driver Gabriel Somlo
2021-12-04 20:41 ` [PATCH v2 1/3] MAINTAINERS: co-maintain LiteX platform Gabriel Somlo
2021-12-06 23:59   ` Joel Stanley
2021-12-07 22:11     ` Gabriel L. Somlo
2021-12-04 20:41 ` [PATCH v2 2/3] dt-bindings: mmc: Add bindings for LiteSDCard Gabriel Somlo
2021-12-06  9:39   ` Geert Uytterhoeven
2021-12-06 10:18   ` Geert Uytterhoeven
2021-12-06 15:36     ` Gabriel L. Somlo
2021-12-06 15:44       ` Geert Uytterhoeven
2021-12-04 20:41 ` [PATCH v2 3/3] mmc: Add driver for LiteX's LiteSDCard interface Gabriel Somlo
2021-12-04 20:57   ` Randy Dunlap
2021-12-05  1:37     ` Gabriel L. Somlo
2021-12-06 10:07   ` Geert Uytterhoeven
2021-12-06 18:40     ` Gabriel L. Somlo
2021-12-08 20:14     ` Gabriel L. Somlo
2021-12-09  8:31       ` Geert Uytterhoeven
2021-12-09 20:58         ` Gabriel L. Somlo [this message]
2021-12-10  8:04           ` Geert Uytterhoeven
2021-12-06 12:24   ` Geert Uytterhoeven
2021-12-07 14:10     ` Gabriel L. Somlo
2021-12-07 14:16       ` Geert Uytterhoeven
2021-12-07 21:30         ` Gabriel L. Somlo
2021-12-08  9:35           ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbJt3NLU9KPO+ERu@errol.ini.cmu.edu \
    --to=gsomlo@gmail.com \
    --cc=david.abdurachmanov@sifive.com \
    --cc=devicetree@vger.kernel.org \
    --cc=florent@enjoy-digital.fr \
    --cc=geert@linux-m68k.org \
    --cc=joel@jms.id.au \
    --cc=kgugala@antmicro.com \
    --cc=krakoczy@antmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mdudek@internships.antmicro.com \
    --cc=mholenko@antmicro.com \
    --cc=paulus@ozlabs.org \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=shorne@gmail.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).