[PATCH 2/3] PM / OPP: rename data structures to dev_pm equivalents
Since Operating Performance Points(OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.
Impacted structures are:
struct opp
enum opp_event
Minor checkpatch warning fixes as a result of this change was fixed as
well.
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/power/opp.txt |4 ++--
arch/arm/mach-omap2/pm.c |2 +-
drivers/base/power/opp.c | 41 ++
drivers/cpufreq/cpufreq-cpu0.c |4 ++--
drivers/cpufreq/exynos5440-cpufreq.c |2 +-
drivers/cpufreq/imx6q-cpufreq.c |4 ++--
drivers/cpufreq/omap-cpufreq.c |2 +-
drivers/devfreq/devfreq.c|9
drivers/devfreq/exynos/exynos4_bus.c |6 ++---
drivers/devfreq/exynos/exynos5_bus.c |6 ++---
include/linux/devfreq.h |4 ++--
include/linux/opp.h | 29 +---
12 files changed, 60 insertions(+), 53 deletions(-)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 185367b..7f67e3d 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -358,14 +358,14 @@ accessed by various functions as described above.
However, the structures
representing the actual OPPs and domains are internal to the OPP library itself
to allow for suitable abstraction reusable across systems.
-struct opp - The internal data structure of OPP library which is used to
+struct dev_pm_opp - The internal data structure of OPP library which is used to
represent an OPP. In addition to the freq, voltage, availability
information, it also contains internal book keeping information required
for the OPP library to operate on. Pointer to this structure is
provided back to the users such as SoC framework to be used as a
identifier for OPP in the interactions with OPP layer.
- WARNING: The struct opp pointer should not be parsed or modified by the
+ WARNING: The struct dev_pm_opp pointer should not be parsed or modified
by the
users. The defaults of for an instance is populated by dev_pm_opp_add,
but the
availability of the OPP can be modified by dev_pm_opp_enable/disable
functions.
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 937744c..92901bd 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -131,7 +131,7 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
{
struct voltagedomain *voltdm;
struct clk *clk;
- struct opp *opp;
+ struct dev_pm_opp *opp;
unsigned long freq, bootup_volt;
struct device *dev;
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 00c6a44..693e14a 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -42,7 +42,7 @@
*/
/**
- * struct opp - Generic OPP description structure
+ * struct dev_pm_opp - Generic OPP description structure
* @node: opp list node. The nodes are maintained throughout the lifetime
* of boot. It is expected only an optimal set of OPPs are
* added to the library by the SoC framework.
@@ -59,7 +59,7 @@
*
* This structure stores the OPP information for a given device.
*/
-struct opp {
+struct dev_pm_opp {
struct list_head node;
bool available;
@@ -150,9 +150,9 @@ static struct device_opp *find_device_opp(struct device
*dev)
* prior to unlocking with rcu_read_unlock() to maintain the integrity of the
* pointer.
*/
-unsigned long dev_pm_opp_get_voltage(struct opp *opp)
+unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
{
- struct opp *tmp_opp;
+ struct dev_pm_opp *tmp_opp;
unsigned long v = 0;
tmp_opp = rcu_dereference(opp);
@@ -180,9 +180,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
* prior to unlocking with rcu_read_unlock() to maintain the integrity of the
* pointer.
*/
-unsigned long dev_pm_opp_get_freq(struct opp *opp)
+unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
{
- struct opp *tmp_opp;
+ struct dev_pm_opp *tmp_opp;
unsigned long f = 0;
tmp_opp = rcu_dereference(opp);
@@ -209,7 +209,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq);
int dev_pm_opp_get_opp_count(struct device *dev)
{
struct device_opp *dev_opp;
- struct opp *temp_opp;
+ struct dev_pm_opp *temp_opp;
int count = 0;
dev_opp = find_device_opp(dev);
@@ -254,11 +254,12 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_opp_count);
* under the locked area. The pointer returned must be used prior to unlocking
* with rcu_read_unlock() to maintain the integrity of the pointer.
*/
-struct opp *dev_pm_opp_find_freq_exact(struct device *dev, unsigned long freq,
-
[PATCH 0/3] PM / OPP: rename to dev_pm_opp * equivalents
Hi, Based on [1], Randy rightly pointed out that OPP functions and data structures could be a bit specific to Power management. So, the following series is based on v3.12-rc1 tag. If folks like it broken in a different way, I am open to suggestions. Nishanth Menon (3): PM / OPP: rename functions to dev_pm_opp* PM / OPP: rename data structures to dev_pm equivalents PM / OPP: rename header to linux/pm_opp.h Documentation/power/opp.txt | 108 arch/arm/mach-imx/mach-imx6q.c |4 +- arch/arm/mach-omap2/board-omap3beagle.c | 10 +-- arch/arm/mach-omap2/omap-pm.h |2 +- arch/arm/mach-omap2/opp.c |6 +- arch/arm/mach-omap2/pm.c|8 +- drivers/base/power/opp.c| 115 - drivers/cpufreq/arm_big_little.c|8 +- drivers/cpufreq/arm_big_little_dt.c |2 +- drivers/cpufreq/cpufreq-cpu0.c | 24 +++--- drivers/cpufreq/exynos5440-cpufreq.c| 17 ++-- drivers/cpufreq/imx6q-cpufreq.c | 26 +++--- drivers/cpufreq/omap-cpufreq.c | 12 +-- drivers/devfreq/devfreq.c | 25 +++--- drivers/devfreq/exynos/exynos4_bus.c| 29 +++ drivers/devfreq/exynos/exynos5_bus.c| 28 +++ include/linux/devfreq.h |6 +- include/linux/opp.h | 134 - include/linux/pm_opp.h | 139 +++ 19 files changed, 357 insertions(+), 346 deletions(-) delete mode 100644 include/linux/opp.h create mode 100644 include/linux/pm_opp.h -- 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 1/3] PM / OPP: rename functions to dev_pm_opp*
Since Operating Performance Points(OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.
Impacted functions are:
opp_get_voltage
opp_get_freq
opp_get_opp_count
opp_find_freq_exact
opp_find_freq_floor
opp_find_freq_ceil
opp_add
opp_enable
opp_disable
opp_get_notifier
opp_init_cpufreq_table
opp_free_cpufreq_table
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/power/opp.txt | 102 +++
arch/arm/mach-imx/mach-imx6q.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |8 +--
arch/arm/mach-omap2/opp.c |4 +-
arch/arm/mach-omap2/pm.c|4 +-
drivers/base/power/opp.c| 82 -
drivers/cpufreq/arm_big_little.c|6 +-
drivers/cpufreq/cpufreq-cpu0.c | 18 +++---
drivers/cpufreq/exynos5440-cpufreq.c| 13 ++--
drivers/cpufreq/imx6q-cpufreq.c | 20 +++---
drivers/cpufreq/omap-cpufreq.c |8 +--
drivers/devfreq/devfreq.c | 14 ++---
drivers/devfreq/exynos/exynos4_bus.c| 21 ---
drivers/devfreq/exynos/exynos5_bus.c| 18 +++---
include/linux/opp.h | 50 +++
15 files changed, 187 insertions(+), 183 deletions(-)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 425c51d..185367b 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -71,14 +71,14 @@ operations until that OPP could be re-enabled if possible.
OPP library facilitates this concept in it's implementation. The following
operational functions operate only on available opps:
-opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count
-and opp_init_cpufreq_table
+opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq,
dev_pm_opp_get_opp_count
+and dev_pm_opp_init_cpufreq_table
-opp_find_freq_exact is meant to be used to find the opp pointer which can then
-be used for opp_enable/disable functions to make an opp available as required.
+dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which
can then
+be used for dev_pm_opp_enable/disable functions to make an opp available as
required.
WARNING: Users of OPP library should refresh their availability count using
-get_opp_count if opp_enable/disable functions are invoked for a device, the
+get_opp_count if dev_pm_opp_enable/disable functions are invoked for a device,
the
exact mechanism to trigger these or the notification mechanism to other
dependent subsystems such as cpufreq are left to the discretion of the SoC
specific framework which uses the OPP library. Similar care needs to be taken
@@ -96,24 +96,24 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
opp_get_{voltage, freq, opp_count} fall into this category.
opp_{add,enable,disable} are updaters which use mutex and implement it's own
-RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses
+RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and
uses
mutex to implment RCU updater strategy. These functions should *NOT* be called
under RCU locks and other contexts that prevent blocking functions in RCU or
mutex operations from working.
2. Initial OPP List Registration
-The SoC implementation calls opp_add function iteratively to add OPPs per
+The SoC implementation calls dev_pm_opp_add function iteratively to add OPPs
per
device. It is expected that the SoC framework will register the OPP entries
optimally- typical numbers range to be less than 5. The list generated by
registering the OPPs is maintained by OPP library throughout the device
operation. The SoC framework can subsequently control the availability of the
-OPPs dynamically using the opp_enable / disable functions.
+OPPs dynamically using the dev_pm_opp_enable / disable functions.
-opp_add - Add a new OPP for a specific domain represented by the device
pointer.
+dev_pm_opp_add - Add a new OPP for a specific domain represented by the device
pointer.
The OPP is defined using the frequency and voltage. Once added, the OPP
is assumed to be available and control of it's availability can be done
- with the opp_enable/disable functions. OPP library internally stores
+ with the dev_pm_opp_enable/disable functions. OPP library internally
stores
and manages this information in the opp struct. This function may be
used by SoC framework to define a optimal list as per the demands of
SoC usage environment.
@@ -124,7 +124,7 @@ opp_add - Add a new OPP for a specific domain represented
by the device pointer.
soc_pm_init()
{
/* Do things */
- r = opp_add(mpu_dev, 100, 90);
+ r
[PATCH 3/3] PM / OPP: rename header to linux/pm_opp.h
Since Operating Performance Points(OPP) functions are specific to
device specific power management, be specific and rename opp.h
to pm_opp.h
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/power/opp.txt |2 +-
arch/arm/mach-imx/mach-imx6q.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/omap-pm.h |2 +-
arch/arm/mach-omap2/opp.c |2 +-
arch/arm/mach-omap2/pm.c|2 +-
drivers/base/power/opp.c|2 +-
drivers/cpufreq/arm_big_little.c|2 +-
drivers/cpufreq/arm_big_little_dt.c |2 +-
drivers/cpufreq/cpufreq-cpu0.c |2 +-
drivers/cpufreq/exynos5440-cpufreq.c|2 +-
drivers/cpufreq/imx6q-cpufreq.c |2 +-
drivers/cpufreq/omap-cpufreq.c |2 +-
drivers/devfreq/devfreq.c |2 +-
drivers/devfreq/exynos/exynos4_bus.c|2 +-
drivers/devfreq/exynos/exynos5_bus.c|4 ++--
include/linux/devfreq.h |2 +-
include/linux/{opp.h = pm_opp.h} |0
18 files changed, 18 insertions(+), 18 deletions(-)
rename include/linux/{opp.h = pm_opp.h} (100%)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 7f67e3d..b8a907d 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -42,7 +42,7 @@ We can represent these as three OPPs as the following {Hz,
uV} tuples:
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
-is located in include/linux/opp.h. OPP library can be enabled by enabling
+is located in include/linux/pm_opp.h. OPP library can be enabled by enabling
CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
optionally boot at a certain OPP without needing cpufreq.
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index dfbf6f2..86dea10 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -25,7 +25,7 @@
#include linux/of_address.h
#include linux/of_irq.h
#include linux/of_platform.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/phy.h
#include linux/reboot.h
#include linux/regmap.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33969e5..6432ab8 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -25,7 +25,7 @@
#include linux/gpio.h
#include linux/input.h
#include linux/gpio_keys.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/cpu.h
#include linux/mtd/mtd.h
diff --git a/arch/arm/mach-omap2/omap-pm.h b/arch/arm/mach-omap2/omap-pm.h
index 67faa7b..1d777e6 100644
--- a/arch/arm/mach-omap2/omap-pm.h
+++ b/arch/arm/mach-omap2/omap-pm.h
@@ -17,7 +17,7 @@
#include linux/device.h
#include linux/cpufreq.h
#include linux/clk.h
-#include linux/opp.h
+#include linux/pm_opp.h
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 7b04637..ec21e6e 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -17,7 +17,7 @@
* GNU General Public License for more details.
*/
#include linux/module.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/cpu.h
#include omap_device.h
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 92901bd..2f569b3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -13,7 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/err.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/export.h
#include linux/suspend.h
#include linux/cpu.h
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 693e14a..fa41874 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -21,7 +21,7 @@
#include linux/list.h
#include linux/rculist.h
#include linux/rcupdate.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/of.h
#include linux/export.h
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 9e82a9d..e010fb7 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -25,7 +25,7 @@
#include linux/cpumask.h
#include linux/export.h
#include linux/of_platform.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/slab.h
#include linux/topology.h
#include linux/types.h
diff --git a/drivers/cpufreq/arm_big_little_dt.c
b/drivers/cpufreq/arm_big_little_dt.c
index 480c0bd..8d9d591 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -24,7 +24,7 @@
#include linux/export.h
#include linux/module.h
#include
Re: [PATCH] Input: gpio-keys - update to devm_* API
On Wed, Sep 18, 2013 at 12:41:11AM +0530, Manish Badarkhe wrote: Hi Dmitry, On Wed, Sep 18, 2013 at 12:22 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Manish, On Sun, Sep 15, 2013 at 01:22:23AM +0530, Manish Badarkhe wrote: Update the code to use devm_* API so that driver core will manage resources. And the benefit of this would be...? There are still resources that are managed in traditional way and I really dislike mixing the 2 styles. I can see applying patch that converts the driver to use devm_ for all its resources and gets rid of the remove() method altogether, but I am not sure how beneficial this kind of changes are for existing drivers. IMO devm_ makes us to manage resources properly without much care about freeing it ( as devm_handles freeing automatically). Are the resources released improperly in the current version of the driver? IOW I do not see the point in applying this patch as it does not make the driver materially better. Thanks. -- Dmitry -- 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 00/51] DMA mask changes
This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some cases rather buggy. I tried to get some of the bug fixes in before the last merge window, but it seems that the maintainers preferred to have the full solution rather than a simple -rc suitable bug fix. So, this is an attempt to clean things up. The first point here is that drivers performing DMA should be calling dma_set_mask()/dma_set_coherent_mask() in their probe function to verify that DMA can be performed. Lots of ARM drivers omit this step; please refer to the DMA API documentation on this subject. What this means is that the DMA mask provided by bus code is a default value - nothing more. It doesn't have to accurately reflect what the device is actually capable of. Apart from the storage for dev-dma_mask being initialised for any device which is DMA capable, there is no other initialisation which is strictly necessary at device creation time. Now, these cleanups address two major areas: 1. The setting of DMA masks, particularly when both the coherent and streaming DMA masks are set together. 2. The initialisation of DMA masks by drivers - this seems to be becoming a popular habbit, one which may not be entirely the right solution. Rather than having this scattered throughout the tree, I've pulled that into a central location (and called it coercing the DMA mask - because it really is about forcing the DMA mask to be that value.) 3. Finally, addressing the long held misbelief that DMA masks somehow correspond with physical addresses. We already have established long ago that dma_addr_t values returned from the DMA API are the values which you program into the DMA controller, and so are the bus addresses. It is _only_ sane that DMA masks are also bus related too, and not related to physical address spaces. (3) is a very important point for LPAE systems, which may still have less than 4GB of memory, but this memory is all located above the 4GB physical boundary. This means with the current model, any device using a 32-bit DMA mask fails - even though the DMA controller is still only a 32-bit DMA controller but the 32-bit bus addresses map to system memory. To put it another way, the bus addresses have a 4GB physical offset on them. This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Patches based on v3.12-rc1. Documentation/DMA-API-HOWTO.txt | 37 +-- Documentation/DMA-API.txt |8 +++ arch/arm/include/asm/dma-mapping.h|8 +++ arch/arm/mm/dma-mapping.c | 49 ++-- arch/arm/mm/init.c| 12 +++--- arch/arm/mm/mm.h |2 + arch/powerpc/kernel/vio.c |3 +- block/blk-settings.c |8 ++-- drivers/amba/bus.c|6 +-- drivers/ata/pata_ixp4xx_cf.c |5 ++- drivers/ata/pata_octeon_cf.c |5 +- drivers/block/nvme-core.c | 10 ++--- drivers/crypto/ixp4xx_crypto.c| 48 ++-- drivers/dma/amba-pl08x.c |5 ++ drivers/dma/dw/platform.c |8 +-- drivers/dma/edma.c|6 +-- drivers/dma/pl330.c |4 ++ drivers/firmware/dcdbas.c | 23 +- drivers/firmware/google/gsmi.c| 13 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +- drivers/media/platform/omap3isp/isp.c |6 +- drivers/media/platform/omap3isp/isp.h |3 - drivers/mmc/card/queue.c |3 +- drivers/mmc/host/sdhci-acpi.c |5 +- drivers/net/ethernet/broadcom/b44.c |3 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 +--- drivers/net/ethernet/brocade/bna/bnad.c | 13 ++ drivers/net/ethernet/emulex/benet/be_main.c | 12 + drivers/net/ethernet/intel/e1000/e1000_main.c |9 +--- drivers/net/ethernet/intel/e1000e/netdev.c| 18 +++- drivers/net/ethernet/intel/igb/igb_main.c | 18 +++- drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++- drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
[PATCH 02/51] DMA-API: net: brocade/bna/bnad.c: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err)
goto release_regions;
}
This means we only try and set the coherent DMA mask if we failed to
set a 32-bit DMA mask, and only if both fail do we fail the driver.
Adjust this so that if either setting fails, we fail the driver - and
thereby end up properly setting both the DMA mask and the coherent
DMA mask in the fallback case.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/brocade/bna/bnad.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c
b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..45ce6e2 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3300,17 +3300,12 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
- if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err)
- goto release_regions;
- }
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (err)
+ goto release_regions;
*using_dac = false;
}
pci_set_master(pdev);
--
1.7.4.4
--
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 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Documentation/DMA-API-HOWTO.txt | 37 ++---
Documentation/DMA-API.txt |8
include/linux/dma-mapping.h | 14 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default
setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ The query for streaming mappings is performed via a call to
+ dma_set_mask():
+
+ int dma_set_mask(struct device *dev, u64 mask);
+
+ The query for consistent allocations is performed via a call
+ to dma_set_coherent_mask():
+
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
- if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
mydev: No suitable DMA available.\n);
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent
allocations as well,
int using_dac, consistent_using_dac;
- if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
- } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
mydev: No suitable DMA available.\n);
goto ignore_this_device;
}
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided. The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided. The
+kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API
for use by
driver writers.
int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
dma_set_mask(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static
[PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e87e9b0..519e293 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6553,21 +6553,15 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.4
--
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 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
pr_err(No usable DMA configuration,
aborting\n);
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- pr_err(No usable DMA configuration,
aborting\n);
- goto err_dma_mask;
- }
+ pr_err(No usable DMA configuration, aborting\n);
+ goto err_dma_mask;
}
}
--
1.7.4.4
--
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 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/igb/igb_main.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 8cf44f2..7579383 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2034,21 +2034,15 @@ static int igb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.4
--
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 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA
configuration, aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c
b/drivers/net/ethernet/intel/igbvf/netdev.c
index 93eb7ee..4e6b02f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2638,21 +2638,15 @@ static int igbvf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev, No usable DMA
- configuration, aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev, No usable DMA
+ configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.4
--
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 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..b1dc844 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7475,19 +7475,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
--
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 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA
configuration, aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..e34c2da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3326,19 +3326,14 @@ static int ixgbevf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev, No usable DMA
- configuration, aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev, No usable DMA
+ configuration, aborting\n);
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
--
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 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: Provide a helper to set both the DMA and coherent DMA masks to the same value - this avoids duplicated code in a number of drivers, sometimes with buggy error handling, and also allows us identify which drivers do things differently. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/DMA-API-HOWTO.txt | 37 ++--- Documentation/DMA-API.txt |8 include/linux/dma-mapping.h | 14 ++ 3 files changed, 44 insertions(+), 15 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 14129f1..5e98303 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt [...] -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will always be able to set the same or a +smaller mask as the streaming mask. However for the rare case that a [...] The new wording doesn't make sense; a mask doesn't set itself. I would suggest: The coherent mask can always be set to the same or a smaller mask than the streaming mask. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/edma.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..7f9fe30 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = edma-dma-engine,
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = edma-dma-engine,
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +722,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
- pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS == 2) {
@@ -731,8 +731,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
- pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
--
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 44/51] DMA-API: dcdbas: update DMA mask handing
dcdbas was explicitly initializing DMA masks thusly:
dcdbas_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
dcdbas_pdev-dev.dma_mask = dcdbas_pdev-dev.coherent_dma_mask;
which bypasses the architecture check. Moreover, it is creating the
dcdbas_pdev device itself, and using the platform_device_register_full()
avoids some of this explicit initialization.
Convert the driver to use platform_device_register_full(), and as it
makes use of coherent DMA, also call dma_set_coherent_mask() to ensure
that the architecture gets to check the mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/firmware/dcdbas.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index ff080ee..a85fda2 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -549,8 +549,9 @@ static int dcdbas_probe(struct platform_device *dev)
* BIOS SMI calls require buffer addresses be in 32-bit address space.
* This is done by setting the DMA mask below.
*/
- dcdbas_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
- dcdbas_pdev-dev.dma_mask = dcdbas_pdev-dev.coherent_dma_mask;
+ error = dma_set_coherent_mask(dcdbas_pdev-dev, DMA_BIT_MASK(32));
+ if (error)
+ return error;
error = sysfs_create_group(dev-dev.kobj, dcdbas_attr_group);
if (error)
@@ -581,6 +582,12 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
};
+static const struct platform_device_info dcdbas_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = -1,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
/**
* dcdbas_init: initialize driver
*/
@@ -592,20 +599,14 @@ static int __init dcdbas_init(void)
if (error)
return error;
- dcdbas_pdev = platform_device_alloc(DRIVER_NAME, -1);
- if (!dcdbas_pdev) {
- error = -ENOMEM;
+ dcdbas_pdev = platform_device_register_full(dcdbas_dev_info);
+ if (IS_ERR(dcdbas_pdev)) {
+ error = PTR_ERR(dcdbas_pdev);
goto err_unregister_driver;
}
- error = platform_device_add(dcdbas_pdev);
- if (error)
- goto err_free_device;
-
return 0;
- err_free_device:
- platform_device_put(dcdbas_pdev);
err_unregister_driver:
platform_driver_unregister(dcdbas_driver);
return error;
--
1.7.4.4
--
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] Input: gpio-keys - update to devm_* API
Hi Dmitry, On Fri, Sep 20, 2013 at 2:52 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Sep 18, 2013 at 12:41:11AM +0530, Manish Badarkhe wrote: Hi Dmitry, On Wed, Sep 18, 2013 at 12:22 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Manish, On Sun, Sep 15, 2013 at 01:22:23AM +0530, Manish Badarkhe wrote: Update the code to use devm_* API so that driver core will manage resources. And the benefit of this would be...? There are still resources that are managed in traditional way and I really dislike mixing the 2 styles. I can see applying patch that converts the driver to use devm_ for all its resources and gets rid of the remove() method altogether, but I am not sure how beneficial this kind of changes are for existing drivers. IMO devm_ makes us to manage resources properly without much care about freeing it ( as devm_handles freeing automatically). Are the resources released improperly in the current version of the driver? IOW I do not see the point in applying this patch as it does not make the driver materially better. Resources are released properly in current version of driver but using a traditional way. This patch is just a clean up and to use new devm_ variant. Yes, This patch does not make a driver materially better but make use of devm_ variant as like any other drivers. Thanks Manish Badarkhe -- 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: dts: Update arch timer node with clock frequency
Resending it as it bounced from kernel mailing group
On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland mark.rutl...@arm.com wrote:
[adding lakml]
On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote:
Without the clock-frequency property in arch timer node, could able
to see the below crash dump.
Why does this cause the below crash specifically? What is CNTFRQ reading
as?
Return value of arch_timer_get_cntfrq() is 0
Your firmware or bootloader should set CNTFRQ -- setting the
clock-frequency is a work-around for buggy firmware/bootloaders that
should be avoided as far as possible.
Why kernel should depend on bootloader/firmware to set CNTFRQ? Any
specific reasons?
Should'nt be indepenedent each other(kernel and bootloader/firmware)?
Is it not possible to fix your firmware or bootlaoder to set CNTFRQ?
Thanks,
Mark.
[c0014e28] (unwind_backtrace+0x0/0xf4) from [c0011808]
(show_stack+0x10/0x14)
[c0011808] (show_stack+0x10/0x14) from [c036ac1c] (dump_stack+0x7c/0xb0)
[c036ac1c] (dump_stack+0x7c/0xb0) from [c01ab760] (Ldiv0_64+0x8/0x18)
[c01ab760] (Ldiv0_64+0x8/0x18) from [c0062f60]
(clockevents_config.part.2+0x1c/0x74)
[c0062f60] (clockevents_config.part.2+0x1c/0x74) from [c0062fd8]
(clockevents_config_and_register+0x20/0x2c)
[c0062fd8] (clockevents_config_and_register+0x20/0x2c) from [c02b8e8c]
(arch_timer_setup+0xa8/0x134)
[c02b8e8c] (arch_timer_setup+0xa8/0x134) from [c04b47b4]
(arch_timer_init+0x1f4/0x24c)
[c04b47b4] (arch_timer_init+0x1f4/0x24c) from [c04b40d8]
(clocksource_of_init+0x34/0x58)
[c04b40d8] (clocksource_of_init+0x34/0x58) from [c049ed8c]
(time_init+0x20/0x2c)
[c049ed8c] (time_init+0x20/0x2c) from [c049b95c]
(start_kernel+0x1e0/0x39c)
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 7d7cc77..668ce5d 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -96,6 +96,7 @@
1 14 0xf08,
1 11 0xf08,
1 10 0xf08;
+ clock-frequency = 2400;
};
mct@101C {
--
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
Re: [PATCH v11 0/8] PHY framework
Hi Greg, On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote: On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. Alright, thanks. Just a gentle ping on this one... Let me know if you want me to rebase this patch series on the latest mainline HEAD. Thanks Kishon -- 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
