Hi

Am 23.06.22 um 21:29 schrieb Kevin Brace:

Hi Jeffrey,

I did not point to the repository I actively maintain, but since I was able to do so since 2017, I think I have figured out all of what I consider "basic" ways of using git to maintain and keep up with the upstream DRM code.

https://cgit.freedesktop.org/openchrome/drm-openchrome/

It is just that I am now at a point of posting code on dri-devel mailing list for the first code review, but I just suddenly realized that git does not appear to have a convenient way to do this. What I am trying to do is to post the code on dri-devel like the previous OpenChrome developer, James Simmons, did in 2013.

https://lists.freedesktop.org/archives/dri-devel/2013-June/039594.html

You probably want 'git send-email'. Once configured, it generates nice patchsets with cover letter and sends them automatically.

There's

https://git-scm.com/docs/git-send-email

and DRI-specific instructions at

https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/

Best regards Thomas

Regards,

Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com

...

Sent: Wednesday, June 22, 2022 at 12:33 PM From: "Jeffrey Hugo" jeffrey.l.hugo@gmail.com To: "Kevin Brace" kevinbrace@gmx.com Cc: "open list:DRM PANEL DRIVERS" dri-devel@lists.freedesktop.org Subject: Re: How do I gather up new code to be converted as patches?

Generating a patch is "git format-patch". This command operates on commits in your local tree. So you need to commit your changes to your local tree. The command for that is "git commit", and it works on staged changes. To stage changes, you need to "git add" them. "git status" can help you visualize unstaged and staged changes.

So, if I had a change in foo.txt, I would likely use "git status" to view that unstaged change. Then I can stage it using "git add foo.txt". "git status" will then show that it is staged. Finally, I will do "git commit", which will ask for a commit text, and commit the change to the tree. I can then verify that the change is committed using "git log".

Does that help you out, or did I misunderstand your situation?

-Jeff

On Wed, Jun 22, 2022 at 11:19 AM Kevin Brace kevinbrace@gmx.com wrote:

...

Hi,

I spent about 2 days trying to figure this out, but I guess not a lot of people do this, so I was not able to find a good example somewhere on the Internet. 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). If someone can tell me how to do this, I will post the work on dri-devel.

Regards,

Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com

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.

1. Driver files
2. Util files
3. Files for the memory handling
4. Files for irq handling
5. HW specific files
6. 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