On 2012-11-15 11:45, Tomi Valkeinen wrote:
On 2012-11-15 04:33, Ricardo Neri wrote:
Hi Mark,
On 11/14/2012 05:08 PM, Mark Brown wrote:
On Wed, Nov 14, 2012 at 11:07:09AM -0600, Ricardo Neri wrote:
On 11/13/2012 09:27 PM, Mark Brown wrote:
Presumably this needs some other corresponding change in the resource setup to go in simultaneously...
Yes, the change in the resources setup has been submitted to the OMAPDSS HDMI driver and accepted by Tomi [1].
Don't do this. With a change like this which must be made at the same time over multiple subsystems it is very important that you send all the parts of the changes together. Otherwise there's a risk that one of them won't get merged and even if they do both get merged you'll break bisection - it's clear that nobody can be testing this on Tomi's branch.
but the changes will hit linux-next at some point and they could be tested there, right?
Sorry, as changes for the HDMI drivers go to several maintainers, I was trying to send the relevant patches to the respective maintainers and avoid potential merge/rebase issues.
Tomi has already taken the DSS changes. Perhaps, if you and Tomi agree, Tomi could also take the ASoC and the arch/arm/mach-omap2 changes. This way all changes come from the same tree.
Hmm, ok, I'm a bit confused here.
I though the omap_hdmi_audio device was a new thing, and thus it was ok to add to omapdss. But now I see omap_hdmi_audio is already registered in arch/arm/mach-omap2/devices.c, meaning the same platform device is registered twice now. Well, with the exception of the device id, which is -1 for the one from devices.c, and 0 for the one in omapdss.
Mark is right, this is not right. The kernel should work fine after each patch, which means that sometimes a patch will touch multiple different areas of kernel.
omapdss master branch is a stable branch, so I don't want to rebase it. But I guess I can "reset" it by merging a mainline using some merge strategy. I haven't done that before, but I guess it'll work.
Can you look at all the HDMI patches related to this hdmi-device change, and rewrite them so that they'll keep the kernel working after each patch?
After some testing I think resetting my master branch with merge is not a very good option.
However, the HDMI audio platform device patch is almost on top of the branch, so reverting it would only create a few steps where the HDMI audio may be broken.
So I can revert the patch and apply a new series with the patches organized so that things will work.
Tomi