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

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Ricardo Neri <ricardo.neri@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	lrg@ti.com, s-guiriec@ti.com, linux-omap@vger.kernel.org,
	alsa-devel@alsa-project.org
Subject: Re: [PATCH 3/3] ASoC: OMAP: HDMI: Obtain DMA port from resources
Date: Thu, 15 Nov 2012 11:45:10 +0200	[thread overview]
Message-ID: <50A4B9A6.5070806@ti.com> (raw)
In-Reply-To: <50A45467.6070404@ti.com>

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

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?

 Tomi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]