Re: xsysace driver support on arches other than PPC/Microblaze

From: Alexey Brodkin
Date: Wed Jun 19 2013 - 08:57:28 EST


On 06/19/2013 04:13 PM, Andy Shevchenko wrote:
> On Wed, Jun 19, 2013 at 11:56 AM, Alexey Brodkin
> <Alexey.Brodkin@xxxxxxxxxxxx> wrote:
[]
> If you have a way to detect endianess run-time then you have to
> introduce kinda ops structure
>
> struct access {
> .read = read_func(),
> .write = write_func(),
> };
>
> ops_le = {...};
> ops_be = {...};
>
> And provide a pointer to the chosen structure.
>
> If there no posibility to get it run-time, use kernel config option.
>
> I wonder if there is any "modern" way to do such things.

Andy, if I understand your idea correctly then this kind of
functionality is already there.

============
static struct ace_reg_ops ace_reg_be16_ops = {
.in = ace_in_be16,
.out = ace_out_be16,
.datain = ace_datain_be16,
.dataout = ace_dataout_be16,
};

static struct ace_reg_ops ace_reg_le16_ops = {
.in = ace_in_le16,
.out = ace_out_le16,
.datain = ace_datain_le16,
.dataout = ace_dataout_le16,
};
============
And in run-time we select which one to use. So no problem here.

The problem I'm facing there is a bit more complex.

Please refer to an extract below:
============
static void ace_out_be16(struct ace_device *ace, int reg, u16 val)
{
out_be16(ace->baseaddr + reg, val);
}

static void ace_dataout_be16(struct ace_device *ace)
{
int i = ACE_FIFO_SIZE / 2;
u16 *src = ace->data_ptr;
while (i--)
out_le16(ace->baseaddr + 0x40, *src++);
ace->data_ptr = src;
}
============

From it you may see that one high-level big-endian accessor
("ace_out_be16") uses big-endian low-level accessor ("out_be16") while
another high-level big-endian accessor ("ace_dataout_be16") uses
little-endian low-level accessor ("out_be16").

It seems like access to 16-bit data words should be done always with LE
accessors (after all it's always just a window to a device's memory).

-Alexey




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/