Messages in this thread | | | Date | Mon, 28 Jan 2008 08:10:24 -0500 | From | "Mike Frysinger" <> | Subject | Re: [rfc] exposing MMR's of on-chip peripherals for debugging purposes |
| |
On Jan 28, 2008 8:04 AM, richard kennedy <richard@rsk.demon.co.uk> wrote: > Mike Frysinger wrote: > > On Jan 28, 2008 5:40 AM, Bryan Wu <bryan.wu@analog.com> wrote: > >> On Mon, 2008-01-28 at 05:16 -0500, Mike Frysinger wrote: > >>> the trouble is that this file currently weighs in at ~1.8 megs. this > >>> is because it contains all the information for all Blackfin processors > >>> we support (which currently, is about ~23 variants). it's only going > >>> to get bigger as we support more. Bryan cringes at the thought of > >>> submitting it to LKML :). so i'm fishing around for alternatives ... > >>> the code was originally developed against 2.6.21, so UIO was not a > >>> possibility. i'm still not sure if it is ... i'd have to research it > >>> a bit more and play with things. > >> The main reason I am not willing to submit this to mainline is the file > >> size. It's almost the biggest file in the kernel source. And it will be > >> bigger and bigger when more and more new Blackfin processors supported > >> by Linux kernel. > > > > a quick check of current git shows it is significantly larger than any other ;) > > > >> My suggestion is: > >> Or more deeper thought: > >> - we don't need all the MMR setup at the same time for debugging. for example, maybe for some developer, he/she only needs one driver MMR for debugging such as watchdog/usb/spi/i2c .... > > > > splitting things up doesnt really address the original issue: there's > > a lot of info here to be kept in the kernel > > > >> - How about split the debug MMR table to each drivers or processors? > >> - watchdog driver implements a debug FS interface for debugging watchdog MMR and other drivers implement their own things. > > > > this had been mentioned before as a possibility but shot down. you do > > not want to tie the creation of these debug files to anything as the > > prevents independent development of any other drivers/application that > > use the same peripheral. > > there is a lot of duplication in your file, but you could slim it down a > bit if thats the only objection.
i imagine there's a ton of duplication ... the file is auto-generated from XML files, so i could take a look at the autogeneration producing unified code.
> so you could have a simple function to create all the COUNTER elements > from a given base address, then each variant only needs call that saving > you lots of LOC.
also a possibility ... just have to be wary of the parts that have slightly different peripherals (like the UART). -mike
| |