Re: [PATCH] tty: Fallback to use dynamic major number
On Thu, Jan 16, 2014 at 09:22:40AM -0800, Greg KH wrote: > On Thu, Jan 16, 2014 at 05:08:14PM +, Mark Brown wrote: > > No, the issue is happening because the drivers are registering things > > at module load time and not at device instantiation time. > That's a driver bug that could easily be fixed, instead of hacking up > the tty core :) Looking at the code it really, really looked intentional - in any case that seems worthwhile, Tushar this looks like a way forwards? > > While the drivers won't actually be run together things like the > > multiplatform defconfig and distro configs will build them in since > > people tend to like to get serial early on. > Build them into the kernel and not as modules? Yes. It's the common case for embedded stuff to just build everything in so people tend to do it. > > The other solutions I can think of are moving tty_register_driver() to > > device probe time, allowing tty_register_driver() to accept duplicate > > majors and the complaining when the devices actually get instantiated > > or changing major numbers where there is a duplicate which is guaranteed > > to break at least some userspaces with static devices (which was the > > original patch you complained about). The first two solutions look a > > bit fun though perhaps they fall out more easily than I suspect. > How about fixing the drivers as I mentioned above, to not register with > the uart or tty core until they know that their hardware is actually > present in the system? That would keep any tty core "hacks" from being > needed. Certainly makes sense to me. I have to confess that looking at the code it looked totally intentional and I remember dragons from the last time I had to peer into that stuff. signature.asc Description: Digital signature
Re: [PATCH] tty: Fallback to use dynamic major number
On Thu, Jan 16, 2014 at 05:08:14PM +, Mark Brown wrote: > On Thu, Jan 16, 2014 at 08:18:41AM -0800, Greg KH wrote: > > On Thu, Jan 16, 2014 at 10:33:22AM +0530, Tushar Behera wrote: > > > In a multi-platform scenario, the hard-coded major/minor numbers in > > > serial drivers may conflict with each other. A typical scenario is > > > observed with amba-pl011 and samsung-uart drivers, both of these > > > drivers use same set of major/minor numbers. If both of these drivers > > > are enabled, probe of samsung-uart driver fails because the desired > > > node is busy. > > > Why would both drivers ever be loaded at the same time? Don't they bind > > to different hardware devices, and as such, never will be in the same > > system? > > No, the issue is happening because the drivers are registering things > at module load time and not at device instantiation time. That's a driver bug that could easily be fixed, instead of hacking up the tty core :) > While the drivers won't actually be run together things like the > multiplatform defconfig and distro configs will build them in since > people tend to like to get serial early on. Build them into the kernel and not as modules? > > The driver shouldn't be registering it's tty devices if the hardware > > isn't present in the system, so how can this codepath ever happen? > > A quick and unscientific poll of serial drivers seems to suggest that > uart_register_driver() is normally called when the module is loaded (if > it shouldn't be this is at least a very common error pattern). It's a common error pattern :) > > > The issue is fixed by adding a fallback in driver core, so that we can > > > use dynamic major number in case device node allocation fails for > > > hard-coded major/minor number. > > > Did you test this out? You still get userspace breakage with it :( > > Yes. I should put my hands up and say that this was my idea. The > theory is that any system using static allocation for a device shouldn't > be affected (modulo races, it's not perfect obviously), any currently > broken system with a userspace with a dynamic dev will start working and > any breakage is confined to drivers which duplicated major numbers (and > even then only on systems with static /dev). > > The other solutions I can think of are moving tty_register_driver() to > device probe time, allowing tty_register_driver() to accept duplicate > majors and the complaining when the devices actually get instantiated > or changing major numbers where there is a duplicate which is guaranteed > to break at least some userspaces with static devices (which was the > original patch you complained about). The first two solutions look a > bit fun though perhaps they fall out more easily than I suspect. How about fixing the drivers as I mentioned above, to not register with the uart or tty core until they know that their hardware is actually present in the system? That would keep any tty core "hacks" from being needed. thanks, greg k-h -- 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] tty: Fallback to use dynamic major number
On Thu, Jan 16, 2014 at 08:18:41AM -0800, Greg KH wrote: > On Thu, Jan 16, 2014 at 10:33:22AM +0530, Tushar Behera wrote: > > In a multi-platform scenario, the hard-coded major/minor numbers in > > serial drivers may conflict with each other. A typical scenario is > > observed with amba-pl011 and samsung-uart drivers, both of these > > drivers use same set of major/minor numbers. If both of these drivers > > are enabled, probe of samsung-uart driver fails because the desired > > node is busy. > Why would both drivers ever be loaded at the same time? Don't they bind > to different hardware devices, and as such, never will be in the same > system? No, the issue is happening because the drivers are registering things at module load time and not at device instantiation time. While the drivers won't actually be run together things like the multiplatform defconfig and distro configs will build them in since people tend to like to get serial early on. > The driver shouldn't be registering it's tty devices if the hardware > isn't present in the system, so how can this codepath ever happen? A quick and unscientific poll of serial drivers seems to suggest that uart_register_driver() is normally called when the module is loaded (if it shouldn't be this is at least a very common error pattern). This in turn calls tty_register_driver() which checks for duplicates in major prior to any device being instantiated. Simply having the module present is enough to cause problems. > > The issue is fixed by adding a fallback in driver core, so that we can > > use dynamic major number in case device node allocation fails for > > hard-coded major/minor number. > Did you test this out? You still get userspace breakage with it :( Yes. I should put my hands up and say that this was my idea. The theory is that any system using static allocation for a device shouldn't be affected (modulo races, it's not perfect obviously), any currently broken system with a userspace with a dynamic dev will start working and any breakage is confined to drivers which duplicated major numbers (and even then only on systems with static /dev). The other solutions I can think of are moving tty_register_driver() to device probe time, allowing tty_register_driver() to accept duplicate majors and the complaining when the devices actually get instantiated or changing major numbers where there is a duplicate which is guaranteed to break at least some userspaces with static devices (which was the original patch you complained about). The first two solutions look a bit fun though perhaps they fall out more easily than I suspect. signature.asc Description: Digital signature
Re: [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
Hi Tomasz,
thank you for posting this series. I would like to use the DT bindings
for power domains in the bindings for C-states on ARM:
http://comments.gmane.org/gmane.linux.power-management.general/41012
and in particular link a given C-state to a given power domain so that the
kernel will have a way to actually check what devices are lost upon C-state
entry (and for devices I also mean CPU peripheral like PMUs, GIC CPU IF,
caches and possibly cpus, all of them already represented with DT nodes).
I have a remark:
- Can we group device nodes under a single power-domain-parent so that
all devices defined under that parent won't have to re-define a
power-domain property (a property like interrupt-parent, so to speak)
What do you think ?
Thanks,
Lorenzo
On Sat, Jan 11, 2014 at 07:42:46PM +, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/power/power_domain.txt | 51
> drivers/base/power/domain.c| 339
> +
> include/linux/pm_domain.h | 34 +++
> kernel/power/Kconfig | 4 +
> 4 files changed, 428 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> + Typically 0 for nodes representing a single power domain and 1 for nodes
> + providing multiple power domains (e.g. power controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
> +
> +Example:
> +
> + power: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> + of power controller specified by phandle.
> +
> +Example:
> +
> + leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domain = <&power 0>;
> + };
> +
> +The node above defines a typical power domain consumer device, which is
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index bfb8955..6d47498 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3,12 +3,16 @@
> *
> * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics
> Corp.
> *
> + * Support for Device Tree based power domain providers:
> + * Copyright (C) 2014 Tomasz Figa
> + *
> * This file is released under the GPLv2.
> */
>
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2177,3 +2181,338 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(&genpd->gpd_list_node, &gpd_list);
> mutex_unlock(&gpd_list_lock);
> }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
> + *
> + * Th
Re: [PATCH] tty: Fallback to use dynamic major number
On Thu, Jan 16, 2014 at 10:33:22AM +0530, Tushar Behera wrote: > In a multi-platform scenario, the hard-coded major/minor numbers in > serial drivers may conflict with each other. A typical scenario is > observed with amba-pl011 and samsung-uart drivers, both of these > drivers use same set of major/minor numbers. If both of these drivers > are enabled, probe of samsung-uart driver fails because the desired > node is busy. Why would both drivers ever be loaded at the same time? Don't they bind to different hardware devices, and as such, never will be in the same system? The driver shouldn't be registering it's tty devices if the hardware isn't present in the system, so how can this codepath ever happen? > The issue is fixed by adding a fallback in driver core, so that we can > use dynamic major number in case device node allocation fails for > hard-coded major/minor number. Did you test this out? You still get userspace breakage with it :( > Signed-off-by: Tushar Behera > --- > Hi Greg, > > This is my second attempt at getting this fixed. Let me know if you are > okay with this. > > Initial approach to fix this problem was by forcing samsung-uart driver > to use dynamic major number, but it was rejected [1] because of possible > user-space breakage. "possible"? Heh, no, that should be "real". Sorry, but I think you are trying to fix a problem that never actually happens in real life, or in valid configurations... greg k-h -- 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 v12 0/7] cpufreq:boost: CPU Boost mode support
Hi Rafael, > On Thursday, January 16, 2014 10:40:08 AM Lukasz Majewski wrote: > > Hi Rafael, > > > > > On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote: > > > > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > > > > Hi Rafael, > > > > > > > > Hi, > > > > > > > > > > This patch series introduces support for CPU overclocking > > > > > > technique called Boost. > > > > > > > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > > > > component: > > > > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) > > > > > > with software oriented one (like the one done at Exynos). > > > > > > For this reason cpufreq/freq_table code has been > > > > > > reorganized to include common code. > > > > > > > > > > > > Important design decisions: > > > > > > - Boost related code is compiled-in unconditionally to > > > > > > cpufreq core and disabled by default. The cpufreq_driver is > > > > > > responsibile for setting boost_supported flag and providing > > > > > > set_boost callback(if HW support is needed). For software > > > > > > managed boost, special Kconfig flag - > > > > > > CONFIG_CPU_FREQ_BOOST_SW has been defined. It will be > > > > > > selected only when a target platform has thermal framework > > > > > > properly configured. > > > > > > > > > > > > - struct cpufreq_driver has been extended with boost related > > > > > > fields: -- boost_supported - when driver supports boosting > > > > > > -- boost_enabled - boost state > > > > > > -- set_boost - callback to function, which is > > > > > > necessary to enable/disable boost > > > > > > > > > > > > - Boost sysfs attribute > > > > > > (/sys/devices/system/cpu/cpufreq/boost) is visible _only_ > > > > > > when cpufreq driver supports Boost. > > > > > > > > > > > > - No special spin_lock for Boost was created. The one from > > > > > > cpufreq core was reused. > > > > > > > > > > > > - The Boost code doesn't rely on any policy. When boost > > > > > > state is changed, then the policy list is iterated and > > > > > > proper adjustements are done. > > > > > > > > > > > > - To improve safety level, the thermal framework is also > > > > > > extended to disable software boosting, when thermal trip > > > > > > point is reached. After cooling down the boost can be > > > > > > enabled again. This emulates behaviour similar to HW > > > > > > managed boost (like x86) > > > > > > > > > > > > Tested at HW: > > > > > >Exynos 4412 3.13-rc4 Linux > > > > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > > > > > > > Lukasz Majewski (7): > > > > > > cpufreq: Add boost frequency support in core > > > > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work > > > > > > with common boost solution > > > > > > cpufreq:boost:Kconfig: Provide support for software > > > > > > managed BOOST cpufreq:exynos:Extend Exynos cpufreq driver > > > > > > to support boost framework > > > > > > Documentation:cpufreq:boost: Update BOOST documentation > > > > > > cpufreq:exynos4x12: Change L0 driver data to > > > > > > CPUFREQ_BOOST_FREQ thermal:exynos:boost: Automatic > > > > > > enable/disable of BOOST feature (at Exynos4412) > > > > > > > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > > > > drivers/cpufreq/Kconfig |4 + > > > > > > drivers/cpufreq/Kconfig.arm | 15 > > > > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > > > > +++-- drivers/cpufreq/cpufreq.c > > > > > > | 118 - > > > > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > > > > drivers/cpufreq/freq_table.c | 56 > > > > > > -- drivers/thermal/samsung/exynos_tmu_data.c > > > > > > | 12 +-- include/linux/cpufreq.h | 24 > > > > > > ++ 10 files changed, 261 insertions(+), 85 deletions(-) > > > > > > > > > > > > > > > > A gentle ping about BOOST patches. > > > > > > > > > > Its been already acked by Viresh and Eduardo. > > > > > > > > > > It applies on kernel_pm/bleeding_edge SHA1: > > > > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > > > > > > > It looks like Rui is still looking into this. > > > > > > > > Rui, are you fine with this series? > > > > > > > Yes, I'm okay with the thermal related parts of this patch set. > > > > > > > Rafael, gentle reminder about BOOST patches ... :-) > > I'm about to take them for 3.14. > Thanks :-) > Thanks! > > [PS: Please don't use the r...@sisk.pl address, that domain is gone.] > Ok, I will not use it. -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Gro
Re: [PATCH v12 0/7] cpufreq:boost: CPU Boost mode support
On Thursday, January 16, 2014 10:40:08 AM Lukasz Majewski wrote: > Hi Rafael, > > > On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote: > > > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > > > Hi Rafael, > > > > > > Hi, > > > > > > > > This patch series introduces support for CPU overclocking > > > > > technique called Boost. > > > > > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > > > component: > > > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > > > software oriented one (like the one done at Exynos). > > > > > For this reason cpufreq/freq_table code has been reorganized to > > > > > include common code. > > > > > > > > > > Important design decisions: > > > > > - Boost related code is compiled-in unconditionally to cpufreq > > > > > core and disabled by default. The cpufreq_driver is > > > > > responsibile for setting boost_supported flag and providing > > > > > set_boost callback(if HW support is needed). For software > > > > > managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW > > > > > has been defined. It will be selected only when a target > > > > > platform has thermal framework properly configured. > > > > > > > > > > - struct cpufreq_driver has been extended with boost related > > > > > fields: -- boost_supported - when driver supports boosting > > > > > -- boost_enabled - boost state > > > > > -- set_boost - callback to function, which is necessary > > > > > to enable/disable boost > > > > > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) > > > > > is visible _only_ when cpufreq driver supports Boost. > > > > > > > > > > - No special spin_lock for Boost was created. The one from > > > > > cpufreq core was reused. > > > > > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > > > changed, then the policy list is iterated and proper > > > > > adjustements are done. > > > > > > > > > > - To improve safety level, the thermal framework is also > > > > > extended to disable software boosting, when thermal trip point > > > > > is reached. After cooling down the boost can be enabled again. > > > > > This emulates behaviour similar to HW managed boost (like x86) > > > > > > > > > > Tested at HW: > > > > >Exynos 4412 3.13-rc4 Linux > > > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > > > > > Lukasz Majewski (7): > > > > > cpufreq: Add boost frequency support in core > > > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with > > > > > common boost solution > > > > > cpufreq:boost:Kconfig: Provide support for software managed > > > > > BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support > > > > > boost framework > > > > > Documentation:cpufreq:boost: Update BOOST documentation > > > > > cpufreq:exynos4x12: Change L0 driver data to > > > > > CPUFREQ_BOOST_FREQ thermal:exynos:boost: Automatic > > > > > enable/disable of BOOST feature (at Exynos4412) > > > > > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > > > drivers/cpufreq/Kconfig |4 + > > > > > drivers/cpufreq/Kconfig.arm | 15 > > > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > > > +++-- drivers/cpufreq/cpufreq.c > > > > > | 118 - > > > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > > > drivers/cpufreq/freq_table.c | 56 -- > > > > > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > > > > > include/linux/cpufreq.h | 24 ++ 10 files > > > > > changed, 261 insertions(+), 85 deletions(-) > > > > > > > > > > > > > A gentle ping about BOOST patches. > > > > > > > > Its been already acked by Viresh and Eduardo. > > > > > > > > It applies on kernel_pm/bleeding_edge SHA1: > > > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > > > > > It looks like Rui is still looking into this. > > > > > > Rui, are you fine with this series? > > > > > Yes, I'm okay with the thermal related parts of this patch set. > > > > Rafael, gentle reminder about BOOST patches ... :-) I'm about to take them for 3.14. Thanks! [PS: Please don't use the r...@sisk.pl address, that domain is gone.] -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: Can't use the usbphy in exynos4412
> Date: Wed, 15 Jan 2014 18:44:33 +0800
> From: lxr1...@hotmail.com
> To: linux-samsung-soc@vger.kernel.org
> CC: ba...@ti.com; kgene@samsung.com
> Subject: Can't use the usbphy in exynos4412
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I meet the usb problem in Linux 3.13-rc8, in my board, the HSIC in SoC
> is connect to usb4640, I have using a litter driver to reset usb4640
> after boot.
> In the old time, when it doesn't use common phy framework, it was work.
> In board, the otg is brike(maybe by franklinism) but HSIC of host is
> normal, I have tested.
> the dmesg show that
> [ 1.26] samsung-usb2phy 125b.usbphy: Can't get usb-phy
> sysreg cfg register
> [ 1.30] usbcore: registered new interface driver uvcvideo
> [ 1.44] usbcore: registered new interface driver usbhid
> [ 1.44] usbhid: USB HID core driver
> [ 1.475000] samsung-usb2phy 125b.usbphy: Can't configure
> specified phy mode
> specified phy mode
>
> root@kagami:~# lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> usb_phy: usbphy@125B {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "samsung,exynos4210-usb2phy";
I am very sorry about that, I shall use samsung,exynos4x10-usb2phy instead.
> reg = <0x125B 0x100>;
> ranges;
> status = "okay";
>
> clocks = <&clock 2>, <&clock 305>;
> clock-names = "xusbxti", "otg";
>
> usbphy-sys {
> /* USB device and host PHY_CONTROL registers */
> reg = <0x10020704 0x8>;
> };
> };
>
> ehci@1258 {
> usb-phy = <&usb_phy>;
> status = "okay";
> };
>
I am sorry for careless again.
Thank you
ayaka
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{北┈�x,∪Ф�≤�}��财�z�&j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f
[PATCH 1/2] spi: Provide core support for DMA mapping transfers
From: Mark Brown
The process of DMA mapping buffers for SPI transfers does not vary between
devices so in order to save duplication of code in drivers this can be
factored out into the core, allowing it to be integrated with the work that
is being done on factoring out the common elements from the data path
including more sharing of dmaengine code.
In order to use this masters need to provide a can_dma() operation and while
the hardware is prepared they should ensure that DMA channels are provided
in tx_dma and rx_dma. The core will then ensure that the buffers are mapped
for DMA prior to calling transfer_one_message().
Currently the cleanup on error is not complete, this needs to be improved.
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 79 +
include/linux/spi/spi.h | 18 +++
2 files changed, 97 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index a86569e1f178..314d326bce9f 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -570,6 +572,74 @@ static void spi_set_cs(struct spi_device *spi, bool enable)
spi->master->set_cs(spi, !enable);
}
+static int spi_dma_map_msg(struct spi_master *master, struct spi_message *msg)
+{
+ struct device *dev = master->dev.parent;
+ struct device *tx_dev, *rx_dev;
+ struct spi_transfer *xfer;
+
+ if (msg->is_dma_mapped || !master->can_dma)
+ return 0;
+
+ tx_dev = &master->dma_tx->dev->device;
+ rx_dev = &master->dma_rx->dev->device;
+
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+ if (!master->can_dma(master, msg->spi, xfer))
+ continue;
+
+ if (xfer->tx_buf != NULL) {
+ xfer->tx_dma = dma_map_single(tx_dev,
+ (void *)xfer->tx_buf,
+ xfer->len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, xfer->tx_dma)) {
+ dev_err(dev, "dma_map_single Tx failed\n");
+ return -ENOMEM;
+ }
+ }
+
+ if (xfer->rx_buf != NULL) {
+ xfer->rx_dma = dma_map_single(rx_dev,
+ xfer->rx_buf, xfer->len,
+ DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, xfer->rx_dma)) {
+ dev_err(dev, "dma_map_single Rx failed\n");
+ dma_unmap_single(tx_dev, xfer->tx_dma,
+xfer->len, DMA_TO_DEVICE);
+ return -ENOMEM;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int spi_dma_unmap_msg(struct spi_master *master,
+struct spi_message *msg)
+{
+ struct spi_transfer *xfer;
+ struct device *tx_dev, *rx_dev;
+
+ if (!master->cur_msg_mapped || msg->is_dma_mapped || !master->can_dma)
+ return 0;
+
+ tx_dev = &master->dma_tx->dev->device;
+ rx_dev = &master->dma_rx->dev->device;
+
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+ if (!master->can_dma(master, msg->spi, xfer))
+ continue;
+
+ dma_unmap_single(rx_dev, xfer->rx_dma, xfer->len,
+DMA_FROM_DEVICE);
+ dma_unmap_single(tx_dev, xfer->tx_dma, xfer->len,
+DMA_TO_DEVICE);
+ }
+
+ return 0;
+}
+
/*
* spi_transfer_one_message - Default implementation of transfer_one_message()
*
@@ -740,6 +810,13 @@ static void spi_pump_messages(struct kthread_work *work)
master->cur_msg_prepared = true;
}
+ ret = spi_dma_map_msg(master, master->cur_msg);
+ if (ret) {
+ master->cur_msg->status = ret;
+ spi_finalize_current_message(master);
+ return;
+ }
+
ret = master->transfer_one_message(master, master->cur_msg);
if (ret) {
dev_err(&master->dev,
@@ -829,6 +906,8 @@ void spi_finalize_current_message(struct spi_master *master)
queue_kthread_work(&master->kworker, &master->pump_messages);
spin_unlock_irqrestore(&master->queue_lock, flags);
+ spi_dma_unmap_msg(master, mesg);
+
if (master->cur_msg_prepared && master->unprepare_message) {
ret = master->unprepare_message(master, mesg);
if (ret) {
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 21a7251d85ee..14380043491b 100644
--- a/include/linux/spi/spi.h
[PATCH 2/2] spi/s3c64xx: Use core DMA mapping code with dmaengine
From: Mark Brown
When using dmaengine allow the core to do the DMA mapping. We still need
local mapping code for the non-dmaengine case so this doesn't save us
anything for now.
Signed-off-by: Mark Brown
---
drivers/spi/spi-s3c64xx.c | 178 +++---
1 file changed, 103 insertions(+), 75 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index ae907dde1371..e7620f299777 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -291,6 +291,81 @@ static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
.name = "samsung-spi-dma",
};
+static int s3c64xx_spi_map_mssg(struct s3c64xx_spi_driver_data *sdd,
+ struct spi_message *msg)
+{
+ struct device *dev = &sdd->pdev->dev;
+ struct spi_transfer *xfer;
+
+ if (is_polling(sdd) || msg->is_dma_mapped)
+ return 0;
+
+ /* First mark all xfer unmapped */
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+ xfer->rx_dma = XFER_DMAADDR_INVALID;
+ xfer->tx_dma = XFER_DMAADDR_INVALID;
+ }
+
+ /* Map until end or first fail */
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+
+ if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
+ continue;
+
+ if (xfer->tx_buf != NULL) {
+ xfer->tx_dma = dma_map_single(dev,
+ (void *)xfer->tx_buf, xfer->len,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, xfer->tx_dma)) {
+ dev_err(dev, "dma_map_single Tx failed\n");
+ xfer->tx_dma = XFER_DMAADDR_INVALID;
+ return -ENOMEM;
+ }
+ }
+
+ if (xfer->rx_buf != NULL) {
+ xfer->rx_dma = dma_map_single(dev, xfer->rx_buf,
+ xfer->len, DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, xfer->rx_dma)) {
+ dev_err(dev, "dma_map_single Rx failed\n");
+ dma_unmap_single(dev, xfer->tx_dma,
+ xfer->len, DMA_TO_DEVICE);
+ xfer->tx_dma = XFER_DMAADDR_INVALID;
+ xfer->rx_dma = XFER_DMAADDR_INVALID;
+ return -ENOMEM;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static void s3c64xx_spi_unmap_mssg(struct s3c64xx_spi_driver_data *sdd,
+ struct spi_message *msg)
+{
+ struct device *dev = &sdd->pdev->dev;
+ struct spi_transfer *xfer;
+
+ if (is_polling(sdd) || msg->is_dma_mapped)
+ return;
+
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+
+ if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1))
+ continue;
+
+ if (xfer->rx_buf != NULL
+ && xfer->rx_dma != XFER_DMAADDR_INVALID)
+ dma_unmap_single(dev, xfer->rx_dma,
+ xfer->len, DMA_FROM_DEVICE);
+
+ if (xfer->tx_buf != NULL
+ && xfer->tx_dma != XFER_DMAADDR_INVALID)
+ dma_unmap_single(dev, xfer->tx_dma,
+ xfer->len, DMA_TO_DEVICE);
+ }
+}
+
static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
unsigned len, dma_addr_t buf)
{
@@ -378,8 +453,22 @@ static void s3c64xx_spi_dma_stop(struct
s3c64xx_spi_driver_data *sdd,
{
sdd->ops->stop((enum dma_ch)dma->ch);
}
+
+#define s3c64xx_spi_can_dma NULL
+
#else
+static int s3c64xx_spi_map_mssg(struct s3c64xx_spi_driver_data *sdd,
+ struct spi_message *msg)
+{
+ return 0;
+}
+
+static void s3c64xx_spi_unmap_mssg(struct s3c64xx_spi_driver_data *sdd,
+ struct spi_message *msg)
+{
+}
+
static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
unsigned len, dma_addr_t buf)
{
@@ -437,6 +526,7 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master
*spi)
ret = -EBUSY;
goto out;
}
+ spi->dma_rx = sdd->rx_dma.ch;
sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
(void *)sdd->tx_dma.dmach, dev, "tx");
@@ -445,6 +535,7 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master
*spi)
ret = -EBUSY;
goto out_rx;
Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
On Wed, Jan 15, 2014 at 07:41:55PM +0530, Kishon Vijay Abraham I wrote: > The point I'm trying to make is that we won't 'always' know the device names > in > advance. In which cases do we not know the device names, and please note, cases where we would need to use the lookup? The normal cases we would use it are.. 1) A driver creating a child device, like dwc3 when it creates the xhci. There the parent just delivers the phys it has to the child, so both the device name and the phys are known. 2) Platform code. Hopefully we can get rid of the platform code one day, but in any case, when we use it, we always know at least how many users a phy has, and if there is only a singe user, we can rely con_id to do the matching. Though I still don't really see much risk in using the controller device name also there. The lookup table should in any case be made in the place where the phy devices are created, so the phy name is definitely always known. 3) Phys part of something like mfd. This is in practice the same as the platform code case. For example, with twl we always know there is only one user for the phy, which is musb. So we can just use musb's con_id if it's to scary to use "musb-hdrc.0". In any other case, you get the phy from DT, and there is no need to use the lookup when linking the phys and the users. > Btw how are you planning to differentiate between multiple controllers of the > same type with con_id? You don't rely on the con_id alone in those cases. You then use the device name. The con_id is just one parameter you can use to do the matching. > Maybe I'm missing the actual intention of this patch. Do you face problem if > the PHY's have to know about it's consumers in ACPI? > >> I would rather leave the way it is modelled now. > > > > Do you mean, leave it in the platform code? Why? We would reduce the > > platform code by moving it to the mfd driver. Or did I misunderstood > > something? > > In this case, the lookup table will be used only for non-dt boot so don't see > much use in moving to mfd driver. > I meant if the new method is not solving any problem then I would prefer the > way it is modelled now where the PHY's know about it's consumers. OK, so that's what you meant. Things like that init_data promotes use of platform data in the drivers, something that we really should get rid of. Is that not a problem to you? The phy drivers simply should not need to care about the consumers. They should not need to care about anything DT, ACPI, platform specific if it's possible, and here there is nothing preventing it. Let me clarify.. The plan is that ultimately the drivers (meaning all the drivers, not just phy) don't need to care about things like DT properties, ACPI properties or anything DT, ACPI, platform specific. We will have generic driver properties and capabilities and the upper layers will take care of delivering the correct values from the source at hand. The drivers can be made truly platform agnostic. That is the goal, and we should make everything new by keeping that in mind. Many existing frameworks are being converted to that direction, like the gpio framework and DMA Engine API. The way you force the phy drivers the deliver the consumers is taking a step backwards. > Btw where does device gets created in ACPI boot? drivers/acpi/acpi_platform.c Thanks, -- heikki -- 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 v2] drivers: i2c: silence a compile warning in i2c-s3c2410.c
On Wed, Jan 15, 2014 at 10:42:42AM +0900, y...@samsung.com wrote: Note that your email address is wrong here. I also fixed the description to "i2c: s3c2410: fix quirk usage for 64-bit" which is more apropriate. Other than that: Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH v12 0/7] cpufreq:boost: CPU Boost mode support
Hi Rafael, > On Wed, 2014-01-08 at 01:35 +0100, Rafael J. Wysocki wrote: > > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > > Hi Rafael, > > > > Hi, > > > > > > This patch series introduces support for CPU overclocking > > > > technique called Boost. > > > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > > component: > > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > > software oriented one (like the one done at Exynos). > > > > For this reason cpufreq/freq_table code has been reorganized to > > > > include common code. > > > > > > > > Important design decisions: > > > > - Boost related code is compiled-in unconditionally to cpufreq > > > > core and disabled by default. The cpufreq_driver is > > > > responsibile for setting boost_supported flag and providing > > > > set_boost callback(if HW support is needed). For software > > > > managed boost, special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW > > > > has been defined. It will be selected only when a target > > > > platform has thermal framework properly configured. > > > > > > > > - struct cpufreq_driver has been extended with boost related > > > > fields: -- boost_supported - when driver supports boosting > > > > -- boost_enabled - boost state > > > > -- set_boost - callback to function, which is necessary > > > > to enable/disable boost > > > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) > > > > is visible _only_ when cpufreq driver supports Boost. > > > > > > > > - No special spin_lock for Boost was created. The one from > > > > cpufreq core was reused. > > > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > > changed, then the policy list is iterated and proper > > > > adjustements are done. > > > > > > > > - To improve safety level, the thermal framework is also > > > > extended to disable software boosting, when thermal trip point > > > > is reached. After cooling down the boost can be enabled again. > > > > This emulates behaviour similar to HW managed boost (like x86) > > > > > > > > Tested at HW: > > > >Exynos 4412 3.13-rc4 Linux > > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > > > Lukasz Majewski (7): > > > > cpufreq: Add boost frequency support in core > > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with > > > > common boost solution > > > > cpufreq:boost:Kconfig: Provide support for software managed > > > > BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support > > > > boost framework > > > > Documentation:cpufreq:boost: Update BOOST documentation > > > > cpufreq:exynos4x12: Change L0 driver data to > > > > CPUFREQ_BOOST_FREQ thermal:exynos:boost: Automatic > > > > enable/disable of BOOST feature (at Exynos4412) > > > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > > drivers/cpufreq/Kconfig |4 + > > > > drivers/cpufreq/Kconfig.arm | 15 > > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > > +++-- drivers/cpufreq/cpufreq.c > > > > | 118 - > > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > > drivers/cpufreq/freq_table.c | 56 -- > > > > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > > > > include/linux/cpufreq.h | 24 ++ 10 files > > > > changed, 261 insertions(+), 85 deletions(-) > > > > > > > > > > A gentle ping about BOOST patches. > > > > > > Its been already acked by Viresh and Eduardo. > > > > > > It applies on kernel_pm/bleeding_edge SHA1: > > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > > > It looks like Rui is still looking into this. > > > > Rui, are you fine with this series? > > > Yes, I'm okay with the thermal related parts of this patch set. > Rafael, gentle reminder about BOOST patches ... :-) > thanks, > rui > > Rafael > > > > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- 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] ARM: exynos_defconfig: Update EHCI config entry
On Thursday, January 16, 2014 5:34 PM, Tushar Behera wrote:
>
> Commit 29824c167bea ("USB: host: Rename ehci-s5p to ehci-exynos")
> renamed the config entry of EHCI host driver. Similar change needs
> to be done in exynos_defconfig as well.
>
> Signed-off-by: Tushar Behera
(+cc Vivek Gautam, Yulgon Kim, Julius Werner)
Reviewed-by: Jingoo Han
Yes, right.
I overlooked 'exynos_defconfig', when I changed the name of
Exynos EHCI driver. Thank you for sending the patch. :-)
Best regards,
Jingoo Han
> ---
> arch/arm/configs/exynos_defconfig |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> index dbe1f1c..4ce7b70 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -94,7 +94,7 @@ CONFIG_FONT_7x14=y
> CONFIG_LOGO=y
> CONFIG_USB=y
> CONFIG_USB_EHCI_HCD=y
> -CONFIG_USB_EHCI_S5P=y
> +CONFIG_USB_EHCI_EXYNOS=y
> CONFIG_USB_STORAGE=y
> CONFIG_USB_DWC3=y
> CONFIG_USB_PHY=y
> --
> 1.7.9.5
--
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
[PATCH] ARM: exynos_defconfig: Update EHCI config entry
Commit 29824c167bea ("USB: host: Rename ehci-s5p to ehci-exynos")
renamed the config entry of EHCI host driver. Similar change needs
to be done in exynos_defconfig as well.
Signed-off-by: Tushar Behera
---
arch/arm/configs/exynos_defconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index dbe1f1c..4ce7b70 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -94,7 +94,7 @@ CONFIG_FONT_7x14=y
CONFIG_LOGO=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_S5P=y
+CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_STORAGE=y
CONFIG_USB_DWC3=y
CONFIG_USB_PHY=y
--
1.7.9.5
--
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
