Re: [PATCH 3/3] ASoC: OMAP: HDMI: Obtain DMA port from resources

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]