On Wed, Sep 16, 2020 at 06:05:52PM +0200, Ricardo Ribalda wrote:
> From: Ricardo Ribalda <[email protected]>
>
> Devices such as the AD5628 require 32 bits of data divided in 12 bits
> for dummy, command and address, and 20 for data and dummy.
What exactly is the format you're trying to describe here? It sounds
like there's two blocks of padding in here (I'm assuing that's what
dummy means) but what's the exact arrangement here and what are the
commands? It sounds like this might not work ideally with things like
the cache code (if it makes things seems sparser than they are) and
might not be obvious to someone looking at the datsheet.
Hi Mark
On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <[email protected]> wrote:
>
> On Wed, Sep 16, 2020 at 06:05:52PM +0200, Ricardo Ribalda wrote:
> > From: Ricardo Ribalda <[email protected]>
> >
> > Devices such as the AD5628 require 32 bits of data divided in 12 bits
> > for dummy, command and address, and 20 for data and dummy.
>
> What exactly is the format you're trying to describe here? It sounds
> like there's two blocks of padding in here (I'm assuing that's what
> dummy means) but what's the exact arrangement here and what are the
> commands? It sounds like this might not work ideally with things like
> the cache code (if it makes things seems sparser than they are) and
> might not be obvious to someone looking at the datsheet.
The format is
XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
Where X is dont care, C is command, A is address and D is data bits. I
am using the following config successfully:
static const struct regmap_config config_dac = {
.reg_bits = 12,
.val_bits = 20,
.max_register = 0xff,
};
Shall I add this to the commit message? I want to send a V2 anyway,
because I screwed up the identity (ribalda.com instead of kernel.org)
Thanks
On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote:
> On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <[email protected]> wrote:
> > What exactly is the format you're trying to describe here? It sounds
> > like there's two blocks of padding in here (I'm assuing that's what
> > dummy means) but what's the exact arrangement here and what are the
> > commands? It sounds like this might not work ideally with things like
> > the cache code (if it makes things seems sparser than they are) and
> > might not be obvious to someone looking at the datsheet.
> The format is
> XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
> Where X is dont care, C is command, A is address and D is data bits. I
> Shall I add this to the commit message? I want to send a V2 anyway,
> because I screwed up the identity (ribalda.com instead of kernel.org)
Yes, please. I was fairly sure it worked, it was just a question of if
it was ideal for the format described. The only issue I can see with
the above is that the users will need to left shift their data - on the
face of it it would seem better to add a facility for padding the LSBs
of the data field to the core so that users can just use the data field
as documented.
HI Mark
On Thu, Sep 17, 2020 at 1:22 PM Mark Brown <[email protected]> wrote:
>
> On Thu, Sep 17, 2020 at 08:31:54AM +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Sep 16, 2020 at 6:29 PM Mark Brown <[email protected]> wrote:
>
> > > What exactly is the format you're trying to describe here? It sounds
> > > like there's two blocks of padding in here (I'm assuing that's what
> > > dummy means) but what's the exact arrangement here and what are the
> > > commands? It sounds like this might not work ideally with things like
> > > the cache code (if it makes things seems sparser than they are) and
> > > might not be obvious to someone looking at the datsheet.
>
> > The format is
>
> > XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
>
> > Where X is dont care, C is command, A is address and D is data bits. I
>
> > Shall I add this to the commit message? I want to send a V2 anyway,
> > because I screwed up the identity (ribalda.com instead of kernel.org)
>
> Yes, please. I was fairly sure it worked, it was just a question of if
> it was ideal for the format described. The only issue I can see with
> the above is that the users will need to left shift their data - on the
> face of it it would seem better to add a facility for padding the LSBs
> of the data field to the core so that users can just use the data field
> as documented.
I was thinking also about that, the problem is that there are many
devices on that family that are "software" compatible and it only
changes the width of the data. Eg:
DDDDDDDDDDDDDDDDXXXX
DDDDDDDDDDDDXXXXXXXX
DDDDDDDDXXXXXXXXXXXX
So if we need to make a driver, we could use the same driver for all
the chips on that family, saying to the user that the data size is
always 20 bits....
I will send v2 ASAP with the updated doc.
Thanks