On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire. The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> We cannot switch to using obj->resv for locking without first moving all
> the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
> mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
>
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
> skip over bo's that are already locked. This gets rid of the nested
> lock classes.
>
> Signed-off-by: Rob Clark
> ---
>
On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire. The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit
On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun, 4 Oct 2020 12:21:45
> > > From: Rob Clark
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected
On Tue, Sep 1, 2020 at 8:41 AM Rob Clark wrote:
>
> From: Rob Clark
>
> This reduces the spam in dmesg when we start hitting the shrinker, and
> replaces it with something we can put on a timeline while profiling or
> debugging system issues.
That is a good solution,
Reviewed-by: Kristian H.
On Tue, May 7, 2019 at 11:02 AM Jordan Crouse wrote:
>
> When we move to 64 bit addressing for a5xx and a6xx targets we will start
> seeing pagefaults at larger addresses so format them appropriately in the
> log message for easier debugging.
Yes please, this has confused me more than once.
On 10/1/07, Pieter Palmers <[EMAIL PROTECTED]> wrote:
> Stefan Richter wrote:
> >> This duplicates the read cycle timer feature of raw1394 (added in Linux
> >> 2.6.21) in firewire-core's userspace ABI.
> >
> > Kristian and Pieter, does this simple duplication of the ioctl make
> > sense on its
On 10/1/07, Pieter Palmers [EMAIL PROTECTED] wrote:
Stefan Richter wrote:
This duplicates the read cycle timer feature of raw1394 (added in Linux
2.6.21) in firewire-core's userspace ABI.
Kristian and Pieter, does this simple duplication of the ioctl make
sense on its own? AFAIU
On Tue, 2007-08-28 at 21:50 +0100, Dave Airlie wrote:
> On Tue, 28 Aug 2007, Christoph Hellwig wrote:
>
> > On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote:
> >> Hello,
> >>
> >>As there are many places in drm code where drm_alloc + memset is used
> >> this patch series
On Tue, 2007-08-28 at 21:50 +0100, Dave Airlie wrote:
On Tue, 28 Aug 2007, Christoph Hellwig wrote:
On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote:
Hello,
As there are many places in drm code where drm_alloc + memset is used
this patch series introduces
On Mon, 2007-06-25 at 16:31 -0400, Steven Rostedt wrote:
> On Mon, 2007-06-25 at 16:07 -0400, Kristian Høgsberg wrote:
>
> > > Maybe we should be looking at something like GENERIC_SOFTIRQ to run
> > > functions that a driver could add. But they would run only on the CPU
&
On Mon, 2007-06-25 at 15:11 -0400, Steven Rostedt wrote:
> On Mon, 2007-06-25 at 14:48 -0400, Kristian Høgsberg wrote:
> ...
> > However, I don't really understand how you can discuss a wholesale
> > replacing of tasklets with workqueues, given the very different
> > execu
On Fri, 2007-06-22 at 23:59 +0200, Ingo Molnar wrote:
> so how about the following, different approach: anyone who has a tasklet
> in any performance-sensitive codepath, please yell now. We'll also do a
> proactive search for such places. We can convert those places to
> softirqs, or move them
On Fri, 2007-06-22 at 23:59 +0200, Ingo Molnar wrote:
so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now. We'll also do a
proactive search for such places. We can convert those places to
softirqs, or move them back
On Mon, 2007-06-25 at 15:11 -0400, Steven Rostedt wrote:
On Mon, 2007-06-25 at 14:48 -0400, Kristian Høgsberg wrote:
...
However, I don't really understand how you can discuss a wholesale
replacing of tasklets with workqueues, given the very different
execution sematics of the two
On Mon, 2007-06-25 at 16:31 -0400, Steven Rostedt wrote:
On Mon, 2007-06-25 at 16:07 -0400, Kristian Høgsberg wrote:
Maybe we should be looking at something like GENERIC_SOFTIRQ to run
functions that a driver could add. But they would run only on the CPU
that scheduled them, and do
Remove all ids from the given idr tree. idr_destroy() only frees up
unused, cached idp_layers, but this function will remove all id mappings
and leave all idp_layers unused.
A typical clean-up sequence for objects stored in an idr tree, will
use idr_for_each() to free all objects, if necessay,
This patch adds an iterator function for the idr data structure. Compared
to just iterating through the idr with an integer and idr_find, this
iterator is (almost, but not quite) linear in the number of elements,
as opposed to the number of integers in the range covered by the idr. This
makes a
Remove all ids from the given idr tree. idr_destroy() only frees up
unused, cached idp_layers, but this function will remove all id mappings
and leave all idp_layers unused.
A typical clean-up sequence for objects stored in an idr tree, will
use idr_for_each() to free all objects, if necessay,
This patch adds an iterator function for the idr data structure. Compared
to just iterating through the idr with an integer and idr_find, this
iterator is (almost, but not quite) linear in the number of elements,
as opposed to the number of integers in the range covered by the idr. This
makes a
On 5/25/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
Of course everybody immediately associates "fw-" with FireWire, not
firmware or firewall or whatever. But "firewire-" has a nice ring to
it too.
It's fine with me. I like the less ambiguous names better, and I
don't think the length of
On 5/25/07, Stefan Richter [EMAIL PROTECTED] wrote:
Of course everybody immediately associates fw- with FireWire, not
firmware or firewall or whatever. But firewire- has a nice ring to
it too.
It's fine with me. I like the less ambiguous names better, and I
don't think the length of the
On 5/22/07, Pierre Ossman <[EMAIL PROTECTED]> wrote:
Kay Sievers wrote:
> We could change the driver-core to suppress the creation of an attribute
> if the attribute's show() or store() method returns something like
> -ENOENT at registration time?
> The driver would pass _all_ possible
On 5/22/07, Pierre Ossman [EMAIL PROTECTED] wrote:
Kay Sievers wrote:
We could change the driver-core to suppress the creation of an attribute
if the attribute's show() or store() method returns something like
-ENOENT at registration time?
The driver would pass _all_ possible attributes of
Christoph Hellwig wrote:
+ if (pci_enable_device(dev)) {
+ fw_error("Failed to enable OHCI hardware.\n");
+ return cleanup(ohci, CLEANUP_PUT_CARD, -ENODEV);
Please use normal goto unwinding so the driver follows the same model
as almost all other pci drivers
Stefan Richter wrote:
Kristian Høgsberg wrote:
I was trying to be clever and only allocate the host once the device had
been discovered and initialized. I have now changed the code to just
allocate the host up front and use the hostdata mechanism for the
sbp2_device struct, which also
Christoph Hellwig wrote:
+ sg = (struct scatterlist *)orb->cmd->request_buffer;
+ count = dma_map_sg(device->card->device, sg, orb->cmd->use_sg,
+ orb->cmd->sc_data_direction);
you need to handle the error case (count == 0)
Yup, done.
+ /* Convert
Christoph Hellwig wrote:
+ sg = (struct scatterlist *)orb-cmd-request_buffer;
+ count = dma_map_sg(device-card-device, sg, orb-cmd-use_sg,
+ orb-cmd-sc_data_direction);
you need to handle the error case (count == 0)
Yup, done.
+ /* Convert the
Stefan Richter wrote:
Kristian Høgsberg wrote:
I was trying to be clever and only allocate the host once the device had
been discovered and initialized. I have now changed the code to just
allocate the host up front and use the hostdata mechanism for the
sbp2_device struct, which also
Christoph Hellwig wrote:
+ if (pci_enable_device(dev)) {
+ fw_error(Failed to enable OHCI hardware.\n);
+ return cleanup(ohci, CLEANUP_PUT_CARD, -ENODEV);
Please use normal goto unwinding so the driver follows the same model
as almost all other pci drivers and
Olaf Hering wrote:
On Thu, May 03, Olaf Hering wrote:
On Thu, May 03, Stefan Richter wrote:
ieee1394-old
Noone will seriously ship two firewire stacks, so that cant be the
issue (for distributors).
Once there is a way to easily switch between kernel releases, I'm ok
with whatever
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 05:11:45PM -0400, Kristian H??gsberg wrote:
The firewire-cdev.h file is meant to be a self-contained userspace header
file and shouldn't include other kernel header files. All duplicated
values are standardized ieee1394 values and won't ever
Christoph Hellwig wrote:
On Thu, May 03, 2007 at 01:01:08AM +0200, Stefan Richter wrote:
Christoph Hellwig wrote:
+fw-core-objs := fw-card.o fw-topology.o fw-transaction.o fw-iso.o \
+ fw-device.o fw-cdev.o
fw-core-y += ..
Like such?
Exactly.
OK, changed that here, will push out
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 02:17:26PM +0200, Stefan Richter wrote:
+#include
+#include
Always use the
Fixed.
+struct fw_cdev_get_info {
+ /* The version field is just a running serial number. We
+* never break backwards compatibility. Userspace
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 02:15:42PM +0200, Stefan Richter wrote:
+/* -*- c-basic-offset: 8 -*-
Please don't pollute the code with annotation for some editors.
OK.
+ * fw-card.c - card level functions
Please don't put
Pekka Enberg wrote:
On 5/2/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
I looked around a bit with grep -R and a few search terms but didn't
find something definite. Is there any other user of a crc16_itu_t or
crc_ccitt or whatever which operates on a (CPU byte ordered) u32[]
instead of on a
Pekka Enberg wrote:
On 5/2/07, Stefan Richter [EMAIL PROTECTED] wrote:
I looked around a bit with grep -R and a few search terms but didn't
find something definite. Is there any other user of a crc16_itu_t or
crc_ccitt or whatever which operates on a (CPU byte ordered) u32[]
instead of on a
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 02:15:42PM +0200, Stefan Richter wrote:
+/* -*- c-basic-offset: 8 -*-
Please don't pollute the code with annotation for some editors.
OK.
+ * fw-card.c - card level functions
Please don't put
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 02:17:26PM +0200, Stefan Richter wrote:
+#include asm/ioctl.h
+#include asm/types.h
Always use the linux/ versions.
Fixed.
+struct fw_cdev_get_info {
+ /* The version field is just a running serial number. We
+* never break
Christoph Hellwig wrote:
On Thu, May 03, 2007 at 01:01:08AM +0200, Stefan Richter wrote:
Christoph Hellwig wrote:
+fw-core-objs := fw-card.o fw-topology.o fw-transaction.o fw-iso.o \
+ fw-device.o fw-cdev.o
fw-core-y += ..
Like such?
Exactly.
OK, changed that here, will push out
Christoph Hellwig wrote:
On Wed, May 02, 2007 at 05:11:45PM -0400, Kristian H??gsberg wrote:
The firewire-cdev.h file is meant to be a self-contained userspace header
file and shouldn't include other kernel header files. All duplicated
values are standardized ieee1394 values and won't ever
Olaf Hering wrote:
On Thu, May 03, Olaf Hering wrote:
On Thu, May 03, Stefan Richter wrote:
ieee1394-old
Noone will seriously ship two firewire stacks, so that cant be the
issue (for distributors).
Once there is a way to easily switch between kernel releases, I'm ok
with whatever
Adrian Bunk wrote:
| An advantage of changing the names is that they are now prefixed.
Is the opportunity to clean up module names compelling enough, vs. (the
wish for) minimized trouble with scripts which refer to module names?
...
How big is the trouble actually?
Exactly. In Fedora we've
Adrian Bunk wrote:
| An advantage of changing the names is that they are now prefixed.
Is the opportunity to clean up module names compelling enough, vs. (the
wish for) minimized trouble with scripts which refer to module names?
...
How big is the trouble actually?
Exactly. In Fedora we've
Christoph Hellwig wrote:
+ for (i = 0; i < buffer->page_count; i++) {
+ buffer->pages[i] = alloc_page(GFP_KERNEL | GFP_DMA32 |
__GFP_ZERO);
+ if (buffer->pages[i] == NULL)
+ goto out_pages;
+
+ address =
Pekka Enberg wrote:
On 5/2/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
+/* The lib/crc16.c implementation uses the standard (0x8005)
+ * polynomial, but we need the ITU-T (or CCITT) polynomial (0x1021).
+ * The implementation below works on an array of host-endian u32
+ * words, assuming
John Stoffel wrote:
"Stefan" == Stefan Richter <[EMAIL PROTECTED]> writes:
Stefan> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
Stefan> ---
Stefan> drivers/firewire/fw-cdev.c| 954 ++
Stefan> include/linux/firewire-cdev.h | 268 +
Stefan> 2
Adrian Bunk wrote:
On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote:
Olaf Hering wrote:
On Tue, May 01, Kristian Høgsberg wrote:
drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code,
Last time I believe I was the only one
Stefan Richter wrote:
Christoph Hellwig wrote:
..
Please send out patches for review first.
Yes, it's been a while since the last submission for review [1], and
most of the changes went over linux1394-devel only. And to put it
mildly, there aren't a lot of capable reviewers watching that
Olaf Hering wrote:
On Tue, May 01, Kristian Høgsberg wrote:
drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code, and keep all
existing module names.
What's your reasoning here? Having different module names allows people to
compile
Olaf Hering wrote:
On Tue, May 01, Kristian Høgsberg wrote:
drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code, and keep all
existing module names.
What's your reasoning here? Having different module names allows people to
compile
Adrian Bunk wrote:
On Wed, May 02, 2007 at 02:48:11PM +0200, Stefan Richter wrote:
Olaf Hering wrote:
On Tue, May 01, Kristian Høgsberg wrote:
drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code,
Last time I believe I was the only one
Stefan Richter wrote:
Christoph Hellwig wrote:
..
Please send out patches for review first.
Yes, it's been a while since the last submission for review [1], and
most of the changes went over linux1394-devel only. And to put it
mildly, there aren't a lot of capable reviewers watching that
John Stoffel wrote:
Stefan == Stefan Richter [EMAIL PROTECTED] writes:
Stefan Signed-off-by: Stefan Richter [EMAIL PROTECTED]
Stefan ---
Stefan drivers/firewire/fw-cdev.c| 954 ++
Stefan include/linux/firewire-cdev.h | 268 +
Stefan 2 files
Pekka Enberg wrote:
On 5/2/07, Stefan Richter [EMAIL PROTECTED] wrote:
+/* The lib/crc16.c implementation uses the standard (0x8005)
+ * polynomial, but we need the ITU-T (or CCITT) polynomial (0x1021).
+ * The implementation below works on an array of host-endian u32
+ * words, assuming
Christoph Hellwig wrote:
+ for (i = 0; i buffer-page_count; i++) {
+ buffer-pages[i] = alloc_page(GFP_KERNEL | GFP_DMA32 |
__GFP_ZERO);
+ if (buffer-pages[i] == NULL)
+ goto out_pages;
+
+ address = dma_map_page(card-device,
Hi Linus,
As you may know, we've been working on a new FireWire stack over on
linux1394-devel. The main driver behind this work is to get a small,
maintainable and supportable FireWire stack, with an acceptable
backwards compatibility story.
I've been talking to Stefan Richter about it and we
Hi Linus,
As you may know, we've been working on a new FireWire stack over on
linux1394-devel. The main driver behind this work is to get a small,
maintainable and supportable FireWire stack, with an acceptable
backwards compatibility story.
I've been talking to Stefan Richter about it and we
On 3/17/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
This considerably reduces the memory requirements for a packet and
eliminates ieee1394's dependency on CONFIG_NET.
Nice work Stefan, the skb rewrite was one of the most pointless
rewrites in the history of the linux1394 stack.
TODO:
-
On 3/17/07, Stefan Richter [EMAIL PROTECTED] wrote:
This considerably reduces the memory requirements for a packet and
eliminates ieee1394's dependency on CONFIG_NET.
Nice work Stefan, the skb rewrite was one of the most pointless
rewrites in the history of the linux1394 stack.
TODO:
-
Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
Indeed, I've just moved to an in-tree development model now. I still think
the out-off-tree model is a good way to prototype, get started and reach
"critical mass"
Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg [EMAIL PROTECTED] wrote:
Indeed, I've just moved to an in-tree development model now. I still think
the out-off-tree model is a good way to prototype, get started and reach
critical mass with your driver. But as I'm
Greg KH wrote:
On Thu, Jan 25, 2007 at 03:38:24PM -0800, Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian H??gsberg <[EMAIL PROTECTED]>
wrote:
I see that ORBs are always allocated with a call (like SKB) and not
embedded into drivers (like URBs). It's great, keep it up. Also,
Greg KH wrote:
On Thu, Jan 25, 2007 at 03:38:24PM -0800, Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian H??gsberg [EMAIL PROTECTED]
wrote:
I see that ORBs are always allocated with a call (like SKB) and not
embedded into drivers (like URBs). It's great, keep it up. Also,
Stefan Richter wrote:
Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
...
will do a status write to the status address specified in the ORB, at which
point the SBP-2 transaction is complete.
You know, I wanted to use this p
Pete Zaitcev wrote:
Hi, Kristian:
I only looked briefly at SBP-2, and at submit/callback paths it pulled,
because I do not understand most of the other issues.
Great, thanks for giving this a look-over, much appreciated.
Executive summary: please implement proper ORB cancellation. This is
Pete Zaitcev wrote:
Hi, Kristian:
I only looked briefly at SBP-2, and at submit/callback paths it pulled,
because I do not understand most of the other issues.
Great, thanks for giving this a look-over, much appreciated.
Executive summary: please implement proper ORB cancellation. This is
Stefan Richter wrote:
Pete Zaitcev wrote:
On Thu, 25 Jan 2007 16:18:35 -0500, Kristian Høgsberg [EMAIL PROTECTED] wrote:
...
will do a status write to the status address specified in the ORB, at which
point the SBP-2 transaction is complete.
You know, I wanted to use this picture for a long
Hi,
I've moved the new FireWire stack to an in-tree git repository and
moved over the missing patches from my out-of-tree version. The tree
is available over here:
git://people.freedesktop.org/~krh/linux-2.6
with gitweb avialable here:
Hi,
I've moved the new FireWire stack to an in-tree git repository and
moved over the missing patches from my out-of-tree version. The tree
is available over here:
git://people.freedesktop.org/~krh/linux-2.6
with gitweb avialable here:
Adrian Bunk wrote:
On Mon, Jan 22, 2007 at 02:41:29PM -0500, Kristian Høgsberg wrote:
Adrian Bunk wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc3-mm1:
...
git-ieee1394.patch
...
git trees
...
This patch contains the following cleanups
like how extern inline will never generate code and
that gcc warns on missing prototype for these case is more of a gcc bug. Not
a big deal though, it's more worthwhile to track down real missing prototype
offenders.
- fw-topology.c: make struct fw_node_create static
Looks good.
Signed-of
will never generate code and
that gcc warns on missing prototype for these case is more of a gcc bug. Not
a big deal though, it's more worthwhile to track down real missing prototype
offenders.
- fw-topology.c: make struct fw_node_create static
Looks good.
Signed-off-by: Kristian Høgsberg [EMAIL
Adrian Bunk wrote:
On Mon, Jan 22, 2007 at 02:41:29PM -0500, Kristian Høgsberg wrote:
Adrian Bunk wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc3-mm1:
...
git-ieee1394.patch
...
git trees
...
This patch contains the following cleanups
On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> However, what I'd really like to do is to leave it to user space to
> allocate the memory as David describes. In the transmit case, user
> space allocates memory (malloc or mmap) and loads the payload into
> that buffer.
there is a lot
On 1/15/07, David Moore <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-15 at 10:20 -0800, Arjan van de Ven wrote:
> if you need that much you probably should redesign your algorithms to
> not need vmalloc in the first place
I think you've convinced me that vmalloc is not a good choice when a
On 1/15/07, Philipp Beyer <[EMAIL PROTECTED]> wrote:
Thanks for your input. My post was based on the (wrong) idea that
the kernel already uses different timeout values per node.
Therefore, having read your answer, I have a different opinion about
how to solve this now.
About your suggestions:
On 1/15/07, Philipp Beyer [EMAIL PROTECTED] wrote:
Thanks for your input. My post was based on the (wrong) idea that
the kernel already uses different timeout values per node.
Therefore, having read your answer, I have a different opinion about
how to solve this now.
About your suggestions:
On 1/15/07, David Moore [EMAIL PROTECTED] wrote:
On Mon, 2007-01-15 at 10:20 -0800, Arjan van de Ven wrote:
if you need that much you probably should redesign your algorithms to
not need vmalloc in the first place
I think you've convinced me that vmalloc is not a good choice when a
driver
On 1/15/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
However, what I'd really like to do is to leave it to user space to
allocate the memory as David describes. In the transmit case, user
space allocates memory (malloc or mmap) and loads the payload into
that buffer.
there is a lot of
Stefan Richter wrote:
...
And Windows Vista will drop the IP over 1394 functionality,
which is another data point about how widely used this standard is.
If we cared what Windows supports or does not support, we would have gap
count optimization by now, but no support of IEEE 1394b-2002.
Pieter Palmers wrote:
Kristian Høgsberg wrote:
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
.. for some reason I didn't get patch 3/4 and 4/4
Robert Hancock wrote:
Kristian Høgsberg wrote:
...
+static struct pci_driver fw_ohci_pci_driver = {
+.name= ohci_driver_name,
+.id_table= pci_table,
+.probe= pci_probe,
+.remove= pci_remove,
+};
How about suspend/resume support? Lots of laptops
Stefan Richter wrote:
Kristian Høgsberg wrote:
...
to sum up the changes:
- Got rid of bitfields.
- Tested on ppc, ppc64 x86-64 and x86.
- ioctl interface tested on 32-bit userspace / 64-bit kernels.
- ASCIIfied sources.
- Incorporated Jeff Garziks comments.
- Updated to work
Stefan Richter wrote:
Kristian Høgsberg wrote:
...
to sum up the changes:
- Got rid of bitfields.
- Tested on ppc, ppc64 x86-64 and x86.
- ioctl interface tested on 32-bit userspace / 64-bit kernels.
- ASCIIfied sources.
- Incorporated Jeff Garziks comments.
- Updated to work
Robert Hancock wrote:
Kristian Høgsberg wrote:
...
+static struct pci_driver fw_ohci_pci_driver = {
+.name= ohci_driver_name,
+.id_table= pci_table,
+.probe= pci_probe,
+.remove= pci_remove,
+};
How about suspend/resume support? Lots of laptops
Pieter Palmers wrote:
Kristian Høgsberg wrote:
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
.. for some reason I didn't get patch 3/4 and 4/4
Stefan Richter wrote:
...
And Windows Vista will drop the IP over 1394 functionality,
which is another data point about how widely used this standard is.
If we cared what Windows supports or does not support, we would have gap
count optimization by now, but no support of IEEE 1394b-2002.
Signed-off-by: Kristian Hoegsberg <[EMAIL PROTECTED]>
---
drivers/firewire/Makefile |3
drivers/firewire/fw-card.c| 56 +++
drivers/firewire/fw-device-cdev.c | 617 +
drivers/firewire/fw-device-cdev.h | 146 +
Signed-off-by: Kristian Hoegsberg <[EMAIL PROTECTED]>
---
drivers/firewire/Kconfig | 11
drivers/firewire/Makefile |1
drivers/firewire/fw-ohci.c | 1394
drivers/firewire/fw-ohci.h | 152 +
4 files changed, 1558 insertions(+), 0
Signed-off-by: Kristian Hoegsberg <[EMAIL PROTECTED]>
---
drivers/firewire/Kconfig | 12
drivers/firewire/Makefile |1
drivers/firewire/fw-sbp2.c | 1073
3 files changed, 1086 insertions(+), 0 deletions(-)
diff --git
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
http://gitweb.freedesktop.org/?p=users/krh/juju.git
but to sum up the changes:
- Got rid of bitfields.
Hi,
Here's a new set of patches for the new firewire stack. The changes
since the last set of patches address the issues that were raised on
the list and can be reviewed in detail here:
http://gitweb.freedesktop.org/?p=users/krh/juju.git
but to sum up the changes:
- Got rid of bitfields.
Signed-off-by: Kristian Hoegsberg [EMAIL PROTECTED]
---
drivers/firewire/Kconfig | 12
drivers/firewire/Makefile |1
drivers/firewire/fw-sbp2.c | 1073
3 files changed, 1086 insertions(+), 0 deletions(-)
diff --git
Signed-off-by: Kristian Hoegsberg [EMAIL PROTECTED]
---
drivers/firewire/Makefile |3
drivers/firewire/fw-card.c| 56 +++
drivers/firewire/fw-device-cdev.c | 617 +
drivers/firewire/fw-device-cdev.h | 146 +
Signed-off-by: Kristian Hoegsberg [EMAIL PROTECTED]
---
drivers/firewire/Kconfig | 11
drivers/firewire/Makefile |1
drivers/firewire/fw-ohci.c | 1394
drivers/firewire/fw-ohci.h | 152 +
4 files changed, 1558 insertions(+), 0
Pull this define out of drivers/ieee1394/ohci1394.c and rename to match
other PCI class defines.
---
drivers/ieee1394/ohci1394.c |4 +---
include/linux/pci_ids.h |1 +
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/ieee1394/ohci1394.c
Pull this define out of drivers/ieee1394/ohci1394.c and rename to match
other PCI class defines.
---
drivers/ieee1394/ohci1394.c |4 +---
include/linux/pci_ids.h |1 +
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/ieee1394/ohci1394.c
Stefan Richter wrote:
Kristian Høgsberg wrote:
Jeff Garzik wrote:
doesn't allowing the stack to issue REPORT LUNS take care of this?
Possibly, I don't have firewire multi-LUN devices to test with here.
The LUNs are also discoverable from the firewire config rom, which is
why I put
1 - 100 of 135 matches
Mail list logo
