From: Deepak Chitriki <deepak.chitriki@ti.com>
To: "Ramirez Luna, Omar" <omar.ramirez@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
Ameya Palande <ameya.palande@nokia.com>,
Hiroshi Doyu <Hiroshi.DOYU@nokia.com>,
Felipe Contreras <felipe.contreras@nokia.com>,
"Menon, Nishanth" <nm@ti.com>
Subject: Re: [RFC][PATCH 2/2] DSPBRIDGE: Distinguish between read or write buffers
Date: Fri, 19 Feb 2010 15:44:32 +0200 [thread overview]
Message-ID: <4B7E95C0.3060308@ti.com> (raw)
In-Reply-To: <1266532429-30927-3-git-send-email-omar.ramirez@ti.com>
Ramirez Luna, Omar wrote:
> This patch introduces the check to differentiate the buffers
> coming to the dsp through bridgedriver. So far they can be
> input (read) or output (write) or rw (which are treated the
> same way as an output buffer), this distinctions are made from
> dsp perspective.
>
> Since this needs to be checked on map function, unused
> bits (16, 15) of flags were used to check for this argument.
>
> As 128 byte alignment limitation doesn't affect input buffers
> only writable buffers are checked. Default value for read buffers
> is set to be 1, this will enforce that users of bridge will fill
> the flags with significant values otherwise (if enabled) check
> will reject buffers not aligned to 128 bytes (even if they fall in
> the input category).
>
> Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com>
> ---
> drivers/dsp/bridge/rmgr/proc.c | 16 ++++++++++++----
> 1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
> index 78a31ef..4fe20ed 100644
> --- a/drivers/dsp/bridge/rmgr/proc.c
> +++ b/drivers/dsp/bridge/rmgr/proc.c
> @@ -71,6 +71,12 @@
>
> #define DSP_CACHE_LINE 128
>
> +#define BUFMODE_MASK (3 << 14)
> +
> +/* Buffer modes from DSP perspective */
> +#define RBUF 0x1 /* Input buffer */
> +#define WBUF 0x2 /* Output Buffer */
> +
> extern char *iva_img;
>
> /* ----------------------------------- Globals */
> @@ -1297,11 +1303,13 @@ DSP_STATUS PROC_Map(DSP_HPROCESSOR hProcessor, void *pMpuAddr, u32 ulSize,
> pReqAddr, ulMapAttr, ppMapAddr);
>
> #ifdef CONFIG_BRIDGE_CACHE_LINE_CHECK
> - if (!IS_ALIGNED((u32)pMpuAddr, DSP_CACHE_LINE) ||
> - !IS_ALIGNED(size, DSP_CACHE_LINE)) {
> - pr_err("%s: not aligned: 0x%x (%d)\n", __func__,
> + if ((ulMapAttr & BUFMODE_MASK) != RBUF) {
What if the result of (ulMapAttr & BUFMODE_MASK) is invalid,still it enters the loop.Since the condition is for writable buffers only,Isn't it better to use "if ((ulMapAttr & BUFMODE_MASK) == WBUF)" condition?
> + if (!IS_ALIGNED((u32)pMpuAddr, DSP_CACHE_LINE) ||
> + !IS_ALIGNED(ulSize, DSP_CACHE_LINE)) {
> + pr_err("%s: not aligned: 0x%x (%d)\n", __func__,
> (u32)pMpuAddr, ulSize);
> - return -EFAULT;
> + return -EFAULT;
> + }
> }
> #endif
Regards,
Deepak
>
>
next prev parent reply other threads:[~2010-02-19 13:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 22:33 [RFC][PATCH 0/2] DSPBRIDGE: 128 bytes alignment check Omar Ramirez Luna
2010-02-18 22:33 ` [RFC][PATCH 1/2] DSPBRIDGE: add checking 128 byte alignment for dsp cache line size Omar Ramirez Luna
2010-02-18 22:33 ` [RFC][PATCH 2/2] DSPBRIDGE: Distinguish between read or write buffers Omar Ramirez Luna
2010-02-19 13:44 ` Deepak Chitriki [this message]
2010-02-19 17:45 ` Omar Ramirez Luna
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=4B7E95C0.3060308@ti.com \
--to=deepak.chitriki@ti.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=ameya.palande@nokia.com \
--cc=felipe.contreras@nokia.com \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=omar.ramirez@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.