- Oct 31, 2012
-
-
Alessandro Rubini authored
Signed-off-by:Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This is a potentially incompatible change: if your driver fills attributes in the input block at raw_io() time, it won't work any more. You should fill chan->current_ctrl instead, which will be visible as a binary blob in sysfs soon. Moving the memcpy() to a later point doesn't change overhead. Signed-off-by:
Federico Vaga <federico.vaga@gmail.com>
-
- Oct 29, 2012
-
-
If a driver module registerscreate its own preferred trigger or buffer, we can't increment its own use count, or we won't be able to unload the module. This patch resolves the issue. Now the ZIO core doesn't increment the use counter of the trigger or buffer, if it's owned by the device. Signed-off-by:
-
Alessandro Rubini authored
By copying ti->tstamp to the control at a later time, we support devices that use an internal time stamp (e.g: white rabbit). Signed-off-by:
-
Alessandro Rubini authored
If the user changes the buffer size, this might make more space for a sleeping writer. Similarly, the buffer may be fuller than the new value after a change, so we check for ">= limit" and not "== limit". This doesn't apply to the vmalloc buffer, that currently doesn't allow a size change. Signed-off-by:
-
Alessandro Rubini authored
buffer->store_block calls trigger->push_block when it receives the first block. The trigger user fires directly , and if the device accepts the data immediately, our data_done() will retr_block from the buffer. This happens with zio-zero, cset 1, and leads to a deadlock. To allow immediate success of push_block down to device level, release the lock before calling push_block. The code here also handles pathologic situations like two processes storing at the same time. Signed-off-by:
-
- Oct 26, 2012
-
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
It is difficult to support a board which has pre-samples and post-samples registers and synchronize these value with the nsamples zio_attribute and control field. But, it is really simple for board that hasn't pre and post samples to use these two attributes because they can use only one attribute for their purpose (only pre-sample or only post-sample). Signed-off-by:
-
- Sep 04, 2012
-
-
Federico Vaga authored
Do not use device->id attribute but define our zio_device->dev_id attribute. This allow ZIO to run on kernel older than 3.2 Signed-off-by:
-
- Aug 29, 2012
-
-
Federico Vaga authored
Signed-off-by:
-
- Aug 21, 2012
-
-
Federico Vaga authored
Signed-off-by: -
Signed-off-by:
-
The core now use "hw" instead of "hwdev" as prefix for the fake zio_device, and no-prefix for the real zio_device. Signed-off-by:
-
Signed-off-by:
-
Signed-off-by:
-
Alessandro Rubini authored
Signed-off-by:
-
Alessandro Rubini authored
Signed-off-by:
-
Alessandro Rubini authored
Signed-off-by:
-
Alessandro Rubini authored
Signed-off-by:
-
Alessandro Rubini authored
The biggest change (as for number of lines) is renaming he ztt_instance structure pointers to ztt. Also, remove a trailing semicolon in a #define, fix a kfree call and remove an old comment that doesn't apply any more. Signed-off-by:
-
Alessandro Rubini authored
This adds 4 bytes to the control (there are atill 16 free) to fit a whole struct addr_zio (same as sockaddr_zio, to be defined when we merge PF_ZIO). The structure was almost ready for that, but we missed the sa_family 16-bit field. This also changes the minor number for the ZIO control structure, and all the few users of the address-related fields. Signed-off-by:
-
- Aug 10, 2012
-
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
A new zio_attribute flag is declared: ZATTR_CONTROL. If this flag is setted the zio_attribute appear in the control, otherwise the attribute is visibile in the sysfs but not in the control Signed-off-by:
-
Federico Vaga authored
The ZIO core use the dev_id parameter but this patch is compatible only with kernel 3.2 or greater. Signed-off-by:
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
Signed-off-by:
-
- May 03, 2012
-
-
Federico Vaga authored
Signed-off-by:
-
- May 02, 2012
-
-
Federico Vaga authored
Signed-off-by:
-
- Apr 17, 2012
-
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
Signed-off-by:
-
Federico Vaga authored
Signed-off-by:
-
Alessandro Rubini authored
Signed-off-by:
-
Federico Vaga authored
The helper zio_trigger_abort() is introduced; it can be used to abort a data transfer. The bit flag ZTI_COMPLETING is introduced: if high ZIO is completing the transfert operation by invokng the data_done() function; if low the transfer is running or the trigger is waiting for event. If abort() is called when this glag is high, the functions does nothing. The helper zio_trigger_data_done() is introduced; insted of call the data_done() function with cset->ti->t_op->data_done() and manually set the ZTI_COMPLETING flag, this hellper must be used. If the trigger operation data_done is not set, then use the __zio_internal_data_done Signed-off-by:
-
Federico Vaga authored
If default_(zbuf|trig) is not empty then ZIO use this as first choice for the buffer|trigger; otherwise it tries to use the preferred_(buffer|trigger) defined at zio_device and valid for any cset. The last choice is the ZIO default. Signed-off-by:
-
- Apr 16, 2012
-
-
Alessandro Rubini authored
Signed-off-by:
-
- Apr 09, 2012
-
-
Alessandro Rubini authored
Signed-off-by:
-
Alessandro Rubini authored
Signed-off-by:
-
Alessandro Rubini authored
The core should ensure its users that create calls are not reentrant. We use the locks that already exist in the buffer type and the trigger type. Then, we init both ti->lock and bi->lock, so our users can rely on them (see next patch). Related to locks: fix a comment in zio.h Signed-off-by:
-
