From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyril Chemparathy Subject: Re: [PATCH v5 01/12] misc: add driver for sequencer serial port Date: Tue, 16 Nov 2010 11:15:56 -0500 Message-ID: <4CE2AE3C.4040805@ti.com> References: <1289848334-8695-1-git-send-email-cyril@ti.com> <1289848334-8695-2-git-send-email-cyril@ti.com> <20101116071047.GE4074@angua.secretlab.ca> Reply-To: cyril-l0cyMroinI0@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org" , "dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , "sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org" , "khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org" , "broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org" , "rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org" , "alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org" , "spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , "akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "lrg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org" To: Grant Likely Return-path: In-Reply-To: <20101116071047.GE4074-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org On 11/16/2010 02:10 AM, Grant Likely wrote: > On Mon, Nov 15, 2010 at 02:12:03PM -0500, Cyril Chemparathy wrote: >> TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port >> device. It has a built-in programmable execution engine that can be programmed >> to operate as almost any serial bus (I2C, SPI, EasyScale, and others). >> >> This patch adds a driver for this controller device. The driver does not >> expose a user-land interface. Protocol drivers built on top of this layer are >> expected to remain in-kernel. >> [...] >> +static inline void ssp_write(struct ti_ssp *ssp, int reg, u32 val) >> +{ >> + __raw_writel(val, ssp->regs + reg); >> +} > > I'm pretty sure it was resolved that __raw_ versions should not be > used here. The endian-swap done by writel/readl are incorrect since these devices are meant to be accessed native-endian at all times. See [1] below for Russell King's earlier response on this. In this case, I don't think memory-device ordering matters, and therefore the __raw_ variants should be ok. Should I just insert barriers into the read/write wrappers here? [...] Regards Cyril. [1] http://kerneltrap.org/mailarchive/linux-kernel/2010/10/22/4636289 ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev From mboxrd@z Thu Jan 1 00:00:00 1970 From: cyril@ti.com (Cyril Chemparathy) Date: Tue, 16 Nov 2010 11:15:56 -0500 Subject: [PATCH v5 01/12] misc: add driver for sequencer serial port In-Reply-To: <20101116071047.GE4074@angua.secretlab.ca> References: <1289848334-8695-1-git-send-email-cyril@ti.com> <1289848334-8695-2-git-send-email-cyril@ti.com> <20101116071047.GE4074@angua.secretlab.ca> Message-ID: <4CE2AE3C.4040805@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 11/16/2010 02:10 AM, Grant Likely wrote: > On Mon, Nov 15, 2010 at 02:12:03PM -0500, Cyril Chemparathy wrote: >> TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port >> device. It has a built-in programmable execution engine that can be programmed >> to operate as almost any serial bus (I2C, SPI, EasyScale, and others). >> >> This patch adds a driver for this controller device. The driver does not >> expose a user-land interface. Protocol drivers built on top of this layer are >> expected to remain in-kernel. >> [...] >> +static inline void ssp_write(struct ti_ssp *ssp, int reg, u32 val) >> +{ >> + __raw_writel(val, ssp->regs + reg); >> +} > > I'm pretty sure it was resolved that __raw_ versions should not be > used here. The endian-swap done by writel/readl are incorrect since these devices are meant to be accessed native-endian at all times. See [1] below for Russell King's earlier response on this. In this case, I don't think memory-device ordering matters, and therefore the __raw_ variants should be ok. Should I just insert barriers into the read/write wrappers here? [...] Regards Cyril. [1] http://kerneltrap.org/mailarchive/linux-kernel/2010/10/22/4636289