[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200612115202.GD5396@sirena.org.uk>
Date: Fri, 12 Jun 2020 12:52:02 +0100
From: Mark Brown <broonie@...nel.org>
To: Xu Yilun <yilun.xu@...el.com>
Cc: linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
trix@...hat.com, hao.wu@...el.com, matthew.gerlach@...ux.intel.com,
russell.h.weight@...el.com
Subject: Re: [PATCH 4/6] spi: altera: use regmap instead of direct mmio
register access
On Fri, Jun 12, 2020 at 12:43:46PM +0800, Xu Yilun wrote:
> So we think of creating regmap to abstract the actually register accessing
> detail. The parent device driver creates the regmap of indirect access,
> and it creates the spi-altera platform device as child. Spi-altera
> driver could just get the regmap from parent, don't have to care about
> the indirect access detail.
To be clear there's absolutely no problem with the end result, my
concern is the way that we're getting there.
> It seems your concern is how to gracefully let spi-altera driver get the
> regmap. or not using it. Since our platform doesn't enable device tree
> support, seems the only way to talk to platform device is the
> platform_data.
No, the problem is with how that platform data is structured. Based on
what you're saying I'd suggest adding another device ID for this - you
can use the id_table field in struct platform_driver to have more than
one ID like you can have more than one ACPI ID or OF compatible. That
would mirror how this would be handled if things were enumerated through
firmware.
> I think the driver may need to figure out the role of the device in
> system, whether it is a subdev of other device (like MFD? Many mfd subdev
> driver will get parent regmap by default), or it is an independent mmio
> device. But I'm not sure how to do it in right way.
Yes, it sounds like this card is a MFD.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists