qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Alistair Francis <alistair.francis@xilinx.com>
Cc: edgar.iglesias@xilinx.com, peter.maydell@linaro.org,
	qemu-devel@nongnu.org, crosthwaitepeter@gmail.com,
	edgar.iglesias@gmail.com, afaerber@suse.de,
	fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] [PATCH v4 03/16] register: Add Memory API glue
Date: Fri, 26 Feb 2016 17:25:36 +0000	[thread overview]
Message-ID: <87fuwf759r.fsf@linaro.org> (raw)
In-Reply-To: <f9c825d5ecc05b9662e6e0fe672785156b1a0ad5.1455055858.git.alistair.francis@xilinx.com>


Alistair Francis <alistair.francis@xilinx.com> writes:

> From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>
> Add memory io handlers that glue the register API to the memory API.
> Just translation functions at this stage. Although it does allow for
> devices to be created without all-in-one mmio r/w handlers.
>
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
> Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
> ---
>
>  hw/core/register.c    | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/hw/register.h | 31 +++++++++++++++++++++++++++++++
>  2 files changed, 79 insertions(+)
>
> diff --git a/hw/core/register.c b/hw/core/register.c
> index 7e47df5..9cd50c8 100644
> --- a/hw/core/register.c
> +++ b/hw/core/register.c
> @@ -150,3 +150,51 @@ void register_reset(RegisterInfo *reg)
>
>      register_write_val(reg, reg->access->reset);
>  }
> +
> +static inline void register_write_memory(void *opaque, hwaddr addr,
> +                                         uint64_t value, unsigned size, bool be)
> +{
> +    RegisterInfo *reg = opaque;
> +    uint64_t we = ~0;
> +    int shift = 0;
> +
> +    if (reg->data_size != size) {
> +        we = (size == 8) ? ~0ull : (1ull << size * 8) - 1;
> +        shift = 8 * (be ? reg->data_size - size - addr : addr);
> +    }

What happens if the user writes too large a value at once to the
register? I haven't attempted to decode the shift magic going on here
but perhaps the handling would be clearer if there was a:

if (size > reg->data_size) {
   ..deal with it..
} else if (size < data_size ) {
  ..do other magic..
}

> +
> +    assert(size + addr <= reg->data_size);

Why are we asserting expected input conditions after we've done stuff?

> +    register_write(reg, value << shift, we << shift);
> +}
> +
> +void register_write_memory_be(void *opaque, hwaddr addr, uint64_t value,
> +                              unsigned size)
> +{
> +    register_write_memory(opaque, addr, value, size, true);
> +}
> +
> +
> +void register_write_memory_le(void *opaque, hwaddr addr, uint64_t value,
> +                              unsigned size)
> +{
> +    register_write_memory(opaque, addr, value, size, false);
> +}
> +
> +static inline uint64_t register_read_memory(void *opaque, hwaddr addr,
> +                                            unsigned size, bool be)
> +{
> +    RegisterInfo *reg = opaque;
> +    int shift = 8 * (be ? reg->data_size - size - addr : addr);
> +

Well we never have to deal with an over/undersized read? I suspect the
magic above might not correctly represent some hardware when presented
with such a thing on the bus.

> +    return register_read(reg) >> shift;
> +}
> +
> +uint64_t register_read_memory_be(void *opaque, hwaddr addr, unsigned size)
> +{
> +    return register_read_memory(opaque, addr, size, true);
> +}
> +
> +uint64_t register_read_memory_le(void *opaque, hwaddr addr, unsigned size)
> +{
> +    return register_read_memory(opaque, addr, size, false);
> +}
> diff --git a/include/hw/register.h b/include/hw/register.h
> index 444239c..9aa9cfc 100644
> --- a/include/hw/register.h
> +++ b/include/hw/register.h
> @@ -69,9 +69,14 @@ struct RegisterAccessInfo {
>   * @prefix: String prefix for log and debug messages
>   *
>   * @opaque: Opaque data for the register
> + *
> + * @mem: optional Memory region for the register
>   */
>
>  struct RegisterInfo {
> +    /* <private> */
> +    MemoryRegion mem;
> +

This seems unconnected with adding the helpers. Should it come with the
original definition or when it actually gets used?

>      /* <public> */
>      void *data;
>      int data_size;
> @@ -108,4 +113,30 @@ uint64_t register_read(RegisterInfo *reg);
>
>  void register_reset(RegisterInfo *reg);
>
> +/**
> + * Memory API MMIO write handler that will write to a Register API register.
> + *  _be for big endian variant and _le for little endian.
> + * @opaque: RegisterInfo to write to
> + * @addr: Address to write
> + * @value: Value to write
> + * @size: Number of bytes to write
> + */
> +
> +void register_write_memory_be(void *opaque, hwaddr addr, uint64_t value,
> +                              unsigned size);
> +void register_write_memory_le(void *opaque, hwaddr addr, uint64_t value,
> +                              unsigned size);
> +
> +/**
> + * Memory API MMIO read handler that will read from a Register API register.
> + *  _be for big endian variant and _le for little endian.
> + * @opaque: RegisterInfo to read from
> + * @addr: Address to read
> + * @size: Number of bytes to read
> + * returns: Value read from register
> + */
> +
> +uint64_t register_read_memory_be(void *opaque, hwaddr addr, unsigned size);
> +uint64_t register_read_memory_le(void *opaque, hwaddr addr, unsigned size);
> +
>  #endif


--
Alex Bennée

  reply	other threads:[~2016-02-26 17:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 22:14 [Qemu-devel] [PATCH v4 00/16] data-driven device registers Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 01/16] memory: Allow subregions to not be printed by info mtree Alistair Francis
2016-02-26 16:51   ` Alex Bennée
2016-02-26 16:54     ` Peter Maydell
2016-03-08  0:49       ` Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 02/16] register: Add Register API Alistair Francis
2016-02-26 17:13   ` Alex Bennée
2016-03-08  0:54     ` Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 03/16] register: Add Memory API glue Alistair Francis
2016-02-26 17:25   ` Alex Bennée [this message]
2016-03-08  1:18     ` Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 04/16] register: Add support for decoding information Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 05/16] register: Define REG and FIELD macros Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 06/16] register: QOMify Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 07/16] register: Add block initialise helper Alistair Francis
2016-02-29 11:28   ` Alex Bennée
2016-03-08  0:09     ` Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 08/16] bitops: Add ONES macro Alistair Francis
2016-02-29 11:51   ` Alex Bennée
2016-03-04 22:42     ` Alistair Francis
2016-02-09 22:14 ` [Qemu-devel] [PATCH v4 09/16] dma: Add Xilinx Zynq devcfg device model Alistair Francis
2016-02-29 12:20   ` Alex Bennée
2016-03-04 19:41     ` Alistair Francis
2016-02-09 22:15 ` [Qemu-devel] [PATCH v4 11/16] qdev: Define qdev_get_gpio_out Alistair Francis
2016-02-09 22:15 ` [Qemu-devel] [PATCH v4 12/16] qdev: Add qdev_pass_all_gpios API Alistair Francis
2016-02-09 22:15 ` [Qemu-devel] [PATCH v4 13/16] irq: Add opaque setter routine Alistair Francis
2016-02-09 22:15 ` [Qemu-devel] [PATCH v4 14/16] register: Add GPIO API Alistair Francis
2016-02-29 12:22   ` Alex Bennée
2016-03-04 18:47     ` Alistair Francis
2016-02-09 22:15 ` [Qemu-devel] [PATCH v4 15/16] misc: Introduce ZynqMP IOU SLCR Alistair Francis
2016-02-09 22:15 ` [Qemu-devel] [PATCH v4 16/16] xlnx-zynqmp: Connect the " Alistair Francis
2016-02-26 16:15 ` [Qemu-devel] [PATCH v4 00/16] data-driven device registers Alex Bennée
2016-02-29 12:26 ` Alex Bennée
2016-03-03 21:27   ` Alistair Francis
2016-03-08  1:21     ` Alistair Francis

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=87fuwf759r.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=afaerber@suse.de \
    --cc=alistair.francis@xilinx.com \
    --cc=crosthwaitepeter@gmail.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=edgar.iglesias@xilinx.com \
    --cc=fred.konrad@greensocs.com \
    --cc=peter.maydell@linaro.org \
    --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 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).