[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250918145644-GYC1274501@gentoo.org>
Date: Thu, 18 Sep 2025 22:56:44 +0800
From: Yixun Lan <dlan@...too.org>
To: Alex Elder <elder@...cstar.com>
Cc: broonie@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, linux-spi@...r.kernel.org,
devicetree@...r.kernel.org, paul.walmsley@...ive.com,
palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
p.zabel@...gutronix.de, spacemit@...ts.linux.dev,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] spi: spacemit: introduce SpacemiT K1 SPI controller
driver
Hi Alex,
On 09:47 Thu 18 Sep , Alex Elder wrote:
> On 9/18/25 9:39 AM, Yixun Lan wrote:
> >>>> + u32 data_reg_addr; /* DMA address of the data register */
> >>> s/data_reg_addr/ssp_data/? I just feel uncomfortable with redundant 'reg_addr'
> >> My convention is normally "virt" or maybe "base" to represent
> >> a virtual address, and "addr" to represent I/O addresses.
> >>
> >> This symbol represents the physical address that underlies the
> >> "SSP Data Register", which fills the TX FIFO when written and
> >> drains the RX FIFO when read.
> >>
> >> How about "data_addr"? I know you wouldn't like "reg_addr".
> >>
> > another idea here, instead of introducing a variable here,
> > how about simply using plain iores->start + SSP_DATAR?
> >
> > so you can cache "iores" instead..
>
> This code has gone through a huge amount of refactoring.
>
> I hadn't looked, but now I see this field is used exactly one
> place in the code, in k1_spi_prepare_dma_io(). It's still
> needed though.
>
> Here's what I plan to do. Rather than saving data_reg_addr,
> I will simply save base_addr, which is the I/O resource start
> address that corresponds to the mapped virtual pointer, "base".
>
> Then in k1_spi_prepare_dma_io() I'll use base_addr + SSP_DATAR.
>
> OK?
>
Yes, this is what I'm suggesting
--
Yixun Lan (dlan)
Powered by blists - more mailing lists