* [Qemu-devel] Small note about qemu/target-sh4/op.c
@ 2006-07-18 12:54 Pablo Virolainen
2006-07-18 17:03 ` [Qemu-devel] smc91x irq patch Thorsten Zitterell
0 siblings, 1 reply; 5+ messages in thread
From: Pablo Virolainen @ 2006-07-18 12:54 UTC (permalink / raw)
To: qemu-devel
Hello,
I just noticed that op_dec8_rN and op_dec8_rN might have a copy-paste
error. I wonder if it should be like
RCS file: /sources/qemu/qemu/target-sh4/op.c,v
retrieving revision 1.3
diff -u -r1.3 op.c
--- op.c 18 Jun 2006 19:12:54 -0000 1.3
+++ op.c 18 Jul 2006 12:22:23 -0000
@@ -737,7 +737,7 @@
void OPPROTO op_dec8_rN(void)
{
- env->gregs[PARAM1] -= 4;
+ env->gregs[PARAM1] -= 8;
RETURN();
}
@@ -761,7 +761,7 @@
void OPPROTO op_inc8_rN(void)
{
- env->gregs[PARAM1] += 4;
+ env->gregs[PARAM1] += 8;
RETURN();
}
Pablo Virolainen
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Qemu-devel] smc91x irq patch
2006-07-18 12:54 [Qemu-devel] Small note about qemu/target-sh4/op.c Pablo Virolainen
@ 2006-07-18 17:03 ` Thorsten Zitterell
2006-07-19 3:29 ` Paul Brook
0 siblings, 1 reply; 5+ messages in thread
From: Thorsten Zitterell @ 2006-07-18 17:03 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
Hi,
I am working on a Gumstix system [1] emulation for QEMU which is based
on a Intel XScale processor. The board has an expansion card for network
support which is a smc91x compatible NIC. However, the irq line is not
directly connected to the processor's interrupt controller but to an
GPIO which triggers an irq when a level edge is detected.
The attached patch allows to give an arbitrary function as irq handler
for the smc91c111 driver - in my case a function which sets the
corresponding GPIO line.
Btw, I already put a preliminary version of the Gumstix system emulation
online [2] - many components are only partly implemented (DMA, GPIO,
PIC, flash ...). However, I can boot a flash image and log into the
Linux system.
Could you apply this patch? I have seen that other functions allow
giving an irq handler, too.
Thanks,
Thorsten
[1] www.gumstix.com
[2] http://www.bitmux.org/qemu.html
[-- Attachment #2: patch-smc_irq-2006-06-18 --]
[-- Type: text/plain, Size: 2984 bytes --]
diff -upr qemu.orig/hw/integratorcp.c qemu.patches/hw/integratorcp.c
--- qemu.orig/hw/integratorcp.c 2006-07-18 18:13:25.361172000 +0200
+++ qemu.patches/hw/integratorcp.c 2006-07-18 18:31:18.151219000 +0200
@@ -501,7 +501,7 @@ static void integratorcp_init(int ram_si
if (nd_table[0].vlan) {
if (nd_table[0].model == NULL
|| strcmp(nd_table[0].model, "smc91c111") == 0) {
- smc91c111_init(&nd_table[0], 0xc8000000, pic, 27);
+ smc91c111_init(&pic_set_irq_new,&nd_table[0], 0xc8000000, pic, 27);
} else {
fprintf(stderr, "qemu: Unsupported NIC: %s\n", nd_table[0].model);
exit (1);
diff -upr qemu.orig/hw/smc91c111.c qemu.patches/hw/smc91c111.c
--- qemu.orig/hw/smc91c111.c 2006-07-18 18:13:25.982420000 +0200
+++ qemu.patches/hw/smc91c111.c 2006-07-18 18:33:13.130230000 +0200
@@ -26,6 +26,7 @@ typedef struct {
uint16_t ercv;
void *pic;
int irq;
+ SetIRQFunc *set_irq;
int bank;
int packet_num;
int tx_alloc;
@@ -86,7 +87,7 @@ static void smc91c111_update(smc91c111_s
if (s->tx_fifo_done_len != 0)
s->int_level |= INT_TX;
level = (s->int_level & s->int_mask) != 0;
- pic_set_irq_new(s->pic, s->irq, level);
+ (*s->set_irq)(s->pic, s->irq, level);
}
/* Try to allocate a packet. Returns 0x80 on failure. */
@@ -692,7 +693,7 @@ static CPUWriteMemoryFunc *smc91c111_wri
smc91c111_writel
};
-void smc91c111_init(NICInfo *nd, uint32_t base, void *pic, int irq)
+void smc91c111_init(SetIRQFunc *set_irq, NICInfo *nd, uint32_t base, void *pic, int irq)
{
smc91c111_state *s;
int iomemtype;
@@ -704,6 +705,8 @@ void smc91c111_init(NICInfo *nd, uint32_
s->base = base;
s->pic = pic;
s->irq = irq;
+ s->set_irq = set_irq;
+
memcpy(s->macaddr, nd->macaddr, 6);
smc91c111_reset(s);
diff -upr qemu.orig/hw/versatilepb.c qemu.patches/hw/versatilepb.c
--- qemu.orig/hw/versatilepb.c 2006-07-18 18:13:26.170931000 +0200
+++ qemu.patches/hw/versatilepb.c 2006-07-18 18:31:06.742434000 +0200
@@ -370,7 +370,7 @@ static void versatile_init(int ram_size,
if (!nd->model)
nd->model = done_smc ? "rtl8139" : "smc91c111";
if (strcmp(nd->model, "smc91c111") == 0) {
- smc91c111_init(nd, 0x10010000, sic, 25);
+ smc91c111_init(&pic_set_irq_new,nd, 0x10010000, sic, 25);
} else {
pci_nic_init(pci_bus, nd);
}
diff -upr qemu.orig/vl.h qemu.patches/vl.h
--- qemu.orig/vl.h 2006-07-18 18:13:24.653227000 +0200
+++ qemu.patches/vl.h 2006-07-18 18:32:46.190286000 +0200
@@ -1094,7 +1094,7 @@ void ps2_queue(void *, int b);
void ps2_keyboard_set_translation(void *opaque, int mode);
/* smc91c111.c */
-void smc91c111_init(NICInfo *, uint32_t, void *, int);
+void smc91c111_init(SetIRQFunc *set_irq, NICInfo *, uint32_t, void *, int);
/* pl110.c */
void *pl110_init(DisplayState *ds, uint32_t base, void *pic, int irq, int);
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] smc91x irq patch
2006-07-18 17:03 ` [Qemu-devel] smc91x irq patch Thorsten Zitterell
@ 2006-07-19 3:29 ` Paul Brook
2006-07-19 17:53 ` Fabrice Bellard
0 siblings, 1 reply; 5+ messages in thread
From: Paul Brook @ 2006-07-19 3:29 UTC (permalink / raw)
To: qemu-devel
On Tuesday 18 July 2006 18:03, Thorsten Zitterell wrote:
> I am working on a Gumstix system [1] emulation for QEMU which is based
> on a Intel XScale processor. The board has an expansion card for network
> support which is a smc91x compatible NIC. However, the irq line is not
> directly connected to the processor's interrupt controller but to an
> GPIO which triggers an irq when a level edge is detected.
As discussed on IRC this is the wrong way to do this. Instead use the
mechanisms in arm_pic.[ch] and make you GPIO emulation look like an interrupt
controller.
There's no point passing round both a pic callback and an object when we can
embed the callback in the object.
Paul
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] smc91x irq patch
2006-07-19 3:29 ` Paul Brook
@ 2006-07-19 17:53 ` Fabrice Bellard
2006-07-19 18:15 ` Paul Brook
0 siblings, 1 reply; 5+ messages in thread
From: Fabrice Bellard @ 2006-07-19 17:53 UTC (permalink / raw)
To: qemu-devel
Paul Brook wrote:
> On Tuesday 18 July 2006 18:03, Thorsten Zitterell wrote:
>
>>I am working on a Gumstix system [1] emulation for QEMU which is based
>>on a Intel XScale processor. The board has an expansion card for network
>>support which is a smc91x compatible NIC. However, the irq line is not
>>directly connected to the processor's interrupt controller but to an
>>GPIO which triggers an irq when a level edge is detected.
>
>
> As discussed on IRC this is the wrong way to do this. Instead use the
> mechanisms in arm_pic.[ch] and make you GPIO emulation look like an interrupt
> controller.
>
> There's no point passing round both a pic callback and an object when we can
> embed the callback in the object.
I don't think that adding a callback is bad. It can be useful to use the
device with another CPU or IRQ controller for example.
In fact, I would like to go further by adding a type such as
"QEMUSignal" which could be used for IRQs or any other I/Os. Then you
can pass it to devices. You can used qemu_signal_set(QEMUSignal *signal,
int level) to set the level and add listeners to get notified on the
changes with something like: qemu_add_signal_cb(QEMUSignal *signal, void
(*cb)(void *opaque), void *opaque).
Regards,
Fabrice.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] smc91x irq patch
2006-07-19 17:53 ` Fabrice Bellard
@ 2006-07-19 18:15 ` Paul Brook
0 siblings, 0 replies; 5+ messages in thread
From: Paul Brook @ 2006-07-19 18:15 UTC (permalink / raw)
To: qemu-devel
> > There's no point passing round both a pic callback and an object when we
> > can embed the callback in the object.
>
> I don't think that adding a callback is bad. It can be useful to use the
> device with another CPU or IRQ controller for example.
It means all the device emulation code has got to keep track of three bits of
information rather than two, which seems silly when the callback and the
object are inherently linked. I can't think of any cases where the callback
is not be implied by the object.
> In fact, I would like to go further by adding a type such as
> "QEMUSignal" which could be used for IRQs or any other I/Os. Then you
> can pass it to devices. You can used qemu_signal_set(QEMUSignal *signal,
> int level) to set the level and add listeners to get notified on the
> changes with something like: qemu_add_signal_cb(QEMUSignal *signal, void
> (*cb)(void *opaque), void *opaque).
Extending the arm_pic code to work with all targets on my list of things to
do.
Paul
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-07-19 18:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-18 12:54 [Qemu-devel] Small note about qemu/target-sh4/op.c Pablo Virolainen
2006-07-18 17:03 ` [Qemu-devel] smc91x irq patch Thorsten Zitterell
2006-07-19 3:29 ` Paul Brook
2006-07-19 17:53 ` Fabrice Bellard
2006-07-19 18:15 ` Paul Brook
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).