xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: vijay.kilari@gmail.com
Cc: Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Prasun.Kapoor@caviumnetworks.com,
	vijaya.kumar@caviumnetworks.com, xen-devel@lists.xen.org,
	stefano.stabellini@citrix.com
Subject: Re: [PATCH v2 05/15] xen/arm: segregate GIC low level functionality
Date: Fri, 04 Apr 2014 14:55:16 +0100	[thread overview]
Message-ID: <533EB9C4.3020709@linaro.org> (raw)
In-Reply-To: <1396612593-443-6-git-send-email-vijay.kilari@gmail.com>

Hi Vijaya,

Thank you for the patch.

On 04/04/2014 12:56 PM, vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> GIC low level functionality is segregated into
> separate functions and are called using registered
> callback wherever required.
> 
> This helps to separate generic and hardware functionality
> later

Honestly, your patch on V1 was far better to read. As you are nearly
modify every functions, you should directly move it to a new file (e.g
merge with patch #9).

> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> ---
>  xen/arch/arm/gic.c                |  362 ++++++++++++++++++++++++++++---------
>  xen/include/asm-arm/gic.h         |   50 +++++
>  xen/include/asm-arm/gic_v2_defs.h |   16 +-
>  3 files changed, 328 insertions(+), 100 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 64699e4..9f03135 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -57,8 +57,21 @@ static irq_desc_t irq_desc[NR_IRQS];
>  static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
>  static DEFINE_PER_CPU(uint64_t, lr_mask);
>  
> +static struct gic_hw_operations *gic_hw_ops;
> +static struct gic_hw_operations gic_ops;
> +
> +void register_gic_ops(struct gic_hw_operations *ops)

the callback should not change during runtime. Should the prototype
should be:

void register_gic_ops(const struct gic_hw_operations *ops);

> +{
> +    gic_hw_ops = ops;
> +}
> +
> +void update_cpu_lr_mask(void)
> +{
> +    this_cpu(lr_mask) = 0ULL;
> +}
> +
>  static uint8_t nr_lrs;
> -#define lr_all_full() (this_cpu(lr_mask) == ((1 << nr_lrs) - 1))
> +#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->nr_lrs()) - 1))
>  
>  /* The GIC mapping of CPU interfaces does not necessarily match the
>   * logical CPU numbering. Let's use mapping as returned by the GIC
> @@ -89,48 +102,124 @@ static unsigned int gic_cpu_mask(const cpumask_t *cpumask)
>  
>  unsigned int gic_number_lines(void)
>  {
> +    return gic_hw_ops->nr_lines();
> +}
> +
> +static unsigned int gic_nr_lines(void)
> +{
>      return gic.lines;
>  }

If you had directly move the code to another files you would avoid this
kind of non sense name...

>  
> -irq_desc_t *__irq_to_desc(int irq)
> +static unsigned int gic_nr_lrs(void)
>  {
> -    if (irq < NR_LOCAL_IRQS) return &this_cpu(local_irq_desc)[irq];
> -    return &irq_desc[irq-NR_LOCAL_IRQS];

Why did you had to modify __irq_to_desc?

> +    return nr_lrs;
>  }
>  
> -void gic_save_state(struct vcpu *v)
> +static int gic_state_init(struct vcpu *v)
> +{
> +     v->arch.gic_state = xzalloc(struct gic_state_data);
> +     if(!v->arch.gic_state)

if ( !v->arch.gic_state )

> +        return -ENOMEM;
> +     return 0;
> +}
> +
> +static void save_state(struct vcpu *v)
>  {
>      int i;
> -    ASSERT(!local_irq_is_enabled());
>  
>      /* No need for spinlocks here because interrupts are disabled around
>       * this call and it only accesses struct vcpu fields that cannot be
>       * accessed simultaneously by another pCPU.
>       */
> -    for ( i = 0; i < nr_lrs; i++ )
> +    for ( i = 0; i < nr_lrs; i++)

Spurious change

[..]

> @@ -129,6 +149,36 @@ int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
>                    unsigned int *out_hwirq, unsigned int *out_type);
>  void gic_clear_lrs(struct vcpu *v);
>  
> +struct gic_hw_operations {

I made some remarks on v1, that you completely forgot to address on this
structure.

Can you document every callbacks (see asm-arm/platform.h for an
example)? Why do you need them...

> +    struct dt_irq * (*get_maintenance_irq)(void);

With my interrupts patch series dt_irq will be removed soon.

> +    unsigned int (*nr_lines)(void);
> +    unsigned int (*nr_lrs)(void);

I don't think we need a callbacks for both of them. 2 unsigned int are fine.

[..]

> +    void (*enable_irq)(int);
> +    void (*disable_irq)(int);
> +    void (*eoi_irq)(int);
> +    void (*deactivate_irq)(int);
> +    unsigned int (*ack_irq)(void);

I would prefer to introduce a new hw_irq_controller here rather than
adding another abstraction.

> +    void (*set_irq_property)(unsigned int irq, bool_t level,
> +                            const cpumask_t *cpu_mask,
> +                            unsigned int priority);

I would rename the function into set_irq_properties.

[..]

> diff --git a/xen/include/asm-arm/gic_v2_defs.h b/xen/include/asm-arm/gic_v2_defs.h
> index f9ff885..e1bb09c 100644
> --- a/xen/include/asm-arm/gic_v2_defs.h
> +++ b/xen/include/asm-arm/gic_v2_defs.h
> @@ -93,15 +93,6 @@
>  #define GICC_IA_CPU_MASK  0x1c00
>  #define GICC_IA_CPU_SHIFT 10
>  
> -#define GICH_HCR_EN       (1 << 0)
> -#define GICH_HCR_UIE      (1 << 1)
> -#define GICH_HCR_LRENPIE  (1 << 2)
> -#define GICH_HCR_NPIE     (1 << 3)
> -#define GICH_HCR_VGRP0EIE (1 << 4)
> -#define GICH_HCR_VGRP0DIE (1 << 5)
> -#define GICH_HCR_VGRP1EIE (1 << 6)
> -#define GICH_HCR_VGRP1DIE (1 << 7)
> -
>  #define GICH_MISR_EOI     (1 << 0)
>  #define GICH_MISR_U       (1 << 1)
>  #define GICH_MISR_LRENP   (1 << 2)
> @@ -118,9 +109,12 @@
>  #define GICH_LR_STATE_MASK      0x3
>  #define GICH_LR_STATE_SHIFT     28
>  #define GICH_LR_PRIORITY_SHIFT  23
> +#define GICH_LR_PRIORITY_MASK   0x1f
> +#define GICH_LR_HW_SHIFT        31
> +#define GICH_LR_HW_MASK         0x1
> +#define GICH_LR_GRP_SHIFT       30
> +#define GICH_LR_GRP_MASK        0x1
>  #define GICH_LR_MAINTENANCE_IRQ (1<<19)
> -#define GICH_LR_PENDING         (1<<28)
> -#define GICH_LR_ACTIVE          (1<<29)
>  #define GICH_LR_GRP1            (1<<30)
>  #define GICH_LR_HW              (1<<31)
>  #define GICH_LR_CPUID_SHIFT     9

Why did you move all theses define on gic_v2_defs.h, and move back to
gic.h again?

Regards,


-- 
Julien Grall

  reply	other threads:[~2014-04-04 13:55 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04 11:56 [PATCH v2 00/15] xen/arm: Add GICv3 support vijay.kilari
2014-04-04 11:56 ` [PATCH v2 01/15] xen/arm: register mmio handler at runtime vijay.kilari
2014-04-04 12:18   ` Julien Grall
2014-04-04 12:30     ` Vijay Kilari
2014-04-04 12:42       ` Ian Campbell
2014-04-04 12:54         ` Julien Grall
2014-04-04 12:59           ` Ian Campbell
2014-04-04 13:06             ` Julien Grall
2014-04-04 12:59       ` Julien Grall
2014-04-08  4:47         ` Vijay Kilari
2014-04-08 10:17           ` Julien Grall
2014-04-08 10:34             ` Vijay Kilari
2014-04-08 10:51               ` Julien Grall
2014-04-08 11:41                 ` Vijay Kilari
2014-04-08 12:29                   ` Ian Campbell
2014-04-04 15:24       ` Vijay Kilari
2014-04-04 15:27         ` Julien Grall
2014-04-08  6:35           ` Vijay Kilari
2014-04-08 10:25             ` Julien Grall
2014-04-09 15:34       ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 02/15] xen/arm: move vgic rank data to gic header file vijay.kilari
2014-04-04 13:16   ` Julien Grall
2014-04-04 15:27     ` Vijay Kilari
2014-04-04 11:56 ` [PATCH v2 03/15] arm/xen: move gic save and restore registers to gic driver vijay.kilari
2014-04-04 13:23   ` Julien Grall
2014-04-09 16:51   ` Ian Campbell
2014-04-10  4:50     ` Vijay Kilari
2014-04-10  8:32       ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 04/15] xen/arm: move gic definitions to seperate file vijay.kilari
2014-04-04 13:27   ` Julien Grall
2014-04-04 15:29     ` Vijay Kilari
2014-04-04 15:37       ` Julien Grall
2014-04-09 15:41       ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 05/15] xen/arm: segregate GIC low level functionality vijay.kilari
2014-04-04 13:55   ` Julien Grall [this message]
2014-04-09  7:43     ` Vijay Kilari
2014-04-09  8:36       ` Julien Grall
2014-04-09 15:55         ` Ian Campbell
2014-04-09 17:00     ` Ian Campbell
2014-04-09 17:07       ` Julien Grall
2014-04-10  5:24         ` Vijay Kilari
2014-04-10  8:59         ` Ian Campbell
2014-04-09  8:50   ` Julien Grall
2014-04-09 11:34     ` Vijay Kilari
2014-04-09 12:10       ` Julien Grall
2014-04-09 15:54   ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 06/15] xen/arm: move gic lock out of gic data structure vijay.kilari
2014-04-10  8:52   ` Ian Campbell
2014-04-10  9:24     ` Vijay Kilari
2014-04-10 10:02       ` Ian Campbell
2014-04-10 10:12         ` Vijay Kilari
2014-04-10 10:31           ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 07/15] xen/arm: split gic driver into generic and gic-v2 driver vijay.kilari
2014-04-10  8:58   ` Ian Campbell
2014-04-10  9:27     ` Vijay Kilari
2014-04-04 11:56 ` [PATCH v2 08/15] xen/arm: use device api to detect GIC version vijay.kilari
2014-04-04 14:07   ` Julien Grall
2014-04-09 14:28     ` Vijay Kilari
2014-04-09 14:32       ` Julien Grall
2014-04-10  9:05         ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 09/15] xen/arm: segregate VGIC low level functionality vijay.kilari
2014-04-04 14:13   ` Julien Grall
2014-04-10  9:08     ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 10/15] xen/arm: split vgic driver into generic and vgic-v2 driver vijay.kilari
2014-04-10  9:12   ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 11/15] xen/arm: make GIC context data version specific vijay.kilari
2014-04-04 14:09   ` Julien Grall
2014-04-10  9:14     ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 12/15] xen/arm: move GIC data to driver from domain structure vijay.kilari
2014-04-10  9:21   ` Ian Campbell
2014-04-04 11:56 ` [PATCH v2 13/15] xen/arm: Add support for GIC v3 vijay.kilari
2014-04-10  9:25   ` Ian Campbell
2014-04-10 10:00   ` Ian Campbell
2014-04-10 10:34     ` Julien Grall
2014-04-10 11:06       ` Vijay Kilari
2014-04-10 11:21         ` Julien Grall
2014-04-10 11:24     ` Julien Grall
2014-04-11 12:59     ` Vijay Kilari
2014-04-14  8:27       ` Ian Campbell
2014-04-14  9:52         ` Vijay Kilari
2014-04-04 11:56 ` [PATCH v2 14/15] xen/arm: Add vgic " vijay.kilari
2014-04-10 10:23   ` Ian Campbell
2014-04-10 10:43     ` Vijay Kilari
2014-04-10 10:51       ` Ian Campbell
2014-04-10 11:19         ` Vijay Kilari
2014-04-10 11:26           ` Ian Campbell
2014-04-10 11:38             ` Vijay Kilari
2014-04-10 12:08               ` Ian Campbell
2014-04-10 13:14                 ` Vijay Kilari
2014-04-04 11:56 ` [PATCH v2 15/15] xen/arm: update GIC dt node with GIC v3 information vijay.kilari
2014-04-04 14:22   ` Julien Grall
2014-04-04 15:45     ` Vijay Kilari
2014-04-04 16:00       ` Julien Grall
2014-04-04 16:13         ` Vijay Kilari
2014-04-04 16:42           ` Julien Grall
2014-04-10 10:28   ` Ian Campbell
2014-04-04 13:01 ` [PATCH v2 00/15] xen/arm: Add GICv3 support Julien Grall
2014-04-04 15:56   ` Vijay Kilari
2014-04-04 16:03     ` Julien Grall
2014-04-10  8:45 ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533EB9C4.3020709@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=Prasun.Kapoor@caviumnetworks.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=vijay.kilari@gmail.com \
    --cc=vijaya.kumar@caviumnetworks.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).