[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEqHmAv+KTrJdiTL=76taTmu5YLYjukEiqk9UPbqCc-fDpQASw@mail.gmail.com>
Date: Fri, 4 May 2012 13:40:18 +0200
From: dd diasemi <dd.diasemi@...il.com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: linux-kernel@...r.kernel.org,
Anthony Olech <Anthony.Olech@...semi.com>
Subject: Re: Linux 3.4-rc2 register mapping and paging on I2C device.
On Fri, May 4, 2012 at 12:33 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
>
>> Below you can find my proposition of API for regmap paging support. It
>> is sufficient for my driver needs.
>> If you are OK with this proposition or you find any issues with it, let me know.
>
> Please submit an actual patch, this needs to be supported by things like
> the cache infrastructure as well. One thing that's not obvious with
> just this is how things like register defaults and iterating all the
> known registers will work.
>
>> +config REGMAP_PAGING
>> + bool
>
> No, this needs to work with both paged and non-paged devices.
Proposed implementation will extend virtually register range by number
of bits defined in .page_bits.
For example, for SPI register range 0 - 0x7F and 4 pages, we have
.page_bits = 2 and we define register mapping for range 0 - 0x1FF.
If .page_bits is not set and equal to 0, register range is going to be
defined as 0 - 0x7F and register mapping will work standard
(unchanged) way.
I plan to manage paging after caching and before actual address
formatting and bus write. The intention is to make register paging
transparent to regmap user and therefore it should cover situation,
when page boundaries are crossed by bulk read / write.
Proposed config flag - REGMAP_PAGING is here only to optimize kernel
compilation in case, when no drivers actually uses paging feature.
If you are asking about the details, I guess, comments may need to
improvement anyway to give a clearer view, how the API could be used,
right?
Kind Regards,
Krystian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists