Re: [PATCH v6 1/2] ARM: dts: twl: Add GPADC data to device tree
Hi Sergei,
On Fri, Jul 19, 2013 at 1:18 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
Hello.
On 07/19/2013 07:40 PM, Grygorii Strashko wrote:
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi
b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..d7d4c28 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+adc: gpadc {
Read my lips: the node should be called just adc, not gpadc.
Are you sure?
I didn't know how to express my disappointment from Oleksandr's inability
to understand what I wanted to convey to him from 2 attempts... first,
How would you comment the following code, v3.10-rc7:
arch/arm/boot/dts/dbx5x0.dtsi, line 375
375 ab8500-gpadc {
376 compatible =
stericsson,ab8500-gpadc;
377 interrupts = 32
IRQ_TYPE_LEVEL_HIGH
arch/arm/boot/dts/dbx5x0.dtsi: ab8500-gpadc {
arch/arm/boot/dts/dbx5x0.dtsi:
compatible = stericsson,ab8500-gpadc;
arch/arm/boot/dts/dbx5x0.dtsi:
vddadc-supply = ab8500_ldo_tvout_reg;
arch/arm/boot/dts/sama5d3.dtsi: tsadcc: tsadcc@f8018000 {
arch/arm/boot/dts/sama5d3.dtsi: compatible =
atmel,at91sam9x5-tsadcc;
arch/arm/boot/dts/sama5d3.dtsi:
atmel,tsadcc_clock = 30;
arch/arm/boot/dts/am33xx.dtsi: tscadc: tscadc@44e0d000 {
arch/arm/boot/dts/am33xx.dtsi: compatible = ti,am3359-tscadc;
arch/arm/boot/dts/am33xx.dtsi: ti,hwmods = adc_tsc;
arch/arm/boot/dts/am33xx.dtsi: am335x_adc: adc {
arch/arm/boot/dts/am33xx.dtsi: compatible =
ti,am3359-adc;
Regards,
Sasha.
changed the label instead of the node name, then he only dropped twl6030_
prefix from the name. I should probably have been even more specific before.
Why? The name was selected according to the documentation on device
General
purpose analog-to-digital converter (GPADC).
Sigh, we simply don't care whether this ADC is general-purpose or not.
The main thing it is ADC.
PS. Following your logic - GPIO need to renamed to IO everywhere ;P
GPIO is well known and established abbreviation, contrasted to GPADC.
Moreover, ePAPR spec lists gpio as a generic node name.
WBR, Sergei
--
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
--
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: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet
On Thu, 2013-07-18 at 01:59 -0700, Tony Lindgren wrote: * Arend van Spriel ar...@broadcom.com [130718 01:47]: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# The wl12xx .dts changes for pandaboard are still missing too. Just for the record, I already have the DTS patches for wl12xx on Panda (and a few other boards). I held them back because I wanted the bindings to be properly defined first. I'll continue this work pretty soon, when I come back from my summer vacations (in a week). -- Cheers, Luca. -- 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] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-07-18 at 01:58 +0200, Laurent Pinchart wrote: Hi Luciano, Hi Laurent, On Monday 01 July 2013 15:39:30 Luciano Coelho wrote: The only thing I can come up with is to make a small clock driver (maybe even inside the WiLink module itself) that registers a new type of clock, ti,wilink-clock or something. But this would really be overkill, wouldn't it? Any other ideas? One possibility would be to just call clk_get_rate() on the clock from the WiLink driver, which would return the fixed frequency specified in DT, and configure the WiLink hardware accordingly. This might be a bit hackish though. The problem is not get the rate itself, the problem is knowing whether the clock is XTAL or not. The WiLink chip uses the clock in a slightly different way if it is XTAL, due to some stabilization time constraints. -- Luca. -- 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: [net-next PATCH 1/1] drivers: net: cpsw: add support to show hw stats via ethtool get_regs
On 7/20/2013 6:02 AM, David Miller wrote: From: Mugunthan V N mugunthan...@ti.com Date: Fri, 19 Jul 2013 19:37:21 +0530 Add support to show CPSW hardware statistics to user via ethtool get_regs ops so user can find if there were any error reported or the system is over loaded duing hagh data rate transfer. Signed-off-by: Mugunthan V N mugunthan...@ti.com This is not the correct way to provide this functionality. -get_regs() is for dumping the raw hardware registers to userspace for low level debugging purposes, not for providing HW specific statistics. The correct thing to do is provide an appropriate implementation of the -get_strings() and -get_ethtool_stats() methods. Will change the implementation and resubmit the patch. Regards Mugunthan V N -- 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 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote: The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i.e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K balaj...@ti.com Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com A few little bits and bobs inline. My only major query is about the lack of info for the temperature channels. How do you convert these to useful real world units? Jonathan --- drivers/iio/adc/Kconfig | 14 + drivers/iio/adc/Makefile| 1 + drivers/iio/adc/twl6030-gpadc.c | 991 3 files changed, 1006 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..3172461 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -150,6 +150,20 @@ config TI_AM335X_ADC Say yes here to build support for Texas Instruments ADC driver which is also a MFD client. +config TWL6030_GPADC + tristate TWL6030 GPADC (General Purpose A/D Converter) Support + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030/TWL6032 General + Purpose A/D Converter. This will add support for battery type + detection, battery voltage and temperature measurement, die + temperature measurement, system supply voltage, audio accessory, + USB ID detection. + + This driver can also be built as a module. If so, the module will be + called twl6030-gpadc. + config VIPERBOARD_ADC tristate Viperboard ADC support depends on MFD_VIPERBOARD USB diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..996ba09 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..b42cfd6 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,991 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat nska...@ti.com + * Balaji T K balaj...@ti.com + * Graeme Gregory g...@slimlogic.co.uk + * Girish S Ghongdemath giris...@ti.com + * Ambresh K ambr...@ti.com + * Oleksandr Kozaruk oleksandr.koza...@ti.com + * + * Based on twl4030-madc.c + * Copyright (C) 2008 Nokia Corporation + * Mikko Ylinen mikko.k.yli...@nokia.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed 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, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h +#include linux/of_platform.h +#include linux/i2c/twl.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h + +#define DRIVER_NAME twl6030_gpadc + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 + +#define TWL6030_GPADC_CTRL_P10x05 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define
Re: mcbsp.1 slave clkx ext problem
Hi Peter
On Fri, Jul 19, 2013 at 05:29:44PM +0200, Michael Trimarchi wrote:
Hi
On 07/19/2013 03:33 PM, Michael Trimarchi wrote:
Hi
I'm trying to understand what is wrong here with this small
driver.
/* McBSP1 */
OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
kernel 3.8.0
I have fixed my problem ;). I will send a description about it
Michael
I will prepare a proper patch. But OMAP supports (both omap3/omap4) the
SND_SOC_DAIFMT_CBM_CFS format in this way. I have already tested it on
my devkit platform
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8d2defd..85dd415 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -435,6 +435,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
/* Sample rate generator drives the FS */
regs-srgr2 |= FSGM;
break;
+ case SND_SOC_DAIFMT_CBM_CFS:
+ /* McBSP slave. FS clock as output */
+ regs-srgr2 |= FSGM;
+ regs-pcr0 |= FSXM;
+ break;
case SND_SOC_DAIFMT_CBM_CFM:
/* McBSP slave */
break;
Best regards
Michael
[ 107.276702] omap-mcbsp omap-mcbsp.1: Configuring McBSP1 phys_base:
0x40122000
[ 107.283691] omap-mcbsp omap-mcbsp.1: McBSP1 regs
[ 107.283721] omap-mcbsp omap-mcbsp.1: DRR2: 0x88260a09
[ 107.283721] omap-mcbsp omap-mcbsp.1: DRR1: 0x
[ 107.283752] omap-mcbsp omap-mcbsp.1: DXR2: 0x
[ 107.283752] omap-mcbsp omap-mcbsp.1: DXR1: 0x
[ 107.283752] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0233
[ 107.283782] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[ 107.283782] omap-mcbsp omap-mcbsp.1: RCR2: 0x80a1
[ 107.283813] omap-mcbsp omap-mcbsp.1: RCR1: 0x00a0
[ 107.283813] omap-mcbsp omap-mcbsp.1: XCR2: 0x80a1
[ 107.283813] omap-mcbsp omap-mcbsp.1: XCR1: 0x00a0
[ 107.283843] omap-mcbsp omap-mcbsp.1: SRGR2: 0x203f
[ 107.283843] omap-mcbsp omap-mcbsp.1: SRGR1: 0x1f00
[ 107.283843] omap-mcbsp omap-mcbsp.1: PCR0: 0x008f
[ 107.283874] omap-mcbsp omap-mcbsp.1: ***
[ 119.926177] omap-dma-engine omap-dma-engine: freeing channel for 33
Well basically it doesn't start the transfer. The clock is provided
using the clkx pin. clkx is rate * channel * bitsxword and come from
the codec.
What is wrong? (I know that how I register the card is deprecated)
Regards Michael
/*
* dacmax.c -- SoC audio for pandaboard demokit
*
* Author: Michael Trimarchi mich...@amarulasolutions.com
*
* Based on:
* Author: Misael Lopez Cruz x0052...@ti.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
* This program is distributed 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, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
* 02110-1301 USA
*
*/
#include linux/clk.h
#include linux/platform_device.h
#include sound/core.h
#include sound/pcm.h
#include sound/pcm_params.h
#include sound/soc.h
#include asm/mach-types.h
#include linux/gpio.h
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/module.h
#include omap-mcbsp.h
static struct snd_soc_card snd_soc_dacmax;
static int dacmax_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
int ret;
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
pr_info(%s: setting the params\n, __func__);
ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKX_EXT, 0,
SND_SOC_CLOCK_IN);
if (ret 0) {
printk(KERN_ERR can't set CPU system clock \
OMAP_MCBSP_CLKR_SRC_CLKX\n);
}
return 0;
}
static struct snd_soc_ops dacmax_ops = {
.hw_params = dacmax_hw_params,
};
static int dacmax_init(struct snd_soc_pcm_runtime *rtd)
{
pr_info(%s: INIT\n, __func__);
return 0;
}
/* Digital audio interface glue - connects codec -- CPU */
static struct snd_soc_dai_link dacmax_dai = {
.name = DACMAX-I2S,
.stream_name = DACMAX-Audio,
.cpu_dai_name =
Re: [PATCH] GPIO: gpio-twl6040: Remove support for legacy (pdata) mode
On Fri, Jul 12, 2013 at 1:30 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote: TWL6040 is used only with OMAP4/5 SoCs and they can only boot in in DT mode. The support for pdata/legacy boot can be removed. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com OK patch applied. 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: Need help for DT GPIO probing
On Fri, Jul 12, 2013 at 4:05 PM, Soumya Sutar soumyasu...@gmail.com wrote: Hi Linus, I am facing DT GPIO probing problem same as below link. http://us.generation-nt.com/answer/gpio-crashed-when-not-using-help-208346861.html Could you know any patch is available for this issues or still we need to use gpio_request() in driver. Please ask questions like this on the mailing lists and include the OMAP GPIO maintainers (Santosh Kevin). And the answer is yes, all GPIO lines you are using need to be requested by the driver. 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: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 08:49:32AM +0530, Kishon Vijay Abraham I wrote: Hi, On Saturday 20 July 2013 05:20 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:59 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: Hi, On Friday 19 July 2013 11:13 AM, Greg KH wrote: On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: + ret = dev_set_name(phy-dev, %s.%d, dev_name(dev), id); Your naming is odd, no phy anywhere in it? You rely on the sender to never send a duplicate name.id pair? Why not create your own ids based on the number of phys in the system, like almost all other classes and subsystems do? hmm.. some PHY drivers use the id they provide to perform some of their internal operation as in [1] (This is used only if a single PHY provider implements multiple PHYS). Probably I'll add an option like PLATFORM_DEVID_AUTO to give the PHY drivers an option to use auto id. [1] - http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html No, who cares about the id? No one outside of the phy core ever should, because you pass back the only pointer that they really do care about, if they need to do anything with the device. Use that, and then you can hmm.. ok. rip out all of the search for a phy by a string logic, as that's not Actually this is needed for non-dt boot case. In the case of dt boot, we use a phandle by which the controller can get a reference to the phy. But in the case of non-dt boot, the controller can get a reference to the phy only by label. I don't understand. They registered the phy, and got back a pointer to it. Why can't they save it in their local structure to use it again later if needed? They should never have to ask for the device, as the One is a *PHY provider* driver which is a driver for some PHY device. This will use phy_create to create the phy. The other is a *PHY consumer* driver which might be any controller driver (can be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference to the phy (by *phandle* in the case of dt boot and *label* in the case of non-dt boot). device id might be unknown if there are multiple devices in the system. I agree with you on the device id part. That need not be known to the PHY driver. How does a consumer know which label to use in a non-dt system if there are multiple PHYs in the system? That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) 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 01/15] drivers: phy: add generic PHY framework
On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any find functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. 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: Need help for DT GPIO probing
Hi Soumya On Saturday, July 20, 2013, Linus Walleij wrote: On Fri, Jul 12, 2013 at 4:05 PM, Soumya Sutar soumyasu...@gmail.com wrote: Hi Linus, I am facing DT GPIO probing problem same as below link. http://us.generation-nt.com/answer/gpio-crashed-when-not-using-help-208346861.html Could you know any patch is available for this issues or still we need to use gpio_request() in driver. Yes, Linus W has already queued some patches for gpio-omap on the for-next branch of his linux-gpio tree [1] that solves this issue. Take a look to commit b4419e1a (gpio/omap: auto request GPIO as input if used as IRQ via DT) although this patch depends on others so you should merge the whole branch to make it work. Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? Please ask questions like this on the mailing lists and include the OMAP GPIO maintainers (Santosh Kevin). And the answer is yes, all GPIO lines you are using need to be requested by the driver. Yours, Linus Walleij -- Thanks a lot and best regards, Javier [1]: https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/log/?h=for-next -- 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
