On Wed, 11 Mar 2009 20:34:09 -0400 Michael Krufky <[email protected]> wrote:
> Mauro Carvalho Chehab wrote: > > Uri and Michael, > > > > I'm seeing this issue from outside, since I never entered into details of > > Siano > > hardware, nor I have any hardware or docs to understand the implementation > > details. However, it seems that the issue is not just technical. > > > > > >> 1) Regarding GPIO - True you took Siano's code, but you modified it, and > >> broke it. Some examples - since various devices use different DMA > >> mechanisms, which require specific, aligned allocation of DMA buffers, we > >> use such dynamic allocations, which you converted to stack variables, and > >> that fails many non-USB devices. > >> You also implement send-and-forget option (with if/"wait") which is > >> illegal by Siano host-device protocol. It will probably work well with > >> sporadic GPIO operations (such as done with LEDs indications in HPG case), > >> but it will fail with more frequent usage. You can said that this is "HPG" > >> only code, but there is no such thing in reality, many of our clients take > >> this code and patch it to match their target hardware, and the favorite > >> method of copy-and-paste always prevails, and soon our FAE will start to > >> get support request on that issue. > >> (!) Note the HPG devices work with the generic set-and-wait-for-reply, as > >> coded in the original patch, without any problem. > >> > > > > > >> 2) Regarding breaking the tree - the patches has been tested one by one. > >> Which patch break the build? I'll fix it ASAP. > >> > > > > > >> 3) Regarding diff'ing against Siano's repository, I have never asked for > >> it, on the contrary, I wrote in a previous posts chain, that after we'll > >> finish to merge everything and we'll have a full updated hg tree, I'll > >> back-merge the results to Siano's repository (by this I gave the hg > >> repository priority over Siano's, which I doubt has ever been given by > >> many other commercial companies). > >> > >> As I wrote before, since your patches break non-HPG SMS-based devices > >> support, I can not approve them. > >> > >> > > > > If I understood well, we have a big trouble here: from one hand, the current > > supported devices are from HPG, and one of the HPG members at the community > > states that it breaks the currently supported devices by the driver. From > > the > > other side, the chipset vendor is stating that HPG current approach is > > broken, > > and that HPG devices were tested with the generic way and that it works. > > > > If the Siano's original GPIO patch really breaks for the current supported > > devices, then this is a very good reason for not merging the patch. > > > > Are the documentation of the Siano host-device protocol open? If so, then > > somebody else could help understanding and checking both alternatives, with > > some > > samples of the involved devices. Otherwise, you both should work together on > > your labs to test both approaches and come together with a definitive answer > > about what changes are breaking the supported the hardware. > > > > Cheers, > > Mauro > > > > > Mauro, > > As far as I am concerned, you can merge Uri's patches. Just so long as > the Hauppauge devices have the option to NOT wait for the firmware's > response to the GPIO command. > > In linux, we allow for all sorts of possibilities within the code. This > means flexibility. > > Siano can have their functions however they like. For the Hauppauge > devices, we need a way to set gpio without waiting for the firmware > response. > > That's it. We're not going to break the devices that are currently > supported in the kernel, nor do we need to create a problem for other > Siano products. We can simply have a function with an option to wait or > not. > > I don't understand why Uri is having such a hard time with this, but I > feel that way too much time has been spent on this silliness. > > Mauro, if you decide to pick up Uri's patches, would you please give me > an opportunity to test and fix any problems that affect the Hauppauge > devices as a result, *before* any regressions are merged into the master > branch? Sure. > > Thank you for your support. > > Regards, > > Mike > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
