[PATCH] U-Boot omap3-dev-usb merge clean up, sync and mainline preparation

Steve, Atin,

I spent some time with diff tools and the various U-Boot branches (omap3-dev, omap3-dev-usb and Wolfgang's mainline). I think I found a way to clean up and sync stuff. Because of the various branches it needs some concentration to understand, but result looks fine and easy :wink: The resulting USB patch we will later send to U-Boot USB maintainer is only ~37k after this clean up and sync.

But first, let us start with omap3-dev and omap3-dev-usb. For this, in attachment there are two patches: one for omap3-dev and one for omap3-dev-usb:

1) omap3-dev: omap3_core_usb_prepartation.txt: [PATCH omap3-dev] OMAP3: Add OMAP3 core changes for MUSB

(based on b09e24eb31c9e69cea44e6290f4a566a68c92e04 "Merge branch 'master' into omap3-dev")

2) omap3-dev-usb: usb_mainline_sync.txt: [PATCH omap3-dev-usb] Update mainline changes

(based on 77d49e493ae4c9159578663571a2e84f2d3304a9 "Removed trailing whitespace.")

What to do with these now in what order?

* Steve: If you have some minutes, I'd would like you to:

a) Apply patch (1) above from attachment against omap3-dev

This patch moves the OMAP3 core changes from omap3-dev-usb into omap3-dev (clock changes, I2C defines etc.)

b) Apply patch (2) above from attachment against omap3-dev-usb

This patch syncs the USB changes already in Wolfgang's mainline into omap3-dev-usb. Additionally, it syncs the OMAP3 core changes from patch (1) into omap3-dev-usb, too.

For next step it helps to know that omap3-dev already contains Wolfgang's mainline (USB) changes, but omap3-dev-usb does not yet.

c) When patch (1) is at omap3-dev (step (a) done) and patch (2) is at omap3-dev-usb (step (b) done), then merge omap3-dev into omap3-dev-usb. I.e. move the contents from omap3-dev to omap3-dev-usb. omap3-dev should stay untouched, except patch (1) from step (a). I tested this with git pull.

Result should be two trivial merge conflicts in

drivers/usb/Makefile
include/usb.h

Please fix them manually: Take the versions which add OMAP3 file/macro.

Result:

After this is done, both branches should be in sync, should be based on the same version from Wolfgang's mainline and USB should be in sync to mainline, too.

* Atin: After this please test omap3-dev-usb! :wink:

Note that I made two changes (see omap3-dev patch):

- In omap3-dev-usb branch, in file cpu/arm_cortexa8/omap3/clock.c

sr32(&prcm_base->iclken1_core, 4, 1, 0x1);

is done twice. One with #ifdef CONFIG_MUSB and one with #ifdef CONFIG_USB_OMAP3530. I think this only necessary one time? Please check!

- #define UDC_MAX_FIFO_SIZE 16384 is moved from omap3.h to include/usbdcore_musb.h

* Result: If all above is done, as mentioned above, the diff between omap3-dev and omap3-dev-usb is only ~37k patch.

* How to go on:

As soon as OMAP3 hits Wolfgang's mainline, I will send an OMAP3 update patch series to bring Wolfgang's mainline in sync with our omap3-dev branch. This is has already ~6 patches (overo pin mux, OMAP3 detection, beagle detection, pandora pin mux etc.). I will add patch (1) from above (OMAP3 core changes for MUSB) to this series, too.

Then we have to wait until this clean up series hits mainline, too. If this is done, we can send the ~37k patch to U-Boot USB maintainer.

To summarize the steps:

1) Wait and hope for OMAP3 to hit mainline.

2) When (1) done, then send OMAP3 core update patches to U-Boot list. This brings mainline OMAP3 in sync with omap3-dev

3a) Wait and hope to hit (2) mainline

3b) Clean up USB patch in omap3-dev-usb

4) When (3a) done, send cleaned up OMAP3 USB patch to U-Boot USB maintainer.

5) Wait and hope ...

Best regards

Dirk

1_omap3_core_usb_prepartation.txt (2.85 KB)

2_usb_mainline_sync.txt (10.3 KB)

I think the usbtty.c changes when putting mainline into usb (patch 2), is bad. I think the if (!usb_configured()) test needs to be in there but patch 2 is taking them out. Similarly, I took out the redundant __attribute__((packed)) and I think patch 2 is putting them back. The rest looks ok.

-Atin

I also didn't see twl4030-usb.c mentioned anywhere - it should be one of the files getting added to omap3-dev in patch 1.

Atin Malaviya wrote:

I think the usbtty.c changes when putting mainline into usb (patch 2), is bad. I think the if (!usb_configured()) test needs to be in there but patch 2 is taking them out. Similarly, I took out the redundant __attribute__((packed)) and I think patch 2 is putting them back. The rest looks ok.

Two proposals:

* I'd like Steve to apply these patches as they are to have everything in sync. Do you mind to re-send your changes again afterwards?

* Are the

(!usb_configured())

and

__attribute__((packed))

OMAP3 specific or general changes?

If they are not OMAP3 specific but generic, please send them as separate patch to U-Boot list and USB maintainer *now*. Then we will get these changes via mainline. We should avoid to mix general changes and OMAP3 specific changes in one patch.

Thanks

Dirk

Both the usb_configured() and __attribute__((packed)) changes are generic. We do need the usb_configured() check in for us to work though - since otherwise we hang. The __attribute__((packed)) is only to get rid of a warning about it being redundant and ignored.

-Atin

Atin Malaviya wrote:

Both the usb_configured() and __attribute__((packed)) changes are generic. We do need the usb_configured() check in for us to work though - since otherwise we hang. The __attribute__((packed)) is only to get rid of a warning about it being redundant and ignored.

Please send a patch to USB maintainer and discuss with him then.

We will get this then via mainline.

Thanks

Dirk

Atin Malaviya wrote:

I also didn't see twl4030-usb.c mentioned anywhere - it should be one of the files getting added to omap3-dev in patch 1.

No. As it is called *_usb.c and located in ./drivers/usb/ it's a file to have in the USB patch to be sent to the USB maintainer later. I don't like to have any (new) USB files in omap3-dev (OMAP3 core) branch.

Best regards

Dirk

I see - I misunderstood, I thought we were also trying to get a working usb gadget mode into omap3-dev now. I guess we want to get omap3-dev-usb close to upstream so we can send a clean set of patches for usb to the usb maintainer, then omap3-dev will automatically get them.

-Atin

Atin Malaviya wrote:

I see - I misunderstood, I thought we were also trying to get a working usb gadget mode into omap3-dev now. I guess we want to get omap3-dev-usb
close to upstream so we can send a clean set of patches for usb to the usb maintainer,

Yes. At the moment my goal is to merge omap3-dev (and with this Wolfgang's mainline) into omap3-dev-usb. Then we will have everything from omap3-dev and mainline in omap3-dev-usb. This will result in *only* OMAP3 USB changes in omap3-dev-usb. I.e. when you then diff omap3-dev and omap3-dev-usb (as I did) you will get a clean OMAP3 USB patch we can send (later) to USB maintainer. This is the ~37k sized patch I talked about.

then omap3-dev will automatically get them.

Well, looking at the time frame we most probably talk about, I'm not sure if we will have a omap3-dev branch still then. But that's an other topic :wink: