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
next prev parent 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