From: Bernhard Beschow <shentey@gmail.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
jsnow@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
balaton@eik.bme.hu, philmd@linaro.org
Subject: Re: [PATCH 1/2] ide/pci.c: introduce pci_ide_update_mode() function
Date: Tue, 24 Oct 2023 07:08:23 +0000 [thread overview]
Message-ID: <15CDD7B3-CDCC-4E41-B35C-4EC510CFBA0D@gmail.com> (raw)
In-Reply-To: <2601c66e-bd00-4df6-8a74-c8b2f81b052d@ilande.co.uk>
Am 23. Oktober 2023 21:06:11 UTC schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
>On 23/10/2023 18:19, Bernhard Beschow wrote:
>
>> Am 22. Oktober 2023 22:06:30 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>>>
>>>
>>> Am 19. Oktober 2023 13:04:51 UTC schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
>>>> This function reads the value of the PCI_CLASS_PROG register for PCI IDE
>>>> controllers and configures the PCI BARs and/or IDE ioports accordingly.
>>>>
>>>> In the case where we switch to legacy mode, the PCI BARs are set to return zero
>>>> (as suggested in the "PCI IDE Controller" specification), the legacy IDE ioports
>>>> are enabled, and the PCI interrupt pin cleared to indicate legacy IRQ routing.
>>>>
>>>> Conversely when we switch to native mode, the legacy IDE ioports are disabled
>>>> and the PCI interrupt pin set to indicate native IRQ routing. The contents of
>>>> the 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 <mark.cave-ayland@ilande.co.uk>
>>>> ---
>>>> hw/ide/pci.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
>>>> include/hw/ide/pci.h | 1 +
>>>> 2 files changed, 91 insertions(+)
>>>>
>>>> diff --git a/hw/ide/pci.c b/hw/ide/pci.c
>>>> index a25b352537..9eb30af632 100644
>>>> --- a/hw/ide/pci.c
>>>> +++ b/hw/ide/pci.c
>>>> @@ -104,6 +104,96 @@ const MemoryRegionOps pci_ide_data_le_ops = {
>>>> .endianness = DEVICE_LITTLE_ENDIAN,
>>>> };
>>>>
>>>> +static const MemoryRegionPortio ide_portio_list[] = {
>>>> + { 0, 8, 1, .read = ide_ioport_read, .write = ide_ioport_write },
>>>> + { 0, 1, 2, .read = ide_data_readw, .write = ide_data_writew },
>>>> + { 0, 1, 4, .read = ide_data_readl, .write = ide_data_writel },
>>>> + PORTIO_END_OF_LIST(),
>>>> +};
>>>> +
>>>> +static const MemoryRegionPortio ide_portio2_list[] = {
>>
>> Although the naming seems familiar: What about renaming both lists to something like ide_portio_primary_list resp. ide_portio_secondary_list? Having one list carrying a number in its name while omitting it for the other I find rather confusing.
>
>The two different portio_lists don't represent the primary and secondary interfaces though: they represent the command and data ports for a single interface.
Ah, right.
> I've left the naming as-is (at least for now) so that all of the IDEBus fields, ISA IDE ioports and PCI IDE ioports all share the same naming convention.
Okay. At some point we should really harmonize the names to avoid above confusion. The PCI IDE BAR code does a much better job at naming and could serve as a template. Then all IDE code would clearly communicate that these are all the same concepts. I could send a patch for it once this series is in.
>
>>>> + { 0, 1, 1, .read = ide_status_read, .write = ide_ctrl_write },
>>>> + PORTIO_END_OF_LIST(),
>>>> +};
>>>> +
>>>> +void pci_ide_update_mode(PCIIDEState *s)
>>>> +{
>>>> + PCIDevice *d = PCI_DEVICE(s);
>>>> + uint8_t mode = d->config[PCI_CLASS_PROG];
>>>> +
>>>> + switch (mode) {
>>>
>>> Maybe
>>>
>>> switch (mode & 0xf) {
>>>
>>> here such that only the bits relevant to the PCI IDE controller specification are analyzed?
Due to the above conversation I realize that s->bus[] could be iterated over such that only the two bits of each bus could be switch()ed over. This would avoid some duplicate code, model the specification closer and allow for catching illegal states. Illegal states could be logged as guest errors. But it would also complicate dealing with the interrupt pin. So this might be a future extension.
Best regards,
Bernhard
>>> Then we can omit the high '8' nibble in the case labels which indicate bus master capability which is obviously out of scope of the switch statement (since you're not touching the BM DMA BAR).
>>>
>>>> + case 0x8a:
>>>
>>> Perhaps we could add a
>>>
>>> case 0x0:
>>>
>>> in front of the above label for compatibility with PIIX-IDE? That way, this function could be reused in the future for resetting PIIX-IDE.
>>>
>>>> + /* Both channels legacy mode */
>>>> +
>>>> + /* Zero BARs */
>>>> + pci_set_long(d->config + PCI_BASE_ADDRESS_0, 0x0);
>>>> + pci_set_long(d->config + PCI_BASE_ADDRESS_1, 0x0);
>>>> + pci_set_long(d->config + PCI_BASE_ADDRESS_2, 0x0);
>>>> + pci_set_long(d->config + PCI_BASE_ADDRESS_3, 0x0);
>>>> +
>>>> + /* Clear interrupt pin */
>>>> + pci_config_set_interrupt_pin(d->config, 0);
>>>
>>> Do we really need to toggle the interrupt pin in this function? Or is this VIA-specific? This byte isn't even defined for PIIX-IDE.
>>>
>>> Best regards,
>>> Bernhard
>>>
>>>> +
>>>> + /* Add legacy IDE ports */
>>>> + if (!s->bus[0].portio_list.owner) {
>>>> + portio_list_init(&s->bus[0].portio_list, OBJECT(d),
>>>> + ide_portio_list, &s->bus[0], "ide");
>>>> + portio_list_add(&s->bus[0].portio_list,
>>>> + pci_address_space_io(d), 0x1f0);
>>>> + }
>>>> +
>>>> + if (!s->bus[0].portio2_list.owner) {
>>>> + portio_list_init(&s->bus[0].portio2_list, OBJECT(d),
>>>> + ide_portio2_list, &s->bus[0], "ide");
>>>> + portio_list_add(&s->bus[0].portio2_list,
>>>> + pci_address_space_io(d), 0x3f6);
>>>> + }
>>>> +
>>>> + if (!s->bus[1].portio_list.owner) {
>>>> + portio_list_init(&s->bus[1].portio_list, OBJECT(d),
>>>> + ide_portio_list, &s->bus[1], "ide");
>>>> + portio_list_add(&s->bus[1].portio_list,
>>>> + pci_address_space_io(d), 0x170);
>>>> + }
>>>> +
>>>> + if (!s->bus[1].portio2_list.owner) {
>>>> + portio_list_init(&s->bus[1].portio2_list, OBJECT(d),
>>>> + ide_portio2_list, &s->bus[1], "ide");
>>>> + portio_list_add(&s->bus[1].portio2_list,
>>>> + pci_address_space_io(d), 0x376);
>>>> + }
>>>> + break;
>>>> +
>>>> + case 0x8f:
>>>> + /* Both channels native mode */
>>>> +
>>>> + /* Set interrupt pin */
>>>> + pci_config_set_interrupt_pin(d->config, 1);
>>>> +
>>>> + /* Remove legacy IDE ports */
>>>> + if (s->bus[0].portio_list.owner) {
>>>> + portio_list_del(&s->bus[0].portio_list);
>>>> + portio_list_destroy(&s->bus[0].portio_list);
>>>> + }
>>>> +
>>>> + if (s->bus[0].portio2_list.owner) {
>>>> + portio_list_del(&s->bus[0].portio2_list);
>>>> + portio_list_destroy(&s->bus[0].portio2_list);
>>>> + }
>>>> +
>>>> + if (s->bus[1].portio_list.owner) {
>>>> + portio_list_del(&s->bus[1].portio_list);
>>>> + portio_list_destroy(&s->bus[1].portio_list);
>>>> + }
>>>> +
>>>> + if (s->bus[1].portio2_list.owner) {
>>>> + portio_list_del(&s->bus[1].portio2_list);
>>>> + portio_list_destroy(&s->bus[1].portio2_list);
>>>> + }
>>>> + break;
>>>> + }
>>>> +}
>>>> +
>>>> static IDEState *bmdma_active_if(BMDMAState *bmdma)
>>>> {
>>>> assert(bmdma->bus->retry_unit != (uint8_t)-1);
>>>> diff --git a/include/hw/ide/pci.h b/include/hw/ide/pci.h
>>>> index 1ff469de87..a814a0a7c3 100644
>>>> --- a/include/hw/ide/pci.h
>>>> +++ b/include/hw/ide/pci.h
>>>> @@ -61,6 +61,7 @@ void bmdma_cmd_writeb(BMDMAState *bm, uint32_t val);
>>>> void bmdma_status_writeb(BMDMAState *bm, uint32_t val);
>>>> extern MemoryRegionOps bmdma_addr_ioport_ops;
>>>> void pci_ide_create_devs(PCIDevice *dev);
>>>> +void pci_ide_update_mode(PCIIDEState *s);
>>>>
>>>> extern const VMStateDescription vmstate_ide_pci;
>>>> extern const MemoryRegionOps pci_ide_cmd_le_ops;
>
>
>ATB,
>
>Mark.
>
next prev parent reply other threads:[~2023-10-24 7:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 13:04 [PATCH 0/2] ide: implement simple legacy/native mode switching for PCI IDE controllers Mark Cave-Ayland
2023-10-19 13:04 ` [PATCH 1/2] ide/pci.c: introduce pci_ide_update_mode() function Mark Cave-Ayland
2023-10-22 22:06 ` Bernhard Beschow
2023-10-23 17:19 ` Bernhard Beschow
2023-10-23 21:06 ` Mark Cave-Ayland
2023-10-24 7:08 ` Bernhard Beschow [this message]
2023-10-24 20:52 ` Mark Cave-Ayland
2023-10-23 18:01 ` Mark Cave-Ayland
2023-10-19 13:04 ` [PATCH 2/2] hw/ide/via: implement legacy/native mode switching Mark Cave-Ayland
2023-10-19 23:09 ` BALATON Zoltan
2023-10-23 21:56 ` Mark Cave-Ayland
2023-10-23 22:31 ` BALATON Zoltan
2023-10-19 23:14 ` [PATCH 0/2] ide: implement simple legacy/native mode switching for PCI IDE controllers BALATON Zoltan
2023-10-22 22:10 ` Bernhard Beschow
2023-10-23 18:03 ` Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15CDD7B3-CDCC-4E41-B35C-4EC510CFBA0D@gmail.com \
--to=shentey@gmail.com \
--cc=balaton@eik.bme.hu \
--cc=jsnow@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).