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 p
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
> p
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
> ---
> drivers/gpu/drm/msm/msm_gem.
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 pat
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. Kr
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.
Revi
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?
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 intr
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
> >
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 b
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, th
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 d
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 attributes
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 an
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
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 cha
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 ne
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 passe
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 the
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 (
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 = dma_map_page(card->dev
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 they'
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 fi
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 lis
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
co
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 f
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:
- Do
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
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,
n
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
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
ho
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:
http://gitweb.freedesktop.org/?p=users/krh/linux-2.6.gi
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
I do 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.
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
dri
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:
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.
Yeah
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
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 with
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 +
drivers/firewire/fw
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 deletion
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 a/drivers/firewire/Kconf
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.
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 b/drivers/ieee1394/ohci1394
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
Jeff Garzik wrote:
Again, thanks for your comments, I've added patches to my git repo, will send
out a new set on LKML before the end of this week.
+/* I don't know why the SCSI stack doesn't define something like
this... */
+typedef void (*scsi_done_fn_t) (struct scsi_cmnd *);
submit a pa
On 12/8/06, Stefan Richter <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote at linux-kernel:
> On Tue 05-12-06 17:05:30, Erik Mouw wrote:
>> On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian H?gsberg wrote:
>> > Marcel Holtmann wrote:
>> > >can you please use drivers/firewire/ if you want to start
I_ANY_ID,
I'm not sure this is a proper class_mask?
Huh, yeah... looks like ~0 should work. And I changed this to use the
PCI_DEVICE_CLASS macro.
+.vendor= PCI_ANY_ID,
+.device= PCI_ANY_ID,
+.subvendor= PCI_ANY_ID,
+ .subdevice= PCI_ANY_
Ben Collins wrote:
...
I would like to see new development efforts take cleanliness WRT host
byte order and 64bit architectures into account from the ground up. (I
understand though why Kristian made the announcement in this early
phase, and I agree with him that this kind of development has to g
Stefan Richter wrote:
...
Another point is the various streaming drivers. There used to be 5 different
userspace streaming APIs in the linux1394: raw1394, video1394, amdtp, dv1394
and rawiso. Recently, amdtp (audio streaming) has been removed, since with
the rawiso interface, this can be done i
Stefan Richter wrote:
...
Another question is whether the stack-internal APIs are really fit for
non-OHCI chips. There is an unfinished low-level driver for GP2Lynx
which worked to some degree at some point, but other than that I don't
remember positive or negative reports in this department. May
Marcel Holtmann wrote:
Hi Erik,
can you please use drivers/firewire/ if you want to start clean or
aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in
the directory path is not really helpful.
Yes, that's probably a better idea. Do you see a problem with using fw_*
as a pr
Ray Lee wrote:
On 12/4/06, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
Ok... I was planning to make big-endian versions of the structs so
that the
endian issue would be solved. But if the bit layout is not consistent, I
guess bitfields are useless for wire formats. I didn'
Alexey Dobriyan wrote:
On Tue, Dec 05, 2006 at 12:22:29AM -0500, Kristian Høgsberg wrote:
I'm announcing an alternative firewire stack that I've been working on
the last few weeks.
Is mainline firewire so hopeless, that you've decided to rewrite it? Could
you show some ug
David Miller wrote:
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 05 Dec 2006 16:42:42 +1100
- It's horribly broken in at least two area :
DO NOT USE BITFIELDS FOR DATA ON THE WIRE !!!
and
Where do you handle endianness ? (no need to shout for
that one).
(Or in general, d
Marcel Holtmann wrote:
Hi Kristian,
I'm announcing an alternative firewire stack that I've been working on
the last few weeks. I'm aiming to implement feature parity with the
...
can you please use drivers/firewire/ if you want to start clean or
aiming at replacing drivers/ieee1394/. Using "
-basic-offset: 8 -*-
+ *
+ * fw-device-cdev.c - Char device for device raw access
+ *
+ * Copyright © 2005 Kristian Høgsberg <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as publis
Oops, looks like the fw-core patch was to big for the list. I've
split it into two parts: fw-core which is the transaction logic and
bus reset handling and fw-device which is device probing and sysfs
integration.
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-k
Benjamin Herrenschmidt wrote:
On Tue, 2006-12-05 at 00:22 -0500, Kristian Høgsberg wrote:
Hi,
I'm announcing an alternative firewire stack that I've been working on
the last few weeks. I'm aiming to implement feature parity with the
current firewire stack, but not necess
Add the OHCI driver to the stack and build system.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c | 1334 ++
drivers/fw/fw-ohci.h | 152 ++
2 files changed, 1486 insertions(+), 0 deletions(-)
diff -
Pull in the fw-sbp2 driver for firewire storage devices.
Signed-off-by: Kristian Høgsberg <[EMAIL PROTECTED]>
---
drivers/fw/fw-ohci.c |2
drivers/fw/fw-sbp2.c | 1083 ++
2 files changed, 1084 insertions(+), 1 deletions(-)
diff -
Hi,
I'm announcing an alternative firewire stack that I've been working on
the last few weeks. I'm aiming to implement feature parity with the
current firewire stack, but not necessarily interface compatibility.
For now, I have the low-level OHCI driver done, the mid-level
transaction logic done,
71 matches
Mail list logo
