All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Peter Chubb <peter.chubb@nicta.com.au>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, Philip OSullivan <philipo@ok-labs.com>,
	Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [patch V5 3/5] FreeSCALE i.MX31 support: Timers
Date: Thu, 5 Apr 2012 18:23:50 +0100	[thread overview]
Message-ID: <CAFEAcA8VVCPU3R5gX2KV3Y8t_g+0EBExnXzZ8e3dM9DxpaKuPA@mail.gmail.com> (raw)
In-Reply-To: <20120403020306.802484890@nicta.com.au>

On 3 April 2012 02:55, Peter Chubb <peter.chubb@nicta.com.au> wrote:
> +    case 2: /* LR - set ticks */
> +        s->lr = value;
> +        /*
> +         * Artificially limit tick rate to something
> +         * achievable under QEMU.  Otherwise, QEMU spends all
> +         * its time generating timer interrupts, and there
> +         * is no forward progress.
> +         * About ten microseconds is the fastest that really works.
> +         */
> +        if ((value * 1000000)/s->freq < 10) {
> +            value = 10*1000000/s->freq;
> +        }
> +        ptimer_set_limit(s->timer, value, !!(s->cr & CR_IOVW));
> +        break;

This seems like the wrong level to do this. If over-eager timer
ticks are a problem we ought to be applying the limit globally
in the timer infrastructure layer somewhere, not via ad-hoc
bandaids in individual device models.

> +void imx_timer_create(const char * const name,
> +                              const target_phys_addr_t addr,
> +                              qemu_irq irq,
> +                              DeviceState *ccm)
> +{
> +    IMXTimerGState *gp;
> +    IMXTimerPState *pp;
> +    DeviceState *dev;
> +
> +    dev = sysbus_create_simple(name, addr, irq);
> +    if (strcmp(name, "imx_timerp") == 0) {
> +        pp = container_of(dev, IMXTimerPState, busdev.qdev);
> +        pp->ccm = ccm;
> +    } else {
> +        gp = container_of(dev, IMXTimerGState, busdev.qdev);
> +        gp->ccm = ccm;
> +    }
> +
> +}

This is wrong in two ways:
(a) strcmp() on the device name is pretty ugly
(b) this kind of helper creation method mustn't go reaching
into the implementation of the device like this. If you need
to hand something to the device it needs to be a qdev property.

-- PMM

  reply	other threads:[~2012-04-05 17:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03  1:55 [Qemu-devel] [patch V5 0/5] i.MX31 support Peter Chubb
2012-04-03  1:55 ` [Qemu-devel] [patch V5 1/5] i.MX UART support Peter Chubb
2012-04-03  1:55 ` [Qemu-devel] [patch V5 2/5] Implement i.MX31 Clock Control Module Peter Chubb
2012-04-05 17:31   ` Peter Maydell
2012-04-03  1:55 ` [Qemu-devel] [patch V5 3/5] FreeSCALE i.MX31 support: Timers Peter Chubb
2012-04-05 17:23   ` Peter Maydell [this message]
2012-04-03  1:55 ` [Qemu-devel] [patch V5 4/5] FreeSCALE i.MX31 support: AVIC Peter Chubb
2012-04-03  1:55 ` [Qemu-devel] [patch V5 5/5] FreeSCALE i.MX31 support: KZM-ARM11-01 evaluation board Peter Chubb
2012-04-05 17:11   ` Peter Maydell
2012-04-03  9:45 ` [Qemu-devel] [patch V5 0/5] i.MX31 support Andreas Färber

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=CAFEAcA8VVCPU3R5gX2KV3Y8t_g+0EBExnXzZ8e3dM9DxpaKuPA@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=paul@codesourcery.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.chubb@nicta.com.au \
    --cc=philipo@ok-labs.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.