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
Attachment:
signature.asc
Description: OpenPGP digital signature
