ting
these modes and instead register master windows as supporting these modes.
Signed-off-by: Martyn Welch
---
drivers/vme/bridges/vme_tsi148.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
ind
The logic in the init routine for the TSI148 is inverted. It isn't switching
on the CR/CSR space when it should be and is reporting it's on when its not.
Correct the logic to do the right thing.
Reported-by: De Roo, Steven
Signed-off-by: Martyn Welch
---
drivers/vme/bridges/vm
e writes are
always posted on the tsi148 (a change from the ca91cx42) the only reason to
turn it on would be if you are going to be doing writes that you want to be
flushed and a check done for errors before the command returns.
Martyn
> Kind regards,
> Steven De Roo
>
>
> -----Oor
errors in a link list if error detection is switched on.
Reported-by: De Roo, Steven
Signed-off-by: Martyn Welch
---
drivers/vme/bridges/vme_tsi148.c | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme
generating the same interrupt as the TSI148.
> Also, I can't find any good documentation on the difference between the
> 'interrupt enable out' and 'interrupt enable' registers. Do you have a clue ?
>
I think this is covered in the TSI-148 manual. From memory,
There is a memory leak in the function vme_dma_free(). The resource
structure allocated in vme_dma_request() needs to be free'd in
vme_dma_free().
Reported-by: De Roo, Steven
Signed-off-by: Martyn Welch
---
drivers/vme/vme.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Sorry, took me a while to get the bits together to test this, some of my kit
had gone walkies...
Martyn
On 06/06/13 12:29, Martyn Welch wrote:
> There is a memory leak in the function vme_dma_free(). The resource
> structure allocated in vme_dma_request() needs to be free'd in
>
On 14/05/13 15:19, Dan Carpenter wrote:
> On Tue, May 14, 2013 at 02:56:17PM +0100, Martyn Welch wrote:
>> On 13/05/13 09:51, Dan Carpenter wrote:
>>> On Mon, May 13, 2013 at 09:16:00AM +0100, Martyn Welch wrote:
>>>> On 13/05/13 07:05, Wei Yongjun wrote:
>>&g
On 13/05/13 09:51, Dan Carpenter wrote:
> On Mon, May 13, 2013 at 09:16:00AM +0100, Martyn Welch wrote:
>> On 13/05/13 07:05, Wei Yongjun wrote:
>>> From: Wei Yongjun
>>>
>>> Fix to return -ENOMEM in the resource alloc error handling
>>> case ins
ic int vme_user_probe(struct vme_dev *vdev)
> if (image[i].resource == NULL) {
> dev_warn(&vdev->dev,
>"Unable to allocate master resource\n");
> + err = -ENOMEM;
>
On 07/05/13 10:54, Martyn Welch wrote:
> On 06/05/13 09:45, De Roo, Steven wrote:
>> Hi all,
>>
>> I'm running OpenSuSE 12.3, kernel 3.7.
>>
>
> I'm not aware of any changes between 3.7 and 3.9 that would affect the
> behaviour of the driver (mainly
>> if (retval != 0) {
>> printf("retval=%d\n", retval);
>> perror("ERROR: Failed to configure window");
>> return 1;
>> }
>> for (i=0; i> data[i] = 0;
>>
onfigure ROR (Release On Request) or RWD
>> (Release When Done) using the 'vme_user' module on a XVME-6300 SBC with
>> TSI148 chipset ?
>>
>> kind regards,
>> Steven De Roo
>>
>
> The tsi148 driver doesn't currently support chan
The tsi148 driver doesn't currently support changing the mode of the requester.
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748
read %d bytes", retval);
> }
>
> // Print first 64 bytes
> for(i=0; i<8*8; i++) {
> if (i % 8 == 0) {
> printf("\n""%4.4x: ", i);
&g
On 12/04/13 08:48, De Roo, Steven wrote:
> Dear Martyn and Manohar,
Hi Steven,
> Can somebody give me a small example on how to use the "vme_user" module ?
> I have some legacy code running on an old machine that reads/writes
> some data on the VME-bus using lseek/read/write,
> using an undocume
On 25/03/13 05:37, Kumar Amit Mehta wrote:
> Audit the return value of cdev_alloc and hence fixes a potential NULL pointer
> dereferencing.
>
> Signed-off-by: Kumar Amit Mehta
Looks good to me, thanks.
Signed-off-by: Martyn Welch
> ---
> drivers/staging/vme/devices
On 25/02/13 18:09, ternaryd wrote:
> On Mon, 25 Feb 2013 15:01:40 +
> Martyn Welch wrote:
>
> Once again, you are right on all accounts. There was a dip switch which
> wasn't moved properly all the way, causing this bad misbehavior. Now,
>
> vme_tsi148 0001:08:0e.
On 25/02/13 17:00, ternaryd wrote:
> On Mon, 25 Feb 2013 14:18:21 +
> Martyn Welch wrote:
>
>> The address space, the cycle type and the data width fields should be
>> a OR'ed set of the capabilities you require from the resource. Not
>> all VME windows ar
);
> err_devalloc:
> list_for_each_entry_safe(vdev, tmp, &drv->devices, drv_list) {
> list_del(&vdev->drv_list);
> list_del(&vdev->bridge_list);
> device_unregister(&vdev->dev);
> }
>
On 25/02/13 13:50, ternaryd wrote:
> On Mon, 25 Feb 2013 12:10:28 +
> Martyn Welch wrote:
>
>>> On 25/02/13 10:24, ternaryd wrote:
>>> But I believe, that even the first test is incorrect. If vme_base +
>>> size must not be larger than VME_A16_MAX, and if
On 25/02/13 10:17, ternaryd wrote:
> On Mon, 25 Feb 2013 09:44:48 +
> Martyn Welch wrote:
>
> On 21/02/13 08:42, ternaryd wrote:
>>> The point is, that vme_user must not be compiled into the kernel,
>>> it needs to be built as a module. Otherwise, vme_user is
On 25/02/13 10:44, ternaryd wrote:
> On Mon, 25 Feb 2013 10:22:28 +
> Martyn Welch wrote:
>
>>> I haven't been able to get the serial console working. This is
>>> U-Boot based, and the last line is: "console [tty0] enabled,
>>> bootconsole disa
aphic addressing, but in both cases, slot 0 is returned.
>
Which cards? Are you sure the geographic address lines are wire back to the
VME bridge chip correctly (I know of boards where they aren't, sometimes the
bus address is exposed via other custom route...). That looks like it's n
the restriction you mention is hardware dependent.
In the case of the tsi148, see tsi148_slave_set() in
drivers/vme/bridges/vme_tsi148.c. The Universe II has different restrictions.
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms
quirements for A32 and A64 are different and covered in the
hardware manual.
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3A
On 14/01/13 19:21, ternaryd wrote:
> On Mon, 14 Jan 2013 17:17:04 +
> Martyn Welch wrote:
>
>> (Please keep this on list)
>
> Sorry, I missed the right reply-button.
>
>> It will require the core and at least one bridge to be registered
>> with it to be
(Please keep this on list)
On 14/01/13 15:35, ternaryd wrote:
> On Mon, 14 Jan 2013 11:14:33 +
> Martyn Welch wrote:
>
>> I'm afraid there's not much documentation about the user space access
>> at the moment. There is a module called "vme_user"
API, that's documented in the file you
found and additionally there is the "vme_user" and "vme_pio2" drivers in
"drivers/staging/vme/devices/" as examples.
>
> Thanks in advance,
>
No problem, hope that helps,
Martyn
--
Martyn Welch (Lead Software Engi
provided with the original driver at http://vmelinux.org/.
> + provided with the original driver at <http://www.vmelinux.org/>.
>
> config VME_PIO2
> tristate "GE PIO2 VME"
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE I
On 14/12/12 11:02, Konstantin Khlebnikov wrote:
> This patch forbids loading vme_pio2 module without specifing "num_bus"
> parameter.
> Otherwise on module unloading pio2_exit() calls vme_unregister_driver() for
> not
> registered pio2_driver.
>
Acked-by: Ma
: Martyn Welch
---
drivers/vme/boards/vme_vmivme7805.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/boards/vme_vmivme7805.c
b/drivers/vme/boards/vme_vmivme7805.c
index 8e05bb4..dd22b50 100644
--- a/drivers/vme/boards/vme_vmivme7805.c
+++ b
: Martyn Welch
---
drivers/vme/bridges/vme_ca91cx42.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/bridges/vme_ca91cx42.c
b/drivers/vme/bridges/vme_ca91cx42.c
index 1425d22c..64bfea3 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers
something new every day :-)
Acked-by: Martyn Welch
Thanks,
Martyn
---
drivers/vme/bridges/vme_tsi148.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index 5fbd08f..9c1aa4d 100644
--- a
George Schreck
> C.T.O.
>
> Beyond Electronics Corporation
> www.beyondelectronics.us
> ph 919-231-8000 ext 400
>
> ___
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/ma
buffer -> VME. Larger (more than a
> * page) transfers will lock the user space buffer into memory and then
> * transfer the data directly from the user space buffers out to VME.
>
Thanks for updating the patch, that's much better:
Acked-by: Martyn Welch
--
Martyn Welch (L
gt; + * We are going to alloc a page during init per window for small transfers.
Yup - that's OK.
Care to fix up the issues above?
Martyn
> * Small transfers will go user space -> buffer -> VME. Larger (more than a
> * page) transfers will lock the user space buffer into memory
On 25/07/12 10:20, Wolfgang Mauerer wrote:
> On 24/07/12 23:53, Martyn Welch wrote:
>> On 24/07/12 16:34, Wolfgang Mauerer wrote:
>>> On 20/07/12 10:48, Martyn Welch wrote:
>>>> On 19/07/12 23:39, Greg Kroah-Hartman wrote:
>>>>> On Thu, Jul 19,
On 24/07/12 16:34, Wolfgang Mauerer wrote:
> On 20/07/12 10:48, Martyn Welch wrote:
>> On 19/07/12 23:39, Greg Kroah-Hartman wrote:
>>> On Thu, Jul 19, 2012 at 08:08:50PM +0100, Martyn Welch wrote:
>
>> Still in two minds about whether we should keep vme_user around. It
On 19/07/12 23:39, Greg Kroah-Hartman wrote:
> On Thu, Jul 19, 2012 at 08:08:50PM +0100, Martyn Welch wrote:
>> The match function for vme_user is completely wrong. It will blindly bind
>> against the first VME slot on each bus (at this point that would be just the
>> first
the slot to which the bridge was attached in the VME
system and to the bus(es) provided via the "bus" module parameter.
To do this cleanly (i.e. without poking arround in the subsystems internal
stuctures) a functionality has been added to provide access to the bus
enumeration.
Signed-off-
VME
device.
The commit 53059aa05988761a738fa8bc082bbf3c5d4462d1 fixed this for the
ca91cx42, however this was not fixed for the tsi148 at the time. This patch
uses the same algorithm to fix the tsi148.
Reported-by: Daniel Lambert
Signed-off-by: Martyn Welch
---
drivers/vme/bridges/vme_tsi148.c
sizeof(struct vme_irq_id));
> if (copied != 0) {
> printk(KERN_WARNING "Partial copy from
> userspace\n");
>
Looks OK to me:
Acked-By: Martyn Welch
--
Martyn Welch (Lead Software Engineer) | Registered i
gt; -
> - return retval;
> -
> -err_reg:
> -err_nocard:
> - return retval;
> + return vme_register_driver(&vme_user_driver, VME_MAX_SLOTS);
> }
>
> static int vme_user_match(struct vme_dev *vdev)
> @@ -888,10 +859,6 @@ static void __exit vme_user_exit(void)
*
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the Free
> - * Software Foundation; either version 2 of the License, or (at your option)
> - * any later version.
> + * Softwar
rms of the GNU General Public License as published by the Free
> - * Software Foundation; either version 2 of the License, or (at your option)
> - * any later version.
> + * Software Foundation; version 2 of the License.
> */
>
> #ifndef _TPCI200_H_
--
Martyn Welch (Lead Soft
9,8 +9,8 @@ menuconfig IPACK_BUS
>
> if IPACK_BUS
>
> -source "drivers/staging/ipack/devices/Kconfig"
> -
> source "drivers/staging/ipack/bridges/Kconfig"
>
> +source "drivers/staging/ipack/devices/Kconfig"
> +
> endif # IPACK
On 03/05/12 17:36, Martyn Welch wrote:
> The documentation for the VME device driver API is currently in
> drivers/vme/vme_api.txt, move this to Documentation/vme_api.txt
>
> Signed-of-by: Martyn Welch
> ---
> {drivers/vme => Documentation}/vme_api.txt |0
> 1 fil
Add Martyn Welch, Manohar Vanga and Greg Kroah-Hartman as maintainers for
the VME subsystem.
Signed-off-by: Martyn Welch
---
MAINTAINERS | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 216dbf3..4e8ace8 100644
--- a/MAINTAINERS
The documentation for the VME device driver API is currently in
drivers/vme/vme_api.txt, move this to Documentation/vme_api.txt
Signed-of-by: Martyn Welch
---
{drivers/vme => Documentation}/vme_api.txt |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename {drivers/
ared. Should it be
> static?
> warning: symbol 'tsi148_free_consistent' was not declared. Should it be
> static?
>
> Signed-off-by: H Hartley Sweeten
> Cc: Greg Kroah-Hartman
> Cc: Martyn Welch
>
Good catch,
Acked-by: Martyn Welch
Martyn
> ---
>
>
ared. Should it be
> static?
> warning: symbol 'ca91cx42_free_consistent' was not declared. Should it be
> static?
>
> Signed-off-by: H Hartley Sweeten
> Cc: Greg Kroah-Hartman
> Cc: Martyn Welch
Good catch,
Acked-by: Martyn Welch
Martyn
>
> ---
>
> d
y are rather slow by todays standards) and as such is implemented as a GPIO
driver. I think it would make more sense to get this driver accepted under
drivers/gpio/.
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (382
n time. Would it be possible to merge the VME
core and bridge drivers and leave the VME device drivers (the contents of
devices/) in staging for a bit longer? The pio2 driver is basically a GPIO
device driver, so that should probably be merged into drivers/gpio/ and it
will give us a bit more time
Hi Greg,
Any chance these can be included in the staging tree soon? They form some
fairly fundamental bug fixing for the DMA support on the tsi148.
Martyn
On 22/03/12 13:27, Martyn Welch wrote:
> The DMA functionality fails to work on some Intel based platforms. Some
> recent Intel pla
On 23/03/12 10:21, Gerard Snitselaar wrote:
> loopback should be declared bool, and variant probably shouldn't be
> const.
>
> Signed-off-by: Gerard Snitselaar
Looks good, thanks,
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/devices/vme_pio2_core.c |4 ++-
On 22/03/12 13:48, Dan Carpenter wrote:
> On Thu, Mar 22, 2012 at 01:27:30PM +0000, Martyn Welch wrote:
>> The DMA functionality fails to work on little endian processors, such as
>> found on x86 based platforms. The DMA engine copies the link list
>> descriptors from m
functionality to ensure that the descriptors are stored in big
endian format.
Signed-off-by: Martyn Welch
---
drivers/staging/vme/bridges/vme_tsi148.c | 163 +-
drivers/staging/vme/bridges/vme_tsi148.h | 20 ++--
2 files changed, 103 insertions(+), 80 deletions(-)
diff
The DMA functionality fails to work on some Intel based platforms. Some
recent Intel platforms have an IOMMU. Transferring the DMA descriptors,
which were mapped using virt_to_phys(), failed. This patch updates the
driver to use dma_map_single().
Signed-off-by: Martyn Welch
---
drivers/staging
copies the link list descriptors from memory into big endian
registers. On little endian systems this results in the values being
byte swapped. This patch uses standard kernel functionality to ensure
that the descriptors are stored in big endian format.
Signed-off-by: Martyn Welch
abel;
> @@ -220,7 +220,7 @@ int __init pio2_gpio_init(struct pio2_card *card)
> return retval;
> };
>
> -void __exit pio2_gpio_exit(struct pio2_card *card)
> +void pio2_gpio_exit(struct pio2_card *card)
> {
> const char *label = card->gc.label;
>
--
After noting that Greg's moved to LF, it would have been wise to check his
email address. Hey ho...
On 13/02/12 14:20, Martyn Welch wrote:
> On 16/01/12 18:12, Greg KH wrote:
>> On Mon, Jan 16, 2012 at 02:16:59PM +0100, Manohar Vanga wrote:
>>> Hi Greg,
>>>
>>
any further
>> changes
>> needed when you have some time?
>
> Yes, I will look at this again soon.
>
Congratulations on your move to LF. Any chance this could happen soon?
Martyn
> thanks,
>
> greg k-h
--
Martyn Welch (Lead Software Engineer) | Registered in Engl
On 20/01/12 09:11, Sam Hansen wrote:
> Fixed a code convention violation in vme.h
>
> Signed-off-by: Sam Hansen
Huh, wonder how that got missed when I ran checkpatch over these files.
Good catch,
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/vme.h |2 +-
>
The PIO2 driver errors when GPIOLIB, on which it depends, is not enabled.
Add dependancy when selecting the PIO2.
Reported-by: Randy Dunlap
Signed-off-by: Martyn Welch
---
Sorry, missed the email on the 6th.
drivers/staging/vme/devices/Kconfig |1 +
1 files changed, 1 insertions(+), 0
The use of typedefs is discouraged, remove them.
Signed-off-by: Martyn Welch
---
drivers/staging/vme/bridges/vme_ca91cx42.c | 18
drivers/staging/vme/bridges/vme_tsi148.c | 36 +++--
drivers/staging/vme/devices/vme_user.h | 10 ++---
drivers/staging/vme/vme.c
e window closes, next week, I'll take a look at the
>> code and let you know what I think needs to be done to get this out of
>> staging.
>
> Ok, I didn't get past vme.h, please remove all the typedefs and the
> foolish _t stuff, and we can then retry this :)
>
On 30/11/11 10:34, Greg KH wrote:
> On Tue, Nov 29, 2011 at 01:28:05PM +0000, Martyn Welch wrote:
>> From: root
>
> I think you got this wrong :)
>
Yeah - I was building this on a embedded system with an NFS file system. Due
to write permissions to the directory, I had to r
uot; array (used to store mask
configuration as these registers are write only) and thus causing memory
corruption. Clear both registers of masks for each bank and half iterations.
Reported-by: Dan Carpenter
Signed-off-by: Martyn Welch
---
drivers/staging/vme/devices/vme_pio2_gpio.c |9 +++-
entation/devices.txt, especially since vme_user
doesn't use the same interface as the driver at vmelinux.org? What if
vmelinux.org has gone away?
Martyn
>
> Thanks,
> Zvika.
>
> - Original Message - From: "Martyn Welch"
> To: "Zvi Vered"
> Cc:
ppears that the version of mdev you are using isn't. Which
version of busybox are you using? It appears from the busybox website that
support for the "!" syntax was added to mdev in busybox 1.17.0.
Martyn
> Thanks,
> Zvika.
>
> - Original Message - From: &q
I148=m, CONFIG_VME_USER=m so upon 'make
> modules', the 2 modules are built.
>
> Upon rcS completion I expect to find the files: /dev/bus/vme/m0 ...
> /dev/bus/vme/s3
>
> Am I right ?
>
Have you tried that?
Martyn
> Thanks,
> Zvika.
>
> - O
ed.
> How can I access the VME using this driver ?
>
Using the in kernel API.
> Must I use CONFIG_VME_USER=y also ?
>
Tf you want access from user space, that module provides some basic access to
the VME bus.
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in Engl
pio2_gpio_exit(struct pio2_card *);
+
+#endif /* _VME_PIO2_H_ */
diff --git a/drivers/staging/vme/devices/vme_pio2_cntr.c
b/drivers/staging/vme/devices/vme_pio2_cntr.c
new file mode 100644
index 000..08e0d59
--- /dev/null
+++ b/drivers/staging/vme/devices/vme_pio2_cntr.c
@@ -0,0 +1,71 @@
+/*
+ * GE P
On 07/11/11 18:26, Paul Bolle wrote:
> On Mon, 2011-11-07 at 17:27 +0000, Martyn Welch wrote:
>> + If you say Y here you have a GE PIO2. The PIO2 is a 6U VME Card,
>
> I've tried that about a dozen times and I still don't have a GE PIO2.
> But perhaps its very sma
From: Martyn Welch
This patch implements a driver for the GE PIO2 VME Parallel I/O Card. This
card is a 6U VME Card, implementing 32 solid-state relay switched IO lines,
in 4 groups of 8. Each bank of IO lines is built to function as input,
output or both depending on the variant of the card
On 07/11/11 09:55, Paul Bolle wrote:
> On Mon, 2011-11-07 at 09:34 +0000, Martyn Welch wrote:
>> On 04/11/11 19:55, Paul Bolle wrote:
>>>> +implementing 32 solid-state relay switched IO lines, in 4 groups of 8.
>>>> +The IO lines are provided as inpu
On 04/11/11 20:00, Greg KH wrote:
> On Fri, Nov 04, 2011 at 08:55:14PM +0100, Paul Bolle wrote:
>> A few random remarks follow. Ie, things that came up while quickly
>> scanning this.
>>
>> On Fri, 2011-11-04 at 17:33 +, Martyn Welch wrote:
>>> diff --git a
On 04/11/11 19:55, Paul Bolle wrote:
> A few random remarks follow. Ie, things that came up while quickly
> scanning this.
>
> On Fri, 2011-11-04 at 17:33 +0000, Martyn Welch wrote:
>> diff --git a/drivers/staging/vme/devices/Kconfig
>> b/drivers/staging/vme/devices/
On 04/11/11 17:33, Martyn Welch wrote:
> From: Martyn Welch
>
Agh, how did that get in there. As in the "signed-off-by" line my email
address is (and has been for a while now) "martyn.we...@ge.com".
Martyn
> This patch implements a driver for the GE PIO2 VME Paral
From: Martyn Welch
This patch implements a driver for the GE PIO2 VME Parallel I/O Card. This
card is a 6U VME Card, implementing 32 solid-state relay switched IO lines,
in 4 groups of 8. The IO lines are provided as input, output or both as a
build time option.
Signed-off-by: Martyn Welch
On 04/11/11 10:12, Manohar Vanga wrote:
> Signed-off-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/vme.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/vme/vme.h b/drivers/staging/vme/vme.h
> index e3
ister_bridge().
>
> Signed-off-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/vme.c | 26 --
> 1 files changed, 8 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/vme/vme.c b/drivers/staging/vme/vme.c
> i
On 04/11/11 10:12, Manohar Vanga wrote:
> Signed-off-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/vme.c |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/vme/vme.c b/drivers/staging/vme/vme.c
> i
Contents of TODO file has become more of a feature wish-list rather than issues
which should stop the VME driver being merged into the mainline kernel.
Update the TODO list with issues that need to be resolved before it can be
migrated to mainline.
Signed-off-by: Martyn Welch
---
Rather than
t having my own git
tree setup). Greg: are you still happy with this or do I need to make other
arrangements?
Martyn
> regards,
> dan carpenter
>
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642)
e the probe function calls vme_bridge_get().
This function no longer exists and I can't quickly see this lock being sought
in the new probing code, so is it still safe?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms
On 11/10/11 13:04, Greg KH wrote:
> On Tue, Oct 11, 2011 at 12:56:32PM +0100, Martyn Welch wrote:
>> On 26/09/11 10:27, Manohar Vanga wrote:
>>> Hi,
>>>
>>> I start by apologizing for my absence recently as I was away on vacation
>>> for a few weeks. Pi
my end. I've had to take paternity
leave a little earlier than expected (I wasn't expecting to be AFK for another
few days). I haven't had a chance to sit down and look over and try out these
patches as I'd like to. I'll probably be rather tied up for about another week
I'
xt) and never be statically allocated.
>
> Signed-off-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/vme.c| 21 +
> drivers/staging/vme/vme_bridge.h |2 +-
> 2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff
ches the (widely used, more historic subset) of
capabilites of the VME bus. I think we can just move the slot number to
vme_dev and do away with vme_device_id entirely.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wa
> thanks,
>
> greg k-h
Thanks Greg, I think that's all the patches that have been agreed so far. I
believe that Manohar is working on a few issues that were found in some of the
other patches.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE I
hrow a false warning if the kernel is
> built without module support. Note that in that case
>
> THIS_MODULE == (struct module *)0.
>
> try_module_get() and module_put() do the right thing for all
> possible configs. Trust them.
>
I can confirm that this does break when the bridge is
On 19/08/11 09:32, Martyn Welch wrote:
> On 13/08/11 09:54, Emilio G. Cota wrote:
>> On Fri, Aug 12, 2011 at 12:30:49 +0200, Manohar Vanga wrote:
>>> This patch adds functions that allow for reference counting
>>> bridge modules. The patch introduces the functions
n the struct vme_dev to both functions.
Martyn
> But the locking needs to be handled with care, see my reply
> to patch 5.
>
> Emilio
>
> ___
> devel mailing list
> devel@linuxdriverproject.org
> http://driv
ff-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/bridges/vme_ca91cx42.c | 24 ++
> drivers/staging/vme/bridges/vme_tsi148.c | 24 ++
> drivers/staging/vme/vme.c | 36 ---
G. Cota in the
> patch:
>
> https://lkml.org/lkml/2010/10/25/486
>
> Signed-off-by: Manohar Vanga
Acked-by: Martyn Welch
> ---
> drivers/staging/vme/vme.c| 38
> +++---
> drivers/staging/vme/vme_bridge.h |1 +
> 2
bridge device this device is on
> * @dev: Internal device structure
> + * @list: List of devices (per driver)
> */
> struct vme_dev {
> struct vme_device_id id;
> struct vme_bridge *bridge;
> struct device dev;
> + struct list_head list;
> };
>
> struct vme_driver {
> st
t *vme_new_dma_list(struct vme_resource *);
> struct vme_dma_attr *vme_dma_pattern_attribute(u32, vme_pattern_t);
> struct vme_dma_attr *vme_dma_pci_attribute(dma_addr_t);
> @@ -147,12 +164,12 @@ int vme_dma_list_exec(struct vme_dma_list *);
> int vme_dma_list_free(struct vme_dma_li
drivers/staging/vme/vme_bridge.h
> b/drivers/staging/vme/vme_bridge.h
> index 8959670..ef751a4 100644
> --- a/drivers/staging/vme/vme_bridge.h
> +++ b/drivers/staging/vme/vme_bridge.h
> @@ -113,6 +113,7 @@ struct vme_bridge {
> struct device *parent; /* Parent device (eg. pdev->dev for PCI) */
> void *driver_
1 - 100 of 198 matches
Mail list logo
