[alsa-devel] [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly

[Vladimir Zapolskiy]

Hi Jyri,

On 14.11.2014 17:05, Jyri Sarha wrote:
> On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:
>> Hi Jyri,
>>
>> On 12.11.2014 16:41, Jyri Sarha wrote:
>>> Signed-off-by: Jyri Sarha <jsarha at ti.com>
>>> ---
>>>   drivers/video/fbdev/omap2/dss/hdmi.h |    4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
>>> index a6e08ff..6d129f2 100644
>>> --- a/drivers/video/fbdev/omap2/dss/hdmi.h
>>> +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
>>> @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
>>>   		struct hdmi_audio_format *aud_fmt);
>>>   void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
>>>   		struct hdmi_audio_dma *aud_dma);
>>> -static inline bool hdmi_mode_has_audio(int mode)
>>> +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
>>>   {
>>> -	return mode == HDMI_HDMI ? true : false;
>>> +	return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false;
>>>   }
>>>
>>>   /* HDMI DRV data */
>>>
>>
>> would it be possible for you to rearrange the changes preserving the
>> following sequence?
>>
>> 1) 13/19
>> 2) 15/19
>> 3) 11/19
>> 4) 14/19
>> 5) 16/19
>>
> 
> Sure, I can do that. Everything should be fine in that order too.
> 
>> Otherwise I'm worried that someone's git rebase may fail.
>>

sorry again, I meant git-bisect, git rebase is fine.

> But do not follow why. Did you notice that 10/19 removes the config 
> options that enable the pieces of code that are deleted in 13/19 and 
> 15/19. IOW, the code that uses hdmi_mode_has_audio() (and would become 
> broken by 11/19) is already disabled by 10/19. Git-wise I see no problem 
> either.

Right, I was worried by changed hdmi_mode_has_audio() API and still
present source code, which uses the old API (it is fixed in the
following patches). If the code that uses hdmi_mode_has_audio() is
disabled by 10/19 and the kernel can be successfully compiled and
working on partial application of the changeset, then there should be no
problem with git-bisect, and probably no need to rearrange the commits.

> I'll rearrange the patches if you still insist there is a problem with 
> current order, but I would like to understand why.

--
With best wishes,
Vladimir