Re: [PATCH 00/23] RFC: exynos multiplatform support
On Friday 08 March 2013, Tomasz Figa wrote: I have a question regarding making this an MFD driver. As you know, the main clocksource driver must be initialized early, from init_time callback of machine_desc. How does using the MFD subsystem fit into this scheme? P.S. I'm still not convinced about any benefits of options 2 and 3 over option 1, which has the obvious advantage of requiring least amount of changes to existing code and not binding the PWM and clocksource drivers together (on Exynos SoCs only the PWM driver is used, clocksource is handled by different hardware block - MCT). I think the main motivation for the MFD here is that you have a shared register set, which would be described as a single device node in DT as its natural representation, but it's not easy to have two drivers be responsible for the same platform device. Similarly, the Linux resource handling tries hard to ensure that multiple device drivers do not share a single register set. If you have an MFD driver, that could bind do the platform_device created from the DT device node, and provide a simple interface for both the timer and the pwm driver to talk to, without exposing those registers directly. Or you could use the syscon regmap approach to expose those registers in a more controlled way. With syscon, you don't actually have to write an MFD driver but could just use the one that is already there. Since you want the timer driver to be available really early, you could also make that timer driver the master and expose an interface for the PWM driver to use. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Thursday 07 of March 2013 08:22:03 Thierry Reding wrote: On Thu, Mar 07, 2013 at 03:02:46AM +, Arnd Bergmann wrote: On Wednesday 06 March 2013, Thierry Reding wrote: Option 2 would probably come down to having a trivial MFD driver exposing a regmap. You can probably reuse drivers/mfd/syscon.c for this and make the node compatible with syscon to designate the clock registers as a system-wide resource, making the other device nodes register-less. I think option 2 is the standard method if one hardware block provides several logical devices. I find it to be a pretty nice solution to this problem. We also have precedent in the PWM subsystem. The TWL chips for instance use it to create a platform device which is later driven by a PWM driver. One difference though is that the TWL chip is a heterogenous MFD that has a lot of different sub-devices, where in case of Exynos the timer device has a set of identical units, each of which can be used either as a PWM or as a clocksource or other timer. I didn't know that. However I still making this an MFD driver is a good fit because it'll move the logic of defining the mode of each unit is kept in a parent driver which can instantiate the proper child devices for the corresponding subsystems. One big disadvantage of this approach is that if this is continued there is a risk that MFD will turn into a dump for all kinds of devices that provide more than a single service. So if people prefer option 3 I'm fine with it as well. I have a question regarding making this an MFD driver. As you know, the main clocksource driver must be initialized early, from init_time callback of machine_desc. How does using the MFD subsystem fit into this scheme? P.S. I'm still not convinced about any benefits of options 2 and 3 over option 1, which has the obvious advantage of requiring least amount of changes to existing code and not binding the PWM and clocksource drivers together (on Exynos SoCs only the PWM driver is used, clocksource is handled by different hardware block - MCT). Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Wed, Mar 06, 2013 at 10:50:42AM +, Arnd Bergmann wrote: On Tuesday 05 March 2013, Tomasz Figa wrote: On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: If none of these are needed for DT-based systems, we should probably build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol I introduced. Yes, none of them are needed for DT-based systems. Ah, good. I'll try to make more code conditional then. How are you planning to solve this? Do you want to have a combined driver that registers both a clocksource and a pwm? Let's start with a quick introduction to the s3c-pwm hardware. Each channel has its own timer value, compare and reload value registers, so they don't need any extra locking. However there are additional shared configuration registers, containing things such as start and reload bits for all channels, prescaler and main divisor values, etc. Those registers needs synchronization. Now there are several possible approaches: 1) A brute force one - two separate drivers, based on the fact that the clocksource driver will be used only on uniprocessor systems, so a simple _irqsave when accessing a shared register in both will guarantee correct synchronization. 2) Two separate drivers with some synchronized shared code accessing registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, etc.; all using a shared spinlock). 3) Single driver registering PWM channels, clocksource and clock event device. This does not seem like a bad idea, since the whole code for configuration of the PWM block would reside in one location and there would be no redundancy. However there is a question where such driver should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere else? Personally I wanted to go with first option, which would require least amount of changes to existing code, at a cost of some code duplication (but some PWM code is duplicated already). I would prefer option 3. That is also easier to implement with a straightforward DT binding that defines a single node with the clock registers. The location doesn't have an obvious answer, but I would probably put them into drivers/clocksource if the PWM maintainer agrees. Option 2 would probably come down to having a trivial MFD driver exposing a regmap. You can probably reuse drivers/mfd/syscon.c for this and make the node compatible with syscon to designate the clock registers as a system-wide resource, making the other device nodes register-less. I think option 2 is the standard method if one hardware block provides several logical devices. I find it to be a pretty nice solution to this problem. We also have precedent in the PWM subsystem. The TWL chips for instance use it to create a platform device which is later driven by a PWM driver. Thierry pgpbk06GdmLK5.pgp Description: PGP signature
Re: [PATCH 00/23] RFC: exynos multiplatform support
Am Dienstag, 5. März 2013, 23:48:45 schrieb Tomasz Figa: On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: On Tuesday 05 March 2013, Tomasz Figa wrote: With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported As far as I'm aware, there are plans to drop non-DT Exynos support. Kgene should know more on this. Yes, that was my understanding as well. It might not actually be too hard to get multiplatform working with the ATAGS based board files (we do that on some of the other platforms), but there is probably no reason to try hard. * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this We have several patches internally for fixing things up to run correclty with common-clk. I'll see if we can post some patches. Ok, excellent. * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already The legacy GPIO code is needed only for non-DT case. DT-case uses the new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. Please have a closer look at the ARM: exynos: work around missing gpio code on multiplatform patch, I think there a few files I had to touch that actually rely on the legacy gpio code: * the pm-gpio.c file * the s3c_i2c0_cfg_gpio function * the eint irqchip If none of these are needed for DT-based systems, we should probably build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol I introduced. Yes, none of them are needed for DT-based systems. * sparsemem support is not available on multiplatform There was some discussion some time ago whether we really need sparsemem on Exynos. If I remember correctly, it turned out that we don't. So this is not really an issue. Ok, good. Arnd Bergmann (23): ARM: exynos: introduce EXYNOS_ATAGS symbol irqchip: exynos: remove dependency on mach/irqs.h tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build ARM: exynos: move debug-macro.S to include/debug/ i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local spi: s3c64xx: move to generic dmaengine API pwm: samsung: repair the worst MMIO abuses I'm currently working (in my free time) on a series of cleanup patches sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and multiplatform) support. Ah, nice. On those platforms it is a bit more complex case as there are two blocks of code that access the same hardware - samsung-time (using two PWM channels for clocksource and clock events) and pwm-samsung. Hopefully, I will have some patches ready soon. How are you planning to solve this? Do you want to have a combined driver that registers both a clocksource and a pwm? Let's start with a quick introduction to the s3c-pwm hardware. Each channel has its own timer value, compare and reload value registers, so they don't need any extra locking. However there are additional shared configuration registers, containing things such as start and reload bits for all channels, prescaler and main divisor values, etc. Those registers needs synchronization. Now there are several possible approaches: 1) A brute force one - two separate drivers, based on the fact that the clocksource driver will be used only on uniprocessor systems, so a simple _irqsave when accessing a shared register in both will guarantee correct synchronization. 2) Two separate drivers with some synchronized shared code accessing registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, etc.; all using a shared spinlock). 3) Single driver registering PWM channels, clocksource and clock event device. This does not seem like a bad idea, since the whole code for configuration of the PWM block would reside in one location and there would be no redundancy. However there is a question where such driver should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere else? Personally I wanted to go with first option, which would require least amount of changes to existing code, at a cost of some code duplication (but some PWM code is duplicated already). Do you also want to include the prescaler and divider handling (that is currently sitting pwm-clock.c in plat-samsung) into this new driver? Because
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Wednesday 06 of March 2013 23:14:56 Heiko Stübner wrote: Am Dienstag, 5. März 2013, 23:48:45 schrieb Tomasz Figa: On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: On Tuesday 05 March 2013, Tomasz Figa wrote: With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported As far as I'm aware, there are plans to drop non-DT Exynos support. Kgene should know more on this. Yes, that was my understanding as well. It might not actually be too hard to get multiplatform working with the ATAGS based board files (we do that on some of the other platforms), but there is probably no reason to try hard. * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this We have several patches internally for fixing things up to run correclty with common-clk. I'll see if we can post some patches. Ok, excellent. * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already The legacy GPIO code is needed only for non-DT case. DT-case uses the new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. Please have a closer look at the ARM: exynos: work around missing gpio code on multiplatform patch, I think there a few files I had to touch that actually rely on the legacy gpio code: * the pm-gpio.c file * the s3c_i2c0_cfg_gpio function * the eint irqchip If none of these are needed for DT-based systems, we should probably build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol I introduced. Yes, none of them are needed for DT-based systems. * sparsemem support is not available on multiplatform There was some discussion some time ago whether we really need sparsemem on Exynos. If I remember correctly, it turned out that we don't. So this is not really an issue. Ok, good. Arnd Bergmann (23): ARM: exynos: introduce EXYNOS_ATAGS symbol irqchip: exynos: remove dependency on mach/irqs.h tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build ARM: exynos: move debug-macro.S to include/debug/ i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local spi: s3c64xx: move to generic dmaengine API pwm: samsung: repair the worst MMIO abuses I'm currently working (in my free time) on a series of cleanup patches sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and multiplatform) support. Ah, nice. On those platforms it is a bit more complex case as there are two blocks of code that access the same hardware - samsung-time (using two PWM channels for clocksource and clock events) and pwm-samsung. Hopefully, I will have some patches ready soon. How are you planning to solve this? Do you want to have a combined driver that registers both a clocksource and a pwm? Let's start with a quick introduction to the s3c-pwm hardware. Each channel has its own timer value, compare and reload value registers, so they don't need any extra locking. However there are additional shared configuration registers, containing things such as start and reload bits for all channels, prescaler and main divisor values, etc. Those registers needs synchronization. Now there are several possible approaches: 1) A brute force one - two separate drivers, based on the fact that the clocksource driver will be used only on uniprocessor systems, so a simple _irqsave when accessing a shared register in both will guarantee correct synchronization. 2) Two separate drivers with some synchronized shared code accessing registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, etc.; all using a shared spinlock). 3) Single driver registering PWM channels, clocksource and clock event device. This does not seem like a bad idea, since the whole code for configuration of the PWM block would reside in one location and there would be no redundancy. However there is a question where such driver should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere else? Personally I wanted to go with first option, which would require least amount of changes to
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Wednesday 06 of March 2013 13:34:26 Thierry Reding wrote: On Wed, Mar 06, 2013 at 10:50:42AM +, Arnd Bergmann wrote: On Tuesday 05 March 2013, Tomasz Figa wrote: On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: If none of these are needed for DT-based systems, we should probably build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol I introduced. Yes, none of them are needed for DT-based systems. Ah, good. I'll try to make more code conditional then. How are you planning to solve this? Do you want to have a combined driver that registers both a clocksource and a pwm? Let's start with a quick introduction to the s3c-pwm hardware. Each channel has its own timer value, compare and reload value registers, so they don't need any extra locking. However there are additional shared configuration registers, containing things such as start and reload bits for all channels, prescaler and main divisor values, etc. Those registers needs synchronization. Now there are several possible approaches: 1) A brute force one - two separate drivers, based on the fact that the clocksource driver will be used only on uniprocessor systems, so a simple _irqsave when accessing a shared register in both will guarantee correct synchronization. 2) Two separate drivers with some synchronized shared code accessing registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, etc.; all using a shared spinlock). 3) Single driver registering PWM channels, clocksource and clock event device. This does not seem like a bad idea, since the whole code for configuration of the PWM block would reside in one location and there would be no redundancy. However there is a question where such driver should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere else? Personally I wanted to go with first option, which would require least amount of changes to existing code, at a cost of some code duplication (but some PWM code is duplicated already). I would prefer option 3. That is also easier to implement with a straightforward DT binding that defines a single node with the clock registers. The location doesn't have an obvious answer, but I would probably put them into drivers/clocksource if the PWM maintainer agrees. Option 2 would probably come down to having a trivial MFD driver exposing a regmap. You can probably reuse drivers/mfd/syscon.c for this and make the node compatible with syscon to designate the clock registers as a system-wide resource, making the other device nodes register-less. I think option 2 is the standard method if one hardware block provides several logical devices. I find it to be a pretty nice solution to this problem. We also have precedent in the PWM subsystem. The TWL chips for instance use it to create a platform device which is later driven by a PWM driver. I prefer this option over 3), because current driver files could be easily reused (just cleaned up and moved into appropriate directories), which would minimize the amount of needed changes. Another reason for having two separate drivers is that on Exynos SoCs the PWM block is not used for timers at all, just for PWM outputs, so the whole part responsible for clocksource would be useless. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Wednesday 06 March 2013, Thierry Reding wrote: Option 2 would probably come down to having a trivial MFD driver exposing a regmap. You can probably reuse drivers/mfd/syscon.c for this and make the node compatible with syscon to designate the clock registers as a system-wide resource, making the other device nodes register-less. I think option 2 is the standard method if one hardware block provides several logical devices. I find it to be a pretty nice solution to this problem. We also have precedent in the PWM subsystem. The TWL chips for instance use it to create a platform device which is later driven by a PWM driver. One difference though is that the TWL chip is a heterogenous MFD that has a lot of different sub-devices, where in case of Exynos the timer device has a set of identical units, each of which can be used either as a PWM or as a clocksource or other timer. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Thu, Mar 07, 2013 at 03:02:46AM +, Arnd Bergmann wrote: On Wednesday 06 March 2013, Thierry Reding wrote: Option 2 would probably come down to having a trivial MFD driver exposing a regmap. You can probably reuse drivers/mfd/syscon.c for this and make the node compatible with syscon to designate the clock registers as a system-wide resource, making the other device nodes register-less. I think option 2 is the standard method if one hardware block provides several logical devices. I find it to be a pretty nice solution to this problem. We also have precedent in the PWM subsystem. The TWL chips for instance use it to create a platform device which is later driven by a PWM driver. One difference though is that the TWL chip is a heterogenous MFD that has a lot of different sub-devices, where in case of Exynos the timer device has a set of identical units, each of which can be used either as a PWM or as a clocksource or other timer. I didn't know that. However I still making this an MFD driver is a good fit because it'll move the logic of defining the mode of each unit is kept in a parent driver which can instantiate the proper child devices for the corresponding subsystems. One big disadvantage of this approach is that if this is continued there is a risk that MFD will turn into a dump for all kinds of devices that provide more than a single service. So if people prefer option 3 I'm fine with it as well. Thierry pgpMP5SktmGM4.pgp Description: PGP signature
Re: [PATCH 00/23] RFC: exynos multiplatform support
* Arnd Bergmann a...@arndb.de [130305 09:51]: Hi everyone, Although I'm not present at the Linaro Connect hacking sessions, I am participating remotely and have tried hacking on multiplatform support for Exynos. This patch set is far from complete, but I think the patches can be useful anyway. The series gets increasingly fishy towards the end, and we should probably not apply any of the last nine patches as-is, nor do I expect everything to work, since I have not tested them at all. With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already * Using the generic DMA engine API in SPI and ASoC means they no longer work on S3C * I did not like the solution for the UART driver, but could also not think of a better one. * The FB_S3C, S3C2410_WATCHDOG and S3C_ADC drivers are left as an exercise to the reader, they are currently disabled with multiplatform * sparsemem support is not available on multiplatform For booting, you might want to add fixing up of the initcalls to your checklist too as that can easily cause surprises to other SoCs. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
Hi Arnd, First of all, thanks for your great effort on making Exynos multiplatform- friendly. I have added my two cents inline. On Tuesday 05 of March 2013 18:42:10 Arnd Bergmann wrote: Hi everyone, Although I'm not present at the Linaro Connect hacking sessions, I am participating remotely and have tried hacking on multiplatform support for Exynos. This patch set is far from complete, but I think the patches can be useful anyway. The series gets increasingly fishy towards the end, and we should probably not apply any of the last nine patches as-is, nor do I expect everything to work, since I have not tested them at all. With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported As far as I'm aware, there are plans to drop non-DT Exynos support. Kgene should know more on this. * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this We have several patches internally for fixing things up to run correclty with common-clk. I'll see if we can post some patches. * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already The legacy GPIO code is needed only for non-DT case. DT-case uses the new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. * Using the generic DMA engine API in SPI and ASoC means they no longer work on S3C * I did not like the solution for the UART driver, but could also not think of a better one. * The FB_S3C, S3C2410_WATCHDOG and S3C_ADC drivers are left as an exercise to the reader, they are currently disabled with multiplatform * sparsemem support is not available on multiplatform There was some discussion some time ago whether we really need sparsemem on Exynos. If I remember correctly, it turned out that we don't. So this is not really an issue. The patches are based on v3.9-rc1 and I have pushed the git branch to git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git testing/exynos-multiplatform I have not yet added subsystem maintainers to Cc on the patches, I'd like to coordinate with the other people involved first, so see if they already have patches for the same drivers. Arnd Arnd Bergmann (23): ARM: exynos: introduce EXYNOS_ATAGS symbol irqchip: exynos: remove dependency on mach/irqs.h tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build ARM: exynos: move debug-macro.S to include/debug/ i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local spi: s3c64xx: move to generic dmaengine API pwm: samsung: repair the worst MMIO abuses I'm currently working (in my free time) on a series of cleanup patches sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and multiplatform) support. On those platforms it is a bit more complex case as there are two blocks of code that access the same hardware - samsung-time (using two PWM channels for clocksource and clock events) and pwm-samsung. Hopefully, I will have some patches ready soon. Best regards, -- Tomasz Figa Samsung Poland RD Center SW Solution Development, Kernel and System Framework ASoC: samsung: move plat/ headers to local directory ASoC: samsung: convert to dmaengine API ASoC: samsung: use irq resource for idma ARM: exynos: prepare for sparse IRQ ARM: exynos: hack to disable private clock code ARM: exynos: work around missing gpio code on multiplatform ARM: exynos: experimental multiplatform support arch/arm/Kconfig | 11 +- arch/arm/Kconfig.debug| 8 + arch/arm/include/debug/exynos.S | 39 +++ arch/arm/include/debug/samsung.S | 87 +++ arch/arm/mach-exynos/Kconfig | 36 ++- arch/arm/mach-exynos/Makefile | 5 + arch/arm/mach-exynos/common.c | 14 +- arch/arm/mach-exynos/common.h | 2 +- arch/arm/mach-exynos/dev-audio.c | 1 + arch/arm/mach-exynos/dev-uart.c | 1 + arch/arm/mach-exynos/include/mach/debug-macro.S | 39 --- arch/arm/mach-exynos/include/mach/gpio.h | 2 + arch/arm/mach-exynos/include/mach/irqs.h | 5 +- arch/arm/mach-exynos/mach-armlex4210.c| 3 + arch/arm/mach-exynos/mach-exynos4-dt.c| 2 + arch/arm/mach-exynos/mach-exynos5-dt.c| 2 +
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 March 2013, Tomasz Figa wrote: With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported As far as I'm aware, there are plans to drop non-DT Exynos support. Kgene should know more on this. Yes, that was my understanding as well. It might not actually be too hard to get multiplatform working with the ATAGS based board files (we do that on some of the other platforms), but there is probably no reason to try hard. * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this We have several patches internally for fixing things up to run correclty with common-clk. I'll see if we can post some patches. Ok, excellent. * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already The legacy GPIO code is needed only for non-DT case. DT-case uses the new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. Please have a closer look at the ARM: exynos: work around missing gpio code on multiplatform patch, I think there a few files I had to touch that actually rely on the legacy gpio code: * the pm-gpio.c file * the s3c_i2c0_cfg_gpio function * the eint irqchip If none of these are needed for DT-based systems, we should probably build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol I introduced. * sparsemem support is not available on multiplatform There was some discussion some time ago whether we really need sparsemem on Exynos. If I remember correctly, it turned out that we don't. So this is not really an issue. Ok, good. Arnd Bergmann (23): ARM: exynos: introduce EXYNOS_ATAGS symbol irqchip: exynos: remove dependency on mach/irqs.h tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build ARM: exynos: move debug-macro.S to include/debug/ i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local spi: s3c64xx: move to generic dmaengine API pwm: samsung: repair the worst MMIO abuses I'm currently working (in my free time) on a series of cleanup patches sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and multiplatform) support. Ah, nice. On those platforms it is a bit more complex case as there are two blocks of code that access the same hardware - samsung-time (using two PWM channels for clocksource and clock events) and pwm-samsung. Hopefully, I will have some patches ready soon. How are you planning to solve this? Do you want to have a combined driver that registers both a clocksource and a pwm? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 March 2013, Heiko Stübner wrote: If I remember correctly Kgene mentioning some time back, that someone was working on converting the s3c dma to dmaengine, but I never heard anything more about it. Ok, let's see if we can find out what happened to that. So personally I would be grateful, for people not breaking my devices :-) . I'm sure we can find a way. It's also clear that the current s3c_dma does not have a bright future. On an unrelated note, exists some sort of documentation for creating dmaengine drivers somewhere? Documentation/* seems to always be only targetted at device driver writers and my own DMA knowledge is still stuck at the theoretical level they teach in generic operating-systems university courses. I think we only have Documentation/dmaengine.txt, which is targetted at people using the dmaengine API, not at someone writing a driver. I have only limited experience myself, but I know that it comes down to filling the operations of a struct dma_device. A slight complication is that the dmaengine interface handles both memory-to-memory transfers and slave device transfers (the slave being the device that you are talking to), and you have to know which parts are relevant for your use case. You probably only need the slave interface, but it can seem like it's bolted to the side of the original API. drivers/dma/mxs-dma.c looks like a reasonable driver that one can use as an example. The s3c64xx_dma code is also interesting because it has both an implementation of the s3c_dma interface in arch/arm/mach-s3c64xx/dma.c and one using the generic interface in drivers/dma/amba-pl08x.c. The latter also implements a virtual channel concept that you probably don't need. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
Am Dienstag, 5. März 2013, 18:42:10 schrieb Arnd Bergmann: Hi everyone, Although I'm not present at the Linaro Connect hacking sessions, I am participating remotely and have tried hacking on multiplatform support for Exynos. This patch set is far from complete, but I think the patches can be useful anyway. The series gets increasingly fishy towards the end, and we should probably not apply any of the last nine patches as-is, nor do I expect everything to work, since I have not tested them at all. With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already * Using the generic DMA engine API in SPI and ASoC means they no longer work on S3C If I remember correctly Kgene mentioning some time back, that someone was working on converting the s3c dma to dmaengine, but I never heard anything more about it. So personally I would be grateful, for people not breaking my devices :-) . On an unrelated note, exists some sort of documentation for creating dmaengine drivers somewhere? Documentation/* seems to always be only targetted at device driver writers and my own DMA knowledge is still stuck at the theoretical level they teach in generic operating-systems university courses. Heiko * I did not like the solution for the UART driver, but could also not think of a better one. * The FB_S3C, S3C2410_WATCHDOG and S3C_ADC drivers are left as an exercise to the reader, they are currently disabled with multiplatform * sparsemem support is not available on multiplatform The patches are based on v3.9-rc1 and I have pushed the git branch to git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git testing/exynos-multiplatform I have not yet added subsystem maintainers to Cc on the patches, I'd like to coordinate with the other people involved first, so see if they already have patches for the same drivers. Arnd Arnd Bergmann (23): ARM: exynos: introduce EXYNOS_ATAGS symbol irqchip: exynos: remove dependency on mach/irqs.h tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build ARM: exynos: move debug-macro.S to include/debug/ i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local spi: s3c64xx: move to generic dmaengine API pwm: samsung: repair the worst MMIO abuses ASoC: samsung: move plat/ headers to local directory ASoC: samsung: convert to dmaengine API ASoC: samsung: use irq resource for idma ARM: exynos: prepare for sparse IRQ ARM: exynos: hack to disable private clock code ARM: exynos: work around missing gpio code on multiplatform ARM: exynos: experimental multiplatform support arch/arm/Kconfig | 11 +- arch/arm/Kconfig.debug| 8 + arch/arm/include/debug/exynos.S | 39 +++ arch/arm/include/debug/samsung.S | 87 +++ arch/arm/mach-exynos/Kconfig | 36 ++- arch/arm/mach-exynos/Makefile | 5 + arch/arm/mach-exynos/common.c | 14 +- arch/arm/mach-exynos/common.h | 2 +- arch/arm/mach-exynos/dev-audio.c | 1 + arch/arm/mach-exynos/dev-uart.c | 1 + arch/arm/mach-exynos/include/mach/debug-macro.S | 39 --- arch/arm/mach-exynos/include/mach/gpio.h | 2 + arch/arm/mach-exynos/include/mach/irqs.h | 5 +- arch/arm/mach-exynos/mach-armlex4210.c| 3 + arch/arm/mach-exynos/mach-exynos4-dt.c| 2 + arch/arm/mach-exynos/mach-exynos5-dt.c| 2 + arch/arm/mach-exynos/mach-nuri.c | 2 + arch/arm/mach-exynos/mach-origen.c| 3 + arch/arm/mach-exynos/mach-smdk4x12.c | 2 + arch/arm/mach-exynos/mach-smdkv310.c | 3 + arch/arm/mach-exynos/setup-i2c0.c | 3 +- arch/arm/mach-exynos/setup-sdhci-gpio.c | 2 +- arch/arm/mach-exynos/setup-usb-phy.c | 8 +- arch/arm/mach-s3c24xx/clock-s3c2440.c | 5 + arch/arm/mach-s3c24xx/common.c| 5 + arch/arm/mach-s3c24xx/dma-s3c2410.c | 2 - arch/arm/mach-s3c24xx/dma-s3c2412.c | 2 -
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 March 2013, Arnd Bergmann wrote: The s3c64xx_dma code is also interesting because it has both an implementation of the s3c_dma interface in arch/arm/mach-s3c64xx/dma.c and one using the generic interface in drivers/dma/amba-pl08x.c. This actually brings me to an interesting idea: the s3c64xx SPI driver is used with the regular dmaengine API and pl330 on S5P and Exynos, but with the s3c-dma interface and pl080 on S3C64xx. If we just convert S3C64xx to use the pl080 dmaengine driver instead, we can apply my SPI patch without breaking anything. We still need a solution for the ASoC drivers, but they are not as essential. We could probably move the wrapper files from plat-samsung/*dma*.c to sounds/soc/samsung when that becomes the only remaining user. There is also drivers/mmc/host/s3cmci.c, which uses the s3c-dma interface, but it is only used on s3c24xx, not s3c64xx or later. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 of March 2013 21:54:22 Arnd Bergmann wrote: On Tuesday 05 March 2013, Arnd Bergmann wrote: The s3c64xx_dma code is also interesting because it has both an implementation of the s3c_dma interface in arch/arm/mach-s3c64xx/dma.c and one using the generic interface in drivers/dma/amba-pl08x.c. This actually brings me to an interesting idea: the s3c64xx SPI driver is used with the regular dmaengine API and pl330 on S5P and Exynos, but with the s3c-dma interface and pl080 on S3C64xx. If we just convert S3C64xx to use the pl080 dmaengine driver instead, we can apply my SPI patch without breaking anything. AFAIR, the PL080 in S3C64xx is a slightly customized variant and requires some modifications to the driver. However I'm saying this only based on what I remember from the past, as I haven't checked current version of the driver yet, so it's possible that it has been modified already. I believe I will eventually have to take a look at it anyway, as it's a necessary step towards S3C64xx DT support. Best regards, Tomasz We still need a solution for the ASoC drivers, but they are not as essential. We could probably move the wrapper files from plat-samsung/*dma*.c to sounds/soc/samsung when that becomes the only remaining user. There is also drivers/mmc/host/s3cmci.c, which uses the s3c-dma interface, but it is only used on s3c24xx, not s3c64xx or later. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 March 2013, Tomasz Figa wrote: AFAIR, the PL080 in S3C64xx is a slightly customized variant and requires some modifications to the driver. However I'm saying this only based on what I remember from the past, as I haven't checked current version of the driver yet, so it's possible that it has been modified already. I believe I will eventually have to take a look at it anyway, as it's a necessary step towards S3C64xx DT support. Ok. Let me know if you need any help adding DT support to the pl08x driver. It would be nice to have that for SPEAr, Versatile and lpce32xx as well. All three currently have full DT support except for the DMA binding, since the common code for that was only added in 3.9-rc1. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
Am Dienstag, 5. März 2013, 22:54:22 schrieb Arnd Bergmann: On Tuesday 05 March 2013, Arnd Bergmann wrote: The s3c64xx_dma code is also interesting because it has both an implementation of the s3c_dma interface in arch/arm/mach-s3c64xx/dma.c and one using the generic interface in drivers/dma/amba-pl08x.c. This actually brings me to an interesting idea: the s3c64xx SPI driver is used with the regular dmaengine API and pl330 on S5P and Exynos, but with the s3c-dma interface and pl080 on S3C64xx. If we just convert S3C64xx to use the pl080 dmaengine driver instead, we can apply my SPI patch without breaking anything. The S3C24XX starting from S3C2443 (including S3C2416 and S3C2450) also use the s3c64xx-spi driver. My argument has of course the problem of me seemingly being the only user of it currently and it being stuff not in mainline yet [0] :-) . But on the other hand, it's no use anyway staying attached to old cruft, so it also wouldn't be a problem to go your way. I'll just try to come up with a dmaengine driver for s3c24xx after common-clk and pinctrl ;-) . [0] https://github.com/mmind/linux-es600/blob/topic/es600-devel/arch/arm/mach- s3c24xx/mach-as090.c#L138 We still need a solution for the ASoC drivers, but they are not as essential. We could probably move the wrapper files from plat-samsung/*dma*.c to sounds/soc/samsung when that becomes the only remaining user. In ASoC there is also a clear distinction between the different SoC generations. SND_SAMSUNG_I2S /_PCM /_AC97 ... is only used by newer SoCs while SND_S3C24XX_I2S and SND_S3C_I2SV2_SOC is used by the legacy SoCs. Of course my subarch is bitten again, as it's using the new sound interface, but the same as above applies. Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 March 2013, Heiko Stübner wrote: Am Dienstag, 5. März 2013, 22:54:22 schrieb Arnd Bergmann: On Tuesday 05 March 2013, Arnd Bergmann wrote: We still need a solution for the ASoC drivers, but they are not as essential. We could probably move the wrapper files from plat-samsung/*dma*.c to sounds/soc/samsung when that becomes the only remaining user. In ASoC there is also a clear distinction between the different SoC generations. SND_SAMSUNG_I2S /_PCM /_AC97 ... is only used by newer SoCs while SND_S3C24XX_I2S and SND_S3C_I2SV2_SOC is used by the legacy SoCs. Well, the only file that really needs to get changed is dma.c, which seems to be used by both the old and the new drivers. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/23] RFC: exynos multiplatform support
On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: On Tuesday 05 March 2013, Tomasz Figa wrote: With this patch set, we can build mach-exynos as part of a multiplatform kernel, with the following caveats: * Only DT based boards are supported As far as I'm aware, there are plans to drop non-DT Exynos support. Kgene should know more on this. Yes, that was my understanding as well. It might not actually be too hard to get multiplatform working with the ATAGS based board files (we do that on some of the other platforms), but there is probably no reason to try hard. * Moving to common-clk breaks things including cpufreq and others. Thomas is working on a patch for this We have several patches internally for fixing things up to run correclty with common-clk. I'll see if we can post some patches. Ok, excellent. * We disable the gpio implementation, which also breaks stuff, but Thomas has a patch already The legacy GPIO code is needed only for non-DT case. DT-case uses the new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. Please have a closer look at the ARM: exynos: work around missing gpio code on multiplatform patch, I think there a few files I had to touch that actually rely on the legacy gpio code: * the pm-gpio.c file * the s3c_i2c0_cfg_gpio function * the eint irqchip If none of these are needed for DT-based systems, we should probably build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol I introduced. Yes, none of them are needed for DT-based systems. * sparsemem support is not available on multiplatform There was some discussion some time ago whether we really need sparsemem on Exynos. If I remember correctly, it turned out that we don't. So this is not really an issue. Ok, good. Arnd Bergmann (23): ARM: exynos: introduce EXYNOS_ATAGS symbol irqchip: exynos: remove dependency on mach/irqs.h tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build ARM: exynos: move debug-macro.S to include/debug/ i2c: s3c2410: make header file local mmc: sdhci-s3c: remove platform dependencies usb: exynos: do not include plat/usb-phy.h [media] exynos: remove unnecessary header inclusions video/exynos: remove unnecessary header inclusions thermal/exynos: remove unnecessary header inclusions mtd: onenand/samsung: make regs-onenand.h file local rtc: s3c: make header file local spi: s3c64xx: move to generic dmaengine API pwm: samsung: repair the worst MMIO abuses I'm currently working (in my free time) on a series of cleanup patches sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and multiplatform) support. Ah, nice. On those platforms it is a bit more complex case as there are two blocks of code that access the same hardware - samsung-time (using two PWM channels for clocksource and clock events) and pwm-samsung. Hopefully, I will have some patches ready soon. How are you planning to solve this? Do you want to have a combined driver that registers both a clocksource and a pwm? Let's start with a quick introduction to the s3c-pwm hardware. Each channel has its own timer value, compare and reload value registers, so they don't need any extra locking. However there are additional shared configuration registers, containing things such as start and reload bits for all channels, prescaler and main divisor values, etc. Those registers needs synchronization. Now there are several possible approaches: 1) A brute force one - two separate drivers, based on the fact that the clocksource driver will be used only on uniprocessor systems, so a simple _irqsave when accessing a shared register in both will guarantee correct synchronization. 2) Two separate drivers with some synchronized shared code accessing registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, etc.; all using a shared spinlock). 3) Single driver registering PWM channels, clocksource and clock event device. This does not seem like a bad idea, since the whole code for configuration of the PWM block would reside in one location and there would be no redundancy. However there is a question where such driver should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere else? Personally I wanted to go with first option, which would require least amount of changes to existing code, at a cost of some code duplication (but some PWM code is duplicated already). Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
