On Sat, 2 Nov 2024, Corey Minyard wrote:
On Sat, Nov 02, 2024 at 02:17:00PM +0100, Bernhard Beschow wrote:
Reviewed-by: Cédric Le Goater
Signed-off-by: Bernhard Beschow
Signed-off-by: Corey Minyard
Did you mean Reviewed-by or was it your patch that Bernhard picked up?
Regards,
BALATON
with a comment would be simpler but the result is
the same so
Reviewed-by: BALATON Zoltan
Regards,
BALATON Zoltan
---
hw/ppc/mpc8544_guts.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/ppc/mpc8544_guts.c b/hw/ppc/mpc8544_guts.c
index e3540b0281..c02b34ccde 1006
thers have no opinion on it.
I also had this patch:
https://patchew.org/QEMU/cover.1728232526.git.bala...@eik.bme.hu/
which I first thought might help but that's about guest_errors not unimp
logs so does not apply here. What other unimp logs get in the way here
that makes traces
ther machines. So I'd go
without the typedef.
Regards,
BALATON Zoltan
struct PPCE500MachineState {
-/*< private >*/
MachineState parent_obj;
/* points to instance of TYPE_PLATFORM_BUS_DEVICE if
* board supports dynamic sysbus devices
*/
PlatformBusDevice
t. You can also put the struct AppleGFXPCIState definition after the
OBJECT_DECLARE_SIMPLE_TYPE line. (See other devices for example.)
Regards,
BALATON Zoltan
+
+OBJECT_DECLARE_SIMPLE_TYPE(AppleGFXPCIState, APPLE_GFX_PCI)
+
+static const char* apple_gfx_pci_option_rom_path = NULL;
+
+static voi
to all machines. Thus I don't think merging with machine state
would be better than keeping is separate as this is more CPU related.
Regards,
BALATON Zoltan
Thanks,
C.
+
struct PPCE500MachineState {
/*< private >*/
MachineState parent_obj;
+boot_info boot_info
On Tue, 24 Sep 2024, Bernhard Beschow wrote:
Am 24. September 2024 09:59:21 UTC schrieb BALATON Zoltan :
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Am 23. September 2024 10:43:19 UTC schrieb BALATON Zoltan :
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Populate this read-only register with
for a similar problem is this:
https://patchew.org/QEMU/20240520101007.a25a34e6...@zero.eik.bme.hu/
I don't know if that would be simpler for this device as well.
Regards,
BALATON Zoltan
Signed-off-by: Bernhard Beschow
---
hw/ppc/ppce500_ccsr.c | 33 +++--
hw/ppc/
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Am 23. September 2024 10:49:53 UTC schrieb BALATON Zoltan :
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Signed-off-by: Bernhard Beschow
---
hw/i2c/mpc_i2c.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Am 23. September 2024 10:43:19 UTC schrieb BALATON Zoltan :
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Populate this read-only register with some arbitrary values which avoids
U-Boot's get_clocks() to hang().
Maybe this should be a pro
type_register_static(&mpc_i2c_type_info);
-}
-
-type_init(mpc_i2c_register_types)
+DEFINE_TYPES(types)
What's the advantage of this when we have a single device? For these
devices this looks like just code churn to me.
Regards,
BALATON Zoltan
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Prefer a macro rather than a string literal when instantiaging device models.
Signed-off-by: Bernhard Beschow
Reviewed-by: BALATON Zoltan
---
hw/pci-host/ppce500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci-host
e for the
machine.
Regards,
BALATON Zoltan
Signed-off-by: Bernhard Beschow
---
hw/ppc/mpc8544_guts.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/ppc/mpc8544_guts.c b/hw/ppc/mpc8544_guts.c
index e3540b0281..6688fd44c3 100644
--- a/hw/ppc/mpc8544_guts.c
+++ b/h
2 of the License, or
+ * (at your option) any later version.
+ */
SPDX-License-Identifier seems to be preferred by some nowadays, I don't
have an opinion on that so just mentioning it for consideration but I'm OK
with this one too although it seems a bit long.
Regards,
BALATON Zol
ci-bar0",
&ccsr->ccsr_space,
- 0, int128_get64(ccsr->ccsr_space.size));
+memory_region_init_alias(&b->bar0, OBJECT(ccsr), "e500-pci-bar0",
+ ccsr_space, 0, int128_get64(ccsr_space->size));
I wonder if this real
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Signed-off-by: Bernhard Beschow
Reviewed-by: BALATON Zoltan
---
hw/ppc/e500.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 32996c188e..228287b457 100644
--- a/hw/ppc/e500.c
+++ b/hw
On Mon, 23 Sep 2024, Bernhard Beschow wrote:
Signed-off-by: Bernhard Beschow
Reviewed-by: BALATON Zoltan
---
hw/ppc/e500.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index f68779a1ea..32996c188e 100644
--- a/hw/ppc/e500.c
+++ b/hw
x27;s clear env is not needed outside of
the loop any more so can be moved there. The purpose of this seems to be
to preserve the env of the first CPU but as it's unused yet maybe it can
be removed for now and readded later when needed.
Regards,
BALATON Zoltan
Signed-off-by: Bernhard Besc
only the parent_obj is followed by a new
line as was suggested as reccomended style.
Regatds,
BALATON Zoltan
/* points to instance of TYPE_PLATFORM_BUS_DEVICE if
* board supports dynamic sysbus devices
*/
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 3bd12b54ab..75b051009f 1006
On Wed, 11 Sep 2024, Pierrick Bouvier wrote:
On 9/11/24 07:10, BALATON Zoltan wrote:
On Tue, 10 Sep 2024, Pierrick Bouvier wrote:
Signed-off-by: Pierrick Bouvier
---
hw/ppc/spapr_events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_events.c b/hw/ppc
#x27;s unlikely that the assert change and
removal of the following break or return would need to be reverted
separately so it's a simple enough change to put in one patch in my
opinion but I don't mink if it's kept separate either.
Regards,
BALATON Zoltan
base? I
don't know how all this works in QEMU and don't have time to check now.
Reagrds,
BALATON Zoltan
On Wed, 3 Jul 2024, Michael S. Tsirkin wrote:
On Wed, Jul 03, 2024 at 04:15:23AM +0200, BALATON Zoltan wrote:
On Tue, 2 Jul 2024, Michael S. Tsirkin wrote:
On Thu, Jun 27, 2024 at 03:08:00PM +0900, Akihiko Odaki wrote:
rom_bar is tristate but was defined as uint32_t so convert it into
Regards,
BALATON Zoltan
such pin so this is a QEMU internal connection that I
think should not be modelled with a named gpio. I think we really need a
function to init a qemu_irq (for now we only have one that also allocares
it) so then we can put this in ViaISAState and init in place. I'll make a
patch.
Regard
cases that way, if
allowed.
I had the same thought as some of these might also have performance
implications (although most of them are in rarely called places).
Regards,
BALATON Zoltan
On Tue, 27 Feb 2024, Philippe Mathieu-Daudé wrote:
On 27/2/24 14:13, BALATON Zoltan wrote:
Other headers now use dash instead of underscore. Rename
ahci_internal.h accordingly for consistency.
Signed-off-by: BALATON Zoltan
---
hw/ide/{ahci_internal.h => ahci-internal.h} | 0
hw/ide/ahc
Other headers now use dash instead of underscore. Rename
ahci_internal.h accordingly for consistency.
Signed-off-by: BALATON Zoltan
---
hw/ide/{ahci_internal.h => ahci-internal.h} | 0
hw/ide/ahci.c | 2 +-
hw/ide/ich.c| 2 +-
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
On 26/2/24 11:50, BALATON Zoltan wrote:
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
On 26/2/24 08:40, Markus Armbruster wrote:
BALATON Zoltan writes:
On Sun, 25 Feb 2024, Philippe Mathieu-Daudé wrote:
Rename "internal.
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
On 26/2/24 13:52, BALATON Zoltan wrote:
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
Most ICH9-related files use the 'ich9_' prefix.
Mention 'AHCI' in the file name.
Signed-off-by: Philippe Mathieu-Daud
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
On 26/2/24 14:01, BALATON Zoltan wrote:
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
Expose TYPE_ICH_DMI_PCI_BRIDGE to the new
"hw/pci-bridge/ich9_dmi.h" header.
Since this is effectively an empty object (that's not ev
x for what it does or used for.
Regards,
BALATON Zoltan
Signed-off-by: Philippe Mathieu-Daudé
---
MAINTAINERS | 1 +
include/hw/pci-bridge/ich9_dmi.h | 20
include/hw/southbridge/ich9.h | 2 --
hw/pci-bridge/{i82801b11.c =>
ahci-allwinnet.c
maybe?
Regsards,
BALATON Zoltan
hw/ide/meson.build| 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename hw/ide/{ich.c => ich9_ahci.c} (100%)
diff --git a/hw/ide/ich.c b/hw/ide/ich9_ahci.c
similarity index 100%
rename from hw/ide/ich.c
rename to hw/ide/ich9_
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
On 26/2/24 09:00, Philippe Mathieu-Daudé wrote:
On 26/2/24 08:40, Markus Armbruster wrote:
BALATON Zoltan writes:
On Sun, 25 Feb 2024, Philippe Mathieu-Daudé wrote:
Rename "internal.h" as "ide_internal.h", and
On Mon, 26 Feb 2024, Philippe Mathieu-Daudé wrote:
On 26/2/24 08:40, Markus Armbruster wrote:
BALATON Zoltan writes:
On Sun, 25 Feb 2024, Philippe Mathieu-Daudé wrote:
Rename "internal.h" as "ide_internal.h", and include
Is there a convention about using underscore o
but there are others elsewhere such as
pci_device.h). Maybe we should be consistent at least within IDE and this
series is now a good opportunity for renaming these headers to match. But
it's just a small nit, thanks for picking this up.
Regards,
BALATON Zoltan
it via its relative local pat
Remove last two includes of hw/ide/intarnal.h outside of hw/ide and
replace them with newly added public header to allow moving internal.h
into hw/ide to really stop exposing it.
Fixes: a11f439a0e (hw/ide: Stop exposing internal.h to non-IDE files)
Signed-off-by: BALATON Zoltan
---
hw/arm/sbsa
of the DMA and IDE types not defined above?
Regards,
BALATON Zoltan
+};
+
+#endif
diff --git a/include/hw/ide/internal.h b/include/hw/ide/internal.h
index 642bd1a979..d1d3fcd23a 100644
--- a/include/hw/ide/internal.h
+++ b/include/hw/ide/internal.h
@@ -9,6 +9,7 @@
#include "hw/ide.h"
select IDE_CORE
Maybe we can assume if something has an IDE bus it also wants to connect
IDE devices to it so just select IDE_DEV here and not at every place
IDE_BUS is selected? Or is there a place that only wants IDE_BUS?
Regards,
BALATON Zoltan
+config IDE_DEV
+bool
+depends
On Tue, 13 Feb 2024, Philippe Mathieu-Daudé wrote:
We should not wire IRQs on unrealized device.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Mark Cave-Ayland
Reviewed-by: BALATON Zoltan
---
hw/misc/macio/macio.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On Tue, 13 Feb 2024, Philippe Mathieu-Daudé wrote:
We should not wire IRQs on unrealized device.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: BALATON Zoltan
---
hw/i386/pc_q35.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/i386/pc_q35.c b/hw/i386
it in the device
realize method. I probably don't understand the problem fully, what I want
to say is that device creation is complex enough now so trying to avoid
adding more complexity to it would be a good thing.
Regards,
BALATON Zoltan
ccess = qdev_realize(DEVICE(ide), BUS(&s->macio_bus), errp);
If realize is unsuccessful can you connect irqs if device may be
unrealized? So maybe either the next two lines should be in an if block or
drop the success flag and return false here if (!qdev_realize) and true at
On Thu, 8 Feb 2024, Philippe Mathieu-Daudé wrote:
We should not wire IRQs on unrealized device.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/pc_q35.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 7ca3f465e0..f67e5a55df 100644
-
On Thu, 1 Feb 2024, Thomas Huth wrote:
On 01/02/2024 13.54, BALATON Zoltan wrote:
On Thu, 1 Feb 2024, Thomas Huth wrote:
On 01/02/2024 13.39, BALATON Zoltan wrote:
On Thu, 1 Feb 2024, Thomas Huth wrote:
For distros like downstream RHEL, it would be helpful to allow to
disable
the
On Thu, 1 Feb 2024, Thomas Huth wrote:
On 01/02/2024 13.39, BALATON Zoltan wrote:
On Thu, 1 Feb 2024, Thomas Huth wrote:
For distros like downstream RHEL, it would be helpful to allow to disable
the CompactFlash device. For making this possible, we need a separate
Kconfig switch for this
include/hw/ide/internal.h to ide.h
and name this one internal.h maybe?
Regards,
BALATON Zoltan
@@ -0,0 +1,41 @@
+/*
+ * ide bus support for qdev.
+ *
+ * Copyright (c) 2009 Gerd Hoffmann
+ *
+ * This code is free software; you can redistribute it and/or
+ * modify it under the terms of the
On Mon, 8 Jan 2024, Bernhard Beschow wrote:
Am 7. Januar 2024 13:59:44 UTC schrieb BALATON Zoltan :
On Sat, 6 Jan 2024, Bernhard Beschow wrote:
The VIA south bridges are able to relocate and toggle (enable or disable) their
SuperI/O functions. So far this is hardcoded such that all functions
? This should just
be int. Newly it's also allowed to declare it within the for so if you
want that you could do so but I have no preference on that and declaring
it here is also OK. Otherwise:
Reviewed-by: BALATON Zoltan
+
+isa_parallel_set_enabled(s->superio.parallel[0], (
cpu)->as;
I think this function should not need Pegasos2MachineState *pm and can
just use cpu_physical_memory_write() instead. Otherwise
Reviewed-by: BALATON Zoltan
+
+stb_phys(as, PCI1_IO_BASE + 0x3f0, addr);
+stb_phys(as, PCI1_IO_BASE + 0x3f1, val);
+}
+
stati
On Tue, 2 Jan 2024, Bernhard Beschow wrote:
Am 24. Dezember 2023 00:51:53 UTC schrieb BALATON Zoltan :
On Tue, 19 Dec 2023, Bernhard Beschow wrote:
Am 19. Dezember 2023 00:26:15 UTC schrieb BALATON Zoltan :
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
The VIA south bridges are able to
On Tue, 19 Dec 2023, Bernhard Beschow wrote:
Am 19. Dezember 2023 00:26:15 UTC schrieb BALATON Zoltan :
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
The VIA south bridges are able to relocate and toggle (enable or disable) their
SuperI/O functions. So far this is hardcoded such that all
On Tue, 19 Dec 2023, Bernhard Beschow wrote:
Am 19. Dezember 2023 00:26:15 UTC schrieb BALATON Zoltan :
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
The VIA south bridges are able to relocate and toggle (enable or disable) their
SuperI/O functions. So far this is hardcoded such that all
he opposite and like more
code to fit in one screen even on todays displays that are wider than
tall. So this funciton would take less space without blank lines. (Even
the local variable may not be necessary as you don't access any fields
within and void * should just cast without a war
same way pegasos2.rom would do. For now the meantime this will be
"same way pegasos2 firmware would do". You can drop the last sentence
about no-op as it does not make much sense as it is or reword it if you
want to keep it.
Regards,
BALATON Zoltan
a no-op.
Signed-off-by: Bernha
the last patch but I can't think of a better name for it other
than spelling out enable/disable. It's probably also not relevant in this
commit message to mention VIA south bridges as this is a generic function
not specific to that usage only.
Regards,
BALATON Zoltan
Signed-off-by
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
Some SuperI/O devices such as the VIA south bridges or the PC87312 controller
are able to relocate their SuperI/O functions. Add a convenience function for
implementing this in the VIA south bridges.
This convenience function relies on previous simpli
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
ParallelState::portio_list isn't used inside ParallelState context but only
inside ISAParallelState context, so more it there.
Same comments as for patch 1 otherwise
Reviewed-by: BALATON Zoltan
Signed-off-by: Bernhard Beschow
---
inclu
27;t need their own. Since all of
these need this io region putting it in SerialState saves some
duplication. Unless I've missed some reason this might be needed.
Regards,
BALATON Zoltan
Signed-off-by: Bernhard Beschow
---
include/hw/char/serial.h | 2 +-
hw/char/serial-isa.c
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
FDCtrl::iomem isn't used inside FDCtrl context but only inside FDCtrlSysBus
context, so more it there.
Same comments as for patch 1 otherwise
Reviewed-by: BALATON Zoltan
Signed-off-by: Bernhard Beschow
---
hw/block/fdc-internal.h | 2
:portio_list and would write out "The
portio_list field of FDCtrl" instead but not a big deal. Also the subject
could say "Move portio_list from FDCtrl to FDCtrlISABus" which is less
ambiguous than using free that's ususally associated with freeing memory.
Otherwise
R
On Mon, 18 Dec 2023, Bernhard Beschow wrote:
Am 18. Dezember 2023 10:54:56 UTC schrieb BALATON Zoltan :
On Sun, 17 Dec 2023, Bernhard Beschow wrote:
Am 17. Dezember 2023 15:47:33 UTC schrieb BALATON Zoltan :
On Sun, 17 Dec 2023, Bernhard Beschow wrote:
Exposing the internal header allows for
On Sun, 17 Dec 2023, Bernhard Beschow wrote:
Am 17. Dezember 2023 15:47:33 UTC schrieb BALATON Zoltan :
On Sun, 17 Dec 2023, Bernhard Beschow wrote:
Exposing the internal header allows for exposing struct FDCtrlISABus which is
encuraged by qdev guidelines.
Hopefully the guidelines don
plementation of
these objects making these harder to chnage in the future so a better way
may be to add methods to fdc and serial to allow changing their base
address and map/unmap their ports and keep their internals unexposed.
Regards,
BALATON Zoltan
Signed-off-by: Bernhard Beschow
serial
device objects should have methods to set their base that then either
superio or vt82c686 could then use without peeking them or exposing the
device sturctures.
Regards,
BALATON Zoltan
Signed-off-by: Bernhard Beschow
---
hw/isa/vt82c686.c | 140 --
h some
comments and docs explainig here and there what bql stands for should be
enough for new people to quickly find out. If we want to be more verbose
how about "qemu_global_mutex" which is self describing but longer and does
not resemble BQL so then comments may be needed to explain this
Return default value in legacy mode for BAR4 when unset. This can't be
set in reset method because BARs are cleared on reset so we return it
instead when BARs are read in legacy mode.
Signed-off-by: BALATON Zoltan
---
This fixes UDMA on amigaone with AmigaOS and I'd like to inclu
On Mon, 20 Nov 2023, Kevin Wolf wrote:
Am 20.11.2023 um 14:47 hat BALATON Zoltan geschrieben:
On Mon, 20 Nov 2023, Kevin Wolf wrote:
Am 20.11.2023 um 14:09 hat BALATON Zoltan geschrieben:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
The only difference I can think of regarding the BAR
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 20/11/2023 13:42, Kevin Wolf wrote:
Am 20.11.2023 um 14:09 hat BALATON Zoltan geschrieben:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 20/11/2023 13:30, BALATON Zoltan wrote:
On Mon, 20 Nov 2023, BALATON Zoltan wrote:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple
On Mon, 20 Nov 2023, BALATON Zoltan wrote:
On Mon, 20 Nov 2023, Kevin Wolf wrote:
Am 20.11.2023 um 14:09 hat BALATON Zoltan geschrieben:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a
On Mon, 20 Nov 2023, Kevin Wolf wrote:
Am 20.11.2023 um 14:09 hat BALATON Zoltan geschrieben:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode
On Mon, 20 Nov 2023, BALATON Zoltan wrote:
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode switching
for PCI
IDE controllers and updates the via
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode switching
for PCI
IDE controllers and updates the via-ide device to use it.
The approach I take
On Mon, 20 Nov 2023, Mark Cave-Ayland wrote:
On 19/11/2023 21:43, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode switching
for PCI
IDE controllers and updates the via-ide device to use it.
The approach I take
On Mon, 20 Nov 2023, Kevin Wolf wrote:
Am 17.11.2023 um 15:23 hat BALATON Zoltan geschrieben:
On Thu, 16 Nov 2023, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Kevin Wolf wrote:
Am 16.11.2023 um 11:33 hat Mark Cave-Ayland geschrieben:
This series adds a simple implementation of legacy/native
On Sun, 19 Nov 2023, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Mark Cave-Ayland wrote:
This series adds a simple implementation of legacy/native mode switching
for PCI
IDE controllers and updates the via-ide device to use it.
The approach I take here is to add a new pci_ide_update_mode
hat could cause this. Testing
was done by Rene Engel, cc'd so maybe he can add more info. It seems to
work with my patch that sets BARs to legacy values and with v2 that sets
them to 0 but not with v3 which should also read 0 but maybe something is
off here.
Regards,
BALATON Z
On Thu, 16 Nov 2023, BALATON Zoltan wrote:
On Thu, 16 Nov 2023, Kevin Wolf wrote:
Am 16.11.2023 um 11:33 hat Mark Cave-Ayland geschrieben:
This series adds a simple implementation of legacy/native mode switching
for PCI
IDE controllers and updates the via-ide device to use it.
The approach I
eft out of this conversation... Did Google or some other
spam filter decide again to filter my messages so you did not see them at
all? Could you confitm that you've got my previous two replies in this
thread so I know I'm not sending comments to /dev/null please?
Regards,
BALATON Zoltan
just the
same as ide_init_ioport without the ISADevice *dev argument and
isa_register_portio_list inlined. The only thing isa_register_portio_list
has is an additional call to isa_init_ioport but maybe that could be done
separately then ide_init_ioport is not dependent on ISA any more so can be
mo
On Mon, 13 Nov 2023, Mark Cave-Ayland wrote:
On 07/11/2023 10:43, Kevin Wolf wrote:
Am 06.11.2023 um 17:13 hat BALATON Zoltan geschrieben:
On Mon, 6 Nov 2023, Kevin Wolf wrote:
Am 25.10.2023 um 00:40 hat Mark Cave-Ayland geschrieben:
Allow the VIA IDE controller to switch between both legacy
he PCI BARs are unspecified, but this is not an issue since if a PCI
IDE
controller has been switched to native mode then its BARs will need to
be
programmed.
Signed-off-by: Mark Cave-Ayland
Tested-by: BALATON Zoltan
Tested-by: Bernhard Beschow
---
hw/ide/pci
/cover.1697661160.git.bala...@eik.bme.hu/4095e01f4596e77a478759161ae736f0c398600a.1697661160.git.bala...@eik.bme.hu/
instead for 8.2. But we still have a few weeks to sort this out if this
isn't the last chance to fix it so maybe wait for updated series from
Mark for now?
Regards,
BALATON Zoltan
mode.
Signed-off-by: Mark Cave-Ayland
Tested-by: BALATON Zoltan
Tested-by: Bernhard Beschow
As I already noted in patch 1, the interrupt handling seems to be wrong
here, it continues to use the ISA IRQ in via_ide_set_irq() even after
switching to native mode.
That's a peculiarity of thi
org/QEMU/cover.1697661160.git.bala...@eik.bme.hu/4095e01f4596e77a478759161ae736f0c398600a.1697661160.git.bala...@eik.bme.hu/
but Mark wanted to make it more general for possible use in other devices
at some point.)
Regards,
BALATON Zoltan
somebody looking at merging this series in
time for next release? Only one week left until the freeze.
Regards,
BALATON Zoltan
The approach I take here is to add a new pci_ide_update_mode() function which
handles
management of the PCI BARs and legacy IDE ioports for each mode to avoid
exposing
l PCI bus reset clears the values of all PCI device BARs
after the device itself has been reset.
Remove the setting of the default BAR addresses from via_ide_reset() to ensure
there is no doubt that these values are never exposed to the guest.
Suggested-by: BALATON Zoltan
this was taken fr
On Mon, 23 Oct 2023, Mark Cave-Ayland wrote:
On 20/10/2023 00:09, BALATON Zoltan wrote:
On Thu, 19 Oct 2023, Mark Cave-Ayland wrote:
Allow the VIA IDE controller to switch between both legacy and native
modes by
calling pci_ide_update_mode() to reconfigure the device whenever
PCI_CLASS_PROG
o the via-ide device) which is good enough for Zoltan's PPC
images whilst paving the way for future improvements after 8.2.
Signed-off-by: Mark Cave-Ayland
Tested-by: BALATON Zoltan
Thank you for finishing these. I've verified that AmigaOS and MorphOS
and Linux still boot on pegas
the intrerrupt pin
because pci_ide_update_mode will set it above so I think this line could
just use pci_set_byte() to set the PCI_INTERRUPT_LINE only now. (Although
it still contradicts the VT8231 data sheet about the interrupt pin default
value but I don't care as long as it works.)
board code:
mc->block_default_type = IF_IDE; Isn't that the default used if no "if"
property given?
Maybe I don't understand how this works but if it makes less convenient
for users and breaks their scripts then I don't think it's a good idea.
Regards,
BALATON Zoltan
curious why it's there in this case?
Regards,
BALATON Zoltan
#endif
Background - Motivation
===
The C switch statement allows you to conditionally goto different labels
depending on a value. A break; statement conveniently goto's the end of
the switch. If a "case
set_word(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
Commit message is way longer than the patch itself and very detailed but I
may have lost in the details. If all 32 bits should be writtern does this
need pci_set_long instead of pci_set_word?
Regards,
BALATON Zoltan
}
static bool pci_piix
On Sun, 21 May 2023, BALATON Zoltan wrote:
On Sun, 21 May 2023, Bernhard Beschow wrote:
Resolves circular depencency between IDE function and south bridge.
Signed-off-by: Bernhard Beschow
Reviewed-by: Mark Cave-Ayland
---
hw/ide/via.c | 6 --
hw/isa/vt82c686.c | 5 +
2 files
On Sun, 21 May 2023, Bernhard Beschow wrote:
The modern, declarative way to set up VM state handling is to assign to
DeviceClass::vmsd attribute.
There shouldn't be any change in behavior since dc->vmsd causes
vmstate_register_with_alias_id() to be called on the instance during
the instance init
On Sun, 21 May 2023, Bernhard Beschow wrote:
Every TYPE_PCI_IDE device performs the same not-so-trivial bit manipulation by
copy'n'paste code. Extract this into bmdma_status_writeb(), mirroring
bmdma_cmd_writeb().
Signed-off-by: Bernhard Beschow
Reviewed-by: BALATON Zoltan
e structure so can be cast into each other but for
consistency it's better to also change
qdev_init_gpio_in(ds, via_ide_set_irq, ARRAY_SIZE(d->bus));
to pass the PCIIDEState so d instead of ds in via_ide_realize().
Regards,
BALATON Zoltan
if (level) {
d->config[0x70 + n
t does not really have one... Then
no idea.)
I don't know this well and did not follow it too deeply so in case I've
completely misunderstood it or missed an important detail then just
disregard all of the above.
Regards,
BALATON Zoltan
On Thu, 27 Apr 2023, Mark Cave-Ayland wrote:
On 27/04/2023 00:24, BALATON Zoltan wrote:
On Wed, 26 Apr 2023, Bernhard Beschow wrote:
Am 26. April 2023 11:41:54 UTC schrieb Mark Cave-Ayland
:
On 22/04/2023 16:07, Bernhard Beschow wrote:
Allows to unexport pci_ide_{cmd,data}_le_ops and models
1 - 100 of 267 matches
Mail list logo