| Message ID | 1483458772-13658-2-git-send-email-arnaud.pouliquen@st.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jan 03, 2017 at 04:52:50PM +0100, Arnaud Pouliquen wrote: > Add helper to allow users to retrieve the speaker allocations without > knowledge of the ELD structure. You don't appear to have sent this to any of the DRM maintainers - it does need review from them.
Mark Brown <broonie@kernel.org> writes: > [ Unknown signature status ] > On Tue, Jan 03, 2017 at 04:52:50PM +0100, Arnaud Pouliquen wrote: >> Add helper to allow users to retrieve the speaker allocations without >> knowledge of the ELD structure. > > You don't appear to have sent this to any of the DRM maintainers - it > does need review from them. It was sent to dri-devel. That's us. And the patch already has a r-b From DRM on it.
On Wed, Jan 18, 2017 at 07:38:53AM +1100, Eric Anholt wrote: > Mark Brown <broonie@kernel.org> writes: > > You don't appear to have sent this to any of the DRM maintainers - it > > does need review from them. > It was sent to dri-devel. That's us. And the patch already has a r-b > From DRM on it. I see. For most subsystems you need to actually copy a human to make sure that things are seen - just the list isn't enough. In terms of it being reviewed one of the problems with DRM not listing the reviwers in the MAINTAINERS file or anything is that it's very hard for anyone to tell if something is considered a good enough review or if it's just a review from someone who happens to contribute to DRM sometimes.
On 01/19/2017 11:29 AM, Mark Brown wrote: > On Wed, Jan 18, 2017 at 07:38:53AM +1100, Eric Anholt wrote: >> Mark Brown <broonie@kernel.org> writes: > >>> You don't appear to have sent this to any of the DRM >>> maintainers - it does need review from them. > >> It was sent to dri-devel. That's us. And the patch already has >> a r-b From DRM on it. > > I see. For most subsystems you need to actually copy a human to > make sure that things are seen - just the list isn't enough. In > terms of it being reviewed one of the problems with DRM not listing > the reviwers in the MAINTAINERS file or anything is that it's very > hard for anyone to tell if something is considered a good enough > review or if it's just a review from someone who happens to > contribute to DRM sometimes. > I limited diffusion to ASoC, as Daniel Vetter and Takashi Iwai discussed the topic here: http://www.spinics.net/lists/alsa-devel/msg58114.html Seems that is was not a good strategy as it leads to discussions.. Sorry for this. Regards Arnaud
On Thu, Jan 19, 2017 at 11:49:56AM +0100, Arnaud Pouliquen wrote: > I limited diffusion to ASoC, as Daniel Vetter and Takashi Iwai > discussed the topic here: > http://www.spinics.net/lists/alsa-devel/msg58114.html > Seems that is was not a good strategy as it leads to discussions.. > Sorry for this. If you're doing something like that and there's not been acks or other tags then you really should put some text after the --- or perhaps in the cover letter for the series explaining what's going on - people won't reliably remember old discussions without prompting.
On Thu, Jan 19, 2017 at 10:29:01AM +0000, Mark Brown wrote: > On Wed, Jan 18, 2017 at 07:38:53AM +1100, Eric Anholt wrote: > > Mark Brown <broonie@kernel.org> writes: > > > > You don't appear to have sent this to any of the DRM maintainers - it > > > does need review from them. > > > It was sent to dri-devel. That's us. And the patch already has a r-b > > From DRM on it. > > I see. For most subsystems you need to actually copy a human to make > sure that things are seen - just the list isn't enough. In terms of it > being reviewed one of the problems with DRM not listing the reviwers in > the MAINTAINERS file or anything is that it's very hard for anyone to > tell if something is considered a good enough review or if it's just a > review from someone who happens to contribute to DRM sometimes. Jani is now officially listed as drm-misc maintainer in MAINTAINERS. We also have official entries for other major areas (like bridge drivers or similar). Where do you see a gap? Note that before KS this was indeed not there, because of the committer model hanging in the air a bit ... -Daniel
On Mon, Jan 23, 2017 at 08:49:11AM +0100, Daniel Vetter wrote: > On Thu, Jan 19, 2017 at 10:29:01AM +0000, Mark Brown wrote: > > I see. For most subsystems you need to actually copy a human to make > > sure that things are seen - just the list isn't enough. In terms of it > > being reviewed one of the problems with DRM not listing the reviwers in > > the MAINTAINERS file or anything is that it's very hard for anyone to > > tell if something is considered a good enough review or if it's just a > > review from someone who happens to contribute to DRM sometimes. > Jani is now officially listed as drm-misc maintainer in MAINTAINERS. We > also have official entries for other major areas (like bridge drivers or > similar). Where do you see a gap? > Note that before KS this was indeed not there, because of the committer > model hanging in the air a bit ... This bit also wasn't there when the series started grinding on IIRC. It does look clear enough now though, thanks.
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index c3a7d44..de93543 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -248,6 +248,7 @@ struct detailed_timing { # define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa /* 500 ms */ #define DRM_ELD_SPEAKER 7 +# define DRM_ELD_SPEAKER_MASK 0x7f # define DRM_ELD_SPEAKER_RLRC (1 << 6) # define DRM_ELD_SPEAKER_FLRC (1 << 5) # define DRM_ELD_SPEAKER_RC (1 << 4) @@ -415,6 +416,18 @@ static inline int drm_eld_size(const uint8_t *eld) } /** + * drm_eld_get_spk_alloc - Get speaker allocation + * @eld: pointer to an ELD memory structure + * + * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER + * field definitions to identify speakers. + */ +static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld) +{ + return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK; +} + +/** * drm_eld_get_conn_type - Get device type hdmi/dp connected * @eld: pointer to an ELD memory structure *