Re: [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers

[BALATON Zoltan]

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-ayland@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