Hi Sam,
Okay, I think what you proposed works out for me, although adding 20+ files, one by one, is a pain. I wish there is a way to automate this. FWIW, this is how I did it.
________ 1) Create a new branch from the current one just for sending the patches
$ git branch Code_Review_1
2) Switch to the new branch
$ git checkout Code_Review_1
3) Copy original drivers/gpu/drm/via/ contents (i.e., *.c, *.h, Kconfig, and Makefile) and include/uapi/drm/via_drm.h 4) Delete drivers/gpu/drm/via/ contents and include/uapi/drm/via_drm.h 5) Delete from DRM core make file (Makefile) located at drivers/gpu/drm/ its OpenChrome DRM build switch
. . . obj-$(CONFIG_DRM_OPENCHROME) +=via/ . . .
6) Commit the change (Note: this commit will not be posted as a patch)
$ git commit -as
7) Move back the preserved files to drivers/gpu/drm/via/ (i.e., *.c, *.h, Kconfig, Makefile) and include/uapi/drm/ (i.e., via_drm.h) 8) Add and commit *.h located at drivers/gpu/drm/via/ one file at a time
$ git add drivers/gpu/drm/via/("Name of the file").h $ git commit -as
9) Add and commit *.c located at drivers/gpu/drm/via/ one file at a time
$ git add drivers/gpu/drm/via/("Name of the file").c $ git commit -as
10) Add and commit via_drm.h located at include/uapi/drm/
$ git add include/uapi/drm/via_drm.h $ git commit -as
11) Commit Kconfig located at drivers/gpu/drm/via/
$ git add drivers/gpu/drm/via/Kconfig $ git commit -as
12) Commit Makefile located at drivers/gpu/drm/via/
$ git add drivers/gpu/drm/via/Makefile $ git commit -as
13) Add back to DRM core make file (Makefile) located at drivers/gpu/drm/ the OpenChrome DRM build switch
. . . obj-$(CONFIG_DRM_OPENCHROME) +=via/ . . .
14) Commit the change
$ git commit -as
15) Generate the commits as patches
$ git format-patch -28
The (-28) may be adjusted to match the number of relevant commits. It is basically derived from,
- 26 files under drivers/gpu/drm/via/ - 1 file under include/uapi/drm/ - 1 commit to change Makefile located at drivers/gpu/drm/
The first commit that deletes the relevant files should not be included in the patch being generated here. ________
I wish there is a easier, more automated way of doing this, but at least this is the best I can do for now. I will likely e-mail the mailing list the code in patch form shortly.
Regards,
Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com
Sent: Wednesday, June 22, 2022 at 1:06 PM From: "Sam Ravnborg" sam@ravnborg.org To: "Kevin Brace" kevinbrace@gmx.com Cc: dri-devel@lists.freedesktop.org Subject: Re: How do I gather up new code to be converted as patches?
Hi Kevin,
On Wed, Jun 22, 2022 at 07:18:58PM +0200, Kevin Brace wrote:
Hi,
How to I use git to gather up new code to be converted to patches? Specifically, I have 20+ new files in one location (drivers/gpu/drm/via) and a small change to DRM main make file (drivers/gpu/drm/Makefile).
One simple way to do this is to start with a clean tree, and then add files step by step. 20+ files in one patch is too much to review, so decide for a reasonable split between the files.
Maybe something like (as inspiration find your own split): 0) Documentation - or add this in you cover letter. Enough info to give the reader a rough understanding of the HW and the driver structure.
- Driver files
- Util files
- Files for the memory handling
- Files for irq handling
- HW specific files
- A the final patch - the Kconfig, and Makefile adjustments.
It is important that the final patch is final as you would otherwise break the build.
I look forward to see the patches!
Sam