[03/13] mpc52xx: add SCLPC register bit definitions

Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
---
 arch/powerpc/include/asm/mpc52xx.h |   40 +++++++++++++++++++++++++++--------
 1 files changed, 31 insertions(+), 9 deletions(-)

On Tue, Dec 22, 2009 at 12:00 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
>

This should probably be merged with the first patch to actually use
the bit definitions.  More comments below.

> Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
> ---
>  arch/powerpc/include/asm/mpc52xx.h |   40 +++++++++++++++++++++++++++--------
>  1 files changed, 31 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc52xx.h b/arch/powerpc/include/asm/mpc52xx.h
> index 57f8335..c659d1d 100644
> --- a/arch/powerpc/include/asm/mpc52xx.h
> +++ b/arch/powerpc/include/asm/mpc52xx.h
> @@ -17,6 +17,7 @@
>  #include <asm/types.h>
>  #include <asm/prom.h>
>  #include <asm/mpc5xxx.h>
> +#include <linux/bitops.h>
>  #endif /* __ASSEMBLY__ */
>
>  #include <linux/suspend.h>
> @@ -212,11 +213,34 @@ struct mpc52xx_sclpc {
>
>        u32 fifo_data;          /* 0x40 FIFO data word register */
>        u32 fifo_status;        /* 0x44 FIFO status register */
> -       u8 fifo_control;        /* 0x48 FIFO control register */
> -       u8 reserved2[3];
> +       u32 fifo_control;       /* 0x48 FIFO control register */
>        u32 fifo_alarm;         /* 0x4C FIFO alarm register */
>  };
>
> +#define MPC52xx_SCLPC_FIFO_SIZE                        (0x200)         /* FIFO size 512 bytes */
> +
> +#define MPC52xx_SCLPC_CONTROL_CS(cs)           ((uint32_t)(cs) << 24)  /* CSX bits */
> +#define MPC52xx_SCLPC_CONTROL_FLUSH            BIT(17)         /* flush, used in last packet  */
> +#define MPC52xx_SCLPC_CONTROL_RWB_RECEIVE      BIT(16)         /* RWb bit, 1 = receive */
> +#define MPC52xx_SCLPC_CONTROL_DAI              BIT(8)
> +
> +#define MPC52xx_SCLPC_ENABLE_RC                        BIT(24)         /* reset controller bit */
> +#define MPC52xx_SCLPC_ENABLE_RF                        BIT(16)         /* reset FIFO bit */
> +#define MPC52xx_SCLPC_ENABLE_AIE               BIT(9)          /* abort interrupt enable bit */
> +#define MPC52xx_SCLPC_ENABLE_NIE               BIT(8)          /* normal interrupt enable bit */
> +#define MPC52xx_SCLPC_ENABLE_ME                        BIT(0)          /* master enable bit */
> +
> +#define MPC52xx_SCLPC_PACKET_SIZE_RESTART      BIT(24)
> +
> +#define MPC52xx_SCLPC_STATUS_AT                        BIT(28)         /* abort termination */
> +#define MPC52xx_SCLPC_STATUS_NT                        BIT(24)         /* normal termination */
> +#define MPC52xx_SCLPC_STATUS_BYTES_DONE_MASK   (0x00FFFFFFU)   /* bytes done bit mask */
> +
> +#define MPC52xx_SLPC_FIFO_STATUS_ERR           BIT(22) /* error bit */
> +
> +#define MPC52xx_SLPC_FIFO_CONTROL_GR(gr)       ((gr) << 24)    /* granularity bits */
> +
> +
>  /* Clock Distribution control */
>  struct mpc52xx_cdm {
>        u32 jtag_id;            /* CDM + 0x00  reg0 read only */
> @@ -304,19 +328,18 @@ extern void mpc52xx_restart(char *cmd);
>  struct mpc52xx_gpt_priv;
>  extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
>  extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, u64 period,
> -                            int continuous);
> +                                  int continuous);

Unrelated whitespace change?

