On Saturday 27 October 2012 09:29 PM, Paul Walmsley wrote:
On Sat, 27 Oct 2012, Santosh Shilimkar wrote:
Another alternative, which I will recommend to just make use of the
read*/wrire* instead __raw versions. The barriers are taken care
already and driver point of view, it is transparent.
Th
Hi Al,
On Sat, 27 Oct 2012 18:10:36 +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> > On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> >
> > > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > > is simply not true. In particula
Hi
On Thu, 25 Oct 2012, Felipe Balbi wrote:
> this is important in cases where client driver
> wants to know how many bytes were actually
> transferred.
>
> There is one trick here: if transfer is completed,
> meaning I2C_CNT reaches zero, then ARDY will be
> asserted to let SW know that it can
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who
On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
>
> > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> > struct foo {
> > ch
On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> You are wrong. Assumption that pointers are aligned to 32bit boundary
> is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> struct foo {
> char x;
> void *p;
> }; will have 1 byte occupied by x, follow
Hi,
Am 27.10.2012 18:50, schrieb Jean Delvare:
> Hi Frank,
>
> On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
>> the i2c interface of my device is capable of writing 2 bytes (reg +
>> data) and reading a single data byte only.
> Are you talking about an I2C master (controller) here, or a
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who
On Sat, 27 Oct 2012, Santosh Shilimkar wrote:
> Another alternative, which I will recommend to just make use of the
> read*/wrire* instead __raw versions. The barriers are taken care
> already and driver point of view, it is transparent.
Those barriers will disappear if CONFIG_ARM_DMA_MEM_BUFFERA
Hi Frank,
On Sat, 27 Oct 2012 17:17:34 +0300, Frank Schäfer wrote:
> the i2c interface of my device is capable of writing 2 bytes (reg +
> data) and reading a single data byte only.
Are you talking about an I2C master (controller) here, or a slave
device?
> A block read/write emulation function
Hi,
the i2c interface of my device is capable of writing 2 bytes (reg +
data) and reading a single data byte only.
A block read/write emulation function would have to do an i2c write (to
increase the register) followed by either an i2c read or write for each
data byte.
The question is now: does it
On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > The original idea of using the hole in the i2c_msg structure is from
> > David Brownell, who was apparently familiar with such practice, so I
> > assumed it was OK
On Saturday 27 October 2012 04:31 AM, Paul Walmsley wrote:
Hi Felipe
just two quick comments
On Thu, 25 Oct 2012, Felipe Balbi wrote:
if we allow compiler reorder our writes, we could
fall into a situation where dev->buf_len is reset
for no apparent reason.
This bug was found with a simple s
13 matches
Mail list logo
