Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
Hi, On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote: > > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey > > >> wrote: > > that was part of the reason to punt this problem to userspace ;-) > > > > In practice, the kernel drivers doesn't usually know too much about > > the dimensions/format/etc.. that is really userspace level knowledge. > > There are a few exceptions when the kernel needs to know how to setup > > GTT/etc for tiled buffers, but normally this sort of information is up > > at the next level up (userspace, and drm_framebuffer in case of > > scanout). Userspace media frameworks like GStreamer already have a > > concept of format/caps negotiation. For non-display<->gpu sharing, I > > think this is probably where this sort of constraint negotiation > > should be handled. Egads. GStreamer's caps negotiation is already close to unbounded time; seems like most of the optimisation work that goes into it these days is all about _reducing_ the complexity of caps negotiation! > I agree that user-space will know which devices will access the buffer > and thus can figure out at least a common pixel format. Hm, are you sure about that? The answer is yes for 'userspace' as a broad handwave, but not necessarily for individual processes. Take, for instance, media decode through GStreamer, being displayed by Wayland using a KMS plane/overlay/sprite/cursor/etc. The media player knows that the buffers are coming from the decode engine, and Wayland knows that the buffers are going to a KMS plane, but neither of them knows the full combination of the two. Though this kinda feeds into an idea I've been kicking around for a while, which is an 'optimal hint' mechanism in the Wayland protocol. So for our hypothetical dmabuf-using protocol, we'd start off with buffers which satisfied all the constraints of our media decode engine, but perhaps just the GPU rather than display controller. At this point, we'd note that we could place the video in a plane if only the buffers were better-allocated, and send an event to the client letting it know how to tweak its buffer allocation for more optimal display. But ... > Though I'm not > so sure userspace can figure out more low-level details like alignment > and placement in physical memory, etc. > > Anyway, assuming user-space can figure out how a buffer should be > stored in memory, how does it indicate this to a kernel driver and > actually allocate it? Which ioctl on which device does user-space > call, with what parameters? Are you suggesting using something like > ION which exposes the low-level details of how buffers are laid out in > physical memory to userspace? If not, what? ... this is still rather unresolved. ;) Cheers, Daniel > > Cheers, > > Tom > > > > > > > ___ > Linaro-mm-sig mailing list > linaro-mm-...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: comments on CML 1.1.0
On Sat, Apr 14, 2001 at 11:58:41AM -0400, jeff millar wrote: > Selecting IP_NF_COMPAT_IPCHAINS turns off IP_NF_CONNTRACK and friends. But, > I think CML1, allowed both support to the new iptables and compatibility > modes to allow old ipchains scripts to work with the new kernel. Only as modules: conntrack/queueing/iptables, ipchains compat, and ipfwadm compat, are all mutually exclusive. The only way that this was at all possible in 2.4.x was via modules, but even then, they were still mutually exclusive. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 07:44:17PM +0700, [EMAIL PROTECTED] wrote: > > On Tue, 24 Apr 2001, Alexander Viro wrote: > > What, makes it hard to write viruses for it? Awww, poor skr1pt k1dd13z... > > > > And would that "use" by any chance include access to network? > > > > So let him log in as root, do everything as root and be cracked > > like a bloody moron he is. Next? > > > > come on, it's hard for me as it's hard for you. not everybody > expect a computer to be like people here thinks how a computer > should be. Hence, Microsoft Windows. It might not be stable, it might not be fast, it might not do RAID, packet-filtering and SQL, but it does a job. A simple job. To give Mum & Dad(tm) (with apologies to maddog) a chance to use a computer. > think about personal devices. something like the nokia communicator. > a system security passwd is acceptable, but that's it. no those- > device-user would like to know about user account, file ownership, > etc. they just want to use it. Since when, did mobile phones == computers? > that also explain why win95 user doesn't want to use NT. not > because they can't afford it (belive me, here NT costs only > us$2), but additional headache isn't acceptable. So, let them stay in Win95. They don't *need* NT. > with multi-user concept, conceptually there should be an > administrator to create account, grant permission, etc. > no my sister doesn't want that. i bet there are billions of > people not willing to learn how to use a computer, they just > want to use it. If your sister doesn't want that, give your sister a copy of Win95. If she doesn't want that, she obviously wouldn't get any advantage out of Linux, as opposed to Win95, whatsoever. Would she get a kick out of having to learn an entirely new environment? Granted, I'm far more productive in GNOME, Sawfish, emacs and mutt than Win95, Word and Outlook, but it takes people time to get used to, and you'll have trouble dragging them out of point-n-click. > and yes, mobile devices access network. > > > What for? If they want root - give them root and be done with that. > > No need to change the kernel. > > > > You know, if you really do not understand the implications of > > running everything with permissions equivalent to root - get > > the hell out of any UNIX-related programming until you learn. > > > > If you want CP/M or MacOS - you know where to find them. > > so what the hell is transmeta doing with mobile linux (midori). > is it going to teach multi-user thing to tablet owners? > surely mortals expect midori to behave like their pc. lets say > on redhat, they have to login as root to access their files, > they don't even know what a root is! > > lets break unix mind for a while, and give everyone a chance > to use linux. If you don't want multiple users, don't add them. Just be content with root, and give her root. It has multiple user capabilities, which should be used under all circumstances, but if you don't want something, don't use it. You have a choice. My $au0.02. (which is apparently just over us1c now. oh joy). -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 08:27:56PM +0700, [EMAIL PROTECTED] wrote: > On Tue, 24 Apr 2001, Daniel Stone wrote: > > Hence, Microsoft Windows. It might not be stable, it might not be fast, it > > might not do RAID, packet-filtering and SQL, but it does a job. A simple > > job. To give Mum & Dad(tm) (with apologies to maddog) a chance to use a > > computer. > > > > > > Since when, did mobile phones == computers? > > read the news! i'm programming nokia 9210 with c++, is that > computer enough? Aah. I see. Where was this? I never saw it. > i bet if you programmed one, you'd wish you have posix > interface. That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be absolutely *rock solid*. Look at the 5110, that's just about perfect. The 7110, on the other hand ... > > > that also explain why win95 user doesn't want to use NT. not > > > because they can't afford it (belive me, here NT costs only > > > us$2), but additional headache isn't acceptable. > > > > So, let them stay in Win95. They don't *need* NT. > > and how's stability, speed, etc. they read. is there a linux > advocate around here? There are Linux advocates, but I'd say most of us are sane enough to use the right-tool-for-the-job approach. And UNIX on a phone is pure overkill. > > If your sister doesn't want that, give your sister a copy of Win95. If she > > doesn't want that, she obviously wouldn't get any advantage out of Linux, as > > opposed to Win95, whatsoever. Would she get a kick out of having to learn an > > entirely new environment? Granted, I'm far more productive in GNOME, > > Sawfish, emacs and mutt than Win95, Word and Outlook, but it takes people > > time to get used to, and you'll have trouble dragging them out of > > point-n-click. > > okay, it wouldn't cost me. but it surely easier if everybody used > linux, so i could put my ext2 disk everywhere i want. > > hey, it's obvious that it's not for a server! > i try to point out a problem for people not on this list, don't > work around that problem. Your sister won't notice much advantage. Linux on a workstation actually has *disadvantages* (unfamiliar interface, unintuitive same, etc), as opposed to 'Doze on a workstation. Sure it's more stable, and the tiniest bit faster, but what's that really matter to your sister, if she can't even figure out how to use it? -d, who owns a 7110 and can lock it solid, or get it to do funny resetting tricks, at least once every 2 days -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problem found (was Re: [PATCH] Single user linux)
On Tue, Apr 24, 2001 at 09:04:02PM +0700, [EMAIL PROTECTED] wrote: > > What's with all these blank lines? Everywhere! > On Tue, 24 Apr 2001, Daniel Stone wrote: > > Aah. I see. Where was this? I never saw it. > > psst, it's a proto. Right-o. In the news, you say. Hrm. > > That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be > > absolutely *rock solid*. Look at the 5110, that's just about perfect. The > > 7110, on the other hand ... > > mobile phone to you! already, people has put linux on pdas. True, but I don't see what's so l33t about having bash on an Agenda, except for, say, the novelty value of opening it up and writing "date" to get the date in UNIX format, when someone asks you the time. > > There are Linux advocates, but I'd say most of us are sane enough to use the > > right-tool-for-the-job approach. And UNIX on a phone is pure overkill. > > problem is you guys are to unix-centric, try to be user-centric a little. We're too UNIX-centric, yet you're the one trying to put UNIX on a phone? Come on ... Al Viro made some excellent points there. If you want to run single-user, hack /sbin/login. Hack /sbin/init. But it's not the kernel's job, what you do. > it's not like it ruins everything. that patch basically do something > like allowing access to port <1024 to everybody, someone just need > to bring a notebook to get passwd from nis. > multi-user security is useless at home as physical access is there. Well, not really, because what if I run single-user, but I also need to get in from home? So, everyone who connects, gets in? What if I run BIND, and forget to update before an exploit? Whoops, there goes my entire system, exploited like that. Single-user is absolutely stupid, IMNSHO. Unless, of course, if you're using something that will *never* be connected, like a watch. In a rabbithole. A rabbithole which is B2 secure. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and ipmasq modules
FTP is under Connection Tracking support, FTP connection tracking. Does the same stuff as ip_masq_ftp. IRC is located in patch-o-matic - download iptables 1.2 and do a make patch-o-matic, there is also RPC and eggdrop support in there. I'm half in the middle of porting ip_masq_icq, but it's one hideously ugly kludge after another. Such is life. d On 20 Jan 2001 14:46:16 -0800, Aaron Lehmann wrote: > It was great to see that 2.4.0 reintroduced ipfwadm support! I had no > need for ipchains and ended up using the wrapper around it that > emulated ipfwadm. However, 2.[02].x used to have "special IP > masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I > can't find these in 2.4.0. Where have they gone? Without important > modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind > the masquerading firewall. > > Thanks, > Aaron Lehmann > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and ipmasq modules
On 20 Jan 2001 15:34:03 -0800, Aaron Lehmann wrote: > On Sun, Jan 21, 2001 at 10:32:15AM +1100, Daniel Stone wrote: > > FTP is under Connection Tracking support, FTP connection tracking. Does > > the same stuff as ip_masq_ftp. IRC is located in patch-o-matic - > > download iptables 1.2 and do a make patch-o-matic, there is also RPC and > > eggdrop support in there. I'm half in the middle of porting ip_masq_icq, > > but it's one hideously ugly kludge after another. Such is life. > > That option seems to conflict with "ipfwadm (2.0-style) support". > Preferably, I'd like to stay with friendly old ipfwadm rather than > switching firewalling tools _again_. Your choice, but if you choose not to switch, you lose the power of: * stateful inspection * modules * a sane command line * a metric shitload of extensions "I'd rather stay with my friendly old pushbike than my car!" So don't complain when you can't use cruise control. d -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Firewall netlink question...
On 22 Jan 2001 10:26:00 +, Scaramanga wrote: > Looking at the code it seemed to do the same thing as the old netlink, but > with more complexity, to what end though, i couldnt tell, was only a brief > skim. So you can do whatever you want with it. > > $ sed -n -e '1874,1876p' /usr/src/linux-2.4.0/Documentation/Configure.help > > CONFIG_IP_NF_QUEUE > > Netfilter has the ability to queue packets to user space: the > > netlink device can be used to access them using this driver. > > > > $ lynx /usr/share/doc/iptables/html/packet-filtering-HOWTO-7.html > > > > Yeah, after some quick googling and freshmeating, i came accross a daemon > that picked up these QUEUEd packets and multiplexed them to various child > processes, which seemed very innefcient, the documentation said something > about QUEUE not being multicast in nature, like the old firewall netlink. This is true. This is called ipqmpd or something similar and written by Harald Welte, yes? Your best option is to either check out libipq (can be found in the directory of the same name in the iptables sources), which provides clean C interfaces, or the PERL interface, available from http://www.intercode.com.au/jamesm/ > What was wrong with the firewall netlink? My re-implementation works great > here. I can't see why anything else would be needed, QUEUE seems twice as > complex. Unless with QUEUE the userspce applications can make decisions on > what to do with the packet? In which case, it would be far too inefficient > for an application like mine, where all i need is to be able to read the > IP datagrams.. It can modify and then reinject the packet if it so wishes. > Am I missing something totally obvious? It just does more stuff. A plane is far more complex than a car, but with an added feature - it also flies above the ground. > Regards -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and ipmasq modules
On 22 Jan 2001 18:01:58 -0800, Aaron Lehmann wrote: > On Tue, Jan 23, 2001 at 12:48:20PM +1100, Rusty Russell wrote: > > Those who berated Aaron for not wanting to upgrade: he is the Debian > > maintainer for crashme, gtk-theme-switch, koules, pngcrush, and > > xdaliclock. By wasting his time making him convert a perfectly > > working system, you are taking away time from those projects. I'd > > rather see him spend time on Cool Stuff(TM) which benefits all of us. I don't use any of that :P > Thank you for your support, but it seems clear that they were right. > I changed the kernel settings to have pure netfilter configuration, > read the NAT-HOWTO, and followed its instructions. I reccomend that any > others still trying to use the 2.[02].x style interfaces do the same. Hallelujiah, brother! > netfilter seems not only much cleaner than ipchains or ipfwadm, but also > much more powerful. I read into the HOWTO a bit and was very impressed > by the capabilities. In particular, it's nice to have port forwarding > integrated with NAT rather than as a seperate chunk of kernel code using > different userspace tools. Among other things. It originally started out having NAT and filtering controlled by two different userspace tools - iptables and ipnatctl, but they were eventually merged. > I hope that netfilter will last longer than the last two packet > filtering/mangling/masquerading mechanisms. :) Looking at something ages ago that I now cannot find, Rusty apparently realised that ipchains was wrong when he was writing it; no such admission (at least, that I know about) yet. > P.S.: The only thing I did not get working successfully was IRC DCC. I > sent a bug report to the maintainer of the patch from the > patch-o-matic, but did not recieve an immediate response, so I'll > include it below in case anyone else has any ideas. > ___ > > >From [EMAIL PROTECTED] Sun Jan 21 00:44:17 2001 > Date: Sun, 21 Jan 2001 00:44:17 -0800 > From: Aaron Lehmann <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: irc-conntrack-nat doesn't work for me > > I applied irc-conntrack-nat from iptables-1.2's patch-o-matic onto a > Linux 2.4.0 kernel with XFS support. I tried several different IRC > clients on the sending end (which was of course behind this NAT box) > and different IRC servers (all on port 6667). On the recieving end, I > would always get: > > -:- DCC GET request from aaronl_[[EMAIL PROTECTED] > [64.81.36.147:33989]] 150 bytes /* That's the NAT box's IP */ > -:- DCC Unable to create connection: Connection refused > > Any idea what's wrong? I have irc-conntrack-nat compiled into the > kernel. Well, it's NAT'ing it OK. Are you sure you have a rule like the following: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ? d PS: If you're trying to NAT a DCC RESUME, don't even bother. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Firewall netlink question...
On 22 Jan 2001 11:58:26 +, Scaramanga wrote: > Hi, > >> What was wrong with the firewall netlink? My re-implementation works great > >> here. I can't see why anything else would be needed, QUEUE seems twice as > >> complex. Unless with QUEUE the userspce applications can make decisions on > >> what to do with the packet? In which case, it would be far too inefficient > >> for an application like mine, where all i need is to be able to read the > >> IP datagrams.. > > > > It can modify and then reinject the packet if it so wishes. > > Excellent, I didn't pick up on that, with the cursory glance at the code i took. > > I wonder, would there be any interest/point in my NETLINK module, which > provides a backward compatible netlink interface. There are a good few > apps out there which rely on it, and its nice not to have to run a daemon > and install a new library, and re-write them just to continue using them... This is a great idea. Seeing as we have the compatability for ipchains and ipfwadm, this can't be an altogether thing. Plus, userspace hacks to detect kernel versions are always bad. > egg.microsoft.com: Remote operating system guess: Solaris 2.6 - 2.7 My all-time favourite is Microsoft-IIS/4.0 (Unix) mod_ssl/2. OpenSSL/0.9.4 -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Rik's bad process killer - how to kill _IT_?
Hi, I've been having a bit of a problem with Rik's new VM, in particular the bad process-killer. Basically put, I have a reasonably underpowered system (P166) running Helix GNOME & Sawfish, and half the time when I load my Eterm (admittedly, transparent, but it looks cool, damnit!), or Netscape (or both!) it seems to be Rik's VM killer slaying them. No error message is logged anywhere, not even if I start 'em from the console. Is there a /proc hack or something? Thanks a lot! :) d -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Rik's bad process killer - how to kill _IT_?
> > Daniel Stone > > Linux Kernel Developer > ^^ > > If you were, you'd have written something that makes sense. Touche. I didn't claim to be a Linus, but I have got a few things in the kernel (sb16 driver, netfilter). Plus you can't ask much when I've gone 5 days without sleep just studying. Better than being kicked out of #Linux (Undernet) for trolling, though. > 1. my OOM killer *always* spits out a message when it kills >something 3 other people have pointed this out to me. > 2. you haven't written what kernel version you're using; >judging from your lack of error messages you're running >2.2 (which has the nasty habit of killing processes under > heavy load ... I have a patch out which fixes that) 2.4.0-test11. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Press release - here we go again!
lready available to advanced users through multiple kernel mirrors (for more mirror information, please see http://www.kernel.org). Although no timeframes have been announced at this time, all current Linux distributors will be updating to this version of the kernel within the next several months. Linux is developed by a online team of programmers headed by Linus Torvalds, a resident of Santa Clara, CA. Linux has been developed using the open source methodology which provides for source code and peer review at all stages of development. It is because of this system of openness that Linux has grown to be the most successful non-corporate operating system to date. For more information, please consult www.linux.org for a list of other Linux-related websites. More information on the new features in Linux 2.4 can be found in the "Wonderful World of Linux 2.4" document, available from ***FIXME: W(here)TF is it?* Linux is a trademark of Linus Torvalds. -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Press release - here we go again!
> Hi Daniel, anyone. Hullo(tm). > I am not a lawyer and I am not a marketing manager, but I think there > are several things that need fixing. Most of these are differences that > I think stand out when comparing your draft with the KDE press releases > for their KDE2.0 betas (those being the only press releases I've read > for an open source project yet), available at www.kde.org. I am not a lawyer, marketing manager, marketer, salesperson, pre-sales person, or indeed even a "real" kernel hacker. I'm a bloody high school student. Hence the lack of the "journalistic touch". I'm just hacking away, hoping someone will notice, tell me everything to fix, I fix it, and in the end I get credit, and people hail me down the streets with a ticker-tape para > 1.) First of all, there should be some people named at the end of the > p.r. that interested press people can contact to get an interview or > such. Naturally, this should be some of the core developers. Read about the second paragraph of the initial email I sent out. A feature writer for a well-known computer magazine here tried to contact one of the higher deities and they more or less told him to bugger off. Do we want to do this to ALL the press? (besides, I don't have Linus' phone number on hand). > 2.) I'm still not sure whether you can use so many trademarks within the > p.r. without marking them as such and using them incorrectly (e.g. 'Sun > Microsystems' instead of 'Sun', 'Microsoft WindowsCE' (a guess) instead > of 'Windows-CE', etc.) That was actually one of the things I red-flagged myself for and pondered about. Then I decided I'd get flamed for it on l-k and just hoped to god that someone would come up with something constructive. > 3.) The language is a bit (and here my own deficit strikes me as I'm > searching for the right word, let's try) 'unprofessional'. With that I > mean that it is not the 'typical' language of press releases. I quote: > > > * Enterprise Ready! Linux 2.4 includes changes that > > make it even more ready for Enterprise environments. > > > * Linux also includes Logical Volume Manager, for easy > > administration of disk space; you can also combine > > several hard drives/partitions into one for even more > > space and ease! > > > * More interface support! Linux is now even better > > supported for the desktop with the advent of support > > for USB, FireWire and AGP. > > > Linux includes a new architecture, known as Netfilter, > > to act as a firewall (security - choose what gets > > through and what doesn't), and masquerading server > > (multiple machines can share the one connection without > > any fuss or hassle). Netfilter is now much quicker, > Yeah, well scroll up. I will go and read the KDE press release, but don't mistake me for a professional journalist, or someone who sits there all day slamming out quality press releases. > One should take time and discuss what _groundbreaking_ new features > Linux 2.4 will have when compared to both 2.2 and the competitors. I'm > thinking of the scalability issues, as well as all the other > 'enterprise' enhancements like maximum memory/processors supported. On > the other end of the user scale you might want to proudly present Linux > as the first system to support ATA100. Full USB support comes to mind. Well, does Linus, Alan, etc, want to share their viewpoint? ATA100 is a very good one, yes, and I actually did put in USB if you bothered to read the press release, indeed what you pasted also. And the first thing I wrote was about how it's so much better for SMP and 64gig of ram, and >2gig files ... > One should single out what Linux 2.4 can do better than the competitors, > but in a respectful (w.r.t. competitors) and indirect way. And one > should take the time and space to go into some application examples to > elaborate on these outstanding features. Application != kernel. > Well, look at the KDE people. I think they really got 'it' when it comes > to writing press releases: Identify your strengths and explain them > briefly, but so that my _mum_ says "Wow, Linux 2.4 is great! Where do I > get one of those cute stuffed penguins?" after reading her woman's > journal. (Ok, ok...:-) okokok, I will. But please, for the love of God, stop mistaking me for a full time quality-bullshit^Wpress-release-artist. Because I'm not. I just hacked out a press release one night when I was pretty tired. Don't flame me for it. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Press release - here we go again!
> >-> Multimedia > > * Faster multimedia with specially designed video acceleration driver s. In combination with the new release of the X Windows System, Linux includes drivers to take full advantage of your accelerated video card (nVidia and 3Dfx cards among those supported) to get maximum video performance for gaming, graph ics, etc. > > Actually it seems that hardware acceleration for nVidia cards has > momentarily > died with the loss of MAP_NR in page[cache].h. NVidia only claims to > support 2.2.x kernels. If updated drivers do exist, I would definitely > love to hear about them. Tim, This may or may not be true. I have no idea as I'm too pov to own a real video card. *fwaps self* More research needed. Treat this as 0.0.0.1-test1-pre1-beta1-alpha1-preview1-unstable-compile1. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PressRel] v0.1.1 - the "errata" release
All, Fixed up a few suggested "buglets" in the release, notably inconsistencies in the grammar, etc. I won't bother you with big posts, so it's at http://dustpuppy.ods.org/press-release - just grab it from there. Still to do is to rewrite half the stuff, and to merge the longer details into WWoL2.4 or similar, so the press release is designed for brevity. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PresRel] Oops ... try now.
*fwaps self* Excuse the 403 on the URL I gave - try now. http://dustpuppy.ods.org/press-release :) d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OMG] test8-pre6 horribly, awfully screwed!
OK.
When I boot up, I have a netfilter init script. It loads many netfilter
modules, among them, ipt_LOG, ipt_state, and ipt_limit. When they load,
whammo, instant OOPS.
ip_conntrack_irc is also among them.
want to lsmod? oops.
want to cat /proc/modules? oops.
want to rmmod? oops.
etc
test7-pre4 also seemed to have this obscene breakage, and test8-pre[123456]
seems to have it as well. Although, seeing as no-one else has reported it,
it certainly seems to be me. I've attached OOPS reports from attempting to
load ip_conntrack_irc, lsmod'ing and cat'ing /proc/modules - in that order.
The ones for ipt_{LOG,state,limit} are a leeetle harder to get ... I'll post
them later, as I get them.
I'm running:
woody (Debian)
test8-pre6 (own)
modutils 2.3.15 (own)
ksymoops 2.3.4 (own)
gcc 2.95.2 (Debian)
binutils 2.10.0.24-1 (Debian)
Only too happy to provide any other pertinent information, if it can make
this bloody stuff die quietly yet agonisingly painfully.
:) d
(yes, I did specify no ksyms as ksymoops oopsed, as did cat /proc/ksyms. go
figure).
--
Daniel Stone
Kernel Hacker (or at least has aspirations to be)
[EMAIL PROTECTED]
http://dustpuppy.ods.org
ksymoops 2.3.4 on i586 2.4.0-test8. Options used
-V (default)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test8/ (default)
-m /usr/src/linux/System.map (default)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 1b12
c0211bd5
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010297
eax: 1b12 ebx: c19ef009 ecx: 1b12 edx: fffe
esi: edi: c1a1df30 ebp: esp: c1a1deec
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 151, stackpage=c1a1d000)
Stack: c28cfc54 c28cf000 0009 c1a1df84 000a c0211d8c
c19ef000 c021d379 c1a1df24 c0116f83 c19ef000 c021d372 0008 1b11
1b12 c28cf6d0 0c00 0c00 c19ef000 1000 c0141cce
Call Trace: [] [] [] [] []
[] []
[] [] [] []
Code: 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 8b 54 24 14 89 c6
>>EIP; c0211bd5<=
Trace; c28cfc54
Trace; c28cf000
Trace; c0211d8c
Trace; c021d379
Trace; c0116f83
Trace; c021d372
Trace; c28cf6d0
Trace; c0141cce
Trace; c013ffb8
Trace; c0128dd6
Trace; c0108d83
Code; c0211bd5
<_EIP>:
Code; c0211bd5<=
0: 80 38 00 cmpb $0x0,(%eax) <=
Code; c0211bd8
3: 74 07 je c <_EIP+0xc> c0211be1
Code; c0211bda
5: 40inc%eax
Code; c0211bdb
6: 4adec%edx
Code; c0211bdc
7: 83 fa ff cmp$0x,%edx
Code; c0211bdf
a: 75 f4 jne0 <_EIP>
Code; c0211be1
c: 29 c8 sub%ecx,%eax
Code; c0211be3
e: 8b 54 24 14 mov0x14(%esp,1),%edx
Code; c0211be7
12: 89 c6 mov%eax,%esi
*
ksymoops 2.3.4 on i586 2.4.0-test8. Options used
-V (default)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test8/ (default)
-m /usr/src/linux/System.map (default)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 1b17
c0116e9b
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010213
eax: 1b0f ebx: c0726076 ecx: edx: c28cfc48
esi: c28c6000 edi: c0726074 ebp: 0f8a esp: c0749ef0
ds: 0018 es: 0018 ss: 0018
Process cat (pid: 444, stackpage=c0749000)
Stack: 0c00 c0726000 1000 c0749f0c 0804c324 c28c6000 33322020
34303200 c0cc2800 0804c324 0001 c0748000 0804b318 0804c000 ba3c
c0e4e83c 0286 c026bce0 c026bf78 0726 c0141c81
Call Trace: [] [] [] [] []
Code: 8b 70 08 89 f7 31 c0 f2 ae f7 d1 49 89 4c 24 14 39 cd 72 65
>>EIP; c0116e9b<=
Trace; c28c6000
Trace; c0141c81
Trace; c013ffb8
Trace; c0128dd6
Trace; c0108d83
Code; c0116e9b
<_EIP>:
Code; c0116e9b<=
0: 8b 70 08 mov0x8(%eax),%esi <=
Code; c0116e9e
3: 89 f7 mov%esi,%edi
Code; c0116ea0
5: 31 c0 xor%eax,%eax
Code; c0116ea2
7: f2 ae repnz scas %es:(%edi),%al
Code; c0116ea4
9: f7 d1 not%ecx
Code; c0116ea6
b: 49dec%ecx
Code; c0116ea7
c: 89 4c 24 14 mov%ecx,0x14(%esp,1)
Code; c0116eab
10: 39 cd cmp%ecx,%ebp
Co
[BUG] That bloody /usr/local busy back again
I haven't had time to test it thoroughly, but I've noticed from about test8-preX onwards (latest tested test8) that on shutdown, my /usr/local (/dev/ide/host0/bus0/target0/lun0/part6, ReiserFS), is always "busy" - the last thing I see in shutdown -r now is: "Unmounting filesystems... /dev/ide/host0/bus0/target0/lun0/part6 busy, mounting read-only Rebooting system..." (may not be absolute verbatim, but pretty close). I'm using the latest update of Debian 2.3 (Woody). I remember this problem sprung up a while ago. *shrug* :) d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] test9-pre6: semi-deadlocks
In test9-pre6, when going to compile something - just hit make, gcc kicked in - and grepping, my system came to a semi-deadlock both times. By this I mean that you can switch between vconsoles pretty snappily (this system has no X), but you cannot type at all on those consoles (I think 5 minutes was a pretty adequate timeout). This sucks pretty hard. I tryed SysRq-S(ync), -U(nmount), which printed SysRq: Emergency Sync and SysRq: Emergency Remount R/O respectively, but I didn't get the confirmation messages telling me that it actually worked, even after waiting about a minute. Mercifully, the SysRq reboot works. A belated bug report: My system sits idling, logged out at home, and in test9-pre4, I'd get home to the exact same situation; could've been that 2-hour-idle bug. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with 2.4.0-test9-pre6 seems to be SHM
> safemode wrote: > > > Mark Hahn wrote: > > > >> this has nothing to do with the linux kernel. > >> X itself does not use shm for anything. apps may use > >> an X extension (XSHM) which uses shm segments to exchange > >> image data without copying through a socket, but that's > >> an extension, not inherent to X. > >> > >> > Ok, compiling using a cvs of X i got a couple hours ago, I'm just > >> > >> > wondering what the average segment number is for SHM on an X > >> session > >> > that has been up for a while i'll get back with any sort of > >> info > >> > on if the SHM problem has been solved with this latest CVS or if > >> it > >> > continues to look like a kernel SHM problem. So far though, > >> > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to > >> test9, > >> > which died in 2 hours upon booting ...and it didn't have the added > >> > >> > stress of compiling X. > >> > > >> > - > >> > > > > > > I think it has a lot to do with the kernel, and with X. Since i > > havn't upgraded anything but X (and thus the extensions) ... now it's > > obvious that X is at fault for providing us with a wonderful shared > > memory leak. But, the kernel too, has something to do with it since > > test9 seems to be fairly unstable with it, causing all sorts of weird > > happenings before totally freezing up like test8-vm3 does. This > > problems only manifests in VERY recent X cvs copies so most people > > will not see this problem. The problem i'm wondering about is if the > > Kernel is handling shared memory correctly or if this is entirely X's > > fault. > > > > Somehow i cant help but think this is somehow linked to an OOM problem > that has yet to be fixed with the 2.4.0-testX series. It seems > suspiciously like the kernel is killing init when X decides it would be > peachy to gobble up all the ram. i dont know of any way to prove > this though. The problem is most definitely NOT X as I experienced the exact same problems and reported it to l-k yesterday; and my box has no trace of X on it. gcc and grep take it down though. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre6 shmem problems revisited
> On Sun, 24 Sep 2000, Daniel Stone wrote: > > The problem is most definitely NOT X as I experienced the exact same > > problems and reported it to l-k yesterday; and my box has no trace of X on > > it. gcc and grep take it down though. > > I have been running 2.4.0-test9-pre2 for some time now and have not experienc ed > any deadlock or shared memory problem, except for one instance. Byron - test9-pre2 was fine for me (bar that deadlock after 2 hours idle thing), it's test9-pre6 that seems to really badly blow goats. d -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random: really secure?
> This would allow you to say "eth0 is my internal network and I'm not > trying to hack my own system, so use IP traffic on that interface to add > entropy to the pool, but not packets that are on port 6699/21/23 or reply > packets". It would probably just be a matter of adding a new flag to a > filter rule to say "use packets that match this rule for entropy", and > then it is up to the user to determine what is safe to use. The fact > that it is user configurable makes it even harder for a cracker to know > what affects the entropy pool. This isn't from the kernel, but works great in userspace: iptables -n RANDOM iptables -A INPUT -i eth0 -j RANDOM iptables -A RANDOM -p tcp --dport 6699 -j iptables -A RANDOM -p tcp --dport 21 -j iptables -A RANDOM -p tcp --dport 32 -j iptables -A RANDOM -m state --state ! NEW -j iptables -P RANDOM -j ULOG --ulog-nlgroup 32 This sends a message down netlink in ULOG format. ULOG is a userspace logging extension written by Harald Welte, but it's extensible like you wouldn't believe, so you could easily do some whacky stuff with it. Or just hook in to a Netfilter hook and do it all from kernel land. ULOG's homepage: http://www.gnumonks.org/gnumonks/projects/project_details?p_id=1 :) d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lockups from heavy IDE/CD-ROM usage
> I get this on the 440LX with the same DMA timeout message. Everyone says it's > the board's fault as well. Funny. Anyways this happens accross just about > any Dev kernel but more so in the -test12 and up versions. . Test10 works > fine without locking. Blaming the hardware reminds me of the help given by > some other company I can't seem to remember the name to. Well, think about it - if there are DMA/IRQ timeouts, the hardware IS rooted. Otherwise, why would it be timing out? I've been seeing these messages shortly before a hardlock (except for the fact numlock still works, but nothing else) when doing long, intensive hard drive activity. Because my hard drives are right next to each other, overheat sometimes and shut straight down when they do. But I'm gonna take a wild guess it's not Linux's fault, unless they've done some whacky stuff with the elevator ;) -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-pre4-ac2 - part of diff fails
I get this when patch'ing in test13-pre4-ac2 (with ReiserFS and Netfilter patches, none of which touch SMP). patching file arch/i386/kernel/smp.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 278. Hunk #2 succeeded at 511 (offset 9 lines). 1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/smp.c.rej Works fine if I reverse it and then put it back in. ? d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre4-ac2 - part of diff fails
> > patching file arch/i386/kernel/smp.c > > Reversed (or previously applied) patch detected! Assume -R? [n] > > Apply anyway? [n] y > > Hunk #1 FAILED at 278. > > Hunk #2 succeeded at 511 (offset 9 lines). > > 1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/smp.c.rej > > > > Works fine if I reverse it and then put it back in. ? > > Its a bug in my patch - get 13pre4ac2 .. Um. Subject: Re: test13-pre4-ac2 - part of diff fails It's _IN_ 13-4ac2. d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre4-ac2 - part of diff fails
> > On 23-Dec-2000 Daniel Stone wrote: > >> > patching file arch/i386/kernel/smp.c > >> > Reversed (or previously applied) patch detected! Assume -R? [n] > >> > Apply anyway? [n] y > >> > Hunk #1 FAILED at 278. > >> > Hunk #2 succeeded at 511 (offset 9 lines). > >> > 1 out of 2 hunks FAILED -- saving rejects to file > >> > arch/i386/kernel/smp.c.rej > >> > > >> > Works fine if I reverse it and then put it back in. ? > >> > >> Its a bug in my patch - get 13pre4ac2 .. > > > > Um. > > Subject: Re: test13-pre4-ac2 - part of diff fails > > It's _IN_ 13-4ac2. > > I applied test13-pre4-ac2 here, and it applied cleanly. > Are you applying it to a clean tree? Are your using > patch v2.5.4 ? (that's the version I have) linux-2.4.0-test12 + reiserfs + test13-pre4 + reiserfs makefile fix (only changes fs/reiserfs/Makefile) + netfilter patch-o-matic stuff (only touches net/ipv4/netfilter) + test13-pre4-ac2. also seen on just linux-2.4.0-test12 + test13-pre4 + test13-pre4-ac2. > FWIW, I was getting smp.c patch failures (well, it said the > patch was previously applied) along with a bunch of > IPTables stuff -- that was a couple of -ac's ago. same here, just forgot to report it. > AC1 and AC2 applied cleanly, tho AC1 wouldnt compile > uniprocessor/no-quotas unless you added a > #include to fs/ext2/balloc.c > (i.e. it left some hanging refs to lock_kernel and > unlock_kernel in fs.o, and I think there was also > one in the UDF module.It's fixed in -ac2. ac1 came out while I was asleep, and I woke up to ac2 being released. d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] test13-pre6 net/atm/lec.c
Thanks, but if you ever send HTML email (MIME'd, no less), I'll dismember you. > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > __JNP_000_5510.0696.1d1b > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hello, > The following patch appears to fix 2 of the 3 undefined references: > publish_netdev is still unresolved. > Regards, > Frank > --- net/atm/lec.c.old Sat Dec 30 03:08:14 2000 > +++ net/atm/lec.c Sat Dec 30 03:17:44 2000 > @@ -772,10 +772,10 @@ > size = sizeof(struct lec_priv); > #ifdef CONFIG_TR > if (is_trdev) > -dev_lec[i] = prepare_trdev(NULL, size); > +dev_lec[i] = init_trdev(NULL, size); > else > #endif > -dev_lec[i] = prepare_etherdev(NULL, size); > +dev_lec[i] = init_etherdev(NULL, size); > if (!dev_lec[i]) > return -ENOMEM; > > __JNP_000_5510.0696.1d1b > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: quoted-printable > > > > Type> > > > Hello, > The following patch appears to fix 2 of the 3 undefined = > references:=20 > publish_netdev is still unresolved. > > style=3D"mso-fareast-font-family: 'MS Mincho'">Regards, > style=3D"mso-fareast-font-family: 'MS Mincho'">Frank > ">---=20 > net/atm/lec.c.old Sat Dec 30 03:08:= > 14=20 > 2000+++ net/atm/lec.c = > ; =20 > Sat Dec 30 03:17:44 2000@@ -772,10 +772,10 @@ style=3D"mso-spacerun: yes">= > ;=20 > size =3D sizeof(struct lec_priv); style=3D"mso-spacerun: yes"> #ifdef CONFIG_TR style=3D"mso-spacerun: yes">= > ;=20 > if (is_trdev)- style=3D"mso-spacerun: yes">= > ;&= > nbsp; =20 > dev_lec[i] =3D prepare_trdev(NULL, size);+ style=3D"mso-spacerun: yes">= > ;&= > nbsp; =20 > dev_lec[i] =3D init_trdev(NULL, size); style=3D"mso-spacerun: yes">= > ;=20 > else #endif-<= > SPAN=20 > style=3D"mso-spacerun: yes">= > ; =20 > dev_lec[i] =3D prepare_etherdev(NULL, size);+ style=3D"mso-spacerun: yes">= > ; =20 > dev_lec[i] =3D init_etherdev(NULL, size); style=3D"mso-spacerun: yes">= > ;=20 > if (!dev_lec[i]) style=3D"mso-spacerun: yes">= > ;&= > nbsp; =20 > return -ENOMEM; style=3D"mso-spacerun: yes"> > > __JNP_000_5510.0696.1d1b-- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compile errors: RCPCI, LANE, and others
> Did full compile, just for fun: > > CONFIG_for Red Creek whatever RCPCI has a syntax error > other warnings and errors, compiled on 2.4.0-prerelease, nonSMP, PIII > > md5sum: WARNING: 11 of 12 computed checksums did NOT match This indicates a corrupted download. > net/network.o: In function `atm_ioctl': > net/network.o(.text+0x3c742): undefined reference to `atm_lane_init' > net/network.o(.text+0x3c7f2): undefined reference to `atm_mpoa_init' > make: *** [vmlinux] Error 1 Known problem, AFAIK. > objcopy: Warning: Output file cannot represent architecture UNKNOWN! um. this is completely rooted. what compiler are you using, what distribution? (hint: if it's redhat 7, don't bother). > ip2/i2cmd.c:142: warning: `ct89' defined but not used > sx.c:1623: warning: `do_memtest_w' defined but not used > i2o_block.c:595: warning: #warning "RACE" this is most likely a bad thing, yes. > md5sum: WARNING: 11 of 12 computed checksums did NOT match see first warning > bttv-cards.c: In function `bttv_check_chipset': > bttv-cards.c:1389: warning: unused variable `i' > bttv-cards.c: At top level: > bttv-cards.c:1379: warning: `needs_etbf' defined but not used > mtdchar.c: In function `init_mtdchar': > mtdchar.c:452: warning: unused variable `mtd' > mtdchar.c:451: warning: unused variable `name' > mtdchar.c:450: warning: unused variable `i' > ftl.c:139: warning: `debug' defined but not used > nftlmount.c: In function `check_and_mark_free_block': > nftlmount.c:363: warning: unused variable `buf' > nftlmount.c:362: warning: unused variable `i' harmless. > sunhme.c:2791: warning: #warning This needs to be corrected... -DaveM > sdla_chdlc.c: In function `if_send': > sdla_chdlc.c:936: warning: unsigned int format, long unsigned int arg (arg 3) > sdla_chdlc.c: In function `wpc_isr': > sdla_chdlc.c:1501: warning: unsigned int format, long unsigned int arg (arg 3) > sdla_ppp.c: In function `if_send': > sdla_ppp.c:901: warning: unsigned int format, long unsigned int arg (arg 3) believe these fall under the set_bit domain. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
OK, but I can't leave without pointing out that having gcc 2.96 breaks compiling gcc 2.95.2. I've got Debian for my main machine and RH7 the other machine on my desk as well as a couple of other test boxen (have to be administered by clueless WinNT-type operators, so Debian was out), and RH7 refuses to compile 2.2.17 or 2.4.0-test9-pre7. "Aha!" thinks Daniel, "I'll just recompile gcc 2.95.2 and all will be well!". No joy; it refuses to compile. Shame, since RH7 has improved dramatically in terms of supporting hardware RAID 5 as the root partition from RH6.2 (i.e. from not at all to working perfectly). d > Please, do *not* start a flamewar about "my distribution is > larger/better/more stable/kinder to animals/whatever than yours" here! > -- > Horst von Brand [EMAIL PROTECTED] > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Daniel Stone Kernel Hacker (or at least has aspirations to be) [EMAIL PROTECTED] http://dustpuppy.ods.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On 07 Feb 2001 11:48:16 -0500, Chris Mason wrote: > > > On Wednesday, February 07, 2001 08:38:54 AM -0800 David Rees > <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote: > >> > >> Ok, how about we list the known bugs: > >> > >> zeros in log files, apparently only between bytes 2048 and 4096 (not > >> reproduced yet). > > > > Could this bug be related to the reported corruption that people with > > new VIA chipsets have been also reporting on ext2? It seems similar > > because of the location of the corruption: > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=98147483712620&w=2 > > > > Anyway, it can't hurt to ask the bug reported if they're using a > > newer VIA chipset and see if they will upgrade their BIOS which seems > > to fix the problem. > > I'd love to blame this on VIA problems, but people are seeing it on other > chipsets too ;-) > > People who report this aren't seeing general corruption, just zeros in > files of specific sizes. So, it really should be a reiserfs bug. I run Reiser on all but /boot, and it seems to enjoy corrupting my mbox'es randomly. Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 chipset with the fixes enabled. This also occurs in some log files, but I put it down to syslogd crashing or something. d -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > I run Reiser on all but /boot, and it seems to enjoy corrupting my > mbox'es randomly. > > what kind of corruption are you seeing? Zeroed bytes. > This also occurs in some log files, but I put it down to syslogd > crashing or something. > > syslogd crashing shouldn't corrupt files... Actually, I meant to say my hard drive crashing. I have two hard drives, side-by-side, and sometimes they overheat and one of them powers down due to the excess heat. They haven't done that lately, though, as I have a dedicated fan for both of them, but the corruption persists. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CML 1 is ok
On Sat, May 19, 2001 at 12:00:28AM +0200, mirabilos wrote: > netfilter: I _liked_ ipfwadm > because I hate to always re-learn when a new kernel comes out. Netfilter is going to stay. Rusty knew from early on in ipchains development that the whole concept was wrong, but Alan told him to continue on, get it into 2.2, and then do a new one for 2.4. There's a document detailing this somewhere, I just can't forget where. > our company will soon ship a product still using ipfwadm (I > started with 2.0.33, going to .36 and 2.4.0-testX). > It's a pity this M$ism to not support it forever (they just > stopped supporting DOS! and GW-BASIC *snief*) This is entirely incorrect and FUD. If enable Netfilter, look in the Netfilter options, disable conntrack and IP tables support, you have (*gasp!*) ipchains compatability, as well as (*ohmygod!*) ipfwadm compatability. > -mirabilos > > PS: Don't answer plz as I'll be offline for a time. > _And_ I mean this honest, even it might considered sp.m The FUD has to be corrected. -- Daniel Stone [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.6-pre2 page_launder() improvements
On Sun, Jun 10, 2001 at 01:40:44AM -0300, Rik van Riel wrote: > [Request For Testers ... patch below] > > Hi, > > during my holidays I've written the following patch (forward-ported > to 2.4.6-pre2 and improved a tad today), which implements these > improvements to page_launder(): > > YMMV, please test it. If it works great for everybody I'd like > to get this improvement merged into the next -pre kernel. I forgot about vmstat, but this is -ac12, anecdotal evidence - my system (weak) performs far better under heavy load (mpg123 nice'd to -20 + apt/dpkg + gcc), than with vanilla -ac12. To get it to compile on -ac, just hand-hack in the patch, and s/CAN_GET_IO/can_get_io_locks/ in vmscan.c. :) d -- Daniel Stone<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS and Alan kernel tree
On Sat, May 05, 2001 at 11:08:16PM +0200, Daniel Podlejski wrote: > I merge XFS witch Alan tree (2.4.4-ac5). It's seems to be stable. > Patch against Alan tree is avaliable at: Hi Daniel, I've got a KDB patch against a relatively recent 2.4.5-ac6, but are you still continuing your porting effort to the -ac series? Thanks, d -- Daniel Stone<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: State of Linux graphics
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote: > The article has been reviewed but if it still contains technical > errors please let me know. Opinions on the content are also > appreciated. 'As a whole, the X.org community barely has enough resources to build a single server. Splitting these resources over many paths only results in piles of half finished projects. I know developers prefer working on whatever interests them, but given the resources available to X.org, this approach will not yield a new server or even a fully-competitive desktop based on the old server in the near term. Maybe it is time for X.org to work out a roadmap for all to follow.' You lose. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert "intel_agp: fix stolen mem range on G33"
On Sat, Oct 06, 2007 at 12:41:21PM +0200, Jiri Slaby wrote: > On 10/06/2007 07:42 AM, Kyle McMartin wrote: > > This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which > > breaks horribly if you aren't running an unreleased xf86-video-intel > > driver out of git. > > I guess, this will break my graphics, no? > http://lkml.org/lkml/2007/9/20/447 You need to upgrade Mesa. Cheers, Daniel signature.asc Description: Digital signature
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wed, Jun 20, 2001 at 05:53:44PM -0500, [EMAIL PROTECTED] wrote: > Not I. The slides for my last meeting were done as TIFF files and I used xv to > display them. Plus, the most recent documentation I wrote for one of our > mainframe applications was done with vi and LaTeX. "What, in addition to the > printed copies, you want a copy of the Word document? There is no Word > document. But I'll convert it to Rich Text for you and you can take it from > there." If my employer didn't require me to use them occasionally, I'd delete > every Microsoft product on my laptop. It's not that I have anything against > proprietary software. It's just Microsoft that I despise. I did the slides for my last LUG talk in MagicPoint (apt-get install mgp, or on rpmfind.net, or wherever, maybe even with RH, I don't know). Very clean format - see http://kabuki.sfarc.net/daniel/netfilter/netfilter.mgp -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] XFS in large Maildir
Hi guys, I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from some point). I'll try an update now, but when I try to access stuff in ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I attached was from mutt, but it also successfully hangs ls, so I doubt it's a mutt bug. :) d -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" ksymoops 2.4.1 on i586 2.4.6-pre3-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.6-pre3-xfs/ (default) -m /boot/System.map-2.4.6-pre3-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Error (regular_file): read_system_map stat /boot/System.map-2.4.6-pre3-xfs failed Unable to handle kernel paging request at virtual address e5a8b460 c01a7a0b *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: e5a8b440 ebx: 224d7000 ecx: c5a8b440 edx: c5c7d9c0 esi: c5a8c1e0 edi: e5a8b440 ebp: c467ba9c esp: c467ba98 ds: 0018 es: 0018 ss: 0018 Process mutt (pid: 7299, stackpage=c467b000) Stack: c45bd7e0 c467bab8 c01a3f11 c5c7d9c0 e5a8b440 c467bcc4 c5a8d0c0 c467bc70 c01a3d10 c5a8c1e0 c5a8b440 c467badc c467bcc4 c5a8d0c0 c01c3052 c589a470 c589a470 22508000 1000 c467bb00 c589a550 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 48 20 8b 52 24 8b 40 24 39 cb 75 0c 39 c2 75 08 8d 74 26 >>EIP; c01a7a0b<= Trace; c01a3f11 Trace; e5a8b440 Trace; c01a3d10 Trace; c01c3052 Trace; c01a3c4f Trace; c01a4722 Trace; c020b840 Trace; c01a3f67 Trace; c01a7bca Trace; c01cfd10 Trace; c01a4079 Trace; c01a7c50 Trace; c01a7c68 Trace; c01a46fa Trace; c01f78e0 Trace; c01e45d3 Trace; c01e5643 Trace; c01e36c9 Trace; c01e3aa6 Trace; c01f8baa Trace; c01fd1d1 Trace; c020592e Trace; c01367a8 Trace; c0136e6d Trace; c01375db Trace; c012c49e Trace; c012c7a6 Trace; c0106b13 <__up_wakeup+102b/23dc> Code; c01a7a0b <_EIP>: Code; c01a7a0b<= 0: 8b 48 20 mov0x20(%eax),%ecx <= Code; c01a7a0e 3: 8b 52 24 mov0x24(%edx),%edx Code; c01a7a11 6: 8b 40 24 mov0x24(%eax),%eax Code; c01a7a14 9: 39 cb cmp%ecx,%ebx Code; c01a7a16 b: 75 0c jne19 <_EIP+0x19> c01a7a24 Code; c01a7a18 d: 39 c2 cmp%eax,%edx Code; c01a7a1a f: 75 08 jne19 <_EIP+0x19> c01a7a24 Code; c01a7a1c 11: 8d 74 26 00 lea0x0(%esi,1),%esi 2 warnings and 1 error issued. Results may not be reliable.
Re: [OOPS] XFS in large Maildir
On Sun, Jun 24, 2001 at 12:18:00PM +0200, Seth Mos wrote: > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > Hi guys, > > I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from > > some point). I'll try an update now, but when I try to access stuff in > > ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I > > attached was from mutt, but it also successfully hangs ls, so I doubt it's a > > mutt bug. > > Have you tried running xfs_repair -n on the filesystem to see if something > is wrong? Was the kernel compiled with 2.96-?? of 2.91.66? I haven't tried anything on the filesystem yet, and it was compiled with Debian (sid aka unstable)'s 2.95.3 snapshot. -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] XFS in large Maildir
On Sun, Jun 24, 2001 at 01:07:40PM +0200, Seth Mos wrote: > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > On Sun, Jun 24, 2001 at 12:18:00PM +0200, Seth Mos wrote: > > > On Sun, 24 Jun 2001, Daniel Stone wrote: > > > > > > > Hi guys, > > > > I've attached the ksymoops output from Linux 2.4.6-pre3-xfs (CVS tree from > > > > some point). I'll try an update now, but when I try to access stuff in > > > > ~/Maildir/netfilter/cur (~7k files in it), XFS just OOPSes. The OOPS I > > > > attached was from mutt, but it also successfully hangs ls, so I doubt it's a > > > > mutt bug. > > > > > > Have you tried running xfs_repair -n on the filesystem to see if something > > > is wrong? Was the kernel compiled with 2.96-?? of 2.91.66? > > > > I haven't tried anything on the filesystem yet, and it was compiled with > > Debian (sid aka unstable)'s 2.95.3 snapshot. > > if you can run xfs_repair -n to see if it produces error output. > xfs_repair -n works on a mounted filesystem but does not change anything. > > If you do see errors you need to unmount the fs and run xfs_repair and see > if you can reproduce the oops after that there must be other issues. > > Can you also apt-get 2.95.4? I believe that one currently is in unstable. > Even if it is just to test for compiler differences. Er, it's the latest from unstable, whichever one that happens to be. -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cosmetic JFFS patch.
On Thu, Jun 28, 2001 at 11:17:15AM -0700, Christoph Zens wrote: > > > Also, in printk's, you waste run-time memory, and you bloat up the need > > for the log size. Both of which are _technical_ reasons not to do it. > > > > Small is beuatiful. > > I totally agree. If you want to use Linux for a small and low cost > embedded system, you can't afford loads of RAM and FLASH space. > Small is the _key_ for those systems. *For* *those* *systems*. Until 99% of the Linux machines are Agendas, or whatever, and 1% PC's, as opposed to the other way around, we should default to displaying basic[1] info about the driver, unless told to with a "verbose" option or somesuch, which would make it spew verbose stuff[2]. And then a "debug" option which would make it spew lots and lots of stuff[3]. All of this specifiable on the commandline. (Can you currently change the default loglevel on the kernel commandline?). I honestly feel that this is the best idea. Just because we do this by default doesn't mean that the people who make embedded systems can't modify the kernel, or hell, even just the bootflags, to do what they want. :) d [1]: : , e.g.: eth0: Intel EtherExpress PRO/100, IRQ10, etc [2]: : : , e.g.: eepro100.c: v0.1, Daniel Stone <[EMAIL PROTECTED]> eth0: Intel EtherExpress PRO/100, IRQ10, etc [3]: : : , e.g.: eepro100.c: v0.1, Daniel Stone <[EMAIL PROTECTED]> Loaded with no options, scanning all PCI bus by default. eth0: Intel EtherExpress PRO/100, IRQ10, etc Intel i82559 OEM card, with bug. Enabling lock-up workaround bug, but you should get a Tulip. -- Daniel Stone <[EMAIL PROTECTED]> "can NE1 help me aim nuclear weaponz? /MSG ME!!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 05:01:18PM -0700, Aaron Lehmann wrote: > On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote: > > And UNIX on a phone is pure overkill. > > Quit being a naysayer. UNIX on a PDA is a wet dream. What real value does it have, apart from the geek "look at me, I'm using bash" value? -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 05:20:27PM -0700, Aaron Lehmann wrote: > On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote: > > What real value does it have, apart from the geek "look at me, I'm using > > bash" value? > > I don't really want to get into it at the moment, but imagine hacking > netfilter without lugging a laptop around. PDA's are sleek and cool, > and using UNIX on them lets you write shell scripts to sort your > addresses and stuff like that. Basically it's everything that's cool > about Unix as a workstation OS scaled down to PDA-size. True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a tab! not space! you just broke my makefiles! aargh!), and compiling Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA. Hrmz. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote: > > > Quit being a naysayer. UNIX on a PDA is a wet dream. > > What real value does it have, apart from the geek "look at me, I'm using > > bash" value? > > It means I can do anything on my ipaq I can do anywhere else. I can run > multiple apps at a time. I can run X11. I can run the palm emulator even ;) How long does it take you to write "date"? Plus, aren't you content with IRCing on your *phone*? ;) > Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool > of apps, environments and tools. Anything your PC can do, my ipaq can do. OK. "time make bzImage". Of course, mine's really slow (and I will consider myself publically humiliated if my only Linux machine is beaten on a kernel compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to write "uptime" on it constitutes a walking penis extension after a while? -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 05:35:10PM -0700, Aaron Lehmann wrote: > On Wed, Apr 25, 2001 at 10:32:46AM +1000, Daniel Stone wrote: > > True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a > > tab! not space! you just broke my makefiles! aargh!), and compiling > > Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA. > > Hrmz. > > I didn't say it was practical. But those PDA's are getting downright > speedy. Much faster than UNIX workstations from days of old. Please, oh please, tell me my machine would beat it on a "time make bzImage". Else I'll do something really stupid. Like, get one for my workstation and feel the improvement ;) > Input is a big problem, but we'll leave that to technology (speech? > microkeyboards?) Aye - difference between space and tab. Broken Makefiles, anyone? -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Wed, Apr 25, 2001 at 08:45:25AM +0100, Alan Cox wrote: > > True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a > > tab! not space! you just broke my makefiles! aargh!), and compiling > > Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA. > > Usual misguided assumptions > > 1.Many PDA's have a keyboard > 2.The ipaq has an optional fold up keyboard > 3.Modern PDA's have 200Mhz processors and XScale will see some of them > hitting 600MHz+ I stand corrected. Too broke to get one, but corrected nevertheless. (I've only seen the agenda in action, and it seemed a lot of time writing "date" for relatively little action - the date). -- Daniel Stone [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Fri, Apr 27, 2001 at 03:12:39PM +0200, Robert Varga wrote: > On Wed, Apr 25, 2001 at 10:34:56AM +1000, Daniel Stone wrote: > > On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote: > > > > What real value does it have, apart from the geek "look at me, I'm using > > > > bash" value? > > > > > > It means I can do anything on my ipaq I can do anywhere else. I can run > > > multiple apps at a time. I can run X11. I can run the palm emulator even ;) > > > > How long does it take you to write "date"? Plus, aren't you content with > > IRCing on your *phone*? ;) > > Okay. Does the word *choice* ring a bell ? Agenda VR3s are supplied with Linux > kernel (modified), and it gives you the freedom to choose what kind of SW > you want to use -- hey, it's linux and when the app fits in the memory, > there's no stopping you. Different look and feel? Different graffitti? Different > kernel? You name it and you got it (well mostly) ;-) I know all this, see my very first point above. I just can't see the real practical value. I'd more than likely find a Palm more productive, as it's simple, does one task, and does it well. If I wanted to buy a PDA, I'd get a Palm. If I wanted to buy a miniature laptop, I'd get a PictureBook or somesuch. I just can't see the practical use. -- Daniel Stone [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Thu, Apr 26, 2001 at 09:35:45PM +0200, Pavel Machek wrote: > Hi! Hola. > > > read the news! i'm programming nokia 9210 with c++, is that > > > computer enough? > > > > Aah. I see. Where was this? I never saw it. > > 9210 has qwerty keyboard. He said "read the news". I've seen the 9110 and 9210's, I was asking where this news was. > > > i bet if you programmed one, you'd wish you have posix > > > interface. > > > > That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be > > absolutely *rock solid*. Look at the 5110, that's just about perfect. The > > 7110, on the other hand ... > > And point is? The point is that you need a known good, absolutely rock-solid OS to do it, and IMHO, you really need a customised job, not something like Linux, which is a monolith in comparison. > > > and how's stability, speed, etc. they read. is there a linux > > > advocate around here? > > > > There are Linux advocates, but I'd say most of us are sane enough to use the > > right-tool-for-the-job approach. And UNIX on a phone is pure > > overkill. > > Is it? Let's see. > > You want your mobile phone to read mail. That's SMTP. Oh, and SMTP > needs to run over something. That's TCP/IP over PPP or SLIP. Oh and > you want web access. Add HTTP to the list. In the mobile world, that is *all* WAP. > [above is reasonable even for "normal" mobile phone; those below > require keyboard] > > You'd like to ssh from your mobile phone. Add ssh. You'd like to ssh > *to* your mobile phone, because it keyboard sucks. That sshd. You'd > like to be able to let others to play games on your mobile phone, oh > that means multiuser mode. I'd *like* to, sure, but this is impractical because the mobile links suck so hard. Dunno about you, but it takes a few seconds to pull in a <1k page. Ugh. SSH? Games, sure, I point my phone at a 7110 or 6210 and I can play 2-player Snake 2 :) > You see? Linux has much stuff you'll need. True, but you have to be wary of overkill, like I said. > > Your sister won't notice much advantage. Linux on a workstation actually has > > *disadvantages* (unfamiliar interface, unintuitive same, etc), as opposed to > > 'Doze on a workstation. Sure it's more stable, and the tiniest bit faster, > > but what's that really matter to your sister, if she can't even figure out > > how to use it? > > My brother is 10 and he uses suse7.2 installation just fine. He likes > it more than windoze 2000 (I deleted) because there are more games in > kde than in windows. [I'd prefer gnome.] I've used RedHat since I was about 11, Debian since 13. It's not that hard, if you can just get used to it. But you're playing with yourself if you think that KDE has more games than Win2k ... Black & White? All the Star Wars games? etc ... I know a lot of them are being ported to Linux, most via Loki, but still ... (I use GNOME, and the panel giving me Bus errors is starting to annoy me). > > -d, who owns a 7110 and can lock it solid, or get it to do funny resetting > > tricks, at least once every 2 days > > Hmm, maybe your 7110 needs memory protection so that runaway calendar > can not hurt basic functions? ;-). Oh, I think it's just to do with changing state, seeing as most of the lockups I get are when I hit keys really, really quickly in sequence, and one lands just as the screen's blank, and it's changing state (snake 2 can also kill it). -- Daniel Stone [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] Vibra16XS and OSS/Free - static
Hi, I have a Vibra16XS (yes, I know it sucks, but I can't afford better right now), and, after about 15 minutes of mpg123 playing, it will suddenly go to complete static. This can only be fixed by something closing the channel, and then reopening it. I've also tried with large waves, only to get the same result. This is using 2.4.4-ac6, with only Netfilter hacks. d -- Daniel Stone [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] drm: Add API for capturing frame CRCs
Hi Tomeu, On 22 July 2016 at 15:10, Tomeu Vizoso wrote: > +/** > + * DOC: CRC ABI > + * > + * DRM device drivers can provide to userspace CRC information of each frame > as > + * it reached a given hardware component (a "source"). > + * > + * Userspace can control generation of CRCs in a given CRTC by writing to the s/can/must/ Is it worth having 'auto' as a default source perhaps? > + * file dri/0/crtc-N/crc/control in debugfs, with N being the index of the > CRTC. > + * Accepted values are source names (which are driver-specific) and the > "none" > + * and "auto" keywords. "none" will disable CRC generation and "auto" will > let > + * the driver select a default source of frame CRCs for this CRTC. Is it also worth having 'connector-%s' (named as per sysfs, e.g. connector-HDMI-A-0) as a standardised entry, for cloneable CRTCs which have CRC control on the connector rather than the CRTC? Cheers, Daniel
Re: [RfC PATCH] Add udmabuf misc device
Hi Gerd, On 14 March 2018 at 08:03, Gerd Hoffmann wrote: >> Either mlock account (because it's mlocked defacto), and get_user_pages >> won't do that for you. >> >> Or you write the full-blown userptr implementation, including mmu_notifier >> support (see i915 or amdgpu), but that also requires Christian Königs >> latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr >> buffers is a no-go). > > I guess I'll look at mlock accounting for starters then. Easier for > now, and leaves the door open to switch to userptr later as this should > be transparent to userspace. Out of interest, do you have usecases for full userptr support? Maybe another way would be to allow creation of dmabufs from memfds. Cheers, Daniel
Re: [PATCH 08/10] drm/fourcc: Add definitions for Allwinner vendor and MB32 tiled format
Hi Paul, On 21 March 2018 at 15:29, Paul Kocialkowski wrote: > +/* > + * Allwinner "MB32" tiled format > + * > + * This is the primary layout coming out of the VPU, where pixels are tiled > + * 32x32. > + */ Can you please be a bit more specific here, following the other examples? In particular, it should list whether the tile order is row- or column-major. Cheers, Daniel
Re: [PATCH] drm/vc4: Add support for SAND modifier.
Hey Eric, On 3 March 2018 at 01:34, Eric Anholt wrote: > Ccing a couple of folks who are likely to have opinions about > drm_fourcc.h additions (Do we have enough docs? Are the macros OK?), > and Bootlin who are likely reviewers. > > The plan is to use these modifiers in VC4 GL imports as well, and for > buffers coming from the v4l2 mmal camera driver. You can find a demo > using this in KMS planes at > https://github.com/anholt/drm_mmal/commit/sand for now. I had a dig through and this seems like the most sensible thing to do if you have a reasonable variety of tile heights. If you only see a couple of combinations in the wild, then hardcoding them as separate modifiers might make things easier than hiving off 24 bits. If you do keep the split though, and especially if you're envisioning future flexible tile formats, maybe something like an 8 code / 48 params split would make more sense. Either way, those are just my opinions (you did ask), and I don't see anything really objectionable, so if you think that's a good split then this is: Acked-by: Daniel Stone Cheers, Daniel
Re: Linux 4.17-rc7
Hi Pavel, On 30 May 2018 at 12:17, Pavel Machek wrote: >> The bulk of it is really pretty trivial one-liners, and nothing looks >> particularly scary. Let's see how next week looks, but if nothing really >> happens I suspect we can make do without an rc8. >> >> Shortlog appended as usual. Go out and test. > > Any chance to still get in this one? > > https://github.com/freedesktop/drm-misc/commit/2bc5ff0bdc00d81d719dad74589317a260d583ed > > ...it fixes display on Nokia N900, and display is rather important for > cellphone. The pull request was sent to Dave just yesterday: https://lists.freedesktop.org/archives/dri-devel/2018-May/178606.html Cheers, Daniel
Re: Linux 4.1 WARNING in drm_ioctl.c
Hi, On 23 June 2015 at 07:39, Daniel Vetter wrote: > Which drm driver are you using? I didn't spot anything in your module list > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > will tell us for sure. That'd be vgem. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/ttm: don't set page->mapping
Hi, On Wed, 25 Nov 2020 at 18:06, Jason Gunthorpe wrote: > On Wed, Nov 25, 2020 at 05:28:32PM +0100, Daniel Vetter wrote: > > Apologies again, this shouldn't have been included. But at least I > > have an idea now why this patch somehow was included in the git > > send-email. Lovely interface :-/ > > I wrote a bit of a script around this because git send-email just too > hard to use > > The key workflow change I made was to have it prepare all the emails > to send and open them in an editor for review - exactly as they would > be sent to the lists. > > It uses a empty 'cover-letter' commit and automatically transforms it > into exactly the right stuff. Keeps track of everything you send in > git, and there is a little tool to auto-run git range-diff to help > build change logs.. This sounds a fair bit like patman, which does something similar and also lets you annotate commit messages with changelogs. But of course, suggesting different methods of carving patches into stone tablets to someone who's written their own, is even more of a windmill tilt than rDMA. ;) Cheers, Daniel
Re: [RFC v2 5/8] drm/fence: add in-fences support
Hi, On 28 April 2016 at 23:28, Rob Clark wrote: > On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote: >> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote: >>> A (per-CRTC?) array of fences would be more flexible. And even in the cases >>> where you could make a 1-to-1 mapping between planes and fences, it's not >>> that much more work for userspace to assemble those fences into an array >>> anyway. >> >> I'm ok with an array too if that's what you folks prefer (it's meant to be >> used by you after all). I just don't want just 1 fence for the entire op, >> forcing userspace to first merge them all together. That seems silly. > > I was kinda more a fan of array too, if for no other reason that to be > consistent w/ how out-fences work. (And using property just for > in-fence seemed slightly weird/abusive to me) I don't think it's really useful to look for much consistency between the two, beyond the name. I'm more concerned with consistency between in-fences and the implicit fences on buffers/FBs, and between out-fences and the page_flip_events. >> One side-effect of that is that we'd also have to rework all the internal >> bits and move fences around in atomic. Which means change a pile of >> drivers. Not sure that's worth it, but I'd be ok either way really. > > hmm, well we could keep the array per-plane (and if one layer is using > multiple planes, just list the same fd multiple times).. then it > mostly comes down to changes in the ioctl fxn itself. ... and new API in libdrm, which is going to be a serious #ifdef and distribution pain. The core property API has been available since 2.4.62 last June, but for this we'd have to write the code, wait for the kernel code, wait for HWC, get everything together, and then merge and release. That gives minimum one year of libdrm releases which have had atomic but not in-fence API support, if we're adding a new array. And I just don't really see what it buys us, apart from the need for the core atomic_get_property helper to statically return -1 when requesting FENCE_FD. Cheers, Daniel
Re: [PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event v3
Hi Tomeu,
On 5 April 2016 at 16:07, Tomeu Vizoso wrote:
> On 4 April 2016 at 17:44, Daniel Stone wrote:
>> On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
>>> + if (async) {
>>> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
>>> + if (crtc->state->event ||
>>> + rockchip_drm_crtc_has_pending_event(crtc)) {
>>> + return -EBUSY;
>>> + }
>>> + }
>>> + }
>>
>> Hmmm ...
>>
>> Doesn't this trigger before the VOP atomic_begin() helper, meaning
>> that anything with an event set will trigger the check? Seems like it
>> should be && rather than ||.
>
> So, these are the two cases that this code aims to handle:
>
> 1. A previous request with an event set hasn't progressed to
> atomic_begin yet, so the event field in drm_crtc_state (at this point,
> the old state) is still populated but vop->event still isn't.
Ah right, this was what I was missing: the async (non-blocking)
implementation. Sounds good to me then.
Cheers,
Daniel
Re: [PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event v5
On 24 May 2016 at 09:27, Tomeu Vizoso wrote: > As per the docs, atomic_commit should return -EBUSY "if an asycnhronous > updated is requested and there is an earlier updated pending". > > v2: Use the status of the workqueue instead of vop->event, and don't add > a superfluous wait on the workqueue. > > v3: Drop work_busy, as there's a sizeable delay when the worker > finishes, which introduces a race in which the client has already > received the last flip event but the next page flip ioctl will still > return -EBUSY because work_busy returns outdated information. > > v4: Hold dev->event_lock while checking the VOP's event field as > suggested by Daniel Stone. > > v5: Only block if there's outstanding work if it's a blocking call. > > Signed-off-by: Tomeu Vizoso Reviewed-by: Daniel Stone Cheers, Daniel
Re: [RFC v2 5/8] drm/fence: add in-fences support
Hi, On 26 April 2016 at 21:48, Greg Hackmann wrote: > On 04/26/2016 01:05 PM, Daniel Vetter wrote: >> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: >>> What are they doing that can't stuff the fences into an array >>> instead of props? >> >> The hw composer interface is one in-fence per plane. That's really the >> major reason why the kernel interface is built to match. And I really >> don't think we should diverge just because we have a slight different >> color preference ;-) > > The relationship between layers and fences is only fuzzy and indirect > though. The relationship is really between the buffer you're displaying on > that layer, and the fence representing the work done to render into that > buffer. SurfaceFlinger just happens to bundle them together inside the same > struct hwc_layer_1 as an API convenience. Right, and when using implicit fencing, this comes as a plane property, by virtue of plane -> fb -> buffer -> fence. > Which is kind of splitting hairs as long as you have a 1-to-1 relationship > between layers and DRM planes. But that's not always the case. Can you please elaborate? > A (per-CRTC?) array of fences would be more flexible. And even in the cases > where you could make a 1-to-1 mapping between planes and fences, it's not > that much more work for userspace to assemble those fences into an array > anyway. As Ville says, I don't want to go down the path of scheduling CRTC updates separately, because that breaks MST pretty badly. If you don't want your updates to display atomically, then don't schedule them atomically ... ? That's the only reason I can see for making fencing per-CRTC, rather than just a pile of unassociated fences appended to the request. Per-CRTC fences also forces userspace to merge fences before submission when using multiple planes per CRTC, which is pretty punitive. I think having it semantically attached to the plane is a little bit nicer for tracing (why was this request delayed? -> a fence -> which buffer was that fence for?) at a glance. Also the 'pile of appended fences' model is a bit awkward for more generic userspace, which creates a libdrm request and builds it (add a plane, try it out, wind back) incrementally. Using properties makes that really easy, but without properties, we'd have to add separate codepaths - and thus separate ABI, which complicates distribution - to libdrm to account for a separate plane array which shares a cursor with the properties. So for that reason if none other, I'd really prefer not to go down that route. Cheers, Daniel
Re: [RFC v2 7/8] drm/fence: add fence timeline to drm_crtc
Hi,
On 26 April 2016 at 00:33, Gustavo Padovan wrote:
> +static inline struct drm_crtc *fence_to_crtc(struct fence *fence)
> +{
> + if (fence->ops != &drm_crtc_fence_ops)
> + return NULL;
Since this is (currently) only used before unconditional dereferences,
maybe turn this into a BUG_ON instead of return NULL?
Cheers,
Daniel
Re: [PATCH 8/9] drm/vc4: Add support for async pageflips.
Hi, On 4 December 2015 at 01:42, Eric Anholt wrote: > Daniel Stone writes: >> On 1 December 2015 at 20:35, Eric Anholt wrote: >>> An async pageflip stores the modeset to be done and executes it once >>> the BOs are ready to be displayed. This gets us about 3x performance >>> in full screen rendering with pageflipping. >> >> Looks good, but you're missing a preclose callback to reap dead events, a la: >> https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7e7a1b9ca129c411a9da9c911037965 >> >> (and parent commit to wire that through to core DRM preclose) > > We've already got a preclose callback that reaps crtc->event -- see > vc4_cancel_page_flip(). Right you are. Carry on then. :) Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/9] drm/rockchip: Use new vblank api drm_crtc_vblank_*
Hi, On 1 December 2015 at 03:26, Mark Yao wrote: > No functional update, drm_vblank_* is the legacy version of > drm_crtc_vblank_*. and use new api make driver more clean. > > Signed-off-by: Mark Yao Heh, I had the same patch in my series to fix pageflip events. Reviewed-by: Daniel Stone Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/9] drm/rockchip: Convert to support atomic API
Hi Mark,
On 1 December 2015 at 03:26, Mark Yao wrote:
> +static void rockchip_atomic_wait_for_complete(struct drm_atomic_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc->state->active)
> + continue;
> +
> + WARN_ON(drm_crtc_vblank_get(crtc));
> + }
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc->state->active)
> + continue;
> +
> + rockchip_crtc_wait_for_update(crtc);
> + }
I'd be much more comfortable if this passed in an explicit pointer to
state, or an address to wait for, rather than have wait_for_complete
dig out state with no locking. The latter is potentially racy for
async operations.
> +struct vop_plane_state {
> + struct drm_plane_state base;
> + dma_addr_t dma_addr[ROCKCHIP_MAX_FB_BUFFER];
Can you get rid of this by just using the pointer to a
rockchip_gem_object already provided?
> -static int vop_update_plane_event(struct drm_plane *plane,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb, int crtc_x,
> - int crtc_y, unsigned int crtc_w,
> - unsigned int crtc_h, uint32_t src_x,
> - uint32_t src_y, uint32_t src_w,
> - uint32_t src_h,
> - struct drm_pending_vblank_event *event)
> +static int vop_plane_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> {
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_framebuffer *fb = state->fb;
> struct vop_win *vop_win = to_vop_win(plane);
> + struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
> const struct vop_win_data *win = vop_win->data;
> - struct vop *vop = to_vop(crtc);
> struct drm_gem_object *obj;
> struct rockchip_gem_object *rk_obj;
> - struct drm_gem_object *uv_obj;
> - struct rockchip_gem_object *rk_uv_obj;
> unsigned long offset;
> - unsigned int actual_w;
> - unsigned int actual_h;
> - unsigned int dsp_stx;
> - unsigned int dsp_sty;
> - unsigned int y_vir_stride;
> - unsigned int uv_vir_stride = 0;
> - dma_addr_t yrgb_mst;
> - dma_addr_t uv_mst = 0;
> - enum vop_data_format format;
> - uint32_t val;
> - bool is_alpha;
> - bool rb_swap;
> bool is_yuv;
> bool visible;
> int ret;
> - struct drm_rect dest = {
> - .x1 = crtc_x,
> - .y1 = crtc_y,
> - .x2 = crtc_x + crtc_w,
> - .y2 = crtc_y + crtc_h,
> - };
> - struct drm_rect src = {
> - /* 16.16 fixed point */
> - .x1 = src_x,
> - .y1 = src_y,
> - .x2 = src_x + src_w,
> - .y2 = src_y + src_h,
> - };
> - const struct drm_rect clip = {
> - .x2 = crtc->mode.hdisplay,
> - .y2 = crtc->mode.vdisplay,
> - };
> - bool can_position = plane->type != DRM_PLANE_TYPE_PRIMARY;
> + struct drm_rect *dest = &vop_plane_state->dest;
> + struct drm_rect *src = &vop_plane_state->src;
> + struct drm_rect clip;
> int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
> DRM_PLANE_HELPER_NO_SCALING;
> int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
> DRM_PLANE_HELPER_NO_SCALING;
>
> - ret = drm_plane_helper_check_update(plane, crtc, fb,
> - &src, &dest, &clip,
> + crtc = crtc ? crtc : plane->state->crtc;
> + /*
> +* Both crtc or plane->state->crtc can be null.
> +*/
> + if (!crtc || !fb)
> + goto out_disable;
> + src->x1 = state->src_x;
> + src->y1 = state->src_y;
> + src->x2 = state->src_x + state->src_w;
> + src->y2 = state->src_y + state->src_h;
> + dest->x1 = state->crtc_x;
> + dest->y1 = state->crtc_y;
> + dest->x2 = state->crtc_x + state->crtc_w;
> + dest->y2 = state->crtc_y + state->crtc_h;
> +
> + clip.x1 = 0;
> + clip.y1 = 0;
> + clip.x2 = crtc->mode.hdisplay;
> + clip.y2 = crtc->mode.vdisplay;
> +
> + ret = drm_plane_helper_check_update(plane, crtc, state->fb,
> + src, dest, &clip,
> min_scale,
> max_scale,
> - can_position, false, &visible);
> + true, tr
Re: [PATCH 8/9] drm/vc4: Add support for async pageflips.
Hi, On 1 December 2015 at 20:35, Eric Anholt wrote: > An async pageflip stores the modeset to be done and executes it once > the BOs are ready to be displayed. This gets us about 3x performance > in full screen rendering with pageflipping. Looks good, but you're missing a preclose callback to reap dead events, a la: https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7e7a1b9ca129c411a9da9c911037965 (and parent commit to wire that through to core DRM preclose) Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/9] drm/rockchip: Convert to support atomic API
Hi Mark,
Thanks for getting back to this.
On 1 December 2015 at 09:31, Mark yao wrote:
> On 2015年12月01日 16:18, Daniel Stone wrote:
>> On 1 December 2015 at 03:26, Mark Yao wrote:
>>> >+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
>>> >+ if (!crtc->state->active)
>>> >+ continue;
>>> >+
>>> >+ rockchip_crtc_wait_for_update(crtc);
>>> >+ }
>>
>> I'd be much more comfortable if this passed in an explicit pointer to
>> state, or an address to wait for, rather than have wait_for_complete
>> dig out state with no locking. The latter is potentially racy for
>> async operations.
>>
> Hi Daniel
>"if this passed in an explicit pointer to state, or an address to wait
> for", I don't understand, can you point how it work?
Ah, OK. I mean that rockchip_crtc_wait_for_update takes a drm_crtc
pointer, and establishes the state from that (e.g.
crtc->primary->state). This can easily lead to confusion in async
contexts, as the states attached to a drm_crtc and a drm_plane can
change here while you wait for it.
It would be better if the call was:
for_each_plane_in_state(state, plane, plane_state, i) {
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
rockchip_crtc_wait_for_update(plane_state->crtc, plane_state);
}
This way it is very clear, and there is no confusion as to which
request we are waiting to complete.
In general, using crtc->state or plane->state is a very bad idea,
_except_ in the atomic_check function where you are calculating
changes (e.g. if (plane_state->fb->pitches[0] !=
plane->state->fb->pitches[0]) rockchip_plane_state->pitch_changed =
true). After atomic_check, you should always pass around pointers to
the plane state explicitly, and avoid using the pointers from drm_crtc
and drm_plane.
Does that help?
>>> if (is_yuv) {
>>> /*
>>> * Src.x1 can be odd when do clip, but yuv plane start
>>> point
>>> * need align with 2 pixel.
>>> */
>>> - val = (src.x1 >> 16) % 2;
>>> - src.x1 += val << 16;
>>> - src.x2 += val << 16;
>>> + uint32_t temp = (src->x1 >> 16) % 2;
>>> +
>>> + src->x1 += temp << 16;
>>> + src->x2 += temp << 16;
>>> }
>>
>> I know this isn't new, but moving the plane around is bad. If the user
>> gives you a pixel boundary that you can't actually use, please reject
>> the configuration rather than silently trying to fix it up.
>
> the origin src.x1 would align with 2 pixel, but when we move the dest
> window, and do clip by output, the src.x1 may be clipped to odd.
> regect this configuration may let user confuse, sometimes good, sometimes
> bad.
For me, it is more confusing when the display shows something
different to what I have requested. In some media usecases, doing this
is a showstopper and will result in products failing acceptance
testing. Userspace can make a policy decision to try different
alignments to get _something_ to show (even if it's not what was
explicitly requested), but doing this in the kernel is inappropriate:
please just reject it, and have userspace fall back to another
composition method (e.g. GL) in these cases.
>>> -static void vop_plane_destroy(struct drm_plane *plane)
>>> +static void vop_atomic_plane_destroy_state(struct drm_plane *plane,
>>> + struct drm_plane_state *state)
>>> {
>>> - vop_disable_plane(plane);
>>> - drm_plane_cleanup(plane);
>>> + struct vop_plane_state *vop_state = to_vop_plane_state(state);
>>> +
>>> + if (state->fb)
>>> + drm_framebuffer_unreference(state->fb);
>>> +
>>> + kfree(vop_state);
>>> }
>>
>> You can replace this hook with drm_atomic_helper_plane_destroy_state.
>
>
> Hmm, only can hook with __drm_atomic_helper_plane_destroy_state.
Ah yes, you're right. But still, using that would be better than duplicating it.
> Can you share your Weston environment to me, I'm interesting to test drm
> rockchip on weston.
Of course. You can download Weston from http://wayland.freedesktop.org
- the most interesting dependencies are libevdev, libinput, and
wayland itself. If you are building newer Weston from git, you'll need
the wayland-protocols repository as well, from
anongit.freedesktop.org/git/wayland/wayland-protocols/. Please let me
know privately if you need some more help with building these, but
they should be quite straightforward.
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/9] drm/rockchip: Convert to support atomic API
Hi Mark, On 2 December 2015 at 14:18, Daniel Stone wrote: > On 1 December 2015 at 09:31, Mark yao wrote: >> Can you share your Weston environment to me, I'm interesting to test drm >> rockchip on weston. > > Of course. You can download Weston from http://wayland.freedesktop.org > - the most interesting dependencies are libevdev, libinput, and > wayland itself. If you are building newer Weston from git, you'll need > the wayland-protocols repository as well, from > anongit.freedesktop.org/git/wayland/wayland-protocols/. Please let me > know privately if you need some more help with building these, but > they should be quite straightforward. Sorry, left one thing out. When running, if you do not have GBM/Wayland enabled for Mali (or no Mali support), you should run with: weston --use-pixman or: weston-launch -- --use-pixman Launching from SSH is a bit more complicated: sudo weston-launch --user=$username --tty=/dev/tty3 -- --use-pixman (Replace tty3 with the TTY of your choice: it must be in text mode.) Once you have done this, you will find three issues: - passing -1 to drm_send_vblank event causes OOPS - now fixed in your tree - not sending pageflip events for same-fb flips causes Weston hang - fixed with my patch, and I believe now fixed in atomic (though it may still have some timing issues; I hope to get to review this early next week) - not having a preclose hook causes OOPS when Weston exits in the middle of rendering - fixed in https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7e7a1b9ca129c411a9da9c911037965 and the preceding commit, which I hope to re-send for 4.4 -fixes in the next couple of days Hope this helps. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller.
Hi Liviu,
On 2 December 2015 at 12:23, Liviu Dudau wrote:
> + if (irq_status & HDLCD_INTERRUPT_VSYNC) {
> + unsigned long flags;
> +
> + drm_handle_vblank(drm, 0);
> +
> + spin_lock_irqsave(&drm->event_lock, flags);
> + if (hdlcd->event) {
> + drm_send_vblank_event(drm, hdlcd->event->pipe,
> hdlcd->event);
> + drm_crtc_vblank_put(&hdlcd->crtc);
> + hdlcd->event = NULL;
> + }
> + spin_unlock_irqrestore(&drm->event_lock, flags);
> + }
As with VC4 and Rockchip, you're missing a ->preclose handler in your
drm_drv, to make sure that you don't try to send events to a dead
client (which causes an OOPS):
https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7
(and its parent)
Also, is there anything preventing clients from submitting multiple
pageflips before the event is sent? I couldn't see anything from a
quick look, so you could have the situation of:
- client submits pageflip, event 1 stored to hdlcd->event
- client submits pageflip, event 2 stored to hdlcd->event
- vblank arrives, event 2 is sent
- event 1 has disappeared and been leaked
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] drm/vc4: Add an interface for capturing the GPU state after a hang.
Hey, On 2 December 2015 at 22:26, Daniel Vetter wrote: > On Wed, Dec 02, 2015 at 11:35:16AM -0800, Eric Anholt wrote: >> Yes, I have thought about basing vc4-gpu-tools off of intel-gpu-tools. >> I've actually tried to build and use the kms testing stuff on vc4, and >> it was a total bust. Someone needs to do a lot of work to make igt >> useful for non-intel. If you'd like me to build my vc4 testing inside >> of igt, I'd someone to demo one of my tests building inside of igt, with >> the test runner working and none of the intel-specific tests reporting >> failure, and get me permission to just push code to that repository >> (It's hard enough getting piglit tests reviewed, vc4-specific tests and >> tools would never get review). > > Daniel Stone claimed that this Just Works but evidently it doesn't. > There's some autoconfig fail where igt wants too much intel crap that just > doesn't build on arm. Iirc Daniel had some patches floating around for > that. Yeah, it was working, though with my ARM farm still being in pieces, I haven't been able to keep on top of it lately. Apparently the patch to disable the ancilliary tools fixes the build, so I'll get that pushed when I can actually test it, or for the meantime: http://paste.fedoraproject.org/296836/09692714 This does still require libpciaccess and libdrm-intel to be built, but they _are_ totally possible to build on ARM, without any stupid hacks. My first cut at getting igt running on ARM (before Micah took over) actually started by eviscerating those as well, but it ended up being too much of a yak-shave. If you can get past those, you get a skip for all but the core tests. For the rest, they either need porting to just use dumb-buffers, or split such that the bits exercising Intel-specific tiling modes can be run separately, or left as Intel only. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] drm: Add support for ARM's HDLCD controller.
Hi Liviu,
On 3 December 2015 at 10:00, Liviu Dudau wrote:
> On Wed, Dec 02, 2015 at 05:21:44PM +0000, Daniel Stone wrote:
>> On 2 December 2015 at 12:23, Liviu Dudau wrote:
>> > + if (irq_status & HDLCD_INTERRUPT_VSYNC) {
>> > + unsigned long flags;
>> > +
>> > + drm_handle_vblank(drm, 0);
>> > +
>> > + spin_lock_irqsave(&drm->event_lock, flags);
>> > + if (hdlcd->event) {
>> > + drm_send_vblank_event(drm, hdlcd->event->pipe,
>> > hdlcd->event);
>> > + drm_crtc_vblank_put(&hdlcd->crtc);
>> > + hdlcd->event = NULL;
>> > + }
>> > + spin_unlock_irqrestore(&drm->event_lock, flags);
>> > + }
>>
>> As with VC4 and Rockchip, you're missing a ->preclose handler in your
>> drm_drv, to make sure that you don't try to send events to a dead
>> client (which causes an OOPS):
>> https://git.collabora.com/cgit/user/daniels/linux.git/commit/?h=wip/4.4.x/rockchip-drm-fixes&id=d14f21bcd7
>> (and its parent)
>
> Thanks for reviewing this!
>
> I do acknowledge your concerns and you might correct my understanding on
> how atomic DRM works, but I believe in this case we should be safe. The
> event stored in hdlcd->event is taken out of the crtc->state->event during
> the crtc->atomic_begin() callback. If the client is dead the callback should
> not be called, so that's how we avoid the OOPS.
Right, it's taken out of the CRTC state and put into the overall HDLCD
structure. So the OOPS happens when:
- client submits state with event requested, async flag set
- atomic_begin moves crtc->state->event into hdlcd->event
- control returns to client, who exits immediately
- vblank happens
- hdlcd->event->base.file_priv now points to a dead client
- OOPS
>> Also, is there anything preventing clients from submitting multiple
>> pageflips before the event is sent? I couldn't see anything from a
>> quick look, so you could have the situation of:
>> - client submits pageflip, event 1 stored to hdlcd->event
>> - client submits pageflip, event 2 stored to hdlcd->event
>> - vblank arrives, event 2 is sent
>> - event 1 has disappeared and been leaked
>
> As for multiple events being submitted before vsync interrupt happening: given
> that the event is plucked out of the crtc->state, is that possible? And if so,
> is there a case where having the later event overwrite the earlier one a
> desired
> outcome?
Having events being overwritten is extremely undesirable; it could
cause a client to stall in the right scenarios (e.g. requests
submitted separately for different planes). It would be far better to
turn hdlcd->event into a list of events which are sent per-vblank,
probably just by retaining a list of pending states to apply; this
also makes it easier to handle async commits in the future (which
Weston in particular relies on).
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] component: remove device from master match list on failed add
Calling component_add() may result in the completion of a set of
devices, which will try to bring up a master. In bringing the master
up, we populate its match array with the current set of children.
If binding any of the devices fails, component_add() itself will fail,
free the struct component entry, and return to the caller. The
now-freed entry is never removed from the master's match array, and
will later be used in a futile attempt to bind to freed memory.
Bring component_add's behaviour on failure to bring up a master into
line with component_del by removing the (to-be-freed) component from
the master's match array.
The specific case which broke was:
- rockchip_drm_drv adds a component master
- dwhdmi_rockchip adds a child component in probe (master incomplete)
- rockchip_drm_vop adds two children in probe, which completes the
set
- inside component_add, we try to bring up the master, having
populated the master's match array, and fail with EPROBE_DEFER from
dwhdmi_rockchip; we delete the putative component
- rockchip_drm_vop's probe fails and returns EPROBE_DEFER
- we later re-probe rockchip_drm_vop and add the component; the
master is complete, so we attempt to bring it up again
- walking the match array, we find the previous child, whose master
pointer doesn't match (as it has been freed in the meantime)
- rockchip_drm_vop probe fails, and will never be attempted again
Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
Signed-off-by: Daniel Stone
Cc: Russell King
Cc: Thierry Reding
Cc: Laurent Pinchart
---
drivers/base/component.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 2738039..04a1582 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -491,6 +491,8 @@ int component_add(struct device *dev, const struct
component_ops *ops)
ret = try_to_bring_up_masters(component);
if (ret < 0) {
+ if (component->master)
+ remove_component(component->master, component);
list_del(&component->node);
kfree(component);
--
2.5.0
Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails
Hi Archit, On 11 February 2016 at 09:35, Archit Taneja wrote: > component_master_add_with_match can fail if the master's bind op doesn't > go through successfully. In such a scenario, all the components in the > master's match array have their 'master' pointer set to the given master. > These pointers need to be set to NULL again. If they aren't, successive > calls to component_master_add_with_match will fail because the driver > thinks these components already have a master. > > This issue can be seen when a driver defers probe because of missing > resources. It is seen after the introduction of commit: > > "component: track components via array rather than list" > > Add 'master_remove_components' which sets the all the components's masters > in the match array to NULL. This function is also re-used in > component_master_del and replaces code that did the same thing. Jon already fixed this (in a slightly more limited way perhaps?) in 57480484f9. Cheers, Daniel
Re: [PATCH] component: remove device from master match list on failed add
Russell, On 12 February 2016 at 00:57, Akshay Bhat wrote: > Daniel Stone collabora.com> writes: >> Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8 >> Signed-off-by: Daniel Stone collabora.com> > > Tested-by: Akshay Bhat > > Tested on imx6 processor based board where re-probe was broken after a > probe deferral. One-week ping; this breaks quite a few drivers, even despite 57480484f9 already being present. Another option could just be to revert the original match-array commit (and the subsequent two fixups) until you can work out a fix. Cheers, Daniel
Re: [PATCH] drm: remove unused function
Hi Sudip, On 14 May 2015 at 12:14, Sudip Mukherjee wrote: > this function was not used anywhere and was giving a build warning. Thanks for the patch, but this function is used in following patches that are in the process of being merged. This shouldn't have snuck in in the earlier patch; apologies. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 2/2] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi, On 13 May 2015 at 16:23, CK Hu wrote: > + /* > +* copy the mode data adjusted by mode_fixup() into crtc->mode > +* so that hardware can be seet to proper mode. > +*/ > + memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode)); Please do not do this. adjusted_mode is already available in crtc->hwmode. Please also restructure this driver to use the atomic infrastructure. A good example of how to do this can be found in the Rockchip RK3288 driver which was submitted a while ago: it started off as a legacy driver like this, but was converted during the submission phase. I'm sure there are many more comments to come, but certainly converting to be an atomic driver is the very first step. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
Hi,
On 4 May 2015 at 08:43, Inki Dae wrote:
> On 2015년 05월 02일 13:08, Krzysztof Kozlowski wrote:
>> Selecting CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD leading to build
>> error:
>
> No, eDP has no any dependency of FIMD but DECON. Just add dependency
> code like below,
>
> config DRM_EXYNOS7_DECON
> bool "Exynos DRM DECON"
> - depends on DRM_EXYNOS
> + depends on DRM_EXYNOS && !FB_S3C
But it does clearly and explicitly call fimd_dp_clock_enable from
exynos_dp_powero{n,ff}. So the dependency you're proposing seems
backwards: it's not an expression of the requirements of the current
code (that FIMD DP code be available, i.e. CONFIG_DRM_EXYNOS_FIMD is
selected), but an indirect expression of another dependency
(CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD, so disable
CONFIG_FB_S3C).
Additionally, as the call comes from exynos_dp_core.c, which is built
by CONFIG_DRM_EXYNOS_DP (an explicitly user-selectable option), why
shouldn't the dependency be there? Ah, because the dependency on DP is
for (DECON || FIMD), but as DECON doesn't provide
fimd_dp_clock_enable(), it doesn't seem like it would compile if you
selected DECON and not FIMD.
So, for me, the cleanest solution would be config DRM_EXYNOS_DP gains
a hard dependency on DRM_EXYNOS_FIMD, at least until it can be fixed
to compile without FIMD.
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add virtio gpu driver.
Hi,
On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event *event,
> +uint32_t flags)
> +{
> + return -EINVAL;
> +}
I'm not going to lie, I was really hoping the 5th (?) GPU option for
Qemu would support pageflipping. Daniel's comment about conversion to
atomic is relevant, but: do you have a mechanism which allows you to
post updates (e.g. 'start displaying this buffer now please') that
allows you to get events back when they have actually been displayed?
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vt_buffer: drop console buffer copying optimisations
On 5 February 2015 at 11:35, One Thousand Gnomes wrote: >> If I'm not mistaken, that would be as simple as adding >> >> #define VT_BUF_HAVE_RW. >> #define scr_writew(val, addr) (*(addr) = (val)) >> #define scr_readw(addr) (*(addr)) >> >> to arch/x86/include/asm/vga.h. > > and stick an > > #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS) > > #endif > > around that and its sorted as an option everyone can leave off but the > afflicted. Well, given all the distros will enable that, might as well be #if !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vt_buffer: drop console buffer copying optimisations
On 9 February 2015 at 10:49, Geert Uytterhoeven wrote: > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone wrote: >> On 5 February 2015 at 11:35, One Thousand Gnomes >> wrote: >>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS) >>> >>> #endif >>> >>> around that and its sorted as an option everyone can leave off but the >>> afflicted. >> >> Well, given all the distros will enable that, might as well be #if >> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER). > > All distros on 1 out of 29 architectures? It's a fairly popular architecture. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm/fence: add FENCE_FD property to planes
Hi,
On 5 April 2016 at 13:36, Rob Clark wrote:
> ok, so I've been slacking on writing up the reasons that I don't like
> the idea of using a property for fd's (including fence fd's).. I did
> at one point assume we'd use properties for fence fd's, but that idea
> falls apart pretty quickly when you think about the 'struct file' vs
> fd lifecycle. It could *possibly* work if it was a write-only
> property, but I don't think that is a good solution.
I've been assuming that it would have to be write-only; I don't
believe there would be any meaningful usecases for read. Do you have
any in mind, or is it just a symmetry/cleanliness thing?
> The issue is that 'struct file' / 'int fd' have a fundamentally
> different lifecycle compared to 'kms obj' / 'u32 obj_id'. For the kms
> objects (like framebuffers) where we can use them with properties, the
> id is tied to the kernel side object. This is not true for file
> descriptors. Resulting in a few problems:
Surely the fence FD tied to the kernel-side struct fence, in exactly
the same way, no?
> 1) if it was a readable property, reading it would (should) take a
> reference.. we can't just return fence_fd that was previously set
> (since in the mean time userspace might have close()d the fd). So we
> have to return a fresh fd. And if userspace (like modetest) doesn't
> realize it is responsible to close() that fd we have a leak
Again, assuming that read would always return -1.
> 2) basically we shouldn't be tracking fd's on the kernel side, since
> we can only count on them being valid during the duration of the ioctl
> call. Once the call returns, you must assume userspace has close()d
> the fd. So in the ioctl we need to convert fd -> file, and from then
> on out track the file object (or in this case the underlying fence
> object).
Right, it would have to be the same as KMS objects, where userspace
passes in an ID (in this case an entry in a non-IDR table, but still),
and the kernel maps that to struct fence and handles the lifetime. So,
almost exactly the same as what we do with KMS objects ...
> I guess we *could* have something analogous to dmabuf, where we import
> the fence fd and get a kms drm_fence object (with an id tied to the
> kernel side object), and then use a property to attach the drm_fence
> object.. but that seems kind of pointless and just trying to force the
> 'everything is a property' mantra.
I think that would be pointless indirection as well.
> I think it is really better to pass in an array of 'struct { u32
> plane; int fd }' (which the atomic ioctl code converts into 'struct
> fence's and attaches to the plane state) and an array of 'struct { u32
> crtc; int fd }' filled in on the kernel side for the out-fences.
Mmm, it definitely makes ioctl parsing harder, and still you rely on
drivers to implement the more-difficult-to-not-screw-up part, which
(analagous to crtc_state->event) is the driver managing the lifecycle
of that component of the state. We already enforce this with events
though, and the difficult part wasn't in the userspace interface, but
the backend handling. This doesn't change at all regardless of whether
we use a property or an external array, so ...
Cheers,
Daniel
Re: [RFC 1/6] drm/fence: add FENCE_FD property to planes
Hi,
On 5 April 2016 at 15:04, Rob Clark wrote:
> On Tue, Apr 5, 2016 at 8:57 AM, Daniel Stone wrote:
>> I've been assuming that it would have to be write-only; I don't
>> believe there would be any meaningful usecases for read. Do you have
>> any in mind, or is it just a symmetry/cleanliness thing?
>
> no, don't see a use-case for it.. but this patch didn't seem to be
> preventing it. And it was storing the fence_fd on the kernel side
> which is a no-no as well.
Yeah, both should be fixed. :)
>>> The issue is that 'struct file' / 'int fd' have a fundamentally
>>> different lifecycle compared to 'kms obj' / 'u32 obj_id'. For the kms
>>> objects (like framebuffers) where we can use them with properties, the
>>> id is tied to the kernel side object. This is not true for file
>>> descriptors. Resulting in a few problems:
>>
>> Surely the fence FD tied to the kernel-side struct fence, in exactly
>> the same way, no?
>
> well, what I mean is you can't keep around the int fd on the kernel
> side, like this patch does
>
> A write-only property, which immediately (ie. during the ioctl call)
> is converted into a fence object, would work. Although given that we
> need to handle fences differently (ie. not a property) for out-fences,
> it seems odd to shoehorn them into a property for in-fences.
Depends on how you look at it, I guess. From the point of view of all
fence-like things being consistent, yes, it falls down. But from the
point of view of in-fences being attached to an FB, and out-fences
(like events) being separately attached to a request, it's a lot more
consistent.
>>> I think it is really better to pass in an array of 'struct { u32
>>> plane; int fd }' (which the atomic ioctl code converts into 'struct
>>> fence's and attaches to the plane state) and an array of 'struct { u32
>>> crtc; int fd }' filled in on the kernel side for the out-fences.
>>
>> Mmm, it definitely makes ioctl parsing harder, and still you rely on
>> drivers to implement the more-difficult-to-not-screw-up part, which
>> (analagous to crtc_state->event) is the driver managing the lifecycle
>> of that component of the state. We already enforce this with events
>> though, and the difficult part wasn't in the userspace interface, but
>> the backend handling. This doesn't change at all regardless of whether
>> we use a property or an external array, so ...
>
> hmm, I'm assuming that the in/out arrays are handled in
> drm_mode_atomic_ioctl() and the drivers never see 'em..
True, but it complicates the (already not hugely straightforward)
parsing that the ioctl has to do. It also makes extending the ioctl a
little harder to do in future, because you're adding in two
variable-size elements, and have to do some fairly complicated parsing
to even figure out what the size _should_ be. So I'd rather not do it
if there was any way out of it; at the very least it'd have to be
userptr rather than array.
Cheers,
Daniel
Re: [RFC 0/6] drm/fences: add in-fences to DRM
Hi Inki, On 31 March 2016 at 08:45, Inki Dae wrote: > 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글: >> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote: >>> In addition, I wonder how explicit and implicit fences could coexist >>> together. >>> Rob said, >>> "Implicit sync ofc remains the default, but userspace could opt-in to >>> explicit sync instead" >>> >>> This would mean that if we use explicit sync for user-space then it >>> coexists with implicit sync. However, these two sync fences can't see same >>> DMA buffer because explicit fence has a different file object from implicit >>> one. >>> So in this case, I think explicit fence would need to be hung up on the >>> reservation object of dmabuf object somehow. Otherwise, although they >>> coexist together, are these fences - explicit and implicit - used for >>> differenct purpose separately? >>> >> >> I'm not entirely sure about coexistance at the same time. It ofc >> shouldn't be a problem for one kernel to support both kinds of >> userspace (pure explicit and pure implicit). And how this would work >> on kms atomic ioctl (compositor/consumer) side seems clear enough.. >> ie. some sort of flag, which if set user provides an explicit fence >> fd, and if not set we fall back to current behaviour (ie. get fences >> from resv object). > > With this patch series, users can register explicit fence(s) to atomic > kms(consumer side) through kms property interface for the explicit sync. > > However, now several DRM drivers(also consumer) already have beeen using > implicit fence. So while GPU(producer side) is accessing DMA buffer after > registering its explicit fence to atomic kms, and if atomic commit is > requested by user-space, then atomic helper framework will try to synchronize > with the producer - waiting for the signal of GPU side(producer), and device > specific page flip function will also try to do same thing. Well, it has to be one or the other: mixing explicit and implicit, defeats the purpose of using explicit fencing. So, when explicit fencing is in use, implicit fences must be ignored. > As of now, it seems that this wouldn't be optional but mandatory if explicit > fence support is added to the atomic helper framework. This would definitely > be duplication and it seems not clear enough even if one of them is just > skipped in runtime. Drivers would have to opt in to explicit fencing support, and part of that would be ensuring that the driver does not wait on implicit fences when the user has requested explicit fencing be used. Cheers, Daniel
Re: [RFC 0/6] drm/fences: add in-fences to DRM
Hi Inki, On 31 March 2016 at 11:05, Inki Dae wrote: > 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글: >> On 31 March 2016 at 08:45, Inki Dae wrote: >>> As of now, it seems that this wouldn't be optional but mandatory if >>> explicit fence support is added to the atomic helper framework. This would >>> definitely be duplication and it seems not clear enough even if one of them >>> is just skipped in runtime. >> >> Drivers would have to opt in to explicit fencing support, and part of >> that would be ensuring that the driver does not wait on implicit >> fences when the user has requested explicit fencing be used. >> > > Then, existing drivers would need additional works for explicit fencing > support. This wouldn't be really what the drivers have to but should be > handled with this patch series because this would affect exising device > drivers which use implicit fencing. Well, yes. Anyone implementing their own atomic commit would need to ensure that the commit works properly for fences. The helpers could also add it, but the helpers are not mandatory, and you are not required to use every part of the helper to use one part of the helper. There is no magic wand you can wave that instantly makes it work for every driver. Cheers, Daniel
Re: [RFC 0/6] drm/fences: add in-fences to DRM
Hi Inki, On 31 March 2016 at 12:26, Inki Dae wrote: > 2016-03-31 19:56 GMT+09:00 Daniel Stone : >> On 31 March 2016 at 11:05, Inki Dae wrote: >>> Then, existing drivers would need additional works for explicit fencing >>> support. This wouldn't be really what the drivers have to but should be >>> handled with this patch series because this would affect exising device >>> drivers which use implicit fencing. >> >> Well, yes. Anyone implementing their own atomic commit would need to >> ensure that the commit works properly for fences. The helpers could >> also add it, but the helpers are not mandatory, and you are not >> required to use every part of the helper to use one part of the >> helper. There is no magic wand you can wave that instantly makes it >> work for every driver > > I meant there are already several DRM drivers which work properly for > implicit fence. So if atomic helper framework of DRM core is > considered only for the explicit fence, then fencing operation would > affect the existing DRM drivers. So I hope this trying could consider > existing implicit fence users. Yes, absolutely. Implicit fencing is already part of userspace ABI that we can effectively never remove: it would break everyone's desktops on Intel alone, as well as many others. So explicit will be opt-in from the user and the driver both, and only when the combination is fully supported will explicit fencing be used. Cheers, Daniel
Re: [PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event v3
Hi Tomeu,
On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 3b8f652698f8..8305bbd2a4d7 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -280,7 +280,18 @@ int rockchip_drm_atomic_commit(struct drm_device *dev,
> {
> struct rockchip_drm_private *private = dev->dev_private;
> struct rockchip_atomic_commit *commit = &private->commit;
> - int ret;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i, ret;
> +
> + if (async) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc->state->event ||
> + rockchip_drm_crtc_has_pending_event(crtc)) {
> + return -EBUSY;
> + }
> + }
> + }
Hmmm ...
Doesn't this trigger before the VOP atomic_begin() helper, meaning
that anything with an event set will trigger the check? Seems like it
should be && rather than ||.
Also, I know rockchip_drm_vop.c isn't holding dev->event_lock when it
checks vop->event, but it really should be ... and so should this
check. Otherwise you can race with the IRQ handler, which isn't
required to hold the CRTC lock.
Cheers,
Daniel
Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt
Hi, On 21 November 2015 at 14:22, Christian König wrote: > On 20.11.2015 16:52, cp...@redhat.com wrote: >> This is somewhat rare on most cards (depending on what angle you plug >> the DVI connector in), but on some cards it happens constantly. The >> Radeon R5 on the machine used for testing this patch for instance, runs >> into this issue just about every time I try to hotplug a DVI monitor and >> as a result hotplugging almost never works. >> >> Rescheduling the hotplug work for a second when we run into an HPD >> signal with a failing DDC probe usually gives enough time for the rest >> of the connector's pins to make contact, and fixes this issue. >> >> Signed-off-by: Stephen Chandler Paul > > > Yeah, that's something I always wondered a about bit as well. > > Debouncing is something very common done in electronics, but as far as I > know the HPD pins don't necessary have an RC circuit so we might need to > handle this case in software here. > > A delay of something between 10-30ms between the last HPD interrupt and > further processing of the signal doesn't sounds like such a bad idea. > > Retrying on the other hand doesn't necessarily improve the situation cause > the delay introduced by this might not be enough. > > So I would rather vote for a fixed delay between an HPD interrupt and > actually starting to process anything. Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. those on marginal power) which send you HPD storms as well. But DP relies on 'short HPD' pulses which can be as brief as 2ms. So attempting to totally debounce all HPD won't work. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/8] Add New DRM Driver for Hisilicon's Hi6220 SoC
Hi Xinwei, Thanks for this contribution! We look forward to seeing support for these devices. This isn't an exhaustive review, but two very high-level comments which should result in a lot of changes ... On 15 September 2015 at 10:37, Xinwei Kong wrote: > 1. Hardware Detail > The display subsystem of Hi6220 SoC is shown as bellow: > +-+ +--+ +-+ +-+ > | | | | | | | | > | FB |-->| ADE|>| DSI |>| External| > | | | | | | | HDMI | > +-+ +--+ +-+ +-+ > > - ADE(Advanced Display Engine) is the display controller. It contains 7 > channels or pipes, 3 overlay and a LDI. > - A channel/pipe looks like: DMA-->clip-->scale-->ctrans/csc. > - Overlay is response to compose planes which come from 7 channels and > pass composed image to LDI. This terminology is backwards from what we usually use in DRM, where an overlay is a special case of DRM planes, and pipes are DRM CRTCs. > - LDI is response to generate timings and RGB data stream. > - DSI converts the RGB data stream from ADE to DSI packets. > - External HDMI module is connected with DSI bus. Now Hikey use a ADI's > ADV7533 external HDMI chip. So this is basically just an implementation detail of DSI? > 2. Software Detail > About the software organization and implementation detail: > We have a main drm platform driver (hisi_drm_drv.c), ade platform driver > (hisi_ade.c) and a dsi platform driver (hisi_drm_dsi.c). Ade driver > implements the plane and crtc driver interfaces and dsi implements the > encoder and connector driver interfaces. We take advantage of component > framework to initialize each driver. > In order to support multi coming Hisilicon's SoCs, we plan to separate > common driver code and SoC specific implemented code as possiple as we can. > We abstract an ops for each component(crtc, plane, encoder and connector) > to reuse the common interface implementation logic (FIXME: Not sure if we > can achieve this target and if it is good or not). Thus, we put these > common driver code into hisi_drm_drv/crtc/plane/encoder/connector.c files. Please do not do this; in general, the abstraction layers cause more problems than they create. We have only just finished removing all the abstraction layers from drivers/gpu/drm/exynos/, which started off with exactly the same idea, but only created problems. The issue is that every time the DRM core interface changes, you have to make the exact same changes in your copies of the interface. In general, there seems to be no benefit to having these here: you can just assign the DRM functions directly according to generation. See current Exynos for an example of this. The biggest issue though, is that this driver should become an atomic modesetting driver. Atomic modesetting, rather than sending small individual commands (enable CRTC, change plane position, etc) is based on validating and passing around complete sets of hardware state. Daniel Vetter's blog has an article on how to convert your driver: http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html In addition, there are some drivers converted already that you can look at: tegra (very simple), exynos (reasonably simple), fsl-dcu (moderate), msm (quite complex), i915 (incredibly complex), rcar-du (???). Once your driver is converted to atomic and the abstraction layers removed, then it will be much easier to review the submission in detail. Thanks very much! Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drm: Improve drm_of_component_probe() to correctly handle ports and remote ports.
On 16 November 2015 at 17:22, Russell King - ARM Linux wrote: > Please sensibly wrap your messages. Your lines are longer than 80 > characters which makes it exceedingly difficult for some people to reply > to your very very very very very very very very very very very very > very very very very very very very very very very very very very very > very very very very very very very very very very very very very very > very very very very very very very very very very very very very very > very very very very very very very very very very very very very very > very very very very very very long lines without first reformatting > them manually - and why should they bother to reply if they have that > kind of additional work? Thanks. His lines are wrapped mostly at 80, but sometimes at 86, characters. You should probably look into fixing your MUA. Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] drm: Improve drm_of_component_probe() to correctly handle ports and remote ports.
On 16 November 2015 at 17:43, Russell King - ARM Linux wrote: > On Mon, Nov 16, 2015 at 05:32:05PM +0000, Daniel Stone wrote: >> On 16 November 2015 at 17:22, Russell King - ARM Linux >> wrote: >> > Please sensibly wrap your messages. Your lines are longer than 80 >> > characters which makes it exceedingly difficult for some people to reply >> > to your very very very very very very very very very very very very >> > very very very very very very very very very very very very very very >> > very very very very very very very very very very very very very very >> > very very very very very very very very very very very very very very >> > very very very very very very very very very very very very very very >> > very very very very very very long lines without first reformatting >> > them manually - and why should they bother to reply if they have that >> > kind of additional work? Thanks. >> >> His lines are wrapped mostly at 80, but sometimes at 86, characters. >> You should probably look into fixing your MUA. > > No. > > Standard net etiquette is that email should be wrapped around 72 > characters to give space for reply indentation to remain readable > on an 80 column screen. Most of my email replies are written on an > 80 column screen. Oh, I just thought there was a greater reason for your 660-character tantrum than someone overshooting by 14 characters on a couple of lines. Then again, having read the rest of the pointlessly hostile mail, it's entirely in keeping with the rest. Shame that your needless aggression obscures a fairly valid point. Have a lovely even ing . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Wed, 16 Jan 2019 at 16:06, h...@lst.de wrote: > On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote: > > To summarize once more: We have an array of struct pages and want to > > coherently map that to a device. > > And the answer to that is very simple: you can't. What is so hard > to understand about? If you want to map arbitrary memory it simply > can't be done in a coherent way on about half of our platforms. > > > If that is not possible because of whatever reason we want to get an > > error code or even not load the driver from the beginning. > > That is a bullshit attitude. Just like everyone else makes their > drivers work you should not be lazy. Can you not talk to people like that? Even if you think that is an OK way to treat anyone - which it isn't, certainly not on dri-devel@ with the fd.o Code of Conduct, and not according to the kernel's either - I have absolutely no idea how you can look at the work the AMD people have put in over many years and conclude that they're 'lazy'. If this makes you so angry, step back from the keyboard for a few minutes, and if you still can't participate in reasonable discussion like an adult, maybe step out of the thread entirely.
Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays
Hi Tomi, On 20 April 2018 at 08:09, Tomi Valkeinen wrote: > It's actually not quite clear to me how manual update displays work with > DRM... > > As far as I see, we have essentially two cases: 1) single buffering, > where the userspace must set an area in the fb dirty, which then > triggers the update, 2) multi buffering, which doesn't need fb dirty, > but just a page flip which triggers the update. > > In the 2) case (which I think is the optimal case which all the modern > apps should use), there's no need for delayed work or any work, and the > code flow should be very similar to the auto-update model. Correct. There's been talk (and I think patches?) of adding a per-plane dirty property, so userspace can as an optimisation inform the kernel of the area changed between frames. But short of that, a pageflip needs to trigger a full-plane update, with no dirtyfb required. Cheers, Daniel
Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays
Hi Tony! On 20 April 2018 at 15:25, Tony Lindgren wrote: > * Daniel Stone [180420 10:21]: >> On 20 April 2018 at 08:09, Tomi Valkeinen wrote: >> > It's actually not quite clear to me how manual update displays work with >> > DRM... >> > >> > As far as I see, we have essentially two cases: 1) single buffering, >> > where the userspace must set an area in the fb dirty, which then >> > triggers the update, 2) multi buffering, which doesn't need fb dirty, >> > but just a page flip which triggers the update. >> > >> > In the 2) case (which I think is the optimal case which all the modern >> > apps should use), there's no need for delayed work or any work, and the >> > code flow should be very similar to the auto-update model. >> >> Correct. There's been talk (and I think patches?) of adding a >> per-plane dirty property, so userspace can as an optimisation inform >> the kernel of the area changed between frames. But short of that, a >> pageflip needs to trigger a full-plane update, with no dirtyfb >> required. > > For per-plane dirty property patches, which ones do you refer to? Here's the latest iteration of that series: https://lists.freedesktop.org/archives/dri-devel/2018-April/171900.html <1522885748-67122-1-git-send-email-dra...@vmware.com> > Then for xorg, there's my second attempt on fixing the command mode > rotation at [0]. Not sure if that's enough for a fix? > > It seems not very efficient to me and I don't really know where > the the per crtc dirty flag should be stored.. I try to deny all knowledge of X11 these days, I'm afraid. Cheers, Daniel
Re: [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything
Hi, On 5 January 2017 at 08:52, Daniel Vetter wrote: > On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote: >> No matter what we do here, the question remains what to do with >> Chamelium. Changing the color range is really a workaround for >> Chamelium, not a fix. Using CEA range is perfectly fine per DP spec. > > Can we just set a non-CEA mode/edid for chamelium, problem solved? We want > to do that anyway for HDMI, where you really have to do the limited range > dance to make stuff display correctly. Or, if you set the 'Broadcast RGB' connector property to 'Full', you'll never hit the color_range_auto branch in the first place ... Cheers, Daniel
Re: [RFC] [GPU][DRM][PROPERTY] -Added a new ioctl in Linux DRM KMS driver.
Hi Satendra, On 20 January 2017 at 08:12, Satendra Singh Thakur wrote: > -Added a new ioctl in Linux DRM KMS driver. > This ioctl allows user to set the values of an object’s multiple > properties in one go. > -In the absence of such ioctl, User would be calling one ioctl to set each > property value; > Thus, user needs to call N ioctls to set values of N properties of an > object, which is a time consuming and costly because each ioctl involves > a system call entering/exiting kernel (context switch). > -This ioctl will set N properties (provided that HW allows it) > in a single context switch > -This ioctl can be used to set multiple properties of ether a plane > or a crtc or a connector (i.e. single object ) > -This ioctl can't be used to set one property of a plane and > one property of crtc in one go. The atomic API already exists to set multiple properties at once, and has the advantage of being, well, atomic. The API you propose duplicates atomic, but it also has the possibility of only half-succeeding, leaving the device in a strange halfway state which is not what the user intended. Cheers, Daniel
Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats
Hi all, On 2 January 2017 at 13:03, ayaka wrote: > On 01/02/2017 07:07 PM, Sakari Ailus wrote: >> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote: >>> On 01/02/2017 05:10 PM, Sakari Ailus wrote: If the format resembles the existing formats but on a different bit depth, it should be named in similar fashion. >>> >>> Do you mean it would be better if it is called as NV12_10? >> >> If it otherwise resembles NV12 but just has 10 bits per pixel, I think >> NV12_10 is a good name for it. > > The main reason I don't like it is that there is a various of software > having used the P010 for this kind of pixel format. It would leadi a > conflict between them(and I never saw it is used as NV12_10), as the P010 is > more common to be used. Indeed; GStreamer, FFmpeg and Microsoft all call this P010: https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx fourcc.org is supposed to reflect Microsoft's registry, but seems to not be actively maintained anymore. Cheers, Daniel
Re: [PATCH 1/2] drm_fourcc: Add new P010 video format
Hi Randy,
On 2 January 2017 at 09:50, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> per channel video format. Rockchip's vop support this
> video format(little endian only) as the input video format.
>
> Signed-off-by: Randy Li
> ---
> include/uapi/drm/drm_fourcc.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7f..d2721da 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -119,6 +119,7 @@ extern "C" {
> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /*
> 2x1 subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /*
> 2x2 subsampled Cr:Cb plane 10 bits per channel */
Thanks, this looks good, but I have two requests. Firstly, the
Microsoft page here also mentions that P016 is a preferred format
along P010, so please add P016 as well:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx
I don't see much use of the other (P21x/P41x/Yxxx) formats defined
there, so there's probably no use going wild and adding them just yet.
Secondly, please update the format_info table in drm_fourcc.c for
these two formats, to avoid throwing a WARN_ON every time they are
used.
Cheers,
Daniel
Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format
Hi Randy,
On 4 January 2017 at 16:29, Randy Li wrote:
> index 90d2cc8..23c8e99 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> + /* FIXME a pixel in Y for P010 is 10 bits */
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
It seems like P010 stores each Y component in a 16-bit value, with the
bottom 6 bits ignored. So I think cpp here should be 2.
Cheers,
Daniel
Re: linux-next: problems fetching the drm-intel, etc trees
Hi Stephen, On 1 December 2016 at 20:45, Stephen Rothwell wrote: > On Thu, 01 Dec 2016 11:02:26 +0000 Daniel Stone wrote: >> Sorry about this, it is quite bad. I think having mirrors for the key DRM >> trees on GitHub is a good idea though, and I can get to setting that up. >> Stephen, you need DRM (airlied), drm-misc, drm-panel, drm-intel, drm-tegra, >> drm-exynos and drm-msm, right? > > Well, here are the trees I fetch from *.freedesktop.org: > > [...] > > I did not have any trouble with the people.fd.o ones. That's actually interesting, given that they lie on the same host. Perhaps it means that the locally-mounted ones were fine, and it was the NFS (cough) mount between git/anongit which took a dive ... thanks for the datapoint! Cheers, Daniel
Re: [PATCH] drm/vc4: Fix race between page flip completion event and clean-up
On 28 November 2016 at 22:31, Eric Anholt wrote: > There was a small window where a userspace program could submit > a pageflip after receiving a pageflip completion event yet still > receive EBUSY. > > Signed-off-by: Derek Foreman > Signed-off-by: Eric Anholt > Reviewed-by: Eric Anholt Reviewed-by: Daniel Stone
