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 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()
function which handles
management of the PCI BARs and legacy IDE ioports for each mode
to avoid exposing
details of the internal logic to individual PCI IDE controllers.
As noted in [1] this is extracted from a local WIP branch I have
which contains
further work in this area. However for the moment I've kept it simple (and
restricted it to 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 <mark.cave-ayl...@ilande.co.uk>
[1] https://lists.gnu.org/archive/html/qemu-devel/2023-10/msg05403.html
v3:
- Rebase onto master
- Move ide_portio_list[] and ide_portio_list2[] to IDE core to
prevent duplication in
hw/ide/pci.c
- Don't zero BARs when switching from native mode to legacy
mode, instead always force
them to read zero as suggested in the PCI IDE specification
(note: this also appears
to fix the fuloong2e machine booting from IDE)
- Add comments in pci_ide_update_mode() suggested by Kevin
- Drop the existing R-B and T-B tags: whilst this passes my
local tests, the behaviour
around zero BARs feels different enough here
Thanks, applied to the block branch.
I feel a bit left 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?
Looks like there's some issue with these mails. They appear in the list
archive but maybe not in people's mailboxes? Did any of you got this message
and previous ones I've sent?
https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03180.html
https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03983.html
I received it, but at least the second one only after sending the mail
you replied to here.
For your specific concern, it seems to me that resetting BAR 4 on a
switch between compatibility mode and native mode is another via quirk
and should therefore be implemented in via.c rather than pci.c?
I think in real chip the default value is there so no need to reset it
when switching mode. Also the defeult mode is legacy so writing 0x8a first
does nothing on real chip but we can't do that in QEMU becaise PCI code
resets BARs after calling device reset method so we can't set reset
degaults there but have to establish them on mode switch instead when the
BARs are yet unset. Setting the BMDMA BAR4 in via.c is fine as well and
could be done as a follow up so that's OK.
If I get a new version of the patches in the next few hours, I can
update the queued patches before sending a pull request, but otherwise
this can still be done in a separate patch.
This v3 series does not work with latest AmigaOS driver as I wrote in my
last reply. So maybe wait for a v4 or merge either v2 from Mark or my
single patch fix for now. Those are better than v3 that's queued now.
Regards,
BALATON Zoltan