>  extern u64 mpc52xx_gpt_timer_period(struct mpc52xx_gpt_priv *gpt);
>  extern int mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
>
>  /* mpc52xx_lpbfifo.c */
>  #define MPC52XX_LPBFIFO_FLAG_READ              (0)
> -#define MPC52XX_LPBFIFO_FLAG_WRITE             (1<<0)
> -#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT      (1<<1)
> -#define MPC52XX_LPBFIFO_FLAG_NO_DMA            (1<<2)
> -#define MPC52XX_LPBFIFO_FLAG_POLL_DMA          (1<<3)
> +#define MPC52XX_LPBFIFO_FLAG_WRITE             BIT(0)
> +#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT      BIT(1)
> +#define MPC52XX_LPBFIFO_FLAG_NO_DMA            BIT(2)
> +#define MPC52XX_LPBFIFO_FLAG_POLL_DMA          BIT(3)

I prefer the (1<<n) style myself.

>
>  struct mpc52xx_lpbfifo_request {
> -       struct list_head list;

Why is the list head being removed?

g.

Dear Grant Likely,

In message <fa686aa41001111121u5c943fc7p789c0ec0b41af883@mail.gmail.com> you wrote:
>
> >  /* mpc52xx_lpbfifo.c */
> >  #define MPC52XX_LPBFIFO_FLAG_READ              (0)
> > -#define MPC52XX_LPBFIFO_FLAG_WRITE             (1<<0)
> > -#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT      (1<<1)
> > -#define MPC52XX_LPBFIFO_FLAG_NO_DMA            (1<<2)
> > -#define MPC52XX_LPBFIFO_FLAG_POLL_DMA          (1<<3)
> > +#define MPC52XX_LPBFIFO_FLAG_WRITE             BIT(0)
> > +#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT      BIT(1)
> > +#define MPC52XX_LPBFIFO_FLAG_NO_DMA            BIT(2)
> > +#define MPC52XX_LPBFIFO_FLAG_POLL_DMA          BIT(3)
> 
> I prefer the (1<<n) style myself.

Indeed, especially as one can argue that "(1<<0)" should be "BIT(31)"
on Power Architecture systems, where bit 0 is the MSB by definition.

Best regards,

Wolfgang Denk

Hello Grant,

On Monday 11 January 2010 20:21:22 Grant Likely wrote:

> Unrelated whitespace change?

My fault, as with some other white space changes. My Emacs is
configured using some older setup found in a 2.4
Documentation/CodingStyle. Before saving a file my spine is used to
reformat the whole source file, which then causes those artefacts.
I'll fix the Emacs setup and try to fix my spine, and double check
before commits.

BTW: no Emacs users amongst the kernel coders any more? At least I
have to read "So, you can either get rid of GNU emacs, or ...".


> I prefer the (1<<n) style myself.

Ok. Looking at it a second time you and Wolfgang are definitively
right. And I prefer the (1<<n) style a lot more than the 0x0080 style.


> Why is the list head being removed?

Not used at all, except in initialization?

Of course a seperate patch would have been needed.


Roman

On Tue, Jan 12, 2010 at 12:55 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> Hello Grant,
>
> On Monday 11 January 2010 20:21:22 Grant Likely wrote:
>
>> Unrelated whitespace change?
>
> My fault, as with some other white space changes. My Emacs is
> configured using some older setup found in a 2.4
> Documentation/CodingStyle. Before saving a file my spine is used to
> reformat the whole source file, which then causes those artefacts.
> I'll fix the Emacs setup and try to fix my spine, and double check
> before commits.
>
> BTW: no Emacs users amongst the kernel coders any more? At least I
> have to read "So, you can either get rid of GNU emacs, or ...".

I believe there are lots of emacs using kernel hackers.  emacs is fine
and most of the style changes you were making were valid, but they
were unrelated and unimportant.  Unless emacs is making automatic
changes to the files, it sounds like your emacs config is just fine.

g.

On Tue, Jan 12, 2010 at 12:55 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> On Monday 11 January 2010 20:21:22 Grant Likely wrote:
>> Why is the list head being removed?
>
> Not used at all, except in initialization?
>
> Of course a seperate patch would have been needed.

For the record, I put the list_head in when writing the driver so that
requests can get queued up instead of the one-at-a-time model
currently used.  It is still my intention to implement request queuing
but as with so many things I haven't got to it yet.  :-/

g.