> +static void tmp105_initfn(Object *obj)
> +{
> +object_property_add(obj, "temperature", "int",
> +tmp105_get_temperature,
> +tmp105_set_temperature, NULL, NULL, NULL);
> +}
> +
> static void tmp105_class_init(ObjectClass *klass, void *data)
>
Thanks so much for taking the initiative on creating functional tests
for the TMP105 hardware model. I am exciting to see these changes and
I am wondering if your QTests could be complemented with the following
standalone unit tests:
https://github.com/ahorn/benchmarks/blob/965e571d92e677e8e64a
test help in clarifying the source
of the error. I would greatly appreciate your thoughts on this.
With best regards,
Alex
On 6 December 2012 21:21, Blue Swirl wrote:
> On Wed, Dec 5, 2012 at 7:48 PM, Alex Horn wrote:
>> The private buffer length field must only be incremented after the
ecision when, in fact, it should be 0.125 C (slush)!
Signed-off-by: Alex Horn
---
hw/tmp105.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/tmp105.c b/hw/tmp105.c
index 8e8dbd9..5f41a3f 100644
--- a/hw/tmp105.c
+++ b/hw/tmp105.c
@@ -152,7 +152,7 @@ static int tmp105
* Define enum for TMP105 registers
* Move tmp105_set() from I2C to TMP105 header
* Document units and range of temperature as preconditions
Signed-off-by: Alex Horn
---
hw/i2c.h|3 --
hw/tmp105.c | 17 ---
hw/tmp105.h | 67
ivers/hwmon/lm75.c#L37
On 3 December 2012 22:43, andrzej zaborowski wrote:
> Hi Alex,
>
> On 1 December 2012 20:39, Alex Horn wrote:
>> Hello all,
>>
>> As I have been browsing through QEMU's source code, I've noticed a
>> hardware model for a temperat
* Define constants for TMP105 registers.
* Move tmp105_set() from I2C to TMP105 header.
Signed-off-by: Alex Horn
---
hw/i2c.h|3 ---
hw/tmp105.c | 17 +
hw/tmp105.h | 34 ++
3 files changed, 43 insertions(+), 11 deletions(-)
create
Hello all,
As I have been browsing through QEMU's source code, I've noticed a
hardware model for a temperature sensor called TMP105. This model
implements the function tmp105_set(I2CSlave *i2c, int temp) declared
in i2c.h [0, 1].
Surprisingly, however, I cannot find any code which calls this sett
tc_x86
On 19 November 2012 11:42, Paolo Bonzini wrote:
> Il 19/11/2012 12:34, Alex Horn ha scritto:
>>> [...] the patch is almost good for inclusion. I'd ask for two changes:
>>> 1) please test == 0, not != REG_B_SET;
>>> 2) please leave the fuzzicsng test last
** Attachment added: "register_b_set_flag_v2.patch"
https://bugs.launchpad.net/bugs/1080086/+attachment/3438594/+files/register_b_set_flag_v2.patch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/10
Cross reference:
https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg01759.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1080086
Title:
MC146818 RTC breaks when SET bit in Register B i
08:52, Paolo Bonzini wrote:
> Il 17/11/2012 19:47, Alex Horn ha scritto:
>> I have attached a patch for the most recent version of the file
>> hw/mc146818rtc.c [1]. The patch also features a functional test which
>> executes through the QTest framework.
>>
>> I would
I have attached a patch for the most recent version of the file
hw/mc146818rtc.c [1]. The patch also features a functional test which
executes through the QTest framework.
I would appreciate your thoughts on this.
[1]
http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071
Public bug reported:
This bug occurs when the SET flag of Register B is enabled. When an RTC
data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set,
the data is (as expected) correctly stored in the cmos_data array. However,
since the SET flag is enabled, the function rtc_se
14 matches
Mail list logo
