[alsa-devel] [PATCH 3/3] ASoC: OMAP: HDMI: Obtain DMA port from resources

[Ricardo Neri]

Hi Tomi,

On 11/15/2012 06:36 AM, Tomi Valkeinen wrote:
> 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.

Thanks! I just resubmitted a new series to complement the creation of 
the audio device for HDMI with code to remove it from 
arch/arm/mach-omap2/devices.c. HDMI audio works correctly in every patch 
of that series.

Thanks Mark and Tomi for pointing out these issues and I apologize for 
the inconvenience.

BR,

Ricardo
>
>   Tomi
>
>