Uri Shkolnik wrote:
--- On Fri, 3/6/09, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote:
From: Michael Krufky <mkrufky@xxxxxxxxxxx>
Subject: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio
To: "Mauro Carvalho Chehab" <mchehab@xxxxxxxxxxxxx>
Cc: linux-media@xxxxxxxxxxxxxxx
Date: Friday, March 6, 2009, 3:15 PM
Mauro,
Please pull from:
http://linuxtv.org/hg/~mkrufky/sms1xxx-gpio
for the following:
- smsusb: whitespace cleanups
- smscore: whitespace cleanups
- smsusb: add autodetection for "nice" and "venice" boards
- smsdvb: whitespace cleanups
- sms-cards: add some more debug
- sms1xxx: update GPIO functionality to support all
devices
sms-cards.c | 26 ++
sms-cards.h | 2
smscoreapi.c | 391
++++++++++++++++++++++++++-------------
smscoreapi.h | 350
++++++++++++++++++----------------
smsdvb.c | 27 +-
smsusb.c | 49
++--
6 files changed, 507 insertions(+), 338 deletions(-)
Cheers,
Mike
--
To unsubscribe from this list: send the line "unsubscribe
linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mike,
I reviewed your tree , which is indicated by the email above, and compared it to a tree I built from the v4l 'trunk' repository + Siano's patches.
I found out two things -
1) The trees are still *very* differ from each other
2) You applied *new* things that are _not_ included in the "old" Siano's patches (and some of them even break it).
I'm wondering what is the status of the Siano's patches merge to the main tree, and I would like to ask what is the target date for final merge. This is critical for us since till now, we told people to download the v4l 'trunk' and apply the various patches (which are available to to all on the vger server) on it. The current state voids that option, and the result is invalid drivers (I tested the your tree, and it fails the very first Siano's QA sanity test).
I would like to ask you to stick with Siano's patches, which are solid, tested thoroughly, and work on multiple devices (including mass production).
We talked about altering some minor stuff (like the EXPORT_SYMBOL_GPL, external functions calls and indentation) this does not mean that we want to create new set of drivers or alter the drivers architecture.
If there are substantial changes you think should be applied, first merge all previously committed patches, and than submit new patches for review.
Please note that are multiple patches awaiting to be submitted from Siano (and some other parties via Siano), that I'm holding till the merge will end. So lets keep the order [1] merge old Siano's patches [2] submit review and merge pending Siano's (exist) patches [3] Submit new patches for review.
Uri,
Plain and simple:
#1 The patches that you submitted break the currently supported devices
#2 The patches that you submitted are not atomic
#3 The patches that you submitted introduce regressions
#4 The patches that you submitted have multiple changes in single patches.
#5 The patches that you submitted are not safe for a git-bisection nor
hg-bisection
#6 The "codingstyle cleanups" that are intertwined in your patches are
actually codingstyle regressions rather than cleanups.
When I complained about these problems, you were not willing to
regenerate your patches. In the interest of moving forward, I had
volunteered to clean the changes and separate them into atomic patches
such that we could avoid any problems caused by the above.
In the last email that you wrote, asking about merge, I explained the
above to you, and I offered as a compromise for this time, that I would
separate your patches and merge them one by one and ensure that the
currently supported Hauppauge devices do not become broken as a result
of this.
This round of merges contains some of your changes. I am still working
on the other parts.
I am in the process of separating your huge patches into smaller
patches, and I am merging slowly into the master branch little by
little. I am IN THE MIDDLE OF THIS PROCESS, but I am merging things
when I can, so that there are less changes to be reviewed and merged all
at once, when the entire merge is finally complete.
AS WE AGREED, I am working through your patchset to get everything
merged. Again, AS WE AGREED, once everything is merged, that's when you
and I will sync up and handle the remaining differences.
...
These patches pending in my repository for merge are a SUBSET of the
patches that you sent to me. What you sent cannot be applied as-is.
After merging your GPIO changesets, it broke the Hauppauge devices,
entirely.
I added some debug to sms-cards.c, and I had to add the "wait" option to
your gpio functions -- without this "wait" option, the Hauppauge gpio
functionality is thoroughly broken.
This "wait" option to the gpio functions was the only way to merge your
new code without breaking the hauppauge devices. The solution is simple
-- when YOU call those functions, set "wait" to true -- that will be the
exact behavior as you expect. Hauppauge needs wait set to 0, otherwise
the desired functionality cannot be achieved.
Uri, as we agreed when we spoke in person, I am working to merge ALL of
your pending changesets. I am working through them one at a time, and I
am breaking them down into smaller changesets.
Please do not feel any need to regenerate the remaining changesets -- I
have them all here refactored into smaller patches and I will be pushing
them up as they are ready for merge.
When you complain like this, it only slows down the process.
We can speed this up in the future if you take better care with your
future changesets:
You must *never* generate patches against the mercurial tree by means of
diffing one file from your repository against a file in the mercurial
repository. This creates regressions (whether function or codingstyle
related). You should send single atomic changesets, each making one
change at a time. Whitespace / codingstyle changes should *never* be
mixed with a functional patch.
Please respond, indicating that you now understand that when all is said
and done, all of your patches will be merged.
This is a slow process, Uri -- Please bear with us.
Regards,
Michael Krufky
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
