Re: [PATCH 1/2] extcon: of: Remove unnecessary function call by using the name of device_node
Hi,
On 03/20/2014 02:20 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
This patch remove unnecessary function call in of_extcon_get_extcon_dev()
by using the name of device_node structure.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/of_extcon.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
index 72173ec..0a29f82 100644
--- a/drivers/extcon/of_extcon.c
+++ b/drivers/extcon/of_extcon.c
@@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct
device *dev, int index)
{
struct device_node *node;
struct extcon_dev *edev;
- struct platform_device *extcon_parent_dev;
if (!dev->of_node) {
dev_dbg(dev, "device does not have a device node entry\n");
@@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct
device *dev, int index)
return ERR_PTR(-ENODEV);
}
- extcon_parent_dev = of_find_device_by_node(node);
- if (!extcon_parent_dev) {
- dev_dbg(dev, "unable to find device by node\n");
- return ERR_PTR(-EPROBE_DEFER);
- }
-
- edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
+ edev = extcon_get_extcon_dev(node->name);
>>>
>>> Since you no longer want to use device names I think you should add this
>>> too to
>>> warn users if they rely on using the device name.
>>
>> Previous of_extcon_get_extcon_dev() support only platform device using
>> of_find_device_by_node.
>>
>> If extcon device is based on i2c/spi/pci and so on,
>> of_extcon_get_extcon_dev() can't
>> find device instance for device name. So, I change device name from the name
>> of platform device
>> to the name of dt node.
>
> That's fine. But we have to fix extcon_dev_register() too, to not use device
> names right? We have to warn extcon users not to use device names right?
I don't think so. extcon_get_edev_by_phandle() shows wrong node->name as
following:
The consumer could detect the cause of problem which can't get extcon device
after
checking error log message.
edev = extcon_get_extcon_dev(node->name);
if (!edev) {
dev_err(dev, "unable to get extcon device : %s\n", node->name);
return ERR_PTR(-ENODEV);
}
I don't want to add more log message.
>>
>>
>>> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
>>> index bc4c789..025eb39 100644
>>> --- a/drivers/extcon/extcon-class.c
>>> +++ b/drivers/extcon/extcon-class.c
>>> @@ -601,7 +601,6 @@ int extcon_dev_register(struct extcon_dev *edev)
>>> edev->dev.class = extcon_class;
>>> edev->dev.release = extcon_dev_release;
>>>
>>> - edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
>>> //The user should always pass the 'name' as we no longer use device name
>>> while
>>> getting extcon device. And this name should also be the 'node' name?
>>> if (IS_ERR_OR_NULL(edev->name)) {
>>> dev_err(&edev->dev,
>>> "extcon device name is null\n");
>>>
>>> Btw changing to node name from device name breaks dwc3 in OMAP5 and you
>>> would
>>> need this too..
>>>
>>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
>>> index 2aea4bc..cea8cd3 100644
>>> --- a/drivers/extcon/extcon-palmas.c
>>> +++ b/drivers/extcon/extcon-palmas.c
>>> @@ -188,6 +188,7 @@ static int palmas_usb_probe(struct platform_device
>>> *pdev)
>>>
>>> palmas_usb->edev.supported_cable = palmas_extcon_cable;
>>> palmas_usb->edev.dev.parent = palmas_usb->dev;
>>> + palmas_usb->edev.name = "palmas_usb";
>>> palmas_usb->edev.mutually_exclusive = mutually_exclusive;
>>>
>>> status = extcon_dev_register(&palmas_usb->edev);
>>>
>>> Cheers
>>> Kishon
>>>
>>
>> If node name is same as extcon device name, don't need some modification.
>> Also, you can modify node name in some OMAP dts file insead of modification
>> of extcon-palmas.c
>
> node name in OMAP dts is already 'palmas_usb'. But since we were not setting
> 'edev.name' in extcon-palmas.c, extcon_dev_register used device name of palmas
> (palmas_usb.7 in my case). So extcon-palmas.c needs the fix.
For example,
I used extcon provider/consumer driver in dts as following:
extcon-max14577.c set device name as edev->name and then dt node name of
max14577
set "max14577-muic" which is same as device name(dev_name(&pdev->dev)).
I don't need to modify extcon-max14577.c
In drivers/extcon/extcon-max14577.c
...
info->edev->name = dev_name(&pdev->dev);
...
In dts.
i2c@1388 {
Re: [PATCH 1/2] extcon: of: Remove unnecessary function call by using the name of device_node
Hi,
On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
> Hi,
>
> On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
>>> This patch remove unnecessary function call in of_extcon_get_extcon_dev()
>>> by using the name of device_node structure.
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> drivers/extcon/of_extcon.c | 12 ++--
>>> 1 file changed, 2 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
>>> index 72173ec..0a29f82 100644
>>> --- a/drivers/extcon/of_extcon.c
>>> +++ b/drivers/extcon/of_extcon.c
>>> @@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
>>> *dev, int index)
>>> {
>>> struct device_node *node;
>>> struct extcon_dev *edev;
>>> - struct platform_device *extcon_parent_dev;
>>>
>>> if (!dev->of_node) {
>>> dev_dbg(dev, "device does not have a device node entry\n");
>>> @@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct
>>> device *dev, int index)
>>> return ERR_PTR(-ENODEV);
>>> }
>>>
>>> - extcon_parent_dev = of_find_device_by_node(node);
>>> - if (!extcon_parent_dev) {
>>> - dev_dbg(dev, "unable to find device by node\n");
>>> - return ERR_PTR(-EPROBE_DEFER);
>>> - }
>>> -
>>> - edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
>>> + edev = extcon_get_extcon_dev(node->name);
>>
>> Since you no longer want to use device names I think you should add this too
>> to
>> warn users if they rely on using the device name.
>
> Previous of_extcon_get_extcon_dev() support only platform device using
> of_find_device_by_node.
>
> If extcon device is based on i2c/spi/pci and so on,
> of_extcon_get_extcon_dev() can't
> find device instance for device name. So, I change device name from the name
> of platform device
> to the name of dt node.
That's fine. But we have to fix extcon_dev_register() too, to not use device
names right? We have to warn extcon users not to use device names right?
>
>
>> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
>> index bc4c789..025eb39 100644
>> --- a/drivers/extcon/extcon-class.c
>> +++ b/drivers/extcon/extcon-class.c
>> @@ -601,7 +601,6 @@ int extcon_dev_register(struct extcon_dev *edev)
>> edev->dev.class = extcon_class;
>> edev->dev.release = extcon_dev_release;
>>
>> - edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
>> //The user should always pass the 'name' as we no longer use device name
>> while
>> getting extcon device. And this name should also be the 'node' name?
>> if (IS_ERR_OR_NULL(edev->name)) {
>> dev_err(&edev->dev,
>> "extcon device name is null\n");
>>
>> Btw changing to node name from device name breaks dwc3 in OMAP5 and you would
>> need this too..
>>
>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
>> index 2aea4bc..cea8cd3 100644
>> --- a/drivers/extcon/extcon-palmas.c
>> +++ b/drivers/extcon/extcon-palmas.c
>> @@ -188,6 +188,7 @@ static int palmas_usb_probe(struct platform_device *pdev)
>>
>> palmas_usb->edev.supported_cable = palmas_extcon_cable;
>> palmas_usb->edev.dev.parent = palmas_usb->dev;
>> + palmas_usb->edev.name = "palmas_usb";
>> palmas_usb->edev.mutually_exclusive = mutually_exclusive;
>>
>> status = extcon_dev_register(&palmas_usb->edev);
>>
>> Cheers
>> Kishon
>>
>
> If node name is same as extcon device name, don't need some modification.
> Also, you can modify node name in some OMAP dts file insead of modification
> of extcon-palmas.c
node name in OMAP dts is already 'palmas_usb'. But since we were not setting
'edev.name' in extcon-palmas.c, extcon_dev_register used device name of palmas
(palmas_usb.7 in my case). So extcon-palmas.c needs the fix.
Cheers
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 1/2] extcon: of: Remove unnecessary function call by using the name of device_node
Hi,
On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
>> This patch remove unnecessary function call in of_extcon_get_extcon_dev()
>> by using the name of device_node structure.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/extcon/of_extcon.c | 12 ++--
>> 1 file changed, 2 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
>> index 72173ec..0a29f82 100644
>> --- a/drivers/extcon/of_extcon.c
>> +++ b/drivers/extcon/of_extcon.c
>> @@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
>> *dev, int index)
>> {
>> struct device_node *node;
>> struct extcon_dev *edev;
>> -struct platform_device *extcon_parent_dev;
>>
>> if (!dev->of_node) {
>> dev_dbg(dev, "device does not have a device node entry\n");
>> @@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
>> *dev, int index)
>> return ERR_PTR(-ENODEV);
>> }
>>
>> -extcon_parent_dev = of_find_device_by_node(node);
>> -if (!extcon_parent_dev) {
>> -dev_dbg(dev, "unable to find device by node\n");
>> -return ERR_PTR(-EPROBE_DEFER);
>> -}
>> -
>> -edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
>> +edev = extcon_get_extcon_dev(node->name);
>
> Since you no longer want to use device names I think you should add this too
> to
> warn users if they rely on using the device name.
Previous of_extcon_get_extcon_dev() support only platform device using
of_find_device_by_node.
If extcon device is based on i2c/spi/pci and so on, of_extcon_get_extcon_dev()
can't
find device instance for device name. So, I change device name from the name of
platform device
to the name of dt node.
> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
> index bc4c789..025eb39 100644
> --- a/drivers/extcon/extcon-class.c
> +++ b/drivers/extcon/extcon-class.c
> @@ -601,7 +601,6 @@ int extcon_dev_register(struct extcon_dev *edev)
> edev->dev.class = extcon_class;
> edev->dev.release = extcon_dev_release;
>
> - edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
> //The user should always pass the 'name' as we no longer use device name while
> getting extcon device. And this name should also be the 'node' name?
> if (IS_ERR_OR_NULL(edev->name)) {
> dev_err(&edev->dev,
> "extcon device name is null\n");
>
> Btw changing to node name from device name breaks dwc3 in OMAP5 and you would
> need this too..
>
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index 2aea4bc..cea8cd3 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -188,6 +188,7 @@ static int palmas_usb_probe(struct platform_device *pdev)
>
> palmas_usb->edev.supported_cable = palmas_extcon_cable;
> palmas_usb->edev.dev.parent = palmas_usb->dev;
> + palmas_usb->edev.name = "palmas_usb";
> palmas_usb->edev.mutually_exclusive = mutually_exclusive;
>
> status = extcon_dev_register(&palmas_usb->edev);
>
> Cheers
> Kishon
>
If node name is same as extcon device name, don't need some modification.
Also, you can modify node name in some OMAP dts file insead of modification of
extcon-palmas.c
Thanks,
Chanwoo Choi
--
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 3/6] PM / Voltagedomain: introduce voltage domain driver support
Quoting Nishanth Menon (2014-03-10 12:25:43) > On 03/10/2014 01:01 PM, Mark Brown wrote: > > On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote: > > > >> The only other options are: > >> a) Abstract it at a higher level at "user drivers", since they are > >> aware of the sequencing needs - but this partially defeats the > >> purpose, unless ofcourse, we do a tricky implementation such as: > >> clk a, b, c -> prenotifiers in a, postnotifiers in c (which as you > >> mentioned is a little trickier to get right). > >> b) introduce a higher level generic dvfs function[1] which does not > >> seem very attractive either. I disagree that a higher level DVFS interface is unattractive. I think it has taken a while to get there but people are finally interested in this. A small amount of discussion about this took place at Linaro Connect earlier this month (just hallway talk) but we shouldn't rule out the idea of a general framework for managing DVFS, which frankly is complex enough to merit not being shoved into the clock layer. > > > >> Any other suggestions other than limiting the usage(and documenting it > >> so) and hoping for a future evolution to take this into consideration? > > > > Something might be doable with telling the clock API about maintianing > > ratios between clocks? I do think we should have an idea where we'd go > > with such requirements, even if we don't currently handle it, so that we > > can hopefully avoid another round of refactoring everything but it > > doesn't seem 100% essential, just very nice to have. This sounds reasonable but I must point out that the clock framework today (based on the existing clk.h api) does not have a single instance of constraint-based logic. For instance there is no clk_set_min_rate or clk_set_max_rate or clk_set_rate_range. These have been discussed before but I feel that pushing something before now would have been premature given that the level of discussion around those features never hit critical mass. So the ratio thing is sensible, but it would be the first constraint-like mechanism in the clock framework so what that looks like bares careful consideration. > > > Mike, > Any suggestions about the above? could we use composite clocks in some > manner here(even though I think the original intent of the same was > not the same)? NACK. Let's just model the hardware in the clock framework, please. If you need to invent fake clocks to represent other constructs then it means the framework is missing something (or we're missing an entire framework, e.g. DVFS). Regards, Mike > > -- > Regards, > Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
* Arnd Bergmann [140319 14:01]:
> On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> > * Arnd Bergmann [140319 12:33]:
> > > The OMAP H2, OSK and OSIRIS machines cannot build without
> > > I2C and TPS65010 both enabled unconditionally.
> > >
> > > In each case, failing to enable CONFIG_I2C results in a
> > > build or link error, so most consistent solution is to
> > > ensure that it is impossible to disable those options.
> > >
> > > It would be nice to leave CONFIG_I2C as user-selectable,
> > > but doing that properly would require more work.
> >
> > We should not select drivers. How about let's just have
> > the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> > those boards?
>
> Good idea. Like this?
Looks good to me :)
Acked-by: Tony Lindgren
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index fd90caf..65d2acb 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
>
> static int tps_setup(struct i2c_client *client, void *context)
> {
> + if (!IS_BUILTIN(CONFIG_TPS65010))
> + return -ENOSYS;
> +
> tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
> TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index d68909b..3a02621 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
>
> static int osk_tps_setup(struct i2c_client *client, void *context)
> {
> + if (!IS_BUILTIN(CONFIG_TPS65010))
> + return -ENOSYS;
> +
> /* Set GPIO 1 HIGH to disable VBUS power supply;
>* OHCI driver powers it up/down as needed.
>*/
>
> --
> 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: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:
> * Arnd Bergmann [140319 12:33]:
> > The OMAP H2, OSK and OSIRIS machines cannot build without
> > I2C and TPS65010 both enabled unconditionally.
> >
> > In each case, failing to enable CONFIG_I2C results in a
> > build or link error, so most consistent solution is to
> > ensure that it is impossible to disable those options.
> >
> > It would be nice to leave CONFIG_I2C as user-selectable,
> > but doing that properly would require more work.
>
> We should not select drivers. How about let's just have
> the tps65010 stuff behind an ifdef CONFIG_TPS65010 for
> those boards?
Good idea. Like this?
Arnd
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fd90caf..65d2acb 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
static int tps_setup(struct i2c_client *client, void *context)
{
+ if (!IS_BUILTIN(CONFIG_TPS65010))
+ return -ENOSYS;
+
tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index d68909b..3a02621 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
static int osk_tps_setup(struct i2c_client *client, void *context)
{
+ if (!IS_BUILTIN(CONFIG_TPS65010))
+ return -ENOSYS;
+
/* Set GPIO 1 HIGH to disable VBUS power supply;
* OHCI driver powers it up/down as needed.
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
* Arnd Bergmann [140319 12:33]: > The OMAP H2, OSK and OSIRIS machines cannot build without > I2C and TPS65010 both enabled unconditionally. > > In each case, failing to enable CONFIG_I2C results in a > build or link error, so most consistent solution is to > ensure that it is impossible to disable those options. > > It would be nice to leave CONFIG_I2C as user-selectable, > but doing that properly would require more work. We should not select drivers. How about let's just have the tps65010 stuff behind an ifdef CONFIG_TPS65010 for those boards? Regards, Tony > Signed-off-by: Arnd Bergmann > Cc: Tony Lindgren > Cc: linux-omap@vger.kernel.org > --- > arch/arm/mach-omap1/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig > index cdd05f2..23ab1d5 100644 > --- a/arch/arm/mach-omap1/Kconfig > +++ b/arch/arm/mach-omap1/Kconfig > @@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR > config MACH_OMAP_H2 > bool "TI H2 Support" > depends on ARCH_OMAP1 && ARCH_OMAP16XX > + select TPS65010 > + select I2C > help > TI OMAP 1610/1611B H2 board support. Say Y here if you have such > a board. > @@ -64,6 +66,8 @@ config MACH_HERALD > config MACH_OMAP_OSK > bool "TI OSK Support" > depends on ARCH_OMAP1 && ARCH_OMAP16XX > + select TPS65010 > + select I2C > help > TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here >if you have such a board. > -- > 1.8.3.2 > -- 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 23/62] ARM: omap1: fix building without 32K_TIMER
* Felipe Balbi [140319 13:06]:
> On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> > >
> > > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in
> > > this function)
> > > while (enable_dyn_sleep) {
> > > ^
> > > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only
> > > once for each function it appears in
> > >
> > > This attempts to fix the #ifdef logic to deal with all combinations
> > > of timers.
> > >
> > > Signed-off-by: Arnd Bergmann
> > > Cc: linux-omap@vger.kernel.org
> > > Cc: Tony Lindgren
> >
> > I had sent a fix for months and months ago, what happened to it ?
>
> Here
>
> http://marc.info/?l=linux-omap&m=138963632408031&w=2
>
> Tony, did you forget to send a pull request ?
Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.
I must have gotten interrupted while applying and then probably
ran git reset --hard before committing.
Arnd, maybe pick up Felipe's earlier patch instead?
Acked-by: Tony Lindgren
--
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 23/62] ARM: omap1: fix building without 32K_TIMER
On Wed, Mar 19, 2014 at 02:59:13PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> > If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> > not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
> >
> > mach-omap1/pm.c: In function 'omap1_pm_idle':
> > mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in
> > this function)
> > while (enable_dyn_sleep) {
> > ^
> > mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only
> > once for each function it appears in
> >
> > This attempts to fix the #ifdef logic to deal with all combinations
> > of timers.
> >
> > Signed-off-by: Arnd Bergmann
> > Cc: linux-omap@vger.kernel.org
> > Cc: Tony Lindgren
>
> I had sent a fix for months and months ago, what happened to it ?
Here
http://marc.info/?l=linux-omap&m=138963632408031&w=2
Tony, did you forget to send a pull request ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
Hi,
On Wed, Mar 19, 2014 at 08:29:20PM +0100, Arnd Bergmann wrote:
> If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
> not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
>
> mach-omap1/pm.c: In function 'omap1_pm_idle':
> mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in
> this function)
> while (enable_dyn_sleep) {
> ^
> mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once
> for each function it appears in
>
> This attempts to fix the #ifdef logic to deal with all combinations
> of timers.
>
> Signed-off-by: Arnd Bergmann
> Cc: linux-omap@vger.kernel.org
> Cc: Tony Lindgren
I had sent a fix for months and months ago, what happened to it ?
> ---
> arch/arm/mach-omap1/pm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 40a1ae3..7dff68e 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -71,10 +71,10 @@ static unsigned int
> mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
> static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
> static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> -
> static unsigned short enable_dyn_sleep = 1;
>
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> +
> static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
>char *buf)
> {
> @@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
> static int __init omap_pm_init(void)
> {
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> int error;
> #endif
>
> @@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
> omap_pm_init_debugfs();
> #endif
>
> -#ifdef CONFIG_OMAP_32K_TIMER
> +#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
> error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
> if (error)
> printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
> --
> 1.8.3.2
>
> --
> 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
--
balbi
signature.asc
Description: Digital signature
[PATCH 00/62] arm-soc randconfig fixes
Hi everyone, This is my much too long series of mostly trivial build for ARM platform code. It's about a third of the total set of patches I have in a local tree that I use for build testing randconfig kernels. Most of the other patches are for device drivers, but there is also a significant chunk for ARM architecture code, and a few things that are controversial or not yet properly fixed. I'd like to put all or most of these into a branch in arm-soc for the coming merge window. Acks are very much appreciated, as as Naks when I got something wrong. Everything I don't hear back from I will assume is ok and put in. Statistically speaking, I probably made a couple of mistakes here, so please have a look if you find the time. Arnd Bergmann (62): ARM: at91: split out at91x40 into a top-level option ARM: at91: don't provide dt init code for at91x40 ARM: at91: export sam9_smc interfaces ARM: at91: fix broken "if () else" statement ARM: at91: sama5 always uses DT ARM: davinci: export da8xx_syscfg0_base ARM: davinci: make dm644x-evm phy fixup conditional ARM: davinci: use explicit 'select' for DA850_EVM ARM: efm32: allow uncompress debug output ARM: efm32: select AUTO_ZRELADDR ARM: ep93xx: export ep93xx_chip_revision ARM: hisi: fix building without CONFIG_HOTPLUG_CPU ARM: hisi: select HAVE_ARM_SCU only for SMP ARM: imx: imx6q_set_lpm is only defined for CONFIG_PM=y ARM: ixp4xx/omixp: always include linux/leds.h ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.h ARM: ixp4xx: fix gpio rework ARM: ks8695/og: make PCI setup conditional ARM: lpc32xx: export lpc32xx_return_iram_size ARM: msm: add missing include of linux/module.h ARM: msm: avoid calling debug_ll_addr on !MMU ARM: msm: export legacy DMA interfaces ARM: omap1: fix building without 32K_TIMER ARM: omap1: select I2C where needed for PMIC ARM: mvebu: add missing header ARM: mvebu: don't select CONFIG_NEON ARM: orion5x: make dns323 independent of PHY support ARM: pxa: FB_W100 must be built-in ARM: pxa: don't "select" SMC91X on MACH_XCEP ARM: pxa: enable pxafb unconditionally for some boards ARM: pxa: fix colibri build ARM: pxa: fix pxa_ssp_* declarations ARM: pxa: remove broken balloon3_gpio_vbus reference ARM: pxa: select I2C_GPIO only if I2C is on ARM: pxa: trizeps4 and trizeps4wl use the same file ARM: rpc: autoselect CPU_SA110 ARM: sa1100/pxa: fix MTD_XIP build ARM: footbridge: don't build floppy code for addin mode ARM: footbridge: fix build with PCI disabled ARM: footbridge: make screen_info setup conditional ARM: realview: fix sparsemem build ARM: realview: use explicit core tile config options ARM: integrator: only select pl01x if TTY is enabled ARM: integrator: refine CPU selection ARM: s3c24xx: MINI2440 needs I2C for EEPROM_AT24 ARM: s3c24xx: fix gta02 build error ARM: s3c64xx: MACH_SMDK6400 needs HSMMC1 ARM: s3c64xx: select power domains only when used ARM: s5p64x0: fix building with only one soc type ARM: s5pv210: enable IDE support in MACH_TORBRECK ARM: samsung: allow serial driver to be disabled ARM: samsung: disable decompressor watchdog on exynos ARM: samsung: fix SAMSUNG_PM_DEBUG Kconfig logic ARM: samsung: select ATAGS where necessary ARM: samsung: select CRC32 for SAMSUNG_PM_CHECK ARM: samsung: select I2C where needed for PMIC ARM: exynos: fix l2x0 saved regs handling ARM: exynos: add missing include of linux/module.h ARM: shmobile: ak4642 needs i2c support ARM: shmobile: work around CONFIG_PHYLIB=m ARM: sunxi: fix build for THUMB2_KERNEL ARM: tegra: make debug_ll code build for ARMv6 arch/arm/Kconfig | 9 - arch/arm/Kconfig.debug | 2 +- arch/arm/include/debug/tegra.S | 18 - arch/arm/mach-at91/Kconfig | 23 +-- arch/arm/mach-at91/Kconfig.non_dt| 8 +--- arch/arm/mach-at91/at91sam9260_devices.c | 4 +- arch/arm/mach-at91/sam9_smc.c| 3 ++ arch/arm/mach-at91/setup.c | 2 +- arch/arm/mach-davinci/Kconfig| 7 +--- arch/arm/mach-davinci/board-dm644x-evm.c | 11 +++--- arch/arm/mach-davinci/devices-da8xx.c| 1 + arch/arm/mach-ep93xx/core.c | 1 + arch/arm/mach-exynos/common.c| 6 ++- arch/arm/mach-exynos/cpuidle.c | 1 + arch/arm/mach-footbridge/Kconfig | 2 +- arch/arm/mach-footbridge/Makefile| 3 +- arch/arm/mach-footbridge/cats-hw.c | 2 + arch/arm/mach-hisi/Kconfig | 2 +- arch/arm/mach-hisi/Makefile | 3 +- arch/arm/mach-hisi/hotplug.c | 2 + arch/arm/mach-imx/clk-imx6q.c| 3 +- arch/arm/mach-imx/clk-imx6sl.c | 3 +- arch/arm/mach-imx/cpuidle-imx6sl.c | 3 ++ arch/arm/mach-integrator/Kconfig | 19 -- arch/arm/mach-ixp4xx/common.c
[PATCH 24/62] ARM: omap1: select I2C where needed for PMIC
The OMAP H2, OSK and OSIRIS machines cannot build without I2C and TPS65010 both enabled unconditionally. In each case, failing to enable CONFIG_I2C results in a build or link error, so most consistent solution is to ensure that it is impossible to disable those options. It would be nice to leave CONFIG_I2C as user-selectable, but doing that properly would require more work. Signed-off-by: Arnd Bergmann Cc: Tony Lindgren Cc: linux-omap@vger.kernel.org --- arch/arm/mach-omap1/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index cdd05f2..23ab1d5 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR config MACH_OMAP_H2 bool "TI H2 Support" depends on ARCH_OMAP1 && ARCH_OMAP16XX + select TPS65010 + select I2C help TI OMAP 1610/1611B H2 board support. Say Y here if you have such a board. @@ -64,6 +66,8 @@ config MACH_HERALD config MACH_OMAP_OSK bool "TI OSK Support" depends on ARCH_OMAP1 && ARCH_OMAP16XX + select TPS65010 + select I2C help TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here if you have such a board. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/62] ARM: omap1: fix building without 32K_TIMER
If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but
not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:
mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this
function)
while (enable_dyn_sleep) {
^
mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once
for each function it appears in
This attempts to fix the #ifdef logic to deal with all combinations
of timers.
Signed-off-by: Arnd Bergmann
Cc: linux-omap@vger.kernel.org
Cc: Tony Lindgren
---
arch/arm/mach-omap1/pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 40a1ae3..7dff68e 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,10 +71,10 @@ static unsigned int
mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifdef CONFIG_OMAP_32K_TIMER
-
static unsigned short enable_dyn_sleep = 1;
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
+
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
@@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
static int __init omap_pm_init(void)
{
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
int error;
#endif
@@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
omap_pm_init_debugfs();
#endif
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
if (error)
printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
--
1.8.3.2
--
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: rts-gpio DT binding
Hi, On Wed, Mar 19, 2014 at 05:02:56PM +, Mark Jackson wrote: > >> Okay ... it comes back to me now. > >> > >> When using RS485 drivers, we're not actually using RTS as a "Ready > >> To Send", we're really using it as an "enable RS485 driver". > >> > >> I just used the "RTS" mnemonic as "we're now wanting to send some > >> data so please now enable the RS485 driver", rather than the normal > >> "I'm ready for your to send me some data". > >> > >> So it's the opposite function. > >> > >> Maybe it was a poor choice of abbreviation ? > >> > >> As I said before, RS485 drivers might have active or active low > >> enables, so we might need to invert the "RTS" polarity. This is > >> not handled by the hardware RTS signal. > >> > >> Is that a good enough explanation ? > > > > fair, but considering you can toggle RTS by hand with writes to MCR > > register, I still don't see the need for remuxing the lines as GPIOs. > > > > Just don't use auto-RTS and toggle the line by hand with MCR, no ? > > TBH I hadn't realised you could do that, so I guess you could. > > But my solution seems more flexible as it would allow you to add an RTS > signal to UART0 and UART5 which don't have any hardware handshaking lines. fair, but at least turn into helper functions part of serial core so that other serial drivers have a chance of reusing this. IMHO, it's a pretty ugly hack, but then again, a bunch of current in-kernel GPIO usage is, anyway. -- balbi signature.asc Description: Digital signature
Re: rts-gpio DT binding
On 19/03/14 14:59, Felipe Balbi wrote: > Hi, > > On Wed, Mar 19, 2014 at 09:15:03AM +, Mark Jackson wrote: [snip] >> >> Okay ... it comes back to me now. >> >> When using RS485 drivers, we're not actually using RTS as a "Ready >> To Send", we're really using it as an "enable RS485 driver". >> >> I just used the "RTS" mnemonic as "we're now wanting to send some >> data so please now enable the RS485 driver", rather than the normal >> "I'm ready for your to send me some data". >> >> So it's the opposite function. >> >> Maybe it was a poor choice of abbreviation ? >> >> As I said before, RS485 drivers might have active or active low >> enables, so we might need to invert the "RTS" polarity. This is >> not handled by the hardware RTS signal. >> >> Is that a good enough explanation ? > > fair, but considering you can toggle RTS by hand with writes to MCR > register, I still don't see the need for remuxing the lines as GPIOs. > > Just don't use auto-RTS and toggle the line by hand with MCR, no ? TBH I hadn't realised you could do that, so I guess you could. But my solution seems more flexible as it would allow you to add an RTS signal to UART0 and UART5 which don't have any hardware handshaking lines. Mark J. -- 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: [RESEND PATCH 0/3] ARM: OMAP2+: Remove remaining unused legacy code
* Javier Martinez Canillas [140318 23:12]: > Once OMAP2+ board files are removed, there is unused code that was only used > by legacy platform code and can be removed. > > This patch-set depends on the series: > > [PATCH 00/12] Drop omap3 board files and make mach-omap2 boot in DT only mode > [0] > > and is composed of the following patches: > > [RESEND PATCH 1/3] ARM: OMAP2+: Remove legacy smsc911x and smc91x > [RESEND PATCH 2/3] ARM: OMAP2+: Remove unnecesary include in GPMC > [RESEND PATCH 3/3] ARM: OMAP2+: Remove legacy board-flash.c > > Tony, > > I don't know what is your new schedule for board files removal but in case it > is > 3.16, I forward ported this patch-set on top of 3.14-rc7 and fixed some > conflicts. Thanks, I'll also rebase my changes in omap-for-v3.14/omap3-board-removal at some point. Probably a good target is v3.16 if the DSS changes go in. Then we just need displays enabled for omap3 and pandora supported to drop the legacy data AFAIK. Regards, Tony > [0]: http://marc.info/?t=13854250461&r=1&w=2 > -- 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] mfd: twl-core: Fix accessibility of some twl4030 audio registers
* Lee Jones [140318 13:23]:
> > > > There are some unused registers in twl4030 at I2C address 0x49 and
> > > > function
> > > > twl4030_49_nop_reg() is used to check accessibility of that registers.
> > > > These
> > > > registers are written in decimal format but the values are correct in
> > > > hexadecimal format. (It can be checked few lines above the patched code
> > > > -
> > > > these registers are marked as unused there.)
> > > >
> > > > As a consequence three registers of audio submodule are treated as
> > > > inaccessible (preamplifier carkit right and both handsfree registers).
> > > >
> > > > CC: Peter Ujfalusi
> > > > Signed-off-by: Tomas Novotny
> > > > ---
> > > > drivers/mfd/twl-core.c | 10 +-
> > > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> > > > index ed71832..e87140b 100644
> > > > --- a/drivers/mfd/twl-core.c
> > > > +++ b/drivers/mfd/twl-core.c
> > > > @@ -282,11 +282,11 @@ static struct reg_default twl4030_49_defaults[] =
> > > > {
> > > > static bool twl4030_49_nop_reg(struct device *dev, unsigned int reg)
> > > > {
> > > > switch (reg) {
> > > > - case 0:
> > > > - case 3:
> > > > - case 40:
> > > > - case 41:
> > > > - case 42:
> > > > + case 0x00:
> > > > + case 0x03:
> > > > + case 0x40:
> > > > + case 0x41:
> > > > + case 0x42:
> > >
> > > Uhm, I can not be that @#$%^& that I did this... I have no idea how I
> > > left out
> > > the "0x"
> > >
> > > Thanks for spotting it!
> > >
> > > Acked-by Peter Ujfalusi
> >
> > Peter, if this does not make it to the -rc series, care to send this to
> > the stable for inclusion after it hits mainline?
> >
> > This fixes twl4030 audio regression at least on boards using HandsfreeL
> > for audio.
>
> I think it's a little late in the cycle to send this to the -rcs.
>
> Stable will be Cc'ed however.
That's fine with me thanks.
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
[PATCH v2] ARM: dts: OMAP5: add pmu node
Expose the PMU on OMAP5.
Tested with perf on OMAP5 uEVM.
Signed-off-by: Nathan Lynch
---
Changes since v1:
- Use symbolic constants.
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a9663e..ccb38944c85a 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -76,6 +76,12 @@
;
};
+ pmu {
+ compatible = "arm,cortex-a15-pmu";
+ interrupts = ,
+;
+ };
+
gic: interrupt-controller@48211000 {
compatible = "arm,cortex-a15-gic";
interrupt-controller;
--
1.8.3.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: DSS DT changes
* Tomi Valkeinen [140319 04:29]: > Hi Tony, > > Is it too late to get the DSS dts changes via arm tree? Yes too late.. > I now got everything working fine so that the dts changes and the > omapdss driver changes can be merged independently. It would be cleaner > if dts changes can go through the proper channel. > > If you can still take them, I've attached the patches, based on your > omap-for-v3.15/dt branch. > > I also attached the bindings docs. Those I can take via my tree, but I'm > not sure if they are supposed to go with the dts changes or with the > driver changes, so I have them here also. > > And I've pushed the changes to my tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git > > The branches are: > > 3.15/dss-dt-dts - contains the .dts changes > 3.15/dss-dt - contains the driver changes + binding docs These look OK to me and would be good to get in so we can move on with dropping more legacy platform data. As you have my acks there, so please feel free to send your 3.15/dss-dt-dts along with the DSS patches after the arm-soc branches have been merged. 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: pandaboard boot crash with linux-next
[cc'ing linux-next ml] On Wed, Mar 19, 2014 at 2:35 PM, Pantelis Antoniou wrote: > Hi Tomi, > > On Mar 19, 2014, at 4:33 PM, Tomi Valkeinen wrote: > >> On 19/03/14 16:29, Pantelis Antoniou wrote: >>> Hi Tomi, >>> >>> On Mar 19, 2014, at 4:25 PM, Tomi Valkeinen wrote: >>> On 17/03/14 16:09, Tomi Valkeinen wrote: > Hi, > > I noticed that my omap4 panda does not boot with today's linux-next > (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to > study > it, but I didn't find any posts about the issue with a quick look. Below > is > the crash. I bisected this to the commit: commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f Author: Pantelis Antoniou Date: Fri Dec 13 20:08:59 2013 +0200 of: device_node kobject lifecycle fixes After the move to having device nodes be proper kobjects the lifecycle of the node needs to be controlled better. At first convert of_add_node() in the unflattened functions to of_init_node() which initializes the kobject so that of_node_get/put work correctly even before of_init is called. Afterwards introduce of_node_is_initialized & of_node_is_attached that query the underlying kobject about the state (attached means kobj is visible in sysfs) Using that make sure the lifecycle of the tree is correct at all times. Signed-off-by: Pantelis Antoniou [grant.likely: moved of_node_init() calls, fixed up locking, and dropped __of_populate() hunks] Signed-off-by: Grant Likely >>> >>> Can you try this? It should fix it (plus it should be in -next soon) >> >> Thanks, that fixes the issue (tested on omap4 panda). >> >> Tomi >> > > Yeah I know; my beaglebone hangs as well without it :) Hi Tomi, Pantelis sent the fix to me yesterday, but I hadn't tested and pushed it out until now. Tomorrow's linux-next it should be okay. g. -- 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: rts-gpio DT binding
Hi, On Wed, Mar 19, 2014 at 09:15:03AM +, Mark Jackson wrote: > On 18/03/14 17:11, Felipe Balbi wrote: > > On Tue, Mar 18, 2014 at 05:04:47PM +, Mark Jackson wrote: > >> On 18/03/14 16:55, Felipe Balbi wrote: > >>> Hi Mark, > >>> > >>> I'm looking at the omap-serial driver and saw that you added rts-gpio > >>> binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add > >>> RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both > >>> actual RTS signals. > >>> > >>> Instead of adding that extra GPIO handling, why didn't you just mux > >>> those signals as RTS and enable auto-RTS/auto-CTS feature ? > >>> > >>> It looks to me like that's highly unnecessary binding. > >> > >> I agree !! > >> > >> I think it was to allow delays pre- and post- sending the comms data. > >> > >> Several RS485 drivers require a "warm up" time before they will > >> transmit data correctly, and also need a "cool down" time to prevent > >> clipping of the last few bits of data. > >> > >> IIRC the built-in RTS handling did not allow for this. > > > > you might be right here. I can't find anywhere to write rts delays. > > Weird... digging TRM. > > > >> It also allows the RTS signal to be "inverted", again required for > >> some RS485 driver chips. > >> > >> However, I'll dig into why I did this and report back. > > > > cool, thanks > > Okay ... it comes back to me now. > > When using RS485 drivers, we're not actually using RTS as a "Ready > To Send", we're really using it as an "enable RS485 driver". > > I just used the "RTS" mnemonic as "we're now wanting to send some > data so please now enable the RS485 driver", rather than the normal > "I'm ready for your to send me some data". > > So it's the opposite function. > > Maybe it was a poor choice of abbreviation ? > > As I said before, RS485 drivers might have active or active low > enables, so we might need to invert the "RTS" polarity. This is > not handled by the hardware RTS signal. > > Is that a good enough explanation ? fair, but considering you can toggle RTS by hand with writes to MCR register, I still don't see the need for remuxing the lines as GPIOs. Just don't use auto-RTS and toggle the line by hand with MCR, no ? -- balbi signature.asc Description: Digital signature
Re: pandaboard boot crash with linux-next
Hi Tomi, On Mar 19, 2014, at 4:25 PM, Tomi Valkeinen wrote: > On 17/03/14 16:09, Tomi Valkeinen wrote: >> Hi, >> >> I noticed that my omap4 panda does not boot with today's linux-next >> (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study >> it, but I didn't find any posts about the issue with a quick look. Below is >> the crash. > > I bisected this to the commit: > > commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f > Author: Pantelis Antoniou > Date: Fri Dec 13 20:08:59 2013 +0200 > >of: device_node kobject lifecycle fixes > >After the move to having device nodes be proper kobjects the lifecycle >of the node needs to be controlled better. > >At first convert of_add_node() in the unflattened functions to >of_init_node() which initializes the kobject so that of_node_get/put >work correctly even before of_init is called. > >Afterwards introduce of_node_is_initialized & of_node_is_attached that >query the underlying kobject about the state (attached means kobj >is visible in sysfs) > >Using that make sure the lifecycle of the tree is correct at all >times. > >Signed-off-by: Pantelis Antoniou >[grant.likely: moved of_node_init() calls, fixed up locking, and > dropped __of_populate() hunks] >Signed-off-by: Grant Likely > Can you try this? It should fix it (plus it should be in -next soon) Regards -- Pantelis --8<-8< commit be9577a6f756beaa87fd2073e3c74a8a608c37dc Author: Pantelis Antoniou Date: Tue Mar 18 16:26:47 2014 +0200 of: of_add_property remove if semicolon. This semicolon shouldn't be there obviously, so remove it. Signed-off-by: Pantelis Antoniou diff --git a/drivers/of/base.c b/drivers/of/base.c index 08156e6..887f4b0 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1821,7 +1821,7 @@ int of_add_property(struct device_node *np, struct property *prop) if (rc) return rc; - if (of_node_is_attached(np)); + if (of_node_is_attached(np)) __of_add_property_sysfs(np, prop); return rc; --8<-8< > >> >> Tomi >> >> [0.00] ti_dt_clocks_register: failed to lookup clock node div_ts_ck >> [0.00] ti_dt_clocks_register: failed to lookup clock node >> bandgap_ts_fclk >> [0.00] Unable to handle kernel NULL pointer dereference at virtual >> address 004c >> [0.00] pgd = c0004000 >> [0.00] [004c] *pgd= >> [0.00] Internal error: Oops: 5 [#1] SMP ARM >> [0.00] Modules linked in: >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.14.0-rc6-next-20140317-09382-g8808b950581f #104 >> [0.00] task: c088ddf8 ti: c0882000 task.ti: c0882000 >> [0.00] PC is at kernfs_find_ns+0x14/0x13c >> [0.00] LR is at kernfs_find_and_get_ns+0x38/0x54 >> [0.00] pc : []lr : []psr: 61d3 >> [0.00] sp : c0883e00 ip : c0883e30 fp : c0883e2c >> [0.00] r10: c0891114 r9 : ebfa11c0 r8 : ebfcd464 >> [0.00] r7 : r6 : r5 : c07c1814 r4 : c08e9ad8 >> [0.00] r3 : c08f568c r2 : r1 : c07c1814 r0 : >> [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM >> Segment kernel >> [0.00] Control: 10c5387d Table: 8000404a DAC: 0015 >> [0.00] Process swapper/0 (pid: 0, stack limit = 0xc0882248) >> [0.00] Stack: (0xc0883e00 to 0xc0884000) >> [0.00] 3e00: c08e9ad8 c07c1814 c08e9ad8 c07c1814 >> ebfcd464 >> [0.00] 3e20: c0883e4c c0883e30 c019628c c0196074 c07c1814 >> c07c1814 ebfcd490 >> [0.00] 3e40: c0883e6c c0883e50 c04c6180 c0196260 c0891140 c07c1814 >> ebfcd490 0001 >> [0.00] 3e60: c0883e9c c0883e70 c04c7308 c04c6160 c008a208 c008a130 >> c0883e9c >> [0.00] 3e80: c07c1814 c0891140 ebfcd464 a1d3 c0883ec4 c0883ea0 >> c04c7c9c c04c72cc >> [0.00] 3ea0: c0882000 ebfcd464 c074dcc8 c086bf64 0001 c074de24 >> c0883ee4 c0883ec8 >> [0.00] 3ec0: c0824b70 c04c7c14 c0891114 c0938af8 c074dcc8 >> c0883f54 c0883ee8 >> [0.00] 3ee0: c0824c58 c0824b18 c0e8bf6c c0882000 >> c0883f14 c0883f08 >> [0.00] 3f00: c05bc6b4 c05bc44c c0883f34 c0883f18 c04cca04 c05bc6b0 >> >> [0.00] 3f20: eb016b80 c0882000 c0883f4c c0883f38 c0938af8 c08910c0 >> c074dcc8 c074de24 >> [0.00] 3f40: c086ad60 c088a880 c0883f7c c0883f58 c0824f5c c0824c20 >> 0001 c0883f68 >> [0.00] 3f60: 0001 c09380c0 c0882000 c0883f8c c0883f80 >> c0825250 c0824f1c >> [0.00] 3f80: c0883f9c c0883f90 c0825400 c0825238 c0883fac c0883fa0 >> c081d67c c08253fc >> [0.00] 3fa0: c0883ff4 c0883fb0 c0819a30 c081d664
Re: pandaboard boot crash with linux-next
Hi Tomi, On Mar 19, 2014, at 4:33 PM, Tomi Valkeinen wrote: > On 19/03/14 16:29, Pantelis Antoniou wrote: >> Hi Tomi, >> >> On Mar 19, 2014, at 4:25 PM, Tomi Valkeinen wrote: >> >>> On 17/03/14 16:09, Tomi Valkeinen wrote: Hi, I noticed that my omap4 panda does not boot with today's linux-next (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study it, but I didn't find any posts about the issue with a quick look. Below is the crash. >>> >>> I bisected this to the commit: >>> >>> commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f >>> Author: Pantelis Antoniou >>> Date: Fri Dec 13 20:08:59 2013 +0200 >>> >>> of: device_node kobject lifecycle fixes >>> >>> After the move to having device nodes be proper kobjects the lifecycle >>> of the node needs to be controlled better. >>> >>> At first convert of_add_node() in the unflattened functions to >>> of_init_node() which initializes the kobject so that of_node_get/put >>> work correctly even before of_init is called. >>> >>> Afterwards introduce of_node_is_initialized & of_node_is_attached that >>> query the underlying kobject about the state (attached means kobj >>> is visible in sysfs) >>> >>> Using that make sure the lifecycle of the tree is correct at all >>> times. >>> >>> Signed-off-by: Pantelis Antoniou >>> [grant.likely: moved of_node_init() calls, fixed up locking, and >>> dropped __of_populate() hunks] >>> Signed-off-by: Grant Likely >>> >> >> Can you try this? It should fix it (plus it should be in -next soon) > > Thanks, that fixes the issue (tested on omap4 panda). > > Tomi > Yeah I know; my beaglebone hangs as well without it :) > Regards -- Pantelis -- 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: pandaboard boot crash with linux-next
On 19/03/14 16:29, Pantelis Antoniou wrote: > Hi Tomi, > > On Mar 19, 2014, at 4:25 PM, Tomi Valkeinen wrote: > >> On 17/03/14 16:09, Tomi Valkeinen wrote: >>> Hi, >>> >>> I noticed that my omap4 panda does not boot with today's linux-next >>> (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study >>> it, but I didn't find any posts about the issue with a quick look. Below is >>> the crash. >> >> I bisected this to the commit: >> >> commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f >> Author: Pantelis Antoniou >> Date: Fri Dec 13 20:08:59 2013 +0200 >> >>of: device_node kobject lifecycle fixes >> >>After the move to having device nodes be proper kobjects the lifecycle >>of the node needs to be controlled better. >> >>At first convert of_add_node() in the unflattened functions to >>of_init_node() which initializes the kobject so that of_node_get/put >>work correctly even before of_init is called. >> >>Afterwards introduce of_node_is_initialized & of_node_is_attached that >>query the underlying kobject about the state (attached means kobj >>is visible in sysfs) >> >>Using that make sure the lifecycle of the tree is correct at all >>times. >> >>Signed-off-by: Pantelis Antoniou >>[grant.likely: moved of_node_init() calls, fixed up locking, and >> dropped __of_populate() hunks] >>Signed-off-by: Grant Likely >> > > Can you try this? It should fix it (plus it should be in -next soon) Thanks, that fixes the issue (tested on omap4 panda). Tomi signature.asc Description: OpenPGP digital signature
Re: pandaboard boot crash with linux-next
On 17/03/14 16:09, Tomi Valkeinen wrote: > Hi, > > I noticed that my omap4 panda does not boot with today's linux-next > (8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study > it, but I didn't find any posts about the issue with a quick look. Below is > the crash. I bisected this to the commit: commit ad2c12e9bc250b3387bcb4ab9ab114f43ff6122f Author: Pantelis Antoniou Date: Fri Dec 13 20:08:59 2013 +0200 of: device_node kobject lifecycle fixes After the move to having device nodes be proper kobjects the lifecycle of the node needs to be controlled better. At first convert of_add_node() in the unflattened functions to of_init_node() which initializes the kobject so that of_node_get/put work correctly even before of_init is called. Afterwards introduce of_node_is_initialized & of_node_is_attached that query the underlying kobject about the state (attached means kobj is visible in sysfs) Using that make sure the lifecycle of the tree is correct at all times. Signed-off-by: Pantelis Antoniou [grant.likely: moved of_node_init() calls, fixed up locking, and dropped __of_populate() hunks] Signed-off-by: Grant Likely > > Tomi > > [0.00] ti_dt_clocks_register: failed to lookup clock node div_ts_ck > [0.00] ti_dt_clocks_register: failed to lookup clock node > bandgap_ts_fclk > [0.00] Unable to handle kernel NULL pointer dereference at virtual > address 004c > [0.00] pgd = c0004000 > [0.00] [004c] *pgd= > [0.00] Internal error: Oops: 5 [#1] SMP ARM > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.14.0-rc6-next-20140317-09382-g8808b950581f #104 > [0.00] task: c088ddf8 ti: c0882000 task.ti: c0882000 > [0.00] PC is at kernfs_find_ns+0x14/0x13c > [0.00] LR is at kernfs_find_and_get_ns+0x38/0x54 > [0.00] pc : []lr : []psr: 61d3 > [0.00] sp : c0883e00 ip : c0883e30 fp : c0883e2c > [0.00] r10: c0891114 r9 : ebfa11c0 r8 : ebfcd464 > [0.00] r7 : r6 : r5 : c07c1814 r4 : c08e9ad8 > [0.00] r3 : c08f568c r2 : r1 : c07c1814 r0 : > [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment > kernel > [0.00] Control: 10c5387d Table: 8000404a DAC: 0015 > [0.00] Process swapper/0 (pid: 0, stack limit = 0xc0882248) > [0.00] Stack: (0xc0883e00 to 0xc0884000) > [0.00] 3e00: c08e9ad8 c07c1814 c08e9ad8 c07c1814 > ebfcd464 > [0.00] 3e20: c0883e4c c0883e30 c019628c c0196074 c07c1814 > c07c1814 ebfcd490 > [0.00] 3e40: c0883e6c c0883e50 c04c6180 c0196260 c0891140 c07c1814 > ebfcd490 0001 > [0.00] 3e60: c0883e9c c0883e70 c04c7308 c04c6160 c008a208 c008a130 > c0883e9c > [0.00] 3e80: c07c1814 c0891140 ebfcd464 a1d3 c0883ec4 c0883ea0 > c04c7c9c c04c72cc > [0.00] 3ea0: c0882000 ebfcd464 c074dcc8 c086bf64 0001 c074de24 > c0883ee4 c0883ec8 > [0.00] 3ec0: c0824b70 c04c7c14 c0891114 c0938af8 c074dcc8 > c0883f54 c0883ee8 > [0.00] 3ee0: c0824c58 c0824b18 c0e8bf6c c0882000 > c0883f14 c0883f08 > [0.00] 3f00: c05bc6b4 c05bc44c c0883f34 c0883f18 c04cca04 c05bc6b0 > > [0.00] 3f20: eb016b80 c0882000 c0883f4c c0883f38 c0938af8 c08910c0 > c074dcc8 c074de24 > [0.00] 3f40: c086ad60 c088a880 c0883f7c c0883f58 c0824f5c c0824c20 > 0001 c0883f68 > [0.00] 3f60: 0001 c09380c0 c0882000 c0883f8c c0883f80 > c0825250 c0824f1c > [0.00] 3f80: c0883f9c c0883f90 c0825400 c0825238 c0883fac c0883fa0 > c081d67c c08253fc > [0.00] 3fa0: c0883ff4 c0883fb0 c0819a30 c081d664 > c08195d0 > [0.00] 3fc0: c086ad60 10c5387d c088a92c c086ad5c > c088f684 8000406a > [0.00] 3fe0: 412fc09a c0883ff8 80008074 c0819840 > > [0.00] Backtrace: > [0.00] [] (kernfs_find_ns) from [] > (kernfs_find_and_get_ns+0x38/0x54) > [0.00] r8:ebfcd464 r7: r6: r5:c07c1814 r4:c08e9ad8 > [0.00] [] (kernfs_find_and_get_ns) from [] > (safe_name+0x2c/0x98) > [0.00] r7:ebfcd490 r6:c07c1814 r5: r4:c07c1814 > [0.00] [] (safe_name) from [] > (__of_add_property_sysfs+0x48/0xc4) > [0.00] r7:0001 r6:ebfcd490 r5:c07c1814 r4:c0891140 > [0.00] [] (__of_add_property_sysfs) from [] > (of_add_property+0x94/0xa0) > [0.00] r8:a1d3 r7:ebfcd464 r6:c0891140 r5:c07c1814 r4: > [0.00] [] (of_add_property) from [] > (omap_get_timer_dt+0x64/0x108) > [0.00] r8:c074de24 r7:0001 r6:c086bf64 r5:c074dcc8 r4:ebfcd464 > r3:c0882000 > [0.00] [] (omap_get_timer_dt) from
Re: [PATCH 1/2] extcon: of: Remove unnecessary function call by using the name of device_node
Hi,
On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
> This patch remove unnecessary function call in of_extcon_get_extcon_dev()
> by using the name of device_node structure.
>
> Signed-off-by: Chanwoo Choi
> ---
> drivers/extcon/of_extcon.c | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
> index 72173ec..0a29f82 100644
> --- a/drivers/extcon/of_extcon.c
> +++ b/drivers/extcon/of_extcon.c
> @@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
> *dev, int index)
> {
> struct device_node *node;
> struct extcon_dev *edev;
> - struct platform_device *extcon_parent_dev;
>
> if (!dev->of_node) {
> dev_dbg(dev, "device does not have a device node entry\n");
> @@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct device
> *dev, int index)
> return ERR_PTR(-ENODEV);
> }
>
> - extcon_parent_dev = of_find_device_by_node(node);
> - if (!extcon_parent_dev) {
> - dev_dbg(dev, "unable to find device by node\n");
> - return ERR_PTR(-EPROBE_DEFER);
> - }
> -
> - edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
> + edev = extcon_get_extcon_dev(node->name);
Since you no longer want to use device names I think you should add this too to
warn users if they rely on using the device name.
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index bc4c789..025eb39 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -601,7 +601,6 @@ int extcon_dev_register(struct extcon_dev *edev)
edev->dev.class = extcon_class;
edev->dev.release = extcon_dev_release;
- edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
//The user should always pass the 'name' as we no longer use device name while
getting extcon device. And this name should also be the 'node' name?
if (IS_ERR_OR_NULL(edev->name)) {
dev_err(&edev->dev,
"extcon device name is null\n");
Btw changing to node name from device name breaks dwc3 in OMAP5 and you would
need this too..
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 2aea4bc..cea8cd3 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -188,6 +188,7 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_usb->edev.supported_cable = palmas_extcon_cable;
palmas_usb->edev.dev.parent = palmas_usb->dev;
+ palmas_usb->edev.name = "palmas_usb";
palmas_usb->edev.mutually_exclusive = mutually_exclusive;
status = extcon_dev_register(&palmas_usb->edev);
Cheers
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
DSS DT changes
Hi Tony, Is it too late to get the DSS dts changes via arm tree? I now got everything working fine so that the dts changes and the omapdss driver changes can be merged independently. It would be cleaner if dts changes can go through the proper channel. If you can still take them, I've attached the patches, based on your omap-for-v3.15/dt branch. I also attached the bindings docs. Those I can take via my tree, but I'm not sure if they are supposed to go with the dts changes or with the driver changes, so I have them here also. And I've pushed the changes to my tree: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git The branches are: 3.15/dss-dt-dts - contains the .dts changes 3.15/dss-dt - contains the driver changes + binding docs Tomi dss-dt-docs.tar.gz Description: application/gzip dss-dts.tar.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Re: [PATCH] dma: edma: fix incorrect SG list handling
On Wednesday 19 March 2014 10:09 AM, Sekhar Nori wrote: > On Wednesday 19 March 2014 12:16 AM, Joel Fernandes wrote: >> On 03/18/2014 10:28 AM, Vinod Koul wrote: >>> where is this patch, somehow am not able to find in my inbox or archives... >>> >> >> I found it archived here: >> http://comments.gmane.org/gmane.linux.davinci/28569 >> >> Patch doesn't breaking anything for > MAX_NR_SG list size on AM335x, so >> it looks good. >> >> Acked-by: Joel Fernandes > > Joel, thanks for the ack. > > Vinod, Looks like the vger and Intel spam filters dropped the patch. I > will try again. Okay, I see see the patch in dmaengine list archives now and hopefully it has reached Vinod too. I think the issue last time around was that From: and Return-Path: headers ended up having different addresses. Thanks, Sekhar -- 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 v5 1/5] doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue
Add the compatible "ti,am437x-dwc3" for dwc3 glue driver. Signed-off-by: George Cherian Acked-by: Roger Quadros --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be "ti,dwc3" + - compatible : Should be + * "ti,dwc3" for OMAP5 and DRA7 + * "ti,am437x-dwc3" for AM437x - ti,hwmods : Should be "usb_otg_ss" - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the -- 1.8.3.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
[PATCH v5 0/5] Add USB nodes for am43xx epos and gp evm
The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with linux-next + Tony's omap-for-v3.15/dt Changes from v1 -> v2 * Reorder "doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue" * Address v1 coments on "ARM: dts: AM4372: Add USB nodes" Changes from v2 -> v3 * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts and am43x-epos-evm.dts Changes from v3 -> v4 * Refreshed on top of Tony's omap-for-v3.15/dt tree * Added usb_phy0_always_on_clk32k and usb_phy1_always_on_clk32k Patch 2 * Used the above clocks in Patch 3 * Patch 4 and 5 edited the unwanted portions of commit log Changes from v4 -> v5 * Address Roger's comment for the clock data George Cherian (5): doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue ARM: dts: am43xx clock data ARM: dts: AM4372: Add USB nodes ARM: dts: am437x-gp-evm: Enable USB ARM: dts: am43x-epos-evm: Enable USB Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 94 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 18 + arch/arm/boot/dts/am43x-epos-evm.dts | 18 + arch/arm/boot/dts/am43xx-clocks.dtsi | 32 5 files changed, 165 insertions(+), 1 deletion(-) -- 1.8.3.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
[PATCH v5 2/5] ARM: dts: am43xx clock data
Add USB and USB PHY reference clock data
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..5171d3e 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,36 @@
clocks = <&clk_32768_ck>, <&clk_32k_tpm_ck>;
reg = <0x4260>;
};
+
+ usb_phy0_always_on_clk32k: usb_phy0_always_on_clk32k {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&usbphy_32khz_clkmux>;
+ ti,bit-shift = <8>;
+ reg = <0x2a40>;
+ };
+
+ usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&usbphy_32khz_clkmux>;
+ ti,bit-shift = <8>;
+ reg = <0x2a48>;
+ };
+
+ usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_clkdcoldo>;
+ ti,bit-shift = <8>;
+ reg = <0x8a60>;
+ };
+
+ usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_per_clkdcoldo>;
+ ti,bit-shift = <8>;
+ reg = <0x8a68>;
+ };
};
--
1.8.3.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
[PATCH v5 4/5] ARM: dts: am437x-gp-evm: Enable USB
Enable
- USB PHY
- USB
for am437x-gp-evm
Signed-off-by: George Cherian
Acked-by: Roger Quadros
---
arch/arm/boot/dts/am437x-gp-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..9e57538 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -125,3 +125,21 @@
pinctrl-0 = <&mmc1_pins>;
cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};
+
+&usb2_phy1 {
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usb2_phy2 {
+ status = "okay";
+};
+
+&usb2 {
+ dr_mode = "host";
+ status = "okay";
+};
--
1.8.3.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
[PATCH v5 5/5] ARM: dts: am43x-epos-evm: Enable USB
Enable
- USB PHY
- USB
for am43x-epos-evm
Signed-off-by: George Cherian
Acked-by: Roger Quadros
---
arch/arm/boot/dts/am43x-epos-evm.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..1a4946a 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -367,3 +367,21 @@
pinctrl-0 = <&spi1_pins>;
status = "okay";
};
+
+&usb2_phy1 {
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usb2_phy2 {
+ status = "okay";
+};
+
+&usb2 {
+ dr_mode = "host";
+ status = "okay";
+};
--
1.8.3.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
[PATCH v5 3/5] ARM: dts: AM4372: Add USB nodes
Add nodes for 2 instances each of
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for AM43xx.
Signed-off-by: George Cherian
Acked-by: Roger Quadros
---
arch/arm/boot/dts/am4372.dtsi | 94 +++
1 file changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a..cedb9d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -735,6 +735,100 @@
#size-cells = <1>;
status = "disabled";
};
+
+ am43xx_control_usb2phy1: control-phy@44e10620 {
+ compatible = "ti,control-phy-usb2-am437";
+ reg = <0x44e10620 0x4>;
+ reg-names = "power";
+ };
+
+ am43xx_control_usb2phy2: control-phy@0x44e10628 {
+ compatible = "ti,control-phy-usb2-am437";
+ reg = <0x44e10628 0x4>;
+ reg-names = "power";
+ };
+
+ ocp2scp0: ocp2scp@483a8000 {
+ compatible = "ti,omap-ocp2scp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "ocp2scp0";
+
+ usb2_phy1: phy@483a8000 {
+ compatible = "ti,am437x-usb2";
+ reg = <0x483a8000 0x8000>;
+ ctrl-module = <&am43xx_control_usb2phy1>;
+ clocks = <&usb_phy0_always_on_clk32k>,
+<&usb_otg_ss0_refclk960m>;
+ clock-names = "wkupclk", "refclk";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ ocp2scp1: ocp2scp@483e8000 {
+ compatible = "ti,omap-ocp2scp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "ocp2scp1";
+
+ usb2_phy2: phy@483e8000 {
+ compatible = "ti,am437x-usb2";
+ reg = <0x483e8000 0x8000>;
+ ctrl-module = <&am43xx_control_usb2phy2>;
+ clocks = <&usb_phy1_always_on_clk32k>,
+<&usb_otg_ss1_refclk960m>;
+ clock-names = "wkupclk", "refclk";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ dwc3_1: omap_dwc3@4838 {
+ compatible = "ti,am437x-dwc3";
+ ti,hwmods = "usb_otg_ss0";
+ reg = <0x4838 0x1>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <1>;
+ ranges;
+
+ usb1: usb@4839 {
+ compatible = "synopsys,dwc3";
+ reg = <0x4839 0x17000>;
+ interrupts = ;
+ phys = <&usb2_phy1>;
+ phy-names = "usb2-phy";
+ maximum-speed = "high-speed";
+ dr_mode = "otg";
+ status = "disabled";
+ };
+ };
+
+ dwc3_2: omap_dwc3@483c {
+ compatible = "ti,am437x-dwc3";
+ ti,hwmods = "usb_otg_ss1";
+ reg = <0x483c 0x1>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ utmi-mode = <1>;
+ ranges;
+
+ usb2: usb@483d {
+ compatible = "synopsys,dwc3";
+ reg = <0x483d 0x17000>;
+ interrupts = ;
+ phys = <&usb2_phy2>;
+ phy-names = "usb2-phy";
+ maximum-speed = "high-speed";
+ dr_mode = "otg";
+ status = "disabled";
+ };
+ };
};
};
--
1.8.3.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/2] add parallel NAND support for TI's new OMAPx and AMxx platforms
Hi Tony, >From: Gupta, Pekon >*changes v1 -> v2* > - AM335x (am335x-evm): > - DRA7xx (dra7-evm): resending > - AM43xx (am43X-epos-evm): fix MTD NAND.filesystem partition offset > I see following patches in your tree/branch "omap-for-v3.15/dt" But probably they were omitted in the pull request. Is there something, I need to do for these ? f68e355 2014-03-02 ARM: dts: am43xx: add support for parallel NAND flash c06c527 2014-03-02 ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt 91994fa 2014-03-02 ARM: dts: am335x-evm: NAND: update MTD partition table 0611c41 2014-03-02 ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms and ECC schemes Also, I had sent a [v2] for one of the patches, dropped by you. Please see if that can be picked [Patch v2 1/2] ARM: dts: dra7: add support for parallel NAND flash [Patch v2 1/2] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition with regards, pekon -- 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: rts-gpio DT binding
On 18/03/14 17:11, Felipe Balbi wrote: > On Tue, Mar 18, 2014 at 05:04:47PM +, Mark Jackson wrote: >> On 18/03/14 16:55, Felipe Balbi wrote: >>> Hi Mark, >>> >>> I'm looking at the omap-serial driver and saw that you added rts-gpio >>> binding in commit 4a0ac0f55b18dc297a87a85417fcf068658bf103 (OMAP: add >>> RS485 support) but, as it turns out, gpio0_13 and gpio2_15 are both >>> actual RTS signals. >>> >>> Instead of adding that extra GPIO handling, why didn't you just mux >>> those signals as RTS and enable auto-RTS/auto-CTS feature ? >>> >>> It looks to me like that's highly unnecessary binding. >> >> I agree !! >> >> I think it was to allow delays pre- and post- sending the comms data. >> >> Several RS485 drivers require a "warm up" time before they will >> transmit data correctly, and also need a "cool down" time to prevent >> clipping of the last few bits of data. >> >> IIRC the built-in RTS handling did not allow for this. > > you might be right here. I can't find anywhere to write rts delays. > Weird... digging TRM. > >> It also allows the RTS signal to be "inverted", again required for >> some RS485 driver chips. >> >> However, I'll dig into why I did this and report back. > > cool, thanks Okay ... it comes back to me now. When using RS485 drivers, we're not actually using RTS as a "Ready To Send", we're really using it as an "enable RS485 driver". I just used the "RTS" mnemonic as "we're now wanting to send some data so please now enable the RS485 driver", rather than the normal "I'm ready for your to send me some data". So it's the opposite function. Maybe it was a poor choice of abbreviation ? As I said before, RS485 drivers might have active or active low enables, so we might need to invert the "RTS" polarity. This is not handled by the hardware RTS signal. Is that a good enough explanation ? Mark J. -- 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
