Thread (52 messages) 52 messages, 5 authors, 2014-12-02

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/19
Sure, 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help