public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Anand, Jerome" <jerome.anand@intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"Ughreja, Rakesh A" <rakesh.a.ughreja@intel.com>
Subject: Re: [PATCH V3 3/5] ALSA: add Intel HDMI LPE audio driver for BYT/CHT-T
Date: Thu, 19 Jan 2017 11:51:49 +0100	[thread overview]
Message-ID: <s5hh94vs4oq.wl-tiwai@suse.de> (raw)
In-Reply-To: <F6867404AABACB4D8EC371BF802A4B7C1495D64E@fmsmsx101.amr.corp.intel.com>

On Thu, 19 Jan 2017 11:39:29 +0100,
Anand, Jerome wrote:
> > > +void mid_hdmi_audio_signal_event(enum had_event_type event) {
> > > +	struct hdmi_lpe_audio_ctx *ctx;
> > > +
> > > +	dev_dbg(&hlpe_pdev->dev, "%s: Enter\n", __func__);
> > > +
> > > +	ctx = platform_get_drvdata(hlpe_pdev);
> > > +
> > > +	if (ctx->had_event_callbacks)
> > > +		(*ctx->had_event_callbacks)(event,
> > > +			ctx->had_pvt_data);
> > 
> > Isn't this racy?  This dispatcher seems called from multiple places including
> > the interrupt handler below.
> > 
> 
> No, It's taken care of in the respective callbacks based on the event

If the race protection must be handled inside the callback, please
describe it.


> > > +/**
> > > + * hdmi_audio_get_caps:
> > > + * used to return the HDMI audio capabilities.
> > > + * e.g. resolution, frame rate.
> > > + */
> > > +static int hdmi_audio_get_caps(enum had_caps_list get_element,
> > > +			void *capabilities)
> > > +{
> > > +	struct hdmi_lpe_audio_ctx *ctx;
> > > +	int ret = 0;
> > > +
> > > +	ctx = get_hdmi_context();
> > > +
> > > +	dev_dbg(&hlpe_pdev->dev, "%s: Enter\n", __func__);
> > > +
> > > +	switch (get_element) {
> > > +	case HAD_GET_ELD:
> > > +		ret = hdmi_get_eld(capabilities);
> > > +		break;
> > > +	case HAD_GET_DISPLAY_RATE:
> > > +		/* ToDo: Verify if sampling freq logic is correct */
> > > +		memcpy(capabilities, &(ctx->tmds_clock_speed),
> > > +			sizeof(uint32_t));
> > 
> > Why memcpy?  Both source and destination are 32bit int, no?
> > 
> 
> Do you think *(int *)capabilities =  ctx->tmds_clock_speed is better  than memcpy?

Why not simply substitution:
	capabilities = ctx->tmds_clock_speed;
?


> > > +/**
> > > + * hdmi_audio_get_register_base
> > > + * used to get the current hdmi base address  */ int
> > > +hdmi_audio_get_register_base(uint32_t **reg_base,
> > > +		uint32_t *config_offset)
> > > +{
> > > +	struct hdmi_lpe_audio_ctx *ctx;
> > > +
> > > +	ctx = platform_get_drvdata(hlpe_pdev);
> > > +	*reg_base = (uint32_t *)(ctx->mmio_start);
> > > +	*config_offset = ctx->had_config_offset;
> > > +	dev_dbg(&hlpe_pdev->dev, "%s: reg_base = 0x%p, cfg_off =
> > 0x%x\n", __func__,
> > > +			*reg_base, *config_offset);
> > > +	return 0;
> > 
> > Well, I see no reason why this function / callback is needed.
> > The base address is never referred in other codes, and the config_offset is
> > always passed to read/write accessors, so it can be calculated there directly.
> > 
> > Any other missing cases?
> > 
> 
> I wanted to have a cleaner separation, hence added this function in this file rather
> Than deriving it. So would prefer to keep it.

Passing the base register address and the offset is never a "clean"
separation from the abstraction POV.  It's just a passthrough of the
lowlevel interface.  If you want an abstraction layer, such a lowlevel
information should be protected inside.

IOW, why does th upper layer need to know these address and offset, if
the lowlevel read/write accessor itself already knows of them?


thanks,

Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-01-19 10:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10  5:08 [PATCH V3 0/5] Add support for Legacy HDMI audio drivers Jerome Anand
2017-01-09 18:20 ` ✓ Fi.CI.BAT: success for Add support for Legacy HDMI audio drivers (rev4) Patchwork
2017-01-10  5:08 ` [PATCH V3 1/5] drm/i915: setup bridge for HDMI LPE audio driver Jerome Anand
2017-01-10  5:08 ` [PATCH V3 2/5] drm/i915: Add support for audio driver notifications Jerome Anand
2017-01-10  1:27   ` kbuild test robot
2017-01-10  5:08 ` [PATCH V3 3/5] ALSA: add Intel HDMI LPE audio driver for BYT/CHT-T Jerome Anand
2017-01-18 11:46   ` Takashi Iwai
2017-01-19 10:39     ` Anand, Jerome
2017-01-19 10:51       ` Takashi Iwai [this message]
2017-01-20  5:46         ` [alsa-devel] " Anand, Jerome
2017-01-20  7:48           ` Takashi Iwai
2017-01-10  5:08 ` [PATCH V3 4/5] ALSA: x86: hdmi: Add audio support for BYT and CHT Jerome Anand
2017-01-18 12:03   ` Takashi Iwai
2017-01-19 10:42     ` Anand, Jerome
2017-01-10  5:08 ` [PATCH V3 5/5] ALSA: x86: hdmi: continue playback even when display resolution changes Jerome Anand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hh94vs4oq.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jerome.anand@intel.com \
    --cc=rakesh.a.ughreja@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox