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?
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
