Re: [PATCH v11 0/8] PHY framework
On Fri, Sep 20, 2013 at 11:04:40AM +0530, Kishon Vijay Abraham I wrote: 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. Yes please. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*
On 20 September 2013 02:33, Nishanth Menon n...@ti.com wrote:
opp_get_opp_count
opp_find_freq_exact
opp_init_cpufreq_table
opp_free_cpufreq_table
The only problem I see is that routines names for few of them are getting
really long now.. Otherwise not much I could find...
Though you had following changes, which you could have avoided in this
hard to review patchset:
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
new_opp = [-kzalloc(sizeof(struct
opp),-]{+kzalloc(sizeof(*new_opp),+} GFP_KERNEL);
new_opp = [-kmalloc(sizeof(struct
opp),-]{+kmalloc(sizeof(*new_opp),+} GFP_KERNEL);
It is almost impossible to catch these with naked eyes for such long
patches.. I took help of --word-diff though :)
If no one else sees these as problems then feel free to add my:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On 18/09/13 14:08, Archit Taneja wrote:
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that
require
regulators. The output's connect op tries to get a regulator which may not
exist
yet because it might get registered later in the kernel boot.
omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe
deferral if a panel's connect op returns -EPROBE_DEFER.
The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we
have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This fixes boot with omapdrm on an omap4 panda ES board. The regulators used
by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 5
drivers/gpu/drm/omapdrm/omap_drv.c | 51
+
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
3 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(mgr_ops);
}
+void omap_crtc_pre_uninit(void)
+{
+ dss_uninstall_mgr_ops();
+}
+
/* initialize crtc */
struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..cbe5d8e 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,24 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev-driver-connect(dssdev);
+ if (r == -EPROBE_DEFER) {
+ return r;
+ } else if (r) {
+ dev_warn(dssdev-dev, could not connect display: %s\n,
+ dssdev-name);
+ }
+ }
+
+ return 0;
+}
Beagle-xm with DT boot doesn't work with this. There are no displays at
omapdrm probe time, so omapdrm doesn't find any displays. I added the
changes below, which made it work.
Tomi
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index cbe5d8e..e315413 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -91,6 +91,7 @@ static int omap_connect_dssdevs(void)
{
int r;
struct omap_dss_device *dssdev = NULL;
+ bool no_displays = true;
for_each_dss_dev(dssdev) {
r = dssdev-driver-connect(dssdev);
@@ -99,9 +100,14 @@ static int omap_connect_dssdevs(void)
} else if (r) {
dev_warn(dssdev-dev, could not connect display: %s\n,
dssdev-name);
+ } else {
+ no_displays = false;
}
}
+ if (no_displays)
+ return -EPROBE_DEFER;
+
return 0;
}
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On Friday 20 September 2013 01:39 PM, Tomi Valkeinen wrote:
snip
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev-driver-connect(dssdev);
+ if (r == -EPROBE_DEFER) {
+ return r;
+ } else if (r) {
+ dev_warn(dssdev-dev, could not connect display: %s\n,
+ dssdev-name);
+ }
+ }
+
+ return 0;
+}
Beagle-xm with DT boot doesn't work with this. There are no displays at
omapdrm probe time, so omapdrm doesn't find any displays. I added the
changes below, which made it work.
Tomi
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index cbe5d8e..e315413 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -91,6 +91,7 @@ static int omap_connect_dssdevs(void)
{
int r;
struct omap_dss_device *dssdev = NULL;
+ bool no_displays = true;
for_each_dss_dev(dssdev) {
r = dssdev-driver-connect(dssdev);
@@ -99,9 +100,14 @@ static int omap_connect_dssdevs(void)
} else if (r) {
dev_warn(dssdev-dev, could not connect display:
%s\n,
dssdev-name);
+ } else {
+ no_displays = false;
}
}
+ if (no_displays)
+ return -EPROBE_DEFER;
+
return 0;
}
I suppose we would hit this case if all of the displays are deferred
because of some dependency and are probed after omapdrm probes.
Is that the case with beagle-xm?
I think we need to move this from pdev_probe() anyway. I don't see other
drivers doing much in pdev_probe(), they do most of their stuff in
dev_load() itself. I'll try with that along with disabling of the
dssdevs in encoder's destroy.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On 20/09/13 11:49, Archit Taneja wrote: I suppose we would hit this case if all of the displays are deferred because of some dependency and are probed after omapdrm probes. Is that the case with beagle-xm? Yes, DVI is probed after omapdrm. There's also analog TV out on beagle. I'm not sure why that wasn't ready earlier, or was it available at all. I didn't study it further. If the analog tv would've been available, omapdrm would have started with only tv out, and DVI would have been left out. So it's still not perfect. I think we need to move this from pdev_probe() anyway. I don't see other drivers doing much in pdev_probe(), they do most of their stuff in dev_load() itself. I'll try with that along with disabling of the dssdevs in encoder's destroy. Ok. The dssdevs are disabled in omap_connector already, though. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Hi,
I have a few comments, mostly on the DT binding and parsing.
diff --git a/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
new file mode 100644
index 000..5d465cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
@@ -0,0 +1,39 @@
+* IRQ CROSSBAR
+
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be irq-crossbar
Missing vendor prefix, this should be something like ti,irq-crossbar.
Does this have a more specific name than CROSSBAR that can be used to
qualify it?
+- interrupt-parent: phandle to crossbar's interrupt parent.
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupt-cells: Should be the same value as the interrupt parent.
That doesn't make sense. The crossbar driver is necessarily interpreting
these cells in a way the parent won't (as it supports more interrupts).
What are the meaning of these cells?
+- reg: Base address and the size of the crossbar registers.
+- max-crossbar-lines: Total number of input lines of the crossbar.
+- max-irqs: Total number of irqs available at the interrupt controller.
Is this the maximum number of interrupts targeting the parent interrupt
controller? Starting at what number, ending at what number? Can this
have gaps?
Is this a shortcut so in the GIC case you don't have to describe up to
160 interrupts? I can see why you don't want to, but there's a big loss
of generality here...
+- reg-size: size of the crossbar registers.
As in the size of all the registers (the size component of reg)?
Or is this the size of each individual register? Does that apply to all
registers or only a subset of them?
What units are these in, bytes?
What are valid sizes?
Is this really that configurable?
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+crossbar. These interrupt lines are reserved in the soc,
+so crossbar bar driver should not consider them as free
+lines.
Are these reserved inputs lines, or outputs to the parent interrupt
controller?
What is the format of each entry in this list?
The example seems to be a different format to the parent interrupt
controller (which per your binding also defined the crossbar's interrupt
format). While 0 1 2 is a valid interrupt per the GIC binding (SPI 0
edge-triggered both ways), 3 5 6, 131 132 139, and 140 . . are
not.
+
+Examples:
+ crossbar_mpu: @4a02 {
+ compatible = irq-crossbar;
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x4a002a48 0x130;
+ max-crossbar-lines = 512;
+ max-irqs = 160;
+ reg-size = 2;
+ irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ #address-cells = 1;
+ #size-cells = 1;
Why are there #address-cells and #size cells? This has no children, and
this affects any interrupt-map property (as the parent unit address now
must be a single cell, that isn't going to be used).
[...]
+static int crossbar_set_affinity(struct irq_data *d,
+const struct cpumask *mask_val,
+bool force)
+{
+ struct irq_chip *chip;
+ struct irq_data *data;
+ int ret = 0;
+
+ crossbar_to_irq_chip_data(d-hwirq, chip, data);
+
+ if (chip-irq_set_affinity)
+ ret = chip-irq_set_affinity(data, mask_val, force);
+
+ return ret;
So if our parent chip can't set affinity, we pretend it can?
irq_set_affinity in kernel/irq/manage.c returns -EINVAL if an irqchip
doesn't have irq_set_affinity.
+/*
+ * Request and free are already called in atomic contexts
+ */
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq = cb-crossbar_map[cb_no].hwirq;
+ int err;
+
+ err = request_threaded_irq(virq, crossbar_irq, NULL,
+ 0, CROSSBAR, irq);
+ if (err)
+ pr_err(\n request_irq failed for crossbar %d, cb_no);
Why does the print begin with a newline rather than ending with one?
+
+ return 0;
+}
[...]
+static int crossbar_domain_xlate(struct irq_domain *d,
+struct
Re: [RFC PATCH 12/15] ARM: dts: omap5: add ocp2scp1 address resource
Hi, On 09/19/2013 05:17 PM, Sergei Shtylyov wrote: On 09/19/2013 05:23 PM, Roger Quadros wrote: Add OCP2SCP1 module address space. CC: Benoit Cousson bcous...@baylibre.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap5.dtsi |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 06aa665..8a88a94 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -663,6 +663,7 @@ #size-cells = 1; ranges; ti,hwmods = ocp2scp1; +reg = 0x4a08 0x1f; Are you sure length is not 0x20? Actually there are just 4 of 32-bit registers with the last one starting at 0x18, so I think length should be 0x1c. I copied 0x1f from omap4.dtsi. Looks like that is wrong as well. But it is harmless as nobody else is using that address. I'll fix this to 0x1c in next rev. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: dwc3: Remove redundant pci_set_drvdata
Driver core sets driver data to NULL upon failure or remove. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/usb/dwc3/dwc3-pci.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 997ebe4..f41ce36 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -164,7 +164,6 @@ static int dwc3_pci_probe(struct pci_dev *pci, return 0; err3: - pci_set_drvdata(pci, NULL); platform_device_put(dwc3); err1: pci_disable_device(pci); @@ -179,7 +178,6 @@ static void dwc3_pci_remove(struct pci_dev *pci) platform_device_unregister(glue-dwc3); platform_device_unregister(glue-usb2_phy); platform_device_unregister(glue-usb3_phy); - pci_set_drvdata(pci, NULL); pci_disable_device(pci); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Hi Mark,
On Friday 20 September 2013 02:28 PM, Mark Rutland wrote:
Hi,
I have a few comments, mostly on the DT binding and parsing.
Thanks for the review. The idea of seeing the crossbar as a new IRQCHIP
itself did not go and the latest direction on this was to handle it inside the
GIC.
http://www.spinics.net/lists/linux-omap/msg97085.html
I am working on that now.
I would have agreed with most of the comments below, otherwise.
diff --git a/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
new file mode 100644
index 000..5d465cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
@@ -0,0 +1,39 @@
+* IRQ CROSSBAR
+
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be irq-crossbar
Missing vendor prefix, this should be something like ti,irq-crossbar.
Does this have a more specific name than CROSSBAR that can be used to
qualify it?
yes, ti,irq-crossbar. Not sure if it can be called as anything
generically apart from crossbar .
+- interrupt-parent: phandle to crossbar's interrupt parent.
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupt-cells: Should be the same value as the interrupt parent.
That doesn't make sense. The crossbar driver is necessarily interpreting
these cells in a way the parent won't (as it supports more interrupts).
What are the meaning of these cells?
These properties were added so that the DT code identifies this as a
interrupt controller and map the children's irq in to this domain and
to map the free irqs allocated in this driver to its parent.
+- reg: Base address and the size of the crossbar registers.
+- max-crossbar-lines: Total number of input lines of the crossbar.
+- max-irqs: Total number of irqs available at the interrupt controller.
Is this the maximum number of interrupts targeting the parent interrupt
controller? Starting at what number, ending at what number? Can this
have gaps?
Is this a shortcut so in the GIC case you don't have to describe up to
160 interrupts? I can see why you don't want to, but there's a big loss
of generality here...
Yes, this was the maximum irqs available at the parent.
The gaps was not considered here because it was mentioned
used the below property irqs-reserved.
+- reg-size: size of the crossbar registers.
As in the size of all the registers (the size component of reg)?
Or is this the size of each individual register? Does that apply to all
registers or only a subset of them?
What units are these in, bytes?
What are valid sizes?
Is this really that configurable?
This was meant to describe the size a individual register and applied to
all. This was used to choose the API's to write. But yes some more
description could be made here.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+crossbar. These interrupt lines are reserved in the soc,
+so crossbar bar driver should not consider them as free
+lines.
Are these reserved inputs lines, or outputs to the parent interrupt
controller?
What is the format of each entry in this list?
The example seems to be a different format to the parent interrupt
controller (which per your binding also defined the crossbar's interrupt
format). While 0 1 2 is a valid interrupt per the GIC binding (SPI 0
edge-triggered both ways), 3 5 6, 131 132 139, and 140 . . are
not.
These were parent's input lines that were not muxed from crossbar
but directly connected from peripherals, so the driver should not
consider it as a free line while allocating a irq. This property was meant to
interpreted only in this driver.
+
+Examples:
+ crossbar_mpu: @4a02 {
+ compatible = irq-crossbar;
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x4a002a48 0x130;
+ max-crossbar-lines = 512;
+ max-irqs = 160;
+ reg-size = 2;
+ irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ #address-cells = 1;
+ #size-cells = 1;
Why are there #address-cells and #size cells? This has no children, and
this affects any interrupt-map property (as the parent unit address now
must be a single cell, that isn't going to be used).
[...]
yes, they could have been
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On Friday 20 September 2013 02:25 PM, Tomi Valkeinen wrote: On 20/09/13 11:49, Archit Taneja wrote: I suppose we would hit this case if all of the displays are deferred because of some dependency and are probed after omapdrm probes. Is that the case with beagle-xm? Yes, DVI is probed after omapdrm. There's also analog TV out on beagle. I'm not sure why that wasn't ready earlier, or was it available at all. I didn't study it further. If the analog tv would've been available, omapdrm would have started with only tv out, and DVI would have been left out. So it's still not perfect. Right, I suppose omapdrm should be probed only after all the dssdevs are probed. That's a bit tough to do. I think we need to move this from pdev_probe() anyway. I don't see other drivers doing much in pdev_probe(), they do most of their stuff in dev_load() itself. I'll try with that along with disabling of the dssdevs in encoder's destroy. Ok. The dssdevs are disabled in omap_connector already, though. I couldn't find where it is disabled in omap_connector. The only function which calls dssdrv-disable is omap_connector_set_enabled(). That doesn't seem to be called in omap_connector. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 15/15] arm: dts: dra7: add sata node
Hi,
On 09/19/2013 05:11 PM, Sergei Shtylyov wrote:
Hello.
On 09/19/2013 05:24 PM, Roger Quadros wrote:
From: Balaji T K balaj...@ti.com
Add support for sata controller.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 49
+++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..545545d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -426,6 +426,55 @@
dma-names = tx, rx;
};
+omap_control_sata: control-phy@4a002374 {
+compatible = ti,control-phy-pipe3;
+reg = 0x4a002374 0x4;
+reg-names = power;
+clocks = sys_clkin1;
+clock-names = sysclk;
+};
+
+ocp2scp3: ocp2scp3@4a09 {
+compatible = ti,omap-ocp2scp;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+ti,hwmods = ocp2scp3;
+reg = 0x4a09 0x1f; /* ocp2scp3 */
+reg-names = ocp2scp3;
+sata_phy: sataphy@4A096000 {
It's better to name the PHY nodes uniformly after already standard
ethernet-phy and your control-phy.
OK. will fix it to sata-phy.
+compatible = ti,phy-pipe3-sata;
+reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+reg-names = phy_rx, phy_tx, pll_ctrl;
+ctrl-module = omap_control_sata;
+clocks = sata_ref_clk,
+ sys_clkin1;
+clock-names = optclk, sysclk;
+#phy-cells = 0;
+};
+};
+
+sata: sata@4a141100 {
+compatible = ti,sata;
+ti,hwmods = sata;
+reg = 0x4a141100 0x7;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+dwc-ahci@4a14 {
Hm, ePAPR spec. [1] says that the name of a node should be somewhat
generic, reflecting the function of the device and not its precise
programming model, so it looks like the name should be sata as well. I'm a
bit at a loss here, not sure why you had to use the nested device nodes.
ok. will fix it to sata.
I've nested it because the wrapper registers are not part of the AHCI sata
controller.
They are TI specific registers for power management.
Similar setup is on the USB controller. Please see omap_dwc3 node.
But if you have better idea, please let me know.
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100;
+ interrupts = 0 54 0x4;
+ phys = sata_phy;
Hm, it's the third PHY related generic property I'm encountering. First,
there was phy-handle, then phy, now phys... Seems like a bit too much.
:-)
I'm afraid but this is how the designers have made it.
1) control-phy-pipe3 is that part of the PHY which sits in control module space
and is different
from the sata-phy space and hence needs a different node. If it were to me, I
would just put this
resource in sata-phy node, but there was a discussion about this earlier to do
it otherwise [1].
2) sata-phy (sataphy) is the actual SATA PHY device.
3) phys is just a reference to the sata_phy and is used via the generic PHY
framework.
It is upto the sata driver to power up/down the phy.
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ clock-names = optclk;
+};
+};
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
cheers,
-roger
[1] - https://lkml.org/lkml/2012/9/10/399
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On 20/09/13 13:18, Archit Taneja wrote: On Friday 20 September 2013 02:25 PM, Tomi Valkeinen wrote: On 20/09/13 11:49, Archit Taneja wrote: I suppose we would hit this case if all of the displays are deferred because of some dependency and are probed after omapdrm probes. Is that the case with beagle-xm? Yes, DVI is probed after omapdrm. There's also analog TV out on beagle. I'm not sure why that wasn't ready earlier, or was it available at all. I didn't study it further. If the analog tv would've been available, omapdrm would have started with only tv out, and DVI would have been left out. So it's still not perfect. Right, I suppose omapdrm should be probed only after all the dssdevs are probed. That's a bit tough to do. Yes. Omapfb has the same issue. I think we need to move this from pdev_probe() anyway. I don't see other drivers doing much in pdev_probe(), they do most of their stuff in dev_load() itself. I'll try with that along with disabling of the dssdevs in encoder's destroy. Ok. The dssdevs are disabled in omap_connector already, though. I couldn't find where it is disabled in omap_connector. The only function which calls dssdrv-disable is omap_connector_set_enabled(). That doesn't seem to be called in omap_connector. Ah, right. Sorry, it seems I remembered totally wrong. I guess I was thinking about omap_dss_put_device instead. Tomi signature.asc Description: OpenPGP digital signature
[PATCH 51/51] ARM: 7805/1: mm: change max*pfn to include the physical offset of memory
From: Santosh Shilimkar santosh.shilim...@ti.com
Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these variable to calculate the dma bounce limit
using dma_mask.
Now since we have a architecture override possibility for DMAable
maximum pfns, lets make meaning of max*pfns as maximum pnfs on ARM
as well.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/dma-mapping.h |8
arch/arm/mm/init.c | 10 --
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 5b579b9..863cd84 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -64,6 +64,7 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void
*addr)
{
return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
}
+
#else
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
@@ -86,6 +87,13 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
void *addr)
}
#endif
+/* The ARM override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+ return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev-dma_mask);
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
/*
* DMA errors are defined by all-bits-set in the DMA address.
*/
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8aab24f..d50533c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -426,12 +426,10 @@ void __init bootmem_init(void)
* This doesn't seem to be used by the Linux memory manager any
* more, but is used by ll_rw_block. If we can get rid of it, we
* also get rid of some of the stuff above as well.
-*
-* Note: max_low_pfn and max_pfn reflect the number of _pages_ in
-* the system, not the maximum PFN.
*/
- max_low_pfn = max_low - PHYS_PFN_OFFSET;
- max_pfn = max_high - PHYS_PFN_OFFSET;
+ min_low_pfn = min;
+ max_low_pfn = max_low;
+ max_pfn = max_high;
}
/*
@@ -537,7 +535,7 @@ static inline void free_area_high(unsigned long pfn,
unsigned long end)
static void __init free_highpages(void)
{
#ifdef CONFIG_HIGHMEM
- unsigned long max_low = max_low_pfn + PHYS_PFN_OFFSET;
+ unsigned long max_low = max_low_pfn;
struct memblock_region *mem, *res;
/* set highmem page free */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 50/51] ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations
From: Santosh Shilimkar santosh.shilim...@ti.com DMA bounce limit is the maximum direct DMA'able memory beyond which bounce buffers has to be used to perform dma operations. MMC queue layr relies on dma_mask but its calculation is based on max_*pfn which don't have uniform meaning across architectures. So make use of dma_max_pfn() which is expected to return the DMAable maximum pfn value across architectures. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/mmc/card/queue.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c index fa9632e..357bbc5 100644 --- a/drivers/mmc/card/queue.c +++ b/drivers/mmc/card/queue.c @@ -15,6 +15,7 @@ #include linux/freezer.h #include linux/kthread.h #include linux/scatterlist.h +#include linux/dma-mapping.h #include linux/mmc/card.h #include linux/mmc/host.h @@ -196,7 +197,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, struct mmc_queue_req *mqrq_prev = mq-mqrq[1]; if (mmc_dev(host)-dma_mask *mmc_dev(host)-dma_mask) - limit = *mmc_dev(host)-dma_mask; + limit = dma_max_pfn(mmc_dev(host)) PAGE_SHIFT; mq-card = card; mq-queue = blk_init_queue(mmc_request_fn, lock); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 49/51] ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations
From: Santosh Shilimkar santosh.shilim...@ti.com DMA bounce limit is the maximum direct DMA'able memory beyond which bounce buffers has to be used to perform dma operations. SCSI driver relies on dma_mask but its calculation is based on max_*pfn which don't have uniform meaning across architectures. So make use of dma_max_pfn() which is expected to return the DMAable maximum pfn value across architectures. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/scsi/scsi_lib.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index d1549b7..7bd7f0d 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1684,7 +1684,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost) host_dev = scsi_get_device(shost); if (host_dev host_dev-dma_mask) - bounce_limit = *host_dev-dma_mask; + bounce_limit = dma_max_pfn(host_dev) PAGE_SHIFT; return bounce_limit; } -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 48/51] ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function
From: Santosh Shilimkar santosh.shilim...@ti.com
Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is trying to unify the meaning of max*_pfn on ARM
as the bootmem layer expects, breaks few block layer driver dma
bounce limit.
To fix this problem, we introduce dma_max_pfn(dev) generic helper with
a possibility of override from the architecture code. The helper converts
a DMA bitmask of bits to a block PFN number. In all the generic cases,
it is just dev-dma_mask PAGE_SHIFT and hence default behavior
is maintained as is.
Subsequent patches will make use of the helper. No functional change.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
include/linux/dma-mapping.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 27d1421..fd4aee2 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -153,6 +153,13 @@ static inline int dma_set_seg_boundary(struct device *dev,
unsigned long mask)
return -EIO;
}
+#ifndef dma_max_pfn
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+ return *dev-dma_mask PAGE_SHIFT;
+}
+#endif
+
static inline void *dma_zalloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 47/51] ARM: 7794/1: block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit()
From: Santosh Shilimkar santosh.shilim...@ti.com
The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.
No functional change.
The idea is to fix the bad assumptions about dma_mask wherever it could
be miss-interpreted.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
block/blk-settings.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index c50ecf0..026c151 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -195,17 +195,17 @@ EXPORT_SYMBOL(blk_queue_make_request);
/**
* blk_queue_bounce_limit - set bounce buffer limit for queue
* @q: the request queue for the device
- * @dma_mask: the maximum address the device can handle
+ * @max_addr: the maximum address the device can handle
*
* Description:
*Different hardware can have different requirements as to what pages
*it can do I/O directly to. A low level driver can call
*blk_queue_bounce_limit to have lower memory pages allocated as bounce
- *buffers for doing I/O to pages residing above @dma_mask.
+ *buffers for doing I/O to pages residing above @max_addr.
**/
-void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask)
+void blk_queue_bounce_limit(struct request_queue *q, u64 max_addr)
{
- unsigned long b_pfn = dma_mask PAGE_SHIFT;
+ unsigned long b_pfn = max_addr PAGE_SHIFT;
int dma = 0;
q-bounce_gfp = GFP_NOIO;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 45/51] DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks
This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/firmware/google/gsmi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 6eb535f..e5a67b2 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -764,6 +764,13 @@ static __init int gsmi_system_valid(void)
static struct kobject *gsmi_kobj;
static struct efivars efivars;
+static const struct platform_device_info gsmi_dev_info = {
+ .name = gsmi,
+ .id = -1,
+ /* SMI callbacks require 32bit addresses */
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static __init int gsmi_init(void)
{
unsigned long flags;
@@ -776,7 +783,7 @@ static __init int gsmi_init(void)
gsmi_dev.smi_cmd = acpi_gbl_FADT.smi_command;
/* register device */
- gsmi_dev.pdev = platform_device_register_simple(gsmi, -1, NULL, 0);
+ gsmi_dev.pdev = platform_device_register_full(gsmi_dev_info);
if (IS_ERR(gsmi_dev.pdev)) {
printk(KERN_ERR gsmi: unable to register platform device\n);
return PTR_ERR(gsmi_dev.pdev);
@@ -785,10 +792,6 @@ static __init int gsmi_init(void)
/* SMI access needs to be serialized */
spin_lock_init(gsmi_dev.lock);
- /* SMI callbacks require 32bit addresses */
- gsmi_dev.pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
- gsmi_dev.pdev-dev.dma_mask =
- gsmi_dev.pdev-dev.coherent_dma_mask;
ret = -ENOMEM;
gsmi_dev.dma_pool = dma_pool_create(gsmi, gsmi_dev.pdev-dev,
GSMI_BUF_SIZE, GSMI_BUF_ALIGN, 0);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 46/51] ARM: DMA-API: better handing of DMA masks for coherent allocations
We need to start treating DMA masks as something which is specific to
the bus that the device resides on, otherwise we're going to hit all
sorts of nasty issues with LPAE and 32-bit DMA controllers in 32-bit
systems, where memory is offset from PFN 0.
In order to start doing this, we convert the DMA mask to a PFN using
the device specific dma_to_pfn() macro. This is the reverse of the
pfn_to_dma() macro which is used to get the DMA address for the device.
This gives us a PFN mask, which we can then check against the PFN
limit of the DMA zone.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mm/dma-mapping.c | 49
arch/arm/mm/init.c|2 +
arch/arm/mm/mm.h |2 +
3 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f5e1a84..13d55e1 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -173,10 +173,30 @@ static u64 get_coherent_dma_mask(struct device *dev)
return 0;
}
- if ((~mask) (u64)arm_dma_limit) {
- dev_warn(dev, coherent DMA mask %#llx is smaller
-than system GFP_DMA mask %#llx\n,
-mask, (u64)arm_dma_limit);
+ /*
+* If the mask allows for more memory than we can address,
+* and we actually have that much memory, then fail the
+* allocation.
+*/
+ if (sizeof(mask) != sizeof(dma_addr_t)
+ mask (dma_addr_t)~0
+ dma_to_pfn(dev, ~0) arm_dma_pfn_limit) {
+ dev_warn(dev, Coherent DMA mask %#llx is larger than
dma_addr_t allows\n,
+mask);
+ dev_warn(dev, Driver did not use or check the return
value from dma_set_coherent_mask()?\n);
+ return 0;
+ }
+
+ /*
+* Now check that the mask, when translated to a PFN,
+* fits within the allowable addresses which we can
+* allocate.
+*/
+ if (dma_to_pfn(dev, mask) arm_dma_pfn_limit) {
+ dev_warn(dev, Coherent DMA mask %#llx (pfn %#lx-%#lx)
covers a smaller range of system memory than the DMA zone pfn 0x0-%#lx\n,
+mask,
+dma_to_pfn(dev, 0), dma_to_pfn(dev, mask) + 1,
+arm_dma_pfn_limit + 1);
return 0;
}
}
@@ -1007,8 +1027,27 @@ void arm_dma_sync_sg_for_device(struct device *dev,
struct scatterlist *sg,
*/
int dma_supported(struct device *dev, u64 mask)
{
- if (mask (u64)arm_dma_limit)
+ unsigned long limit;
+
+ /*
+* If the mask allows for more memory than we can address,
+* and we actually have that much memory, then we must
+* indicate that DMA to this device is not supported.
+*/
+ if (sizeof(mask) != sizeof(dma_addr_t)
+ mask (dma_addr_t)~0
+ dma_to_pfn(dev, ~0) arm_dma_pfn_limit)
+ return 0;
+
+ /*
+* Translate the device's DMA mask to a PFN limit. This
+* PFN number includes the page which we can DMA to.
+*/
+ limit = dma_to_pfn(dev, mask);
+
+ if (limit arm_dma_pfn_limit)
return 0;
+
return 1;
}
EXPORT_SYMBOL(dma_supported);
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index febaee7..8aab24f 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -218,6 +218,7 @@ EXPORT_SYMBOL(arm_dma_zone_size);
* so a successful GFP_DMA allocation will always satisfy this.
*/
phys_addr_t arm_dma_limit;
+unsigned long arm_dma_pfn_limit;
static void __init arm_adjust_dma_zone(unsigned long *size, unsigned long
*hole,
unsigned long dma_size)
@@ -240,6 +241,7 @@ void __init setup_dma_zone(const struct machine_desc *mdesc)
arm_dma_limit = PHYS_OFFSET + arm_dma_zone_size - 1;
} else
arm_dma_limit = 0x;
+ arm_dma_pfn_limit = arm_dma_limit PAGE_SHIFT;
#endif
}
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index d5a4e9a..d5a982d 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -81,8 +81,10 @@ extern __init void add_static_vm_early(struct static_vm
*svm);
#ifdef CONFIG_ZONE_DMA
extern phys_addr_t arm_dma_limit;
+extern unsigned long arm_dma_pfn_limit;
#else
#define arm_dma_limit ((phys_addr_t)~0)
+#define arm_dma_pfn_limit (~0ul PAGE_SHIFT)
#endif
extern phys_addr_t arm_lowmem_limit;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need to access the allocated musb platform device
from within its callbacks, which may be called during the musb
device probing.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/usb/musb/am35x.c| 50 ++
drivers/usb/musb/da8xx.c| 49 ++---
drivers/usb/musb/davinci.c | 48 ++--
drivers/usb/musb/tusb6010.c | 49 ++---
4 files changed, 68 insertions(+), 128 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 5c310c6..790b22b 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -89,7 +89,6 @@ struct am35x_glue {
struct clk *phy_clk;
struct clk *clk;
};
-#define glue_to_musb(g)platform_get_drvdata(g-musb)
/*
* am35x_musb_enable - enable interrupts
@@ -452,14 +451,18 @@ static const struct musb_platform_ops am35x_ops = {
.set_vbus = am35x_musb_set_vbus,
};
-static u64 am35x_dmamask = DMA_BIT_MASK(32);
+static const struct platform_device_info am35x_dev_info = {
+ .name = musb-hdrc,
+ .id = PLATFORM_DEVID_AUTO,
+ .dma_mask = DMA_BIT_MASK(32),
+};
static int am35x_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = dev_get_platdata(pdev-dev);
struct platform_device *musb;
struct am35x_glue *glue;
-
+ struct platform_device_info pinfo;
struct clk *phy_clk;
struct clk *clk;
@@ -471,12 +474,6 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}
- musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
- if (!musb) {
- dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
- }
-
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
@@ -503,12 +500,7 @@ static int am35x_probe(struct platform_device *pdev)
goto err6;
}
- musb-dev.parent= pdev-dev;
- musb-dev.dma_mask = am35x_dmamask;
- musb-dev.coherent_dma_mask = am35x_dmamask;
-
glue-dev = pdev-dev;
- glue-musb = musb;
glue-phy_clk = phy_clk;
glue-clk = clk;
@@ -516,22 +508,17 @@ static int am35x_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
- ret = platform_device_add_resources(musb, pdev-resource,
- pdev-num_resources);
- if (ret) {
- dev_err(pdev-dev, failed to add resources\n);
- goto err7;
- }
-
- ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
- if (ret) {
- dev_err(pdev-dev, failed to add platform_data\n);
- goto err7;
- }
-
- ret = platform_device_add(musb);
- if (ret) {
- dev_err(pdev-dev, failed to register musb device\n);
+ pinfo = am35x_dev_info;
+ pinfo.parent = pdev-dev;
+ pinfo.res = pdev-resource;
+ pinfo.num_res = pdev-num_resources;
+ pinfo.data = pdata;
+ pinfo.size_data = sizeof(*pdata);
+
+ glue-musb = musb = platform_device_register_full(pinfo);
+ if (IS_ERR(musb)) {
+ ret = PTR_ERR(musb);
+ dev_err(pdev-dev, failed to register musb device: %d\n,
ret);
goto err7;
}
@@ -550,9 +537,6 @@ static int am35x_probe(struct platform_device *pdev)
clk_put(phy_clk);
err3:
- platform_device_put(musb);
-
-err1:
kfree(glue);
err0:
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d9ddf41..2f2c1cb 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -472,7 +472,11 @@ static const struct musb_platform_ops da8xx_ops = {
.set_vbus = da8xx_musb_set_vbus,
};
-static u64 da8xx_dmamask = DMA_BIT_MASK(32);
+static const struct platform_device_info da8xx_dev_info = {
+ .name = musb-hdrc,
+ .id = PLATFORM_DEVID_AUTO,
+ .dma_mask = DMA_BIT_MASK(32),
+};
static int da8xx_probe(struct platform_device *pdev)
{
@@ -480,7 +484,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct musb_hdrc_platform_data *pdata = dev_get_platdata(pdev-dev);
struct platform_device *musb;
struct da8xx_glue *glue;
-
+ struct platform_device_info pinfo;
struct clk
[PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/ata/pata_ixp4xx_cf.c |5 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(pdev-dev);
+ int ret;
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
/* acquire resources and fill host */
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
data-cs0 = devm_ioremap(pdev-dev, cs0-start, 0x1000);
data-cs1 = devm_ioremap(pdev-dev, cs1-start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ int ret;
+
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
return drm_platform_init(exynos_drm_driver, pdev);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* set dma mask for device */
- /* NOTE: this is a workaround for the hwmod not initializing properly */
- dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto fail;
omap_dmm-dummy_pa = page_to_phys(omap_dmm-dummy_page);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/51] DMA-API: amba: get rid of separate dma_mask
AMBA Primecell devices always treat streaming and coherent DMA exactly
the same, so there's no point in having the masks separated.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/amba/bus.c |6 +-
drivers/of/platform.c|3 ---
include/linux/amba/bus.h |2 --
3 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index c670727..c4876ac 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -552,7 +552,6 @@ amba_aphb_device_add(struct device *parent, const char
*name,
if (!dev)
return ERR_PTR(-ENOMEM);
- dev-dma_mask = dma_mask;
dev-dev.coherent_dma_mask = dma_mask;
dev-irq[0] = irq1;
dev-irq[1] = irq2;
@@ -619,7 +618,7 @@ static void amba_device_initialize(struct amba_device *dev,
const char *name)
dev_set_name(dev-dev, %s, name);
dev-dev.release = amba_device_release;
dev-dev.bus = amba_bustype;
- dev-dev.dma_mask = dev-dma_mask;
+ dev-dev.dma_mask = dev-dev.coherent_dma_mask;
dev-res.name = dev_name(dev-dev);
}
@@ -663,9 +662,6 @@ int amba_device_register(struct amba_device *dev, struct
resource *parent)
amba_device_initialize(dev, dev-dev.init_name);
dev-dev.init_name = NULL;
- if (!dev-dev.coherent_dma_mask dev-dma_mask)
- dev_warn(dev-dev, coherent dma mask is unset\n);
-
return amba_device_add(dev, parent);
}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9b439ac..54382ba 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -284,9 +284,6 @@ static struct amba_device *of_amba_device_create(struct
device_node *node,
else
of_device_make_bus_id(dev-dev);
- /* setup amba-specific device info */
- dev-dma_mask = ~0;
-
/* Allow the HW Peripheral ID to be overridden */
prop = of_get_property(node, arm,primecell-periphid, NULL);
if (prop)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 43ec7e2..682df0e 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -30,7 +30,6 @@ struct amba_device {
struct device dev;
struct resource res;
struct clk *pclk;
- u64 dma_mask;
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
};
@@ -131,7 +130,6 @@ struct amba_device name##_device = {
\
struct amba_device name##_device = { \
.dev = __AMBA_DEV(busid, data, ~0ULL), \
.res = DEFINE_RES_MEM(base, SZ_4K), \
- .dma_mask = ~0ULL, \
.irq = irqs,\
.periphid = id, \
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/pl330.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..df8b10f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2903,6 +2903,10 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pdat = dev_get_platdata(adev-dev);
+ ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
/* Allocate a new DMAC and its Channels */
pdmac = devm_kzalloc(adev-dev, sizeof(*pdmac), GFP_KERNEL);
if (!pdmac) {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/51] DMA-API: net: emulex/benet: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/emulex/benet/be_main.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index 3224d28..2084151 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4335,19 +4335,11 @@ static int be_probe(struct pci_dev *pdev, const struct
pci_device_id *pdev_id)
adapter-netdev = netdev;
SET_NETDEV_DEV(netdev, pdev-dev);
- status = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ status = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!status) {
- status = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (status 0) {
- dev_err(pdev-dev, dma_set_coherent_mask failed\n);
- goto free_netdev;
- }
netdev-features |= NETIF_F_HIGHDMA;
} else {
- status = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
- if (!status)
- status = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
+ status = dma_set_mask_and_coherent(pdev-dev,
DMA_BIT_MASK(32));
if (status) {
dev_err(pdev-dev, Could not set PCI DMA Mask\n);
goto free_netdev;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/51] DMA-API: net: sfc/efx.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/sfc/efx.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 07c9bc4..2e27837 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1121,7 +1121,7 @@ static int efx_init_io(struct efx_nic *efx)
*/
while (dma_mask 0x7fffUL) {
if (dma_supported(pci_dev-dev, dma_mask)) {
- rc = dma_set_mask(pci_dev-dev, dma_mask);
+ rc = dma_set_mask_and_coherent(pci_dev-dev, dma_mask);
if (rc == 0)
break;
}
@@ -1134,16 +1134,6 @@ static int efx_init_io(struct efx_nic *efx)
}
netif_dbg(efx, probe, efx-net_dev,
using DMA mask %llx\n, (unsigned long long) dma_mask);
- rc = dma_set_coherent_mask(pci_dev-dev, dma_mask);
- if (rc) {
- /* dma_set_coherent_mask() is not *allowed* to
-* fail with a mask that dma_set_mask() accepted,
-* but just in case...
-*/
- netif_err(efx, probe, efx-net_dev,
- failed to set consistent DMA mask\n);
- goto fail2;
- }
efx-membase_phys = pci_resource_start(efx-pci_dev, EFX_MEM_BAR);
rc = pci_request_region(pci_dev, EFX_MEM_BAR, sfc);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/51] DMA-API: staging: et131x: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/staging/et131x/et131x.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index f73e58f..98edfa8 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -4797,21 +4797,8 @@ static int et131x_pci_setup(struct pci_dev *pdev,
pci_set_master(pdev);
/* Check the DMA addressing support of this device */
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))) {
- rc = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (rc 0) {
- dev_err(pdev-dev,
- Unable to obtain 64 bit DMA for consistent
allocations\n);
- goto err_release_res;
- }
- } else if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(32))) {
- rc = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
- if (rc 0) {
- dev_err(pdev-dev,
- Unable to obtain 32 bit DMA for consistent
allocations\n);
- goto err_release_res;
- }
- } else {
+ if (dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)) ||
+ dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32))) {
dev_err(pdev-dev, No usable DMA addressing method\n);
rc = -EIO;
goto err_release_res;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/51] DMA-API: net: intel/e1000: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/e1000/e1000_main.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..34672f8 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1018,19 +1018,14 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
*/
pci_using_dac = 0;
if ((hw-bus_type == e1000_bus_type_pcix)
- !dma_set_mask(pdev-dev, DMA_BIT_MASK(64))) {
- /* according to DMA-API-HOWTO, coherent calls will always
-* succeed if the set call did
-*/
- dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
+ !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) {
pr_err(No usable DMA config, aborting\n);
goto err_dma;
}
- dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
}
netdev-netdev_ops = e1000_netdev_ops;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/51] DMA-API: block: nvme-core: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/block/nvme-core.c | 10 -- 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c index da52092..26d03fa 100644 --- a/drivers/block/nvme-core.c +++ b/drivers/block/nvme-core.c @@ -1949,12 +1949,9 @@ static int nvme_dev_map(struct nvme_dev *dev) if (pci_request_selected_regions(pdev, bars, nvme)) goto disable_pci; - if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))) - dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64)); - else if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(32))) - dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); - else - goto disable_pci; + if (dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)) + dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32))) + goto disable; pci_set_drvdata(pdev, dev); dev-bar = ioremap(pci_resource_start(pdev, 0), 8192); @@ -2168,6 +2165,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id) INIT_LIST_HEAD(dev-namespaces); dev-pci_dev = pdev; + result = nvme_set_instance(dev); if (result) goto free; -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/staging/media/dt3155v4l/dt3155v4l.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c index 90d6ac4..081407b 100644 --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id) int err; struct dt3155_priv *pd; - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32)); - if (err) - return -ENODEV; - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (err) return -ENODEV; pd = kzalloc(sizeof(*pd), GFP_KERNEL); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/51] DMA-API: net: broadcom/bnx2x: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 2f8dbbb..e6c3e66 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -12072,13 +12072,9 @@ static int bnx2x_set_coherency_mask(struct bnx2x *bp)
{
struct device *dev = bp-pdev-dev;
- if (dma_set_mask(dev, DMA_BIT_MASK(64)) == 0) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)) == 0) {
bp-flags |= USING_DAC_FLAG;
- if (dma_set_coherent_mask(dev, DMA_BIT_MASK(64)) != 0) {
- dev_err(dev, dma_set_coherent_mask failed,
aborting\n);
- return -EIO;
- }
- } else if (dma_set_mask(dev, DMA_BIT_MASK(32)) != 0) {
+ } else if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) != 0) {
dev_err(dev, System does not support DMA, aborting\n);
return -EIO;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/51] DMA-API: net: b43legacy: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/wireless/b43legacy/dma.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/b43legacy/dma.c
b/drivers/net/wireless/b43legacy/dma.c
index 42eb26c..b2ed179 100644
--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -806,12 +806,9 @@ static int b43legacy_dma_set_mask(struct b43legacy_wldev
*dev, u64 mask)
/* Try to set the DMA mask. If it fails, try falling back to a
* lower mask, as we can always also support a lower one. */
while (1) {
- err = dma_set_mask(dev-dev-dma_dev, mask);
- if (!err) {
- err = dma_set_coherent_mask(dev-dev-dma_dev, mask);
- if (!err)
- break;
- }
+ err = dma_set_mask_and_coherent(dev-dev-dma_dev, mask);
+ if (!err)
+ break;
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = true;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/51] DMA-API: usb: bcma: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/usb/host/bcma-hcd.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/bcma-hcd.c b/drivers/usb/host/bcma-hcd.c index df13d42..205f4a3 100644 --- a/drivers/usb/host/bcma-hcd.c +++ b/drivers/usb/host/bcma-hcd.c @@ -227,8 +227,7 @@ static int bcma_hcd_probe(struct bcma_device *dev) /* TODO: Probably need checks here; is the core connected? */ - if (dma_set_mask(dev-dma_dev, DMA_BIT_MASK(32)) || - dma_set_coherent_mask(dev-dma_dev, DMA_BIT_MASK(32))) + if (dma_set_mask_and_coherent(dev-dma_dev, DMA_BIT_MASK(32))) return -EOPNOTSUPP; usb_dev = kzalloc(sizeof(struct bcma_hcd_device), GFP_KERNEL); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/51] DMA-API: video: clcd: add dma_set_mask_and_coherent() call
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/video/amba-clcd.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..afe4702 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -10,6 +10,7 @@
*
* ARM PrimeCell PL110 Color LCD Controller
*/
+#include linux/dma-mapping.h
#include linux/module.h
#include linux/kernel.h
#include linux/errno.h
@@ -551,6 +552,10 @@ static int clcdfb_probe(struct amba_device *dev, const
struct amba_id *id)
if (!board)
return -EINVAL;
+ ret = dma_set_mask_and_coherent(dev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out;
+
ret = amba_request_regions(dev, NULL);
if (ret) {
printk(KERN_ERR CLCD: unable to reserve regs region\n);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/51] DMA-API: usb: ssb-hcd: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/usb/host/ssb-hcd.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ssb-hcd.c b/drivers/usb/host/ssb-hcd.c index 74af2c6..0196f76 100644 --- a/drivers/usb/host/ssb-hcd.c +++ b/drivers/usb/host/ssb-hcd.c @@ -163,8 +163,7 @@ static int ssb_hcd_probe(struct ssb_device *dev, /* TODO: Probably need checks here; is the core connected? */ - if (dma_set_mask(dev-dma_dev, DMA_BIT_MASK(32)) || - dma_set_coherent_mask(dev-dma_dev, DMA_BIT_MASK(32))) + if (dma_set_mask_and_coherent(dev-dma_dev, DMA_BIT_MASK(32))) return -EOPNOTSUPP; usb_dev = kzalloc(sizeof(struct ssb_hcd_device), GFP_KERNEL); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/51] DMA-API: provide a helper to setup DMA masks
Many drivers contain code such as:
dev-dma_mask = dev-coherent_dma_mask;
dev-coherent_dma_mask = MASK;
Let's move this pattern out of drivers and have the DMA API provide a
helper for it. This helper uses dma_set_mask_and_coherent() to allow
platform issues to be properly dealt with via dma_set_mask()/
dma_is_supported().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
include/linux/dma-mapping.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index ec951f9..27d1421 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -111,6 +111,16 @@ static inline int dma_set_mask_and_coherent(struct device
*dev, u64 mask)
return rc;
}
+/*
+ * Similar to the above, except it deals with the case where the device
+ * does not have dev-dma_mask appropriately setup.
+ */
+static inline int dma_coerce_mask_and_coherent(struct device *dev, u64 mask)
+{
+ dev-dma_mask = dev-coherent_dma_mask;
+ return dma_set_mask_and_coherent(dev, mask);
+}
+
extern u64 dma_get_required_mask(struct device *dev);
static inline unsigned int dma_get_max_seg_size(struct device *dev)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/51] DMA-API: usb: ohci-sa1111: add a note about DMA masks
Add a comment to explain why this driver doesn't call any of the DMA API dma_set_mask() functions. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/usb/host/ohci-sa.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ohci-sa.c b/drivers/usb/host/ohci-sa.c index 17b2a7d..aa9e127 100644 --- a/drivers/usb/host/ohci-sa.c +++ b/drivers/usb/host/ohci-sa.c @@ -185,6 +185,12 @@ static int ohci_hcd_sa_probe(struct sa_dev *dev) if (usb_disabled()) return -ENODEV; + /* +* We don't call dma_set_mask_and_coherent() here because the +* DMA mask has already been appropraitely setup by the core +* SA- bus code (which includes bug workarounds.) +*/ + hcd = usb_create_hcd(ohci_sa_hc_driver, dev-dev, sa); if (!hcd) return -ENOMEM; -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers
This code sequence is unsafe in modules:
static u64 mask = DMA_BIT_MASK(something);
...
if (!dev-dma_mask)
dev-dma_mask = mask;
as if a module is reloaded, the mask will be pointing at the original
module's mask address, and this can lead to oopses. Moreover, they
all follow this with:
if (!dev-coherent_dma_mask)
dev-coherent_dma_mask = mask;
where 'mask' is the same value as the statically defined mask, and this
bypasses the architecture's check on whether the DMA mask is possible.
Fix these issues by using the new dma_coerce_coherent_and_mask()
function.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
sound/arm/pxa2xx-pcm.c |9 +++--
sound/soc/atmel/atmel-pcm.c | 11 ---
sound/soc/blackfin/bf5xx-ac97-pcm.c | 11 ---
sound/soc/blackfin/bf5xx-i2s-pcm.c | 10 --
sound/soc/davinci/davinci-pcm.c |9 +++--
sound/soc/fsl/fsl_dma.c |9 +++--
sound/soc/fsl/mpc5200_dma.c | 10 --
sound/soc/jz4740/jz4740-pcm.c | 12
sound/soc/kirkwood/kirkwood-dma.c |9 +++--
sound/soc/nuc900/nuc900-pcm.c |9 -
sound/soc/omap/omap-pcm.c | 11 ---
sound/soc/pxa/pxa2xx-pcm.c | 11 ---
sound/soc/s6000/s6000-pcm.c |9 +++--
sound/soc/samsung/dma.c | 11 ---
sound/soc/samsung/idma.c| 11 ---
15 files changed, 55 insertions(+), 97 deletions(-)
diff --git a/sound/arm/pxa2xx-pcm.c b/sound/arm/pxa2xx-pcm.c
index 69a2455..fb3b76f 100644
--- a/sound/arm/pxa2xx-pcm.c
+++ b/sound/arm/pxa2xx-pcm.c
@@ -83,8 +83,6 @@ static struct snd_pcm_ops pxa2xx_pcm_ops = {
.mmap = pxa2xx_pcm_mmap,
};
-static u64 pxa2xx_pcm_dmamask = 0x;
-
int pxa2xx_pcm_new(struct snd_card *card, struct pxa2xx_pcm_client *client,
struct snd_pcm **rpcm)
{
@@ -100,10 +98,9 @@ int pxa2xx_pcm_new(struct snd_card *card, struct
pxa2xx_pcm_client *client,
pcm-private_data = client;
pcm-private_free = pxa2xx_pcm_free_dma_buffers;
- if (!card-dev-dma_mask)
- card-dev-dma_mask = pxa2xx_pcm_dmamask;
- if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = 0x;
+ ret = dma_coerce_mask_and_coherent_mask(card-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out;
if (play) {
int stream = SNDRV_PCM_STREAM_PLAYBACK;
diff --git a/sound/soc/atmel/atmel-pcm.c b/sound/soc/atmel/atmel-pcm.c
index 3109db7..fbb87e3 100644
--- a/sound/soc/atmel/atmel-pcm.c
+++ b/sound/soc/atmel/atmel-pcm.c
@@ -68,18 +68,15 @@ int atmel_pcm_mmap(struct snd_pcm_substream *substream,
}
EXPORT_SYMBOL_GPL(atmel_pcm_mmap);
-static u64 atmel_pcm_dmamask = DMA_BIT_MASK(32);
-
int atmel_pcm_new(struct snd_soc_pcm_runtime *rtd)
{
struct snd_card *card = rtd-card-snd_card;
struct snd_pcm *pcm = rtd-pcm;
- int ret = 0;
+ int ret;
- if (!card-dev-dma_mask)
- card-dev-dma_mask = atmel_pcm_dmamask;
- if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(card-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
if (pcm-streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
pr_debug(atmel-pcm: allocating PCM playback DMA buffer\n);
diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c
b/sound/soc/blackfin/bf5xx-ac97-pcm.c
index 53f8408..1d4c676 100644
--- a/sound/soc/blackfin/bf5xx-ac97-pcm.c
+++ b/sound/soc/blackfin/bf5xx-ac97-pcm.c
@@ -415,19 +415,16 @@ static void bf5xx_pcm_free_dma_buffers(struct snd_pcm
*pcm)
}
}
-static u64 bf5xx_pcm_dmamask = DMA_BIT_MASK(32);
-
static int bf5xx_pcm_ac97_new(struct snd_soc_pcm_runtime *rtd)
{
struct snd_card *card = rtd-card-snd_card;
struct snd_pcm *pcm = rtd-pcm;
- int ret = 0;
+ int ret;
pr_debug(%s enter\n, __func__);
- if (!card-dev-dma_mask)
- card-dev-dma_mask = bf5xx_pcm_dmamask;
- if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(card-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
if (pcm-streams[SNDRV_PCM_STREAM_PLAYBACK].substream) {
ret = bf5xx_pcm_preallocate_dma_buffer(pcm,
diff --git a/sound/soc/blackfin/bf5xx-i2s-pcm.c
b/sound/soc/blackfin/bf5xx-i2s-pcm.c
index 9cb4a80..2a5b434 100644
--- a/sound/soc/blackfin/bf5xx-i2s-pcm.c
+++ b/sound/soc/blackfin/bf5xx-i2s-pcm.c
@@ -323,18 +323,16 @@ static struct snd_pcm_ops bf5xx_pcm_i2s_ops = {
.silence= bf5xx_pcm_silence,
};
-static u64 bf5xx_pcm_dmamask = DMA_BIT_MASK(32);
-
static int bf5xx_pcm_i2s_new(struct snd_soc_pcm_runtime *rtd)
{
[PATCH 30/51] DMA-API: dma: dw_dmac.c: convert to use dma_coerce_mask_and_coherent()
This code sequence:
if (!pdev-dev.dma_mask) {
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/dw/platform.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index e35d975..453822c 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -191,11 +191,9 @@ static int dw_probe(struct platform_device *pdev)
if (IS_ERR(chip-regs))
return PTR_ERR(chip-regs);
- /* Apply default dma_mask if needed */
- if (!dev-dma_mask) {
- dev-dma_mask = dev-coherent_dma_mask;
- dev-coherent_dma_mask = DMA_BIT_MASK(32);
- }
+ err = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (err)
+ return err;
pdata = dev_get_platdata(dev);
if (!pdata)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/51] DMA-API: ata: pata_octeon_cf: convert to use dma_coerce_mask_and_coherent()
Convert this code sequence: pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64); pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; to use dma_coerce_mask_and_coherent() to avoid bypassing the architecture check on the DMA mask. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/ata/pata_octeon_cf.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/ata/pata_octeon_cf.c b/drivers/ata/pata_octeon_cf.c index c51bbb9..6231d43 100644 --- a/drivers/ata/pata_octeon_cf.c +++ b/drivers/ata/pata_octeon_cf.c @@ -1014,8 +1014,9 @@ static int octeon_cf_probe(struct platform_device *pdev) } cf_port-c0 = ap-ioaddr.ctl_addr; - pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64); - pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; + rv = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)); + if (rv) + return ret; ata_port_desc(ap, cmd %p ctl %p, base, ap-ioaddr.ctl_addr); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
The code sequence:
isp-raw_dmamask = DMA_BIT_MASK(32);
isp-dev-dma_mask = isp-raw_dmamask;
isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/media/platform/omap3isp/isp.c |6 +++---
drivers/media/platform/omap3isp/isp.h |3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index df3a0ec..1c36080 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
isp-pdata = pdata;
isp-ref_count = 0;
- isp-raw_dmamask = DMA_BIT_MASK(32);
- isp-dev-dma_mask = isp-raw_dmamask;
- isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(isp-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
platform_set_drvdata(pdev, isp);
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index cd3eff4..ce65d3a 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -152,7 +152,6 @@ struct isp_xclk {
* @mmio_base_phys: Array with physical L4 bus addresses for ISP register
* regions.
* @mmio_size: Array with ISP register regions size in bytes.
- * @raw_dmamask: Raw DMA mask
* @stat_lock: Spinlock for handling statistics
* @isp_mutex: Mutex for serializing requests to ISP.
* @crashed: Bitmask of crashed entities (indexed by entity ID)
@@ -190,8 +189,6 @@ struct isp_device {
unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
- u64 raw_dmamask;
-
/* ISP Obj */
spinlock_t stat_lock; /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should access this member directly. Convert all direct write accesses to using the correct API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tejun Heo t...@kernel.org The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should access this member directly. Convert all direct write accesses to using the correct API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tejun Heo t...@kernel.org The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? Hmm... maybe hte pata_ixp4xx_cf.c part should be moved to the one which updates pata_octeon_cf.c? Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/51] DMA-API: net: b43: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/wireless/b43/dma.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index c51d2dc..1d7982a 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1065,12 +1065,9 @@ static int b43_dma_set_mask(struct b43_wldev *dev, u64
mask)
/* Try to set the DMA mask. If it fails, try falling back to a
* lower mask, as we can always also support a lower one. */
while (1) {
- err = dma_set_mask(dev-dev-dma_dev, mask);
- if (!err) {
- err = dma_set_coherent_mask(dev-dev-dma_dev, mask);
- if (!err)
- break;
- }
+ err = dma_set_mask_and_coherent(dev-dev-dma_dev, mask);
+ if (!err)
+ break;
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = true;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*
On 12:44-20130920, Viresh Kumar wrote:
On 20 September 2013 02:33, Nishanth Menon n...@ti.com wrote:
opp_get_opp_count
opp_find_freq_exact
opp_init_cpufreq_table
opp_free_cpufreq_table
The only problem I see is that routines names for few of them are getting
really long now.. Otherwise not much I could find...
I am open to suggestions if any one feels we can improve this better.
Though you had following changes, which you could have avoided in this
hard to review patchset:
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
new_opp = [-kzalloc(sizeof(struct
opp),-]{+kzalloc(sizeof(*new_opp),+} GFP_KERNEL);
new_opp = [-kmalloc(sizeof(struct
opp),-]{+kmalloc(sizeof(*new_opp),+} GFP_KERNEL);
It is almost impossible to catch these with naked eyes for such long
patches.. I took help of --word-diff though :)
I believe that change was from Patch #2[1]
yes, you are right, I had squashed this patch in to squelch checkpatch
warnings:
CHECK: Prefer kzalloc(sizeof(*new_opp)...) over kzalloc(sizeof(struct
dev_pm_opp)...)
#177: FILE: drivers/base/power/opp.c:406:
+ new_opp = kzalloc(sizeof(struct dev_pm_opp), GFP_KERNEL);
CHECK: Prefer kmalloc(sizeof(*new_opp)...) over kmalloc(sizeof(struct
dev_pm_opp)...)
#191: FILE: drivers/base/power/opp.c:495:
+ new_opp = kmalloc(sizeof(struct dev_pm_opp), GFP_KERNEL);
I had added a comment:
Minor checkpatch warning fixes as a result of this change was fixed as
well.
Would you suggest I split the change off to a separate patch or improve
the comment a little more?
If no one else sees these as problems then feel free to add my:
Acked-by: Viresh Kumar viresh.ku...@linaro.org
[1] https://patchwork.kernel.org/patch/2913551/
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 32/51] DMA-API: mmc: sdhci-acpi: use dma_coerce_mask_and_coherent()
The code sequence:
dev-dma_mask = dev-coherent_dma_mask;
dev-coherent_dma_mask = dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/mmc/host/sdhci-acpi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index cdd4ce0..ef19874 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -310,8 +310,9 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
dma_mask = DMA_BIT_MASK(32);
}
- dev-dma_mask = dev-coherent_dma_mask;
- dev-coherent_dma_mask = dma_mask;
+ err = dma_coerce_mask_and_coherent(dev, dma_mask);
+ if (err)
+ goto err_free;
}
if (c-slot) {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 33/51] DMA-API: net: nxp/lpc_eth: use dma_coerce_mask_and_coherent()
The code sequence:
pldat-pdev-dev.coherent_dma_mask = 0x;
pldat-pdev-dev.dma_mask = pldat-pdev-dev.coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/nxp/lpc_eth.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c
b/drivers/net/ethernet/nxp/lpc_eth.c
index a061b93..ba3ca18 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1399,8 +1399,10 @@ static int lpc_eth_drv_probe(struct platform_device
*pdev)
}
if (pldat-dma_buff_base_v == 0) {
- pldat-pdev-dev.coherent_dma_mask = 0x;
- pldat-pdev-dev.dma_mask = pldat-pdev-dev.coherent_dma_mask;
+ ret = dma_coerce_mask_and_coherent(pdev-dev,
DMA_BIT_MASK(32));
+ if (ret)
+ goto err_out_free_irq;
+
pldat-dma_buff_size = PAGE_ALIGN(pldat-dma_buff_size);
/* Allocate a chunk of memory for the DMA ethernet buffers
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 34/51] DMA-API: net: octeon: use dma_coerce_mask_and_coherent()
The code sequence: pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64); pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; bypasses the architectures check on the DMA mask. It can be replaced with dma_coerce_mask_and_coherent(), avoiding the direct initialization of this mask. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/net/ethernet/octeon/octeon_mgmt.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c index 622aa75..2006a07 100644 --- a/drivers/net/ethernet/octeon/octeon_mgmt.c +++ b/drivers/net/ethernet/octeon/octeon_mgmt.c @@ -1552,8 +1552,9 @@ static int octeon_mgmt_probe(struct platform_device *pdev) p-phy_np = of_parse_phandle(pdev-dev.of_node, phy-handle, 0); - pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64); - pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; + result = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)); + if (result) + goto err; netif_carrier_off(netdev); result = register_netdev(netdev); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/usb/chipidea/ci_hdrc_imx.c |5 +++--
drivers/usb/dwc3/dwc3-exynos.c |5 +++--
drivers/usb/gadget/lpc32xx_udc.c |4 +++-
drivers/usb/host/ehci-atmel.c |5 +++--
drivers/usb/host/ehci-octeon.c |4 +++-
drivers/usb/host/ehci-omap.c |8 +---
drivers/usb/host/ehci-orion.c |5 +++--
drivers/usb/host/ehci-platform.c |7 ---
drivers/usb/host/ehci-s5p.c|5 +++--
drivers/usb/host/ehci-spear.c |5 +++--
drivers/usb/host/ehci-tegra.c |5 +++--
drivers/usb/host/ohci-at91.c |7 ---
drivers/usb/host/ohci-exynos.c |5 +++--
drivers/usb/host/ohci-nxp.c|4 +++-
drivers/usb/host/ohci-octeon.c |4 +++-
drivers/usb/host/ohci-omap3.c |8 +---
drivers/usb/host/ohci-pxa27x.c |6 --
drivers/usb/host/ohci-spear.c |5 +++--
drivers/usb/host/uhci-platform.c |5 +++--
19 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 74d998d..bf33bd3 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -123,8 +123,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
- if (!pdev-dev.coherent_dma_mask)
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto err_clk;
if (data-usbmisc_data) {
ret = imx_usbmisc_init(data-usbmisc_data);
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 2f2e88a..c10b324 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -121,8 +121,9 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
*/
if (!dev-dma_mask)
dev-dma_mask = dev-coherent_dma_mask;
- if (!dev-coherent_dma_mask)
- dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto err1;
platform_set_drvdata(pdev, exynos);
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx_udc.c
index 67128be..6a2a65a 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -3078,7 +3078,9 @@ static int __init lpc32xx_udc_probe(struct
platform_device *pdev)
udc-isp1301_i2c_client-addr);
pdev-dev.dma_mask = lpc32xx_usbd_dmamask;
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (retval)
+ goto resource_fail;
udc-board = lpc32xx_usbddata;
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..5831a88 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
*/
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
- if (!pdev-dev.coherent_dma_mask)
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (retval)
+ goto fail_create_hcd;
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd) {
diff --git a/drivers/usb/host/ehci-octeon.c b/drivers/usb/host/ehci-octeon.c
index ab0397e..4c528b2 100644
--- a/drivers/usb/host/ehci-octeon.c
+++ b/drivers/usb/host/ehci-octeon.c
@@ -116,8 +116,10 @@ static int ehci_octeon_drv_probe(struct platform_device
*pdev)
* We can DMA from anywhere. But the descriptors must be in
* the lower 4GB.
*/
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
pdev-dev.dma_mask = ehci_octeon_dma_mask;
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
hcd = usb_create_hcd(ehci_octeon_hc_driver, pdev-dev, octeon);
if (!hcd)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 78b01fa..d0759c5 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -104,7 +104,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
struct resource *res;
struct usb_hcd *hcd;
void __iomem *regs;
- int ret = -ENODEV;
+ int ret;
int irq;
int i;
[PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/usb/chipidea/ci_hdrc_imx.c |4 +--- drivers/usb/dwc3/dwc3-exynos.c |4 +--- drivers/usb/host/ehci-atmel.c |4 +--- drivers/usb/host/ehci-omap.c |4 +--- drivers/usb/host/ehci-orion.c |4 +--- drivers/usb/host/ehci-platform.c |5 ++--- drivers/usb/host/ehci-s5p.c|4 +--- drivers/usb/host/ehci-spear.c |4 +--- drivers/usb/host/ehci-tegra.c |4 +--- drivers/usb/host/ohci-at91.c |4 +--- drivers/usb/host/ohci-exynos.c |4 +--- drivers/usb/host/ohci-nxp.c|3 +-- drivers/usb/host/ohci-octeon.c |3 +-- drivers/usb/host/ohci-omap3.c |4 +--- drivers/usb/host/ohci-pxa27x.c |4 +--- drivers/usb/host/ohci-spear.c |4 +--- drivers/usb/host/uhci-platform.c |4 +--- 17 files changed, 18 insertions(+), 49 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index bf33bd3..af731db 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -121,9 +121,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) pdata.phy = data-phy; - if (!pdev-dev.dma_mask) - pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; - ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + ret = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (ret) goto err_clk; diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index c10b324..8b20c70 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -119,9 +119,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we move to full device tree support this will vanish off. */ - if (!dev-dma_mask) - dev-dma_mask = dev-coherent_dma_mask; - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); if (ret) goto err1; diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c index 5831a88..8e7323e 100644 --- a/drivers/usb/host/ehci-atmel.c +++ b/drivers/usb/host/ehci-atmel.c @@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we have dma capability bindings this can go away. */ - if (!pdev-dev.dma_mask) - pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; - retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + retval = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (retval) goto fail_create_hcd; diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index d0759c5..6fa82d6 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -144,9 +144,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we have dma capability bindings this can go away. */ - if (!dev-dma_mask) - dev-dma_mask = dev-coherent_dma_mask; - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); if (ret) return ret; diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c index 5870206..2ba7673 100644 --- a/drivers/usb/host/ehci-orion.c +++ b/drivers/usb/host/ehci-orion.c @@ -180,9 +180,7 @@ static int ehci_orion_drv_probe(struct platform_device *pdev) * set. Since shared usb code relies on it, set it here for * now. Once we have dma capability bindings this can go away. */ - if (!pdev-dev.dma_mask) - pdev-dev.dma_mask = pdev-dev.coherent_dma_mask; - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + err = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (err) goto err1; diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 5b0cd2d..7f30b71 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -89,9 +89,8 @@ static int ehci_platform_probe(struct platform_device *dev) */ if (!dev_get_platdata(dev-dev)) dev-dev.platform_data = ehci_platform_defaults; - if (!dev-dev.dma_mask) - dev-dev.dma_mask = dev-dev.coherent_dma_mask; - err = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32)); + + err = dma_coerce_mask_and_coherent(dev-dev, DMA_BIT_MASK(32)); if (err) return err; diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index 10d6a2e..d919ed4 100644
[PATCH 38/51] DMA-API: staging: use dma_set_coherent_mask()
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/staging/dwc2/platform.c|5 +++--
drivers/staging/imx-drm/imx-drm-core.c |8 ++--
drivers/staging/imx-drm/ipuv3-crtc.c |4 +++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dwc2/platform.c b/drivers/staging/dwc2/platform.c
index 44cce2f..1d68c49 100644
--- a/drivers/staging/dwc2/platform.c
+++ b/drivers/staging/dwc2/platform.c
@@ -100,8 +100,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
*/
if (!dev-dev.dma_mask)
dev-dev.dma_mask = dev-dev.coherent_dma_mask;
- if (!dev-dev.coherent_dma_mask)
- dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ retval = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+ if (retval)
+ return retval;
irq = platform_get_irq(dev, 0);
if (irq 0) {
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 47c5888..847f430 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -805,6 +805,12 @@ static struct drm_driver imx_drm_driver = {
static int imx_drm_platform_probe(struct platform_device *pdev)
{
+ int ret;
+
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
imx_drm_device-dev = pdev-dev;
return drm_platform_init(imx_drm_driver, pdev);
@@ -847,8 +853,6 @@ static int __init imx_drm_init(void)
goto err_pdev;
}
- imx_drm_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32),
-
ret = platform_driver_register(imx_drm_pdrv);
if (ret)
goto err_pdrv;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 6fd37a7..9e73e8d 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -523,7 +523,9 @@ static int ipu_drm_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
ipu_crtc = devm_kzalloc(pdev-dev, sizeof(*ipu_crtc), GFP_KERNEL);
if (!ipu_crtc)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/51] DMA-API: net: broadcom/b44: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/broadcom/b44.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/b44.c
b/drivers/net/ethernet/broadcom/b44.c
index 9b017d9..b4d2018 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -2183,8 +2183,7 @@ static int b44_init_one(struct ssb_device *sdev,
goto err_out_free_dev;
}
- if (dma_set_mask(sdev-dma_dev, DMA_BIT_MASK(30)) ||
- dma_set_coherent_mask(sdev-dma_dev, DMA_BIT_MASK(30))) {
+ if (dma_set_mask_and_coherent(sdev-dma_dev, DMA_BIT_MASK(30))) {
dev_err(sdev-dev,
Required 30BIT DMA mask unsupported by the system\n);
goto err_out_powerdown;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
Hi, On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: Use platform_device_register_full() for those drivers which can, to avoid messing directly with DMA masks. This can only be done when the driver does not need to access the allocated musb platform device from within its callbacks, which may be called during the musb device probing. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk you want me to carry this one through my tree or you prefer getting my Acked-by ? Either way works for me: Acked-by: Felipe Balbi ba...@ti.com there's also the third option of me setting up a branch with only this patch and we both merge it, that'd also work. cheers -- balbi signature.asc Description: Digital signature
[PATCH v2 0/3] OMAP3 ROM Random Number Generator support
This patch series adding support for OMAP3 ROM Random Number Generator on Nokia N900. In previous version I forgot to send patch which changing clk dev id to new driver name. Pali Rohár (3): omap2: Change clk dev id for rng to omap3-rom-rng hwrng: OMAP3 ROM Random Number Generator support RX-51: Add support for OMAP3 ROM Random Number Generator arch/arm/mach-omap2/board-rx51-peripherals.c | 19 arch/arm/mach-omap2/cclock3xxx_data.c|2 +- arch/arm/mach-omap2/omap-secure.c| 11 ++ arch/arm/mach-omap2/omap-secure.h|1 + drivers/char/hw_random/Kconfig | 13 +++ drivers/char/hw_random/Makefile |1 + drivers/char/hw_random/omap3-rom-rng.c | 141 ++ 7 files changed, 187 insertions(+), 1 deletion(-) create mode 100644 drivers/char/hw_random/omap3-rom-rng.c -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] omap2: Change clk dev id for rng to omap3-rom-rng
Name omap_rng is already used by omap_rng driver which is for omap2 and omap4.
For omap3 HS devices there is new driver omap3-rom-rng which needs that clk.
And because there cannot be two drivers with same name, rename omap3 clk dev id.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 334b767..5059338 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3274,7 +3274,7 @@ static struct omap_clk omap36xx_clks[] = {
*/
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
- CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] RX-51: Add support for OMAP3 ROM Random Number Generator
Adding this driver as platform device and only for RX-51 until somebody test if
it working also on other OMAP3 HS devices and until there will be generic ARM
way to deal with SMC calls.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 19 +++
arch/arm/mach-omap2/omap-secure.c| 11 +++
arch/arm/mach-omap2/omap-secure.h|1 +
3 files changed, 31 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index c3270c0..497d260 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -57,6 +57,8 @@
#include common-board-devices.h
#include gpmc.h
#include gpmc-onenand.h
+#include soc.h
+#include omap-secure.h
#define SYSTEM_REV_B_USES_VAUX30x1699
#define SYSTEM_REV_S_USES_VAUX3 0x8
@@ -1289,6 +1291,22 @@ static void __init rx51_init_twl4030_hwmon(void)
platform_device_register(madc_hwmon);
}
+static struct platform_device omap3_rom_rng_device = {
+ .name = omap3-rom-rng,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_secure_rng_call,
+ },
+};
+
+static void __init rx51_init_omap3_rom_rng(void)
+{
+ if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
+ pr_info(RX-51: Registring OMAP3 HWRNG device\n);
+ platform_device_register(omap3_rom_rng_device);
+ }
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1309,5 +1327,6 @@ void __init rx51_peripherals_init(void)
rx51_charger_init();
rx51_init_twl4030_hwmon();
+ rx51_init_omap3_rom_rng();
}
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
index 146a7c4..5ac122e 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -135,3 +135,14 @@ u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits)
FLAG_START_CRITICAL,
1, acr, 0, 0, 0);
}
+
+/**
+ * rx51_secure_rng_call: Routine for HW random generator
+ */
+u32 rx51_secure_rng_call(u32 ptr, u32 count, u32 flag)
+{
+ return rx51_secure_dispatcher(RX51_PPA_HWRNG,
+ 0,
+ NO_FLAG,
+ 3, ptr, count, flag, 0);
+}
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 51b59c6..f6cabb0 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -65,6 +65,7 @@ extern int omap_secure_ram_reserve_memblock(void);
extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits);
+extern u32 rx51_secure_rng_call(u32 ptr, u32 count, u32 flag);
#ifdef CONFIG_OMAP4_ERRATA_I688
extern int omap_barrier_reserve_memblock(void);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] hwrng: OMAP3 ROM Random Number Generator support
This driver provides kernel-side support for the Random Number
Generator hardware found on OMAP34xx processors.
This driver comes from Maemo 2.6.28 kernel and was tested on Nokia RX-51.
It is platform device because it needs board specific function for smc calls.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
---
drivers/char/hw_random/Kconfig | 13 +++
drivers/char/hw_random/Makefile|1 +
drivers/char/hw_random/omap3-rom-rng.c | 141
3 files changed, 155 insertions(+)
create mode 100644 drivers/char/hw_random/omap3-rom-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 0aa9d91..0a331c3 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -165,6 +165,19 @@ config HW_RANDOM_OMAP
If unsure, say Y.
+config HW_RANDOM_OMAP3_ROM
+ tristate OMAP3 ROM Random Number Generator support
+ depends on HW_RANDOM ARCH_OMAP3
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on OMAP34xx processors.
+
+ To compile this driver as a module, choose M here: the
+ module will be called omap3-rom-rng.
+
+ If unsure, say Y.
+
config HW_RANDOM_OCTEON
tristate Octeon Random Number Generator support
depends on HW_RANDOM CAVIUM_OCTEON_SOC
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index bed467c..7c8aa80 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -15,6 +15,7 @@ n2-rng-y := n2-drv.o n2-asm.o
obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
+obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
diff --git a/drivers/char/hw_random/omap3-rom-rng.c
b/drivers/char/hw_random/omap3-rom-rng.c
new file mode 100644
index 000..c853e9e
--- /dev/null
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -0,0 +1,141 @@
+/*
+ * omap3-rom-rng.c - RNG driver for TI OMAP3 CPU family
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Juha Yrjola juha.yrj...@solidboot.com
+ *
+ * Copyright (C) 2013 Pali Rohár pali.ro...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
+#include linux/module.h
+#include linux/init.h
+#include linux/random.h
+#include linux/hw_random.h
+#include linux/timer.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/platform_device.h
+
+#define RNG_RESET 0x01
+#define RNG_GEN_PRNG_HW_INIT 0x02
+#define RNG_GEN_HW 0x08
+
+/* param1: ptr, param2: count, param3: flag */
+static u32 (*omap3_rom_rng_call)(u32, u32, u32);
+
+static struct timer_list idle_timer;
+static int rng_idle;
+static struct clk *rng_clk;
+
+static void omap3_rom_rng_idle(unsigned long data)
+{
+ int r;
+
+ r = omap3_rom_rng_call(0, 0, RNG_RESET);
+ if (r != 0) {
+ pr_err(reset failed: %d\n, r);
+ return;
+ }
+ clk_disable_unprepare(rng_clk);
+ rng_idle = 1;
+}
+
+static int omap3_rom_rng_get_random(void *buf, unsigned int count)
+{
+ u32 r;
+ u32 ptr;
+
+ del_timer_sync(idle_timer);
+ if (rng_idle) {
+ clk_prepare_enable(rng_clk);
+ r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
+ if (r != 0) {
+ clk_disable_unprepare(rng_clk);
+ pr_err(HW init failed: %d\n, r);
+ return -EIO;
+ }
+ rng_idle = 0;
+ }
+
+ ptr = virt_to_phys(buf);
+ r = omap3_rom_rng_call(ptr, count, RNG_GEN_HW);
+ mod_timer(idle_timer, jiffies + msecs_to_jiffies(500));
+ if (r != 0)
+ return -EINVAL;
+ return 0;
+}
+
+static int omap3_rom_rng_data_present(struct hwrng *rng, int wait)
+{
+ return 1;
+}
+
+static int omap3_rom_rng_data_read(struct hwrng *rng, u32 *data)
+{
+ int r;
+
+ r = omap3_rom_rng_get_random(data, 4);
+ if (r 0)
+ return r;
+ return 4;
+}
+
+static struct hwrng omap3_rom_rng_ops = {
+ .name = omap3-rom,
+ .data_present = omap3_rom_rng_data_present,
+ .data_read = omap3_rom_rng_data_read,
+};
+
+static int omap3_rom_rng_probe(struct platform_device *pdev)
+{
+ pr_info(initializing\n);
+
+ omap3_rom_rng_call = pdev-dev.platform_data;
+ if (!omap3_rom_rng_call) {
+
Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote: Hi, On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: Use platform_device_register_full() for those drivers which can, to avoid messing directly with DMA masks. This can only be done when the driver does not need to access the allocated musb platform device from within its callbacks, which may be called during the musb device probing. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk you want me to carry this one through my tree or you prefer getting my Acked-by ? Either way works for me: Acked-by: Felipe Balbi ba...@ti.com there's also the third option of me setting up a branch with only this patch and we both merge it, that'd also work. I think this patch is sufficiently stand-alone that it should be fine if you want to take it through your tree. That may be better in the long run to avoid conflicts with this patch and any future work in this area during this cycle. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should access this member directly. Convert all direct write accesses to using the correct API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tejun Heo t...@kernel.org The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? The plan is... I'm going to try and avoid going through the hell of re-posting this patch series to all the recipients another time... (It's taken some 17 hours and lots of hand holding to get this patch set out without exim jumping off a cliff into deep OOM - soo deep that even the OOM killer doesn't run and the CPU is 100% idle because every single process stuck in an uninterruptible sleep waiting for every other process to free some memory - ouch!) I know that dealing with this patch set will be a problem due to how widespread this is, but much of the driver level changes come down to depending on a couple of patches. One solution would be if I published a branch with just the dependencies in, which subsystem maintainers could pull, and then apply the appropriate patches on top. Another would be if subsystem maintainers are happy that I carry them, I can add the acks, and then later on towards the end of the cycle, provide a branch subsystem maintainers could pull. Or... if you can think of something easier... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote: On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: [...] -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. Yes, the original sentence is not particularly good, but I think even your modified version can be interpreted as a mask setting itself for all the same reasons that the original can be (which mask does same refer to?) Even so, I prefer your version. Thanks. :) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index fce46c5..e51a983 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
if (ret)
return ret;
+ /* Ensure that we can do DMA */
+ ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out_no_pl08x;
+
/* Create the driver state holder */
pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
if (!pl08x) {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/powerpc/kernel/vio.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index 78a3506..96b6c97 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask(viodev-dev, DMA_BIT_MASK(64)); - dma_set_coherent_mask(viodev-dev, DMA_BIT_MASK(64)); + dma_set_mask_and_coherent(viodev-dev, DMA_BIT_MASK(64)); } /* register with generic device framework */ -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 40/51] DMA-API: crypto: fix ixp4xx crypto platform device support
Don't statically allocate struct device's in modules, and shut the
warning up with an empty release() function. There's a reason that
warning is there and that's not for people to hide in this way. It's
there to persuade people to use the correct APIs to allocate platform
devices.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/crypto/ixp4xx_crypto.c | 37 +
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 21180d6..8306185 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -218,23 +218,10 @@ static dma_addr_t crypt_phys;
static int support_aes = 1;
-static void dev_release(struct device *dev)
-{
- return;
-}
-
#define DRIVER_NAME ixp4xx_crypto
-static struct platform_device pseudo_dev = {
- .name = DRIVER_NAME,
- .id = 0,
- .num_resources = 0,
- .dev = {
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .release = dev_release,
- }
-};
-static struct device *dev = pseudo_dev.dev;
+static struct platform_device *pdev;
+static struct device *dev;
static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
{
@@ -1418,20 +1405,30 @@ static struct ixp_alg ixp4xx_algos[] = {
} };
#define IXP_POSTFIX -ixp4xx
+
+static const struct platform_device_info ixp_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static int __init ixp_module_init(void)
{
int num = ARRAY_SIZE(ixp4xx_algos);
- int i,err ;
+ int i, err ;
- if (platform_device_register(pseudo_dev))
- return -ENODEV;
+ pdev = platform_device_register_full(ixp_dev_info);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ dev = pdev-dev;
spin_lock_init(desc_lock);
spin_lock_init(emerg_lock);
err = init_ixp_crypto();
if (err) {
- platform_device_unregister(pseudo_dev);
+ platform_device_unregister(pdev);
return err;
}
for (i=0; i num; i++) {
@@ -1496,7 +1493,7 @@ static void __exit ixp_module_exit(void)
crypto_unregister_alg(ixp4xx_algos[i].crypto);
}
release_ixp_crypto();
- platform_device_unregister(pseudo_dev);
+ platform_device_unregister(pdev);
}
module_init(ixp_module_init);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks
Hi, On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote: On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote: Hi, On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: Use platform_device_register_full() for those drivers which can, to avoid messing directly with DMA masks. This can only be done when the driver does not need to access the allocated musb platform device from within its callbacks, which may be called during the musb device probing. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk you want me to carry this one through my tree or you prefer getting my Acked-by ? Either way works for me: Acked-by: Felipe Balbi ba...@ti.com there's also the third option of me setting up a branch with only this patch and we both merge it, that'd also work. I think this patch is sufficiently stand-alone that it should be fine if you want to take it through your tree. That may be better in the long run to avoid conflicts with this patch and any future work in this area during this cycle. awesome, i'll take this one early next week. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] usb: musb: dsps fix the typo in reg-names of the dma node
Hi, adding Benoit Cousson and linux-omap On Wed, Aug 14, 2013 at 07:29:59PM +0200, Sebastian Andrzej Siewior wrote: I forgot to separete the different names in the reg-names property. This didn't cause anything to fail because the driver does not use the names and simply relies on the order of the memory offsets in reg. This patch fixes this in case it is used later. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de Benoit, hope you can take this patch in the -rc cycle. Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/boot/dts/am33xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 24d6309..a38f8d3 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -470,7 +470,7 @@ 0x47402000 0x1000 0x47403000 0x1000 0x47404000 0x4000; - reg-names = glue controller scheduler queuemgr; + reg-names = glue, controller, scheduler, queuemgr; interrupts = 17; interrupt-names = glue; #dma-cells = 2; -- 1.8.4.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/4] usb: musb: am335x: add second port to beagle bone
On Thu, Aug 15, 2013 at 05:21:50PM +0200, Sebastian Andrzej Siewior wrote:
So I assumed that Beagle bone has only one USB port in host mode because
the micro USB connector had an USB-UART there. I was wrong a little. The
second port runs on host mode, but the micro USB plug is connected to an
internal HUB with two ports: one to the USB-UART and one to musb
instance one.
For that reason, this patch enables both ports: the primary in device
mode only and the second in host mode only.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index e8447a7..596d653 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -131,9 +131,24 @@
status = okay;
};
+ usb-phy@47401b00 {
+ status = okay;
+ };
+
usb@47401000 {
status = okay;
};
+
+ usb@47401800 {
+ status = okay;
+ usb@47401c00 {
+ mg,port-mode = 1;
+ };
+ };
+
+ dma-controller@07402000 {
+ status = okay;
+ };
};
i2c0: i2c@44e0b000 {
--
1.8.4.rc2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/4] usb: musb: am335x: Do not remove the session bit HOST-only mode
On Thu, Aug 15, 2013 at 05:21:51PM +0200, Sebastian Andrzej Siewior wrote:
This is what I observe:
On the first connect, the musb starts with DEVCTL.Session set. On
disconnect, musb_core calls try_idle. That functions removes the Session
bit signalizing that the session is over (something that only in OTG is
required). A new device, that is plugged, is no longer recognized.
I've setup a timer and checked the DEVCTL register and I haven't seen a
change in VBus and I saw the B-Device bit set. After setting the IDDIG
into A mode and forcing the device to behave like a A device, I didn't
see a change.
Neither VBUS goes to 0b11 nor does a session start request comes.
In the TI-v3.2 kernel they skip to call musb_platform_try_idle() in the
OTG_STATE_A_WAIT_BCON state while not in OTG mode.
Since the second port hast a standard A plug the patch changes the port
to run in host mode only and skips the timer which would remove
DEVCTL.Session so we can reconnect to another device later.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 3 +++
drivers/usb/musb/musb_dsps.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 648a67e..794b38b9 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -192,6 +192,9 @@
usb@47401800 {
status = okay;
+ musb1: usb@47401c00 {
+ port-mode = 1;
+ };
};
dma-controller@07402000 {
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 7368577..b7b2346 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -230,6 +230,8 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
glue-last_timer = jiffies;
return;
}
+ if (musb-port_mode == MUSB_PORT_MODE_HOST)
+ return;
if (time_after(glue-last_timer, timeout)
timer_pending(glue-timer)) {
--
1.8.4.rc2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/9] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
Hi, On Thu, Aug 15, 2013 at 01:18:23PM +0300, Roger Quadros wrote: The platform data bits can be inferred from the other members of struct usbhs_phy_data. So get rid of the platform_data member. Build the platform data for the PHY device in usbhs_init_phys() instead. Signed-off-by: Roger Quadros rog...@ti.com Tony, do I get your Acked-by here and all following arch/arm/mach-omap2* patches in this series ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] usb: usb: dsps: update code according to the binding document
+ linux-omap, Benoit
On Thu, Aug 15, 2013 at 05:21:49PM +0200, Sebastian Andrzej Siewior wrote:
This relfects the code and dts requires changes due to recent .dts
binding updates:
- use mg prefix for the Metor Graphics specific attributes
- use power in mA not in mA/2 as specifed in the USB2.0 specification
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
hope this can go in during the -rc cycle
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 2 +-
arch/arm/boot/dts/am335x-evm.dts | 6 +++---
arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
arch/arm/boot/dts/am33xx.dtsi | 26 +-
drivers/usb/musb/musb_dsps.c | 11 ++-
5 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index a8907b5..e8447a7 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -127,7 +127,7 @@
status = okay;
};
- phy@47401300 {
+ usb-phy@47401300 {
status = okay;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index c26c16c..648a67e 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -178,11 +178,11 @@
status = okay;
};
- phy@47401300 {
+ usb-phy@47401300 {
status = okay;
};
- phy@47401b00 {
+ usb-phy@47401b00 {
status = okay;
};
@@ -194,7 +194,7 @@
status = okay;
};
- dma@07402000 {
+ dma-controller@07402000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index e92446c..a6c5033 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -214,7 +214,7 @@
status = okay;
};
- phy@47401300 {
+ usb-phy@47401300 {
status = okay;
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a38f8d3..c57c6b8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -354,7 +354,7 @@
status = disabled;
};
- usb0_phy: phy@47401300 {
+ usb0_phy: usb-phy@47401300 {
compatible = ti,am335x-usb-phy;
reg = 0x47401300 0x100;
reg-names = phy;
@@ -377,11 +377,11 @@
reg-names = mc;
interrupts = 18;
interrupt-names = mc;
- multipoint = 1;
- num-eps = 16;
- ram-bits = 12;
- port-mode = 3;
- power = 250;
+ mg,multipoint = 1;
+ mg,num-eps = 16;
+ mg,ram-bits = 12;
+ mg,port-mode = 3;
+ mg,power = 500;
phys = usb0_phy;
dmas = cppi41dma 0 0 cppi41dma 1 0
@@ -409,7 +409,7 @@
};
};
- usb1_phy: phy@47401b00 {
+ usb1_phy: usb-phy@47401b00 {
compatible = ti,am335x-usb-phy;
reg = 0x47401b00 0x100;
reg-names = phy;
@@ -432,11 +432,11 @@
reg-names = mc;
interrupts = 19;
interrupt-names = mc;
- multipoint = 1;
- num-eps = 16;
- ram-bits = 12;
- port-mode = 3;
- power = 250;
+ mg,multipoint = 1;
+ mg,num-eps = 16;
+ mg,ram-bits = 12;
+
Re: [RFC PATCH] ARM: OMAP3630: Add generic machine descriptor
Hi, On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote: An alternative approach may be to (for all SoCs): 1. define every SoC entry - ti,omap3430 ti,omap3630... 2. have a generic omap3_init which uses if (of_machine_is_compatible(ti,omap3630)) to invoke the appropriate omap3xxx_init_early. Yes, this would be better, but you can do add a DT_MACHINE as in this patch but have ti,omap3630 as the dt_compat table. Then there's no need to add runtime checks. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] omap2: Change clk dev id for rng to omap3-rom-rng
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which is for omap2 and omap4.
For omap3 HS devices there is new driver omap3-rom-rng which needs that clk.
And because there cannot be two drivers with same name, rename omap3 clk dev
id.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 334b767..5059338 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3274,7 +3274,7 @@ static struct omap_clk omap36xx_clks[] = {
*/
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
- CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
Hmm are you sure the omap_rng is not available on
any of the omap3 GP versions? If so, the omap_rng
alias should be kept as well.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/9] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
* Felipe Balbi ba...@ti.com [130920 08:52]: Hi, On Thu, Aug 15, 2013 at 01:18:23PM +0300, Roger Quadros wrote: The platform data bits can be inferred from the other members of struct usbhs_phy_data. So get rid of the platform_data member. Build the platform data for the PHY device in usbhs_init_phys() instead. Signed-off-by: Roger Quadros rog...@ti.com Tony, do I get your Acked-by here and all following arch/arm/mach-omap2* patches in this series ? If you can merge just this series without the .dts changes into an immutable topic branch against let's say v3.12-rc2 when it comes out, then yes I can ack them: Acked-by: Tony Lindgren t...@atomide.com That way I can also pull in the topic branch as needed to avoid self inflicted merge conflicts ;) And Benoit can set up a separate .dts branch based on your branch to make sure the dependencies are in place before merging that one upstream. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-boneblack: move fixed regulator to board level
On Thu, Sep 19, 2013 at 12:12:44PM -0500, Nishanth Menon wrote: 3.3V fixed regulator does not belong to TPS node - as a result the fixed regulator is never probed and MMC is continually deferred due to lack of regulator. Move the fixed regulator to be at root of platform. Signed-off-by: Nishanth Menon n...@ti.com Tested-by: Felipe Balbi ba...@ti.com I boot tested this on my BBB. -- balbi signature.asc Description: Digital signature
[RFC PATCH] ARM: OMAP3630: Add generic machine descriptor
Add generic machine which can handle inits for omap3630.
Currently beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early
This defeats the purpose of having SoC specific init_early handlers,
example: clock nodes are not the same between 3430 and 3630.
Signed-off-by: Nishanth Menon n...@ti.com
---
An alternative approach may be to (for all SoCs):
1. define every SoC entry - ti,omap3430 ti,omap3630...
2. have a generic omap3_init which uses if
(of_machine_is_compatible(ti,omap3630))
to invoke the appropriate omap3xxx_init_early.
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..cd85b36 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -147,6 +147,24 @@ DT_MACHINE_START(OMAP3_GP_DT, Generic OMAP3-GP (Flattened
Device Tree))
.dt_compat = omap3_gp_boards_compat,
.restart= omap3xxx_restart,
MACHINE_END
+
+static const char *omap3630_gp_boards_compat[] __initdata = {
+ ti,omap3-beagle-xm,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP3630_GP_DT, Generic OMAP3630-GP (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_secure_sync32k_timer_init,
+ .dt_compat = omap3630_gp_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
#endif
#ifdef CONFIG_SOC_AM33XX
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/9] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
On Fri, Sep 20, 2013 at 09:18:22AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [130920 08:52]: Hi, On Thu, Aug 15, 2013 at 01:18:23PM +0300, Roger Quadros wrote: The platform data bits can be inferred from the other members of struct usbhs_phy_data. So get rid of the platform_data member. Build the platform data for the PHY device in usbhs_init_phys() instead. Signed-off-by: Roger Quadros rog...@ti.com Tony, do I get your Acked-by here and all following arch/arm/mach-omap2* patches in this series ? If you can merge just this series without the .dts changes into an immutable topic branch against let's say v3.12-rc2 when it comes out, then yes I can ack them: Acked-by: Tony Lindgren t...@atomide.com That way I can also pull in the topic branch as needed to avoid self inflicted merge conflicts ;) And Benoit can set up a separate .dts branch based on your branch to make sure the dependencies are in place before merging that one upstream. Alright, i'll put this in my todo for next week. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] ARM: OMAP3630: Add generic machine descriptor
Hi, On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote: On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote: An alternative approach may be to (for all SoCs): 1. define every SoC entry - ti,omap3430 ti,omap3630... 2. have a generic omap3_init which uses if (of_machine_is_compatible(ti,omap3630)) to invoke the appropriate omap3xxx_init_early. Yes, this would be better, but you can do add a DT_MACHINE as in this patch but have ti,omap3630 as the dt_compat table. Then there's no need to add runtime checks. I was going to reply that adding of_machine_is_compatible(ti,omap3630) would help in some situations, but guess it's already tainted ;-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] ADP1653 board code for Nokia RX-51
* Pali Rohár pali.ro...@gmail.com [130919 15:38]: On Wednesday 18 September 2013 19:42:12 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [130918 09:08]: On Wednesday 18 September 2013 15:16:44 Pavel Machek wrote: On Sun 2013-09-08 02:02:52, Aaro Koskinen wrote: Hi, On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote: --- /dev/null +++ b/arch/arm/mach-omap2/board-rx51-camera.c [...] Ping, can you review this patch v2? I don't think Tony will accept any new board stuff for RX-51/N900. See for example: http://marc.info/?l=linux-kernelm=137629626213187w=2 There should be initial Nokia N900 DTS file in 3.12-rc1, and we should continue converting this board fully to DT. That's not reasonable. N900 is pretty far away from working with device tree. Yes, I was able to get some bits merged, but that should not be excuse to halt other N900 development. Pavel Right. So Tony, will you accept future patches for board files? Only fixes to board-*.c files please unless there's a _really_ good reason to make things more complex with the platform data. Let's not make the DT conversion any more complex than it already is. Getting things working with DT for the devices is pretty trivial in most cases. And we can also still initialize the legacy devices using platform data the same way as earlier. Regards, Tony So, what to this with this patch v2 (it was sent 06.03.2013)? It adding board support for ADP1653 flash torch which is part of rx51 camera code. Driver itself is already in kernel tree. Can you comment/review this patch? Yeah I'm not taking any more of new platform data like this, this all is already very trivial to do with device tree directly in the driver. Adding this would make the pains of moving to device tree based booting just more of a pain and guess who has to deal with all of that. For the hwrng platform data makes still sense even for the device tree as we don't have any better way currently to do the SMC callbacks. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] omap2: Change clk dev id for rng to omap3-rom-rng
On Friday 20 September 2013 18:23:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which is
for omap2 and omap4. For omap3 HS devices there is new
driver omap3-rom-rng which needs that clk. And because
there cannot be two drivers with same name, rename omap3
clk dev id.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c index
334b767..5059338 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3274,7 +3274,7 @@ static struct omap_clk omap36xx_clks[]
= {
*/
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
- CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
Hmm are you sure the omap_rng is not available on
any of the omap3 GP versions? If so, the omap_rng
alias should be kept as well.
Regards,
Tony
I really do not know, but driver char/hw_random/omap-rng.c
support only omap2 and omap4 platforms. So omap_rng dev id for
omap3 is not used.
In email [1] you suggested to use clk_get instead clk_get_sys. If
I understand correctly clk_get calling clk_get_sys with driver
name. So dev in in CLK macro must be same as driver name. And
because in cclock3xxx_data.c is dev id omap_rng and there is
already driver with name omap_rng, I need to rename dev in
cclock3xxx_data.c to get new omap3-rom-rng driver working.
Or if you know better way how to do it, let me know.
[1] - https://lkml.org/lkml/2013/4/1/278
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*
On 20 September 2013 18:08, Nishanth Menon n...@ti.com wrote: I am open to suggestions if any one feels we can improve this better. I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp** though.. I believe that change was from Patch #2[1] Yeah.. I just replied on a single patch :) yes, you are right, I had squashed this patch in to squelch checkpatch warnings: I see.. I had added a comment: Minor checkpatch warning fixes as a result of this change was fixed as well. I really missed that.. Would you suggest I split the change off to a separate patch or improve the comment a little more? don't really know, maybe leave those as is and let checkpatch warn you.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP35x MMC Host Controller compatibility with SDXC?
Hi Balaji,
My test shows that I'm having some timeout in some cases (v3.4.60):
omap_hsmmc omap_hsmmc.0: IRQ Status is 18000
omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO
mmc0: req done (CMD52): -110:
mmc0: starting CMD52 arg 8c08 flags 0195
omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x
omap_hsmmc omap_hsmmc.0: IRQ Status is 18000
omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO
mmc0: req failed (CMD5): -110, retrying...
mmc1: starting CMD8 arg 01aa flags 02f5
omap_hsmmc omap_hsmmc.1: mmc1: CMD8, argument 0x01aa
mmc0: starting CMD18 arg 0002 flags 00b5
omap_hsmmc omap_hsmmc.1: IRQ Status is 18000
omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req done (CMD8): -110:
So CMD 52,5 and 8 gives me timeout...
For SD cards, these cmd's are expected to timeout during card
initialization.
When you say that they are expected to timeout for SD are you
including for microSD also? So for what will it not timeout normally
(CMD 52,5 and 8)?
Looking at the 3.11.1 there is 2 more validation for UHS that are not in
3.4.60:
omap_hsmmc_set_clock // Enable High-Speed Support
omap_set_bus_width
Those changes are not for SD3.0 speed modes
thx for the confirmation.
Is it safe to use SDXC with OMAP35x or not? Should this pop a error
message?
SDXC cards should work albeit at High Speed mode (as in SD2.0).
Refer to [1] for card size Vs speed mode/SD spec version.
Your link clearly says that there should be no problem running SDXC
with Spec 2.0:
High Speed SD, SDHC and SDXC --- 25MB/s 2.00
Can you check if the filesystem type on SDXC card
is supported by the system software running on OMAP35x.
By that you mean?
I'm using similar script as this one to partition my system:
http://git.sakoman.com/git/gitweb.cgi?p=meta-sakoman.git;a=blob;f=scripts/mksdcard.sh;h=a817935dba988f6f0f0c3dd534374797a661034e;hb=HEAD
Creating 2 partition boot (FAT32) and rootfs (EXT3):
mkfs.vfat -F 32 -n boot ${PART1}
mke2fs -j -L rootfs ${PART2}
Just to help you understand a bit more the reason of my question. I'm
having a MMC error only with (micro)SDXC 64GB ((micro)SDHC 32GB no
problem so far) and our system is not booting the rootfs.
card mmcblk0: error -110 sending status command, retrying
... (stuck there infinitely if tune2fs -e continue)
see my post:
http://marc.info/?l=linux-omapm=137764004920777w=3
Best Regards,
-KA
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13
Hi all, Here are few patches to make it easier for us to maintain legacy platform data support while moving to device tree based booting. It seems that we still have quite a few places where we still need platform data for omap3 to keep things from breaking. As the remaining drivers get converted to use device tree, we can then just remove the support from the pdata-quirks.c. Regards, Tony --- Tony Lindgren (4): ARM: OMAP2+: Always build in board-generic ARM: OMAP2+: Add quirk support for legacy platform data init ARM: OMAP2+: Use pdata quirk support for board-generic.c ARM: OMAP2+: Use pdata quirks for wl12xx legacy init arch/arm/mach-omap2/Kconfig | 10 +-- arch/arm/mach-omap2/Makefile|2 - arch/arm/mach-omap2/board-generic.c | 33 -- arch/arm/mach-omap2/common.h|2 + arch/arm/mach-omap2/devices.c | 38 arch/arm/mach-omap2/pdata-quirks.c | 111 +++ 6 files changed, 118 insertions(+), 78 deletions(-) create mode 100644 arch/arm/mach-omap2/pdata-quirks.c -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: Add quirk support for legacy platform data init
We want to drop the board-*.c files but keep things working.
Let's make it a bit easier to support legacy platform data
init with quirks. This also keeps board-generic.c clean from
board specific hacks.
For now, the quirks table is empty, that is populated
in the later patches.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|2 ++
arch/arm/mach-omap2/pdata-quirks.c | 39 +++
4 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-omap2/pdata-quirks.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index afb457c..f8d4a1b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -233,7 +233,7 @@ obj-y += drm.o
endif
# Specific board support
-obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
+obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
pdata-quirks.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..022b0df 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -56,6 +56,7 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ pdata_quirks_init();
/*
* HACK: call display setup code for selected boards to enable omapdss.
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 4a5684b..fd059e0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -288,6 +288,8 @@ static inline void omap4_cpu_resume(void)
#endif
+void pdata_quirks_init(void);
+
struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
new file mode 100644
index 000..e605199
--- /dev/null
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -0,0 +1,39 @@
+/*
+ * Legacy platform_data quirks
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/clk.h
+#include linux/init.h
+#include linux/kernel.h
+
+#include common.h
+#include common-board-devices.h
+#include dss-common.h
+
+struct pdata_init {
+ const char *compatible;
+ void (*fn)(void);
+};
+
+static struct pdata_init pdata_quirks[] __initdata = {
+ { /* sentinel */ },
+};
+
+void __init pdata_quirks_init(void)
+{
+ struct pdata_init *quirks = pdata_quirks;
+
+ while (quirks-compatible) {
+ if (of_machine_is_compatible(quirks-compatible)) {
+ if (quirks-fn)
+ quirks-fn();
+ break;
+ }
+ quirks++;
+ }
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: dts: am335x-bone-common: correct mux mode for mmc1_cmd
correct mux mode for mmc1_cmd to detect eMMC on bone-black
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 56361ce..90ab56c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -117,7 +117,7 @@
emmc_pins: pinmux_emmc_pins {
pinctrl-single,pins =
0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk */
- 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn2.mmc1_cmd */
0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0 */
0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1 */
0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2 */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+: Use pdata quirk support for board-generic.c
Let's use platform data quirk support for board-generic.c.
This removes all board specific hacks out of board-generic.c.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 32 ---
arch/arm/mach-omap2/pdata-quirks.c | 41 +++
2 files changed, 41 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 022b0df..a66575f 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,13 +15,10 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
-#include linux/clk.h
#include asm/mach/arch.h
#include common.h
-#include common-board-devices.h
-#include dss-common.h
#if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
#define intc_of_init NULL
@@ -36,41 +33,12 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias(main_clk, NULL, clkname, NULL);
- if (ret) {
- pr_err(%s:Failed to add main_clk alias to %s :%d\n,
- __func__, clkname, ret);
- }
-}
-
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
pdata_quirks_init();
-
- /*
-* HACK: call display setup code for selected boards to enable omapdss.
-* This will be removed when omapdss supports DT.
-*/
- if (of_machine_is_compatible(ti,omap4-panda)) {
- omap4_panda_display_init_of();
- legacy_init_ehci_clk(auxclk3_ck);
-
- }
- else if (of_machine_is_compatible(ti,omap4-sdp))
- omap_4430sdp_display_init_of();
- else if (of_machine_is_compatible(ti,omap5-uevm))
- legacy_init_ehci_clk(auxclk1_ck);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index e605199..648d957 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -20,7 +20,48 @@ struct pdata_init {
void (*fn)(void);
};
+/*
+ * Create alias for USB host PHY clock.
+ * Remove this when clock phandle can be provided via DT
+ */
+static void __init __used legacy_init_ehci_clk(char *clkname)
+{
+ int ret;
+
+ ret = clk_add_alias(main_clk, NULL, clkname, NULL);
+ if (ret)
+ pr_err(%s:Failed to add main_clk alias to %s :%d\n,
+ __func__, clkname, ret);
+}
+
+#ifdef CONFIG_ARCH_OMAP4
+static void __init omap4_sdp_legacy_init(void)
+{
+ omap_4430sdp_display_init_of();
+}
+
+static void __init omap4_panda_legacy_init(void)
+{
+ omap4_panda_display_init_of();
+ legacy_init_ehci_clk(auxclk3_ck);
+}
+#endif
+
+#ifdef CONFIG_SOC_OMAP5
+static void __init omap5_uevm_legacy_init(void)
+{
+ legacy_init_ehci_clk(auxclk1_ck);
+}
+#endif
+
static struct pdata_init pdata_quirks[] __initdata = {
+#ifdef CONFIG_ARCH_OMAP4
+ { ti,omap4-sdp, omap4_sdp_legacy_init, },
+ { ti,omap4-panda, omap4_panda_legacy_init, },
+#endif
+#ifdef CONFIG_SOC_OMAP5
+ { ti,omap5-uevm, omap5_uevm_legacy_init, },
+#endif
{ /* sentinel */ },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: OMAP3630: Add generic machine descriptor
On Fri, Sep 20, 2013 at 9:23 AM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote: On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote: An alternative approach may be to (for all SoCs): 1. define every SoC entry - ti,omap3430 ti,omap3630... 2. have a generic omap3_init which uses if (of_machine_is_compatible(ti,omap3630)) to invoke the appropriate omap3xxx_init_early. Yes, this would be better, but you can do add a DT_MACHINE as in this patch but have ti,omap3630 as the dt_compat table. Then there's no need to add runtime checks. I was going to reply that adding of_machine_is_compatible(ti,omap3630) would help in some situations, but guess it's already tainted ;-) Oh, if it's just a few checks, then by all means go down that route. I didn't look at the code to see how much it would be. But if a new DT_MACHINE is added, then it should definitely be based on ti,omap3630 instead of listing all the boards. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: OMAP2+: Use pdata quirks for wl12xx legacy init
Let's use the platform data quirk support for wl12xx
and move the board specific code out of devices.c.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 38
arch/arm/mach-omap2/pdata-quirks.c | 31 +
2 files changed, 31 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5c5315b..5336c75 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,7 +19,6 @@
#include linux/of.h
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
-#include linux/wl12xx.h
#include linux/platform_data/mailbox-omap.h
#include asm/mach-types.h
@@ -475,40 +474,6 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
-#if IS_ENABLED(CONFIG_WL12XX)
-
-static struct wl12xx_platform_data wl12xx __initdata;
-
-void __init omap_init_wl12xx_of(void)
-{
- int ret;
-
- if (!of_have_populated_dt())
- return;
-
- if (of_machine_is_compatible(ti,omap4-sdp)) {
- wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
- wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
- wl12xx.irq = gpio_to_irq(53);
- } else if (of_machine_is_compatible(ti,omap4-panda)) {
- wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
- wl12xx.irq = gpio_to_irq(53);
- } else {
- return;
- }
-
- ret = wl12xx_set_platform_data(wl12xx);
- if (ret) {
- pr_err(error setting wl12xx data: %d\n, ret);
- return;
- }
-}
-#else
-static inline void omap_init_wl12xx_of(void)
-{
-}
-#endif
-
/*-*/
static int __init omap2_init_devices(void)
@@ -531,9 +496,6 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_rng();
- } else {
- /* These can be removed when bindings are done */
- omap_init_wl12xx_of();
}
omap_init_sti();
omap_init_vout();
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 648d957..52b4bc3 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -8,8 +8,10 @@
* published by the Free Software Foundation.
*/
#include linux/clk.h
+#include linux/gpio.h
#include linux/init.h
#include linux/kernel.h
+#include linux/wl12xx.h
#include common.h
#include common-board-devices.h
@@ -34,16 +36,45 @@ static void __init __used legacy_init_ehci_clk(char
*clkname)
__func__, clkname, ret);
}
+#if IS_ENABLED(CONFIG_WL12XX)
+
+static struct wl12xx_platform_data wl12xx __initdata;
+
+static void __init __used legacy_init_wl12xx(unsigned ref_clock,
+unsigned tcxo_clock,
+int gpio)
+{
+ int res;
+
+ wl12xx.board_ref_clock = ref_clock;
+ wl12xx.board_tcxo_clock = tcxo_clock;
+ wl12xx.irq = gpio_to_irq(gpio);
+
+ res = wl12xx_set_platform_data(wl12xx);
+ if (res) {
+ pr_err(error setting wl12xx data: %d\n, res);
+ return;
+ }
+}
+#else
+static inline void omap_init_wl12xx_of(void)
+{
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
omap_4430sdp_display_init_of();
+ legacy_init_wl12xx(WL12XX_REFCLOCK_26,
+ WL12XX_TCXOCLOCK_26, 53);
}
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
legacy_init_ehci_clk(auxclk3_ck);
+ legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
^--- copy and paste error - should of course be PL330
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/pl330.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..df8b10f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2903,6 +2903,10 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pdat = dev_get_platdata(adev-dev);
+ ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
/* Allocate a new DMAC and its Channels */
pdmac = devm_kzalloc(adev-dev, sizeof(*pdmac), GFP_KERNEL);
if (!pdmac) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP2+: Always build in board-generic
We are moving to device tree based booting, so board-generic should always be built. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b5fb5f7..f6a1db1 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -94,6 +94,7 @@ config ARCH_OMAP2PLUS select GENERIC_CLOCKEVENTS select GENERIC_IRQ_CHIP select HAVE_CLK + select MACH_OMAP_GENERIC select OMAP_DM_TIMER select PINCTRL select PROC_DEVICETREE if PROC_FS @@ -187,16 +188,11 @@ config OMAP_PACKAGE_CUS config OMAP_PACKAGE_CBP bool -comment OMAP Board Type +comment OMAP Legacy Platform Data Board Type depends on ARCH_OMAP2PLUS config MACH_OMAP_GENERIC - bool Generic OMAP2+ board - depends on ARCH_OMAP2PLUS - default y - help - Support for generic TI OMAP2+ boards using Flattened Device Tree. - More information at Documentation/devicetree + bool config MACH_OMAP2_TUSB6010 bool -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: OMAP3630: Add generic machine descriptor
Hi, On Fri, Sep 20, 2013 at 10:16:48AM -0700, Olof Johansson wrote: On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote: On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote: An alternative approach may be to (for all SoCs): 1. define every SoC entry - ti,omap3430 ti,omap3630... 2. have a generic omap3_init which uses if (of_machine_is_compatible(ti,omap3630)) to invoke the appropriate omap3xxx_init_early. Yes, this would be better, but you can do add a DT_MACHINE as in this patch but have ti,omap3630 as the dt_compat table. Then there's no need to add runtime checks. I was going to reply that adding of_machine_is_compatible(ti,omap3630) would help in some situations, but guess it's already tainted ;-) Oh, if it's just a few checks, then by all means go down that route. I didn't look at the code to see how much it would be. But if a new DT_MACHINE is added, then it should definitely be based on ti,omap3630 instead of listing all the boards. the idea was to CPU compatible property to conditionally enable known erratas workarounds. In some cases, Revision register can't be trusted, so instead of creating per-errata DT properties (since that'd be describing the SW, in a way), I thought of using of_machine_is_compatible() checks, but that assumes CPU compatible is correct. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] ARM: dts: am335x-bone-common: correct mux mode for mmc1_cmd
On Fri, Sep 20, 2013 at 11:08:16PM +0530, Balaji T K wrote: correct mux mode for mmc1_cmd to detect eMMC on bone-black Signed-off-by: Balaji T K balaj...@ti.com Tested on my BBB, I see that after this patch eMMC gets detected just fine: Tested-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/3] omap2: Change clk dev id for rng to omap3-rom-rng
* Pali Rohár pali.ro...@gmail.com [130920 09:49]:
On Friday 20 September 2013 18:23:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which is
for omap2 and omap4. For omap3 HS devices there is new
driver omap3-rom-rng which needs that clk. And because
there cannot be two drivers with same name, rename omap3
clk dev id.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c index
334b767..5059338 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3274,7 +3274,7 @@ static struct omap_clk omap36xx_clks[]
= {
*/
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
- CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
Hmm are you sure the omap_rng is not available on
any of the omap3 GP versions? If so, the omap_rng
alias should be kept as well.
Regards,
Tony
I really do not know, but driver char/hw_random/omap-rng.c
support only omap2 and omap4 platforms. So omap_rng dev id for
omap3 is not used.
In email [1] you suggested to use clk_get instead clk_get_sys. If
I understand correctly clk_get calling clk_get_sys with driver
name. So dev in in CLK macro must be same as driver name. And
because in cclock3xxx_data.c is dev id omap_rng and there is
already driver with name omap_rng, I need to rename dev in
cclock3xxx_data.c to get new omap3-rom-rng driver working.
Or if you know better way how to do it, let me know.
I think it's safest to keep the existing alias also, and
add a comment saying that it may not be available on omap3
processors.
Regards,
Tony
[1] - https://lkml.org/lkml/2013/4/1/278
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] omap2: Change clk dev id for rng to omap3-rom-rng
* Pali Rohár pali.ro...@gmail.com [130920 11:32]:
On Friday 20 September 2013 19:46:41 Tony Lindgren wrote:
Ok, then there is new patch which only adding omap3-rom-rng and not removing
omap_rng.
It is OK to have same CLK data but with different names?
Yes in this case it's always either omap_rng or omap3-rom-rng
so the patch below looks OK to me.
Regards,
Tony
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 334b767..03a2829 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3275,6 +3275,7 @@ static struct omap_clk omap36xx_clks[] = {
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] omap2: Change clk dev id for rng to omap3-rom-rng
On Friday 20 September 2013 19:46:41 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 09:49]:
On Friday 20 September 2013 18:23:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which
is for omap2 and omap4. For omap3 HS devices there is
new driver omap3-rom-rng which needs that clk. And
because there cannot be two drivers with same name,
rename omap3 clk dev id.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c index
334b767..5059338 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3274,7 +3274,7 @@ static struct omap_clk
omap36xx_clks[] = {
*/
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
- CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
Hmm are you sure the omap_rng is not available on
any of the omap3 GP versions? If so, the omap_rng
alias should be kept as well.
Regards,
Tony
I really do not know, but driver char/hw_random/omap-rng.c
support only omap2 and omap4 platforms. So omap_rng dev id
for omap3 is not used.
In email [1] you suggested to use clk_get instead
clk_get_sys. If I understand correctly clk_get calling
clk_get_sys with driver name. So dev in in CLK macro must
be same as driver name. And because in cclock3xxx_data.c is
dev id omap_rng and there is already driver with name
omap_rng, I need to rename dev in cclock3xxx_data.c to
get new omap3-rom-rng driver working.
Or if you know better way how to do it, let me know.
I think it's safest to keep the existing alias also, and
add a comment saying that it may not be available on omap3
processors.
Regards,
Tony
[1] - https://lkml.org/lkml/2013/4/1/278
Ok, then there is new patch which only adding omap3-rom-rng and not removing
omap_rng.
It is OK to have same CLK data but with different names?
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 334b767..03a2829 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3275,6 +3275,7 @@ static struct omap_clk omap36xx_clks[] = {
static struct omap_clk omap34xx_omap36xx_clks[] = {
CLK(NULL, aes1_ick, aes1_ick),
CLK(omap_rng, ick, rng_ick),
+ CLK(omap3-rom-rng,ick, rng_ick),
CLK(NULL, sha11_ick,sha11_ick),
CLK(NULL, des1_ick, des1_ick),
CLK(NULL, cam_mclk, cam_mclk),
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[net-next PATCH 2/4] drivers: net: cpsw-phy-sel: Add new driver for phy mode selection for cpsw
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this register is modified, and so it needs reprogramming
after resume.
This patch adds a new driver in which hardware interface can configure
correct register bits when the slave is opened.
The AM33xx also has a bit for each slave to configure the RMII reference
clock direction. Setting it is now supported by a per-slave DT property.
This code path introducted by this patch is currently exclusive for
am33xx and same can be extened to various platforms via the DT compatibility
property.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Daniel Mack zon...@gmail.com
---
.../devicetree/bindings/net/cpsw-phy-sel.txt | 28
drivers/net/ethernet/ti/Kconfig| 8 +
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/cpsw-phy-sel.c | 161 +
drivers/net/ethernet/ti/cpsw.h | 2 +
5 files changed, 200 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
create mode 100644 drivers/net/ethernet/ti/cpsw-phy-sel.c
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
new file mode 100644
index 000..7ff57a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -0,0 +1,28 @@
+TI CPSW Phy mode Selection Device Tree Bindings
+---
+
+Required properties:
+- compatible : Should be ti,am3352-cpsw-phy-sel
+- reg : physical base address and size of the cpsw
+ registers map
+- reg-names: names of the register map given in reg node
+
+Optional properties:
+-rmii-clock-ext: If present, the driver will configure the RMII
+ interface to external clock usage
+
+Examples:
+
+ phy_sel: cpsw-phy-sel@44e10650 {
+ compatible = ti,am3352-cpsw-phy-sel;
+ reg= 0x44e10650 0x4;
+ reg-names = gmii-sel;
+ };
+
+(or)
+ phy_sel: cpsw-phy-sel@44e10650 {
+ compatible = ti,am3352-cpsw-phy-sel;
+ reg= 0x44e10650 0x4;
+ reg-names = gmii-sel;
+ rmii-clock-ext;
+ };
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index de71b1e..53150c2 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -49,11 +49,19 @@ config TI_DAVINCI_CPDMA
To compile this driver as a module, choose M here: the module
will be called davinci_cpdma. This is recommended.
+config TI_CPSW_PHY_SEL
+ boolean TI CPSW Switch Phy sel Support
+ depends on TI_CPSW
+ ---help---
+ This driver supports configuring of the phy mode connected to
+ the CPSW.
+
config TI_CPSW
tristate TI CPSW Switch Support
depends on ARM (ARCH_DAVINCI || SOC_AM33XX)
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
+ select TI_CPSW_PHY_SEL
---help---
This driver supports TI's CPSW Ethernet Switch.
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index c65148e..9cfaab8 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_CPMAC) += cpmac.o
obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
+obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
new file mode 100644
index 000..e092ede
--- /dev/null
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -0,0 +1,161 @@
+/* Texas Instruments Ethernet Switch Driver
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/platform_device.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/phy.h
+#include linux/of.h
+#include linux/of_device.h
+
+#include cpsw.h
+
+/* AM33xx SoC specific definitions for the CONTROL port */
+#define AM33XX_GMII_SEL_MODE_MII 0
+#define
Re: [PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*
On 09/20/2013 11:51 AM, Viresh Kumar wrote: On 20 September 2013 18:08, Nishanth Menon n...@ti.com wrote: I am open to suggestions if any one feels we can improve this better. I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp** though.. I had proposed this earlier, however, had gone with Rafael's suggestion [1] to have the right context to the usage. I believe that change was from Patch #2[1] Yeah.. I just replied on a single patch :) yes, you are right, I had squashed this patch in to squelch checkpatch warnings: I see.. I had added a comment: Minor checkpatch warning fixes as a result of this change was fixed as well. I really missed that.. no problems.. Would you suggest I split the change off to a separate patch or improve the comment a little more? don't really know, maybe leave those as is and let checkpatch warn you.. that is fair as well. i can split it off seperately in the next respin. [1] http://marc.info/?l=linaro-kernelm=137645747511725w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 1/4] net: ethernet: cpsw: switch to devres allocations
From: Daniel Mack zon...@gmail.com
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 153 -
1 file changed, 43 insertions(+), 110 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 79974e3..01c42e1 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -367,8 +367,6 @@ struct cpsw_priv {
spinlock_t lock;
struct platform_device *pdev;
struct net_device *ndev;
- struct resource *cpsw_res;
- struct resource *cpsw_wr_res;
struct napi_struct napi;
struct device *dev;
struct cpsw_platform_data data;
@@ -1712,62 +1710,55 @@ static int cpsw_probe_dt(struct cpsw_platform_data
*data,
if (of_property_read_u32(node, active_slave, prop)) {
pr_err(Missing active_slave property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-active_slave = prop;
if (of_property_read_u32(node, cpts_clock_mult, prop)) {
pr_err(Missing cpts_clock_mult property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-cpts_clock_mult = prop;
if (of_property_read_u32(node, cpts_clock_shift, prop)) {
pr_err(Missing cpts_clock_shift property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-cpts_clock_shift = prop;
- data-slave_data = kcalloc(data-slaves, sizeof(struct cpsw_slave_data),
- GFP_KERNEL);
+ data-slave_data = devm_kzalloc(pdev-dev, data-slaves
+ * sizeof(struct cpsw_slave_data),
+ GFP_KERNEL);
if (!data-slave_data)
- return -EINVAL;
+ return -ENOMEM;
if (of_property_read_u32(node, cpdma_channels, prop)) {
pr_err(Missing cpdma_channels property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-channels = prop;
if (of_property_read_u32(node, ale_entries, prop)) {
pr_err(Missing ale_entries property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-ale_entries = prop;
if (of_property_read_u32(node, bd_ram_size, prop)) {
pr_err(Missing bd_ram_size property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-bd_ram_size = prop;
if (of_property_read_u32(node, rx_descs, prop)) {
pr_err(Missing rx_descs property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-rx_descs = prop;
if (of_property_read_u32(node, mac_control, prop)) {
pr_err(Missing mac_control property in the DT.\n);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
data-mac_control = prop;
@@ -1794,8 +1785,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, phy_id, lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
pr_err(Missing slave[%d] phy_id property\n, i);
- ret = -EINVAL;
- goto error_ret;
+ return -EINVAL;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -1825,10 +1815,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
return 0;
-
-error_ret:
- kfree(data-slave_data);
- return ret;
}
static int cpsw_probe_dual_emac(struct platform_device *pdev,
@@ -1870,7 +1856,6 @@ static int cpsw_probe_dual_emac(struct platform_device
*pdev,
priv_sl2-coal_intvl = 0;
priv_sl2-bus_freq_mhz = priv-bus_freq_mhz;
- priv_sl2-cpsw_res = priv-cpsw_res;
priv_sl2-regs = priv-regs;
priv_sl2-host_port = priv-host_port;
priv_sl2-host_port_regs = priv-host_port_regs;
@@ -1914,8 +1899,8 @@ static int cpsw_probe(struct platform_device *pdev)
struct cpsw_priv*priv;
struct
[net-next PATCH 0/4] cpsw: support for control module register
This patch series adds the support for configuring GMII_SEL register of control module to select the phy mode type and also to configure the clock source for RMII phy mode whether to use internal clock or the external clock from the phy itself. Till now CPSW works as this configuration is done in U-Boot and carried over to the kernel. But during suspend/resume Control module tends to lose its configured value for GMII_SEL register in AM33xx PG1.0, so if CPSW is used in RMII or RGMII mode, on resume cpsw is not working as GMII_SEL register lost its configuration values. The initial version of the patch is done by Daniel Mack but as per Tony's comment he wants it as a seperate driver as it is done in USB control module. I have created a seperate driver for the same. Changes from RFC version: * Changed _ to - in DT names as per Serger's comment Daniel Mack (1): net: ethernet: cpsw: switch to devres allocations Mugunthan V N (3): drivers: net: cpsw-phy-sel: Add new driver for phy mode selection for cpsw drivers: net: cpsw: use cpsw-phy-sel driver to configure phy mode ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode .../devicetree/bindings/net/cpsw-phy-sel.txt | 28 arch/arm/boot/dts/am33xx.dtsi | 6 + drivers/net/ethernet/ti/Kconfig| 8 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/cpsw-phy-sel.c | 161 + drivers/net/ethernet/ti/cpsw.c | 157 ++-- drivers/net/ethernet/ti/cpsw.h | 2 + 7 files changed, 253 insertions(+), 110 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/cpsw-phy-sel.txt create mode 100644 drivers/net/ethernet/ti/cpsw-phy-sel.c -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: dts: am335x-bone-common: correct mux mode for mmc1_cmd
On 09/20/2013 12:38 PM, Balaji T K wrote:
correct mux mode for mmc1_cmd to detect eMMC on bone-black
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 56361ce..90ab56c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -117,7 +117,7 @@
emmc_pins: pinmux_emmc_pins {
pinctrl-single,pins =
0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk */
- 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn2.mmc1_cmd */
0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0 */
0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1 */
0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2 */
is'nt this a common change? why is it black only? if it is so, then
the pinmux should probably be spun off outside bone-common.dtsi into
boneblack.dtsi perhaps?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger
On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
This patch will register bq24150a charger in RX-51 board data.
Patch also adding platform function between isp1704 and
bq2415x drivers for detecting charger type.
So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 56
+- 1 file changed, 55 insertions(+),
1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c index
9c2dd10..a993ffe 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
#include linux/gpio_keys.h
#include linux/mmc/host.h
#include linux/power/isp1704_charger.h
+#include linux/power/bq2415x_charger.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/mtd-onenand-omap2.h
@@ -270,6 +271,44 @@ static struct platform_device
rx51_battery_device = { .id = -1,
};
+static enum bq2415x_mode rx51_charger_mode =
BQ2415X_MODE_OFF; +static void *rx51_charger_hook_data;
+static void (*rx51_charger_hook)(enum bq2415x_mode mode, void
*data); +
+static int rx51_charger_set_hook(
+ void (*hook)(enum bq2415x_mode mode, void *data), void
*data) +{
+ rx51_charger_hook = hook;
+ rx51_charger_hook_data = data;
+ if (rx51_charger_hook)
+ rx51_charger_hook(rx51_charger_mode,
rx51_charger_hook_data); +return 1;
+}
+
+static void rx51_charger_set_current(int mA)
+{
+ enum bq2415x_mode mode;
+
+ pr_info(RX-51: Charger current limit is %d mA\n, mA);
+
+ if (mA == 0)
+ mode = BQ2415X_MODE_OFF;
+ else if (mA 500)
+ mode = BQ2415X_MODE_NONE;
+ else if (mA 1800)
+ mode = BQ2415X_MODE_HOST_CHARGER;
+ else
+ mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+ if (rx51_charger_mode == mode)
+ return;
+
+ rx51_charger_mode = mode;
+
+ if (rx51_charger_hook)
+ rx51_charger_hook(rx51_charger_mode,
rx51_charger_hook_data); +}
+
static void rx51_charger_set_power(bool on)
{
gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
@@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
on)
static struct isp1704_charger_data rx51_charger_data = {
.set_power = rx51_charger_set_power,
+ .set_current= rx51_charger_set_current,
};
static struct platform_device rx51_charger_device = {
@@ -1017,6 +1057,16 @@ static struct aic3x_pdata
rx51_aic3x_data2 = { .gpio_reset = 60,
};
+static struct bq2415x_platform_data
rx51_bq24150a_platform_data = { + .current_limit = 100,
/*
mA */
+ .weak_battery_voltage = 3400, /* mV */
+ .battery_regulation_voltage = 4200, /* mV */
+ .charge_current = 650, /* mA */
+ .termination_current = 100, /* mA */
+ .resistor_sense = 68, /* m ohm */
+ .set_mode_hook = rx51_charger_set_hook,
+};
+
static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = { {
I2C_BOARD_INFO(tlv320aic3x, 0x18),
@@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = { {
I2C_BOARD_INFO(tpa6130a2, 0x60),
.platform_data = rx51_tpa6130a2_data,
- }
+ },
+ {
+ I2C_BOARD_INFO(bq24150a, 0x6b),
+ .platform_data = rx51_bq24150a_platform_data,
+ },
};
static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_3[] = {
Tony, can you look and review this board patch?
I think that this patch series it the most important for Nokia
N900, because it finally bringing charging support. And without
charging battery it very hard to use phone which has power supply
only from battery.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[net-next PATCH 3/4] drivers: net: cpsw: use cpsw-phy-sel driver to configure phy mode
Phy mode can be configured via the cpsw-phy-sel driver, this patch enabled the cpsw driver to utilise the api provided by the cpsw-phy-sel driver to configure the phy mode. Signed-off-by: Mugunthan V N mugunthan...@ti.com Tested-by: Daniel Mack zon...@gmail.com --- drivers/net/ethernet/ti/cpsw.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 01c42e1..5efb37b 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -1021,6 +1021,10 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv) dev_info(priv-dev, phy found : id is : 0x%x\n, slave-phy-phy_id); phy_start(slave-phy); + + /* Configure GMII_SEL register */ + cpsw_phy_sel(priv-pdev-dev, slave-phy-interface, +slave-slave_num); } } -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 4/4] ARM: dts: am33xx: adopt to cpsw-phy-sel driver to configure phy mode
Add DT entries for the phy mode selection in AM33xx SoC using cpsw-phy-sel
driver.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Daniel Mack zon...@gmail.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..d76ae24 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -594,6 +594,12 @@
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
+
+ phy_sel: cpsw-phy-sel@44e10650 {
+ compatible = ti,am3352-cpsw-phy-sel;
+ reg= 0x44e10650 0x4;
+ reg-names = gmii-sel;
+ };
};
ocmcram: ocmcram@4030 {
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
