Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Vladimir Zapolskiy <hidden>
Date: 2014-11-17 15:12:59
Also in:
alsa-devel, linux-omap
Hi Jyri, On 14.11.2014 17:05, Jyri Sarha wrote:
On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:quoted
Hi Jyri, On 12.11.2014 16:41, Jyri Sarha wrote:quoted
Signed-off-by: Jyri Sarha <redacted> --- 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/19Sure, I can do that. Everything should be fine in that order too.quoted
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