From: Bjorn Helgaas <helgaas@kernel.org>
To: Sui Jingfeng <suijingfeng@loongson.cn>
Cc: Li Yi <liyi@loongson.cn>,
etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
Russell King <linux+etnaviv@armlinux.org.uk>,
Bjorn Helgaas <bhelgaas@google.com>,
Sui Jingfeng <15330273260@189.cn>
Subject: Re: [PATCH v8 6/8] drm/etnaviv: add driver support for the PCI devices
Date: Fri, 9 Jun 2023 14:46:21 -0500 [thread overview]
Message-ID: <20230609194621.GA1257228@bhelgaas> (raw)
In-Reply-To: <79e07134-4f89-22dd-5a9c-3c8dfac50bf2@loongson.cn>
On Sat, Jun 10, 2023 at 02:07:58AM +0800, Sui Jingfeng wrote:
> On 2023/6/10 01:52, Bjorn Helgaas wrote:
> > On Fri, Jun 09, 2023 at 09:37:02AM +0800, Sui Jingfeng wrote:
> > > On 2023/6/9 01:32, Bjorn Helgaas wrote:
> > > > On Wed, Jun 07, 2023 at 06:55:49PM +0800, Sui Jingfeng wrote:
> > > > > From: Sui Jingfeng <suijingfeng@loongson.cn>
> > > > >
> > > > > This patch adds PCI driver support on top of what we already have. Take
> > > > > the GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device
> > > > > driver. There is only one GPU core for the GC1000 in the LS7A1000 and
> > > > > LS2K1000. Therefore, component frameworks can be avoided.
> > > > > + {PCI_VENDOR_ID_LOONGSON, 0x7a15, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> > > > > + {PCI_VENDOR_ID_LOONGSON, 0x7a05, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> > > > PCI_VDEVICE()
> > > This make it impossible to hook device-specific data in the future.
> > >
> > > But currently there no device specific data associated with the
> > > 0x7a05 and 0x7a15,
> > >
> > > so it's acceptable for now. Thanks.
> > Haha, ISTR having this conversation before, sorry for repeating it.
> >
> > Indeed, it's fine as-is. But PCI_VDEVICE() actually *does* allow for
> > vendor-specific data because it doesn't include the data element,
> > which defaults to zero if you don't specify it.
> >
> > So for example, drivers/net/ethernet/realtek/r8169_main.c has this:
> >
> > { PCI_VDEVICE(REALTEK, 0x8129) },
> > { PCI_VDEVICE(REALTEK, 0x8136), RTL_CFG_NO_GBIT },
> >
> > where 0x8129 has no driver_data (it defaults to zero), but 0x8136
> > does.
>
> PCI_VDEVICE macro end with two zero. (I thought it was three)
No worries, I thought the same thing the first five times I read it :)
next prev parent reply other threads:[~2023-06-09 19:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 10:55 [PATCH v8 0/8] drm/etnaviv: add pci device driver support Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 1/8] drm/etnaviv: add a dedicated function to register an irq handler Sui Jingfeng
2023-06-08 17:25 ` Bjorn Helgaas
2023-06-09 1:23 ` Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 2/8] drm/etnaviv: add a dedicated function to get various clocks Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 3/8] drm/etnaviv: add dedicated functions to create and destroy platform devices Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 4/8] drm/etnaviv: add helpers for private data construction and destruction Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 5/8] drm/etnaviv: allow bypass component framework Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 6/8] drm/etnaviv: add driver support for the PCI devices Sui Jingfeng
2023-06-08 17:32 ` Bjorn Helgaas
2023-06-09 1:37 ` Sui Jingfeng
2023-06-09 17:52 ` Bjorn Helgaas
2023-06-09 18:07 ` Sui Jingfeng
2023-06-09 19:46 ` Bjorn Helgaas [this message]
2023-06-07 10:55 ` [PATCH v8 7/8] drm/etnaviv: add support for the dma coherent device Sui Jingfeng
2023-06-07 10:55 ` [PATCH v8 8/8] drm/etnaviv: add a dedicated function to create the virtual master Sui Jingfeng
2023-06-09 3:55 ` [PATCH v8 0/8] drm/etnaviv: add pci device driver support Sui Jingfeng
2023-06-12 14:23 ` Sui Jingfeng
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=20230609194621.GA1257228@bhelgaas \
--to=helgaas@kernel.org \
--cc=15330273260@189.cn \
--cc=bhelgaas@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=liyi@loongson.cn \
--cc=suijingfeng@loongson.cn \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).