Match the style of the main i915 Makefile in the gvt-specfic one and
remove the GVT_DIR and GVT_SOURCE variables.
Signed-off-by: Christoph Hellwig <[email protected]>
---
drivers/gpu/drm/i915/gvt/Makefile | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
index 4d70f4689479c..f2f6ea02714ec 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,8 +1,25 @@
# SPDX-License-Identifier: GPL-2.0
-GVT_DIR := gvt
-GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
- interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
- execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \
- fb_decoder.o dmabuf.o page_track.o
-i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
+i915-y += \
+ gvt/gvt.o \
+ gvt/aperture_gm.o \
+ gvt/handlers.o \
+ gvt/vgpu.o \
+ gvt/trace_points.o \
+ gvt/firmware.o \
+ gvt/interrupt.o \
+ gvt/gtt.o \
+ gvt/cfg_space.o \
+ gvt/opregion.o \
+ gvt/mmio.o \
+ gvt/display.o \
+ gvt/edid.o \
+ gvt/execlist.o \
+ gvt/scheduler.o \
+ gvt/sched_policy.o \
+ gvt/mmio_context.o \
+ gvt/cmd_parser.o \
+ gvt/debugfs.o \
+ gvt/fb_decoder.o \
+ gvt/dmabuf.o \
+ gvt/page_track.o
--
2.30.2
On Mon, 11 Apr 2022, Jason Gunthorpe <[email protected]> wrote:
> On Mon, Apr 11, 2022 at 04:13:34PM +0200, Christoph Hellwig wrote:
>> Match the style of the main i915 Makefile in the gvt-specfic one and
>> remove the GVT_DIR and GVT_SOURCE variables.
>>
>> Signed-off-by: Christoph Hellwig <[email protected]>
>> drivers/gpu/drm/i915/gvt/Makefile | 29 +++++++++++++++++++++++------
>> 1 file changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
>> index 4d70f4689479c..f2f6ea02714ec 100644
>> +++ b/drivers/gpu/drm/i915/gvt/Makefile
>> @@ -1,8 +1,25 @@
>> # SPDX-License-Identifier: GPL-2.0
>> -GVT_DIR := gvt
>> -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
>> - interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>> - execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \
>> - fb_decoder.o dmabuf.o page_track.o
>>
>> -i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
>> +i915-y += \
>> + gvt/gvt.o \
>> + gvt/aperture_gm.o \
>> + gvt/handlers.o \
>> + gvt/vgpu.o \
>> + gvt/trace_points.o \
>> + gvt/firmware.o \
>> + gvt/interrupt.o \
>> + gvt/gtt.o \
>> + gvt/cfg_space.o \
>> + gvt/opregion.o \
>> + gvt/mmio.o \
>> + gvt/display.o \
>> + gvt/edid.o \
>> + gvt/execlist.o \
>> + gvt/scheduler.o \
>> + gvt/sched_policy.o \
>> + gvt/mmio_context.o \
>> + gvt/cmd_parser.o \
>> + gvt/debugfs.o \
>> + gvt/fb_decoder.o \
>> + gvt/dmabuf.o \
>> + gvt/page_track.o
>
> Up to you but I usually sort these lists
Yeah, please do. Otherwise matches what I sent, so ack.
BR,
Jani.
>
> Reviewed-by: Jason Gunthorpe <[email protected]>
>
> Jason
--
Jani Nikula, Intel Open Source Graphics Center
On Mon, Apr 11, 2022 at 04:13:34PM +0200, Christoph Hellwig wrote:
> Match the style of the main i915 Makefile in the gvt-specfic one and
> remove the GVT_DIR and GVT_SOURCE variables.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> drivers/gpu/drm/i915/gvt/Makefile | 29 +++++++++++++++++++++++------
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
> index 4d70f4689479c..f2f6ea02714ec 100644
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -1,8 +1,25 @@
> # SPDX-License-Identifier: GPL-2.0
> -GVT_DIR := gvt
> -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
> - interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
> - execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \
> - fb_decoder.o dmabuf.o page_track.o
>
> -i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
> +i915-y += \
> + gvt/gvt.o \
> + gvt/aperture_gm.o \
> + gvt/handlers.o \
> + gvt/vgpu.o \
> + gvt/trace_points.o \
> + gvt/firmware.o \
> + gvt/interrupt.o \
> + gvt/gtt.o \
> + gvt/cfg_space.o \
> + gvt/opregion.o \
> + gvt/mmio.o \
> + gvt/display.o \
> + gvt/edid.o \
> + gvt/execlist.o \
> + gvt/scheduler.o \
> + gvt/sched_policy.o \
> + gvt/mmio_context.o \
> + gvt/cmd_parser.o \
> + gvt/debugfs.o \
> + gvt/fb_decoder.o \
> + gvt/dmabuf.o \
> + gvt/page_track.o
Up to you but I usually sort these lists
Reviewed-by: Jason Gunthorpe <[email protected]>
Jason
On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
> > Up to you but I usually sort these lists
>
> Yeah, please do. Otherwise matches what I sent, so ack.
Let's just merge your 2 patch series ASAP and I'll rebase on top of
that.
What branch in drm-intel should I use as the base for the next version
btw? Or does gvt go through yet another tree?
On 4/13/22 12:33 PM, Jani Nikula wrote:
> On Mon, 11 Apr 2022, Christoph Hellwig <[email protected]> wrote:
>> On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
>>>> Up to you but I usually sort these lists
>>>
>>> Yeah, please do. Otherwise matches what I sent, so ack.
>>
>> Let's just merge your 2 patch series ASAP and I'll rebase on top of
>> that.
>
> I rebased them on top of current gvt-next and resent [1]. Zhenyu, Zhi,
> please pick them up if you approve.
>
>> What branch in drm-intel should I use as the base for the next version
>> btw? Or does gvt go through yet another tree?
>
> It's yet another tree... Basically gvt is developed on top of gvt-next
> (see MAINTAINERS) and Zhenyu and Zhi send pull requests for
> drm-intel-next.
>
Hi Jani and Christoph:
It seems Jani's makefile clean patch has already included this one, I can
just simply drop this one so that Christoph won't need to re-send everything.
For the branch to move on, I am merging the patches and will re-generate the
gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
gvt branches.
If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
gvt-staging branch until my pull request landed in drm-intel-next.
Also our QA will test gvt-staging-branch before the pull request. I suppose
it will take one or two days.
Again, thanks so much for making this happen.
Thanks,
Zhi.
> > BR,
> Jani.
>
>
> [1] https://lore.kernel.org/all/[email protected]
>
On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
>
>> It seems Jani's makefile clean patch has already included this one, I can
>> just simply drop this one so that Christoph won't need to re-send everything.
>>
>> For the branch to move on, I am merging the patches and will re-generate the
>> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
>> gvt branches.
>>
>> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
>> gvt-staging branch until my pull request landed in drm-intel-next.
>>
>> Also our QA will test gvt-staging-branch before the pull request. I suppose
>> it will take one or two days.
>
> When you are wrangling the branches it would be great if Christoph's
> series and it's minimal dependencies could be on a single branch that
> could reasonably be pulled to the VFIO tree too, thanks
>
> Jason
>
Hi Jason:
I am thinking about the process of merging process. Here are the dependence:
1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
go through drm.
My patches of GVT-g will go through drm-intel-next -> drm -> upstream.
2) Christoph's patches depends on my patches, but part of them are for VFIO.
a. If they are fully going through VFIO repo, they might have to wait my
patches to get landed first.
b. If only the GVT-g parts goes through GVT repo, and rest of them goes
through VFIO, the rest part still needs to wait.
What would be a better process?
Thanks,
Zhi.
On Mon, 11 Apr 2022, Christoph Hellwig <[email protected]> wrote:
> On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
>> > Up to you but I usually sort these lists
>>
>> Yeah, please do. Otherwise matches what I sent, so ack.
>
> Let's just merge your 2 patch series ASAP and I'll rebase on top of
> that.
I rebased them on top of current gvt-next and resent [1]. Zhenyu, Zhi,
please pick them up if you approve.
> What branch in drm-intel should I use as the base for the next version
> btw? Or does gvt go through yet another tree?
It's yet another tree... Basically gvt is developed on top of gvt-next
(see MAINTAINERS) and Zhenyu and Zhi send pull requests for
drm-intel-next.
BR,
Jani.
[1] https://lore.kernel.org/all/[email protected]
--
Jani Nikula, Intel Open Source Graphics Center
On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> It seems Jani's makefile clean patch has already included this one, I can
> just simply drop this one so that Christoph won't need to re-send everything.
>
> For the branch to move on, I am merging the patches and will re-generate the
> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> gvt branches.
>
> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> gvt-staging branch until my pull request landed in drm-intel-next.
>
> Also our QA will test gvt-staging-branch before the pull request. I suppose
> it will take one or two days.
When you are wrangling the branches it would be great if Christoph's
series and it's minimal dependencies could be on a single branch that
could reasonably be pulled to the VFIO tree too, thanks
Jason
On Wed, Apr 13, 2022 at 02:26:23PM +0000, Wang, Zhi A wrote:
> On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> >
> >> It seems Jani's makefile clean patch has already included this one, I can
> >> just simply drop this one so that Christoph won't need to re-send everything.
> >>
> >> For the branch to move on, I am merging the patches and will re-generate the
> >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> >> gvt branches.
> >>
> >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> >> gvt-staging branch until my pull request landed in drm-intel-next.
> >>
> >> Also our QA will test gvt-staging-branch before the pull request. I suppose
> >> it will take one or two days.
> >
> > When you are wrangling the branches it would be great if Christoph's
> > series and it's minimal dependencies could be on a single branch that
> > could reasonably be pulled to the VFIO tree too, thanks
> >
> > Jason
> >
>
> Hi Jason:
>
> I am thinking about the process of merging process. Here are the dependence:
>
> 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> go through drm.
> My patches of GVT-g will go through drm-intel-next -> drm -> upstream.
>
> 2) Christoph's patches depends on my patches, but part of them are for VFIO.
>
> a. If they are fully going through VFIO repo, they might have to wait my
> patches to get landed first.
>
> b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> through VFIO, the rest part still needs to wait.
>
> What would be a better process?
You should organize everything onto one simple branch based on a rc to
make this all work.
Make your #1 patch as a single patch PR based on rc to drm-intel so it
gets to the right tree
Make your MMIO series as PR on the branch above that first PR and merge to
the gvt tree
Make Christoph's series as a PR on the branch above the second PR's
MMIO series and merge to the gvt tree
Merge the gvt toward DRM in the normal way - ie the main merge path for
this should be through DRM.
Then ask Alex to merge the 3rd PR as well.
I don't see any intel-next stuff in linux-next yet so hopefully it is
early enough to get #1 OK.
Jason
+ Tvrtko
Quoting Jason Gunthorpe (2022-04-13 17:45:48)
> On Wed, Apr 13, 2022 at 02:26:23PM +0000, Wang, Zhi A wrote:
> > On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> > >
> > >> It seems Jani's makefile clean patch has already included this one, I can
> > >> just simply drop this one so that Christoph won't need to re-send everything.
> > >>
> > >> For the branch to move on, I am merging the patches and will re-generate the
> > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> > >> gvt branches.
> > >>
> > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> > >> gvt-staging branch until my pull request landed in drm-intel-next.
> > >>
> > >> Also our QA will test gvt-staging-branch before the pull request. I suppose
> > >> it will take one or two days.
> > >
> > > When you are wrangling the branches it would be great if Christoph's
> > > series and it's minimal dependencies could be on a single branch that
> > > could reasonably be pulled to the VFIO tree too, thanks
> > >
> > > Jason
> > >
> >
> > Hi Jason:
> >
> > I am thinking about the process of merging process. Here are the dependence:
> >
> > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> > go through drm.
> > My patches of GVT-g will go through drm-intel-next -> drm -> upstream.
> >
> > 2) Christoph's patches depends on my patches, but part of them are for VFIO.
> >
> > a. If they are fully going through VFIO repo, they might have to wait my
> > patches to get landed first.
> >
> > b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> > through VFIO, the rest part still needs to wait.
> >
> > What would be a better process?
>
> You should organize everything onto one simple branch based on a rc to
> make this all work.
>
> Make your #1 patch as a single patch PR based on rc to drm-intel so it
> gets to the right tree
>
> Make your MMIO series as PR on the branch above that first PR and merge to
> the gvt tree
>
> Make Christoph's series as a PR on the branch above the second PR's
> MMIO series and merge to the gvt tree
>
> Merge the gvt toward DRM in the normal way - ie the main merge path for
> this should be through DRM.
>
> Then ask Alex to merge the 3rd PR as well.
>
> I don't see any intel-next stuff in linux-next yet so hopefully it is
> early enough to get #1 OK.
>
> Jason