Hi Joe,
> +static int aspeed_i3c_device_ibi_finish(I3CBus *bus)
> +{
> + AspeedI3CDevice *s = ASPEED_I3C_DEVICE(bus->qbus.parent);
> + bool nack_and_disable_hj = ARRAY_FIELD_EX32(s->regs, DEVICE_CTRL,
> + HOT_JOIN_ACK_NACK_CTRL);
> + if (nack
Hi Joe,
> > 1) Is this something that qemu upstream would accept? Do we need a
> > formal description of the guest-to-host interface somewhere? Or is there
> > a more standard way of exposing busses like this?
> >
> Not sure! I'm open to ideas.
> I think the most controversial portion of the remo
Hi Joe,
> > > Jeremy, how different is it ? Could we introduce properties or sub
> > > classes, to support both.
> >
> > The differences (at least from the view of the current Linux driver
> > implementation) are very minor; unless we want to be errata-compatible,
> > you could use the dw driver
Hi Joe,
> +static uint8_t aspeed_i3c_device_target_addr(AspeedI3CDevice *s,
> + uint16_t offset)
> +{
> + if (offset > ASPEED_I3C_NR_DEVICES) {
> + qemu_log_mask(LOG_GUEST_ERROR, "%s: Device addr table offset %d out
> of "
> +
Hi Joe,
> Adds a model to communicate to remote I3C devices over chardev. This
> allows QEMU to communicate to I3C targets that exist outside of QEMU.
Nice!
I've been wanting something similar for a while, both for i2c and i3c
busses, to the point of having a similar concept partly implemented.
Hi Joe,
First up, nice work with this series! I haven't yet had a thorough look
at the series, but one item on something that caught me up on the Linux
side:
> +static void aspeed_i3c_device_ibi_queue_push(AspeedI3CDevice *s)
> +{
> + /* Stored value is in 32-bit chunks, convert it to byte chu
Hi Cédric,
> > Isn't this the designware i3c ip block, and as such could we name
> > it so?
>
> Currently, QEMU only has a model for a dummy Aspeed I3C variant so
> this is a great addition.
[...]
> According to recent work on the kernel, it is indeed based on
> designware I3C :
>
> https:/
Hi Klaus,
> I had to reverse the target mode functionality in QEMU from the linux
> driver, so I am really not too sure if having START and STOP set in
> the interrupt register is allowed behavior or not
>From my interpretation of things, there's nothing explicitly preventing
both a pending start
ible I will propose upstream.
Cheers,
Jeremy
---
>From 6331cf2499c182606979029d2aaed93ee3e544fa Mon Sep 17 00:00:00 2001
From: Jeremy Kerr
Date: Fri, 18 Nov 2022 14:04:50 +0800
Subject: [PATCH] i2c: aspeed: Allow combined STOP & START irqs
Currently, if we enter our interrupt handler wi
Hi Klaus,
> Add an abstract MCTP over I2C endpoint model. This implements MCTP
> control message handling as well as handling the actual I2C transport
> (packetization).
>
> Devices are intended to derive from this and implement the class
> methods.
Looks good, nice to see how it's used by the n
Hi Klaus,
[+CC Matt]
> This adds a generic MCTP endpoint model that other devices may derive
> from. I'm not 100% happy with the design of the class methods, but
> it's a start.
Thanks for posting these! I'll have a more thorough look through soon,
but wanted to tackle some of the larger design-
Hi Greg,
> > The standard process is to send me an email :)
>
> Is this standard process mentioned somewhere ?
No, not really. I usually let the folks who request the project in the
first place know though.
> > You're wanting to add user 'groug' to the qemu project, is that
> > correct?
> >
>
Hi Alexey,
> Jeremy or Stephen (cc-ing) do definitely know if there is a better
> way.
The standard process is to send me an email :)
You're wanting to add user 'groug' to the qemu project, is that
correct?
Cheers,
Jeremy
Hi Andrew,
> This patch series models enough of the ASPEED AST2400 ARM9 SoC[0] to
> boot an aspeed_defconfig Linux kernel[1][2]. Specifically, the series
> implements the ASPEED timer and VIC devices, integrates them into an
> AST2400 SoC and exposes it all through a new opbmc2400 machine. The
> d
Hi Michael,
We'd like to add Peter Maydell
as an additional patchwork admin.
Could you do this please?
Sure thing, all done.
Cheers,
Jeremy
Hi Grant,
Thanks, this fixes the overflow for me too. Have applied to my tree and pushed
out.
If anyone else would like to check out out the patches, my tree is at:
http://kernel.ubuntu.com/git?p=jk/dt/qemu.git;a=summary
git://kernel.ubuntu.com/jk/dt/qemu.git
Cheers,
Jeremy
Hi Grant,
> This is an experimental set of patches for populating the flattened
> device tree (fdt) data from the actual set of qdevs in the platform.
Neat. I've pulled these into my qemu tree, and have updated it to the current
qemu master branch too (only a minor change, as qemu_error has been
17 matches
Mail list logo
