Re: [PATCH v2 10/18] OMAPDSS: DISPC: Configure input and output sizes for writeback
On Tuesday 25 September 2012 08:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.
Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e42e902..04fdd33 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -719,7 +719,7 @@ static void dispc_ovl_set_input_size(enum omap_plane plane,
int width,
{
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
- if (plane == OMAP_DSS_GFX)
+ if (plane == OMAP_DSS_GFX || plane == OMAP_DSS_WB)
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
else
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
@@ -734,7 +734,10 @@ static void dispc_ovl_set_output_size(enum omap_plane
plane, int width,
val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
- dispc_write_reg(DISPC_OVL_SIZE(plane), val);
+ if (plane == OMAP_DSS_WB)
+ dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
+ else
+ dispc_write_reg(DISPC_OVL_SIZE(plane), val);
}
Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.
It'll be hard for someone who's referring to the TRM in that case. It'll
also be hard to track reg dumps if these names change. I think we should
stick to the TRM names only.
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 v2 10/18] OMAPDSS: DISPC: Configure input and output sizes for writeback
On Wed, 2012-09-26 at 11:52 +0530, Archit Taneja wrote:
On Tuesday 25 September 2012 08:03 PM, Tomi Valkeinen wrote:
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
Writeback uses the WB_PICTURE_SIZE register to define the size of the
content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager
to
which it is connected, this is the input to the scaler. This naming is
different
as compared to overlays.
Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index e42e902..04fdd33 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -719,7 +719,7 @@ static void dispc_ovl_set_input_size(enum omap_plane
plane, int width,
{
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
- if (plane == OMAP_DSS_GFX)
+ if (plane == OMAP_DSS_GFX || plane == OMAP_DSS_WB)
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
else
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
@@ -734,7 +734,10 @@ static void dispc_ovl_set_output_size(enum omap_plane
plane, int width,
val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
- dispc_write_reg(DISPC_OVL_SIZE(plane), val);
+ if (plane == OMAP_DSS_WB)
+ dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
+ else
+ dispc_write_reg(DISPC_OVL_SIZE(plane), val);
}
Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.
It'll be hard for someone who's referring to the TRM in that case. It'll
also be hard to track reg dumps if these names change. I think we should
stick to the TRM names only.
Generally speaking I agree.
However, with each new OMAP we get register name changes. We already
have at least a few of those, and I think it'll just get worse. So at
some point we'll have a mishmash of register names from different omap
versions, or we'll rename the registers according to one particular omap
version (probably the latest one), or we'll name the registers as seems
best for the driver.
But yes, perhaps it's still best to keep the reg names as they are.
Perhaps there's even a logic with the names, I just can't see it =).
Tomi
signature.asc
Description: This is a digitally signed message part
Re: Powering OMAP's pins
On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120925 10:06]: On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120925 03:22]: Hi Tony, Each pin of OMAP requires a particular power to be enabled for the pin to function (Ball Characteristics table from data manual). Is there a plan how this is managed with pinctrl? Currently each driver needs to make sure the correct regulators are enabled for the pins it uses, which is platform specific and messy. As a driver maintainer, I would wish that the pins would just get enabled automatically when I call pm_runtime_get()... Hmm can you clarify a bit what exactly do you want to do there with pm_runtime_get()? Call the regulator framework? Well, I'm not very familiar with pinctrl, but if I've understood right, a set of pins are assigned to a driver in DT data (or wherever, that's not relevant). Those pins should be automatically configured and enabled when the driver uses pm_runtime_get() to enable its hardware. And if I've also understood right, the pinctrl discussions related to omap have only dealt with pin muxing itself. But that's not enough to get the pin functional, but the relevant regulator needs to be enabled also. So when I call pm_runtime_get in the omapdss driver, I imagine that the runtime PM and pinctrl would together handle muxing the pins for omapdss's use, and also enable the relevant regulators to make the pins usable. But aren't these regulators something that potentially are dynamically configured by the driver? For example, vdds_(sd)mmc1 depends on which card is plugged in. Ah, ok. Are there other cases than mmc where the voltage(?) needs to be dynamically configured? So to me it seesm that it's best to define the regulators and claim them by the driver using them rather than try to use automatically. It's Well, in mmc case it sounds it's the driver's job. Perhaps the DSS pins are special cases, then. I don't see any dynamic configuration needed there. Sometimes the regulator for the pins is implicitly enabled as it's needed by a DSS component. For example when using DSI pins, the vdda_dsi used by the pins is already enabled as it's used for the DSI itself, so the pins just happen to work. But then the same pins that are used for DSI can be used for other things. On omap3430 DSI's dx0 pin can also be muxed to dss_data0, uart1_cts, gpio_70. Of these, I'm mainly interested in the dss_data0, of course. So if I want to use parallel dss output, which uses dss_data0 pin, omapdss driver needs to enable vdda_dsi on omap3430, even though there's no other use for vdda_dsi in the parallel output case. But on omap4430 data0 pins seems to be powered by vdds_1p8v. On AM35xx something else. So either I need to program all those into the omapdss driver, which is not the right way as they are platform specific things, or I need to pass some kind of pin data from platform data to omapdss driver, giving the required regulator for each pin. And how about the uart1_cts or gpio_70 pins on 3430? Do both uart and gpio drivers need to have similar kind of platform data, giving the required regulator so that the pin can be enabled? sort of the same situation as with GPIO pins? How are the GPIO pins handled? They have this kind of pin-regulator mapping? Tomi signature.asc Description: This is a digitally signed message part
RE: [RFC PATCH 00/13] DMA Engine support for AM33xx
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote:
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
There are a mind-boggling number of dependencies for this series:
- Jon Hunter's OF DMA helpers series
https://patchwork.kernel.org/patch/1461061/
https://patchwork.kernel.org/patch/1461051/
- Patch to address OF DMA helpers naming issues:
https://patchwork.kernel.org/patch/1477921/
- EDMA DMA Engine wrapper driver in linux-next
c2dde5f8f2095d7c623ff3565c1462e190272273
- EDMA DMA Engine wrapper driver bug fix:
https://patchwork.kernel.org/patch/1474411/
- A huge number of patches in linux-next for AM33xx boot
(too numerous to list)
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
What works? Well, with this series we now have MMC and SPI support
on AM33xx. The only caveat for MMC is that the mmc3 controller has
its events on the crossbar and is not usable right now.
This is tested on BeagleBone with a SPI framebuffer driver and SD
card.
After this series, the plan is to convert the last in-tree user
of the private EDMA API (davinci-pcm/mcasp) and then eliminate
the private EDMA API by folding its functionality into
drivers/dma/edma.c.
TODO:
add AM33xx crossbar support to the private EDMA API
(any EDMA events on the crossbar are not supported)
Can you please mention the base repo you have taken as starting point.
(repo + extra patches ...).
It's mainline 3.6-rc6 and you can see the complete set of patches
at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2
This will help us to test the code.
This is because I looked at the patch 12/13 and I see that mmc
device-node is modified. But in mainline I don’t see device
node for mmc (yet).
Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and
fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include
in this series. I'll have them in for v2.
Yesterday I tested edma patches on latest linux-next/master + merge of
linux-omap/for_3.7/dts_part2. Below are my observations
1. baseline = linux-next/master + merge of linux-omap/for_3.7/dts_part2
2. on top of above branch, I applied patches [1-9]/13 of your edma
patches
3. few patches required trivial changes before applying
4. Applied dma of patches as you mentioned
5. add custom patch (ARM: CUSTOM: Build a uImage with dtb already
appended)
From https://github.com/hvaibhav/am335x-linux/commit/
7e72f5ed4b702c9373d19f7626f07ae31a381d53#arch/arm/Makefile
6. Modified 9/13 patch to apply properly on latest am33xx.dtsi.
a. Edma portion as it is
b. mmc portion as below
mmc1: mmc@4806 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc1;
ti,dual-volt;
ti,needs-special-reset;
bus-width = 4;
vmmc-supply = vmmc_reg;
dmas = edma 24
edma 25;
dma-names = tx, rx;
};
c. added mmc pinmux as-well
7. make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm distclean
make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm
omap2plus_defconfig
8. enabled TI_EDMA from menuconfig (since it was not enabled for
omap2plus_defconfig
9. make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm uImage
make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm
uImage-dtb.am335x-evm
With above changes, edma probe was failing at request_mem_region()
Inside linux-next/arch/arm/common/edma.c -- edma_probe()
I had to modify edma_probe as below
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index f337f81..efe2673 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1589,11 +1589,11 @@ static int __init edma_probe(struct platform_device
*pdev)
for (j = 0; j EDMA_MAX_CC; j++) {
if (node) {
Re: [RFC PATCH] drivers: phy: add generic PHY framework
Hi,
On Mon, Sep 17, 2012 at 3:03 PM, Marc Kleine-Budde m...@pengutronix.de wrote:
On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
[...]
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
What about adding a struct phy_res, doing so,m you don't need these
casts, and it's easier to add more pointers if needed.
Wont we still need to do the cast since you get only a void pointer.
Maybe I'm not getting you.
As res is a void pointer, no need to hast to to a struct phy_res
pointer, if you think that's unclean code, you can still cast it. But
IMHO the code is far more readable.
+
+ phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+ return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, u8 index)
+{
+ struct phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, phy_bind_list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
*node)
+{
+ int index = 0;
+ struct phy *phy;
^^
Please remove that stray space.
Sure.
+ struct phy_bind *phy_map = NULL;
+
+ list_for_each_entry(phy_map, phy_bind_list, list)
+ if (!(strcmp(phy_map-dev_name, dev_name(dev
+ index++;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-desc-of_node)
+ continue;
+
+ phy_map = phy_bind(dev_name(dev), index,
dev_name(phy-dev));
+ if (!IS_ERR(phy_map)) {
+ phy_map-phy = phy;
+ phy_map-auto_bind = true;
+ }
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+/**
+ * devm_phy_get - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres
data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, u8 index)
+{
+ struct phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = phy_get(dev, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
nitpick: when when if has { }, else should have, too.
Sure.
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * devm_phy_put - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+ int r;
+
+ r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+ dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * devm_of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ *
+ * Returns the phy driver associated with the given phandle value,
Re: [RFC PATCH] drivers: phy: add generic PHY framework
On 09/26/2012 11:20 AM, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Mon, Sep 17, 2012 at 3:03 PM, Marc Kleine-Budde m...@pengutronix.de
wrote:
On 09/14/2012 03:06 PM, ABRAHAM, KISHON VIJAY wrote:
[...]
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
What about adding a struct phy_res, doing so,m you don't need these
casts, and it's easier to add more pointers if needed.
Wont we still need to do the cast since you get only a void pointer.
Maybe I'm not getting you.
As res is a void pointer, no need to hast to to a struct phy_res
pointer, if you think that's unclean code, you can still cast it. But
IMHO the code is far more readable.
+
+ phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void
*match_data)
+{
+ return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, u8 index)
+{
+ struct phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, phy_bind_list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+ return phy_bind-phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+static struct phy *of_phy_lookup(struct device *dev, struct device_node
*node)
+{
+ int index = 0;
+ struct phy *phy;
^^
Please remove that stray space.
Sure.
+ struct phy_bind *phy_map = NULL;
+
+ list_for_each_entry(phy_map, phy_bind_list, list)
+ if (!(strcmp(phy_map-dev_name, dev_name(dev
+ index++;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-desc-of_node)
+ continue;
+
+ phy_map = phy_bind(dev_name(dev), index,
dev_name(phy-dev));
+ if (!IS_ERR(phy_map)) {
+ phy_map-phy = phy;
+ phy_map-auto_bind = true;
+ }
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+/**
+ * devm_phy_get - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres
data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, u8 index)
+{
+ struct phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = phy_get(dev, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
nitpick: when when if has { }, else should have, too.
Sure.
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * devm_phy_put - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+ int r;
+
+ r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+ dev_WARN_ONCE(dev, r, couldn't find PHY resource\n);
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * devm_of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ *
+ *
Re: [PATCH] mtd: nand: omap2: Fix the nand-disk led trigger
On Mon, 2012-09-17 at 13:52 +0300, Grazvydas Ignotas wrote: On Thu, Sep 13, 2012 at 6:06 PM, Raphael Assenat r...@8d.com wrote: When the omap2 nand flash driver is used, the nand-disk led trigger does not work due to nand_wait_ready not being called. I think better solution is just to delete omap_wait() function, which is just a copy of nand_wait() without LED and oops handling. If waitfunc is not set by the driver, default nand_wait is used by the core. Or if it does really need own wait function, we can re-work the internal api similarly to what we did to MTD api. Instead of calling 'chip-waitfunc()' directly from everywhere, have a wrapper 'nand_wati()' function, which can do things common to all drivers, and then actually call the underlying '-waitfunc()'. So in this case, it can do the LED stuff. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH v2] arm/dts: AM33XX: Add SPI device tree data
Hi Benoit, On Tue, Sep 18, 2012 at 11:00:28, Philip, Avinash wrote: Add McSPI data node to AM33XX device tree file. The McSPI module (and so as the driver) is reused from OMAP4. Signed-off-by: Philip, Avinash avinashphi...@ti.com Tested-by: Matt Porter mpor...@ti.com I haven't received any comments till now for this patch. Do you have any comments for this patch? With this patch SPI is working on AM335x SoC in PIO mode. If no comments, can you pull this patch for 3.7? Thanks Avinash -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote: On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Gentle Ping. Matt Poter recently submitted EDMA related patches as RFC. He confirmed that basic mmc is working on AM335x with his edma patches. Above patch is required to get High-speed cards working on AM335x. I haven't seen any review comments for this. Can this be pulled in for 3.7? Regards, Venkat. Regards, Gururaja Regards, Gururaja -- 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: [PATCHv7 17/21] ARM: OMAP4: TWL: enable high speed mode for PMIC communication
Hi Tero,
On 09/25/2012 07:33 PM, Tero Kristo wrote:
With the new parameters, I2C can now be put to high speed mode for
better performance.
We have twl6040 on the same bus. have you tried this with audio enabled?
twl6040 is in standard mode (up to 100 kbps) after power up...
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 611cb63..7ff9667 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -218,6 +218,7 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
.cmd_reg_addr = OMAP4_VDD_CORE_SR_CMD_REG,
+ .i2c_high_speed = true,
.i2c_pad_load = 3,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
--
Péter
--
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
replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Hi, With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using pinctrl and that seems to work. On the 3.2 vendor tree there was the omap_mux driver with an awesome debugfs interface: # cat /sys/kernel/debug/omap_mux/lcd_data0 name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3 signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA | pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6 Notice how it tells me that it's muxed the PWM in 2 ways: signal name (ehrpwm2A) and register content (0x0003). Compare to pinctrl: root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 * pinconf-pins:pin 40 (44e108a0): pingroups:pin 40 (44e108a0) pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function pinmux_pruss_led_pins group pinmux_pruss_led_pins pins:pin 40 (44e108a0) pinctrl-single What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in the DT, but debugfs remains mute on how pin 40 is muxed. regards, Koen-- 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: Powering OMAP's pins
On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: So when I call pm_runtime_get in the omapdss driver, I imagine that the runtime PM and pinctrl would together handle muxing the pins for omapdss's use, and also enable the relevant regulators to make the pins usable. So we do something like this in the recent patch to the PL022 SPI driver by setting the pinctrl states inside the runtime suspend and resume callbacks: http://sourceforge.net/mailarchive/forum.php?thread_name=20120920130240.GR17666%40opensource.wolfsonmicro.comforum_name=spi-devel-general You can very well do clocks and regulators in these functions as well. Other platforms like shmobile will use runtime pm notifications to do all this orthogonally in a central place, which may be applicable for OMAP. Yours, Linus Walleij -- 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: [PATCHv7 17/21] ARM: OMAP4: TWL: enable high speed mode for PMIC communication
On Wed, 2012-09-26 at 14:39 +0300, Peter Ujfalusi wrote:
Hi Tero,
On 09/25/2012 07:33 PM, Tero Kristo wrote:
With the new parameters, I2C can now be put to high speed mode for
better performance.
We have twl6040 on the same bus. have you tried this with audio enabled?
twl6040 is in standard mode (up to 100 kbps) after power up...
No, I don't have capability to try out audio. Can you give it a shot and
see what happens? Otherwise we probably just have to drop this patch out
for now.
-Tero
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 611cb63..7ff9667 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -218,6 +218,7 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
.cmd_reg_addr = OMAP4_VDD_CORE_SR_CMD_REG,
+ .i2c_high_speed = true,
.i2c_pad_load = 3,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
--
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: [PATCHv7 17/21] ARM: OMAP4: TWL: enable high speed mode for PMIC communication
On 09/26/2012 03:06 PM, Tero Kristo wrote: On Wed, 2012-09-26 at 14:39 +0300, Peter Ujfalusi wrote: Hi Tero, On 09/25/2012 07:33 PM, Tero Kristo wrote: With the new parameters, I2C can now be put to high speed mode for better performance. We have twl6040 on the same bus. have you tried this with audio enabled? twl6040 is in standard mode (up to 100 kbps) after power up... No, I don't have capability to try out audio. Can you give it a shot and see what happens? Otherwise we probably just have to drop this patch out for now. Just compiled your mainline-3.6-rc5-omap-auto-ret-v7 branch with audio. Works fine on my Blaze. -- Péter -- 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: Powering OMAP's pins
On Wed, 2012-09-26 at 13:46 +0200, Linus Walleij wrote: On Tue, Sep 25, 2012 at 7:05 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: So when I call pm_runtime_get in the omapdss driver, I imagine that the runtime PM and pinctrl would together handle muxing the pins for omapdss's use, and also enable the relevant regulators to make the pins usable. So we do something like this in the recent patch to the PL022 SPI driver by setting the pinctrl states inside the runtime suspend and resume callbacks: http://sourceforge.net/mailarchive/forum.php?thread_name=20120920130240.GR17666%40opensource.wolfsonmicro.comforum_name=spi-devel-general You can very well do clocks and regulators in these functions as well. That's not really what I mean. The regulators in question are OMAP version specific, so the driver shouldn't know which regulators are needed. The regulators for each pin could be passed to the driver from platform data, and the driver could enable the regulators in the runtime resume callback. But then each driver that may use the pins would require the same code and the same platform data to be duplicated. Other platforms like shmobile will use runtime pm notifications to do all this orthogonally in a central place, which may be applicable for OMAP. What notifications do you refer to? The PM notifiers (PM_RESTORE_PREPARE etc) are global, so they are not of help here. I was going through the pinctrl code to understand it better. If I read it right, there's a default pin configuration that is set at boot time, and if that configuration needs to be changed later, the drivers use pinctrl_get() pinctrl_select_state() to change it. How I thought that it works (before going through the code) is that at boot time a default pin configuration is set, and for many pins this default config is disabled/safe mode. When a driver, that has been assigned those pins, is loaded and uses pm_runtime_get() to start its hardware, the pins would also be enabled and muxed for the proper operation, without the driver doing any pinctrl calls. And when the driver does pm_runtime_put(), the pins would be disabled and changed to safe-mode. Is there a reason the pin control cannot be automatic as I described above? The pl022 change you linked seems to do the same, but manually. Again, I'm not so familiar with pin control, so perhaps all this can be implemented in platform code. It sounds easier to me (from driver's perspective), and should preserve some minimal power also if the pins are disabled when not in use. Of course, disabled here is platform and board specific, on some boards a pin must be kept alive and, say, pulled down even when not in use. Tomi signature.asc Description: This is a digitally signed message part
Re: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Adding Linus W. and lkml. On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote: Hi, With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using pinctrl and that seems to work. On the 3.2 vendor tree there was the omap_mux driver with an awesome debugfs interface: # cat /sys/kernel/debug/omap_mux/lcd_data0 name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3 signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA | pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6 Notice how it tells me that it's muxed the PWM in 2 ways: signal name (ehrpwm2A) and register content (0x0003). Compare to pinctrl: root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 * pinconf-pins:pin 40 (44e108a0): pingroups:pin 40 (44e108a0) pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function pinmux_pruss_led_pins group pinmux_pruss_led_pins pins:pin 40 (44e108a0) pinctrl-single What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in the DT, but debugfs remains mute on how pin 40 is muxed. It does seem like a pretty big gap in the pinctrl/pinmux debugfs interface when viewed from an OMAP perspective. Ideally there would be a pinctrl/pinmux hook to the pinmux driver to provide the detailed h/w specific pin state info. -Matt -- 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 2/2] arm: omap: sram: skip the first 16K on OMAP3 HS
Hi Aaro On Thu, 30 Aug 2012 13:40:30 -0700 Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120829 08:30]: On Wed, Aug 29, 2012 at 8:24 AM, Aaro Koskinen aaro.koski...@iki.fi wrote: In some OMAP3 HS devices (at least Nokia N9 and N950), the public SRAM seems to conflict with secure portition of SRAM. When booting the 3.6-rc3 kernel (and also earlier) on these devices, the kernel gets tainted with tons of the following warnings: [6.894348] In-band Error seen by MPU at address 0 [...] [6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 Fix this by skipping the first 16K of the public SRAM. (Note that the mapping could not be changed, as it resulted in secure monitor call failure in save_secure_sram().) This will leave 12K SRAM available that should be still sufficient. The patch has been boot tested with vanilla 3.6-rc3 on N900, N950 and N9. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/plat-omap/sram.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) Looks good. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks applying both into fixes. Aaro, note that now that we're merging patches via the arm soc tree, let's use ARM: OMAP: for the subject so I don't need to fix it up ;) This issue appears to be in 3.5 too (I didn't check others). Should you commit id of this patch and affected kernel versions to stable? -- Jarkko -- 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 00/13] DMA Engine support for AM33xx
On Wed, Sep 26, 2012 at 08:26:19AM +, Hebbar, Gururaja wrote:
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote:
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
There are a mind-boggling number of dependencies for this series:
- Jon Hunter's OF DMA helpers series
https://patchwork.kernel.org/patch/1461061/
https://patchwork.kernel.org/patch/1461051/
- Patch to address OF DMA helpers naming issues:
https://patchwork.kernel.org/patch/1477921/
- EDMA DMA Engine wrapper driver in linux-next
c2dde5f8f2095d7c623ff3565c1462e190272273
- EDMA DMA Engine wrapper driver bug fix:
https://patchwork.kernel.org/patch/1474411/
- A huge number of patches in linux-next for AM33xx boot
(too numerous to list)
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
What works? Well, with this series we now have MMC and SPI support
on AM33xx. The only caveat for MMC is that the mmc3 controller has
its events on the crossbar and is not usable right now.
This is tested on BeagleBone with a SPI framebuffer driver and SD
card.
After this series, the plan is to convert the last in-tree user
of the private EDMA API (davinci-pcm/mcasp) and then eliminate
the private EDMA API by folding its functionality into
drivers/dma/edma.c.
TODO:
add AM33xx crossbar support to the private EDMA API
(any EDMA events on the crossbar are not supported)
Can you please mention the base repo you have taken as starting point.
(repo + extra patches ...).
It's mainline 3.6-rc6 and you can see the complete set of patches
at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2
This will help us to test the code.
This is because I looked at the patch 12/13 and I see that mmc
device-node is modified. But in mainline I don’t see device
node for mmc (yet).
Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and
fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include
in this series. I'll have them in for v2.
Yesterday I tested edma patches on latest linux-next/master + merge of
linux-omap/for_3.7/dts_part2. Below are my observations
1. baseline = linux-next/master + merge of linux-omap/for_3.7/dts_part2
2. on top of above branch, I applied patches [1-9]/13 of your edma
patches
3. few patches required trivial changes before applying
4. Applied dma of patches as you mentioned
5. add custom patch (ARM: CUSTOM: Build a uImage with dtb already
appended)
From https://github.com/hvaibhav/am335x-linux/commit/
7e72f5ed4b702c9373d19f7626f07ae31a381d53#arch/arm/Makefile
Alternatively you can run a current u-boot master build for am335x and
the appended dtb is no longer required.
6. Modified 9/13 patch to apply properly on latest am33xx.dtsi.
a. Edma portion as it is
b. mmc portion as below
mmc1: mmc@4806 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc1;
ti,dual-volt;
ti,needs-special-reset;
bus-width = 4;
vmmc-supply = vmmc_reg;
dmas = edma 24
edma 25;
dma-names = tx, rx;
};
c. added mmc pinmux as-well
7. make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm distclean
make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm
omap2plus_defconfig
8. enabled TI_EDMA from menuconfig (since it was not enabled for
omap2plus_defconfig
9. make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm uImage
make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm
uImage-dtb.am335x-evm
With above changes, edma probe was failing at request_mem_region()
Inside linux-next/arch/arm/common/edma.c -- edma_probe()
I had to modify
Re: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote: Adding Linus W. and lkml. On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote: Hi, With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using pinctrl and that seems to work. On the 3.2 vendor tree there was the omap_mux driver with an awesome debugfs interface: # cat /sys/kernel/debug/omap_mux/lcd_data0 name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3 signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA | pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6 Notice how it tells me that it's muxed the PWM in 2 ways: signal name (ehrpwm2A) and register content (0x0003). Compare to pinctrl: root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 * pinconf-pins:pin 40 (44e108a0): pingroups:pin 40 (44e108a0) pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function pinmux_pruss_led_pins group pinmux_pruss_led_pins pins:pin 40 (44e108a0) pinctrl-single What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in the DT, but debugfs remains mute on how pin 40 is muxed. It does seem like a pretty big gap in the pinctrl/pinmux debugfs interface when viewed from an OMAP perspective. Ideally there would be a pinctrl/pinmux hook to the pinmux driver to provide the detailed h/w specific pin state info. So add the hooks you need? I assume you are using Tony's pinctrl-single driver, so Tony is the one to ask. Yours, Linus Walleij -- 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: Powering OMAP's pins
On Wed, Sep 26, 2012 at 2:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: [Me] You can very well do clocks and regulators in these functions as well. That's not really what I mean. The regulators in question are OMAP version specific, so the driver shouldn't know which regulators are needed. So then it can't be done in generic code atleast, and it becomes a matter for the OMAP driver, I guess you're referring to Tony's pinctrl-single? The regulators for each pin could be passed to the driver from platform data, and the driver could enable the regulators in the runtime resume callback. But then each driver that may use the pins would require the same code and the same platform data to be duplicated. There are many ways to skin this cat I suspect. You could have the pinctrl states also control the regulators (and clocks, and so on..) Or you could layer all notifications orthogonally as described: Other platforms like shmobile will use runtime pm notifications to do all this orthogonally in a central place, which may be applicable for OMAP. What notifications do you refer to? The PM notifiers (PM_RESTORE_PREPARE etc) are global, so they are not of help here. Check drivers/base/power/clock_ops.c for example. What it does is to register notifiers on whenever a device is runtime suspended/resumed and use this to control the clocks. DaVinci, OMAP1 and SH simply registers pm_clk_add_notifier() onto the bus and this takes care of enabling/disabling block clocks. You can do the same for any other resource that should be coupled to the runtime PM states. I was going through the pinctrl code to understand it better. If I read it right, there's a default pin configuration that is set at boot time, and if that configuration needs to be changed later, the drivers use pinctrl_get() pinctrl_select_state() to change it. Basically there are two mutually exclusive usecases: 1. Set the mux+config and be done with it - use hogs and let the pinctrl driver handle everything. No runtime changes can be done from this point. 2. The driver or something else request and manipulate pinctrl handles directly, get/set_state/put, see e.g. drivers/tty/serial/amba-pl011.c Not both at the same time. How I thought that it works (before going through the code) is that at boot time a default pin configuration is set, and for many pins this default config is disabled/safe mode. When a driver, that has been assigned those pins, is loaded and uses pm_runtime_get() to start its hardware, the pins would also be enabled and muxed for the proper operation, without the driver doing any pinctrl calls. And when the driver does pm_runtime_put(), the pins would be disabled and changed to safe-mode. (...) Is there a reason the pin control cannot be automatic as I described above? The pl022 change you linked seems to do the same, but manually. Manually ... there are no men involved in this ;-) But I get what you mean. I don't know if the above can be done, probably the best approach would be to use notifications such as for clocks in OMAP1/DaVinci/SH in that case, create something like drivers/base/power/pin_ops.c and start to hack! I'm all for it if it works for you. However for AMBA drivers like PL011 it won't work because we have systems that has pin control that need to be switched from the driver level but they don't use runtime PM so we can't assume that to always be present. So then we take the default state in probe(), put pins on unused ports into sleep mode and that's it. Then if and only if we also have runtime PM enabled, we will more agressively got to sleep mode pm_runtime_suspend(), as an optimization. If your driver is only used on one system which always selects runtime PM things are easier but we don't have that luxury. Yours, Linus Walleij -- 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: The USB is not working with SM502 Graphics, but working with Intel Pc graphics
On Wed, Sep 26, 2012 at 03:09:03PM +0530, Thirumalesha N wrote: Dear Sir/Madam, I'm testing PMC type SM502 based Graphics card which has usb, audio and display interfaces. I'm using kernel version linux-2.6.21 with redhat enterprise 5.5 OS. As you are testing RHEL, please work with Red Hat for this issue, they are the only ones tha tcan support it, we can't. Especially as you are paying for that support, you might as well use it :) Good luck, greg k-h -- 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
[RFC PATCH 0/3] uio_pruss support for AM33xx
This series enables uio_pruss on AM33xx and it mostly intended to look for the proper solution to handling this particular OMAP hwmod which contains hardware reset lines. The comment in arch/arm/mach-omap2/omap_hwmod.c: /* * If an IP block contains HW reset lines and any of them are * asserted, we let integration code associated with that * block handle the enable. We've received very little * information on what those driver authors need, and until * detailed information is provided and the driver code is * posted to the public lists, this is probably the best we * can do. */ is waiting for some information which is at least partially available with this uio_pruss driver example. The series has some ifdefery to get uio_pruss to build without the DaVinci specific sram API, and then some needed DT, pinctrl, and runtime PM support so I could actually use the driver on AM33xx. The approach to deal with the hardware reset (for at least the pruss hwmod) was to add a generic omap property to properly define this hardware. The implementation simply deasserts any rst lines that are called out in the property when the omap_device is instantiated. This is not the right implementation as the sequence is a bit wrong for pruss since the busy check during the hard reset will fail, even though it fails in a benign manner. Ideally, we would want the implementation to observe the ti,deassert-hard-reset property and use that in omap_hwmod.c:_enable() *after* the module is unidled and the clocks active. However, this is actually functional for purposes of getting the uio_pruss driver up and running. Matt Porter (3): uio: uio_pruss: port to AM33xx ARM: omap: add DT support for deasserting hardware reset lines ARM: dts: AM33xx PRUSS support .../devicetree/bindings/arm/omap/omap.txt |2 + Documentation/devicetree/bindings/uio/pruss.txt| 17 ++ .../devicetree/bindings/uio/uio_pruss.txt | 17 ++ arch/arm/boot/dts/am335x-bone.dts |4 ++ arch/arm/boot/dts/am33xx.dtsi | 11 arch/arm/plat-omap/omap_device.c | 25 +++- drivers/uio/Kconfig|4 +- drivers/uio/uio_pruss.c| 63 +++- 8 files changed, 138 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/uio/pruss.txt create mode 100644 Documentation/devicetree/bindings/uio/uio_pruss.txt -- 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
[RFC PATCH 2/3] ARM: omap: add DT support for deasserting hardware reset lines
This optional binding extension allows specification of a hwmod
and associate hardware reset line which should be deasserted for
the device to be functional.
The implementation works for reference as to the problem that
exists for utilizing uio_pruss on AM33xx but is suboptimal. The
problem is that this deassertion occurs before clocks are enabled
and we are warned that the hard reset failed. Ideally the list of
rst lines requested to be deasserted would be cached and used within
the hwmod enable sequencing (instead of it just returning if any
hardware reset line is asserted).
Signed-off-by: Matt Porter mpor...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |2 ++
arch/arm/plat-omap/omap_device.c | 25 ++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d0051a7..3133a4b 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,8 @@ Required properties:
Optional properties:
- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
+- ti,deassert-hard-reset: list of hwmod and hardware reset line name pairs
+ (ascii strings) to be deasserted upon device instantiation.
Example:
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d5f617c..d1ae68c 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -330,8 +330,8 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
struct omap_device *od;
struct omap_hwmod *oh;
struct device_node *node = pdev-dev.of_node;
- const char *oh_name;
- int oh_cnt, i, ret = 0;
+ const char *oh_name, *rst_name;
+ int oh_cnt, dstr_cnt, i, ret = 0;
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
@@ -376,6 +376,27 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
if (of_get_property(node, ti,no_idle_on_suspend, NULL))
omap_device_disable_idle_on_suspend(pdev);
+ dstr_cnt =
+ of_property_count_strings(node, ti,deassert-hard-reset);
+ if (dstr_cnt 0) {
+ for (i = 0; i dstr_cnt; i += 2) {
+ of_property_read_string_index(
+ node, ti,deassert-hard-reset, i,
+ oh_name);
+ of_property_read_string_index(
+ node, ti,deassert-hard-reset, i+1,
+ rst_name);
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ dev_warn(pdev-dev,
+ Cannot parse deassert property for '%s'\n,
+ oh_name);
+ break;
+ }
+ omap_hwmod_deassert_hardreset(oh, rst_name);
+ }
+ }
+
pdev-dev.pm_domain = omap_device_pm_domain;
odbfd_exit1:
--
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
[RFC PATCH 3/3] ARM: dts: AM33xx PRUSS support
Adds a pruss node and an example of use on Beaglebone.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
arch/arm/boot/dts/am33xx.dtsi | 11 +++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..9e070c2 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,7 @@
};
};
};
+
+pruss {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..399feb3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,16 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ pruss: pruss@4a30 {
+ compatible = ti,pruss-v2;
+ ti,hwmods = pruss;
+ ti,deassert-hard-reset = pruss, pruss;
+ reg = 0x4a30 0x08;
+ ti,pintc-offset = 0x2;
+ interrupt-parent = intc;
+ interrupts = 20 21 22 23 24 25 26 27;
+ status = disabled;
+ };
};
};
--
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
[RFC PATCH 1/3] uio: uio_pruss: port to AM33xx
Add ifdefery hacks to only use SRAM on Davinci. This
needs to be cleaned up with a sane generic SRAM allocator
(like the DT based driver available that can't be used on
Davinci which is just starting DT conversion) before it
can go upstream.
Adds DT, pinctrl, and runtime PM support for use on
AM33xx.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/uio/pruss.txt| 17 ++
.../devicetree/bindings/uio/uio_pruss.txt | 17 ++
drivers/uio/Kconfig|4 +-
drivers/uio/uio_pruss.c| 63 +++-
4 files changed, 98 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/uio/pruss.txt
create mode 100644 Documentation/devicetree/bindings/uio/uio_pruss.txt
diff --git a/Documentation/devicetree/bindings/uio/pruss.txt
b/Documentation/devicetree/bindings/uio/pruss.txt
new file mode 100644
index 000..2ac45c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/pruss.txt
@@ -0,0 +1,17 @@
+TI PRUSS device
+
+Required properties:
+- compatible :
+ - ti,pruss-v1 for AM18xx/OMAP-L138/DA850
+ - ti,pruss-v2 for AM33xx.
+- ti,pintc-offset : Offset of the PINTC from the PRUSS address base
+- ti,hwmods: Name of the hwmod associated to the PRUSS
+
+Example:
+
+pruss: pruss@4a30 {
+ compatible = ti,pruss-v2;
+ ti,hwmods = pruss;
+ reg = 0x4a30 0x08;
+ ti,pintc-offset = 0x2;
+};
diff --git a/Documentation/devicetree/bindings/uio/uio_pruss.txt
b/Documentation/devicetree/bindings/uio/uio_pruss.txt
new file mode 100644
index 000..2ac45c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_pruss.txt
@@ -0,0 +1,17 @@
+TI PRUSS device
+
+Required properties:
+- compatible :
+ - ti,pruss-v1 for AM18xx/OMAP-L138/DA850
+ - ti,pruss-v2 for AM33xx.
+- ti,pintc-offset : Offset of the PINTC from the PRUSS address base
+- ti,hwmods: Name of the hwmod associated to the PRUSS
+
+Example:
+
+pruss: pruss@4a30 {
+ compatible = ti,pruss-v2;
+ ti,hwmods = pruss;
+ reg = 0x4a30 0x08;
+ ti,pintc-offset = 0x2;
+};
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 6f3ea9b..8da7d9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -96,9 +96,9 @@ config UIO_NETX
config UIO_PRUSS
tristate Texas Instruments PRUSS driver
- depends on ARCH_DAVINCI_DA850
+ depends on ARCH_DAVINCI_DA850 || SOC_AM33XX
help
- PRUSS driver for OMAPL138/DA850/AM18XX devices
+ PRUSS driver for OMAPL138/DA850/AM18XX and AM33XX devices
PRUSS driver requires user space components, examples and user space
driver is available from below SVN repo - you may use anonymous login
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index 33a7a27..326ce40 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -25,7 +25,15 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/slab.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
+#include linux/pm_runtime.h
+
+#ifdef CONFIG_ARCH_DAVINCI_DA850
#include mach/sram.h
+#endif
#define DRV_NAME pruss_uio
#define DRV_VERSION 1.0
@@ -105,8 +113,10 @@ static void pruss_cleanup(struct platform_device *dev,
dma_free_coherent(dev-dev, extram_pool_sz, gdev-ddr_vaddr,
gdev-ddr_paddr);
}
+#ifdef CONFIG_ARCH_DAVINCI_DA850
if (gdev-sram_vaddr)
sram_free(gdev-sram_vaddr, sram_pool_sz);
+#endif
kfree(gdev-info);
clk_put(gdev-pruss_clk);
kfree(gdev);
@@ -117,8 +127,10 @@ static int __devinit pruss_probe(struct platform_device
*dev)
struct uio_info *p;
struct uio_pruss_dev *gdev;
struct resource *regs_prussio;
+ struct resource res;
int ret = -ENODEV, cnt = 0, len;
struct uio_pruss_pdata *pdata = dev-dev.platform_data;
+ struct pinctrl *pinctrl;
gdev = kzalloc(sizeof(struct uio_pruss_dev), GFP_KERNEL);
if (!gdev)
@@ -129,6 +141,7 @@ static int __devinit pruss_probe(struct platform_device
*dev)
kfree(gdev);
return -ENOMEM;
}
+#ifdef CONFIG_ARCH_DAVINCI_DA850
/* Power on PRU in case its not done as part of boot-loader */
gdev-pruss_clk = clk_get(dev-dev, pruss);
if (IS_ERR(gdev-pruss_clk)) {
@@ -140,6 +153,28 @@ static int __devinit pruss_probe(struct platform_device
*dev)
} else {
clk_enable(gdev-pruss_clk);
}
+#endif
+
+ if (dev-dev.of_node) {
+ pm_runtime_enable(dev-dev);
+ ret = pm_runtime_get_sync(dev-dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev-dev, pm_runtime_get_sync() failed\n);
+ return ret;
+ }
+
+ ret =
RE: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS
Hi,
On Tue, Sep 25, 2012 at 2:39 PM, Philippe De Swert
Then maybe it's best to just remove the ifdefs and always provide
generic_interrupt() ?
Anyone against it ?
Providing generic_interrupt seems fine.
Well it seems there are only two drivers that use it omap2430 and
ux500. Maybe we somehow link it to the drivers that need it? (I might
have missed other drivers but it looks like it is just those two)
One way I see is that omap2430 and ux500 implement the isr handler
in platform glue driver and then call the musb_interrupt() as done in
daxxx, amxxx, ti8xxx platforms. Then generic_interrupt can be removed.
So something along those lines? (If this is the right way I will resend as a
real patch)
From deae78e1084749f340ae8b8aaeca51818d5bfc55 Mon Sep 17 00:00:00 2001
From: Philippe De Swert philippe.desw...@jollamobile.com
Date: Wed, 26 Sep 2012 17:00:46 +0300
Subject: [PATCH 1/1] musb: Move generic_interrupt out of the way
Have all musb drivers define their own isr.
Signed-off-by: Philippe De Swert philippe.desw...@jollamobile.com
---
drivers/usb/musb/musb_core.c | 33 ++---
drivers/usb/musb/omap2430.c | 22 ++
drivers/usb/musb/ux500.c | 21 +
3 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..1d5ee34 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1496,35 +1496,6 @@ static int __devinit musb_core_init(u16 musb_type,
struct musb *musb)
return 0;
}
-/*-*/
-
-#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \
- defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500)
-
-static irqreturn_t generic_interrupt(int irq, void *__hci)
-{
- unsigned long flags;
- irqreturn_t retval = IRQ_NONE;
- struct musb *musb = __hci;
-
- spin_lock_irqsave(musb-lock, flags);
-
- musb-int_usb = musb_readb(musb-mregs, MUSB_INTRUSB);
- musb-int_tx = musb_readw(musb-mregs, MUSB_INTRTX);
- musb-int_rx = musb_readw(musb-mregs, MUSB_INTRRX);
-
- if (musb-int_usb || musb-int_tx || musb-int_rx)
- retval = musb_interrupt(musb);
-
- spin_unlock_irqrestore(musb-lock, flags);
-
- return retval;
-}
-
-#else
-#define generic_interrupt NULL
-#endif
-
/*
* handle all the irqs defined by the HDRC core. for now we expect: other
* irq sources (phy, dma, etc) will be handled first, musb-int_* values
@@ -1907,7 +1878,8 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-ops = plat-platform_ops;
/* The musb_platform_init() call:
-* - adjusts musb-mregs and musb-isr if needed,
+* - adjusts musb-mregs if needed
+* - sets the musb-isr
* - may initialize an integrated tranceiver
* - initializes musb-xceiv, usually by otg_get_phy()
* - stops powering VBUS
@@ -1917,7 +1889,6 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
* external/discrete ones in various flavors (twl4030 family,
* isp1504, non-OTG, etc) mostly hooking up through ULPI.
*/
- musb-isr = generic_interrupt;
status = musb_platform_init(musb);
if (status 0)
goto fail1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..5461619d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -306,6 +306,26 @@ static void omap_musb_mailbox_work(struct work_struct
*mailbox_work)
omap_musb_set_mailbox(glue);
}
+static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
+{
+unsigned long flags;
+irqreturn_t retval = IRQ_NONE;
+struct musb *musb = __hci;
+
+spin_lock_irqsave(musb-lock, flags);
+
+musb-int_usb = musb_readb(musb-mregs, MUSB_INTRUSB);
+musb-int_tx = musb_readw(musb-mregs, MUSB_INTRTX);
+musb-int_rx = musb_readw(musb-mregs, MUSB_INTRRX);
+
+if (musb-int_usb || musb-int_tx || musb-int_rx)
+retval = musb_interrupt(musb);
+
+spin_unlock_irqrestore(musb-lock, flags);
+
+return retval;
+}
+
static int omap2430_musb_init(struct musb *musb)
{
u32 l;
@@ -325,6 +345,8 @@ static int omap2430_musb_init(struct musb *musb)
return -ENODEV;
}
+ musb-isr = omap2430_musb_interrupt;
+
status = pm_runtime_get_sync(dev);
if (status 0) {
dev_err(dev, pm_runtime_get_sync FAILED %d\n, status);
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index a8c0fad..ec9aaec 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -36,6 +36,26 @@ struct ux500_glue {
};
#define glue_to_musb(g)
Re: [PATCH V2 0/2] OMAPDSS: Enable dynamic debug printing
Hi, On Wed, 2012-09-26 at 10:45 +0530, Chandrabhanu Mahapatra wrote: Hi everyone, this patch series aims at cleaning up of DSS of printk()'s enabled with dss_debug and replace them with generic dynamic debug printing. The 1st patch * replaces printk() in DSSDBG definition with pr_debug() * removes DSSDBGF definition and replaces its instances with DSSDBG() The 2nd patch * cleans up printk()'s in omap_dispc_unregister_isr() and _dsi_print_reset_status() with pr_debug() * removes dss_debug variable Changes with respect to V1: * added debug messages to DSSDBG calls replacing DSSDBGF * added patch OMAPDSS: Remove dss_debug variable All your comments and suggestions are welcome. This doesn't work quite correctly. The problem is in dss.h, where we define DEBUG if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. The thing is, DEBUG should be defined before including the kernel headers where the pr_debug etc are defined. So if you try the patches without dynamic debugging enabled, you won't get any debug outputs at all, even if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. And for dynamic debug, the Kconfig help says: If a source file is compiled with DEBUG flag set, any pr_debug() calls in it are enabled by default, but can be disabled at runtime as below. Note that DEBUG flag is turned on by many CONFIG_*DEBUG* options. So if we have CONFIG_OMAP2_DSS_DEBUG_SUPPORT set, all the pr_debugs should be enabled by default, which is not the case, again because DEBUG is defined too late. I think setting DEBUG in dss.h should be removed, and instead DEBUG should be set in the makefile if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] drivers: phy: add generic PHY framework
The PHY framework provides a set of API's for the PHY drivers to create/destroy a PHY and API's for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has describes the PHY (label, type etc..) and ops like init, exit, suspend, resume, poweron, shutdown. Cc: Felipe Balbi ba...@ti.com Cc: Marc Kleine-Budde m...@pengutronix.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Did testing (phandle path) to some extent by hacking omap-usb2 to use this new framework. (completely modifying omap-usb2 to use this framework will take some time mostly because of the OTG stuff). Also perfomed non-dt testing by moving to a older kernel. Any kind of testing for this patch is welcome :-) MAINTAINERS |7 + drivers/Kconfig |2 + drivers/Makefile|2 + drivers/phy/Kconfig | 13 ++ drivers/phy/Makefile|5 + drivers/phy/phy-core.c | 445 +++ include/linux/phy/phy.h | 182 +++ 7 files changed, 656 insertions(+) create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/MAINTAINERS b/MAINTAINERS index ea0519a..48f3cfb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3078,6 +3078,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git S: Maintained F: include/asm-generic +GENERIC PHY FRAMEWORK +M: Kishon Vijay Abraham I kis...@ti.com +L: linux-ker...@vger.kernel.org +S: Supported +F: drivers/phy/ +F: include/linux/phy/ + GENERIC UIO DRIVER FOR PCI DEVICES M: Michael S. Tsirkin m...@redhat.com L: k...@vger.kernel.org diff --git a/drivers/Kconfig b/drivers/Kconfig index 324e958..d289df5 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -154,4 +154,6 @@ source drivers/vme/Kconfig source drivers/pwm/Kconfig +source drivers/phy/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index d64a0f7..e39252d 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -40,6 +40,8 @@ obj-y += char/ # gpu/ comes after char for AGP vs DRM startup obj-y += gpu/ +obj-y += phy/ + obj-$(CONFIG_CONNECTOR)+= connector/ # i810fb and intelfb depend on char/agp/ diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig new file mode 100644 index 000..34f7077 --- /dev/null +++ b/drivers/phy/Kconfig @@ -0,0 +1,13 @@ +# +# PHY +# + +menuconfig GENERIC_PHY + tristate Generic PHY Support + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile new file mode 100644 index 000..9e9560f --- /dev/null +++ b/drivers/phy/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the phy drivers. +# + +obj-$(CONFIG_GENERIC_PHY) += phy-core.o diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c new file mode 100644 index 000..bf47a88 --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,445 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2012 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/kernel.h +#include linux/export.h +#include linux/module.h +#include linux/err.h +#include linux/device.h +#include linux/slab.h +#include linux/of.h +#include linux/phy/phy.h + +static struct class *phy_class; +static LIST_HEAD(phy_list); +static DEFINE_MUTEX(phy_list_mutex); +static LIST_HEAD(phy_bind_list); + +static void devm_phy_release(struct device *dev, void *res)
Re: [PATCH V2 0/7] ARM: OMAP2+: Add device-tree support for timers
Hi All, I appear to be having problems receiving emails being sent to me by the mailing lists. I did not receive any of the responses to this patch set, but I know see online that there have been a few responses. So sorry for not responding. I have been complaining to our IT department but all they tell me is that they see no issues on their side and it is a problem with the mailing list. I find it hard to believe that I am subscribe to all 3 mailing lists in CC and I don't get a single copy of any response. I will complain again. If anyone has any way I can prove it is a problem on the TI side please let me know. Thanks Jon -- 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 7/7] ARM: OMAP: Add DT support for timer driver
Hi Rob, On 09/13/2012 06:31 PM, Jon Hunter wrote: In order to add device-tree support to the timer driver the following changes were made ... 1. Allocate system timers (used for clock-events and clock-source) based upon timer properties rather than using an hard-coded timer instance ID. To allow this a new helper function called omap_dmtimer_find_by_property() has been added for finding a timer with the particular properties in the device-tree blob. Please note that this is an internal helper function for system timers only to find a timer in the device-tree blob. This cannot be used by device drivers, another API has been added for that (see below). Timers that are allocated for system timers are dynamically disabled at boot time by adding a status property with the value disabled to the timer's device-tree node. Please note that when allocating system timers we now pass a timer ID and timer property. The timer ID is only be used for allocating a timer when booting without device-tree. Once device-tree migration is complete, all the timer ID references will be removed. 2. If DT blob is present, then let device-tree create the timer devices dynamically. 3. When device-tree is present the id field in the platform_device structure (pdev-id) is initialised to -1 and hence cannot be used to identify a timer instance. Due to this the following changes were made ... a). The API omap_dm_timer_request_specific() is not supported when using device-tree, because it uses the device ID to request a specific timer. This function will return an error if called when device-tree is present. Users of this API should use omap_dm_timer_request_by_cap() instead. b). When removing the DMTIMER driver, the timer id was used to identify the timer instance. The remove function has been modified to use the device name instead of the id. 4. When device-tree is present the platform_data structure will be NULL and so check for this. 5. The OMAP timer device tree binding has the following optional parameters ... a). ti,timer-alwon -- Timer is in an always-on power domain b). ti,timer-dsp-- Timer can generate an interrupt to the on-chip DSP c). ti,timer-pwm-- Timer can generate a PWM output d). ti,timer-secure -- Timer is reserved on a secure OMAP device Search for the above parameters and set the appropriate timer attribute flags. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/timer.c | 96 +- arch/arm/plat-omap/dmtimer.c | 41 +++--- 2 files changed, 112 insertions(+), 25 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 60d43c8..d1c7771 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -58,16 +58,20 @@ #define OMAP3_32K_SOURCE omap_32k_fck #define OMAP4_32K_SOURCE sys_32k_ck +#define TIMER_PROP_ALWON ti,timer-alwon + I see you made the following comment [1] here ... It would be easier to follow the code if you use the strings directly (and you do in some places). I could avoid the above definition. #ifdef CONFIG_OMAP_32K_TIMER #define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE #define OMAP3_SECURE_TIMER 12 +#define TIMER_PROP_SECUREti,timer-secure #else #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE #define OMAP3_SECURE_TIMER 1 +#define TIMER_PROP_SECURETIMER_PROP_ALWON #endif Are you ok, with having the TIMER_PROP_SECURE definition or would you prefer I handle this differently? This is dependent on the kernel config. Cheers Jon [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/84458/focus=84982 -- 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 7/7] ARM: OMAP: Add DT support for timer driver
On 09/26/2012 10:51 AM, Jon Hunter wrote: Hi Rob, #define OMAP3_32K_SOURCEomap_32k_fck #define OMAP4_32K_SOURCEsys_32k_ck +#define TIMER_PROP_ALWONti,timer-alwon + I see you made the following comment [1] here ... It would be easier to follow the code if you use the strings directly (and you do in some places). I could avoid the above definition. #ifdef CONFIG_OMAP_32K_TIMER #define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE #define OMAP3_SECURE_TIMER 12 +#define TIMER_PROP_SECURE ti,timer-secure #else #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE #define OMAP3_SECURE_TIMER 1 +#define TIMER_PROP_SECURE TIMER_PROP_ALWON #endif Are you ok, with having the TIMER_PROP_SECURE definition or would you prefer I handle this differently? This is dependent on the kernel config.\ Yes, that's fine. Rob Cheers Jon [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/84458/focus=84982 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
On Wed, Sep 26, 2012 at 03:03:27PM +0200, Linus Walleij wrote:
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote:
Adding Linus W. and lkml.
On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote:
Hi,
With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using
pinctrl and that seems to work. On the 3.2 vendor tree there was the
omap_mux driver with an awesome debugfs interface:
# cat /sys/kernel/debug/omap_mux/lcd_data0
name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA |
pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6
Notice how it tells me that it's muxed the PWM in 2 ways: signal name
(ehrpwm2A) and register content (0x0003). Compare to pinctrl:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 *
pinconf-pins:pin 40 (44e108a0):
pingroups:pin 40 (44e108a0)
pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function
pinmux_pruss_led_pins group pinmux_pruss_led_pins
pins:pin 40 (44e108a0) pinctrl-single
What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in
the DT, but debugfs remains mute on how pin 40 is muxed.
It does seem like a pretty big gap in the pinctrl/pinmux debugfs
interface when viewed from an OMAP perspective. Ideally there would
be a pinctrl/pinmux hook to the pinmux driver to provide the detailed
h/w specific pin state info.
So add the hooks you need?
Ok. :)
I assume you are using Tony's pinctrl-single driver, so Tony is the one to
ask.
Yes, so roughly for pinctrl-single I have the following...likely broken
for arbitrary register sizes but a starting point. Tony, any thoughts
about this?
Koen: you just need a userspace tool that groks the raw data for human
consumption. The nice thing is that the old omap_mux implementation had
plenty of OMAP-isms in the parser that didn't apply to AM33xx. A
userspace tool can do a better job of parsing on a per-part basis.
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -246,7 +246,15 @@ static void pcs_pin_dbg_show(struct pinctrl_dev *pctldev,
struct seq_file *s,
unsigned offset)
{
- seq_printf(s, DRIVER_NAME);
+ struct pcs_device *pcs;
+ unsigned val;
+
+ pcs = pinctrl_dev_get_drvdata(pctldev);
+
+ val = pcs-read(pcs-base + offset);
+ val = pcs-fmask;
+
+ seq_printf(s, %08x %s , val, DRIVER_NAME);
}
static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
--
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] arm/omap: Replace board_ref_clock with enum values
Use the enum for board_ref_clock from linux/wl12xx.h
Signed-off-by: Vikram Narayanan vikram...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
---
I'm not subscribed to the list. So please keep me in Cc for the replies.
arch/arm/mach-omap2/board-omap4panda.c |3 +--
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 70f6d1d..e188765 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -248,8 +248,7 @@ static struct platform_device omap_vwlan_device = {
};
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
- /* PANDA ref clock is 38.4 MHz */
- .board_ref_clock = 2,
+ .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
};
static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index b797cb2..499dca7 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -193,8 +193,7 @@ static struct platform_device omap_vwlan_device = {
};
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
- /* ZOOM ref clock is 26 MHz */
- .board_ref_clock = 1,
+ .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
};
static struct omap2_hsmmc_info mmc[] = {
--
1.7.4.1
--
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 0/7] ARM: OMAP2+: Add device-tree support for timers
On 09/20/2012 06:53 PM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [120919 19:24]: Hi Tony, I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7. I suggest that you do a separate branch on top of Paul's hwmod series when he posts those if that works for you? Benoit, I see that you have pulled in the DTS patch. Do you guys want me to rebase the remaining patches with Rob's change on Tony's master branch and re-submit? Cheers Jon -- 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] drivers: phy: add generic PHY framework
On Wed, 2012-09-26 at 20:31 +0530, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of API's for the PHY drivers to
create/destroy a PHY and API's
Just some trivial notes.
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
[]
@@ -0,0 +1,445 @@
[]
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
That's a bit twisted isn't it?
Perhaps
struct phy *phy = res;
[]
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+ return res == match_data;
static bool devm_phy_match(etc...)
[]
+struct phy *devm_of_phy_get(struct device *dev, const char *phandle, u8
index)
+{
+ struct phy *phy = NULL, **ptr;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
Is this the right size?
Because ptr is **, perhaps sizeof(struct phy) is clearer.
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
alloc failures generally don't need specific OOM messages
as the general alloc OOM dumps stack.
+ return ERR_PTR(-ENOMEM);
+ }
+
+ mutex_lock(phy_list_mutex);
+
+ phy = of_phy_lookup(dev, node);
+ if (IS_ERR(phy) || !phy-dev.class ||
+ !try_module_get(phy-dev.class-owner)) {
I think it's tasteful coding style to align like:
if (IS_ERR(phy) || !phy-dev.class ||
!try_module_get(phy-dev.class-owner)) {
[]
+struct phy *phy_create(struct device *dev, struct phy_descriptor *desc)
+{
+ int ret;
+ struct phy *phy;
+ struct phy_bind *phy_bind;
+ const char *devname = NULL;
+
+ if (!dev || !desc) {
+ dev_err(dev, no descriptor/device provided for PHY\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ if (!desc-ops) {
+ dev_err(dev, no PHY ops provided\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ dev_err(dev, no memory for PHY\n);
No OOM message required...
[]
+static int __init phy_core_init(void)
+{
+ phy_class = class_create(THIS_MODULE, phy);
+ if (IS_ERR(phy_class)) {
+ pr_err(failed to create phy class -- %ld\n,
+ PTR_ERR(phy_class));
You might add #define pr_fmt(fmt) KBUILD_MODNAME : fmt
before any include so that pr_levels are prefixed.
cheers, Joe
--
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] drivers: phy: add generic PHY framework
On Wed, Sep 26, 2012 at 08:31:15PM +0530, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/destroy a PHY and API's for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has describes the PHY (label, type etc..) and ops like init, exit, suspend, resume, poweron, shutdown. Do you have an example driver that uses this new framework? How does it look in sysfs? You need to add Documentation/ABI/ entries for the sysfs files you created as well. greg k-h -- 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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Op 26 sep. 2012, om 18:15 heeft Matt Porter mpor...@ti.com het volgende
geschreven:
On Wed, Sep 26, 2012 at 03:03:27PM +0200, Linus Walleij wrote:
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote:
Adding Linus W. and lkml.
On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote:
Hi,
With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins using
pinctrl and that seems to work. On the 3.2 vendor tree there was the
omap_mux driver with an awesome debugfs interface:
# cat /sys/kernel/debug/omap_mux/lcd_data0
name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA |
pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6
Notice how it tells me that it's muxed the PWM in 2 ways: signal name
(ehrpwm2A) and register content (0x0003). Compare to pinctrl:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 *
pinconf-pins:pin 40 (44e108a0):
pingroups:pin 40 (44e108a0)
pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function
pinmux_pruss_led_pins group pinmux_pruss_led_pins
pins:pin 40 (44e108a0) pinctrl-single
What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in
the DT, but debugfs remains mute on how pin 40 is muxed.
It does seem like a pretty big gap in the pinctrl/pinmux debugfs
interface when viewed from an OMAP perspective. Ideally there would
be a pinctrl/pinmux hook to the pinmux driver to provide the detailed
h/w specific pin state info.
So add the hooks you need?
Ok. :)
I assume you are using Tony's pinctrl-single driver, so Tony is the one to
ask.
Yes, so roughly for pinctrl-single I have the following...likely broken
for arbitrary register sizes but a starting point. Tony, any thoughts
about this?
Koen: you just need a userspace tool that groks the raw data for human
consumption. The nice thing is that the old omap_mux implementation had
plenty of OMAP-isms in the parser that didn't apply to AM33xx. A
userspace tool can do a better job of parsing on a per-part basis.
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -246,7 +246,15 @@ static void pcs_pin_dbg_show(struct pinctrl_dev *pctldev,
struct seq_file *s,
unsigned offset)
{
- seq_printf(s, DRIVER_NAME);
+ struct pcs_device *pcs;
+ unsigned val;
+
+ pcs = pinctrl_dev_get_drvdata(pctldev);
+
+ val = pcs-read(pcs-base + offset);
+ val = pcs-fmask;
+
+ seq_printf(s, %08x %s , val, DRIVER_NAME);
}
static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
Much better already:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 pins
pin 40 (44e108a0) 0027 pinctrl-single
Now I can write a userspace tool do list the current muxes without resorting to
devmem2!
--
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] drivers: phy: add generic PHY framework
On Wednesday, September 26, 2012 09:57:57 AM Joe Perches wrote:
On Wed, 2012-09-26 at 20:31 +0530, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of API's for the PHY drivers to
create/destroy a PHY and API's
Just some trivial notes.
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
[]
@@ -0,0 +1,445 @@
[]
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
That's a bit twisted isn't it?
Perhaps
struct phy *phy = res;
No, because you really need to dereference ptr, not simply cast.
...
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
Is this the right size?
Because ptr is **, perhaps sizeof(struct phy) is clearer.
But incorrect.
Thanks.
--
Dmitry
--
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] drivers: phy: add generic PHY framework
On 09/26/2012 07:41 PM, Dmitry Torokhov wrote:
On Wednesday, September 26, 2012 09:57:57 AM Joe Perches wrote:
On Wed, 2012-09-26 at 20:31 +0530, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of API's for the PHY drivers to
create/destroy a PHY and API's
Just some trivial notes.
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
[]
@@ -0,0 +1,445 @@
[]
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
That's a bit twisted isn't it?
Perhaps
struct phy *phy = res;
No, because you really need to dereference ptr, not simply cast.
To avoid this confusion I suggest to create a struct phy_res. For now
its only member will be a pointer to a struct phy.
...
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
Is this the right size?
Because ptr is **, perhaps sizeof(struct phy) is clearer.
But incorrect.
A proper struct will make the code more readable here, too.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
Hi,
On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev,
usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
This clock is needed for usb2 to work in dwc3 (omap5). So we have to
report the error in case we dont get the clock no?
sure, but you don't need to bail out. Print a warning message such as:
dev_dbg(pdev-dev, couldn't get refclk960m, trying without\n);
or something similar. Then you don't need to add this has960mhzclk flag
to dts files.
--
balbi
signature.asc
Description: Digital signature
[PATCH 1/1] ARM: Add option to configure output line for McSPI driver
McSPI driver previously assumed that D0 was input (MISO) and D1 was output
(MOSI).
This forces the hardware designer to wire all SPI peripherals in this way when
it should be a software configuration option.
Signed-off-by: Stan Hu sta...@gmail.com
---
arch/arm/plat-omap/include/plat/mcspi.h |2 ++
drivers/spi/spi-omap2-mcspi.c | 11 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index a357eb2..0a6b790 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -18,6 +18,8 @@ struct omap2_mcspi_dev_attr {
struct omap2_mcspi_device_config {
unsigned turbo_mode:1;
+ /* 1 - [D0 = MOSI, D1 = MISO], otherwise vice versa */
+ unsigned d0_is_output:1;
};
#endif
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..1853527 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -717,6 +717,7 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
struct spi_transfer *t)
{
struct omap2_mcspi_cs *cs = spi-controller_state;
+ struct omap2_mcspi_device_config *cd = spi-controller_data;
struct omap2_mcspi *mcspi;
struct spi_master *spi_cntrl;
u32 l = 0, div = 0;
@@ -742,8 +743,14 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- l = ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
- l |= OMAP2_MCSPI_CHCONF_DPE0;
+ l = ~(OMAP2_MCSPI_CHCONF_IS|
+ OMAP2_MCSPI_CHCONF_DPE0|OMAP2_MCSPI_CHCONF_DPE1);
+
+ /* set input selection for D0 and D1 */
+ if (cd-d0_is_output)
+ l |= OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1;
+ else
+ l |= OMAP2_MCSPI_CHCONF_DPE0;
/* wordlength */
l = ~OMAP2_MCSPI_CHCONF_WL_MASK;
--
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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
* Koen Kooi k...@dominion.thruhere.net [120926 10:23]:
Op 26 sep. 2012, om 18:15 heeft Matt Porter mpor...@ti.com het volgende
geschreven:
On Wed, Sep 26, 2012 at 03:03:27PM +0200, Linus Walleij wrote:
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote:
Adding Linus W. and lkml.
On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote:
Hi,
With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins
using pinctrl and that seems to work. On the 3.2 vendor tree there was
the omap_mux driver with an awesome debugfs interface:
# cat /sys/kernel/debug/omap_mux/lcd_data0
name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA |
pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6
Notice how it tells me that it's muxed the PWM in 2 ways: signal name
(ehrpwm2A) and register content (0x0003). Compare to pinctrl:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 *
pinconf-pins:pin 40 (44e108a0):
pingroups:pin 40 (44e108a0)
pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function
pinmux_pruss_led_pins group pinmux_pruss_led_pins
pins:pin 40 (44e108a0) pinctrl-single
What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in
the DT, but debugfs remains mute on how pin 40 is muxed.
It does seem like a pretty big gap in the pinctrl/pinmux debugfs
interface when viewed from an OMAP perspective. Ideally there would
be a pinctrl/pinmux hook to the pinmux driver to provide the detailed
h/w specific pin state info.
So add the hooks you need?
Ok. :)
I assume you are using Tony's pinctrl-single driver, so Tony is the one to
ask.
Yes, so roughly for pinctrl-single I have the following...likely broken
for arbitrary register sizes but a starting point. Tony, any thoughts
about this?
Koen: you just need a userspace tool that groks the raw data for human
consumption. The nice thing is that the old omap_mux implementation had
plenty of OMAP-isms in the parser that didn't apply to AM33xx. A
userspace tool can do a better job of parsing on a per-part basis.
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -246,7 +246,15 @@ static void pcs_pin_dbg_show(struct pinctrl_dev
*pctldev,
struct seq_file *s,
unsigned offset)
{
- seq_printf(s, DRIVER_NAME);
+ struct pcs_device *pcs;
+ unsigned val;
+
+ pcs = pinctrl_dev_get_drvdata(pctldev);
+
+ val = pcs-read(pcs-base + offset);
+ val = pcs-fmask;
+
+ seq_printf(s, %08x %s , val, DRIVER_NAME);
}
static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
Much better already:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 pins
pin 40 (44e108a0) 0027 pinctrl-single
Cool :) For the proper patch feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
Now I can write a userspace tool do list the current muxes without resorting
to devmem2!
Yeah maybe add support to omapconf for that? I can generate
the data for balls etc from old omap mux if you let me know the
format you need.
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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
Op 26 sep. 2012, om 20:52 heeft Tony Lindgren t...@atomide.com het volgende
geschreven:
* Koen Kooi k...@dominion.thruhere.net [120926 10:23]:
Op 26 sep. 2012, om 18:15 heeft Matt Porter mpor...@ti.com het volgende
geschreven:
On Wed, Sep 26, 2012 at 03:03:27PM +0200, Linus Walleij wrote:
On Wed, Sep 26, 2012 at 2:56 PM, Matt Porter mpor...@ti.com wrote:
Adding Linus W. and lkml.
On Wed, Sep 26, 2012 at 01:46:45PM +0200, Koen Kooi wrote:
Hi,
With a patched 3.6rc7 on my beaglebone I can set the pinmux for pins
using pinctrl and that seems to work. On the 3.2 vendor tree there was
the omap_mux driver with an awesome debugfs interface:
# cat /sys/kernel/debug/omap_mux/lcd_data0
name: lcd_data0.ehrpwm2A (0x44e108a0/0x8a0 = 0x0003), b NA, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE3
signals: lcd_data0 | gpmc_a0 | pr1_mii_mt0_clk | ehrpwm2A | NA |
pr1_pru1_pru_r30_0 | pr1_pru1_pru_r31_0 | gpio2_6
Notice how it tells me that it's muxed the PWM in 2 ways: signal name
(ehrpwm2A) and register content (0x0003). Compare to pinctrl:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 *
pinconf-pins:pin 40 (44e108a0):
pingroups:pin 40 (44e108a0)
pinmux-pins:pin 40 (44e108a0): 4a30.pruss (GPIO UNCLAIMED) function
pinmux_pruss_led_pins group pinmux_pruss_led_pins
pins:pin 40 (44e108a0) pinctrl-single
What is that pin muxed to? It is part of the 'pinmux_pruss_led_pins' in
the DT, but debugfs remains mute on how pin 40 is muxed.
It does seem like a pretty big gap in the pinctrl/pinmux debugfs
interface when viewed from an OMAP perspective. Ideally there would
be a pinctrl/pinmux hook to the pinmux driver to provide the detailed
h/w specific pin state info.
So add the hooks you need?
Ok. :)
I assume you are using Tony's pinctrl-single driver, so Tony is the one to
ask.
Yes, so roughly for pinctrl-single I have the following...likely broken
for arbitrary register sizes but a starting point. Tony, any thoughts
about this?
Koen: you just need a userspace tool that groks the raw data for human
consumption. The nice thing is that the old omap_mux implementation had
plenty of OMAP-isms in the parser that didn't apply to AM33xx. A
userspace tool can do a better job of parsing on a per-part basis.
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -246,7 +246,15 @@ static void pcs_pin_dbg_show(struct pinctrl_dev
*pctldev,
struct seq_file *s,
unsigned offset)
{
- seq_printf(s, DRIVER_NAME);
+ struct pcs_device *pcs;
+ unsigned val;
+
+ pcs = pinctrl_dev_get_drvdata(pctldev);
+
+ val = pcs-read(pcs-base + offset);
+ val = pcs-fmask;
+
+ seq_printf(s, %08x %s , val, DRIVER_NAME);
}
static void pcs_dt_free_map(struct pinctrl_dev *pctldev,
Much better already:
root@bone-mainline:/sys/kernel/debug/pinctrl/44e10800.pinmux# grep 8a0 pins
pin 40 (44e108a0) 0027 pinctrl-single
Cool :) For the proper patch feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
Now I can write a userspace tool do list the current muxes without resorting
to devmem2!
Yeah maybe add support to omapconf for that? I can generate
the data for balls etc from old omap mux if you let me know the
format you need.
It's for am335x :)--
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: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [120926 00:06]: On Tue, 2012-09-25 at 12:07 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120925 10:06]: On Tue, 2012-09-25 at 08:38 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120925 03:22]: Hi Tony, Each pin of OMAP requires a particular power to be enabled for the pin to function (Ball Characteristics table from data manual). Is there a plan how this is managed with pinctrl? Currently each driver needs to make sure the correct regulators are enabled for the pins it uses, which is platform specific and messy. As a driver maintainer, I would wish that the pins would just get enabled automatically when I call pm_runtime_get()... Hmm can you clarify a bit what exactly do you want to do there with pm_runtime_get()? Call the regulator framework? Well, I'm not very familiar with pinctrl, but if I've understood right, a set of pins are assigned to a driver in DT data (or wherever, that's not relevant). Those pins should be automatically configured and enabled when the driver uses pm_runtime_get() to enable its hardware. And if I've also understood right, the pinctrl discussions related to omap have only dealt with pin muxing itself. But that's not enough to get the pin functional, but the relevant regulator needs to be enabled also. So when I call pm_runtime_get in the omapdss driver, I imagine that the runtime PM and pinctrl would together handle muxing the pins for omapdss's use, and also enable the relevant regulators to make the pins usable. But aren't these regulators something that potentially are dynamically configured by the driver? For example, vdds_(sd)mmc1 depends on which card is plugged in. Ah, ok. Are there other cases than mmc where the voltage(?) needs to be dynamically configured? Seems VSIM too and possibly some USB pins if you search for PBIAS in the 44xx TRM. So to me it seesm that it's best to define the regulators and claim them by the driver using them rather than try to use automatically. It's Well, in mmc case it sounds it's the driver's job. Perhaps the DSS pins are special cases, then. I don't see any dynamic configuration needed there. Sometimes the regulator for the pins is implicitly enabled as it's needed by a DSS component. For example when using DSI pins, the vdda_dsi used by the pins is already enabled as it's used for the DSI itself, so the pins just happen to work. OK But then the same pins that are used for DSI can be used for other things. On omap3430 DSI's dx0 pin can also be muxed to dss_data0, uart1_cts, gpio_70. Of these, I'm mainly interested in the dss_data0, of course. So if I want to use parallel dss output, which uses dss_data0 pin, omapdss driver needs to enable vdda_dsi on omap3430, even though there's no other use for vdda_dsi in the parallel output case. But on omap4430 data0 pins seems to be powered by vdds_1p8v. On AM35xx something else. So either I need to program all those into the omapdss driver, which is not the right way as they are platform specific things, or I need to pass some kind of pin data from platform data to omapdss driver, giving the required regulator for each pin. Pass the device tree regulators to the DSS driver and enable the ones with runtime PM in the DSS driver? I guess you have the names for those regulatros? And how about the uart1_cts or gpio_70 pins on 3430? Do both uart and gpio drivers need to have similar kind of platform data, giving the required regulator so that the pin can be enabled? Hmm aren't those always enabled with VIO_18? sort of the same situation as with GPIO pins? How are the GPIO pins handled? They have this kind of pin-regulator mapping? There's some support documented under Documentation, but in many cases the usage is drivers specific, like enabling GPIO wake-up event for RX pin only etc. 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: Powering OMAP's pins
* Linus Walleij linus.wall...@linaro.org [120926 06:28]: On Wed, Sep 26, 2012 at 2:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: [Me] You can very well do clocks and regulators in these functions as well. That's not really what I mean. The regulators in question are OMAP version specific, so the driver shouldn't know which regulators are needed. So then it can't be done in generic code atleast, and it becomes a matter for the OMAP driver, I guess you're referring to Tony's pinctrl-single? Yes the pins are muxed with pinctrl-single. Then for the SoC specific regulator handling I suggest you use regulator names that make sense from the driver point of view that can be mapped in SoC specific way in the .dts files. If you need SoC specific more complicated handling, you may want to have SoC specific glue driver to the DSS core driver, like dss-44xx.c etc. Then you can select the appropriate glue layer based on the compatible flag. 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: replacement for /sys/kernel/debug/omap_mux in DT/pinctrl land ?
* Koen Kooi k...@dominion.thruhere.net [120926 11:54]: It's for am335x :) Ah OK we don't have that data in the kernel then. But if you have some format in mind suitable I can still generate the other omap+package+mode data for you. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: phy: add generic PHY framework
On 09/26/2012 05:01 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/destroy a PHY and API's for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has describes the PHY (label, type etc..) and ops like init, exit, suspend, resume, poweron, shutdown. Cc: Felipe Balbi ba...@ti.com Cc: Marc Kleine-Budde m...@pengutronix.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I suggest to talk to someone who is familiar with the linux-bus abstraction. Adding devices, drivers, matching them and maintaining binding information should not be reinvented. See more comments inline. --- Did testing (phandle path) to some extent by hacking omap-usb2 to use this new framework. (completely modifying omap-usb2 to use this framework will take some time mostly because of the OTG stuff). Also perfomed non-dt testing by moving to a older kernel. Any kind of testing for this patch is welcome :-) MAINTAINERS |7 + drivers/Kconfig |2 + drivers/Makefile|2 + drivers/phy/Kconfig | 13 ++ drivers/phy/Makefile|5 + drivers/phy/phy-core.c | 445 +++ include/linux/phy/phy.h | 182 +++ 7 files changed, 656 insertions(+) create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/MAINTAINERS b/MAINTAINERS index ea0519a..48f3cfb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3078,6 +3078,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git S: Maintained F: include/asm-generic +GENERIC PHY FRAMEWORK +M: Kishon Vijay Abraham I kis...@ti.com +L: linux-ker...@vger.kernel.org +S: Supported +F: drivers/phy/ +F: include/linux/phy/ + GENERIC UIO DRIVER FOR PCI DEVICES M: Michael S. Tsirkin m...@redhat.com L: k...@vger.kernel.org diff --git a/drivers/Kconfig b/drivers/Kconfig index 324e958..d289df5 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -154,4 +154,6 @@ source drivers/vme/Kconfig source drivers/pwm/Kconfig +source drivers/phy/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index d64a0f7..e39252d 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -40,6 +40,8 @@ obj-y += char/ # gpu/ comes after char for AGP vs DRM startup obj-y+= gpu/ +obj-y+= phy/ + obj-$(CONFIG_CONNECTOR) += connector/ # i810fb and intelfb depend on char/agp/ diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig new file mode 100644 index 000..34f7077 --- /dev/null +++ b/drivers/phy/Kconfig @@ -0,0 +1,13 @@ +# +# PHY +# + +menuconfig GENERIC_PHY + tristate Generic PHY Support + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile new file mode 100644 index 000..9e9560f --- /dev/null +++ b/drivers/phy/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the phy drivers. +# + +obj-$(CONFIG_GENERIC_PHY)+= phy-core.o diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c new file mode 100644 index 000..bf47a88 --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,445 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2012 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#include
Re: [PATCH v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Mon, Sep 17, 2012 at 12:53:18PM +0530, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. None of these patches apply to any tree that I know of, what did you do them against? Please redo them against the char-next branch of linux-next and resend them if you wish to see them applied. thanks, greg k-h -- 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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote: Hi Greg, Ping on this? It was a RFT patch, with a huge thread. What's the resolution here? Did people figure out the real problem here or not? If so, care to resend the proper patch so I know what to apply? thanks, greg k-h -- 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 v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Wed, 26 Sep 2012 13:24:00 -0700 Greg KH gre...@linuxfoundation.org wrote: On Mon, Sep 17, 2012 at 12:53:18PM +0530, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. None of these patches apply to any tree that I know of, what did you do them against? Please redo them against the char-next branch of linux-next and resend them if you wish to see them applied. Presumably they're against eariler patches whcih you don't have. I'm presently sitting on drivers-misc-lis3lv02d-add-generic-dt-matching-code.patch drivers-misc-lis3lv02d-add-generic-dt-matching-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix-fix.patch drivers-misc-lis3lv02d-remove-lis3lv02d-driver-dt-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-fix-some-comments-specific-to-lis331dlh-driver.patch -- 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 v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Wed, Sep 26, 2012 at 01:34:50PM -0700, Andrew Morton wrote: On Wed, 26 Sep 2012 13:24:00 -0700 Greg KH gre...@linuxfoundation.org wrote: On Mon, Sep 17, 2012 at 12:53:18PM +0530, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. None of these patches apply to any tree that I know of, what did you do them against? Please redo them against the char-next branch of linux-next and resend them if you wish to see them applied. Presumably they're against eariler patches whcih you don't have. I'm presently sitting on drivers-misc-lis3lv02d-add-generic-dt-matching-code.patch drivers-misc-lis3lv02d-add-generic-dt-matching-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix-fix.patch drivers-misc-lis3lv02d-remove-lis3lv02d-driver-dt-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-fix-some-comments-specific-to-lis331dlh-driver.patch Care to send them to me so that I can get them to Linus for the 3.7 merge window? I do keep the char-misc tree for these types of things :) thanks, greg k-h -- 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 v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Wed, 26 Sep 2012 13:44:03 -0700 Greg KH gre...@linuxfoundation.org wrote: On Wed, Sep 26, 2012 at 01:34:50PM -0700, Andrew Morton wrote: On Wed, 26 Sep 2012 13:24:00 -0700 Greg KH gre...@linuxfoundation.org wrote: On Mon, Sep 17, 2012 at 12:53:18PM +0530, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. None of these patches apply to any tree that I know of, what did you do them against? Please redo them against the char-next branch of linux-next and resend them if you wish to see them applied. Presumably they're against eariler patches whcih you don't have. I'm presently sitting on drivers-misc-lis3lv02d-add-generic-dt-matching-code.patch drivers-misc-lis3lv02d-add-generic-dt-matching-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix-fix.patch drivers-misc-lis3lv02d-remove-lis3lv02d-driver-dt-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-fix-some-comments-specific-to-lis331dlh-driver.patch Care to send them to me so that I can get them to Linus for the 3.7 merge window? OK. I do keep the char-misc tree for these types of things :) I've actually been doing this miscdev driver since day one. I'm happy to hand over the keys but please review the patches carefully and try not to miss stuff! -- 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 v3 0/4] lis3: lis3lv02d_i2c: Add device tree support
On Wed, Sep 26, 2012 at 01:54:12PM -0700, Andrew Morton wrote: On Wed, 26 Sep 2012 13:44:03 -0700 Greg KH gre...@linuxfoundation.org wrote: On Wed, Sep 26, 2012 at 01:34:50PM -0700, Andrew Morton wrote: On Wed, 26 Sep 2012 13:24:00 -0700 Greg KH gre...@linuxfoundation.org wrote: On Mon, Sep 17, 2012 at 12:53:18PM +0530, AnilKumar Ch wrote: Adds device tree support to lis3lv02d_i2c driver. Along with this DT init is moved from core driver to individual drivers, with the current implementation some pdata is missing in lis3lv02d_i2c driver. Also adds platform data for lis331dlh driver to am335x-EVM. These patches were tested on AM335x-EVM. None of these patches apply to any tree that I know of, what did you do them against? Please redo them against the char-next branch of linux-next and resend them if you wish to see them applied. Presumably they're against eariler patches whcih you don't have. I'm presently sitting on drivers-misc-lis3lv02d-add-generic-dt-matching-code.patch drivers-misc-lis3lv02d-add-generic-dt-matching-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-dt-matching-table-passthru-code-fix-fix.patch drivers-misc-lis3lv02d-remove-lis3lv02d-driver-dt-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_spic-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init.patch drivers-misc-lis3lv02d-lis3lv02d_i2cc-add-lis3lv02d-device-tree-init-fix.patch drivers-misc-lis3lv02d-fix-some-comments-specific-to-lis331dlh-driver.patch Care to send them to me so that I can get them to Linus for the 3.7 merge window? OK. I do keep the char-misc tree for these types of things :) I've actually been doing this miscdev driver since day one. I'm happy to hand over the keys but please review the patches carefully and try not to miss stuff! Will do, thanks. greg k-h -- 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/3] uio: uio_pruss: port to AM33xx
On Wed, Sep 26, 2012 at 09:44:29AM -0400, Matt Porter wrote: Add ifdefery hacks to only use SRAM on Davinci. This needs to be cleaned up with a sane generic SRAM allocator (like the DT based driver available that can't be used on Davinci which is just starting DT conversion) before it can go upstream. Adds DT, pinctrl, and runtime PM support for use on AM33xx. Ick, that's really messy, no other way to do this in a cleaner fashion? greg k-h -- 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 v6 0/7] ARM: OMAP2+: PM: introduce the power domains functional states
Hi Jean, On Wed, 12 Sep 2012, Jean Pihet wrote: Here is a re-spin after some comments and suggestions after review and discussions. Thanks Jean, I'll take it from here, probably with some changes which I will respond to the individual patches, probably for 3.8. - Paul -- 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 0/2] OMAP 3 CSI-2 configuration
Hi Paul and Laurent, This is an update to an old patchset for CSI-2 configuration for OMAP 3430 and 3630, and the corresponding patch to the ISP driver. Both have been tested on the 3630 only so far. Additional patches for the N9(50) camera support that mostly aren't yet upstreamable, are available in rm696-016/002-devel branch here: URL:https://git.gitorious.org/omap3camera/mainline.git Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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/2] omap3: Provide means for changing CSI2 PHY configuration
The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to
the actual CSI-2 receivers outside the ISP itself. Allow changing this
configuration from the ISP driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
arch/arm/mach-omap2/control.c | 86
arch/arm/mach-omap2/control.h | 15 +
arch/arm/mach-omap2/include/mach/control.h | 13
3 files changed, 114 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/control.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 3223b81..11bb900 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -12,9 +12,12 @@
*/
#undef DEBUG
+#include linux/export.h
#include linux/kernel.h
#include linux/io.h
+#include mach/control.h
+
#include plat/hardware.h
#include plat/sdrc.h
@@ -607,4 +610,87 @@ int omap3_ctrl_save_padconf(void)
return 0;
}
+static int omap3630_ctrl_csi2_phy_cfg(u32 phy, u32 flags)
+{
+ u32 cam_phy_ctrl =
+ omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ u32 shift, mode;
+
+ switch (phy) {
+ case OMAP3_CTRL_CSI2_PHY1_CCP2B:
+ cam_phy_ctrl =
~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ break;
+ case OMAP3_CTRL_CSI2_PHY1_CSI2C:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ case OMAP3_CTRL_CSI2_PHY2_CCP2B:
+ cam_phy_ctrl |=
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ break;
+ case OMAP3_CTRL_CSI2_PHY2_CSI2A:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ default:
+ pr_warn(bad phy %d\n, phy);
+ return -EINVAL;
+ }
+
+ /* Select data/clock or data/strobe mode for CCP2 */
+ switch (phy) {
+ case OMAP3_CTRL_CSI2_PHY1_CCP2B:
+ case OMAP3_CTRL_CSI2_PHY2_CCP2B:
+ if (flags OMAP3_CTRL_CSI2_CFG_CCP2_DATA_STROBE)
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
+ else
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
+ break;
+ }
+
+ cam_phy_ctrl = ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK
shift);
+ cam_phy_ctrl |= mode shift;
+
+ omap_ctrl_writel(cam_phy_ctrl,
+OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+ return 0;
+}
+
+static int omap3430_ctrl_csi2_phy_cfg(u32 phy, bool on, u32 flags)
+{
+ uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
+ | OMAP343X_CONTROL_CSIRXFE_RESET;
+
+ /* Nothing to configure here. */
+ if (phy == OMAP3_CTRL_CSI2_PHY2_CSI2A)
+ return 0;
+
+ if (phy != OMAP3_CTRL_CSI2_PHY1_CCP2B)
+ return -EINVAL;
+
+ if (!on) {
+ omap_ctrl_writel(0, OMAP343X_CONTROL_CSIRXFE);
+ return 0;
+ }
+
+ if (flags OMAP3_CTRL_CSI2_CFG_CCP2_DATA_STROBE)
+ csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+
+ omap_ctrl_writel(csirxfe, OMAP343X_CONTROL_CSIRXFE);
+
+ return 0;
+}
+
+int omap3_ctrl_csi2_phy_cfg(u32 phy, bool on, u32 flags)
+{
+ if (cpu_is_omap3630() on)
+ return omap3630_ctrl_csi2_phy_cfg(phy, flags);
+ if (cpu_is_omap3430())
+ return omap3430_ctrl_csi2_phy_cfg(phy, on, flags);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap3_ctrl_csi2_phy_cfg);
+
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b8cdc85..7b2ee5d 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -132,6 +132,11 @@
#define OMAP343X_CONTROL_MEM_DFTRW1(OMAP2_CONTROL_GENERAL + 0x000c)
#define OMAP343X_CONTROL_DEVCONF1 (OMAP2_CONTROL_GENERAL + 0x0068)
#define OMAP343X_CONTROL_CSIRXFE (OMAP2_CONTROL_GENERAL + 0x006c)
+#define OMAP343X_CONTROL_CSIRXFE_CSIB_INV (1 7)
+#define OMAP343X_CONTROL_CSIRXFE_RESENABLE (1 8)
+#define OMAP343X_CONTROL_CSIRXFE_SELFORM (1 10)
+#define OMAP343X_CONTROL_CSIRXFE_PWRDNZ(1 12)
+#define OMAP343X_CONTROL_CSIRXFE_RESET (1 13)
#define OMAP343X_CONTROL_SEC_STATUS(OMAP2_CONTROL_GENERAL + 0x0070)
#define OMAP343X_CONTROL_SEC_ERR_STATUS(OMAP2_CONTROL_GENERAL
+ 0x0074)
#define OMAP343X_CONTROL_SEC_ERR_STATUS_DEBUG (OMAP2_CONTROL_GENERAL + 0x0078)
@@ -189,6 +194,16 @@
#define OMAP3630_CONTROL_FUSE_OPP50_VDD2
[PATCH v2 2/2] omap3isp: Configure CSI-2 phy based on platform data
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
This patch is dependent on omap3: Provide means for changing CSI2 PHY
configuration.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.h |3 -
drivers/media/platform/omap3isp/ispcsiphy.c | 161 +++
drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
3 files changed, 90 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..a2f992c 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -127,9 +127,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes);
};
/*
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 348f67e..1d16e66 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -28,41 +28,13 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include mach/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
/*
- * csiphy_lanes_config - Configuration of CSIPHY lanes.
- *
- * Updates HW configuration.
- * Called with phy-mutex taken.
- */
-static void csiphy_lanes_config(struct isp_csiphy *phy)
-{
- unsigned int i;
- u32 reg;
-
- reg = isp_reg_readl(phy-isp, phy-cfg_regs, ISPCSI2_PHY_CFG);
-
- for (i = 0; i phy-num_data_lanes; i++) {
- reg = ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
-ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
- reg |= (phy-lanes.data[i].pol
- ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
- reg |= (phy-lanes.data[i].pos
- ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
- }
-
- reg = ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
-ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
- reg |= phy-lanes.clk.pol ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
- reg |= phy-lanes.clk.pos ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-cfg_regs, ISPCSI2_PHY_CFG);
-}
-
-/*
* csiphy_power_autoswitch_enable
* @enable: Sets or clears the autoswitch function enable flag.
*/
@@ -107,46 +79,32 @@ static int csiphy_set_power(struct isp_csiphy *phy, u32
power)
}
/*
- * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
- *
- * Called with phy-mutex taken.
+ * TCLK values are OK at their reset values
*/
-static void csiphy_dphy_config(struct isp_csiphy *phy)
-{
- u32 reg;
-
- /* Set up ISPCSIPHY_REG0 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG0);
-
- reg = ~(ISPCSIPHY_REG0_THS_TERM_MASK |
-ISPCSIPHY_REG0_THS_SETTLE_MASK);
- reg |= phy-dphy.ths_term ISPCSIPHY_REG0_THS_TERM_SHIFT;
- reg |= phy-dphy.ths_settle ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG0);
-
- /* Set up ISPCSIPHY_REG1 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG1);
-
- reg = ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
-ISPCSIPHY_REG1_TCLK_MISS_MASK |
-ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
- reg |= phy-dphy.tclk_term ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
- reg |= phy-dphy.tclk_miss ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
- reg |= phy-dphy.tclk_settle ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
-}
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE14
-static int csiphy_config(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes)
+static int omap3isp_csiphy_config(struct isp_csiphy *phy)
{
+ struct isp_csi2_device *csi2 = phy-csi2;
+ struct isp_pipeline *pipe = to_isp_pipeline(csi2-subdev.entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
+ struct isp_csiphy_lanes_cfg *lanes;
+ int csi2_ddrclk_khz;
unsigned int used_lanes = 0;
unsigned int i;
+ unsigned int phy_num;
+ u32 reg;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
/* Clock and data lanes verification */
- for (i = 0; i
Re: [PATCH v2 2/2] omap3isp: Configure CSI-2 phy based on platform data
Moi Sakari * Sakari Ailus sakari.ai...@iki.fi [120926 14:51]: Configure CSI-2 phy based on platform data in the ISP driver. For that, the new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same was configured from the board code. This patch is dependent on omap3: Provide means for changing CSI2 PHY configuration. Can you please do one more patch to get rid of the last remaining cpu_is_omap check in drivers/media/platform/omap3isp/isp.c? That data should come from platform_data (or device tree) as we going to make cpu_is_omap privat to mach-omap2. 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 0/2] OMAP: mailbox initial device tree support
Hi Benoit, On 12 September 2012 19:08, Omar Ramirez Luna omar.l...@linaro.org wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt Ping. I'm in the understanding that these go through your tree, am I right? Regards, Omar -- 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 0/2] OMAP: mailbox initial device tree support
Hi Omar, On 9/26/2012 3:21 PM, Omar Ramirez Luna wrote: Hi Benoit, On 12 September 2012 19:08, Omar Ramirez Luna omar.l...@linaro.org wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt Ping. I'm in the understanding that these go through your tree, am I right? Since it is too late for 3.7, you should probably do two more things: - move the mailbox driver outside mach-omap2 - move the nr_mbox information in the driver as well instead of the hwmod for the DT boot. Regards, Benoit -- 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/3] uio: uio_pruss: port to AM33xx
On Wed, Sep 26, 2012 at 09:44:29AM -0400, Matt Porter wrote:
Add ifdefery hacks to only use SRAM on Davinci. This
needs to be cleaned up with a sane generic SRAM allocator
(like the DT based driver available that can't be used on
Davinci which is just starting DT conversion) before it
can go upstream.
I agree with that ;-)
Needing lots of ifdefs in *.c files is usually a bad sign...
Thanks anyway for posting, it's good to have things like that in the archives.
And please make driver code and documentation updates separate patches in the
future.
Hans
Adds DT, pinctrl, and runtime PM support for use on
AM33xx.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/uio/pruss.txt| 17 ++
.../devicetree/bindings/uio/uio_pruss.txt | 17 ++
drivers/uio/Kconfig|4 +-
drivers/uio/uio_pruss.c| 63
+++-
4 files changed, 98 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/uio/pruss.txt
create mode 100644 Documentation/devicetree/bindings/uio/uio_pruss.txt
diff --git a/Documentation/devicetree/bindings/uio/pruss.txt
b/Documentation/devicetree/bindings/uio/pruss.txt
new file mode 100644
index 000..2ac45c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/pruss.txt
@@ -0,0 +1,17 @@
+TI PRUSS device
+
+Required properties:
+- compatible :
+ - ti,pruss-v1 for AM18xx/OMAP-L138/DA850
+ - ti,pruss-v2 for AM33xx.
+- ti,pintc-offset : Offset of the PINTC from the PRUSS address base
+- ti,hwmods: Name of the hwmod associated to the PRUSS
+
+Example:
+
+pruss: pruss@4a30 {
+ compatible = ti,pruss-v2;
+ ti,hwmods = pruss;
+ reg = 0x4a30 0x08;
+ ti,pintc-offset = 0x2;
+};
diff --git a/Documentation/devicetree/bindings/uio/uio_pruss.txt
b/Documentation/devicetree/bindings/uio/uio_pruss.txt
new file mode 100644
index 000..2ac45c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_pruss.txt
@@ -0,0 +1,17 @@
+TI PRUSS device
+
+Required properties:
+- compatible :
+ - ti,pruss-v1 for AM18xx/OMAP-L138/DA850
+ - ti,pruss-v2 for AM33xx.
+- ti,pintc-offset : Offset of the PINTC from the PRUSS address base
+- ti,hwmods: Name of the hwmod associated to the PRUSS
+
+Example:
+
+pruss: pruss@4a30 {
+ compatible = ti,pruss-v2;
+ ti,hwmods = pruss;
+ reg = 0x4a30 0x08;
+ ti,pintc-offset = 0x2;
+};
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 6f3ea9b..8da7d9b 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -96,9 +96,9 @@ config UIO_NETX
config UIO_PRUSS
tristate Texas Instruments PRUSS driver
- depends on ARCH_DAVINCI_DA850
+ depends on ARCH_DAVINCI_DA850 || SOC_AM33XX
help
- PRUSS driver for OMAPL138/DA850/AM18XX devices
+ PRUSS driver for OMAPL138/DA850/AM18XX and AM33XX devices
PRUSS driver requires user space components, examples and user space
driver is available from below SVN repo - you may use anonymous login
diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
index 33a7a27..326ce40 100644
--- a/drivers/uio/uio_pruss.c
+++ b/drivers/uio/uio_pruss.c
@@ -25,7 +25,15 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/slab.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
+#include linux/pm_runtime.h
+
+#ifdef CONFIG_ARCH_DAVINCI_DA850
#include mach/sram.h
+#endif
#define DRV_NAME pruss_uio
#define DRV_VERSION 1.0
@@ -105,8 +113,10 @@ static void pruss_cleanup(struct platform_device *dev,
dma_free_coherent(dev-dev, extram_pool_sz, gdev-ddr_vaddr,
gdev-ddr_paddr);
}
+#ifdef CONFIG_ARCH_DAVINCI_DA850
if (gdev-sram_vaddr)
sram_free(gdev-sram_vaddr, sram_pool_sz);
+#endif
kfree(gdev-info);
clk_put(gdev-pruss_clk);
kfree(gdev);
@@ -117,8 +127,10 @@ static int __devinit pruss_probe(struct platform_device
*dev)
struct uio_info *p;
struct uio_pruss_dev *gdev;
struct resource *regs_prussio;
+ struct resource res;
int ret = -ENODEV, cnt = 0, len;
struct uio_pruss_pdata *pdata = dev-dev.platform_data;
+ struct pinctrl *pinctrl;
gdev = kzalloc(sizeof(struct uio_pruss_dev), GFP_KERNEL);
if (!gdev)
@@ -129,6 +141,7 @@ static int __devinit pruss_probe(struct platform_device
*dev)
kfree(gdev);
return -ENOMEM;
}
+#ifdef CONFIG_ARCH_DAVINCI_DA850
/* Power on PRU in case its not done as part of boot-loader */
gdev-pruss_clk = clk_get(dev-dev, pruss);
if (IS_ERR(gdev-pruss_clk)) {
@@ -140,6 +153,28 @@ static int __devinit pruss_probe(struct platform_device
*dev)
} else {
Re: [PATCH v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
Hi Afzal, On 09/19/2012 08:23 AM, Afzal Mohammed wrote: Presently there are three peripherals that gets it timing by runtime calculation. Those peripherals can work with frequency scaling that affects gpmc clock. But timing calculation for them are in different ways. Here a generic runtime calculation method is proposed. Input to this function were selected so that they represent timing variables that are present in peripheral datasheets. Motive behind this was to achieve DT bindings for the inputs as is. Even though a few of the tusb6010 timings could not be made directly related to timings normally found on peripherals, expressions used were translated to those that could be justified. There are possibilities of improving the calculations, like calculating timing for read write operations in a more similar way. Expressions derived here were tested for async onenand on omap3evm (as vanilla Kernel does not have omap3evm onenand support, local patch was used). Other peripherals, tusb6010, smc91x calculations were validated by simulating on omap3evm. Regarding we_on for onenand async, it was found that even for muxed address/data, it need not be greater than adv_wr_off, but rather could be derived from write setup time for peripheral from start of access time, hence would more be in line with peripheral timings. With this method it was working fine. If it is required in some cases to have we_on same as wr_data_mux_bus (i.e. greater than adv_wr_off), another variable could be added to indicate it. But such a requirement is not expected though. It has been observed that adv_rd_off adv_wr_off are currently calculated by adding an offset over oe_on and we_on respectively in the case of smc91x. But peripheral datasheet does not specify so and so adv_rd(wr)_off has been derived (to be specific, made ignorant of oe_on and we_on) observing datasheet rather than adding an offset. Hence this generic routine is expected to work for smc91x (91C96 RX51 board). This was verified on smsc911x (9220 on OMAP3EVM) - a similar ethernet controller. Timings are calculated in ps to prevent rounding errors and converted to ns at final stage so that these values can be directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings() would be modified to take ps once all custom timing routines are replaced by the generic routine, at the same time generic timing routine would be modified to provide timings in ps. struct gpmc_timings field types are upgraded from u16 = u32 so that it can hold ps values. Whole of this exercise is being done to achieve driver and DT conversion. If timings could not be calculated in a peripheral agnostic way, either gpmc driver would have to be peripheral gnostic or a wrapper arrangement over gpmc driver would be required. Signed-off-by: Afzal Mohammed af...@ti.com --- v7: 1. Use picoseconds throughout generic timing routine to prevent rounding error. 2. Documentation on gpmc timings Documentation/bus-devices/ti-gpmc.txt | 77 arch/arm/mach-omap2/gpmc.c | 319 + arch/arm/plat-omap/include/plat/gpmc.h | 101 --- 3 files changed, 477 insertions(+), 20 deletions(-) create mode 100644 Documentation/bus-devices/ti-gpmc.txt diff --git a/Documentation/bus-devices/ti-gpmc.txt b/Documentation/bus-devices/ti-gpmc.txt new file mode 100644 index 000..2c88a88 --- /dev/null +++ b/Documentation/bus-devices/ti-gpmc.txt @@ -0,0 +1,77 @@ +GPMC (General Purpose Memory Controller): += + +GPMC is an unified memory controller dedicated to interfacing external +memory devices like + * Asynchronous SRAM like memories and application specific integrated + circuit devices. + * Asynchronous, synchronous, and page mode burst NOR flash devices + NAND flash + * Pseudo-SRAM devices + +GPMC is found on Texas Instruments SoC's (OMAP based) + + +GPMC generic timing calculation: + + +GPMC has certain timings that has to be programmed for proper +functioning of the peripheral, while peripheral has another set of +timings. To have peripheral work with gpmc, peripheral timings has to +be translated to the form gpmc can understand. The way it has to be +translated depends on the connected peripheral. Also there is a +dependency for certain gpmc timings on gpmc clock frequency. Hence a +generic timing routine was developed to achieve above requirements. + +Generic routine provides a generic method to calculate gpmc timings +from gpmc peripheral timings. struct gpmc_device_timings fields has to +be updated with timings from the datasheet of the peripheral that is +connected to gpmc. A few of the peripheral timings can be fed either +in time or in cycles, provision to handle this scenario has been +provided (refer struct gpmc_device_timings definition). It may so
Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
Hi,
On Wed, Sep 26, 2012 at 11:57 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev,
usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
This clock is needed for usb2 to work in dwc3 (omap5). So we have to
report the error in case we dont get the clock no?
sure, but you don't need to bail out. Print a warning message such as:
dev_dbg(pdev-dev, couldn't get refclk960m, trying without\n);
but then we'll get this debug message for omap4 which actually doesn't
need 960m clk.
Thanks
Kishon
--
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] usb: phy: omap-usb2: enable 960Mhz clock for omap5
On Thu, Sep 27, 2012 at 10:43:06AM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Wed, Sep 26, 2012 at 11:57 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Sep 26, 2012 at 11:10:48AM +0530, ABRAHAM, KISHON VIJAY wrote:
Hi,
On Wed, Sep 19, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev,
usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
This clock is needed for usb2 to work in dwc3 (omap5). So we have to
report the error in case we dont get the clock no?
sure, but you don't need to bail out. Print a warning message such as:
dev_dbg(pdev-dev, couldn't get refclk960m, trying without\n);
but then we'll get this debug message for omap4 which actually doesn't
need 960m clk.
then make it dev_vdbg(). It's just a debugging message, it's not saying
it will fail, it's just stating that clock isn't present and we're
trying without because it's known that some versions don't need that
clock.
Another way to do it, would be to request or not the extra clock, based
on the Revision Register (if this IP has one).
--
balbi
signature.asc
Description: Digital signature
[PATCH 2/3] usb: musb: dsps: remove nop unregister
usb: musb: dsps: remove explicit NOP device creation removed nop register, but not unregistering, remove nop unregister in error and exit path. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/usb/musb/musb_dsps.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 444346e..9d7ca4c 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -411,7 +411,6 @@ static int dsps_musb_init(struct musb *musb) return 0; err0: usb_put_phy(musb-xceiv); - usb_nop_xceiv_unregister(); return status; } @@ -431,7 +430,6 @@ static int dsps_musb_exit(struct musb *musb) /* NOP driver needs change if supporting dual instance */ usb_put_phy(musb-xceiv); - usb_nop_xceiv_unregister(); return 0; } -- 1.7.12 -- 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/3] usb: musb: dsps: document dt bindings properly
DT bindings have '-' (hyphens) instead of '_' (underscore), update the documentation to reflect it. Signed-off-by: Afzal Mohammed af...@ti.com --- Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index 9782585..6d5d5f0 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -3,12 +3,12 @@ AM33XX MUSB GLUE - ti,hwmods : must be usb_otg_hs - multipoint : Should be 1 indicating the musb controller supports multipoint. This is a MUSB configuration-specific setting. - - num_eps : Specifies the number of endpoints. This is also a + - num-eps : Specifies the number of endpoints. This is also a MUSB configuration-specific setting. Should be set to 16 - - ram_bits : Specifies the ram address size. Should be set to 12 - - port0_mode : Should be 3 to represent OTG. 1 signifies HOST and 2 + - ram-bits : Specifies the ram address size. Should be set to 12 + - port0-mode : Should be 3 to represent OTG. 1 signifies HOST and 2 represents PERIPHERAL. - - port1_mode : Should be 1 to represent HOST. 3 signifies OTG and 2 + - port1-mode : Should be 1 to represent HOST. 3 signifies OTG and 2 represents PERIPHERAL. - power : Should be 250. This signifies the controller can supply upto 500mA when operating in host mode. -- 1.7.12 -- 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/3] usb: otg: nop: add dt support
From: B, Ravi ravib...@ti.com
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi,
This series is made over over Balbi's usb master branch.
It applies cleanly over musb branch too.
Regards
Afzal
Documentation/devicetree/bindings/usb/am33xx-usb.txt | 3 +++
drivers/usb/otg/nop-usb-xceiv.c | 10 ++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index e52e35e..64bfbe4 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -154,12 +155,21 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {},
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.12
--
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] ARM: OMAP2+: SmartReflex: fix return value check in sr_dev_init()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function voltdm_lookup() returns NULL
not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
arch/arm/mach-omap2/sr_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index d033a65..c248b30 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -123,7 +123,7 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void
*user)
sr_data-senp_mod = 0x1;
sr_data-voltdm = voltdm_lookup(sr_dev_attr-sensor_voltdm_name);
- if (IS_ERR(sr_data-voltdm)) {
+ if (!sr_data-voltdm) {
pr_err(%s: Unable to get voltage domain pointer for VDD %s\n,
__func__, sr_dev_attr-sensor_voltdm_name);
goto exit;
--
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] ARM: OMAP2+: PM: fix return value check in omap2_set_init_voltage()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function voltdm_lookup() returns NULL
not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
arch/arm/mach-omap2/pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 9cb5ced..ab15e5c 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -176,7 +176,7 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
}
voltdm = voltdm_lookup(vdd_name);
- if (IS_ERR(voltdm)) {
+ if (!voltdm) {
pr_err(%s: unable to get vdd pointer for vdd_%s\n,
__func__, vdd_name);
goto exit;
--
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
