RE: Custom pinmuxing on DM355 with git kernel
Kevin Hilman wrote: Nori, Sekhar nsek...@ti.com writes: I don't think having drivers handle pinmux directly is acceptable at all. Correct. Drivers should not do muxing. This should be done by SoC or board init code. If your bootloader is doing it, that suggests that it is init-time only, and should be done in init code. I still think splitting davinci_cfg_reg() they way you describe may have some merit in terms of code organization, but I fail to see where it will be useful (at least in the current kernel). I'm all for cleaning up the mux code, but I'm with Sekhar and don't currently understand the use case you're proposing. My thoughts are a bit wooly, but Mike Williamson seems to be thinking similar thoughts: Mike Williamson wrote: Having a pile of custom machines (kernel configurations) for every permutation seems painful if all they are doing is enabling different devices. I sort of thought the point of modular kernel drivers was to provide pluggable support for dynamic device control. I appreciate that someone needs to keep track of the resources, but couldn't there be some sort of allocation mechanism to allow drivers to test and see if they can have a set of resources before using them, much like the gpiolib? I am not sure I actually need it for what I'm doing right now, but having a supported way to change pinmuxing outside of board init seems like a good thing for boards where the wiring can support it. I can imagine designs that might. Also like the gpiolib something seems not quite right in the way pinmuxing is done now; you need to remember to set it up right in your board init code otherwise things will fail to work in confusing ways. I can imagine how it might work, but this would perhaps be epic overkill: - Board init would setup pinmuxing resource structures that could be passed to drivers, something like gpio, but supporting the different DaVinci devices (insert handwaving here) - Device driver can callback to request / release its mux resources - mux layer can print/warn/bug for debug if claimed resources conflict Aplogies if this is all very wrongheaded. I am still getting to grips with the provided APIs, attempting to specify a new one is a stretch. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Custom pinmuxing on DM355 with git kernel
On Mon, Mar 15, 2010 at 07:47:44, Jon Povey wrote: Kevin Hilman wrote: Nori, Sekhar nsek...@ti.com writes: I don't think having drivers handle pinmux directly is acceptable at all. Correct. Drivers should not do muxing. This should be done by SoC or board init code. If your bootloader is doing it, that suggests that it is init-time only, and should be done in init code. I still think splitting davinci_cfg_reg() they way you describe may have some merit in terms of code organization, but I fail to see where it will be useful (at least in the current kernel). I'm all for cleaning up the mux code, but I'm with Sekhar and don't currently understand the use case you're proposing. My thoughts are a bit wooly, but Mike Williamson seems to be thinking similar thoughts: Mike Williamson wrote: Having a pile of custom machines (kernel configurations) for every permutation seems painful if all they are doing is enabling different devices. I sort of thought the point of modular kernel drivers was to provide pluggable support for dynamic device control. I appreciate that someone needs to keep track of the resources, but couldn't there be some sort of allocation mechanism to allow drivers to test and see if they can have a set of resources before using them, much like the gpiolib? I am not sure I actually need it for what I'm doing right now, but having a supported way to change pinmuxing outside of board init seems like a good thing for boards where the wiring can support it. I can imagine designs that might. Also like the gpiolib something seems not quite right in the way pinmuxing is done now; you need to remember to set it up right in your board init code otherwise things will fail to work in confusing ways. I can imagine how it might work, but this would perhaps be epic overkill: - Board init would setup pinmuxing resource structures that could be passed to drivers, something like gpio, but supporting the different DaVinci devices (insert handwaving here) - Device driver can callback to request / release its mux resources - mux layer can print/warn/bug for debug if claimed resources conflict Aplogies if this is all very wrongheaded. I am still getting to grips with the provided APIs, attempting to specify a new one is a stretch. As far as possible, the interfaces to device drivers should not be SoC specific ones, but should be portable across platforms and architectures. So, what you are proposing needs to be an interface defined in include/linux/* and cannot be DaVinci specific. The problem is there is no cross-platform framework for handling pin as a resource defined yet. Currently, every platform that runs into this solves it in its own way. Have a look at this post from the thread I posted earlier.. http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11301.html .. and the response from Dave Brownell to that. http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11303.html Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: edma: clear interrupt status for interrupt enabled channels only
On Fri, Mar 12, 2010 at 23:33:10, Kevin Hilman wrote: Sekhar Nori nsek...@ti.com writes: From: Anuj Aggarwal anuj.aggar...@ti.com Currently, the ISR in the EDMA driver clears the pending interrupt for all channels without regard to whether that channel has a registered callback or not. This causes problems for devices like DM355/DM365 where the multimedia accelerator uses EDMA by polling on the interrupt pending bits of some of the EDMA channels. Since these channels are actually allocated through the Linux EDMA driver (by an out-of-kernel module), the same shadow region is used by Linux and accelerator. There a race between the Linux ISR and the polling code running on the accelerator on the IPR (interrupt pending register). This patch fixes the issue by making the ISR clear the interrupts only for those channels which have interrupt enabled. The channels which are allocated for the purpose of being polled on by the accelerator will not have a callback function provided and so will not have IER (interrupt enable register) bits set. Dumb question: why cat the MM accelerator use the normal ISR + callback? There is some OS-less code running on the accelerator. I believe (at least some parts of) the accelerator cannot even see the DDR so having an OS implemented there seems far fetched. Without an OS in place, it is easier to poll on EDMA IPR bits. Having Linux handle the interrupt brings in IPC mechanisms which again needs an OS running on the other side and is also seen as detrimental to performance. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davinci git updated to v2.6.34-rc1
On Mon, Mar 15, 2010 at 07:54:57, Jon Povey wrote: Kevin Hilman wrote: Raffaele Recalcati lamiapost...@gmail.com writes: I see you are talking about: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git and not: http://arago-project.org/git/projects/linux-davinci.git Correct. As pointed out elsewhere, the arago tree is a TI development tree and includes several things that are not ready for upstream or work in progress etc. This gets asked and answered quite a bit, including by me. I did a bit of wiki-work this morning, improvements encouraged to http://wiki.davincidsp.com/index.php/Linux_Toolchain#Linux_Kernel Hmm, did not realize this is documented here so far. Thanks! The details look pretty complete to me. What would you would like to see added there? Information on submitting patches upstream is documented here: http://wiki.davincidsp.com/index.php/Patch_upstream_sending Note that this is a public wiki, so modifications can be made by anyone in the community (not just TI folks). Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
