From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9CDB3C54E76 for ; Mon, 20 Nov 2023 11:10:39 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r52A8-0001k3-8R; Mon, 20 Nov 2023 06:09:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r52A0-0001jc-Lu; Mon, 20 Nov 2023 06:09:50 -0500 Received: from zero.eik.bme.hu ([2001:738:2001:2001::2001]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r529n-00014N-Av; Mon, 20 Nov 2023 06:09:47 -0500 Received: from zero.eik.bme.hu (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 191B875A406; Mon, 20 Nov 2023 12:10:06 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 0AA7875607B; Mon, 20 Nov 2023 12:10:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 0821E756066; Mon, 20 Nov 2023 12:10:06 +0100 (CET) Date: Mon, 20 Nov 2023 12:10:05 +0100 (CET) From: BALATON Zoltan To: Kevin Wolf cc: Mark Cave-Ayland , jsnow@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, philmd@linaro.org, shentey@gmail.com Subject: Re: [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers In-Reply-To: Message-ID: <0ce24a22-c4d4-ab8d-fc59-6d5655de9506@eik.bme.hu> References: <20231116103355.588580-1-mark.cave-ayland@ilande.co.uk> <48c8863d-6534-eae2-4cba-089cc4fb6a6d@eik.bme.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV using ClamSMTP Received-SPF: pass client-ip=2001:738:2001:2001::2001; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org 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 >>>>> >>>>> [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