From: "Terje Bergström" <tbergstrom@nvidia.com>
To: Lucas Stach <dev@lynxeye.de>
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCHv4 0/8] Support for Tegra 2D hardware
Date: Thu, 3 Jan 2013 08:14:06 +0200 [thread overview]
Message-ID: <50E521AE.2030500@nvidia.com> (raw)
In-Reply-To: <1356097818.1490.109.camel@tellur>
On 21.12.2012 15:50, Lucas Stach wrote:
> Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
>> Some of the issues left open:
>> * Register definitions still use static inline. There has been a
>> debate about code style versus ability to use compiler type
>> checking and code coverage analysis. There was no conclusion, so
>> I left it as was.
> This has to be resolved before merging. Personally I'm in favour of
> keeping reg access patterns close to what is done in other parts of the
> kernel.
How about if I define inline functions, and #defines to proxy to them?
Something like:
static inline u32 host1x_sync_cfpeek_ctrl_r(void)
{
return 0x74c;
}
#define HOST1X_SYNC_CFPEEK_CTRL \
host1x_sync_cfpeek_ctrl_r()
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_ena_f(u32 v)
{
return (v & 0x1) << 31;
}
#define HOST1X_SYNC_CFPEEK_CTRL_CFPEEK_ENA_F(v) \
host1x_sync_cfpeek_ctrl_cfpeek_ena_f(v)
I'd use the macros in .c files. That way the references will look
familiar to reader of .c files, but we can still get the benefits of
compiler processing (type checking, better error codes etc) and gcov
coverage tracking.
Terje
WARNING: multiple messages have this Message-ID (diff)
From: "Terje Bergström" <tbergstrom@nvidia.com>
To: Lucas Stach <dev@lynxeye.de>
Cc: "thierry.reding@avionic-design.de"
<thierry.reding@avionic-design.de>,
"airlied@linux.ie" <airlied@linux.ie>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv4 0/8] Support for Tegra 2D hardware
Date: Thu, 3 Jan 2013 08:14:06 +0200 [thread overview]
Message-ID: <50E521AE.2030500@nvidia.com> (raw)
In-Reply-To: <1356097818.1490.109.camel@tellur>
On 21.12.2012 15:50, Lucas Stach wrote:
> Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
>> Some of the issues left open:
>> * Register definitions still use static inline. There has been a
>> debate about code style versus ability to use compiler type
>> checking and code coverage analysis. There was no conclusion, so
>> I left it as was.
> This has to be resolved before merging. Personally I'm in favour of
> keeping reg access patterns close to what is done in other parts of the
> kernel.
How about if I define inline functions, and #defines to proxy to them?
Something like:
static inline u32 host1x_sync_cfpeek_ctrl_r(void)
{
return 0x74c;
}
#define HOST1X_SYNC_CFPEEK_CTRL \
host1x_sync_cfpeek_ctrl_r()
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_ena_f(u32 v)
{
return (v & 0x1) << 31;
}
#define HOST1X_SYNC_CFPEEK_CTRL_CFPEEK_ENA_F(v) \
host1x_sync_cfpeek_ctrl_cfpeek_ena_f(v)
I'd use the macros in .c files. That way the references will look
familiar to reader of .c files, but we can still get the benefits of
compiler processing (type checking, better error codes etc) and gcov
coverage tracking.
Terje
next prev parent reply other threads:[~2013-01-03 6:14 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 11:39 [PATCHv4 0/8] Support for Tegra 2D hardware Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 1/8] gpu: host1x: Add host1x driver Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 2/8] gpu: host1x: Add syncpoint wait and interrupts Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 3/8] gpu: host1x: Add channel support Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-4-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-22 4:17 ` Steven Rostedt
2012-12-22 4:17 ` Steven Rostedt
[not found] ` <1356149848.5896.124.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
2013-01-02 9:31 ` Terje Bergström
2013-01-02 9:31 ` Terje Bergström
2013-01-02 7:40 ` Mark Zhang
2013-01-02 7:40 ` Mark Zhang
2013-01-02 9:31 ` Terje Bergström
[not found] ` <50E3FE8C.8000309-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-02 9:31 ` Mark Zhang
2013-01-02 9:31 ` Mark Zhang
[not found] ` <50E3FE57.5070702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-02 9:43 ` Terje Bergström
2013-01-02 9:43 ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 4/8] gpu: host1x: Add debug support Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 7/8] drm: tegra: Add gr2d device Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-1-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 11:39 ` [PATCHv4 5/8] drm: tegra: Remove redundant host1x Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-6-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 14:36 ` Thierry Reding
2012-12-21 14:36 ` Thierry Reding
2012-12-22 6:50 ` Terje Bergström
[not found] ` <50D55820.7030302-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-25 5:25 ` Stephen Warren
2012-12-25 5:25 ` Stephen Warren
2012-12-28 21:21 ` Thierry Reding
2012-12-31 6:43 ` Terje Bergström
2012-12-31 6:43 ` Terje Bergström
[not found] ` <20121221143614.GA16167-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2013-01-03 17:58 ` Terje Bergström
2013-01-03 17:58 ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 6/8] ARM: tegra: Add board data and 2D clocks Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 8/8] gpu: host1x: Register DRM dummy device Terje Bergstrom
2012-12-21 11:39 ` Terje Bergstrom
[not found] ` <1356089964-5265-9-git-send-email-tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 13:53 ` Lucas Stach
2012-12-21 13:53 ` Lucas Stach
2012-12-21 14:09 ` Thierry Reding
2012-12-21 14:09 ` Thierry Reding
2012-12-21 13:50 ` [PATCHv4 0/8] Support for Tegra 2D hardware Lucas Stach
2012-12-21 13:50 ` Lucas Stach
2012-12-21 13:57 ` Terje Bergström
2012-12-21 13:57 ` Terje Bergström
[not found] ` <50D46AE4.8020308-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-21 13:59 ` Lucas Stach
2012-12-21 13:59 ` Lucas Stach
2013-01-03 6:14 ` Terje Bergström [this message]
2013-01-03 6:14 ` Terje Bergström
2012-12-26 9:42 ` Mark Zhang
2012-12-26 9:42 ` Mark Zhang
2013-01-02 9:25 ` Terje Bergström
[not found] ` <50E3FD17.80402-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03 2:36 ` Mark Zhang
2013-01-03 2:36 ` Mark Zhang
2012-12-28 9:14 ` Mark Zhang
[not found] ` <50DD6311.9000002-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-02 9:42 ` Terje Bergström
2013-01-02 9:42 ` Terje Bergström
[not found] ` <50E40106.4020406-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03 3:31 ` Mark Zhang
2013-01-03 3:31 ` Mark Zhang
[not found] ` <50E4FBAF.30700-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-03 5:50 ` Terje Bergström
2013-01-03 5:50 ` Terje Bergström
[not found] ` <50E51C08.1020603-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-01-03 5:55 ` Mark Zhang
2013-01-03 5:55 ` Mark Zhang
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=50E521AE.2030500@nvidia.com \
--to=tbergstrom@nvidia.com \
--cc=dev@lynxeye.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
/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.