Fwd: Very odd memory behavior. Is this normal?
(Resending in plain-text mode) Hi Shaun, just a user here, with a little android-kernel related experience who also likes to tinker with the desktop kernel :) Have you given the following patchset a try yet: http://linux-kernel.2935.n7.nabble.com/patch-v2-0-3-mm-improve-page-aging-fairness-between-zones-nodes-td696105.html Not exactly sure if it addresses your problems but it improves performance for me and other desktop users Regards Matt -- 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: Very odd memory behavior. Is this normal?
On Thu, Oct 10, 2013 at 8:57 PM, Shaun Thomas wrote: >> just a user here, with a little android-kernel related experience who >> also likes to tinker with the desktop kernel :) >> >> Have you given the following patchset a try yet: >> >> http://linux-kernel.2935.n7.nabble.com/patch-v2-0-3-mm-improve- >> page-aging-fairness-between-zones-nodes-td696105.html > > Holy cow, that looks extremely promising. What version of the kernel is this > compatible with? It looks like 3.11, but I'm not sure. > > Thanks! > > -- > Shaun Thomas > OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 > 312-676-8870 > stho...@optionshouse.com > > CC'ing: Johannes Weiner I started using it with a 3.10 kernel (V1, V2) and now have it applied against a heavily modified 3.11 kernel (V2). So I can't say anything whether it'll work with older versions of the kernel but the following: it's "stable" material which needs backporting to the longterm kernels ;) Glad if I can be of help Matt -- 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/
3.10-rc4: mtrr_cleanup: can not find optimal value, please specify mtrr_gran_size/mtrr_chunk_size
cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 64M chunk_size: 2G num_reg: 5 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 128M chunk_size: 128M num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 128M chunk_size: 256M num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 128M chunk_size: 512M num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 128M chunk_size: 1G num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 128M chunk_size: 2G num_reg: 5 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 256M chunk_size: 256M num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 256M chunk_size: 512M num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 256M chunk_size: 1G num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 256M chunk_size: 2G num_reg: 5 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 512M chunk_size: 512M num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 512M chunk_size: 1G num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 512M chunk_size: 2G num_reg: 5 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 1G chunk_size: 1G num_reg: 4 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] *BAD*gran_size: 1G chunk_size: 2G num_reg: 5 lose cover RAM: -0G Jun 5 00:20:47 localhost kernel: [0.00] gran_size: 2G chunk_size: 2G num_reg: 2 lose cover RAM: 2G Jun 5 00:20:47 localhost kernel: [0.00] mtrr_cleanup: can not find optimal value Jun 5 00:20:47 localhost kernel: [0.00] please specify mtrr_gran_size/mtrr_chunk_size Is this some kind of kernel BUG due to the negative value (- 0G) ? MTRR seems to be a topic that is not widely discussed or thoroughly understood when using google to find answers. cat /proc/mtrr reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back reg01: base=0x2 ( 8192MB), size= 1024MB, count=1: write-back reg02: base=0x0c000 ( 3072MB), size= 1024MB, count=1: uncachable Many thanks in advance Kind Regards Matt P.S.: I'm not subscribed to the list so please CC me when needed -- 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: 3.10-rc4: mtrr_cleanup: can not find optimal value, please specify mtrr_gran_size/mtrr_chunk_size
Hi Sergey, Hi List, Hi Yinghai Lu, the following patches http://marc.info/?l=linux-kernel&m=137080807327118&w=2 http://marc.info/?l=linux-kernel&m=137080805927115&w=2 "fixed" it for me and it works again meanwhile I also tried out 3.9.5 & 3.8.13 and I got the same "BAD" result on 3.9.5 whereas with 3.8.13 it worked fine result of 3.10-rc5 + patches: [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D3FFF write-protect [0.00] D4000-D uncachable [0.00] E-E3FFF write-protect [0.00] E4000-E7FFF write-through [0.00] E8000-EBFFF write-protect [0.00] EC000-E write-through [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask E write-back [0.00] 1 base 2 mask FC000 write-back [0.00] 2 base 0C000 mask FC000 uncachable [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] original variable MTRRs [0.00] reg 0, base: 0GB, range: 8GB, type WB [0.00] reg 1, base: 8GB, range: 1GB, type WB [0.00] reg 2, base: 3GB, range: 1GB, type UC [0.00] total RAM covered: 8192M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 64K num_reg: 4 lose cover RAM: 0G [0.00] New variable MTRRs [0.00] reg 0, base: 0GB, range: 2GB, type WB [0.00] reg 1, base: 2GB, range: 1GB, type WB [0.00] reg 2, base: 4GB, range: 4GB, type WB [0.00] reg 3, base: 8GB, range: 1GB, type WB cat /proc/mtrr reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back reg03: base=0x2 ( 8192MB), size= 1024MB, count=1: write-back reg04: base=0x0d000 ( 3328MB), size= 256MB, count=1: write-combining which is the same like on 3.8.13 Thanks ! Matt On Mon, Jun 10, 2013 at 12:01 PM, Sergey Meirovich wrote: > Hi, > > On 5 June 2013 02:08, Matt wrote: >> Hi everyone, >> >> >> I noticed today the following error messages in /var/log/kern.log : >> >> >> Jun 5 00:26:48 localhost kernel: [0.00] MTRR default type: >> uncachable >> Jun 5 00:26:48 localhost kernel: [0.00] MTRR fixed ranges enabled: >> Jun 5 00:26:48 localhost kernel: [0.00] 0-9 write-back >> Jun 5 00:26:48 localhost kernel: [0.00] A-B uncachable >> Jun 5 00:26:48 localhost kernel: [0.00] C-D3FFF write-protect >> Jun 5 00:26:48 localhost kernel: [0.00] D4000-D uncachable >> Jun 5 00:26:48 localhost kernel: [0.00] E-E3FFF write-protect >> Jun 5 00:26:48 localhost kernel: [0.00] E4000-E7FFF write-through >> Jun 5 00:26:48 localhost kernel: [0.00] E8000-EBFFF write-protect >> Jun 5 00:26:48 localhost kernel: [0.00] EC000-E write-through >> Jun 5 00:26:48 localhost kernel: [0.00] F-F write-protect >> Jun 5 00:26:48 localhost kernel: [0.00] MTRR variable ranges >> enabled: >> Jun 5 00:26:48 localhost kernel: [0.00] 0 base 0 >> mask E write-back >> Jun 5 00:26:48 localhost kernel: [0.00] 1 base 2 >> mask FC000 write-back >> Jun 5 00:26:48 localhost kernel: [0.00] 2 base 0C000 >> mask FC000 uncachable >> Jun 5 00:26:48 localhost kernel: [0.00] 3 disabled >> Jun 5 00:26:48 localhost kernel: [0.00] 4 disabled >> Jun 5 00:26:48 localhost kernel: [0.00] 5 disabled >> Jun 5 00:26:48 localhost kernel: [0.00] 6 disabled >> Jun 5 00:26:48 localhost kernel: [0.00] 7 disabled >> Jun 5 00:26:48 localhost kernel: [0.00] x86 PAT enabled: cpu >> 0, old 0x7040600070406, new 0x7010600070106 >> Jun 5 00:26:48 localhost kernel: [0.00] original variable MTRRs >> Jun 5 00:26:48 localhost kernel: [0.00] reg 0, base: 0GB, >> range: 8GB, type WB >> Jun 5 00:26:48 localhost kernel: [0.00] reg 1, base: 8GB, >> range: 1GB, type WB >> Jun 5 00:26:48 localhost kernel: [0.00] reg 2, base: 3GB, >> range: 1GB, type UC >> Jun 5 00:26:48 localhost kernel: [0.00] total RAM covered: 8192M >> Jun 5 00:26:48 localhost kernel: [0.000
ioctl arg passing
Righto, first post to the list, here goes:
I'm writing a char device driver for a dsp card that drives a motion
platform. The basic flow is I basically have to reset the card and upload
an executable file to it, and then poke the card to run it. Once this is
done, I can issue instructions to the card/code to pass and return data
from the card about the platform it's controlling.
To pass the instructions I'm using a generic ioctl which passes the data
between user & kernel-space using a struct which is basically like:
struct instruction_t {
__s16 code;
__s16 rxlen;
__s16 *rxbuf;
__s16 txlen;
__s16 *txbuf;
};
(rx|tx)len is the length of the extra data that is provided/requested
in/to be in (rx|tx)buf. Got me so far?
Am I allowed to do this across the ioctl interface? In my ioctl
"handler" I'm attempting to do:
--8<--
struct instruction_t local;
__s16 *temp;
copy_from_user( &local, ( struct instruction_t * ) arg, sizeof( struct instruction_t )
);
temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL );
copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen );
local.rxbuf = temp;
temp = kmalloc( sizeof( __s16 ) * local.txlen, GFP_KERNEL );
...
--8<--
Is this going to work as expected? Or am I gonna generate oops-a-plenty?
Cheers
Matt
-
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: ioctl arg passing
Matt aka Doofus festures mentioned the following: | struct instruction_t local; | __s16 *temp; | | copy_from_user( &local, ( struct instruction_t * ) arg, sizeof( struct instruction_t |) ); | temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL ); | copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen ); I meant that last line to be: copy_from_user( temp, local.rxbuf, sizeof( __s16 ) * local.rxlen ); ^^^ Which'd clear up any confusion as to why I'd want two copies of the same argument. That's the main crux of my query, can I retrieve the value of a pointer in some struct passed via ioctl? In this case, the struct/chunk of memory referenced by local.rxbuf, (which is rxlen x 2 bytes big). Apologies, I'm a muppet. Matt PS. Thanks for the help so far, I'd meant to add error checking and what not, I just kept it out to keep the e-mail smaller. - 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: ioctl arg passing
Ingo Oeser mentioned the following: | On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote: | > I'm writing a char device driver for a dsp card that drives a motion | > platform. | | Can you elaborate on the dsp card? Is it freely programmable? I'm | working on a project to support this kind of stuff via a | dedicated subsystem for Linux. AFAIK the card could be used for all sorts, but I'm not terribly knowledgable about it as I've only been told how to program the thing with respect to it's chosen application, ie. to drive the platform. It's got analog and digital inputs/outputs, I don't know what else. I'm writing this driver as part of my final year project at University, and I'm working from the existing Windows code, so I'm not really exposed to the cards internals at all. The card is solely accessed through four consecutive I/O port address, the first two control the address of ram on the card I want, and I read or write to the second two. All accesses are 16-bit wide. That's as much as I know really. | The problem is, that it's hard to get access to such cards. So | development is moving very slow :-( My other problem is that I only have three/four weeks left to do as much as possible, I've just managed to get my head 'round the Windows code so I know how the code works, without having to fit it into some other grand scheme of things. I did try to write the driver with respect to making it nice and modular, but without another card I can't work out what might be common to both etc. Once I've written the driver, I might be able to help merge it into some other system, but atm my prority is to get it working as it is, so I can at least get a good mark, I don't think I'm doing it a bad way, it's just based heavily in structure on the existing Windows code. Cheers Matt - 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: ioctl arg passing
rui.sousa mentioned the following: | On Mon, 23 Apr 2001, Ingo Oeser wrote: | | > Can you elaborate on the dsp card? Is it freely programmable? I'm | > working on a project to support this kind of stuff via a | > dedicated subsystem for Linux. | | Very interesting... The emu10k1 driver (SBLive!) that will appear | shortly in acXX will support loading code to it's DSP. It's a very | simple chip with only 16 instructions but it can generate | hardware interrupts, DMA to host memory, 32 bit math. The maximum | program size is 512 instructions (64 bits each) and can make use of 256 | registers (32 bits). | | Is there a web page for your project? I haven't got one for my Linux port, but the company is Motionbase, http://www.motionbase.com/, which at least has some piccy's of the hardware in action. (Unless you meant Ingo's project, oops!) The nature of driver is such that it's "useless" unless you have one of these platforms, so it's not really for the average chap... :) As the card offers analog inputs which are commonly used for joysticks/steering wheels depending on the application being run, I plan to create a joystick abstraction device that pipes the analog inputs through the joystick interface too, so that any software can use joysticks in a standard way regardless of whether they're using the platform or just a regular PC. I'm developing for 2.2.x, but once that's working I'll adapt the code for 2.4.x and use the event interface, devfs etc. where necessary. | > > copy_from_user( &local, ( struct instruction_t * ) arg, sizeof( struct |instruction_t ) ); | > > temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL ); | > > copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen ); | ^^^ local.rxbuf, no ? Yup, that's the one, hopefully everyone except me noticed that one! :) Thanks for the help so far, appreciated. Matt - 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: ioctl arg passing
Matt mentioned the following:
| struct instruction_t {
| __s16 code;
| __s16 rxlen;
| __s16 *rxbuf;
| __s16 txlen;
| __s16 *txbuf;
| };
So far, I now know I can grab stuff across the user <-> kernel divide as I
planned. The only problem I'm left with, which was kindly pointed out to
me, is a question of packing with respect to both kernel & user-space.
Can anyone suggest a method of either assuring the above structure is
always packed the same, or alterations so that the problem is
minimised? Either splitting the one ioctl into many, etc.
Thanks
Matt
-
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/
question about the mount mechanism
While doing a little exploration in the kernel I found something that I thought curious. I would like an explanation of why, at mount time, the kernel is not more verbose to a person from mounting a 'non-clean' files system. Specifically, in /linux/fs/ext2/super.c, line 285 (really this whole section of code) Lets make the assumption that fsck fails for some reason. You're working remotely on the system and thusly have no way to see the console (short of going out of your way to look at the logs after every mount). Lastly, the partition you want to mount was not unmounted cleanly. How do you know you won't damage the partition? What would be the harm in asking for confirmation that, yes, I really do want to mount this potentially damaged partition? Would it make sense to pass a message out to mount and allow it to ask for confirmation? Thanks for any information, Matt Berglund Starting Java ... Killing Netscape. - 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: system call sched_yield() doesn't work on Linux 2.2
mohit, to expect perfect alternation is not reasonable. the scheduler (or one of its subsidiary and/or supporting functions) decides what should run and what shouldn't. the linux scheduler did have problems in 2.2 (and still does in some places). however last i checked sched_yield() is at best a hint to the scheduler not a command. the man page even suggests this. it says that if the process (or thread) yields and if it is the highest priority task at the time it will be re-run. so you can not guarantee that it will not re-run. this i think was the point david was trying to make (albiet with some possibly misplaced "fervour"). however i did notice one small change wrt to SCHED_YIELD semantics from 2.2.18 and 2.4.1-ac1 (one would assume that this change happened during the schedule() re-writes during 2.3.x). xref line 119 of kernel/sched.c in 2.2.18 and xref line 148 of kernel/sched.c in 2.4.1-ac1 in this case you will see that in 2.2.18 a SCHED_YIELD process will get a "goodness" value of 0, however in 2.4.1-ac1 you will find that it gets a value of -1 (and hence a lower scheduling priority). i dont have a machine handy that is running 2.2.18 that i can patch and reboot, how ever you may wish to change the return value on line 119 of kernel/sched.c in 2.2.18 to -1 and you may find that it might give the behaviour you are looking for. it may also cause other problems. caveat emptor and all that.. matt - 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/
[no subject]
subscribe linux-kernel - 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/
Can the kernel access /?
I'm writing a device driver for a DSP card that requires some software loaded onto the card for it to function, currently I'm copying the software to the /dev node and the driver is doing the magic in it's write() handler. Can the driver pull the file from the filesystem if I were to pass the path of the file as an argument on loading the module? I'm not sure it can, but perhaps someone could settle my curiosity and perhaps point me to some code that does this in the kernel? I'm thinking that if it could, things like the P6 Microcode driver would be perhaps done this way too... Cheers Matt - 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/
2.4.x on sparc32
Can anyone tell me the current status of 2.4.x on sparc(32) platforms? I tried 2.4.2 previously which compiled fine, but would lock the machine up loading the kernel after the SILO prompt, (before Tux appears, etc.). I've tried 2.4.4 today, but that won't build as it appears this architecture is missing the pte_alloc_one_fast() definitions and such, (many warnings). My box is an SS IPX (sun4c), PROM 2.9 & currently running 2.2.18 +RAID, which I've been told has been a meddlesome platform in the past. Thanks Matt - 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/
Timers
I'm having some major headaches trying to get a timer working in my driver. The timer is started when the device node is opened, and deleted when it's closed. The timer code itself calls mod_timer to add itself back in again. At the moment, it runs every second and does nothing more than issue a debug printk to say it's working okay. The problem comes when I try and wrap the timer code inside some down() and up() calls to make sure it's not fiddling with the hardware at the same time as some other calls. When I do this, I get a huge oops which goes right off my screen and I get the "Aieee..." message afterwards and I have to push the reset button :(. Should I be using spin_(un)lock_irqsave() calls anywhere instead of just a semaphore? Or is there anything else I should be doing? Cheers Matt - 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: Problems booting 4.1.6
Hi Peter,
does the following patch help:
x86/idle: Restore trace_cpu_idle to mwait_idle() calls
http://marc.info/?l=linux-kernel&m=144009977312088
x86/idle: Restore trace_cpu_idle to mwait_idle() calls
Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.
Add them back to restore the proper behaviour.
Greetings,
Matt
--
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/
linux-3.16.2 queue (3.16.1+)
Hi Greg, please consider adding the following 2 patches to 3.16.2: Jan Kara (1): reiserfs: Fix use after free in journal teardown Jeff Mahoney (1): reiserfs: fix corruption introduced by balance_leaf refactor Reason/Related: https://bugzilla.kernel.org/show_bug.cgi?id=83121 https://bugzilla.kernel.org/show_bug.cgi?id=83321 http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html Many thanks in advance Kind Regards Matt -- 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: linux-3.16.2 queue (3.16.1+)
On Thu, Aug 28, 2014 at 5:22 PM, Greg KH wrote: > On Thu, Aug 28, 2014 at 05:16:58PM +0200, Matt wrote: >> Hi Greg, >> >> >> please consider adding the following 2 patches to 3.16.2: >> >> Jan Kara (1): >> reiserfs: Fix use after free in journal teardown >> >> Jeff Mahoney (1): >> reiserfs: fix corruption introduced by balance_leaf refactor >> >> >> >> Reason/Related: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=83121 >> >> https://bugzilla.kernel.org/show_bug.cgi?id=83321 >> >> http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html >> >> >> Many thanks in advance > > I need git commit ids of these patches in Linus's tree, can you provide > those please? > > thanks, > > greg k-h Sure: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d reiserfs: fix corruption introduced by balance_leaf refactor https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e reiserfs: Fix use after free in journal teardown are checkpatch warnings usually also fixed within stable releases ? if yes: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3fb9e27325c4e1730440820ea8a1e9d9a5af709 fs/reiserfs/xattr.c: fix blank line missing after declarations https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=17093991af4995c4b93f6d8ac63aab68fcd9e1be fs/reiserfs: use linux/uaccess.h https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=53872ed07786714bff3642ee9ee61afd3f4eb749 fs/reiserfs: replace not-standard %Lu/%Ld Greetings Matt -- 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: linux-3.16.2 queue (3.16.1+)
On Thu, Aug 28, 2014 at 5:32 PM, Greg KH wrote: > On Thu, Aug 28, 2014 at 05:27:27PM +0200, Matt wrote: >> On Thu, Aug 28, 2014 at 5:22 PM, Greg KH wrote: >> > On Thu, Aug 28, 2014 at 05:16:58PM +0200, Matt wrote: >> >> Hi Greg, >> >> >> >> >> >> please consider adding the following 2 patches to 3.16.2: >> >> >> >> Jan Kara (1): >> >> reiserfs: Fix use after free in journal teardown >> >> >> >> Jeff Mahoney (1): >> >> reiserfs: fix corruption introduced by balance_leaf refactor >> >> >> >> >> >> >> >> Reason/Related: >> >> >> >> https://bugzilla.kernel.org/show_bug.cgi?id=83121 >> >> >> >> https://bugzilla.kernel.org/show_bug.cgi?id=83321 >> >> >> >> http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html >> >> >> >> >> >> Many thanks in advance >> > >> > I need git commit ids of these patches in Linus's tree, can you provide >> > those please? >> > >> > thanks, >> > >> > greg k-h >> >> >> Sure: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d >> reiserfs: fix corruption introduced by balance_leaf refactor >> >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e >> reiserfs: Fix use after free in journal teardown >> >> >> >> are checkpatch warnings usually also fixed within stable releases ? > > No, not at all, please read Documentation/stable_kernel_patches.txt for > what is acceptable for stable kernel patches. > > thanks, > > greg k-h okay, will do thanks for pointing that out Regards Matt -- 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: slab kmalloc guard patch uncovers potential issue with crypto, triggered by cryptomgr_test
On Wed, Sep 10, 2014 at 4:35 PM, Matt wrote: > Hi Herbert, > Hi David, > > (added maintainers according to https://www.kernel.org/doc/linux/MAINTAINERS) > > Hi crypto ML, > > > running a kernel with Mikulas Patocka's kmalloc guard patch for slab > the following message appears during boot: > > [1.439704] AVX2 version of gcm_enc/dec engaged. > [1.20] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) > [1.449029] kmalloc: red zone damaged, pointer 8807fa48bcc0, > real_size 192, size 160, red zone 8807fa4fccc0 > [1.449033] CPU: 1 PID: 127 Comm: cryptomgr_test Not tainted 3.16.2-test+ > #1 > [1.449034] Hardware name: ASUS All Series/P9D WS, BIOS 1804 04/17/2014 > [1.449036] 829ef90e 8807fa48bcc0 > 8218c799 > [1.449039] 8807fa48bcc0 82186d9f 8807fa48bcc0 > 824a22aa > [1.449042] 0069 008a > 824a18c3 > [1.449044] Call Trace: > [1.449048] [] ? dump_stack+0x4a/0x75 > [1.449052] [] ? ksize+0x9/0x30 > [1.449054] [] ? kzfree+0xf/0x30 > [1.449057] [] ? alg_test_hash+0x4a/0x90 > [1.449059] [] ? alg_test+0x113/0x2b0 > [1.449062] [] ? crypto_unregister_pcomp+0x10/0x10 > [1.449064] [] ? cryptomgr_test+0x38/0x40 > [1.449066] [] ? kthread+0xca/0xe0 > [1.449068] [] ? kthread_create_on_node+0x180/0x180 > [1.449071] [] ? ret_from_fork+0x7c/0xb0 > [1.449072] [] ? kthread_create_on_node+0x180/0x180 > [1.449074] kmalloc: red zone damaged, pointer 8807fa48bcc0, > real_size 192, size 160, red zone 8807fa4fccc0 > [1.449077] CPU: 1 PID: 127 Comm: cryptomgr_test Not tainted 3.16.2-test+ > #1 > [1.449078] Hardware name: ASUS All Series/P9D WS, BIOS 1804 04/17/2014 > [1.449079] 829ef90e 8807fa48bcc0 > 821b5d7f > [1.449082] 8807fa48bcc0 82ac18b8 > 8807fa48bc00 > [1.449084] 8807fa48bc40 824a22aa > > [1.449087] Call Trace: > [1.449088] [] ? dump_stack+0x4a/0x75 > [1.449091] [] ? kfree+0x1f/0x1d0 > [1.449093] [] ? alg_test_hash+0x4a/0x90 > [1.449095] [] ? alg_test+0x113/0x2b0 > [1.449097] [] ? crypto_unregister_pcomp+0x10/0x10 > [1.449099] [] ? cryptomgr_test+0x38/0x40 > [1.449101] [] ? kthread+0xca/0xe0 > [1.449102] [] ? kthread_create_on_node+0x180/0x180 > [1.449104] [] ? ret_from_fork+0x7c/0xb0 > [1.449106] [] ? kthread_create_on_node+0x180/0x180 > [1.449138] sha1_ssse3: Using AVX2 optimized SHA-1 implementation > [1.449182] alg: No test for crc32 (crc32-pclmul) > [1.449188] sha256_ssse3: Using AVX2 optimized SHA-256 implementation > [1.449262] sha512_ssse3: Using AVX2 optimized SHA-512 implementation > > link to the patch: http://marc.info/?l=linux-kernel&m=140995770121230&w=2 > > > The kernel this appears on only has 2 reiserfs fixes, BFQ, BFS and > this patch added on top: > https://github.com/kernelOfTruth/linux/commits/linux-3.16.2-test > > > Kernel config is attached > > > Kind Regards > > Matt Adding the main Linux Kernel Mailing List for good measure -- 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: linux-3.16.2 queue (3.16.1+)
On Thu, Aug 28, 2014 at 9:18 PM, Matt wrote: > On Thu, Aug 28, 2014 at 5:32 PM, Greg KH wrote: >> On Thu, Aug 28, 2014 at 05:27:27PM +0200, Matt wrote: >>> On Thu, Aug 28, 2014 at 5:22 PM, Greg KH wrote: >>> > On Thu, Aug 28, 2014 at 05:16:58PM +0200, Matt wrote: >>> >> Hi Greg, >>> >> >>> >> >>> >> please consider adding the following 2 patches to 3.16.2: >>> >> >>> >> Jan Kara (1): >>> >> reiserfs: Fix use after free in journal teardown >>> >> >>> >> Jeff Mahoney (1): >>> >> reiserfs: fix corruption introduced by balance_leaf refactor >>> >> >>> >> >>> >> >>> >> Reason/Related: >>> >> >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=83121 >>> >> >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=83321 >>> >> >>> >> http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html >>> >> >>> >> >>> >> Many thanks in advance >>> > >>> > I need git commit ids of these patches in Linus's tree, can you provide >>> > those please? >>> > >>> > thanks, >>> > >>> > greg k-h >>> >>> >>> Sure: >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d >>> reiserfs: fix corruption introduced by balance_leaf refactor >>> >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e >>> reiserfs: Fix use after free in journal teardown >>> >>> >>> >>> are checkpatch warnings usually also fixed within stable releases ? >> >> No, not at all, please read Documentation/stable_kernel_patches.txt for >> what is acceptable for stable kernel patches. >> >> thanks, >> >> greg k-h > > > okay, will do > > thanks for pointing that out > > > Regards > > Matt Hi Greg, could you please add the above mentioned two patches https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d reiserfs: fix corruption introduced by balance_leaf refactor https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e reiserfs: Fix use after free in journal teardown in next stable (3.16.3) kernel ? more and more people seem to be affected by the data corruption introduced by the recent changes. Reading through Documentation/stable_kernel_rules.txt, http://cwe.mitre.org/data/definitions/416.html and http://www.hpenterprisesecurity.com/vulncat/en/vulncat/cpp/use_after_free.html both patches seem relevant enough (concerning data integrity filesystem-wise and security) to be included for the stable branch Thanks & Regards Matt -- 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: Kernel 3.16.0 USB crash
Hi Claudio, this issue is clearly caused by UAS. if zcat /proc/config.gz | grep UAS # CONFIG_USB_UAS is not set is de-selected, everything's fine when this is selected (usb is compiled as a module here) the system crashes or hardlocks as soon as an USB 3.0 capable drive is connected. During bootup the system crashes as soon as the kernel module is loaded. This happened for me with 3.15.6 and 3.16.0 kernel (and 3.16-rc6). I've a different chipset but the symptoms are similar: 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) So the only solution to work with newer kernels right now is to de-select that option and re-compile the kernel. It doesn't help fix the problem but at least it mitigates the issues for now (crash). Regards Matt -- 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: Kernel 3.16.0 USB crash
On Wed, Aug 13, 2014 at 10:24 PM, Matt wrote: > Hi Claudio, > > this issue is clearly caused by UAS. > > if > > zcat /proc/config.gz | grep UAS > # CONFIG_USB_UAS is not set > > is de-selected, everything's fine > > when this is selected (usb is compiled as a module here) > > the system crashes or hardlocks as soon as an USB 3.0 capable drive is > connected. > > During bootup the system crashes as soon as the kernel module is loaded. > > This happened for me with 3.15.6 and 3.16.0 kernel (and 3.16-rc6). > > I've a different chipset but the symptoms are similar: > > 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > Family USB xHCI (rev 05) > > > So the only solution to work with newer kernels right now is to > de-select that option and re-compile the kernel. It doesn't help fix > the problem but at least it mitigates the issues for now (crash). > > > Regards > > Matt Adding some relevant CCs -- 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: UKSM: What's maintainers think about it?
Hi Timofey, Hi List, don't forget to consider PKSM - it's supposed to be an improvement over UKSM & KSM: http://www.phoronix.com/scan.php?page=news_item&px=MTM0OTQ https://code.google.com/p/pksm/ Kind Regards Matt -- 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: missing MS_RDONLY check in fsync
Hi Sanidhya, you might be interested in the following patch by Richard Yao: http://marc.info/?l=linux-fsdevel&m=141523828324345&w=2 [PATCH v4 1/1] vfs: Respect MS_RDONLY at bind mount creation Regards Matt -- 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/
[regression v4.0-rc1] mm: IPIs from TLB flushes causing significant performance degradation.
Hi Dave, is the following thread and patch related to your problem, I just happened to stumble upon it a few days ago: https://lkml.org/lkml/2014/12/17/280 , http://marc.info/?l=linux-kernel&m=141876582909898&w=2 Re: post-3.18 performance regression in TLB flushing code Linus already posted a fix to the problem, however I can't seem to find the matching commit in his tree (searching for "TLC regression" or "TLB cache"). Kind Regards Matt -- 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: [regression v4.0-rc1] mm: IPIs from TLB flushes causing significant performance degradation.
On Mon, Mar 2, 2015 at 8:25 PM, Dave Hansen wrote: > On 03/02/2015 11:17 AM, Matt wrote: >> Linus already posted a fix to the problem, however I can't seem to >> find the matching commit in his tree (searching for "TLC regression" >> or "TLB cache"). > > It's in 721c21c17ab958abf19a8fc611c3bd4743680e38 iirc. Mea culpa, should have looked at the date of the thread - was just grasping at straws to make an help attempt :/ I'll refrain from posting in this thread then to avoid clutter & load to the list (this is way over my head, I'm mostly doing minor patch porting and custom kernels as a hobby) Kind Regards Matt -- 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/
possible audio regression for usb-audio with 5.3 kernel (5.3.1), sounds like variants of 8-bit audio
Hi Takashi, there appears to be a sound regression for plug-n-play usb-audio DACs with 5.3 kernel. I'm using the following one: https://www.aliexpress.com/item/33012416525.html?spm=a2g0s.9042311.0.0.4f314c4dv3EF0p which includes SA9023A + ES9018K2M on the chip. When listening to parts of the Unreal Tournament 3 soundtrack the output resembles a bit like: https://www.youtube.com/watch?v=9gq4R6acnBQ Rush - Tom Sawyer (8-bit NES audio render) it immediately made me think of 8-bit audio and the NES. First thought of misconfiguration in the kernel config but then went back to 5.2.17-rt9 (copying the config and only enabling full preemption) and there the output is correct and crystal clear. For each kernel build I need to jump through a few hoops (nvidia driver, zfsonlinux modules, luks, genkernel, etc.) so it'll take a while to build and get it up and running. System is: cat /etc/lsb-release DISTRIB_ID="Gentoo" ~amd64 gcc version 9.2.0 (Gentoo Hardened 9.2.0-r1 p2) GNU ld (Gentoo 2.32 p2) 2.32.0 PCIe related sound doesn't seem to be affected (Xonar DX), it works fine both on 5.3.1 and 5.2.17-rt9 Kind Regards Matthew
Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN
On 2017-04-20 11:19, Serge E. Hallyn wrote: Quoting Matt Brown (m...@nmatt.com): On 04/19/2017 07:53 PM, Serge E. Hallyn wrote: >Quoting Matt Brown (m...@nmatt.com): >>On 04/19/2017 12:58 AM, Serge E. Hallyn wrote: >>>On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote: >>>>This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity >>>>project in-kernel. >>>> >>>>This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding >>>>sysctl kernel.tiocsti_restrict that, when activated, restrict all TIOCSTI >>>>ioctl calls from non CAP_SYS_ADMIN users. >>>> >>>>Possible effects on userland: >>>> >>>>There could be a few user programs that would be effected by this >>>>change. >>>>See: <https://codesearch.debian.net/search?q=ioctl%5C%28.*TIOCSTI> >>>>notable programs are: agetty, csh, xemacs and tcsh >>>> >>>>However, I still believe that this change is worth it given that the >>>>Kconfig defaults to n. This will be a feature that is turned on for the >>> >>>It's not worthless, but note that for instance before this was fixed >>>in lxc, this patch would not have helped with escapes from privileged >>>containers. >>> >> >>I assume you are talking about this CVE: >>https://bugzilla.redhat.com/show_bug.cgi?id=1411256 >> >>In retrospect, is there any way that an escape from a privileged >>container with the this bug could have been prevented? > >I don't know, that's what I was probing for. Detecting that the pgrp >or session - heck, the pid namespace - has changed would seem like a >good indicator that it shouldn't be able to push. > pgrp and session won't do because in the case we are discussing current->signal->tty is the same as tty. This is the current check that is already in place: | if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN)) | return -EPERM; Yeah... The only thing I could find to detect the tty message coming from a container is as follows: | task_active_pid_ns(current)->level This will be zero when run on the host, but 1 when run inside a container. However this is very much a hack and could probably break some userland stuff where there are multiple levels of namespaces. Yes. This is also however why I don't like the current patch, because capable() will never be true in a container, so nested containers break. What do you mean by "capable() will never be true in a container"? My understanding is that if a container is given CAP_SYS_ADMIN then capable(CAP_SYS_ADMIN) will return true? I agree the hack I mentioned above would be a bad idea because it would break nested containers, but the current patch would not IMO. A better version of the hack could involve a config CONFIG_TIOCSTI_MAX_NS_LEVEL where a check would be performed to ensure that task_active_pid_ns(current)->level is not greater than the config value(an integer that is >= 0) . Again, I think we both would agree that this is not the best solution. The clear downside is that you could have multiple container layers where the desired security boundaries happened to fall at different levels. Just throwing ideas around. What does current->signal->tty->pgrp actually point to? Can we take it to be the pgrp which opened it? Could we check ns_capable(current_pid_ns()->user_ns, CAP_whatever) and get a meaningful answer? The real problem is that there are no TTY namespaces. I don't think we can solve this problem for CAP_SYS_ADMIN containers unless we want to introduce a config that allows one to override normal CAP_SYS_ADMIN functionality by denying TIOCSTI ioctls for processes whom task_active_pid_ns(current)->level is equal to 0. In the mean time, I think we can go ahead with this feature to give people the ability to lock down non CAP_SYS_ADMIN containers/processes. >>>>same reason that people activate it when using grsecurity. Users of this >>>>opt-in feature will realize that they are choosing security over some OS >>>>features like unprivileged TIOCSTI ioctls, as should be clear in the >>>>Kconfig help message. >>>> >>>>Threat Model/Patch Rational: >>>> >>>>>From grsecurity's config for GRKERNSEC_HARDEN_TTY. >>>> >>>>| There are very few legitimate uses for this functionality and it >>>>| has made vulnerabilities in several 'su'-like programs possible in >>>>| the past. Even without these vulnerabilities, it provides an >>>>| attacker with an easy mec
Re: [PATCH] efivarfs: fix abnormal GUID in variable name by using strcpy to replace null with dash
On 03/11/2013 01:17 PM, joeyli wrote:
> Sorry for after I wrote patch, I think it's better we still use your
> original patch to fix this bug, because I found the
> efi_variable->VariableName allocated 1024 size and it also used by old
> vars system.
>
> The following is my patch for reference, but I think your original patch
> is better for backward compatible on variable name.
>
> Please consider to merge your original patch!
OK, this is what I've got queued up (note I removed the warning).
---
>From afa9ae7bf47145d661487f88f2ec67b062ca98bc Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Fri, 1 Mar 2013 14:49:12 +
Subject: [PATCH] efivars: explicitly calculate length of VariableName
It's not wise to assume VariableNameSize represents the length of
VariableName, as not all firmware updates VariableNameSize in the same
way (some don't update it at all if EFI_SUCCESS is returned). There
are even implementations out there that update VariableNameSize with
values that are both larger than the string returned in VariableName
and smaller than the buffer passed to GetNextVariableName(), which
resulted in the following bug report from Michael Schroeder,
> On HP z220 system (firmware version 1.54), some EFI variables are
> incorrectly named :
>
> ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns
> /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
> /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
> /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
>
/sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8c
The issue here is that because we blindly use VariableNameSize without
verifying its value, we can potentially read garbage values from the
buffer containing VariableName if VariableNameSize is larger than the
length of VariableName.
Since VariableName is a string, we can calculate its size by searching
for the terminating NULL character.
Reported-by: Frederic Crozat
Cc: Matthew Garrett
Cc: Josh Boyer
Cc: Michael Schroeder
Cc: Lee, Chun-Yi
Cc: Lingzhu Xiang
Cc: Seiji Aguchi
Signed-off-by: Matt Fleming
---
drivers/firmware/efivars.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index d90b061..ae26d5e 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -1704,6 +1704,31 @@ static bool variable_is_present(efi_char16_t
*variable_name, efi_guid_t *vendor)
return found;
}
+/*
+ * Returns the size of variable_name, in bytes, including the
+ * terminating NULL character, or variable_name_size if no NULL
+ * character is found among the first variable_name_size bytes.
+ */
+static unsigned long var_name_strnsize(efi_char16_t *variable_name,
+ unsigned long variable_name_size)
+{
+ unsigned long len;
+ efi_char16_t c;
+
+ /*
+* The variable name is, by definition, a NULL-terminated
+* string, so make absolutely sure that variable_name_size is
+* the value we expect it to be. If not, return the real size.
+*/
+ for (len = 2; len <= variable_name_size; len += sizeof(c)) {
+ c = variable_name[(len / sizeof(c)) - 1];
+ if (!c)
+ break;
+ }
+
+ return min(len, variable_name_size);
+}
+
static void efivar_update_sysfs_entries(struct work_struct *work)
{
struct efivars *efivars = &__efivars;
@@ -1744,10 +1769,13 @@ static void efivar_update_sysfs_entries(struct
work_struct *work)
if (!found) {
kfree(variable_name);
break;
- } else
+ } else {
+ variable_name_size = var_name_strnsize(variable_name,
+
variable_name_size);
efivar_create_sysfs_entry(efivars,
variable_name_size,
variable_name, &vendor);
+ }
}
}
@@ -1994,6 +2022,8 @@ int register_efivars(struct efivars *efivars,
&vendor_guid);
switch (status) {
case EFI_SUCCESS:
+ variable_name_size = var_name_strnsize(variable_name,
+
variable_name_size);
efivar_create_sysfs_entry(efivars,
variable_name_size,
variable_name,
--
1.7.11.7
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: se
Re: [ 41/75] ARM: davinci: edma: fix dmaengine induced null pointer dereference on da830
On Tue, Mar 19, 2013 at 04:25:35PM +, Luis Henriques wrote:
> On Mon, Mar 18, 2013 at 02:07:04PM -0700, Greg Kroah-Hartman wrote:
> > 3.8-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Matt Porter
> >
> > commit 069552777a121eb39da29de4bc0383483dbe1f7e upstream.
> >
> > This adds additional error checking to the private edma api implementation
> > to catch the case where the edma_alloc_slot() has an invalid controller
> > parameter. The edma dmaengine wrapper driver relies on this condition
> > being handled in order to avoid setting up a second edma dmaengine
> > instance on DA830.
> >
> > Verfied using a DA850 with the second EDMA controller platform instance
> > removed to simulate a DA830 which only has a single EDMA controller.
> >
> > Reported-by: Tomas Novotny
> > Signed-off-by: Matt Porter
> > Tested-by: Tomas Novotny
> > Signed-off-by: Sekhar Nori
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > arch/arm/mach-davinci/dma.c |3 +++
> > 1 file changed, 3 insertions(+)
> >
> > --- a/arch/arm/mach-davinci/dma.c
> > +++ b/arch/arm/mach-davinci/dma.c
> > @@ -743,6 +743,9 @@ EXPORT_SYMBOL(edma_free_channel);
> > */
> > int edma_alloc_slot(unsigned ctlr, int slot)
> > {
> > + if (!edma_cc[ctlr])
> > + return -EINVAL;
> > +
> > if (slot >= 0)
> > slot = EDMA_CHAN_SLOT(slot);
>
> I couldn't figure out the reason why this is tagged for v3.7.x+ only.
> Shouldn't this be applied to 3.2, 3.4 and 3.5 as well?
The bug being fixed is triggered by the edma dmaengine driver (and only
on one board) that was introduced in 3.7. Prior to that it is just a
theoretical bug.
-Matt
--
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] x86/efi: pull NV+BS variables out before we exit boot services
pa_data = s_d->next) {
> + struct efi_setup_bootvars *bvs;
> + efi_char16_t *bvs_name;
> + int i = 0;
> +
> + s_d = phys_to_virt(pa_data);
> +
> + if (s_d->type != SETUP_EFIVAR)
> + continue;
> +
> + bvs = (struct efi_setup_bootvars *)s_d;
> + bvs_name = (efi_char16_t *)(bvs->data + bvs->size);
> +
> + for (i = 0; bvs_name[i] != 0 && name[i] != 0; i++)
> + if (bvs_name[i] != name[i])
> + break;
> +
> + if (bvs_name[i] != 0 || name[i] != 0)
> + continue;
> +
This would be cleaner if you pulled some of the utf16_str* functions out
of drivers/firmware/efivars.c and stuck them in include/linux/efi.h.
Then you could do something like,
if (utf16_strncmp(bvs_name, name, utf16_strlen(name)) != 0)
continue;
> + if (memcmp(&bvs->guid, vendor, sizeof(*vendor)) != 0)
> + continue;
> +
> + if (attr)
> + *attr = bvs->attributes;
> +
> + if (*data_size < bvs->size) {
> + *data_size = bvs->size;
> + return EFI_BUFFER_TOO_SMALL;
> + }
> + *data_size = bvs->size;
> + memcpy(data, bvs->data, bvs->size);
> +
> + return EFI_SUCCESS;
> + }
> + return EFI_NOT_FOUND;
> }
>
> static efi_status_t virt_efi_get_next_variable(unsigned long *name_size,
> efi_char16_t *name,
> efi_guid_t *vendor)
> {
> - return efi_call_virt3(get_next_variable,
> - name_size, name, vendor);
> + static int use_bootvars = 0;
> + efi_status_t status;
> + u64 pa_data = boot_params.hdr.setup_data;
> + int found = 0;
Why not make found a boolean?
--
Matt Fleming, Intel Open Source Technology Center
--
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/
[GIT PULL] EFI changes for v3.9-rc3
Hi guys, The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-for-3.9-rc3 for you to fetch changes up to e971318bbed610e28bb3fde9d548e6aaf0a6b02e: efivars: Handle duplicate names from get_next_variable() (2013-03-21 12:43:46 +) EFI changes for v3.9-rc3, * A new config option and efivars module parameter have been added to allow the efivars pstore backend to be disabled as we're still seeing issues on machines despite adding heuristics to workaround known bugs. Distributions now have a way to disable EFI variable pstore code completely - from Seth Forshee. * A couple of efivars patches to workaround quirky implementations of GetNextVariableName() which resulted in machines hanging and sysfs files being created with garbage names. Matt Fleming (2): efivars: explicitly calculate length of VariableName efivars: Handle duplicate names from get_next_variable() Seth Forshee (2): efivars: Allow disabling use as a pstore backend efivars: Add module parameter to disable use as a pstore backend drivers/firmware/Kconfig | 18 ++ drivers/firmware/efivars.c | 150 +++-- 2 files changed, 122 insertions(+), 46 deletions(-) -- Matt Fleming, Intel Open Source Technology Center -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 12:01:37AM +, Sergei Shtylyov wrote: > Hello. > > On 01-02-2013 22:59, Matt Porter wrote: > > >>>>> Move mach-davinci/dma.c to common/edma.c so it can be used > >>>>> by OMAP (specifically AM33xx) as well. > > >>>> I think this should rather go to drivers/dma/? > > >>> No, this is the private EDMA API. It's the analogous thing to > >>> the private OMAP dma API that is in plat-omap/dma.c. The actual > >>> dmaengine driver is in drivers/dma/edma.c as a wrapper around > >>> this...same way OMAP DMA engine conversion is being done. > > >>Keeps me wondering why we couldn't have the same with CPPI 4.1 when I > >> proposed > >> that, instead of waiting indefinitely for TI to convert it to drivers/dma/ > >> directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this > >> time... Sigh. > > > That is a shame. Yeah, I've pointed out that I was doing this exactly > > the same way as was acceptable for the OMAP DMA conversion since it was > > in RFC. The reasons are sound since in both cases, we have many drivers > > to convert that need to continue using the private DMA APIs. > > In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other > in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is > sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't > know them well). Well, it's pretty clear to me now that there's good reason for it not landing in arch/arm/ so the obvious path is to do the dmaengine conversion and put it in drivers/dma/ if it's really a generic dma engine. I'm not sure why you express concern over the dma engine api not fitting with CPPI 4.1? If it doesn't work, work with Vinod to fix the api. It's expected, I'm working on dmaengine API changes right now to deal with a limitation of EDMA that needs to be abstracted. As pointed out, edma.c is already here in arch/arm/, so moving it doesn't add something new. It does let us regression test all platforms that use it (both Davinci and AM33xx) as I go through the conversion process. -Matt -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote: > * Matt Porter [130202 10:10]: > > If it doesn't work, work with Vinod to fix the api. It's expected, > > I'm working on dmaengine API changes right now to deal with a > > limitation of EDMA that needs to be abstracted. > > Regarding the DMA API limitations, I'm only aware of lack of capability > to configure autoincrement at the device end. And that keeps us from > converting all GPMC related devices using omap SDMA to use the DMA API. > > Are there other limitations currently known with the DMA API? Yes, I called one out when this was first posted as an RFC and was working it in parallel with this support. This one blocks AM33XX support in mmc and is the reason I split all of the mmc support out of the base edma dmaengine for am33xx series. Independent of the blockage, whatever we finally settle on to address this API need will also cleanup the use of magic values in the davinci mmc driver (that's part of the second thread below). RFC posting: https://patchwork.kernel.org/patch/1583531/ Posting with initial attempt at a caps api: http://www.spinics.net/lists/linux-mmc/msg18351.html Also, I haven't fully vetted the situation with cyclic transfers and EDMA, however, I'm pretty sure that we'll need some API changes there. The reason is that some Davinci platforms have no FIFO on their McASP implementation (that was a new feature added on DA8xx and also AM33xx). As such they have audio support implemented using ping-pong buffering via an SRAM buffer. There's been a number of patches ahead of all this that myself and others have worked upstream to get the SRAM stuff to be Davinci-independent (genalloc). But, at the end of all of this, there's no notion in a cyclic transfer of doing synchronized ping-pong buffering using two chain channels. This is how it is implemented (and documented in EDMA docs going back to the DSPs this IP first showed up on) using the private API. I'll be looking at this soon, but, I'm more interested in 1) getting the base support in 2) then the mmc stuff blocking DT populated platforms using omap_hsmmc (split out and posted) 3) v3 of the caps api w/ vinod's concerns address (working it not) Normally, I'm not going to bring up the cyclic transfer issue until I have some code to show or reference for discussion...but it's worth being aware. But, in any case, I'm confident that will gate having the mcasp driver that am33xx also uses converted to dmaengine. Except for the gpmc limitation you menationed, that's the last in kernel user of the privat edma api needed to be converted such that we can kill off arch/arm/common/edma.c once it's taken in. -Matt -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Sat, Feb 02, 2013 at 07:06:06PM +, Sergei Shtylyov wrote: > Hello. > > On 02-02-2013 22:07, Matt Porter wrote: > > >>>>>>> Move mach-davinci/dma.c to common/edma.c so it can be used > >>>>>>> by OMAP (specifically AM33xx) as well. > > >>>>>> I think this should rather go to drivers/dma/? > > >>>>> No, this is the private EDMA API. It's the analogous thing to > >>>>> the private OMAP dma API that is in plat-omap/dma.c. The actual > >>>>> dmaengine driver is in drivers/dma/edma.c as a wrapper around > >>>>> this...same way OMAP DMA engine conversion is being done. > > >>>> Keeps me wondering why we couldn't have the same with CPPI 4.1 when > >>>> I proposed > >>>> that, instead of waiting indefinitely for TI to convert it to > >>>> drivers/dma/ > >>>> directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this > >>>> time... Sigh. > > >>> That is a shame. Yeah, I've pointed out that I was doing this exactly > >>> the same way as was acceptable for the OMAP DMA conversion since it was > >>> in RFC. The reasons are sound since in both cases, we have many drivers > >>> to convert that need to continue using the private DMA APIs. > > >> In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other > >> in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even > >> is > >> sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I > >> don't > >> know them well). > > > Well, it's pretty clear to me now that there's good reason for it not > > landing in arch/arm/ so the obvious path is to do the dmaengine > > conversion and put it in drivers/dma/ if it's really a generic dma engine. > > I'm not sure why you express concern over the dma engine api not fitting > > with CPPI 4.1? > > It's not a DMA controller only, it's 3 distinct devices, with the DMA > controller being one among them and using another one, the queue manager, as > some sort of proxy. The third device doesn't exist on OMAP-L1x SoCs -- it's > the buffer manager. Interesting, and you don't see a way to have this split between dmaengine and the musb driver? This all assumes there's even a match as RMK did raise concerns elsewhere in this thread. > > If it doesn't work, work with Vinod to fix the api. It's > > expected, I'm working on dmaengine API changes right now to deal with a > > limitation of EDMA that needs to be abstracted. > > Sorry, now it's TI's task. I no longer have time to work on this (my > internal project to push OMAP-L1x support upstream has expired at Sep 2010) > and my future in MV is very uncertain at this moment. Most probably I'll > leave > it (or be forced to leave). Too bad, it's certainly "somebody's task". The people employed by TI have names too. ;) I suspect it falls to Felipe or Kishon these days, but I try to avoid USB as it's generally a source of pain. > > As pointed out, edma.c is already here in arch/arm/, so moving it doesn't > > add something new. It does let us regression test all platforms that use it > > (both Davinci and AM33xx) as I go through the conversion process. > > Could have been the same with CPPI 4.1 in theory if it was added to > mach-davinci/ back in 2009... we'd then only have to move it. EDMA code is > much older of course, so it's probably more justified. Absolutely, timing is everything. I can assure you I've flamed enough people "internally" about leaving this EDMA dmaengine conversion for so long. As you might have guessed, AM33xx is a bit of a driver for it, but all of this would have been quite a bit simpler had somebody taken a little effort and moved edma to dmaengine years ago when slave dma support was added to dmaengine. ;) -Matt -- 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] ia64/mm: fix a bad_page bug when crash kernel booting
On Tue, 2013-01-29 at 11:52 +0800, Xishi Qiu wrote:
> On ia64 platform, I set "crashkernel=1024M-:600M", and dmesg shows 128M-728M
> memory is reserved for crash kernel. Then "echo c > /proc/sysrq-trigger" to
> test kdump.
>
> When crash kernel booting, efi_init() will aligns the memory address in
> IA64_GRANULE_SIZE(16M), so 720M-728M memory will be dropped, It means
> crash kernel only manage 128M-720M memory.
>
> But initrd start and end are fixed in boot loader, it is before efi_init(),
> so initrd size maybe overflow when free_initrd_mem().
[...]
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index b755ea9..cfdb1eb 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -207,6 +207,17 @@ free_initrd_mem (unsigned long start, unsigned long end)
> start = PAGE_ALIGN(start);
> end = end & PAGE_MASK;
>
> + /*
> + * Initrd size is fixed in boot loader, but kernel parameter max_addr
> + * which aligns in granules is fixed after boot loader, so initrd size
> + * maybe overflow.
> + */
> + if (max_addr != ~0UL) {
> + end = GRANULEROUNDDOWN(end);
> + if (start > end)
> + start = end;
> + }
> +
> if (start < end)
> printk(KERN_INFO "Freeing initrd memory: %ldkB freed\n", (end -
> start) >> 10);
I don't think this is the correct fix.
Now, my ia64-fu is weak, but could it be that there's actually a bug in
efi_init() and that the following patch would be the best way to fix
this?
---
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index f034563..8d579f1 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -482,7 +482,7 @@ efi_init (void)
if (memcmp(cp, "mem=", 4) == 0) {
mem_limit = memparse(cp + 4, &cp);
} else if (memcmp(cp, "max_addr=", 9) == 0) {
- max_addr = GRANULEROUNDDOWN(memparse(cp + 9, &cp));
+ max_addr = GRANULEROUNDUP(memparse(cp + 9, &cp));
} else if (memcmp(cp, "min_addr=", 9) == 0) {
min_addr = GRANULEROUNDDOWN(memparse(cp + 9, &cp));
} else {
--
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: [ 105/128] efi: Make efi_enabled a function to query EFI facilities
On Sun, 2013-02-03 at 16:15 +0100, Ben Hutchings wrote: > As you can see this needed quite a lot of work to backport, and I > haven't been able to test it yet. So I would particularly appreciate > careful review of this. Everything looks fine to me but I haven't actually booted with these changes. -- 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 v8 2/4] misc: Generic on-chip SRAM allocation driver
On Tue, Feb 05, 2013 at 12:53:45AM +0900, Paul Mundt wrote: > On Mon, Feb 04, 2013 at 12:32:16PM +0100, Philipp Zabel wrote: > > This driver requests and remaps a memory region as configured in the > > device tree. It serves memory from this region via the genalloc API. > > It optionally enables the SRAM clock. > > > > Other drivers can retrieve the genalloc pool from a phandle pointing > > to this drivers' device node in the device tree. > > > > The allocation granularity is hard-coded to 32 bytes for now, > > to make the SRAM driver useful for the 6502 remoteproc driver. > > There is overhead for bigger SRAMs, where only a much coarser > > allocation granularity is needed: At 32 bytes minimum allocation > > size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. > > > > Signed-off-by: Philipp Zabel > > Reviewed-by: Shawn Guo > > How exactly is this "generic" if you have randomly hard-coded an > allocation granularity that is larger than half of the in-tree SRAM pool > users today can even support? Did you even bother to look at in-tree SRAM > pool users other than the one you are working on? > > There also doesn't seem to be any real reason for the hard-coding either, > this information could easily be fetched via platform data or the device > tree, and the driver in question would simply need to be able to > determine whether the size is suitable for it or not. Please see http://thread.gmane.org/gmane.linux.kernel/1377702 for the original discussion on my patch for configurable allocation granularity. I believe there was an implied agreement from Grant that it was ok if we went with a more descriptive name even though it hits the grey area of not describing hardware. -Matt -- 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 v3 1/3] dmaengine: add dma_get_slave_sg_caps()
Add a dmaengine API to retrieve slave SG transfer capabilities.
The API is optionally implemented by dmaengine drivers and when
unimplemented will return a NULL pointer. A client driver using
this API provides the required dma channel, address width, and
burst size of the transfer. dma_get_slave_sg_caps() returns an
SG caps structure with the maximum number and size of SG segments
that the given channel can handle.
Signed-off-by: Matt Porter
---
include/linux/dmaengine.h | 40
1 file changed, 40 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d3201e4..5b5b220 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,19 @@ struct dma_slave_config {
unsigned int slave_id;
};
+/* struct dma_slave_sg_caps - expose SG transfer capability of a
+ * channel.
+ *
+ * @max_seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @max_seg_len: maximum length of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dma_slave_sg_caps {
+ u32 max_seg_nr;
+ u32 max_seg_len;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(&chan->dev->device);
@@ -534,6 +547,7 @@ struct dma_tx_state {
* struct with auxiliary transfer status information, otherwise the call
* will just return a simple status code
* @device_issue_pending: push pending transactions to hardware
+ * @device_slave_sg_caps: return the slave SG capabilities
*/
struct dma_device {
@@ -602,6 +616,9 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+ struct dma_slave_sg_caps *(*device_slave_sg_caps)(
+ struct dma_chan *chan, enum dma_slave_buswidth addr_width,
+ u32 maxburst);
};
static inline int dmaengine_device_control(struct dma_chan *chan,
@@ -969,6 +986,29 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t
last, dma_cookie_t used,
}
}
+/**
+ * dma_get_slave_sg_caps - get DMAC SG transfer capabilities
+ * @chan: target DMA channel
+ * @addr_width: address width of the DMA transfer
+ * @maxburst: maximum DMA transfer burst size
+ *
+ * Get SG transfer capabilities for a specified channel. If the dmaengine
+ * driver does not implement SG transfer capabilities then NULL is
+ * returned.
+ */
+static inline struct dma_slave_sg_caps
+*dma_get_slave_sg_caps(struct dma_chan *chan,
+ enum dma_slave_buswidth addr_width,
+ u32 maxburst)
+{
+ if (chan->device->device_slave_sg_caps)
+ return chan->device->device_slave_sg_caps(chan,
+ addr_width,
+ maxburst);
+
+ return NULL;
+}
+
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
#ifdef CONFIG_DMA_ENGINE
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
--
1.7.9.5
--
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 v3 3/3] mmc: davinci: get SG segment limits with dma_get_slave_sg_caps()
Replace the hardcoded values used to set max_segs/max_seg_size with
a dma_get_slave_sg_caps() query to the dmaengine driver.
Signed-off-by: Matt Porter
---
drivers/mmc/host/davinci_mmc.c| 37 -
include/linux/platform_data/mmc-davinci.h |3 ---
2 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 2063677..583cbd0 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -144,18 +144,6 @@
/* MMCSD Init clock in Hz in opendrain mode */
#define MMCSD_INIT_CLOCK 20
-/*
- * One scatterlist dma "segment" is at most MAX_CCNT rw_threshold units,
- * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
- * for drivers with max_segs == 1, making the segments bigger (64KB)
- * than the page or two that's otherwise typical. nr_sg (passed from
- * platform data) == 16 gives at least the same throughput boost, using
- * EDMA transfer linkage instead of spending CPU time copying pages.
- */
-#define MAX_CCNT ((1 << 16) - 1)
-
-#define MAX_NR_SG 16
-
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
MODULE_PARM_DESC(rw_threshold,
@@ -216,8 +204,6 @@ struct mmc_davinci_host {
u8 version;
/* for ns in one cycle calculation */
unsigned ns_in_one_cycle;
- /* Number of sg segments */
- u8 nr_sg;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -1165,6 +1151,7 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
struct resource *r, *mem = NULL;
int ret = 0, irq = 0;
size_t mem_size;
+ struct dma_slave_sg_caps *dma_sg_caps;
/* REVISIT: when we're fully converted, fail if pdata is NULL */
@@ -1214,12 +1201,6 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
init_mmcsd_host(host);
- if (pdata->nr_sg)
- host->nr_sg = pdata->nr_sg - 1;
-
- if (host->nr_sg > MAX_NR_SG || !host->nr_sg)
- host->nr_sg = MAX_NR_SG;
-
host->use_dma = use_dma;
host->mmc_irq = irq;
host->sdio_irq = platform_get_irq(pdev, 1);
@@ -1248,14 +1229,16 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
mmc->caps |= pdata->caps;
mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
- /* With no iommu coalescing pages, each phys_seg is a hw_seg.
-* Each hw_seg uses one EDMA parameter RAM slot, always one
-* channel and then usually some linked slots.
-*/
- mmc->max_segs = MAX_NR_SG;
+ /* Just check one channel for the DMA SG limits */
+ dma_sg_caps = dma_get_slave_sg_caps(
+ host->dma_tx,
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ rw_threshold / DMA_SLAVE_BUSWIDTH_4_BYTES);
- /* EDMA limit per hw segment (one or two MBytes) */
- mmc->max_seg_size = MAX_CCNT * rw_threshold;
+ if (dma_sg_caps) {
+ mmc->max_segs = dma_sg_caps->max_seg_nr;
+ mmc->max_seg_size = dma_sg_caps->max_seg_len;
+ }
/* MMC/SD controller limits for multiblock requests */
mmc->max_blk_size = 4095; /* BLEN is 12 bits */
diff --git a/include/linux/platform_data/mmc-davinci.h
b/include/linux/platform_data/mmc-davinci.h
index 5ba6b22..6910209 100644
--- a/include/linux/platform_data/mmc-davinci.h
+++ b/include/linux/platform_data/mmc-davinci.h
@@ -25,9 +25,6 @@ struct davinci_mmc_config {
/* Version of the MMC/SD controller */
u8 version;
-
- /* Number of sg segments */
- u8 nr_sg;
};
void davinci_setup_mmc(int module, struct davinci_mmc_config *config);
--
1.7.9.5
--
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 v3 2/3] dma: edma: add device_slave_sg_caps() support
Implement device_slave_sg_caps().
EDMA has a finite set of PaRAM slots available for linking a
multi-segment SG transfer. In order to prevent any one channel
from consuming all PaRAM slots to fulfill a large SG transfer,
the driver reports a static per-channel max number of SG segments
it will handle.
The maximum size of an SG segment is limited by the addr_width
and maxburst of a given transfer request. These values are
provided by the client driver and used to calculate and return
the maximum segment length.
Signed-off-by: Matt Porter
---
drivers/dma/edma.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index f424298..b779cee 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -72,6 +72,7 @@ struct edma_chan {
dma_addr_t addr;
int addr_width;
int maxburst;
+ struct dma_slave_sg_capssg_caps;
};
struct edma_cc {
@@ -463,6 +464,20 @@ static void edma_issue_pending(struct dma_chan *chan)
spin_unlock_irqrestore(&echan->vchan.lock, flags);
}
+static struct dma_slave_sg_caps
+*edma_get_slave_sg_caps(struct dma_chan *chan,
+ enum dma_slave_buswidth addr_width,
+ u32 maxburst)
+{
+ struct edma_chan *echan;
+
+ echan = to_edma_chan(chan);
+ echan->sg_caps.max_seg_len =
+ (SZ_64K - 1) * addr_width * maxburst;
+
+ return &echan->sg_caps;
+}
+
static size_t edma_desc_size(struct edma_desc *edesc)
{
int i;
@@ -522,6 +537,7 @@ static void __init edma_chan_init(struct edma_cc *ecc,
echan->ch_num = EDMA_CTLR_CHAN(ecc->ctlr, i);
echan->ecc = ecc;
echan->vchan.desc_free = edma_desc_free;
+ echan->sg_caps.max_seg_nr = MAX_NR_SG;
vchan_init(&echan->vchan, dma);
@@ -538,6 +554,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
dma_device *dma,
dma->device_alloc_chan_resources = edma_alloc_chan_resources;
dma->device_free_chan_resources = edma_free_chan_resources;
dma->device_issue_pending = edma_issue_pending;
+ dma->device_slave_sg_caps = edma_get_slave_sg_caps;
dma->device_tx_status = edma_tx_status;
dma->device_control = edma_control;
dma->dev = dev;
--
1.7.9.5
--
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 v3 0/3] dmaengine: add slave sg transfer capabilities api
Changes since v2: - Change to a separate slave sg specific api. Drop the generic per-channel capabilities api that is not used. Changes since v1: - Use the existing dma_transaction_type enums instead of adding the mostly duplicated dmaengine_apis enums This series adds a new dmaengine api, dma_get_slave_sg_caps(), which may be used by a client driver to get slave SG transfer capabilities for a particular channel. At this time, these include the max number of segments and max length of a segment that a channel can handle for a SG transfer. Along with the API implementation, this series implements the backend device_slave_sg_caps() in the EDMA DMA Engine driver and converts the davinci_mmc driver to use dma_get_slave_sg_caps() to replace hardcoded limits. This is tested on the AM1808-EVM. Matt Porter (3): dmaengine: add dma_get_slave_sg_caps() dma: edma: add device_slave_sg_caps() support mmc: davinci: get SG segment limits with dma_get_slave_sg_caps() drivers/dma/edma.c| 17 drivers/mmc/host/davinci_mmc.c| 37 -- include/linux/dmaengine.h | 40 + include/linux/platform_data/mmc-davinci.h |3 --- 4 files changed, 67 insertions(+), 30 deletions(-) -- 1.7.9.5 -- 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 0/3] omap_hsmmc DT DMA Client support
On Wed, Feb 06, 2013 at 01:41:06PM +0100, Lars Poeschel wrote: > Hi Matt! > > At first thanks for you efforts on DMA Engine on AM33XX. > > On Friday 01 February 2013 at 22:01:17, Matt Porter wrote: > > This series adds DT DMA Engine Client support to the omap_hsmmc. > > It leverages the generic DMA OF helpers in -next and the > > dma_request_slave_channel_compat() wrapper introduced in the > > AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms > > booting via DT. These platforms include omap2/3/4/5 and am33xx. > > > > These patches were split out from the v5 version of the AM33XX DMA > > series and split from the EDMA-specific omap_hsmmc changes. > > > > The series depends on the following patches: > > > > - dmaengine DT support and edma dmaengine driver fix from > > the git://git.infradead.org/users/vkoul/slave-dma.git next > > branch > > - dma_request_slave_channel_compat() support > > https://patchwork.kernel.org/patch/2081671/ > > > > The series with all dependencies can be found at > > https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 > > I cloned your github repository and did short testing with it. I get the > following error when the kernel mounts my sd-card: > > Starting udev > [5.884738] udevd[72]: starting version 182 > [8.879651] edma-dma-engine edma-dma-engine.0: Exceeded max SG segments 33 Hi Lars, I left it somewhat ambiguous as to what this series claims to support, sorry about that. This series, by itself, supports only platforms using SDMA (omap 2/3/4/5 assuming you add the appropriate DMA dts bits). This is only part of what am33xx requires for working mmc support. I've also posted v3 of dmaengine slave sg caps series at https://lkml.org/lkml/2013/2/4/561 I have to rebase the am33xx specific bits for omap_hsmmc on top of that and post. That was previously all contained in one series but I didn't want to block omap2/3/4/5 from working DMA on DT support until the api change is resolved for am33xx. -Matt > [8.887377] omap_hsmmc mmc.3: prep_slave_sg() failed > [8.892588] omap_hsmmc mmc.3: MMC start dma failure > [8.897725] mmcblk0: unknown error -1 sending read/write command, card > status 0x900 > [8.905889] end_request: I/O error, dev mmcblk0, sector 17039 > [8.911926] end_request: I/O error, dev mmcblk0, sector 17047 > [8.917934] end_request: I/O error, dev mmcblk0, sector 17055 > [8.923960] end_request: I/O error, dev mmcblk0, sector 17063 > [8.929967] end_request: I/O error, dev mmcblk0, sector 17071 > [8.935988] end_request: I/O error, dev mmcblk0, sector 17079 > [8.942010] end_request: I/O error, dev mmcblk0, sector 17087 > [8.948016] end_request: I/O error, dev mmcblk0, sector 17095 > [8.954037] end_request: I/O error, dev mmcblk0, sector 17103 > [8.960043] end_request: I/O error, dev mmcblk0, sector 17111 > [9.020919] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3764: > inode #8: block 239: comm mount: unable to read itable block > [9.033514] EXT4-fs (mmcblk0p2): no journal found > [9.043799] kjournald starting. Commit interval 5 seconds > [9.049589] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, running > e2fsck is recommended > [9.060940] EXT3-fs (mmcblk0p2): using internal journal > [9.066437] EXT3-fs (mmcblk0p2): recovery complete > [9.071460] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode > > After that the filesystem on the sd-card has an error that I have to fix with > e2fsck. As rootfs I use a nfsroot. > In my quick tests, same setup, I don't get any error on edma-dmaengine- > am33xx-v5 branch of your repository. > If you need any further information, let me now. > > Regards, > Lars > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss -- 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/3 v3] selftests: Add tests for efivarfs
On Fri, 2013-02-08 at 18:05 +0800, Jeremy Kerr wrote: > However, the tests expose a bug at the moment, so run_tests will fail. > Matt will have that fixed soon though :) In which case, would it make more sense for me to take these tests through the efi tree? I'm fine either way, I'm just looking for the least surprising option. -- 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 v5 -next 0/2] make efivars/efi_pstore interrupt-safe
On Fri, 2013-02-08 at 22:31 +, Seiji Aguchi wrote: > Matt, > > Can you please take a look at this patchset which removes > create_sysfs_entries() from efi_pstore_write()? > > It has been updated in accordance with Mike's comment and fixes an > actual bug. > http://comments.gmane.org/gmane.linux.kernel.efi/406 OK, I'll find some time to review these. -- 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 v5 -next 1/2]efivars: Disable external interrupt while holding efivars->lock
On Thu, 2013-01-24 at 00:41 +, Seiji Aguchi wrote: > [Problem] > There is a scenario which efi_pstore fails to log messages in a panic case. > > - CPUA holds an efi_var->lock in either efivarfs parts >or efi_pstore with interrupt enabled. > - CPUB panics and sends IPI to CPUA in smp_send_stop(). > - CPUA stops with holding the lock. > - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC) >but it returns without logging messages. > > [Patch Description] > This patch disables an external interruption while holding efivars->lock > as follows. > > In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is > replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may > be called in an interrupt context. > > In other functions, they are replaced by spin_lock_irq/spin_unlock_irq. > because they are all called from a process context. > > By applying this patch, we can avoid the problem above with > a following senario. > > - CPUA holds an efi_var->lock with interrupt disabled. > - CPUB panics and sends IPI to CPUA in smp_send_stop(). > - CPUA receives the IPI after releasing the lock because it is >disabling interrupt while holding the lock. > - CPUB waits for one sec until CPUA releases the lock. > - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC) >And it can hold the lock successfully. > > Signed-off-by: Seiji Aguchi > Acked-by: Mike Waychison > --- > drivers/firmware/efivars.c | 86 ++- > 1 files changed, 44 insertions(+), 42 deletions(-) Acked-by: Matt Fleming Tony, are you picking this up? -- Matt Fleming, Intel Open Source Technology Center -- 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 v5 -next 2/2]efi_pstore: Introducing workqueue updating sysfs entries
On Thu, 2013-01-24 at 00:41 +, Seiji Aguchi wrote: > [Problem] > efi_pstore creates sysfs entries, which enable users to access to NVRAM, > in a write callback. If a kernel panic happens in an interrupt context, > it may fail because it could sleep due to dynamic memory allocations during > creating sysfs entries. > > [Patch Description] > This patch removes sysfs operations from a write callback by introducing > a workqueue updating sysfs entries which is scheduled after the write > callback is called. > > Also, the workqueue is kicked in a just oops case. > A system will go down in other cases such as panic, clean shutdown and > emergency > restart. And we don't need to create sysfs entries because there is no chance > for > users to access to them. > > efi_pstore will be robust against a kernel panic in an interrupt context with > this patch. > > Signed-off-by: Seiji Aguchi > --- > drivers/firmware/efivars.c | 85 > +--- > include/linux/efi.h |3 +- > 2 files changed, 82 insertions(+), 6 deletions(-) Acked-by: Matt Fleming -- Matt Fleming, Intel Open Source Technology Center -- 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 "efi: Build EFI stub with EFI-appropriate options" has been added to the 3.6-stable tree
On 30/03/13 10:04, Daniel Vacek wrote:
> On Sat, Mar 30, 2013 at 4:28 AM, Ben Hutchings wrote:
>> Daniel, this is an obvious fix but I noticed it still hasn't been
>> applied. Please can you re-send with the proper Signed-off-by line?
>
> Resending patch. It got lost somewhere. Thanks for pushing Ben.
>
> From 53864fe932aa87be62f1c70944c386cff9bb9130 Mon Sep 17 00:00:00 2001
> From: Daniel Vacek
> Date: Thu, 18 Oct 2012 22:06:26 +0200
> Subject: [PATCH] efi: fix typo in Makefile
>
> Fix a little typo.
>
> Signed-off-by: Daniel Vacek
> Acked-by: Matthew Garrett
> ---
> arch/x86/boot/compressed/Makefile |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I applied this by hand. Your patch appears to be whitespace damaged. Also, I
expanded the commit message and turned it into,
efi: fix typo in Makefile
commit 9dead5bbb825 ("efi: Build EFI stub with EFI-appropriate options")
contains a typo which means that the efi_stub_$(BITS).o code is still not
compiled with -fshort-wchar and -mno-red-zone.
Fix it with s/KBUILD_CLFAGS/KBUILD_CFLAGS/
--
Matt Fleming, Intel Open Source Technology Center
--
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] efi: Determine how much space is used by boot services-only variables
On 01/04/13 16:13, Matthew Garrett wrote: > EFI variables can be flagged as being accessible only within boot services. > This makes it awkward for us to figure out how much space they use at > runtime. In theory we could figure this out by simply comparing the results > from QueryVariableInfo() to the space used by all of our variables, but > that fails if the platform doesn't garbage collect on every boot. Thankfully, > calling QueryVariableInfo() while still inside boot services gives a more > reliable answer. This patch passes that information from the EFI boot stub > up to the efivars code, letting us calculate a reasonably accurate value. > > Signed-off-by: Matthew Garrett > --- > arch/x86/boot/compressed/eboot.c | 47 > +++ > arch/x86/include/asm/efi.h| 10 > arch/x86/include/uapi/asm/bootparam.h | 1 + > arch/x86/platform/efi/efi.c | 21 > drivers/firmware/efivars.c| 29 + > 5 files changed, 108 insertions(+) We're fixing a regression in efivars.c, but only for those users that boot via the EFI boot stub? That seems likely to upset some people. Introducing new features via the EFI boot stub is fine, and working around firmware bugs so that we can use some feature is also cool, but we can't start fixing regressions from other subsystems in the EFI boot stub. -- Matt Fleming, Intel Open Source Technology Center -- 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 2/2] efi: Distinguish between "remaining space" and actually used space
On 01/04/13 16:14, Matthew Garrett wrote:
> @@ -452,8 +462,33 @@ check_var_size_locked(struct efivars *efivars, u32
> attributes,
> if (status != EFI_SUCCESS)
> return status;
>
> - if (!storage_size || size > remaining_size || size > max_size ||
> - (remaining_size - size) < (storage_size / 2))
> + list_for_each_entry(entry, &efivars->list, list) {
> + var = &entry->var;
> + status = get_var_data_locked(efivars, var);
> +
> + if (status || !(var->Attributes & EFI_VARIABLE_NON_VOLATILE))
> + continue;
> +
> + active_size += var->DataSize;
> + active_size += utf16_strsize(var->VariableName, 1024);
> + /*
> + * There's some additional metadata associated with each
> + * variable. Intel's reference implementation is 60 bytes -
> + * bump that to 128 to account for vendor additions and
> + * potential alignment constraints
> + */
> + active_size += 128;
> + }
This is the kind of thing I was referring to when I said,
Hmm... I'm not convinced this will provide a long-term solution. Is there
anything that mandates that the size of all variables has to correlate
sensibly with the results from QueryVariableInfo()? Even if there is in
theory, I doubt it'll be true everywhere in practice, and trying to
workaround implementation bugs in our workarounds for other bugs is the
path to madness.
We can't continue this approach where we attempt to guess how the firmware
implements variable storage, because as we've seen, there are various
schemes out there.
This looks like something that will differ between implementations, and the
fact that it's appearing in our code is a sure sign that this isn't the way to
go.
--
Matt Fleming, Intel Open Source Technology Center
--
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 2/2] efi: Distinguish between "remaining space" and actually used space
On 03/04/13 14:48, Matthew Garrett wrote: > On Wed, 2013-04-03 at 14:11 +0100, Matt Fleming wrote: > >> This looks like something that will differ between implementations, and the >> fact that it's appearing in our code is a sure sign that this isn't the way >> to >> go. > > Our choices right now are: > > 1) Break machines that don't garbage collect on every reboot > 2) Leave Samsungs (and some Lenovos?) vulnerable to bricking > 3) Maintain a whitelist or blacklist that will inevitably be inadequate, > either breaking otherwise working machines or risking bricking of broken > ones > 4) Attempt to implement something that'll work in all cases The solution you're proposing has the same downsides as 3) - we risk having to tweak things either way. The difference is that in the case of 3) the tweaking is adding entries to the whitelist, whereas tweaking your solution has more chance of introducing further unwanted regressions because you'd be tweaking an algorithm, an algorithm that relies on the internal implementation of the variable storage code. > Dealing with firmware is hard. This fixes (1) without leaving us with > (2), which seems like a net win. I'm not convinced that implementing 3) would inevitably lead to 2), provided that we apply a bit of common sense when adding entries. I'm not advocating some kind of flag day where we add umpteen machines to the whitelist. For reference, I just pushed two patches to the 'whitelist' branch at, git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git which should hopefully illustrate the kind of thing that I'm talking about. -- Matt Fleming, Intel Open Source Technology Center -- 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 1/6] efi: move utf16 string functions to efi.h
From: Matt Fleming
There are currently two implementations of the utf16 string functions.
Somewhat confusingly, they've got different names.
Centralise the functions in efi.h.
Cc: Tom Gundersen
Cc: Mike Waychison
Signed-off-by: Matt Fleming
---
drivers/firmware/efivars.c | 17 -
drivers/firmware/google/gsmi.c | 19 ---
include/linux/efi.h| 17 +
3 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 7acafb8..34c8783 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -172,23 +172,6 @@ static void efivar_update_sysfs_entries(struct work_struct
*);
static DECLARE_WORK(efivar_work, efivar_update_sysfs_entries);
static bool efivar_wq_enabled = true;
-/* Return the number of unicode characters in data */
-static unsigned long
-utf16_strnlen(efi_char16_t *s, size_t maxlength)
-{
- unsigned long length = 0;
-
- while (*s++ != 0 && length < maxlength)
- length++;
- return length;
-}
-
-static inline unsigned long
-utf16_strlen(efi_char16_t *s)
-{
- return utf16_strnlen(s, ~0UL);
-}
-
/*
* Return the number of bytes is the length of this string
* Note: this is NOT the same as the number of unicode characters
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 91ddf0f..c409a75 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -288,17 +288,6 @@ static int gsmi_exec(u8 func, u8 sub)
return rc;
}
-/* Return the number of unicode characters in data */
-static size_t
-utf16_strlen(efi_char16_t *data, unsigned long maxlength)
-{
- unsigned long length = 0;
-
- while (*data++ != 0 && length < maxlength)
- length++;
- return length;
-}
-
static efi_status_t gsmi_get_variable(efi_char16_t *name,
efi_guid_t *vendor, u32 *attr,
unsigned long *data_size,
@@ -311,7 +300,7 @@ static efi_status_t gsmi_get_variable(efi_char16_t *name,
};
efi_status_t ret = EFI_SUCCESS;
unsigned long flags;
- size_t name_len = utf16_strlen(name, GSMI_BUF_SIZE / 2);
+ size_t name_len = utf16_strnlen(name, GSMI_BUF_SIZE / 2);
int rc;
if (name_len >= GSMI_BUF_SIZE / 2)
@@ -380,7 +369,7 @@ static efi_status_t gsmi_get_next_variable(unsigned long
*name_size,
return EFI_BAD_BUFFER_SIZE;
/* Let's make sure the thing is at least null-terminated */
- if (utf16_strlen(name, GSMI_BUF_SIZE / 2) == GSMI_BUF_SIZE / 2)
+ if (utf16_strnlen(name, GSMI_BUF_SIZE / 2) == GSMI_BUF_SIZE / 2)
return EFI_INVALID_PARAMETER;
spin_lock_irqsave(&gsmi_dev.lock, flags);
@@ -408,7 +397,7 @@ static efi_status_t gsmi_get_next_variable(unsigned long
*name_size,
/* Copy the name back */
memcpy(name, gsmi_dev.name_buf->start, GSMI_BUF_SIZE);
- *name_size = utf16_strlen(name, GSMI_BUF_SIZE / 2) * 2;
+ *name_size = utf16_strnlen(name, GSMI_BUF_SIZE / 2) * 2;
/* copy guid to return buffer */
memcpy(vendor, ¶m.guid, sizeof(param.guid));
@@ -434,7 +423,7 @@ static efi_status_t gsmi_set_variable(efi_char16_t *name,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS,
};
- size_t name_len = utf16_strlen(name, GSMI_BUF_SIZE / 2);
+ size_t name_len = utf16_strnlen(name, GSMI_BUF_SIZE / 2);
efi_status_t ret = EFI_SUCCESS;
int rc;
unsigned long flags;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 9bf2f1f..d1d782a 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -719,6 +719,23 @@ static inline void memrange_efi_to_native(u64 *addr, u64
*npages)
*addr &= PAGE_MASK;
}
+/* Return the number of unicode characters in data */
+static inline unsigned long
+utf16_strnlen(efi_char16_t *s, size_t maxlength)
+{
+ unsigned long length = 0;
+
+ while (*s++ != 0 && length < maxlength)
+ length++;
+ return length;
+}
+
+static inline unsigned long
+utf16_strlen(efi_char16_t *s)
+{
+ return utf16_strnlen(s, ~0UL);
+}
+
#if defined(CONFIG_EFI_VARS) || defined(CONFIG_EFI_VARS_MODULE)
/*
* EFI Variable support.
--
1.7.10.4
--
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 2/6] efivars: Keep a private global pointer to efivars
From: Matt Fleming
Some machines have an EFI variable interface that does not conform to the UEFI
specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code and Kconfig glue
so that it's only possible to select one implementation of EFI variable
operations. This allows us to keep a single (file-scope) global pointer 'struct
efivars', which simplifies access. This will hopefully dissuade developers from
accessing the generic operations struct directly in the future, as was done in
the efivarfs and pstore code, thereby allowing future code to work with both
the generic efivar ops and the google SMI ops.
This may seem like a step backwards in terms of modularity, but we don't need
to track more than one 'struct efivars' at one time. There is no
synchronisation done between multiple EFI variable operations, and according to
Mike no one is using both the generic EFI var ops and CONFIG_GOOGLE_SMI. It
also helps to clearly highlight which functions form the core of the efivars
interface - those that require access to __efivars.
Note that because of the Kconfig rules, we don't need to use any kind of
synchronisation primitive in register_efivars() - it's not possible to compile
more than one set of EFI variable operations into the kernel.
Cc: Tom Gundersen
Cc: Mike Waychison
Signed-off-by: Matt Fleming
---
drivers/firmware/Kconfig |6 +++
drivers/firmware/efivars.c | 91 +++-
2 files changed, 63 insertions(+), 34 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 42c759a..96d84ad 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -53,6 +53,12 @@ config EFI_VARS
Subsequent efibootmgr releases may be found at:
<http://linux.dell.com/efibootmgr>
+config EFI_VARS_GENERIC_OPS
+ bool
+ depends on EFI
+ depends on !GOOGLE_SMI
+ default y
+
config EFI_VARS_PSTORE
bool "Register efivars backend for pstore"
depends on EFI_VARS && PSTORE
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 34c8783..721d200 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -125,7 +125,6 @@ struct efi_variable {
} __attribute__((packed));
struct efivar_entry {
- struct efivars *efivars;
struct efi_variable var;
struct list_head list;
struct kobject kobj;
@@ -137,8 +136,8 @@ struct efivar_attribute {
ssize_t (*store)(struct efivar_entry *entry, const char *buf, size_t
count);
};
-static struct efivars __efivars;
-static struct efivar_operations ops;
+/* Private pointer to registered efivars */
+static struct efivars *__efivars;
#define PSTORE_EFI_ATTRIBUTES \
(EFI_VARIABLE_NON_VOLATILE | \
@@ -479,7 +478,7 @@ efivar_attr_read(struct efivar_entry *entry, char *buf)
if (!entry || !buf)
return -EINVAL;
- status = get_var_data(entry->efivars, var);
+ status = get_var_data(__efivars, var);
if (status != EFI_SUCCESS)
return -EIO;
@@ -513,7 +512,7 @@ efivar_size_read(struct efivar_entry *entry, char *buf)
if (!entry || !buf)
return -EINVAL;
- status = get_var_data(entry->efivars, var);
+ status = get_var_data(__efivars, var);
if (status != EFI_SUCCESS)
return -EIO;
@@ -530,7 +529,7 @@ efivar_data_read(struct efivar_entry *entry, char *buf)
if (!entry || !buf)
return -EINVAL;
- status = get_var_data(entry->efivars, var);
+ status = get_var_data(__efivars, var);
if (status != EFI_SUCCESS)
return -EIO;
@@ -545,7 +544,7 @@ static ssize_t
efivar_store_raw(struct efivar_entry *entry, const char *buf, size_t count)
{
struct efi_variable *new_var, *var = &entry->var;
- struct efivars *efivars = entry->efivars;
+ struct efivars *efivars = __efivars;
efi_status_t status = EFI_NOT_FOUND;
if (count != sizeof(struct efi_variable))
@@ -606,7 +605,7 @@ efivar_show_raw(struct efivar_entry *entry, char *buf)
if (!entry || !buf)
return 0;
- status = get_var_data(entry->efivars, var);
+ status = get_var_data(__efivars, var);
if (status != EFI_SUCCESS)
return -EIO;
@@ -728,7 +727,7 @@ static ssize_t efivarfs_file_write(struct file *file,
const char __user *userbuf, size_t count, loff_t *ppos)
{
struct efivar_entry *var = file->private_data;
- struct efivars *efivars;
+ struct efivars *efivars = __efivars;
efi_status_t status;
void *data;
u32 attributes;
@@ -746,8 +745,6 @@ static ssize_t efivarfs_file_write(struct file *file,
if (attributes & ~(EFI_VARIABLE_MASK))
return -EINVAL;
- efivars = var->efivars;
-
[PATCH 0/6] Chainsaw efivars.c
From: Matt Fleming drivers/firmware/efivars.c has grown pretty large and is ~2K lines. Inside efivars.c there's currently, o code for handling EFI variables at the firmware-level o sysfs code for exposing EFI variables o a new EFI variable filesystem o a persistent storage backend all intertwined and smushed together. This situation is only going to get worse as new EFI support is added. We need an interface that hides the EFI variable operations in use so code isn't tempted to access them directly, e.g. efivarfs currently uses '__efivars' which means it doesn't work for CONFIG_GOOGLE_SMI as that uses different variable ops. With this interface in place, we can start moving independent code out into separate files, allowing users to only turn on the functionality that they want. This patch series introduces the new efivar_entry API, and splits out the major parts of efivars.c into new files. In particular, having the efivarfs code under fs/ allows building an efivarfs.ko module, which means mount(8) can automatically load it. The remaining EFI code is repositioned under drivers/firmware/efi/. The series is also available on the 'chainsaw' branch at, git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/linux.git Matt Fleming (5): efi: move utf16 string functions to efi.h efivars: Keep a private global pointer to efivars efivars: efivar_entry API efivars: Move pstore code into the new EFI directory efivarfs: Move to fs/efivarfs Tom Gundersen (1): efi: split efisubsystem from efivars MAINTAINERS | 13 +- drivers/firmware/Kconfig | 36 +- drivers/firmware/Makefile |2 +- drivers/firmware/efi/Kconfig | 45 + drivers/firmware/efi/Makefile |6 + drivers/firmware/efi/efi-pstore.c | 244 + drivers/firmware/efi/efi.c| 145 +++ drivers/firmware/efi/efivars.c| 615 +++ drivers/firmware/efi/vars.c | 1020 + drivers/firmware/efivars.c| 2171 - drivers/firmware/google/gsmi.c| 30 +- fs/Kconfig|1 + fs/Makefile |1 + fs/efivarfs/Kconfig | 12 + fs/efivarfs/Makefile |7 + fs/efivarfs/file.c| 111 ++ fs/efivarfs/inode.c | 173 +++ fs/efivarfs/internal.h| 22 + fs/efivarfs/super.c | 266 + include/linux/efi.h | 132 ++- 20 files changed, 2818 insertions(+), 2234 deletions(-) create mode 100644 drivers/firmware/efi/Kconfig create mode 100644 drivers/firmware/efi/Makefile create mode 100644 drivers/firmware/efi/efi-pstore.c create mode 100644 drivers/firmware/efi/efi.c create mode 100644 drivers/firmware/efi/efivars.c create mode 100644 drivers/firmware/efi/vars.c delete mode 100644 drivers/firmware/efivars.c create mode 100644 fs/efivarfs/Kconfig create mode 100644 fs/efivarfs/Makefile create mode 100644 fs/efivarfs/file.c create mode 100644 fs/efivarfs/inode.c create mode 100644 fs/efivarfs/internal.h create mode 100644 fs/efivarfs/super.c -- 1.7.10.4 -- 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 5/6] efivarfs: Move to fs/efivarfs
From: Matt Fleming
Now that efivarfs uses the efivar API, move it out of efivars.c and into
fs/efivarfs where it belongs. This move will eventually allow us to enable the
efivarfs code without having to also enable CONFIG_EFI_VARS built, and vice
versa.
Furthermore, things like,
mount -t efivarfs none /sys/firmware/efi/efivars
will now work if efivarfs is built as a module without requiring the use of
MODULE_ALIAS(), which would have been necessary when the efivarfs code was part
of efivars.c.
Cc: Matthew Garrett
Cc: Jeremy Kerr
Cc: Tom Gundersen
Signed-off-by: Matt Fleming
---
MAINTAINERS|9 +
drivers/firmware/efivars.c | 495
fs/Kconfig |1 +
fs/Makefile|1 +
fs/efivarfs/Kconfig| 12 ++
fs/efivarfs/Makefile |7 +
fs/efivarfs/file.c | 111 ++
fs/efivarfs/inode.c| 173
fs/efivarfs/internal.h | 22 ++
fs/efivarfs/super.c| 266
10 files changed, 602 insertions(+), 495 deletions(-)
create mode 100644 fs/efivarfs/Kconfig
create mode 100644 fs/efivarfs/Makefile
create mode 100644 fs/efivarfs/file.c
create mode 100644 fs/efivarfs/inode.c
create mode 100644 fs/efivarfs/internal.h
create mode 100644 fs/efivarfs/super.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d106da..ed131c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2990,6 +2990,15 @@ F: arch/x86/platform/efi/*
F: drivers/firmware/efivars.c
F: include/linux/efi*.h
+EFI VARIABLE FILESYSTEM
+M: Matthew Garrett
+M: Jeremy Kerr
+M: Matt Fleming
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
+L: linux-...@vger.kernel.org
+S: Maintained
+F: fs/efivarfs/
+
EFIFB FRAMEBUFFER DRIVER
L: linux-fb...@vger.kernel.org
M: Peter Jones
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 949d8d4..f6fd57e 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -94,7 +94,6 @@ MODULE_DESCRIPTION("sysfs interface to EFI Variables");
MODULE_LICENSE("GPL");
MODULE_VERSION(EFIVARS_VERSION);
-static LIST_HEAD(efivarfs_list);
LIST_HEAD(efivar_sysfs_list);
EXPORT_SYMBOL_GPL(efivar_sysfs_list);
@@ -558,12 +557,6 @@ static struct kobj_type efivar_ktype = {
.default_attrs = def_attrs,
};
-static int efivarfs_file_open(struct inode *inode, struct file *file)
-{
- file->private_data = inode->i_private;
- return 0;
-}
-
static int efi_status_to_err(efi_status_t status)
{
int err;
@@ -597,492 +590,6 @@ static int efi_status_to_err(efi_status_t status)
return err;
}
-static ssize_t efivarfs_file_write(struct file *file,
- const char __user *userbuf, size_t count, loff_t *ppos)
-{
- struct efivar_entry *var = file->private_data;
- void *data;
- u32 attributes;
- struct inode *inode = file->f_mapping->host;
- unsigned long datasize = count - sizeof(attributes);
- ssize_t bytes = 0;
- bool set = false;
-
- if (count < sizeof(attributes))
- return -EINVAL;
-
- if (copy_from_user(&attributes, userbuf, sizeof(attributes)))
- return -EFAULT;
-
- if (attributes & ~(EFI_VARIABLE_MASK))
- return -EINVAL;
-
- data = kmalloc(datasize, GFP_KERNEL);
- if (!data)
- return -ENOMEM;
-
- if (copy_from_user(data, userbuf + sizeof(attributes), datasize)) {
- bytes = -EFAULT;
- goto out;
- }
-
- bytes = efivar_entry_set_get_size(var, attributes, &datasize,
- data, &set);
- if (!set && bytes)
- goto out;
-
- if (!bytes) {
- mutex_lock(&inode->i_mutex);
- i_size_write(inode, datasize + sizeof(attributes));
- mutex_unlock(&inode->i_mutex);
- } else if (bytes == -ENOENT) {
- drop_nlink(inode);
- d_delete(file->f_dentry);
- dput(file->f_dentry);
- } else
- pr_warn("efivarfs: inconsistent EFI variable implementation? "
- "status=%zu\n", bytes);
-
- bytes = count;
-
-out:
- kfree(data);
-
- return bytes;
-}
-
-static ssize_t efivarfs_file_read(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct efivar_entry *var = file->private_data;
- unsigned long datasize = 0;
- u32 attributes;
- void *data;
- ssize_t size = 0;
- int err;
-
- err = efivar_entry_size(var, &datasize);
- if (err)
- return err;
-
- data = kmalloc(datasize + sizeof(attributes), GFP_KERNEL);
-
-
[PATCH 4/6] efivars: Move pstore code into the new EFI directory
From: Matt Fleming efivars.c has grown far too large and needs to be divided up. Create a new directory and move the persistence storage code to efi-pstore.c now that it uses the new efivar API. This helps us to greatly reduce the size of efivars.c and paves the way for moving other code out of efivars.c. Note that because CONFIG_EFI_VARS can be built as a module efi-pstore must also include support for buildilng as a module. Cc: Tom Gundersen Cc: Seiji Aguchi Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Matthew Garrett Cc: Tony Luck Signed-off-by: Matt Fleming --- MAINTAINERS |2 +- drivers/firmware/Kconfig | 42 +- drivers/firmware/Makefile |1 + drivers/firmware/efi/Kconfig | 45 ++ drivers/firmware/efi/Makefile |4 + drivers/firmware/efi/efi-pstore.c | 244 drivers/firmware/efivars.c| 277 ++--- include/linux/efi.h | 38 + 8 files changed, 346 insertions(+), 307 deletions(-) create mode 100644 drivers/firmware/efi/Kconfig create mode 100644 drivers/firmware/efi/Makefile create mode 100644 drivers/firmware/efi/efi-pstore.c diff --git a/MAINTAINERS b/MAINTAINERS index 4cf5fd3..9d106da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6319,7 +6319,7 @@ S:Maintained T: git git://git.infradead.org/users/cbou/linux-pstore.git F: fs/pstore/ F: include/linux/pstore* -F: drivers/firmware/efivars.c +F: drivers/firmware/efi/efi-pstore.c F: drivers/acpi/apei/erst.c PTP HARDWARE CLOCK SUPPORT diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 96d84ad..9387630 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -36,47 +36,6 @@ config FIRMWARE_MEMMAP See also Documentation/ABI/testing/sysfs-firmware-memmap. -config EFI_VARS - tristate "EFI Variable Support via sysfs" - depends on EFI - default n - help - If you say Y here, you are able to get EFI (Extensible Firmware - Interface) variable information via sysfs. You may read, - write, create, and destroy EFI variables through this interface. - - Note that using this driver in concert with efibootmgr requires - at least test release version 0.5.0-test3 or later, which is - available from Matt Domsch's website located at: - <http://linux.dell.com/efibootmgr/testing/efibootmgr-0.5.0-test3.tar.gz> - - Subsequent efibootmgr releases may be found at: - <http://linux.dell.com/efibootmgr> - -config EFI_VARS_GENERIC_OPS - bool - depends on EFI - depends on !GOOGLE_SMI - default y - -config EFI_VARS_PSTORE - bool "Register efivars backend for pstore" - depends on EFI_VARS && PSTORE - default y - help - Say Y here to enable use efivars as a backend to pstore. This - will allow writing console messages, crash dumps, or anything - else supported by pstore to EFI variables. - -config EFI_VARS_PSTORE_DEFAULT_DISABLE - bool "Disable using efivars as a pstore backend by default" - depends on EFI_VARS_PSTORE - default n - help - Saying Y here will disable the use of efivars as a storage - backend for pstore by default. This setting can be overridden - using the efivars module's pstore_disable parameter. - config EFI_PCDP bool "Console device selection via EFI PCDP or HCDP table" depends on ACPI && EFI && IA64 @@ -170,5 +129,6 @@ config ISCSI_IBFT Otherwise, say N. source "drivers/firmware/google/Kconfig" +source "drivers/firmware/efi/Kconfig" endmenu diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 5a7e273..31bf68c 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -14,3 +14,4 @@ obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o obj-$(CONFIG_GOOGLE_FIRMWARE) += google/ +obj-$(CONFIG_EFI) += efi/ diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig new file mode 100644 index 000..c011f9c --- /dev/null +++ b/drivers/firmware/efi/Kconfig @@ -0,0 +1,45 @@ +menu "EFI (Extensible Firmware Interface) Support" + depends on EFI + +config EFI_VARS + tristate "EFI Variable Support via sysfs" + depends on EFI + default n + help + If you say Y here, you are able to get EFI (Extensible Firmware + Interface) variable information via sysfs. You may read, + write, create, and destroy EFI variables through this interface. + + Note that using this driver in concert with efibootmgr requires + at least test release version 0.5.0-test3 or later, which is +
Re: [PATCH 1/2] efivars: Check max_size only if it is non-zero.
On 04/04/13 17:12, Richard Weinberger wrote: > Fair point. I'll add such a printk() to my patch and resend. Also take a look at FW_BUG. -- 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] x86, efi: remove attribute check from setup_efi_pci
On Tue, 2013-01-29 at 17:52 +0100, Maarten Lankhorst wrote:
> It looks like the original commit that copied the rom contents from efi
> always copied
> the rom, and the fixup in setup_efi_pci from commit 886d751a2ea99a160
> ("x86, efi: correct precedence of operators in setup_efi_pci") broke that.
>
> This resulted in macbook pro's no longer finding the rom images, and thus not
> being able to use the radeon card any more.
>
> The solution is to just remove the check for now, and always copy the rom if
> available.
>
> Signed-off-by: Maarten Lankhorst
Applied, thanks!
--
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: [GIT PULL] EFI fixes for v3.8
Hi guys, The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git for you to fetch changes up to 739701888f5d98010a8960b2d974d74c77c830a2: x86, efi: remove attribute check from setup_efi_pci (2013-01-29 17:52:06 +) Various urgent EFI fixes and some warning cleanups for v3.8 * EFI boot stub fix for Macbook Pro's from Maarten Lankhorst * Fix an oops in efivarfs from Lingzhu Xiang * 32-bit warning cleanups from Jan Beulich * Patch to Boot on >512GB RAM systems from Nathan Zimmer * Set efi.runtime_version correctly * efivarfs updates Jan Beulich (1): x86, efi: fix 32-bit warnings in setup_efi_pci() Lingzhu Xiang (1): efivarfs: Drop link count of the right inode Maarten Lankhorst (1): x86, efi: remove attribute check from setup_efi_pci Matt Fleming (3): efivarfs: Never return ENOENT from firmware efivarfs: Delete dentry from dcache in efivarfs_file_write() x86, efi: Set runtime_version to the EFI spec revision Nathan Zimmer (1): efi, x86: Pass a proper identity mapping in efi_call_phys_prelog arch/x86/boot/compressed/eboot.c | 11 --- arch/x86/platform/efi/efi.c | 2 +- arch/x86/platform/efi/efi_64.c | 22 +- drivers/firmware/efivars.c | 5 +++-- 4 files changed, 25 insertions(+), 15 deletions(-) -- Matt Fleming, Intel Open Source Technology Center -- 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 v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Wed, Jan 23, 2013 at 10:28:46PM +, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Matt Porter wrote:
> > Adds a dma_request_slave_channel_compat() wrapper which accepts
> > both the arguments from dma_request_channel() and
> > dma_request_slave_channel(). Based on whether the driver is
> > instantiated via DT, the appropriate channel request call will be
> > made.
> >
> > This allows for a much cleaner migration of drivers to the
> > dmaengine DT API as platforms continue to be mixed between those
> > that boot using DT and those that do not.
>
> I noticed today some drivers in linux-next that rely on this patch,
> but the patch itself still missing from -next.
>
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
> > dma_async_tx_descriptor *tx);
> > struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> > struct dma_chan *net_dma_find_channel(void);
> > #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x,
> > y)
> > +static inline struct dma_chan
> > +*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
> > + void *fn_param, struct device *dev,
> > + char *name)
> > +{
> > + if (dev->of_node)
> > + return dma_request_slave_channel(dev, name);
> > + else
> > + return dma_request_channel(mask, fn, fn_param);
> > +}
>
> Hmm, dma_request_channel is actually a macro that passes mask by reference,
> presumably because it can get modified by the filter function. Also, there
> may be cases where we do have an of_node but don't use the dma binding
> yet, or where dma_request_slave_channel doesn't actually use DT information
> but rather one of the other methods that Vinod was talking about adding.
>
> I think what it should look like instead is the below.
Yes, looks correct now, thanks. I've incorporated it into v6.
-Matt
>
> Arnd
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bfcdecb..b6ffd7d 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -993,6 +993,19 @@ static inline void dma_release_channel(struct dma_chan
> *chan)
> }
> #endif
>
> +static inline struct dma_chan
> *__dma_request_slave_channel_compat(dma_cap_mask_t *mask,
> + dma_filter_fn fn, void *fn_param, struct device
> *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
> +
> /* --- DMA device --- */
>
> int dma_async_device_register(struct dma_device *device);
> @@ -1001,6 +1014,8 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
>
> /* --- Helper iov-locking functions --- */
>
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
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 v5 03/14] ARM: edma: add AM33XX support to the private EDMA API
On Mon, Jan 28, 2013 at 09:27:24PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter wrote:
> > Adds support for parsing the TI EDMA DT data into the required
> > EDMA private API platform data. Enables runtime PM support to
> > initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
> > support.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/common/edma.c | 314
> > ++--
> > include/linux/platform_data/edma.h |1 +
> > 2 files changed, 306 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> > index 2dce245..beeb1d2 100644
> > --- a/arch/arm/common/edma.c
> > +++ b/arch/arm/common/edma.c
> > @@ -24,6 +24,13 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > #include
> >
> > @@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
> > */
> > int edma_alloc_slot(unsigned ctlr, int slot)
> > {
> > + if (!edma_cc[ctlr])
> > + return -EINVAL;
> > +
> > if (slot >= 0)
> > slot = EDMA_CHAN_SLOT(slot);
> >
> > @@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
> > EXPORT_SYMBOL(edma_clear_event);
> >
> > /*---*/
> > +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> > +const char *propname, s8
> > *out_values,
> > +size_t sz)
>
> I'm sorry I didn't get why you couldn't use of_property_read_u8_array() ?
> The similar comment to u16 and so on.
There's some manipulation of the legacy Davinci platform data
structures going on here. The driving reason was to not change any of
the davinci platforms pdata which uses s8/s16 tables of mapping values
with signed values as terminators. These versions below add the
convert to the signed value and terminate the array as needed by the
existing driver. This will all go away when the driver is rewritten and
merged into drivers/dma/edma.c. At that point I want to throwaway all
these legacy data structures. First, there's some more drivers to
convert to dmaengine api.
-Matt
>
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
> > +const char *propname, s16
> > *out_values,
> > +size_t sz)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_xbar_event_map(struct device *dev,
> > + struct device_node *node,
> > + struct edma_soc_info *pdata, int len)
> > +{
> > + int ret = 0;
> > + int i;
> > + struct resource res;
> > + void *xbar;
> > + const s16 (*xbar_chans)[2];
> > + u32 shift, offset, mux;
> > +
> > + xbar_chans = devm_kzalloc(dev,
> > + len/siz
[PATCH v6 10/10] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index e711ffb..ddf702a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -328,6 +328,11 @@ interrupt = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; + dmas = <&edma 16 + &edma 17 + &edma 18 + &edma 19>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; @@ -339,6 +344,11 @@ interrupt = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; + dmas = <&edma 42 + &edma 43 + &edma 44 + &edma 45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; -- 1.7.9.5 -- 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 v6 07/10] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
---
include/linux/dmaengine.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..17d8ffd 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
+
+static inline struct dma_chan
+*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
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 v6 02/10] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be3c04a..2dce245 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
--
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 v6 00/10] DMA Engine support for AM33XX
Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support
Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
removed some unneeded definitions
- Fixed parsing of optional properties
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.8-rc5 and the following patches:
- dmaengine DT support and edma dmaengine driver fix from
the git://git.infradead.org/users/vkoul/slave-dma.git next
branch
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
With this series both BeagleBone and the AM335x EVM have working
SPI DMA support (and MMC support with the separate MMC series).
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v6
has the complete series, dependencies, and some test
drivers/defconfigs. Note that MMC can only be tested with a
separate MMC dmaengine/DT series applied.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (10):
ARM: davinci: move private EDMA API to arm/common
ARM: edma: remove unused transfer controller handlers
ARM: edma: add AM33XX support to the private EDMA API
dmaengine: edma: enable build for AM33XX
dmaengine: edma: Add TI EDMA device tree binding
ARM: dts: add AM33XX EDMA support
dmaengine: add dma_request_slave_channel_compat()
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
spi: omap2-mcspi: add generic DMA request support to the DT binding
ARM: dts: add AM33XX SPI DMA support
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
arch/arm/Kconfig |1 +
arch/arm/boot/dts/am33xx.dtsi | 30 ++
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} | 355 +---
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tne
[PATCH v6 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..68cb28e 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
--
1.7.9.5
--
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 v6 08/10] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+
[PATCH v6 01/10] ARM: davinci: move private EDMA API to arm/common
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} |4 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|6 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach => include/linux/platform_data}/edma.h| 89 +---
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |7 +-
23 files changed, 35 insertions(+), 106 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
rename {arch/arm/mach-davinci/include/mach =>
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..be3c04a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
@@ -1387,7 +1387,7 @@ EXPORT_SYMBOL(edma_clear_event);
/*---*/
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
const s8(*queue_priority_mapping)[2];
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o psc.o \
- dma.o usb.o common.o sram.o aemif.o
+ usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c
b/arch/arm/mach-davinci/devices-tnetv107x.c
index 773ab07..ba37760 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch
[PATCH v6 06/10] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
--
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 v6 05/10] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = <0x4900 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
--
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 v6 04/10] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 0b408bb..239020b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -220,7 +220,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 -- 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 v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data. Enables runtime PM support to
initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
support.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 314 ++--
arch/arm/plat-omap/Kconfig |1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 307 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2dce245..beeb1d2 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-xbar-event-map",
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] >> 2;
+ offset <<= 2;
+ mux = readl((void *)((u32)xbar + offset));
+ mux &= ~(0xff << shift);
+ mux |= xbar_chans[i][0] << shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata->xbar_chans = xbar_chans;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ const s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, "dma-channels", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_channel = value;
+
+ ret = of_property_read_u32(node, "ti,edma-regio
Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
On Wed, Jan 30, 2013 at 1:07 PM, Nicolas Pitre wrote: > On Wed, 30 Jan 2013, Ruslan Bilovol wrote: > >> Currently, reading /proc/cpuinfo provides userspace with CPU ID of >> the CPU carrying out the read from the file. >> Userspace using this information may decide what module >> to load or how to configure some specific (and processor-depended) >> settings or so. >> However, since really different SoCs can share same ARM core, >> this information currently is not so useful. >> For example, TI OMAP4460 and OMAP4470 SoCs show the same >> information in the /proc/cpuinfo whereas they are different. >> Since in most cases ARM CPU is a part of some system on a chip (SoC), >> the "cpuinfo" file looks like exactly that place, where this >> information have to be displayed. >> >> So added new line "SoC name" in the "cpuinfo" output for system >> on a chip name. It is placed between CPU information and machine >> information, so the file structure looks gracefully (CPU-SoC-Hardware) >> >> Example: >> >> / # cat proc/cpuinfo >> [...] >> CPU variant : 0x2 >> CPU part: 0xc09 >> CPU revision: 10 >> >> SoC name: OMAP4470 >> >> Hardware: OMAP4 Blaze Tablet > > Please remove that extra blank line between "SoC name" and "Hardware". > The blank line after "CPU revision" is fine. > > Also, please rename this to "System name". Not all systems are "on > chip". By using "System name" this is more universally useful. I can't agree with "System name", it is confusing in common terminology since it's about the same definition as the current "Hardware" line. If we're just printing out the name of the device surrounding the CPU - be it a Northbridge/Southbridge combination or SoC packaging - "Chipset" might be a better name for it. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. -- 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 v5 03/14] ARM: edma: add AM33XX support to the private EDMA API
On Wed, Jan 30, 2013 at 09:40:52AM +0200, Andy Shevchenko wrote:
> On Wed, Jan 30, 2013 at 8:41 AM, Matt Porter wrote:
> > On Mon, Jan 28, 2013 at 09:27:24PM +0200, Andy Shevchenko wrote:
> >> On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter wrote:
> >> > Adds support for parsing the TI EDMA DT data into the required
> >> > EDMA private API platform data. Enables runtime PM support to
> >> > initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
> >> > support.
> >> >
> >> > Signed-off-by: Matt Porter
> >> > ---
> >> > arch/arm/common/edma.c | 314
> >> > ++--
> >> > include/linux/platform_data/edma.h |1 +
> >> > 2 files changed, 306 insertions(+), 9 deletions(-)
> >> >
> >> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> >> > index 2dce245..beeb1d2 100644
> >> > --- a/arch/arm/common/edma.c
> >> > +++ b/arch/arm/common/edma.c
> >> > @@ -24,6 +24,13 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +#include
> >> > +#include
> >> >
> >> > #include
> >> >
> >> > @@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
> >> > */
> >> > int edma_alloc_slot(unsigned ctlr, int slot)
> >> > {
> >> > + if (!edma_cc[ctlr])
> >> > + return -EINVAL;
> >> > +
> >> > if (slot >= 0)
> >> > slot = EDMA_CHAN_SLOT(slot);
> >> >
> >> > @@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
> >> > EXPORT_SYMBOL(edma_clear_event);
> >> >
> >> >
> >> > /*---*/
> >> > +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> >> > +const char *propname, s8
> >> > *out_values,
> >> > +size_t sz)
> >>
> >> I'm sorry I didn't get why you couldn't use of_property_read_u8_array() ?
> >> The similar comment to u16 and so on.
> >
> > There's some manipulation of the legacy Davinci platform data
> > structures going on here. The driving reason was to not change any of
> > the davinci platforms pdata which uses s8/s16 tables of mapping values
> > with signed values as terminators. These versions below add the
> > convert to the signed value and terminate the array as needed by the
> > existing driver. This will all go away when the driver is rewritten and
> > merged into drivers/dma/edma.c. At that point I want to throwaway all
> > these legacy data structures. First, there's some more drivers to
> > convert to dmaengine api.
> >
>
> I mean instead of custom functions you could use existing ones.
> And sign here will be implicitly applied.
Yes, sorry, wasn't following you at first. The is definitely much better
and does work fine. I will update this...thanks!
-Matt
> So, what I propose is to do something like this
>
> static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> const char *propname, s8 *out_values,
> size_t sz)
> {
>
> int ret;
> ret = of_property_read_u8_array(np, propname, out_values, sz);
> if (ret)
> return ret;
>
>/* Terminate it */
>*out_values++ = -1;
>*out_values++ = -1;
> }
>
> > -Matt
> >>
> >> > +{
> >> > + struct property *prop = of_find_property(np, propname, NULL);
> >> > + const __be32 *val;
> >> > +
> >> > + if (!prop)
> >> > + return -EINVAL;
> >> > + if (!prop->value)
> >> > + return -ENODATA;
> >> > + if ((sz * sizeof(u32)) > prop->length)
> >> > + return -EOVERFLOW;
> >> > +
> >> > + val = prop->value;
> >> > +
> >> > + while (sz--)
> >> > + *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
> >> > +
> >> > + /* Terminate it */
> >> > + *out_v
Re: [PATCH v6 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
On Wed, Jan 30, 2013 at 09:24:00AM +, Arnd Bergmann wrote: > On Wednesday 30 January 2013, Matt Porter wrote: > > +Optional properties: > > +- dmas: List of DMA controller phandle and DMA request ordered > > + pairs. One tx and one rx pair is required for each chip > > + select. > > The binding looks ok, but the wording is slightly incorrect here: > strictly speaking, it's not a pair of controller phandle and request > line number, but a DMA descriptor as specified in bindings/dma/dma.txt > with a format specific to the dma engine being used. That can > require more than just a single integer request number. Correct. I will update accordingly. -Matt -- 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 v6 07/10] dmaengine: add dma_request_slave_channel_compat()
On Wed, Jan 30, 2013 at 09:27:18AM +, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Matt Porter wrote:
> > Adds a dma_request_slave_channel_compat() wrapper which accepts
> > both the arguments from dma_request_channel() and
> > dma_request_slave_channel(). Based on whether the driver is
> > instantiated via DT, the appropriate channel request call will be
> > made.
> >
> > This allows for a much cleaner migration of drivers to the
> > dmaengine DT API as platforms continue to be mixed between those
> > that boot using DT and those that do not.
> >
> > Suggested-by: Tony Lindgren
> > Signed-off-by: Matt Porter
> > Acked-by: Tony Lindgren
>
> Acked-by: Arnd Bergmann
>
> > @@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
> > dma_async_tx_descriptor *tx);
> > struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> > struct dma_chan *net_dma_find_channel(void);
> > #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x,
> > y)
> > +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> > + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
> > +
> > +static inline struct dma_chan
> > +*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
> > + void *fn_param, struct device *dev,
> > + char *name)
> > +{
> > + struct dma_chan *chan;
> > +
> > + chan = dma_request_slave_channel(dev, name);
> > + if (chan)
> > + return chan;
> > +
> > + return __dma_request_channel(mask, fn, fn_param);
> > +}
>
> After I have spent some more time with implementing the code for dw_dma,
> I think the mask is actually unnecessary here, the helper could just
> always set it to DMA_SLAVE before calling __dma_request_channel.
>
> It's not a bug to do it this way though, and it may help convert drivers
> a little easier if there is less to change.
Agreed.
-Matt
>
> Arnd
--
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 v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > On Wednesday 30 January 2013, Matt Porter wrote: > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > + of_dma_controller_register(dev->of_node, > > + of_dma_simple_xlate, > > + &edma_filter_info); > > + } > > How do you actually deal with the problem mentioned by Padma, that > the filter function does not know which edma instance it is looking > at? If you assume that there can only be a single edma instance in > the system, that is probably a limitation that should be documented > somewhere, and ideally the probe() function should check for that. I make an assumption of one edma instance in the system in the case of DT being populated. This is always true right now as the only SoC with two EDMA controllers in existence is Davinci DA850. Until recently, Davinci had no DT support. Given the steady work being done today on DT support for DA850, it'll probably be something needed in 3.10. I will add a comment and check in probe() to capture this assumption and then plan to update separately to support DA850 booting from DT. -Matt -- 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 v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: > On Thursday 31 January 2013, Matt Porter wrote: > > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > > On Wednesday 30 January 2013, Matt Porter wrote: > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > > + of_dma_controller_register(dev->of_node, > > > > + of_dma_simple_xlate, > > > > + &edma_filter_info); > > > > + } > > > > > > How do you actually deal with the problem mentioned by Padma, that > > > the filter function does not know which edma instance it is looking > > > at? If you assume that there can only be a single edma instance in > > > the system, that is probably a limitation that should be documented > > > somewhere, and ideally the probe() function should check for that. > > > > I make an assumption of one edma instance in the system in the case of > > DT being populated. This is always true right now as the only SoC with > > two EDMA controllers in existence is Davinci DA850. Until recently, > > Davinci had no DT support. Given the steady work being done today on DT > > support for DA850, it'll probably be something needed in 3.10. > > > > I will add a comment and check in probe() to capture this assumption > > and then plan to update separately to support DA850 booting from DT. > > Ok, sounds good. Hopefully by then we will already have a nicer > way to write an xlate function that does not rely on a filter > function. Yes, it would be nice to avoid what Padma had to do. I should have mentioned also that the second EDMA on DA850 has no DMA events of immediate use on it anyway. All the in-kernel users use events on the first controller, except for the second MMC instance. That's only used for a wl12xx module on the EVM and that driver has no DT support so it doesn't matter yet in the DT case. Because of this, DA850 can actually add EDMA DT support immediately (on top of this series) and add DMA support to the DT support already posted for the Davinci SPI and MMC client drivers. -Matt -- 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 v2 0/3] dmaengine: add per channel capabilities api
On Mon, Jan 28, 2013 at 10:06:03AM +, Vinod Koul wrote: > On Mon, Jan 21, 2013 at 01:19:23PM -0500, Matt Porter wrote: > > > b) Sg segment length and numbers: Well these are capabilities, so it tells > > > you what is the maximum I can do. IMO it doesn't make sense to tie it > > > down to > > > burst, width etc. For that configuration you are checking maximum. What > > > this > > > needs to return is what is the maximum length it supports and maximum > > > number of > > > sg list the h/w can use. Also if you return your burst and width > > > capablity, then > > > any client can easily find out what is the length byte value it can hold. > > > > Ok, so I could report the max burst size to the client, but on EDMA it's > > going to be SZ_64K-1, as that's the hw limit. Max addr width would also > > be the same or capped at the maximum enum the current API support of 8 > > bytes. > Yes IMO you should report the h/w limit and let client deduce what can be done > with that h/w limit given the other parameters (burst, length etc...) Hrm, in a driver that runs on two different DMACs, we don't know which one we are running on in order to determine if the information returned is relevant to do a calculation. If omap_hsmmc.c is running on SDMA the absolute max_seg_len may be fixed. On EDMA, that max values can be returned but is invalid for purposes of computing the actual length of sg segments that can be absorbed by the driver. The client driver does know the burst and length, and could compute this in an EDMA specific way, but we're talking now about in the client driver is: if (i_am_edma) max_seg_len = (SZ_64K-1) * max_burst * addr_width; else /* sdma */ max_seg_len = MY_FIXED_VALUE_FROM_CHANNEL_CAPS; There's no way to deduce what to do in the client driver without having the knowledge of being on an EDMA DMAC or not. The only thing to do with fixed h/w caps is to report back a safe value. That would be SZ_64K-1 but would be very inefficient when the slave config is set for a large FIFO and 32-bit address width and the actual size that can be transferred if much larger. > > > > This information is not useful to the client in my case. Only the client > > knows its FIFO size, and thus the actual burst size it needs to request > > as that is a value specific to the IP the client driver controls. So it > > knows actual burst size and the width of that fifo transfer, because we > > already support telling the dmaengine driver this info in the current > > API. > Your current API way is not very generic. We need to make sure it useful on > other systems too. That is why it would make sense to query the DMA H/W > capablities and then use it with above properties to get various parameters > used > for initiating a transfer, that way you dont need to set slave parameters Ok, you want something then that takes max_burst and addr_width as arguments and returns max_seg_len. Easy enough. That's the minimum information the driver needs to report the value and will avoid having to set the slave config first. -Matt -- 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 v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Fri, Feb 01, 2013 at 08:01:41AM +0200, Luciano Coelho wrote: > On Thu, 2013-01-31 at 16:42 -0500, Matt Porter wrote: > > On Thu, Jan 31, 2013 at 08:58:39PM +, Arnd Bergmann wrote: > > > On Thursday 31 January 2013, Matt Porter wrote: > > > > On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote: > > > > > On Wednesday 30 January 2013, Matt Porter wrote: > > > > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > > > > + of_dma_controller_register(dev->of_node, > > > > > > + of_dma_simple_xlate, > > > > > > + &edma_filter_info); > > > > > > + } > > > > > > > > > > How do you actually deal with the problem mentioned by Padma, that > > > > > the filter function does not know which edma instance it is looking > > > > > at? If you assume that there can only be a single edma instance in > > > > > the system, that is probably a limitation that should be documented > > > > > somewhere, and ideally the probe() function should check for that. > > > > > > > > I make an assumption of one edma instance in the system in the case of > > > > DT being populated. This is always true right now as the only SoC with > > > > two EDMA controllers in existence is Davinci DA850. Until recently, > > > > Davinci had no DT support. Given the steady work being done today on DT > > > > support for DA850, it'll probably be something needed in 3.10. > > > > > > > > I will add a comment and check in probe() to capture this assumption > > > > and then plan to update separately to support DA850 booting from DT. > > > > > > Ok, sounds good. Hopefully by then we will already have a nicer > > > way to write an xlate function that does not rely on a filter > > > function. > > > > Yes, it would be nice to avoid what Padma had to do. I should have > > mentioned also that the second EDMA on DA850 has no DMA events of > > immediate use on it anyway. All the in-kernel users use events on the > > first controller, except for the second MMC instance. That's only used > > for a wl12xx module on the EVM and that driver has no DT support so it > > doesn't matter yet in the DT case. Because of this, DA850 can actually > > add EDMA DT support immediately (on top of this series) and add DMA > > support to the DT support already posted for the Davinci SPI and MMC > > client drivers. > > I haven't followed this whole discussion in details, but please notice > that I'm aiming to get DT support for the WiLink modules (wlcore, > wl12xx...) for 3.10. ;) Great, looks like we'll all be synced then. ;) -Matt -- 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 v7 08/10] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(&spi->dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+
[PATCH v7 03/10] ARM: edma: add AM33XX support to the private EDMA API
Adds support for parsing the TI EDMA DT data into the
required EDMA private API platform data. Enables runtime
PM support to initialize the EDMA hwmod. Adds AM33XX EDMA
crossbar event mux support. Enables build on OMAP.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 96
arch/arm/plat-omap/Kconfig |1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 89 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 3440d16..bd2416a 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1575,27 +1585,69 @@ static struct of_dma_filter_info edma_filter_info = {
static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
+ struct edma_soc_infotmpinfo;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
- struct resource *r[EDMA_MAX_CC] = {NULL};
+ struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
+ struct resource res[EDMA_MAX_CC];
resource_size_t len[EDMA_MAX_CC];
charres_name[10];
charirq_name[10];
+ struct device_node *node = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ if (node) {
+ /* Check if this is a second instance registered */
+ if (arch_num_cc) {
+ dev_err(dev, "only one EDMA instance is supported via
DT\n");
+ return -ENODEV;
+ }
+ info = ninfo;
+ edma_of_parse_dt(dev, node, &tmpinfo);
+ info[0] = &tmpinfo;
+
+ dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+ of_dma_controller_register(dev->of_node,
+ of_dma_simple_xlate,
+ &edma_filter_info);
+ }
if (!info)
return -ENODEV;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, "pm_runtime_get_sync() failed\n");
+ return ret;
+ }
+
for (j = 0; j < EDMA_MAX_CC; j++) {
- sprintf(res_name, "edma_cc%d", j);
- r[j] = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ if (!info[j]) {
+ if (!found)
+ return -ENODEV;
+ break;
+ }
+ if (node) {
+ ret = of_address_to_resource(node, j, &res[j]);
+ if (!IS_ERR_VALUE(ret))
+ r[j] = &res[j];
+ } else {
+ sprintf(res_name, "edma_cc%d", j);
+ r[j] = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM,
res_name);
- if (!r[j] || !info[j]) {
+ }
+ if (!r[j]) {
if (found)
break;
else
@@ -1670,8 +1722,22 @@ static int edma_probe(struct platform_device *pdev)
}
}
- sprintf(irq_name, "edma%d", j);
- irq[j] = platform_get_irq_byname(pdev, irq_name);
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]->xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]->edma_unused);
+ }
+ }
+
+
[PATCH v7 04/10] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 0b408bb..239020b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -220,7 +220,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 -- 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 v7 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas. The string naming
+ is to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
--
1.7.9.5
--
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 v7 10/10] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index e711ffb..ddf702a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -328,6 +328,11 @@ interrupt = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; + dmas = <&edma 16 + &edma 17 + &edma 18 + &edma 19>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; @@ -339,6 +344,11 @@ interrupt = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; + dmas = <&edma 42 + &edma 43 + &edma 44 + &edma 45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; -- 1.7.9.5 -- 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 v7 07/10] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
Acked-by: Arnd Bergmann
---
include/linux/dmaengine.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..17d8ffd 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
+
+static inline struct dma_chan
+*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
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 v7 00/10] DMA Engine support for AM33XX
Changes since v6:
- Converted edma_of_read_*() to wrappers around of_property_read_*()
- Fixed wording on the omap-spi generic DMA properties
- Added comment/check to clarify that the driver only supports
a single EDMA instance when booting from DT
Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support
Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
removed some unneeded definitions
- Fixed parsing of optional properties
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.8-rc5 and the following patches:
- dmaengine DT support and edma dmaengine driver fix from
the git://git.infradead.org/users/vkoul/slave-dma.git next
branch
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
With this series both BeagleBone and the AM335x EVM have working
SPI DMA support (and MMC support with the separate MMC series).
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v7
has the complete series, dependencies, and some test
drivers/defconfigs. Note that MMC can only be tested with a
separate MMC dmaengine/DT series applied.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (10):
ARM: davinci: move private EDMA API to arm/common
ARM: edma: remove unused transfer controller handlers
ARM: edma: add AM33XX support to the private EDMA API
dmaengine: edma: enable build for AM33XX
dmaengine: edma: Add TI EDMA device tree binding
ARM: dts: add AM33XX EDMA support
dmaengine: add dma_request_slave_channel_compat()
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
spi: omap2-mcspi: add generic DMA request support to the DT binding
ARM: dts: add AM33XX SPI DMA support
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
arch/arm/Kconfig |1 +
arch/arm/boot/dts/am33xx.dtsi | 30 ++
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-da
[PATCH v7 06/10] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
--
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 v7 05/10] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = <0x4900 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
--
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 v7 02/10] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index aa4a49a..3440d16 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1743,23 +1723,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
--
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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} | 209 +++-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|6 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach => include/linux/platform_data}/edma.h| 89 +
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |7 +-
23 files changed, 240 insertions(+), 106 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (90%)
rename {arch/arm/mach-davinci/include/mach =>
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 90%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..aa4a49a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
@@ -1386,8 +1386,213 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = d
Re: [PATCH v7 05/10] dmaengine: edma: Add TI EDMA device tree binding
On Fri, Feb 01, 2013 at 01:22:50PM -0500, Matt Porter wrote:
> The binding definition is based on the generic DMA controller
> binding.
>
> Signed-off-by: Matt Porter
Grant or Rob, can I get an ack on this binding and others in this
series?
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 49
> +
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> new file mode 100644
> index 000..075a60e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -0,0 +1,49 @@
> +TI EDMA
> +
> +Required properties:
> +- compatible : "ti,edma3"
> +- ti,hwmods: Name of the hwmods associated to the EDMA
> +- ti,edma-regions: Number of regions
> +- ti,edma-slots: Number of slots
> +- ti,edma-queue-tc-map: List of transfer control to queue mappings
> +- ti,edma-queue-priority-map: List of queue priority mappings
> +- ti,edma-default-queue: Default queue value
> +
> +Optional properties:
> +- ti,edma-reserved-channels: List of reserved channel regions
> +- ti,edma-reserved-slots: List of reserved slot regions
> +- ti,edma-xbar-event-map: Crossbar event to channel map
> +
> +Example:
> +
> +edma: edma@4900 {
> + reg = <0x4900 0x1>;
> + interrupt-parent = <&intc>;
> + interrupts = <12 13 14>;
> + compatible = "ti,edma3";
> + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> + #dma-cells = <1>;
> + dma-channels = <64>;
> + ti,edma-regions = <4>;
> + ti,edma-slots = <256>;
> + ti,edma-reserved-channels = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8>;
> + ti,edma-reserved-slots = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8
> + 64 127>;
> + ti,edma-queue-tc-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-queue-priority-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-default-queue = <0>;
> + ti,edma-xbar-event-map = <1 12
> + 2 13>;
> +};
> --
> 1.7.9.5
>
--
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 v7 07/10] dmaengine: add dma_request_slave_channel_compat()
On Fri, Feb 01, 2013 at 01:22:52PM -0500, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
>
> Suggested-by: Tony Lindgren
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
> Acked-by: Arnd Bergmann
Vinod, can I get an ack on this one?
-Matt
> ---
> include/linux/dmaengine.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bfcdecb..17d8ffd 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
> +
> +static inline struct dma_chan
> +*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
>
> /* --- Helper iov-locking functions --- */
>
> --
> 1.7.9.5
>
--
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 v7 00/10] DMA Engine support for AM33XX
On Fri, Feb 01, 2013 at 01:22:45PM -0500, Matt Porter wrote:
> This series adds DMA Engine support for AM33xx, which uses
> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> a private API implementation (much like the situation with OMAP
> DMA) found on the DaVinci family of SoCs.
Tony,
Will you be able to take this series in through your tree? It appears we
just need acks on the new bindings and the compat api change. I haven't
heard from you or Benoit on the dts patches so it seems those are ready
as well.
Thanks,
Matt
>
> The series applies on top of 3.8-rc5 and the following patches:
>
> - dmaengine DT support and edma dmaengine driver fix from
> the git://git.infradead.org/users/vkoul/slave-dma.git next
> branch
>
> The approach taken is similar to how OMAP DMA is being converted to
> DMA Engine support. With the functional EDMA private API already
> existing in mach-davinci/dma.c, we first move that to an ARM common
> area so it can be shared. Adding DT and runtime PM support to the
> private EDMA API implementation allows it to run on AM33xx. AM33xx
> *only* boots using DT so we leverage Jon's generic DT DMA helpers to
> register EDMA DMAC with the of_dma framework and then add support
> for calling the dma_request_slave_channel() API to both the mmc
> and spi drivers.
>
> With this series both BeagleBone and the AM335x EVM have working
> SPI DMA support (and MMC support with the separate MMC series).
>
> This is tested on BeagleBone with a SPI framebuffer driver and MMC
> rootfs. A trivial gpio DMA event misc driver was used to test the
> crossbar DMA event support. It is also tested on the AM335x EVM
> with the onboard SPI flash and MMC rootfs. The branch at
> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v7
> has the complete series, dependencies, and some test
> drivers/defconfigs. Note that MMC can only be tested with a
> separate MMC dmaengine/DT series applied.
>
> Regression testing was done on AM180x-EVM (which also makes use
> of the EDMA dmaengine driver and the EDMA private API) using SD,
> SPI flash, and the onboard audio supported by the ASoC Davinci
> driver. Regression testing was also done on a BeagleBoard xM
> booting from the legacy board file using MMC rootfs.
>
>
> Matt Porter (10):
> ARM: davinci: move private EDMA API to arm/common
> ARM: edma: remove unused transfer controller handlers
> ARM: edma: add AM33XX support to the private EDMA API
> dmaengine: edma: enable build for AM33XX
> dmaengine: edma: Add TI EDMA device tree binding
> ARM: dts: add AM33XX EDMA support
> dmaengine: add dma_request_slave_channel_compat()
> spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
> spi: omap2-mcspi: add generic DMA request support to the DT binding
> ARM: dts: add AM33XX SPI DMA support
>
> Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
> Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
> arch/arm/Kconfig |1 +
> arch/arm/boot/dts/am33xx.dtsi | 30 ++
> arch/arm/common/Kconfig|3 +
> arch/arm/common/Makefile |1 +
> arch/arm/{mach-davinci/dma.c => common/edma.c} | 342
> +---
> arch/arm/mach-davinci/Makefile |2 +-
> arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
> arch/arm/mach-davinci/davinci.h|2 +-
> arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
> arch/arm/mach-davinci/devices.c|6 +-
> arch/arm/mach-davinci/dm355.c |2 +-
> arch/arm/mach-davinci/dm365.c |2 +-
> arch/arm/mach-davinci/dm644x.c |2 +-
> arch/arm/mach-davinci/dm646x.c |2 +-
> arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
> arch/arm/plat-omap/Kconfig |1 +
> drivers/dma/Kconfig|2 +-
> drivers/dma/edma.c |2 +-
> drivers/mmc/host/davinci_mmc.c |1 +
> drivers/spi/spi-omap2-mcspi.c | 65 ++--
> include/linux/dmaengine.h | 16 +
> include/linux/mfd/davinci_voicecodec.h |3 +-
> .../mach => include/linux/platform_data}/edma.h| 90 +-
> include/linux/platform_data/spi-davinci.h |2 +-
> sound/soc/davinci/davinci-evm.c|1 +
> sound/soc/davinci/davinci-pcm.c|1 +
> sound/soc/davinci/davinci-pcm.h|
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Fri, Feb 01, 2013 at 06:41:08PM +, Tony Lindgren wrote: > * Matt Porter [130201 10:25]: > > Move mach-davinci/dma.c to common/edma.c so it can be used > > by OMAP (specifically AM33xx) as well. > > I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in plat-omap/dma.c. The actual dmaengine driver is in drivers/dma/edma.c as a wrapper around this...same way OMAP DMA engine conversion is being done. -Matt -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote: > Hello. > > On 02/01/2013 09:49 PM, Matt Porter wrote: > > >>> Move mach-davinci/dma.c to common/edma.c so it can be used > >>> by OMAP (specifically AM33xx) as well. > > >> I think this should rather go to drivers/dma/? > > > No, this is the private EDMA API. It's the analogous thing to > > the private OMAP dma API that is in plat-omap/dma.c. The actual > > dmaengine driver is in drivers/dma/edma.c as a wrapper around > > this...same way OMAP DMA engine conversion is being done. > > Keeps me wondering why we couldn't have the same with CPPI 4.1 when I > proposed > that, instead of waiting indefinitely for TI to convert it to drivers/dma/ > directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... > Sigh. That is a shame. Yeah, I've pointed out that I was doing this exactly the same way as was acceptable for the OMAP DMA conversion since it was in RFC. The reasons are sound since in both cases, we have many drivers to convert that need to continue using the private DMA APIs. -Matt > -- 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 0/3] omap_hsmmc DT DMA Client support
This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The series depends on the following patches: - dmaengine DT support and edma dmaengine driver fix from the git://git.infradead.org/users/vkoul/slave-dma.git next branch - dma_request_slave_channel_compat() support https://patchwork.kernel.org/patch/2081671/ The series with all dependencies can be found at https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1 Matt Porter (2): mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: add generic DMA request support to the DT binding Santosh Shilimkar (1): mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- drivers/mmc/host/omap_hsmmc.c | 38 2 files changed, 48 insertions(+), 16 deletions(-) -- 1.7.9.5 -- 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 3/3] mmc: omap_hsmmc: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..8c8908a 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+dmas: List of DMA specifiers with the controller specific format
+as described in the generic DMA client binding. A tx and rx
+specifier is required.
+dma-names: List of DMA request names. These strings correspond
+1:1 with the DMA specifiers listed in dmas. The string naming is
+to be "rx" and "tx" for RX and TX DMA requests, respectively.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,dual-volt;
+ bus-width = <4>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
@@ -30,4 +51,7 @@ Example:
bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
+ dmas = <&edma 24
+ &edma 25>;
+ dma-names = "tx", "rx";
};
--
1.7.9.5
--
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 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case
From: Santosh Shilimkar
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Signed-off-by: Santosh Shilimkar
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_conf_bus_power(host);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
- if (!res) {
- dev_err(mmc_dev(host->mmc), "cannot get DMA TX channel\n");
- ret = -ENXIO;
- goto err_irq;
- }
- tx_req = res->start;
+ if (!pdev->dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+ if (!res) {
+ dev_err(mmc_dev(host->mmc), "cannot get DMA TX
channel\n");
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ tx_req = res->start;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
- if (!res) {
- dev_err(mmc_dev(host->mmc), "cannot get DMA RX channel\n");
- ret = -ENXIO;
- goto err_irq;
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+ if (!res) {
+ dev_err(mmc_dev(host->mmc), "cannot get DMA RX
channel\n");
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ rx_req = res->start;
}
- rx_req = res->start;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
--
1.7.9.5
--
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/
