Using IO functions across ARM, PPC and Microblaze architectures

Using IO functions across ARM, PPC and Microblaze architectures

[Michal Simek]

Hi,

I would like to get some advices what correct coding style is.

I have one problem with some drivers (uartlite for example)
which are shared across three architectures arm, powerpc and microblaze.

Because I need to use IO functions which will behave
on arm as little endian and on powerpc as big endian
and on microblaze depends on endian setting.
I haven't found any IO function which I could use by 3 architectures
without using preprocessor macros or runtime detection

Please correct me if there is any standard IO function which I could use
for this case.

I was looking at.
readl - make no sense on PowerPC because I need big endian and it is
little there
ioread - is little endian on PPC(ioreadXXbe is big endain)
ioreadXXbe - is always big endian
in_be/in_le - is the same option as ioread/writebe

Using __raw_readl function should be also problematic on ARM
because doesn't prevent reordering or partial accesses.


It means that I should use helper function.

1. Using helper function + preprocessor macros
(using static inline function also possible)

#ifdef __LITTLE_ENDIAN
# define driver_read ioread32
#else
# define driver_read ioread32be
#endif

fce() {
      u32 val = driver_read(..);
}

2. Using function pointers
a) initialization based on preprocesor macros

fce() {
      u32 val;

#ifdef __LITTLE_ENDIAN
      dev_data->read_fn = ioread32
#else
      dev_data->read_fn = ioread32be
#endif

      val = dev_data->read_fn(..);
}

b) Runtime initialization - here is the question if there is
any standard function which I could use.

fce() {
	int num = 1;
	/* run time endian detection */	
	if (*(char *)&num == 1) {
		dev_data->read_fn = ioread32
	else
		dev_data->read_fn = ioread32be

	val = dev_data->read_fn(..);
}

Can you recommend me the best way I should use?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: Using IO functions across ARM, PPC and Microblaze architectures

[Alan Cox]

> Because I need to use IO functions which will behave
> on arm as little endian and on powerpc as big endian
> and on microblaze depends on endian setting.
> I haven't found any IO function which I could use by 3 architectures
> without using preprocessor macros or runtime detection

Its a rather weird mix. We can do "always big" and "always little"

> 1. Using helper function + preprocessor macros
> (using static inline function also possible)

Then someone comes along and sticks a daughterboard into the system with
the same device the other way around and there are years

> 2. Using function pointers

Probably smarter. 8250.c works this way and it has to handle some
extremely bizarre mappings.
 
> b) Runtime initialization - here is the question if there is
> any standard function which I could use.

Set the pointers up and pass them as data with your platform device, that
way the function definitions are buried in your platform code where they
depend.

Alan

Re: Using IO functions across ARM, PPC and Microblaze architectures

[Geert Uytterhoeven]

On Fri, Dec 7, 2012 at 10:16 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Because I need to use IO functions which will behave
>> on arm as little endian and on powerpc as big endian
>> and on microblaze depends on endian setting.
>> I haven't found any IO function which I could use by 3 architectures
>> without using preprocessor macros or runtime detection
>
> Its a rather weird mix. We can do "always big" and "always little"
>
>> 1. Using helper function + preprocessor macros
>> (using static inline function also possible)
>
> Then someone comes along and sticks a daughterboard into the system with
> the same device the other way around and there are years
>
>> 2. Using function pointers
>
> Probably smarter. 8250.c works this way and it has to handle some
> extremely bizarre mappings.
>
>> b) Runtime initialization - here is the question if there is
>> any standard function which I could use.
>
> Set the pointers up and pass them as data with your platform device, that
> way the function definitions are buried in your platform code where they
> depend.

Or embed a struct io_ops * in struct device, to be set up by the bus driver?

Wasn't David Hinds working on something like this in the context of PCMCIA
a few decades ago?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Using IO functions across ARM, PPC and Microblaze architectures

[Michal Simek]

On 12/08/2012 11:57 AM, Geert Uytterhoeven wrote:
> On Fri, Dec 7, 2012 at 10:16 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> Because I need to use IO functions which will behave
>>> on arm as little endian and on powerpc as big endian
>>> and on microblaze depends on endian setting.
>>> I haven't found any IO function which I could use by 3 architectures
>>> without using preprocessor macros or runtime detection
>>
>> Its a rather weird mix. We can do "always big" and "always little"
>>
>>> 1. Using helper function + preprocessor macros
>>> (using static inline function also possible)
>>
>> Then someone comes along and sticks a daughterboard into the system with
>> the same device the other way around and there are years
>>
>>> 2. Using function pointers
>>
>> Probably smarter. 8250.c works this way and it has to handle some
>> extremely bizarre mappings.
>>
>>> b) Runtime initialization - here is the question if there is
>>> any standard function which I could use.
>>
>> Set the pointers up and pass them as data with your platform device, that
>> way the function definitions are buried in your platform code where they
>> depend.
>
> Or embed a struct io_ops * in struct device, to be set up by the bus driver?
>
> Wasn't David Hinds working on something like this in the context of PCMCIA
> a few decades ago?


Do you have any link on that?

Thanks,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian