Re: [PATCH 0/4] OMAP-GPMC generic timing migration
On 19.10.2012 17:34, Afzal Mohammed wrote: > Hi Daniel, > > On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote: > >> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I >> would like to augment this to make GPMC attached NAND probable in DT, in >> case this is still an open topic. > > In case you can help on making gpmc nand dt probable, please > proceed. I would be on vacation next week, may be we can > discuss after I am back. Enjoy your vacation :) > am335x based boards like beagle bone should be booting on > l-o master and it has gpmc header cleanup changes with > minimal driver support. > > As I don't have the sufficient time to explain in detail, some > pointers. Discussion between us [1] hopefully explains it in brief. > It would be like peripherals connected to gpmc being represented > as child nodes in dt. gpmc driver probably in probe would have to > invoke of_platform_populate to create child nodes (for devices like > nand). And driver would have to be enhanced to configure gpmc > based on information passed through dt for each child nodes. > Or roughly have a dt equivalent of driver as in [2]. Hmm, not sure if I follow all your thought here, but I cooked up something that is straight-forward and works well for me. I'll post them now, so we at least have a base for discussions ... Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Daniel, On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote: Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I would like to augment this to make GPMC attached NAND probable in DT, in case this is still an open topic. In case you can help on making gpmc nand dt probable, please proceed. I would be on vacation next week, may be we can discuss after I am back. am335x based boards like beagle bone should be booting on l-o master and it has gpmc header cleanup changes with minimal driver support. As I don't have the sufficient time to explain in detail, some pointers. Discussion between us [1] hopefully explains it in brief. It would be like peripherals connected to gpmc being represented as child nodes in dt. gpmc driver probably in probe would have to invoke of_platform_populate to create child nodes (for devices like nand). And driver would have to be enhanced to configure gpmc based on information passed through dt for each child nodes. Or roughly have a dt equivalent of driver as in [2]. One issue would be the memory resource creation by gpmc driver and which has to be provided to client resource data. And a decision has to be taken whether a generic routine is going to be used or initially a custom routine invocation based on child compatible fields would be sufficient. Regards Afzal [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74397.html [2] git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-drv-v6 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Daniel, On Wednesday 17 October 2012 08:43 PM, Daniel Mack wrote: On 17.10.2012 07:42, Afzal Mohammed wrote: I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though. Another thing that might be worth thinking about is that apart from the GPMC host controller and the peripherals, there could be other components like level shifters or series resistors on the board that limit the maximum speed of transactions. So in fact we might be better off storing all that timing details in the DT, as they are in fact highly application specific. Yes, making it future proof for these kind of scenarios was one of the reason's that initially triggered generic timing path. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Daniel Mack [121017 08:15]: > Hi Afzal, > > On 17.10.2012 07:42, Afzal Mohammed wrote: > > On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: > >> I certainly don't think it is easier, rather tougher, cleaner > >> as well. One thing that worried me was, if we pursue the > >> auxdata path (a last resort option) and later if it is > >> objected, we would be back to square one. > > > > I commented on auxdata usage without visualising in more > > detail how it can be implemented, it was bad of me. > > > > I doubt whether auxdata would help here, it seems using > > compatible field alone would help in deciding relevant > > custom timing routine. Whether we want this kind of > > peripheral knowledge in gpmc driver instead of using > > generic timing routine has to be decided though. > > Maybe slightly off-topic, but still: > > When GPMC is used for driving NAND chips that comply to CFI, the timings > could actually be derived from the connected peripheral as well. I > believe a slowest-possible-mode will have to be selected first for the > identication phase. I wish.. Just getting things working to the identification phase requires quite a bit of configuration for the timings. > Another thing that might be worth thinking about is that apart from the > GPMC host controller and the peripherals, there could be other > components like level shifters or series resistors on the board that > limit the maximum speed of transactions. So in fact we might be better > off storing all that timing details in the DT, as they are in fact > highly application specific. Yes and the level shifters affect timings too. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Afzal, On 17.10.2012 07:42, Afzal Mohammed wrote: > On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: >> I certainly don't think it is easier, rather tougher, cleaner >> as well. One thing that worried me was, if we pursue the >> auxdata path (a last resort option) and later if it is >> objected, we would be back to square one. > > I commented on auxdata usage without visualising in more > detail how it can be implemented, it was bad of me. > > I doubt whether auxdata would help here, it seems using > compatible field alone would help in deciding relevant > custom timing routine. Whether we want this kind of > peripheral knowledge in gpmc driver instead of using > generic timing routine has to be decided though. Maybe slightly off-topic, but still: When GPMC is used for driving NAND chips that comply to CFI, the timings could actually be derived from the connected peripheral as well. I believe a slowest-possible-mode will have to be selected first for the identication phase. Another thing that might be worth thinking about is that apart from the GPMC host controller and the peripherals, there could be other components like level shifters or series resistors on the board that limit the maximum speed of transactions. So in fact we might be better off storing all that timing details in the DT, as they are in fact highly application specific. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one. I commented on auxdata usage without visualising in more detail how it can be implemented, it was bad of me. I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though. Let me discuss internally and get back. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Monday 15 October 2012 09:31 PM, Tony Lindgren wrote: * Mohammed, Afzal [121015 05:42]: On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote: Yes, then please do a second pull request for what's needed to apply the minimal DT bindings. For the DT binding, let's just leave out the timings for now as we can load those from auxdata. Then the binding for the timings can be added later on. So just the minimal binding using standard features for the iorange and interrupt. Ok, I will keep timings aside for now and proceed with DT (avoiding auxdata usage with generic routine looked to me a saner approach though, with an initial DT'fy delay) Oh well if you think it's easier to do the timings too in the DT binding, please go ahead with that. It may take some longer discussion on the lists for the binding though. But up to you. I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one. Let me discuss internally and get back. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Mohammed, Afzal [121015 05:42]: > Hi Tony, > > On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote: > > * Mohammed, Afzal [121011 05:48]: > > > After -rc1 is out, let's plan on adding the minimal > > set required for removing plat and mach includes from > > drivers into a clean-up branch. Afzal, can you maybe > > do a pull request for that set against -rc1 when it's > > out? Just the minimal set of patches. > > Pull request on gpmc cleanup for common ARM zImage has > been sent. Thanks. > > Yes, then please do a second pull request for what's needed > > to apply the minimal DT bindings. For the DT binding, let's > > just leave out the timings for now as we can load those from > > auxdata. Then the binding for the timings can be added > > later on. So just the minimal binding using standard features > > for the iorange and interrupt. > > Ok, I will keep timings aside for now and proceed with DT > (avoiding auxdata usage with generic routine looked to me a > saner approach though, with an initial DT'fy delay) Oh well if you think it's easier to do the timings too in the DT binding, please go ahead with that. It may take some longer discussion on the lists for the binding though. But up to you. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote: > * Mohammed, Afzal [121011 05:48]: > After -rc1 is out, let's plan on adding the minimal > set required for removing plat and mach includes from > drivers into a clean-up branch. Afzal, can you maybe > do a pull request for that set against -rc1 when it's > out? Just the minimal set of patches. Pull request on gpmc cleanup for common ARM zImage has been sent. > Yes, then please do a second pull request for what's needed > to apply the minimal DT bindings. For the DT binding, let's > just leave out the timings for now as we can load those from > auxdata. Then the binding for the timings can be added > later on. So just the minimal binding using standard features > for the iorange and interrupt. Ok, I will keep timings aside for now and proceed with DT (avoiding auxdata usage with generic routine looked to me a saner approach though, with an initial DT'fy delay) Regards Afzal
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Mohammed, Afzal [121011 05:48]: > Hi Daniel, > > On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote: > > > Admittedly, I lost track on the multiple GPMC series here, and they also > > cause major merge conflicts with Linus' current master branch. > > > > Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I > > Series [1-2] plus this series would be the required. > Note that 1st patch of series [2] has already reached mainline. > > Another easy way would be, pull, > git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing > > git checkout -b gpmc > git rebase --onto next-20121005 (or "080aa9c") After -rc1 is out, let's plan on adding the minimal set required for removing plat and mach includes from drivers into a clean-up branch. Afzal, can you maybe do a pull request for that set against -rc1 when it's out? Just the minimal set of patches. > > would like to augment this to make GPMC attached NAND probable in DT, in > > case this is still an open topic. > > I would be doing gpmc DT conversion next. Hoping that this > series too will be picked up by Tony, as once this series is > accepted, during DT conversion we need not rely on > auxdata (a last resort option) for timings. Yes, then please do a second pull request for what's needed to apply the minimal DT bindings. For the DT binding, let's just leave out the timings for now as we can load those from auxdata. Then the binding for the timings can be added later on. So just the minimal binding using standard features for the iorange and interrupt. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Daniel, On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote: > Admittedly, I lost track on the multiple GPMC series here, and they also > cause major merge conflicts with Linus' current master branch. > > Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I Series [1-2] plus this series would be the required. Note that 1st patch of series [2] has already reached mainline. Another easy way would be, pull, git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing git checkout -b gpmc git rebase --onto next-20121005 (or "080aa9c") > would like to augment this to make GPMC attached NAND probable in DT, in > case this is still an open topic. I would be doing gpmc DT conversion next. Hoping that this series too will be picked up by Tony, as once this series is accepted, during DT conversion we need not rely on auxdata (a last resort option) for timings. > Thanks for you hard work, Thanks, it was a pleasure to read the above. Regards Afzal [1] http://marc.info/?l=linux-omap&m=134945131602622&w=2 [2] http://marc.info/?l=linux-omap&m=134967458329531&w=2
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi, On 05.10.2012 18:00, Afzal Mohammed wrote: > This series provides a generic gpmc timing calculation routine. There > were three peripherals (OneNAND, tusb6010, smc91x) using custom timing > calculations, they are migrated to use the generic timing calculation. > > Such a generic routine would help create a driver out of gpmc platform > code, which would be peripheral agnostic and thus lead to DT finally. > Input to generic timing calculation routine would be gpmc peripheral > timings, output - translated timings that gpmc can understand. Later, > to DT'ify, gpmc peripheral timings could be passed through DT. Input > timings that has been used here are selected such that it represents > those that are present in peripheral timing datasheets. Admittedly, I lost track on the multiple GPMC series here, and they also cause major merge conflicts with Linus' current master branch. Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I would like to augment this to make GPMC attached NAND probable in DT, in case this is still an open topic. Thanks for you hard work, Daniel > This series has been created by pulling out last 4 patches in v7 > of the series, > "OMAP-GPMC: generic time calc, prepare for driver" > This was done to have easy path for common zImage gpmc cleanup patches. > > Proposed generic routine has been tested on OneNAND (async) on > OMAP3EVM rev C (as mainline does not have the OneNAND support for this, > local patch were used to test). For other cases of custom timing > calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing > calculation routine was verified by simulating on OMAP3EVM. > > This series is available > @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1 > and is based on > linux-next (next-20121005) > and is dependent on > http://marc.info/?l=linux-omap&m=134945131602622&w=2 > http://marc.info/?l=linux-omap&m=134945239306131&w=2 > > This series as such is only the first version, but these patches has > already undergone one change before being made as this series. The > change was in using ps instead of ns to prevent rounding errors. > Also along with this series documentation has been improved. > > Regards > Afzal > > > Afzal Mohammed (4): > ARM: OMAP2+: gpmc: generic timing calculation > ARM: OMAP2+: onenand: generic timing calculation > ARM: OMAP2+: smc91x: generic timing calculation > ARM: OMAP2+: tusb6010: generic timing calculation > > Documentation/bus-devices/ti-gpmc.txt | 122 + > arch/arm/mach-omap2/gpmc-onenand.c| 124 + > arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++--- > arch/arm/mach-omap2/gpmc.c| 325 > ++ > arch/arm/mach-omap2/gpmc.h| 102 --- > arch/arm/mach-omap2/usb-tusb6010.c| 182 +-- > 6 files changed, 633 insertions(+), 265 deletions(-) > create mode 100644 Documentation/bus-devices/ti-gpmc.txt > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Tuesday 09 October 2012 08:31 AM, Tony Lindgren wrote: * Afzal Mohammed [121005 09:02]: Proposed generic routine has been tested on OneNAND (async) on OMAP3EVM rev C (as mainline does not have the OneNAND support for this, local patch were used to test). For other cases of custom timing calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing calculation routine was verified by simulating on OMAP3EVM. Have you tested to make sure this works if you change the L3 frequency? With changed L3 frequency it was not tested. I do not have a single board that is supported in mainline that calculates on the run gpmc timing from device timing. What has been tested here is OneNAND working in asynchronous mode on omap3evm, but it's support is not available in mainline, so private patch had to be used to test it. All other peripherals were tested by simulation, i.e. by comparing output from existing custom timing routine & generic routine for particular frequencies. That should probably be tested as a sanity check. Maybe you can force the L3 for some test boots for this, I don't think we scale it by default. On omap3evm, don't know whether L3 frequency can be changed & still have a working Kernel. I am not sure whether it is worth attempting as OneNAND on omap3evm is not supported in mainline. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Afzal Mohammed [121005 09:02]: > > Proposed generic routine has been tested on OneNAND (async) on > OMAP3EVM rev C (as mainline does not have the OneNAND support for this, > local patch were used to test). For other cases of custom timing > calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing > calculation routine was verified by simulating on OMAP3EVM. Have you tested to make sure this works if you change the L3 frequency? That should probably be tested as a sanity check. Maybe you can force the L3 for some test boots for this, I don't think we scale it by default. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
