> >
> > So xxx_p is for pause (or something like that).
> > This also matches that m68k do some tricks with delay() in the _p variants.
> > Thanks for the explanation.
>
> m68k's isa_delay() uses the same approach as x86's slow_down_io(),
> but only for Q40/Q60, which has a "real" ISA bus that acc
On Sat, Jul 19, 2014 at 11:11 AM, Sam Ravnborg wrote:
> On Sat, Jul 19, 2014 at 11:05:33AM +0200, Arnd Bergmann wrote:
>> On Saturday 19 July 2014 10:41:52 Sam Ravnborg wrote:
>> > > >
>> > > > This set:
>> > > > #define inb_p(addr) inb(addr)
>> > > > #define inw_p(addr) inw(addr)
>> > > >
On Sat, 2014-07-19 at 11:11 +0200, Sam Ravnborg wrote:
> On Sat, Jul 19, 2014 at 11:05:33AM +0200, Arnd Bergmann wrote:
> > On Saturday 19 July 2014 10:41:52 Sam Ravnborg wrote:
> > > > >
> > > > > This set:
> > > > > #define inb_p(addr) inb(addr)
> > > > > #define inw_p(addr) inw(addr)
>
On Sat, Jul 19, 2014 at 11:05:33AM +0200, Arnd Bergmann wrote:
> On Saturday 19 July 2014 10:41:52 Sam Ravnborg wrote:
> > > >
> > > > This set:
> > > > #define inb_p(addr) inb(addr)
> > > > #define inw_p(addr) inw(addr)
> > > > #define inl_p(addr) inl(addr)
> > > > #define outb_p(x, a
On Saturday 19 July 2014 10:53:38 Sam Ravnborg wrote:
>
> Then there are the other type where one IO access function
> may re-use the implementation of another IO access function:
>
> #ifndef writeb
> #define writeb __raw_writeb
> #endif
>
> This could have been implmented like this:
On Saturday 19 July 2014 10:41:52 Sam Ravnborg wrote:
> > >
> > > This set:
> > > #define inb_p(addr) inb(addr)
> > > #define inw_p(addr) inw(addr)
> > > #define inl_p(addr) inl(addr)
> > > #define outb_p(x, addr) outb((x), (addr))
> > > #define outw_p(x, addr) outw((x), (addr))
> > >
> > A semi related question.
> > Why do we play all these macro tricks in io.h?
> >
> > Example:
> >
> > #define writeb __raw_writeb
> >
> > The consensus these days is to use static inline to have the
> > correct prototype but this file is contains a lot of these
> > macro conversions.
> >
> >
> > This set:
> > #define inb_p(addr) inb(addr)
> > #define inw_p(addr) inw(addr)
> > #define inl_p(addr) inl(addr)
> > #define outb_p(x, addr) outb((x), (addr))
> > #define outw_p(x, addr) outw((x), (addr))
> > #define outl_p(x, addr) outl((x), (addr))
> >
> > Should have a comme
On Friday 18 July 2014 22:59:53 Sam Ravnborg wrote:
> On Wed, Jul 16, 2014 at 01:01:22PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Currently driver writers need to use io{read,write}{8,16,32}_rep() when
> > accessing FIFO registers portably. This is bad for two reasons: it is
On Friday 18 July 2014 23:06:31 Sam Ravnborg wrote:
> >
> > All these things are not introduced by your patch but now that
> > you show some love and care for this file maybe we could take
> > the next step and bring more order to the current semi chaos?
>
> And I just noticed...
>
> These are n
>
> All these things are not introduced by your patch but now that
> you show some love and care for this file maybe we could take
> the next step and bring more order to the current semi chaos?
And I just noticed...
These are never used - and only defined a few places:
#define inb_p(addr) i
On Wed, Jul 16, 2014 at 01:01:22PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Currently driver writers need to use io{read,write}{8,16,32}_rep() when
> accessing FIFO registers portably. This is bad for two reasons: it is
> inconsistent with how other registers are accessed using the
On Wed, Jul 16, 2014 at 12:01:22PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Currently driver writers need to use io{read,write}{8,16,32}_rep() when
> accessing FIFO registers portably. This is bad for two reasons: it is
> inconsistent with how other registers are accessed using the
13 matches
Mail list logo