Re: Custom pinmuxing on DM355 with git kernel
On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson michael.william...@criticallink.com wrote: On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Nori, Sekhar nsek...@ti.com writes: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. 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. Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. With the pinmux stuff in the board specific code, u-boot passes the board type into the kernel, so only the code that matches the specific board type is executed. I realized that I'm repeating my last post. Perhaps I don't fully understand your requirements. Regarding your comment about passing pinmux setting as a kernel parameter. Of course that can be done. you got the source code ;) The dangers are 1. The change would not be accepted by the community. 2. Potential maintenance issue with custom kernel. 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 Kevin's tree supports single binary that boots multiple DaVinci SoC. In other words, you can have a single binary with multiple boards (or SoCs) enabled. You can have a specific pinmux setting depends on the board type u-boot pass to the kernel in a single binary. Steve ___ 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
How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. Kevin, This reminds me of the discussions between you, Mark G, and Dave Brownell about dynamic pinmux setup and conflict detection. I seem to remember a comment regarding a change in clock setup (or was it some driver init) that would make a variant of dynamic pinmux setup in MVL Pro5 acceptable to the community. Just wondering if you remember any details. Steve ___ 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 Wed, Mar 17, 2010 at 8:17 AM, Steve Chen sc...@mvista.com wrote: On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson michael.william...@criticallink.com wrote: On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Nori, Sekhar nsek...@ti.com writes: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. 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. Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. With the pinmux stuff in the board specific code, u-boot passes the board type into the kernel, so only the code that matches the specific board type is executed. I realized that I'm repeating my last post. Perhaps I don't fully understand your requirements. Regarding your comment about passing pinmux setting as a kernel parameter. Of course that can be done. you got the source code ;) The dangers are 1. The change would not be accepted by the community. 2. Potential maintenance issue with custom kernel. Understood, and I have no desire to go this route. 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 Kevin's tree supports single binary that boots multiple DaVinci SoC. In other words, you can have a single binary with multiple boards (or SoCs) enabled. You can have a specific pinmux setting depends on the board type u-boot pass to the kernel in a single binary. My concern spawns from the fact that I can foresee maybe as many as 20 unique pinmux configurations for 1 specific davinci based SoM. This is based on real experience with older SoM's (not running a linux OS). These devices support a lot of permutations of pin assignments. If the right way is really to register 20 different machines over time and make 20 different board init files and submit them up, no problem. But it seems like it would become a headache managing that over time. I had a brief experience working with FreeScale parts that used a ROM device tree block, where this sort of configuration was read in at init and provided a way to define which peripherals on a SoC you wanted to use without having to rebuild the kernel (or worse, make a new machine type). It was't perfect, but seemed to work. I thought perhaps there was a similar approach available for the davincis. Thanks for the insight. -Mike ___ 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 Wed, Mar 17, 2010 at 7:17 AM, Mike Williamson michael.william...@criticallink.com wrote: On Wed, Mar 17, 2010 at 8:17 AM, Steve Chen sc...@mvista.com wrote: On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson michael.william...@criticallink.com wrote: On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Nori, Sekhar nsek...@ti.com writes: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. 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. Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. With the pinmux stuff in the board specific code, u-boot passes the board type into the kernel, so only the code that matches the specific board type is executed. I realized that I'm repeating my last post. Perhaps I don't fully understand your requirements. Regarding your comment about passing pinmux setting as a kernel parameter. Of course that can be done. you got the source code ;) The dangers are 1. The change would not be accepted by the community. 2. Potential maintenance issue with custom kernel. Understood, and I have no desire to go this route. 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 Kevin's tree supports single binary that boots multiple DaVinci SoC. In other words, you can have a single binary with multiple boards (or SoCs) enabled. You can have a specific pinmux setting depends on the board type u-boot pass to the kernel in a single binary. My concern spawns from the fact that I can foresee maybe as many as 20 unique pinmux configurations for 1 specific davinci based SoM. This is based on real experience with older SoM's (not running a linux OS). These devices support a lot of permutations of pin assignments. If the right way is really to register 20 different machines over time and make 20 different board init files and submit them up, no problem. But it seems like it would become a headache managing that over time. I did not know that there are so many permutations. Having a different machine for every permutations does not look like a good solution. I had a brief experience working with FreeScale parts that used a ROM device tree block, where this sort of configuration was read in at init and provided a way to define which peripherals on a SoC you wanted to use without having to rebuild the kernel (or worse, make a new machine type). It was't perfect, but seemed to work. I thought perhaps there was a similar approach available for the davincis. Thanks for the insight. In MVL Pro5, I embedded pinmux configuration in clock setup code. This provide the ability to dynamically setup pinmux as each device is loaded. There was also a provision to detect pinmux conflict. Because the patch abuses the clock API, it was rejected. Perhaps we should take another look at pinmux and explore the possibilities... whenever time permits :( Steve ___ 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
Steve Chen sc...@mvista.com writes: How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. Kevin, This reminds me of the discussions between you, Mark G, and Dave Brownell about dynamic pinmux setup and conflict detection. I seem to remember a comment regarding a change in clock setup (or was it some driver init) that would make a variant of dynamic pinmux setup in MVL Pro5 acceptable to the community. Just wondering if you remember any details. I don't remember anything that would make the MVL5 method acceptable. What I remember saying was that there was a new framework coming along that would generalize dynamic runtime PM features, allowing more than just clocks to be managed if desired. This framework is now in mainline, and is called runtime PM. I am currently working on the implementation for OMAP. There's an LWN article[1] covering the basics, and I'll also be giving a talk on runtime PM at ELC San Francisco in abouta month. Kevin [1] http://lwn.net/Articles/347573/ ___ 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
Mike Williamson michael.william...@criticallink.com writes: On Wed, Mar 17, 2010 at 8:17 AM, Steve Chen sc...@mvista.com wrote: On Fri, Mar 12, 2010 at 7:06 PM, Mike Williamson michael.william...@criticallink.com wrote: On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Nori, Sekhar nsek...@ti.com writes: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. 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. Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. With the pinmux stuff in the board specific code, u-boot passes the board type into the kernel, so only the code that matches the specific board type is executed. I realized that I'm repeating my last post. Perhaps I don't fully understand your requirements. Regarding your comment about passing pinmux setting as a kernel parameter. Of course that can be done. you got the source code ;) The dangers are 1. The change would not be accepted by the community. 2. Potential maintenance issue with custom kernel. Understood, and I have no desire to go this route. 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 Kevin's tree supports single binary that boots multiple DaVinci SoC. In other words, you can have a single binary with multiple boards (or SoCs) enabled. You can have a specific pinmux setting depends on the board type u-boot pass to the kernel in a single binary. My concern spawns from the fact that I can foresee maybe as many as 20 unique pinmux configurations for 1 specific davinci based SoM. This is based on real experience with older SoM's (not running a linux OS). These devices support a lot of permutations of pin assignments. If the right way is really to register 20 different machines over time and make 20 different board init files and submit them up, no problem. But it seems like it would become a headache managing that over time. Is there any way in SW to determine between the variants? If so, you don't need 20 different machine types, just a single one with runtime detection in the board file. I had a brief experience working with FreeScale parts that used a ROM device tree block, where this sort of configuration was read in at init and provided a way to define which peripherals on a SoC you wanted to use without having to rebuild the kernel (or worse, make a new machine type). It was't perfect, but seemed to work. I thought perhaps there was a similar approach available for the davincis. Thanks for the insight. One way or the other, you have to maintain *something* different for each variant. A separate u-boot, separate device tree or a separate pin-mux init in the kernel. Since we don't have device trees for ARM/Linux (not unique to davinci), I strongly prefer the latter. If you cannot detect the variant boards in SW, an alternate might be to use a single machine type but add a custom command-line option that just lists the variant. The kernel board file would use that option to set init the muxing. Kevin ___ Davinci-linux-open-source mailing list
Re: Custom pinmuxing on DM355 with git kernel
On Wed, Mar 17, 2010 at 8:37 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Steve Chen sc...@mvista.com writes: How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. Kevin, This reminds me of the discussions between you, Mark G, and Dave Brownell about dynamic pinmux setup and conflict detection. I seem to remember a comment regarding a change in clock setup (or was it some driver init) that would make a variant of dynamic pinmux setup in MVL Pro5 acceptable to the community. Just wondering if you remember any details. I don't remember anything that would make the MVL5 method acceptable. What I remember saying was that there was a new framework coming along that would generalize dynamic runtime PM features, allowing more than just clocks to be managed if desired. This framework is now in mainline, and is called runtime PM. I am currently working on the implementation for OMAP. There's an LWN article[1] covering the basics, and I'll also be giving a talk on runtime PM at ELC San Francisco in abouta month. Kevin [1] http://lwn.net/Articles/347573/ Kevin, Yes, runtime PM was it. I'll check out the link. Thanks, Steve ___ 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
Nori, Sekhar wrote: On Mon, Mar 15, 2010 at 07:47:44, Jon Povey wrote: - 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-sou...@linux.davincidsp.c om/msg11301.html .. and the response from Dave Brownell to that. http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11303.html Thanks for those useful archive links. How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. -- 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
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: Custom pinmuxing on DM355 with git kernel
On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman khil...@deeprootsystems.comwrote: Nori, Sekhar nsek...@ti.com writes: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. 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. Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. 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? -Mike ___ 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 Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.ukwrote: I am porting our drivers from MV 2.6.10 kernel to Kevin's git kernel. We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. I see in the git kernel that pinmux settings are defined in an array per-CPU (i.e. dm355.c) and the board file calls davinci_cfg_reg for those it wants setup. I'd like to build a single kernel which can support all of our board types, possibly detecting which it is running on by a parameter passed from u-boot. I could just update the hacks in our drivers, and our bootloader should setup the muxing right anyway, but if there is a supported right way to do this then I'd be interested to hear it. I like the debug warning messages if muxing is changed and feel like I should be using that code. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. Any thoughts welcome. thanks. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Regards, Steve ___ 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
Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Then I may extend the mux.c interface to support debugfs for reporting, and perhaps an owner name string. The mux.c interface could maintain a bitmap of claimed mux bits and warn/deny on conflicts like the gpiolib does. I recently found the gpiolib tracking of owners and debugfs support very useful, which inspired me to look at muxing in that way. Again comments are welcome, especially you're an idiot, do it like this instead or all fixed in arago, otherwise I will quietly hack away on my own and maybe submit a patch later. Cc'd KH as he seems to have been most active in mux.c recently. -- 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 Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. I don't think having drivers handle pinmux directly is acceptable at all. 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 may extend the mux.c interface to support debugfs for reporting, and perhaps an owner name string. The mux.c interface could maintain a bitmap of claimed mux bits and warn/deny on conflicts like the gpiolib does. Something like this was implemented (I think by Steve Chen) for MV kernel. It has not been submitted for upstream acceptance, but I do not seem to recall any major opposition to the idea (you should check the thread above). I recently found the gpiolib tracking of owners and debugfs support very useful, which inspired me to look at muxing in that way. Again comments are welcome, especially you're an idiot, do it like this instead or all fixed in arago, otherwise I will quietly hack away on my own and maybe submit a patch later. Cc'd KH as he seems to have been most active in mux.c recently. You didn't actually do it (I did now), but there should be no need to do that since he tracks this list pretty closely. 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
