RE: [PATCH] ARM: dts: omap2plus: remove interrupt-parent property
Hi Benoit,
Are there any review comments on this patch?
Could you please accept this patch if there are not any review comments?
Thanks
Manish Badarkhe
-Original Message-
From: Vishwanathrao Badarkhe, Manish
Sent: Monday, March 11, 2013 3:30 PM
To: devicetree-disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: t...@atomide.com; Cousson, Benoit; li...@arm.linux.org.uk; Vishwanathrao
Badarkhe, Manish
Subject: [PATCH] ARM: dts: omap2plus: remove interrupt-parent property
Removed interrupt-parent property from dts file as it is already
with root node in dtsi file.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
:100644 100644 f624dc8... 36e839a... M arch/arm/boot/dts/omap3-beagle.dts
:100644 100644 e8ba1c2... a5375fd... M arch/arm/boot/dts/omap3-evm.dts
:100644 100644 4122efe... 389c9c7... M arch/arm/boot/dts/omap4-panda.dts
:100644 100644 43e5258... cdf5dfd... M arch/arm/boot/dts/omap4-sdp.dts
:100644 100644 6601e6a... 1d4a9d4... M arch/arm/boot/dts/omap4-var-som.dts
arch/arm/boot/dts/omap3-beagle.dts |1 -
arch/arm/boot/dts/omap3-evm.dts |1 -
arch/arm/boot/dts/omap4-panda.dts |2 --
arch/arm/boot/dts/omap4-sdp.dts |2 --
arch/arm/boot/dts/omap4-var-som.dts |1 -
5 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..36e839a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -46,7 +46,6 @@
twl: twl@48 {
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
};
};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..a5375fd 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -34,7 +34,6 @@
twl: twl@48 {
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..389c9c7 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -119,7 +119,6 @@
reg = <0x48>;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-parent = <&gic>;
};
twl6040: twl@4b {
@@ -127,7 +126,6 @@
reg = <0x4b>;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
- interrupt-parent = <&gic>;
ti,audpwron-gpio = <&gpio4 31 0>; /* gpio line 127 */
vio-supply = <&v1v8>;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..cdf5dfd 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -221,7 +221,6 @@
reg = <0x48>;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-parent = <&gic>;
};
twl6040: twl@4b {
@@ -229,7 +228,6 @@
reg = <0x4b>;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
- interrupt-parent = <&gic>;
ti,audpwron-gpio = <&gpio4 31 0>; /* gpio line 127 */
vio-supply = <&v1v8>;
diff --git a/arch/arm/boot/dts/omap4-var-som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
index 6601e6a..1d4a9d4 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -35,7 +35,6 @@
reg = <0x48>;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-parent = <&gic>;
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call _init_mpu_rt_base if no sysc
> -Original Message-
> From: Hunter, Jon
> Sent: Thursday, April 11, 2013 7:17 AM
> To: Shilimkar, Santosh
> Cc: Cousson, Benoit; linux-omap@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; t...@atomide.com; Hiremath, Vaibhav
> Subject: Re: [PATCH v2 11/11] ARM: OMAP2+: omap_hwmod: Don't call
> _init_mpu_rt_base if no sysc
>
>
> On 03/19/2013 08:30 AM, Santosh Shilimkar wrote:
> > OMAP hwmod layer does the reset of the IPs in early code so that
> > we have SOC in sane state. To do the soft-reset, it needs to
> ioremap()
> > the ip address space to be able to write to sysconfig registers.
> >
> > But there are few hwmod which doesn't have sysconfig registers and
> hence
> > no need to ioremap() them in early init code.
> >
> > So this patch makes prevet calling the _init_mpu_rt_base()
> conditional
> > based on sysc availability.
> >
> > Cc: Benoit Cousson
> >
> > Signed-off-by: Santosh Shilimkar
> > ---
> > arch/arm/mach-omap2/omap_hwmod.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
> omap2/omap_hwmod.c
> > index 4501038..1a1f0a4 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -2449,7 +2449,8 @@ static int __init _init(struct omap_hwmod *oh,
> void *data)
> > if (oh->_state != _HWMOD_STATE_REGISTERED)
> > return 0;
> >
> > - _init_mpu_rt_base(oh, NULL);
> > + if (oh->class->sysc)
> > + _init_mpu_rt_base(oh, NULL);
> >
> > r = _init_clocks(oh, NULL);
> > if (IS_ERR_VALUE(r)) {
>
> I have not looked into why, but this commit is triggering the following
> panic on am335x-evm. I don't see this on the omap platforms only
> am335x.
>
> Adding Vaibhav ...
>
I think I have already fixed this, can you try applying below patches
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg87524.html
Thanks,
Vaibhav
Thanks,
Vaibhav
--
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] USB: ehci-omap: Select USB_PHY
Am 11.04.2013 20:29, schrieb Felipe Balbi: > and who said OMAP USB depends on CONFIG_USB_PHY ? Some platforms need to > control a PHY and some don't. I've read that so. > Go check out kernel 2.6.39 (maybe even 3.1 and 3.2) and you'll see that > we're much better off today where we can actually have multiple PHY > drivers and multiple UDC drivers enabled (either as modules or > built-in), but the fact is that changing all of this over takes time and > sometimes people make mistakes, but that's alright, since we have the > -rc series to catch those unwanted errors. I'll still have to stick to 3.2 because nothing afterwards boots from EHCI on my beagleboard. > > Without the help of the rest of the community, though, it'll just get > slower and slower. With the whole single zImage effort going on in the > ARM land, things have gotten much more critical WRT getting rid of > "selects" and turning legacy "drivers" into real drivers, not just a > bunch of exported functions which a single architecture uses. > > Add to that all the rework going on in the Gadget Framework, PHY layer > and EHCI drivers (which now has a core re-usable library thanks to Alan > Stern) and you have a lot of work to do. > > Next time you consider ranting about something, use that 'frustration' > and turn it into motivation to write patches, then we all win. Also I frequently tried and gave up. But thanks for the good suggestions. Regards, Alexander -- 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 3/5] gpio/omap: Add DT support to GPIO driver
On 04/11/2013 04:16 PM, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren
> wrote:
>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
>
>>> So the only reason I'm rambing on about this is that it breaks the
>>
>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>
>> If "it" is this patch, then should "breaks" be re-establishes?
>
> No I'm replying to Javier Martinez Canillas mail in this thread:
> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
> which is stating a question to grand, and contains the below
> hunk:
>
>> +static int gpio_irq_request(struct irq_data *d)
>> +{
>> + struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> + return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>> +}
>
> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
OK, right. sorry for being so confused/confusing.
Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
more like omap_gpio__irq_request() too, so the names don't look like
they'd clash with global functions. (__ added for clarity but probably
only one _ at a time)
--
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 3/5] gpio/omap: Add DT support to GPIO driver
On 04/11/2013 04:16 PM, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren
> wrote:
>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
>
>>> So the only reason I'm rambing on about this is that it breaks the
>>
>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>
>> If "it" is this patch, then should "breaks" be re-establishes?
>
> No I'm replying to Javier Martinez Canillas mail in this thread:
> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
> which is stating a question to grand, and contains the below
> hunk:
>
>> +static int gpio_irq_request(struct irq_data *d)
>> +{
>> + struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> + return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>> +}
>
> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
>
> It's the same thing you mention below:
>
>> If I recall the patch I'm replying to correctly, the idea was to add an
>> "IRQ request" operation that would (internally to the GPIO/IRQ driver
>> itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
>> exactly the situation you mention above.
OK, right. sorry for being so confused/confusing.
Yes, that code should certainly call e.g. omap_gpio__irq_to_gpio() not
irq_to_gpio(). Probably gpio_irq_request() wants renaming to something
more like omap_gpio__irq_request() too, so the names don't look like
they'd clash with global functions. (__ added for clarity but probably
only one _ at a time)
--
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 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, Apr 12, 2013 at 12:16 AM, Linus Walleij
wrote:
> On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren
> wrote:
>> On 04/10/2013 03:28 PM, Linus Walleij wrote:
>
>>> So the only reason I'm rambing on about this is that it breaks the
>>
>> I'm not sure I understand this paragraph; what is "it" in the line above.
>>
>> If "it" is this patch, then should "breaks" be re-establishes?
>
> No I'm replying to Javier Martinez Canillas mail in this thread:
> http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
> which is stating a question to grand, and contains the below
> hunk:
>
>> +static int gpio_irq_request(struct irq_data *d)
>> +{
>> + struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
>> +
>> + return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
>> +}
>
> irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
>
> It's the same thing you mention below:
>
>> If I recall the patch I'm replying to correctly, the idea was to add an
>> "IRQ request" operation that would (internally to the GPIO/IRQ driver
>> itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
>> exactly the situation you mention above.
>
> So the above does not look like it's internal to the driver does it?
>
> I think this is irq_to_gpio sneaking back in, and requiring that every
> driver of this sort follow the same design pattern. And then maybe
> you see my persistance ... are we talking about different things?
>
> So I'd be happy with something local to the driver, foo_irq_to_gpio()
> and that we also back out a bit and see what the subsystem can do
> to avoid this kind of code having to be duplicated everywhere, that's
> all.
>
Hi Linus,
Thanks a lot for your explanation. I didn't know that irq_to_gpio()
was being deprecated and we shouldn't use anymore. Now from this
thread discussion I understand the reasons for this decision.
I'll read the whole thread again and try to implement something that
is local to the gpio-omap driver instead using irq_to_gpio().
Besides using a controller specific mapping instead of irq_to_gpio(),
do you think that is a good idea to add a new "irq_request" function
pointer to struct irq_chip?
The idea is that GPIO controller drivers can call gpio_request() and
enabling the GPIO bank module before a call to request_irq() is made.
Or do you think that is better to implement the DT gpio hogs that you
were suggesting?
I really want to find a solution to this since currently we can't use
any device that uses an GPIO line as an IRQ on OMAP based boards.
> Yours,
> Linus Walleij
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thu, Apr 11, 2013 at 2:48 AM, Roger Quadros wrote: > On 04/10/2013 08:39 PM, Nishanth Menon wrote: >> On 13:55-20130410, Roger Quadros wrote: >>> On 04/10/2013 11:06 AM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-09 13:49:00) >> Folks, this does seem to be the best compromise we can achieve at this >> point in time. feedback on this approach is much appreciated - if folks >> are ok, I can post this as an formal patch series. > > This looks fine to me. Minor comments below. Thanks on the review. will fix in my next post 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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On Thu, Apr 11, 2013 at 1:46 PM, Mike Turquette wrote: > Quoting Nishanth Menon (2013-04-10 10:39:21) >> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c >> new file mode 100644 >> index 000..63a4cce >> --- /dev/null >> +++ b/drivers/clk/omap/clk.c >> @@ -0,0 +1,94 @@ >> +/* >> + * Texas Instruments OMAP Clock driver >> + * >> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ >> + * Nishanth Menon >> + * Tony Lindgren >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any >> + * kind, whether express or implied; without even the implied warranty >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include > > Please use clk-provider.h. Otherwise this looks like an OK transitional k. thanks for checking up on this. will update. > solution. Hopefully this will be replaced with a more legitimate clock > driver for 3.11. I hope so too. At least we should start debate with the direction we'd like to take and start migrating towards that purpose. 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 3/5] gpio/omap: Add DT support to GPIO driver
On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren wrote:
> On 04/10/2013 03:28 PM, Linus Walleij wrote:
>> So the only reason I'm rambing on about this is that it breaks the
>
> I'm not sure I understand this paragraph; what is "it" in the line above.
>
> If "it" is this patch, then should "breaks" be re-establishes?
No I'm replying to Javier Martinez Canillas mail in this thread:
http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2
which is stating a question to grand, and contains the below
hunk:
> +static int gpio_irq_request(struct irq_data *d)
> +{
> + struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
> +
> + return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq");
> +}
irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio().
It's the same thing you mention below:
> If I recall the patch I'm replying to correctly, the idea was to add an
> "IRQ request" operation that would (internally to the GPIO/IRQ driver
> itself) map IRQ->GPIO, and call gpio_request(). That would then prevent
> exactly the situation you mention above.
So the above does not look like it's internal to the driver does it?
I think this is irq_to_gpio sneaking back in, and requiring that every
driver of this sort follow the same design pattern. And then maybe
you see my persistance ... are we talking about different things?
So I'd be happy with something local to the driver, foo_irq_to_gpio()
and that we also back out a bit and see what the subsystem can do
to avoid this kind of code having to be duplicated everywhere, that's
all.
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 3/5] gpio/omap: Add DT support to GPIO driver
On 04/10/2013 03:28 PM, Linus Walleij wrote: > On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren > wrote: >> On 04/10/2013 12:12 PM, Linus Walleij wrote: > >>> If the information is there, whether to convert from IRQ to GPIO >>> or from GPIO to IRQ is a technicality and any order should be >>> feasible in some way? >> >> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put >> another way, a single GPIO would likely only ever trigger a single IRQ, >> but a single IRQ might easily be triggered by any number of GPIOs. This >> is exactly why the function irq_to_gpio() isn't something one should use >> any more. I think there was an effort to outright remove the API, >> although it doesn't look like that's entirely complete yet. I guess you >> know this given your mentions of problem with gpio_to_irq() later on, so >> I'm not quite sure what your paragraph above was supposed to mean. > > So the only reason I'm rambing on about this is that it breaks the I'm not sure I understand this paragraph; what is "it" in the line above. If "it" is this patch, then should "breaks" be re-establishes? > connection between GPIOs and their IRQs and at one point > I percieved it as there was going to be some IRQ -> GPIO lookup, > and it would sneak back in. But now I realize that may have been > supposed to be something local to the driver, in it's irqchip portions > and then it's actually no problem for the kernel at large. Yes, I believe the intention was for their to be a correlation between GPIOs and IRQs only with the individual gpio_chip/irq_chip drivers for those GPIOs/IRQs, and not exposed anywhere outside it. > Let's restate: I'm also after something fragile here. I assume you mean the opposite of that? > IIUC, it will be possible for a GPIO to be set up as input and used > as an IRQ without the GPIO subsystem knowing it. And it will be > possible for the GPIO subsystem to go in and request the same pin > and set it as output and e.g. bit-bang it. I wonder what happens then. Yes, I think that's possible now. If I recall the patch I'm replying to correctly, the idea was to add an "IRQ request" operation that would (internally to the GPIO/IRQ driver itself) map IRQ->GPIO, and call gpio_request(). That would then prevent exactly the situation you mention above. -- 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: How do you configure AM335x dts for dual ethernet ?
On 11/04/13 17:14, Mark Jackson wrote: I'm trying to work out how to setup my custom dts file to support dual ethernet. This is on a custom board based on the BeagleBone, but with both ethernet ports connected in MII mode. I know this should work (since the svm has dual ethernet), so can anyone give me some pointers ? That should read "since the *starter kit* has dual ethernet". 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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Quoting Nishanth Menon (2013-04-10 10:39:21) > diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c > new file mode 100644 > index 000..63a4cce > --- /dev/null > +++ b/drivers/clk/omap/clk.c > @@ -0,0 +1,94 @@ > +/* > + * Texas Instruments OMAP Clock driver > + * > + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ > + * Nishanth Menon > + * Tony Lindgren > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include Please use clk-provider.h. Otherwise this looks like an OK transitional solution. Hopefully this will be replaced with a more legitimate clock driver for 3.11. Regards, Mike -- 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
Section mismatch warning with linux next in usbhs_init_phys()
Hi Roger, Looks like there's a section mismatch issue in linux next: WARNING: vmlinux.o(.text+0x2a7b4): Section mismatch in reference from the function usbhs_init_phys() to the function .init.text:usb_bind_phy() The function usbhs_init_phys() references the function __init usb_bind_phy(). This is often because usbhs_init_phys lacks a __init annotation or the annotation of usb_bind_phy is wrong. Can you please take a look? Also, is the auxclk related patch the only patch missing for USB to work on panda with DT in linux next? Or are some .dts or .config updates needed also? So far no luck here. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Hi, On Thu, Apr 11, 2013 at 07:33:32PM +0200, Alexander Holler wrote: > >>Sorry, but this just will end up with many users having broken configs > >>because of disabled stuff they don't know why they have to enable them. > >>And thus with a never ending stream of questions and thus with a needed > >>FAQ entry. > >> > > > >Alexander, > > > >I agree with you that it can get difficult with users. But it is best for > >users do not disable anything they are not familiar with. > > > >As the USB_PHY option doesn't depend on anything, it is safe to select it > >from USB_EHCI_HCD_OMAP. > > > >However, the PHY drivers themselves must be selected from the board configs. > > Maybe I understood something wrong, but if the OMAP USB driver > requires CONFIG_USB_PHY (or similiar), it should be selected > automatically and not just enabled in the board config. and who said OMAP USB depends on CONFIG_USB_PHY ? Some platforms need to control a PHY and some don't. > I just had it to often, that I needed to search around why a driver > doesn't work (or even compiles), just to find out that I need to > enable some strange config option which wasn't selected > automatically. Especially with OMAPs. ;) so ? Send a patch fixing it, those are really welcome. You see, it's very difficult to get all of this perfectly right and if people continue to rant rather than fix, we will get nowhere. > And this not only occured when disabling options, it often occured by > just updating the kernel. Suddenly some obscur option was needed too, > it wasn't selected automatically by make oldconfig, bang. So the > argument to not remove anything from a board config doesn't help > much. blablabla, Kconfig changes are *always* necessary. Specially when we need to re-design an entire API because the previous one was just a *SINGLE* global pointer. Go check out kernel 2.6.39 (maybe even 3.1 and 3.2) and you'll see that we're much better off today where we can actually have multiple PHY drivers and multiple UDC drivers enabled (either as modules or built-in), but the fact is that changing all of this over takes time and sometimes people make mistakes, but that's alright, since we have the -rc series to catch those unwanted errors. Without the help of the rest of the community, though, it'll just get slower and slower. With the whole single zImage effort going on in the ARM land, things have gotten much more critical WRT getting rid of "selects" and turning legacy "drivers" into real drivers, not just a bunch of exported functions which a single architecture uses. Add to that all the rework going on in the Gadget Framework, PHY layer and EHCI drivers (which now has a core re-usable library thanks to Alan Stern) and you have a lot of work to do. Next time you consider ranting about something, use that 'frustration' and turn it into motivation to write patches, then we all win. Also consider that under drivers/usb/ alone we have 270K LOCs, and that's quite a lot of code to handle with only a few of us (Greg, Sarah, Alan, Alex and myself) being the gateway towards mainline. With all that comes the responsibility of revieweing drivers for architectures we, most of the times, don't have access to with drivers that only compile in some ceratin ways. Cleaning all of that takes time. Look at all the effort it's taking the Chipidea folks just to get rid of a couple copies of the chipidea driver. It takes time, it takes sweat and we can all use some help rather than some random rant. -- balbi signature.asc Description: Digital signature
Re: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
* Tony Lindgren [130411 10:01]:
> * David Howells [130411 09:50]:
> > Tony Lindgren wrote:
> >
> > > Looks like the mach-omap1/pm.c part we can make into
> > > a debugfs entry as it only contains PM debug data. But
> > > that we can do after this patch.
> >
> > If you have a patch to do that, I can substitute it for this one.
>
> Sure will do.
Here's the updated patch to do it against current linux next.
Tested on osk5912. It should not conflict with anything else
currently queued, so please feel free to merge it along with
your other patches.
Note that the patch below does not contain the swp_emulate.c
changes.
Regards,
Tony
From: Tony Lindgren
Date: Thu, 11 Apr 2013 10:02:38 -0700
Subject: [PATCH] ARM: OMAP1: Replace PM debug create_proc_read_entry() with
debugfs
There's no need to keep this entry in proc, it is PM
related debug only entry. Let's move it into debugfs.
Based on an earlier patch David Howells
to use seq_printf and to update to use create_proc_read_entry().
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index db37f49..dd712f1 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -37,7 +37,8 @@
#include
#include
-#include
+#include
+#include
#include
#include
#include
@@ -423,23 +424,12 @@ void omap1_pm_suspend(void)
omap_rev());
}
-#if defined(DEBUG) && defined(CONFIG_PROC_FS)
-static int g_read_completed;
-
+#ifdef CONFIG_DEBUG_FS
/*
* Read system PM registers for debugging
*/
-static int omap_pm_read_proc(
- char *page_buffer,
- char **my_first_byte,
- off_t virtual_start,
- int length,
- int *eof,
- void *data)
+static int omap_pm_debug_show(struct seq_file *m, void *v)
{
- int my_buffer_offset = 0;
- char * const my_base = page_buffer;
-
ARM_SAVE(ARM_CKCTL);
ARM_SAVE(ARM_IDLECT1);
ARM_SAVE(ARM_IDLECT2);
@@ -480,10 +470,7 @@ static int omap_pm_read_proc(
MPUI1610_SAVE(EMIFS_CONFIG);
}
- if (virtual_start == 0) {
- g_read_completed = 0;
-
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ seq_printf(m,
"ARM_CKCTL_REG:0x%-8x \n"
"ARM_IDLECT1_REG: 0x%-8x \n"
"ARM_IDLECT2_REG: 0x%-8x \n"
@@ -513,8 +500,8 @@ static int omap_pm_read_proc(
ULPD_SHOW(ULPD_STATUS_REQ),
ULPD_SHOW(ULPD_POWER_CTRL));
- if (cpu_is_omap7xx()) {
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ if (cpu_is_omap7xx()) {
+ seq_printf(m,
"MPUI7XX_CTRL_REG 0x%-8x \n"
"MPUI7XX_DSP_STATUS_REG: 0x%-8x \n"
"MPUI7XX_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -527,8 +514,8 @@ static int omap_pm_read_proc(
MPUI7XX_SHOW(MPUI_DSP_API_CONFIG),
MPUI7XX_SHOW(EMIFF_SDRAM_CONFIG),
MPUI7XX_SHOW(EMIFS_CONFIG));
- } else if (cpu_is_omap15xx()) {
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ } else if (cpu_is_omap15xx()) {
+ seq_printf(m,
"MPUI1510_CTRL_REG 0x%-8x \n"
"MPUI1510_DSP_STATUS_REG: 0x%-8x \n"
"MPUI1510_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -541,8 +528,8 @@ static int omap_pm_read_proc(
MPUI1510_SHOW(MPUI_DSP_API_CONFIG),
MPUI1510_SHOW(EMIFF_SDRAM_CONFIG),
MPUI1510_SHOW(EMIFS_CONFIG));
- } else if (cpu_is_omap16xx()) {
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ } else if (cpu_is_omap16xx()) {
+ seq_printf(m,
"MPUI1610_CTRL_REG 0x%-8x \n"
"MPUI1610_DSP_STATUS_REG: 0x%-8x \n"
"MPUI1610_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -555,28 +542,37 @@ static int omap_pm_read_proc(
MPUI1610_SHOW(MPUI_DSP_API_CONFIG),
MPUI1610_SHOW(EMIFF_SDRAM_CONFIG),
MPUI1610_SHOW(EMIFS_CONFIG));
- }
-
- g_read_completed++;
- } else if (g_read_completed >= 1) {
-*eof = 1;
-return 0;
}
- g_read_completed++;
- *my_first_byte = page_buffer;
- return my_buffer_offset;
+ return 0;
+}
+
+static int omap_pm_debug_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, omap_pm_debug_show,
+ &inode->i_private);
}
-static void omap_pm_init_proc(void)
+static const struct file_operations omap_pm_d
Re: gpio/omap v2: map irq_enable/disable to mask/unmask.
On 04/11/2013 10:54 AM, Santosh Shilimkar wrote: > On Thursday 11 April 2013 06:48 PM, Andreas Fenkart wrote: >> Hi Santosh, >> >> I submitted the following patch a while back. >> https://patchwork.kernel.org/patch/1886421/ >> >> As already said, the patch is straight forward, but without it, >> we probably will not see decent SDIO performance on am335x chips. >> >> [why it is needed] >> > Why part is clear for me. > >> There are still open questions to gpio patch itself, see here >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg87217.html >> >> So could we pls reopen that thread? It might be on the other side >> of your mailbox >> > Your idea is reasonable and probably patch make lot of sense for > edge triggered interrupt. > > Can you please repost the patch with the more comprehensive change-log > as discussed in the thread. Originally, I had a question on enable/disable versus mask/unmask, but looking at the way we have implemented mask/unmask for omap, I don't think that my question is really applicable. Yes so please re-post. Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Am 11.04.2013 16:44, schrieb Roger Quadros: Sorry, but this just will end up with many users having broken configs because of disabled stuff they don't know why they have to enable them. And thus with a never ending stream of questions and thus with a needed FAQ entry. Alexander, I agree with you that it can get difficult with users. But it is best for users do not disable anything they are not familiar with. As the USB_PHY option doesn't depend on anything, it is safe to select it from USB_EHCI_HCD_OMAP. However, the PHY drivers themselves must be selected from the board configs. Maybe I understood something wrong, but if the OMAP USB driver requires CONFIG_USB_PHY (or similiar), it should be selected automatically and not just enabled in the board config. I just had it to often, that I needed to search around why a driver doesn't work (or even compiles), just to find out that I need to enable some strange config option which wasn't selected automatically. Especially with OMAPs. ;) And this not only occured when disabling options, it often occured by just updating the kernel. Suddenly some obscur option was needed too, it wasn't selected automatically by make oldconfig, bang. So the argument to not remove anything from a board config doesn't help much. Sorry for the rant. ;) Regards, Alexander -- 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 25/26] arm: Don't use create_proc_read_entry() [RFC]
* David Howells [130411 09:50]: > Tony Lindgren wrote: > > > Looks like the mach-omap1/pm.c part we can make into > > a debugfs entry as it only contains PM debug data. But > > that we can do after this patch. > > If you have a patch to do that, I can substitute it for this one. Sure will do. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
Tony Lindgren wrote: > Looks like the mach-omap1/pm.c part we can make into > a debugfs entry as it only contains PM debug data. But > that we can do after this patch. If you have a patch to do that, I can substitute it for this one. David -- 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: [GIT PULL 5/5] omap dt changes for v3.10 merge window
* Olof Johansson [130411 04:11]: > Hi, > > On Mon, Apr 08, 2013 at 09:51:03PM -0700, Tony Lindgren wrote: > > The following changes since commit 5852264f9d6139751796853fdfca9d5230cbfb97: > > > > Merge tag 'omap-devel-b-for-3.10' of > > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into > > for_3.10/dts_merged (2013-04-09 00:11:05 +0200) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > > tags/omap-for-v3.10/dt-signed-v2 > > > > for you to fetch changes up to 161e89a689bb88004b757986eefda2402448eef7: > > > > ARM/dts: OMAP3: fix pinctrl-single configuration (2013-04-08 17:00:22 > > -0700) > > > > > > Device tree updates for omaps via Benoit Cousson . > > > > Note that the branch has dependencies to two other branches: > > > > - omap-devel-b-for-3.10 from Paul to get the AM33xx missing > > hwmod and thus avoid a regression with Santosh's hwmod > > cleanup including in this DT series [1]. It avoids breaking > > bisect if this series is merged before Paul's fixes. > > Looks like this was part of omap/fixes-non-critical, the branch name from Paul > just didn't percolate up. At least the topmost SHA from that merge in your > history seems to be part of said branch. :) > > > > - omap-for-v3.10/usb branch to avoid nasty merge conflict in > > omap3.dtsi and omap4.dtsi due to the DTS patches contained > > in the USB branch because of a screw up by the unnamed person > > typing this signed tag based on Benoit's comments. > > > Ok, it looks like this one was merged in next/drivers as omap/usb. > > > So based on the above, I've merged in omap/fixes-non-critical and omap/usb as > a base, and merged this on top. All of this has gone into next/dt2. OK 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
Re: Kexec couldn't reboot capture kernel on pandaboard ES with OMAP4460
On 04/10/2013 10:46 PM, Li Haifeng wrote: > 2013/4/10 Stephen Warren : >> On 04/10/2013 03:35 AM, Li Haifeng wrote: >>> Hi, everyone. >>> >>> Recently, I try to run kdump on pandaboard ES with omap4460. After >>> load capture kernel by "kexec -l" and execute "kexec -e", the serial >>> port output "Starting new kernel" and "Bye", then the system hangs up. >>> >>> I have tried the upstream Linux Kernel v3.4 and v3.8. All are with this >>> issue. >> >> This is a shot in the dark. I assume you have SMP enabled. Can you use >> hotplug to remove all CPUs other than CPU0, so that the kexec happens on >> the boot CPU? That is certainly necessary for kexec to work correctly on >> Tegra. > > Thanks for your attention. > > I do disable SMP feature. And the .config file for v3.8 could be found here: > http://pastehtml.com/view/cylyrfejt.txt ... > The output: > [ 57.373687] Starting new kernel > [ 57.377044] Bye! > > Then system hangs. Oh well, you've exhausted my knowledge I'm afraid! I can only suggesting trying to enable earlyprintk and/or uncompressor debug in the kernel you're kexec'ing and see if that yields any clue. Either that, or JTAG! -- 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
How do you configure AM335x dts for dual ethernet ?
I'm trying to work out how to setup my custom dts file to support dual ethernet.
This is on a custom board based on the BeagleBone, but with both ethernet ports
connected in MII mode.
So far I have just copied the layout of am335x-evm.dts, but that only gives me
eth0:-
[1.418487] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.424952] davinci_mdio 4a101000.mdio: detected phy mask fffc
[1.434455] libphy: 4a101000.mdio: probed
[1.438790] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
driver SMSC LAN8710/LAN8720
[1.448486] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01,
driver SMSC LAN8710/LAN8720
[1.458585] Random MACID = 82:72:bb:49:3f:49
[1.466964] rtc-ds1307 0-0068: setting system clock to 2013-04-11 16:15:37
UTC (1365696937)
[1.478107] net eth0: initializing cpsw version 1.12 (0)
[1.486109] net eth0: phy found : id is : 0x7c0f1
[1.491696] net eth0: phy found : id is : 0x7c0f1
I added:-
mac: ethernet@4a10 {
dual_emac = <1>;
};
... which gives me eth0 and eth1, but kills my nfs root:-
[1.444534] libphy: 4a101000.mdio: probed
[1.448842] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
driver SMSC LAN8710/LAN8720
[1.458422] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01,
driver SMSC LAN8710/LAN8720
[1.468439] Random MACID = 1e:5b:03:c9:a4:f7
[1.475683] cpsw: Random MACID = 66:56:fa:5e:9f:19
[1.484027] rtc-ds1307 0-0068: setting system clock to 2013-04-11 16:50:32
UTC (1365699032)
[1.494911] net eth0: initializing cpsw version 1.12 (0)
[1.503727] net eth0: phy found : id is : 0x7c0f1
[4.579126] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[4.608561] IP-Config: Guessing netmask 255.0.0.0
[4.613910] IP-Config: Complete:
[4.617307] device=eth0, hwaddr=1e:5b:03:c9:a4:f7, ipaddr=10.0.101.111,
mask=255.0.0.0, gw=10.0.0.100
[4.627473] host=10.0.101.111, domain=, nis-domain=(none)
[4.633613] bootserver=255.255.255.255, rootserver=10.0.0.100, rootpath=
[4.665520] VFS: Mounted root (nfs filesystem) on device 0:12.
[4.673877] devtmpfs: mounted
[4.677461] Freeing init memory: 196K
Starting logging: OK
Initializing random number generator... done.
Starting network...
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
[5.449203] net eth1: initializing cpsw version 1.12 (0)
[5.456180] net eth1: phy found : id is : 0x7c0f1
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Starting dropbear sshd: OK
Welcome to Buildroot
nanobone login: root
Password:
# ps
[ 27.729217] nfs: server 10.0.0.100 not responding, still trying
I know this should work (since the svm has dual ethernet), so can anyone give
me some pointers ?
Cheers
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: gpio/omap v2: map irq_enable/disable to mask/unmask.
On Thursday 11 April 2013 06:48 PM, Andreas Fenkart wrote: > Hi Santosh, > > I submitted the following patch a while back. > https://patchwork.kernel.org/patch/1886421/ > > As already said, the patch is straight forward, but without it, > we probably will not see decent SDIO performance on am335x chips. > > [why it is needed] > Why part is clear for me. > There are still open questions to gpio patch itself, see here > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg87217.html > > So could we pls reopen that thread? It might be on the other side > of your mailbox > Your idea is reasonable and probably patch make lot of sense for edge triggered interrupt. Can you please repost the patch with the more comprehensive change-log as discussed in the thread. Regards, Santosh -- 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 25/26] arm: Don't use create_proc_read_entry() [RFC]
* David Howells [130411 06:35]:
> Don't use create_proc_read_entry() as that is deprecated, but rather use
> proc_create_data() and seq_file instead.
>
> Signed-off-by: David Howells
> cc: Russell King
> cc: Kevin Hilman
Looks like the mach-omap1/pm.c part we can make into
a debugfs entry as it only contains PM debug data. But
that we can do after this patch.
Acked-by: Tony Lindgren
> cc: linux-arm-ker...@lists.infradead.org
> cc: linux-omap@vger.kernel.org
> ---
>
> arch/arm/kernel/swp_emulate.c | 42 +-
> arch/arm/mach-omap1/pm.c | 58
> +
> 2 files changed, 43 insertions(+), 57 deletions(-)
>
> diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
> index 0bba47a..087fc32 100644
> --- a/arch/arm/kernel/swp_emulate.c
> +++ b/arch/arm/kernel/swp_emulate.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -79,27 +80,27 @@ static unsigned long abtcounter;
> static pid_t previous_pid;
>
> #ifdef CONFIG_PROC_FS
> -static int proc_read_status(char *page, char **start, off_t off, int count,
> - int *eof, void *data)
> +static int proc_status_show(struct seq_file *m, void *v)
> {
> - char *p = page;
> - int len;
> -
> - p += sprintf(p, "Emulated SWP:\t\t%lu\n", swpcounter);
> - p += sprintf(p, "Emulated SWPB:\t\t%lu\n", swpbcounter);
> - p += sprintf(p, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
> + seq_printf(m, "Emulated SWP:\t\t%lu\n", swpcounter);
> + seq_printf(m, "Emulated SWPB:\t\t%lu\n", swpbcounter);
> + seq_printf(m, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
> if (previous_pid != 0)
> - p += sprintf(p, "Last process:\t\t%d\n", previous_pid);
> -
> - len = (p - page) - off;
> - if (len < 0)
> - len = 0;
> -
> - *eof = (len <= count) ? 1 : 0;
> - *start = page + off;
> + seq_printf(m, "Last process:\t\t%d\n", previous_pid);
> + return 0;
> +}
>
> - return len;
> +static int proc_status_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, proc_status_show, PDE_DATA(inode));
> }
> +
> +static const struct file_operations proc_status_fops = {
> + .open = proc_status_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release= seq_release,
> +};
> #endif
>
> /*
> @@ -266,12 +267,7 @@ static struct undef_hook swp_hook = {
> static int __init swp_emulation_init(void)
> {
> #ifdef CONFIG_PROC_FS
> - struct proc_dir_entry *res;
> -
> - res = create_proc_read_entry("cpu/swp_emulation", S_IRUGO, NULL,
> - proc_read_status, NULL);
> -
> - if (!res)
> + if (!proc_create("cpu/swp_emulation", S_IRUGO, NULL, &proc_status_fops))
> return -ENOMEM;
> #endif /* CONFIG_PROC_FS */
>
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 7a7690a..2645e37 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -38,6 +38,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -423,22 +424,11 @@ void omap1_pm_suspend(void)
> }
>
> #if defined(DEBUG) && defined(CONFIG_PROC_FS)
> -static int g_read_completed;
> -
> /*
> * Read system PM registers for debugging
> */
> -static int omap_pm_read_proc(
> - char *page_buffer,
> - char **my_first_byte,
> - off_t virtual_start,
> - int length,
> - int *eof,
> - void *data)
> +static int omap_pm_proc_show(struct seq_file *m, void *v)
> {
> - int my_buffer_offset = 0;
> - char * const my_base = page_buffer;
> -
> ARM_SAVE(ARM_CKCTL);
> ARM_SAVE(ARM_IDLECT1);
> ARM_SAVE(ARM_IDLECT2);
> @@ -479,10 +469,7 @@ static int omap_pm_read_proc(
> MPUI1610_SAVE(EMIFS_CONFIG);
> }
>
> - if (virtual_start == 0) {
> - g_read_completed = 0;
> -
> - my_buffer_offset += sprintf(my_base + my_buffer_offset,
> + seq_printf(m,
> "ARM_CKCTL_REG:0x%-8x \n"
> "ARM_IDLECT1_REG: 0x%-8x \n"
> "ARM_IDLECT2_REG: 0x%-8x \n"
> @@ -512,8 +499,8 @@ static int omap_pm_read_proc(
> ULPD_SHOW(ULPD_STATUS_REQ),
> ULPD_SHOW(ULPD_POWER_CTRL));
>
> - if (cpu_is_omap7xx()) {
> - my_buffer_offset += sprintf(my_base + my_buffer_offset,
> + if (cpu_is_omap7xx()) {
> + seq_printf(m,
> "MPUI7XX_CTRL_REG 0x%-8x \n"
> "MPUI7XX_DSP_STATUS_REG: 0x%-8x \n"
> "MPUI7XX_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
> @@ -526,8 +513,8 @@ static int omap_pm_read_proc(
> MPUI7XX_SHOW(MPUI_DSP_API_CONFIG),
>
Re: gpio/omap v2: map irq_enable/disable to mask/unmask.
Hi, * Andreas Fenkart [130411 06:23]: > Hi Santosh, > > I submitted the following patch a while back. > https://patchwork.kernel.org/patch/1886421/ > > As already said, the patch is straight forward, but without it, > we probably will not see decent SDIO performance on am335x chips. I suggest you repost, patches can easily get forgotten unuless you follow-up getting them merged. > [why it is needed] > > The omap_hsmmc module is suspended whenever it is idle, its > functional clock being turned off. In this mode it is not able to > forwared IRQs to the system. For that to happen, it needs to tell > the PRCM to restore it's fclk. > >-- > | PRCM | >-- > | ^ >fclk | | swakeup > v | > --- -- > <-- IRQ -- | hsmmc | <-- CIRQ -- | card | > --- -- > > This is done through the swakeup line, which can be configured to > trigger for various events, among others; CIRQ. The problem is > that on the AM335x family the swakeup line is missing, it has not > been routed from the module to the PRCM. > > [solution] > the simplest solution was to keep the fclk enabled all the > time. But that was not accepted, instead this was suggested > > > > The alternative was to configure dat1 line as a GPIO, while > > > waiting for an IRQ. Then configuring it back as dat1 to serve > > > the SDIO card after it signalled an IRQ. Or when the host > > > wants to start a transfer. > > > > The way to implement this is set named states in the .dts file > > for the pins using pinctrl-single.c, then have the MMC driver > > request states "default" "active" and "idle" during the probe, > > then toggle between active and idle during the runtime. > > Surprisingly the induced overhead is quite small, the performance > is similar to keeping the fclk enabled at all times. See here > for full thread: > http://www.spinics.net/lists/linux-omap/msg83363.html > https://patchwork.kernel.org/patch/1901471/ ... or just the patch That's nice, AFAIK this is the only way to do it for some omaps. > There are still open questions to gpio patch itself, see here > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg87217.html > > So could we pls reopen that thread? It might be on the other side > of your mailbox The SDIO related patch can already get merged while the GPIO patch is being discussed I hope? If so, you should fix #if 0 part I commented on and repost with the ack from Grant. And update it against the current linux next so people can apply it for testing. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Hi, On Thu, Apr 11, 2013 at 05:53:10PM +0300, Roger Quadros wrote: > >>> From: Roger Quadros > >>> Date: Thu, 11 Apr 2013 12:08:19 +0300 > >>> Subject: [PATCH] USB: ehci-omap: Select USB_PHY > >>> > >>> As we need NOP_USB_XCEIV which depends on USB_PHY > >>> we need to select USB_PHY as well. > >>> > >>> Gets rid of the below warnings when USB_EHCI_HCD_OMAP > >>> is enabled. > >>> > >>> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet > >>> direct dependencies (USB_SUPPORT && USB_PHY) > >>> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet > >>> direct dependencies (USB_SUPPORT && USB_PHY) > >>> > >>> Signed-off-by: Roger Quadros > >> > >> Ideally, however, we wouldn't select any PHY in particular as different > >> boards might need a different PHY driver, even on OMAP ;-) > >> > > Right, but we need to select USB_PHY here as the driver uses > > the USB_PHY APIs. > > > > The NOP_USB_XCEIV selection could be done by the board config. > > I would avoid 'select' completely and just update omap2plus_defconfig > adding those two as modules. > > >>> > >>> OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". > >>> > >> > >> One more issue to clarify. > >> > >> if USB_PHY is not enabled, then all phy_get() API's should return NULL and > >> not > >> -ENXIO as it does now. > > > > ENXIO means "No such device or address", looks alright to me ;-) > > > >> This way the drivers need not treat it as an error and all PHY ops can > >> be NOPs. > > > > drivers will already be using if (IS_ERR()) construction, returning > > -ENXIO when the API is disabled gives them an oportunity to *not* > > request probe deferral since the API isn't enabled anyway. > > on second thoughts I agree with you. So the general understanding is > that USB_PHY users without USB_PHY enabled is an error case. > > This means we need to allow controller drivers to select USB_PHY > and minimize this possibility. perhaps but OTOH careless select will also cause lots of problems. distro-like kernels will just put all those as modules and product-like kernels will only enable exactly what they need, so it makes no difference if we select or not. Except that select will enable that PHY even in e.g. beaglebone derivative which is, for now, using the same DTS file. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Hi, On Thu, Apr 11, 2013 at 05:44:00PM +0300, Roger Quadros wrote: > Felipe, > > On 04/11/2013 04:02 PM, Alexander Holler wrote: > > Am 11.04.2013 14:42, schrieb Roger Quadros: > >> On 04/11/2013 01:55 PM, Felipe Balbi wrote: > > > >>> I would avoid 'select' completely and just update omap2plus_defconfig > >>> adding those two as modules. > > Setting USB_PHY as a module gives rise to these problems > > arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': > /work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to > `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': > /work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference > to `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': > /work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined > reference to `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': > /work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined > reference to `usb_bind_phy' > arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': > /work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to > `usb_bind_phy' > > So USB_PHY shouldn't be tristate IMO or at least the platform registration > stuff > as the usb_bind_phy() part is used by platform code. alright, let's send a patch to fix the check in the header. We should be using IS_ENABLED() anyway. -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: ehci-omap: Select USB_PHY
On 04/11/2013 05:34 PM, Felipe Balbi wrote: > Hi, > > On Thu, Apr 11, 2013 at 04:18:33PM +0300, Roger Quadros wrote: >> On 04/11/2013 03:42 PM, Roger Quadros wrote: >>> On 04/11/2013 01:55 PM, Felipe Balbi wrote: Hi, On Thu, Apr 11, 2013 at 01:51:16PM +0300, Roger Quadros wrote: > On 04/11/2013 01:04 PM, Felipe Balbi wrote: >> Hi, >> >> On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: >>> Hi Greg, >>> >>> The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP >>> is enabled. >>> >>> Patch is based on your usb-next branch and is needed for 3.10. >>> >>> From: Roger Quadros >>> Date: Thu, 11 Apr 2013 12:08:19 +0300 >>> Subject: [PATCH] USB: ehci-omap: Select USB_PHY >>> >>> As we need NOP_USB_XCEIV which depends on USB_PHY >>> we need to select USB_PHY as well. >>> >>> Gets rid of the below warnings when USB_EHCI_HCD_OMAP >>> is enabled. >>> >>> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet >>> direct dependencies (USB_SUPPORT && USB_PHY) >>> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet >>> direct dependencies (USB_SUPPORT && USB_PHY) >>> >>> Signed-off-by: Roger Quadros >> >> Ideally, however, we wouldn't select any PHY in particular as different >> boards might need a different PHY driver, even on OMAP ;-) >> > Right, but we need to select USB_PHY here as the driver uses > the USB_PHY APIs. > > The NOP_USB_XCEIV selection could be done by the board config. I would avoid 'select' completely and just update omap2plus_defconfig adding those two as modules. >>> >>> OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". >>> >> >> One more issue to clarify. >> >> if USB_PHY is not enabled, then all phy_get() API's should return NULL and >> not >> -ENXIO as it does now. > > ENXIO means "No such device or address", looks alright to me ;-) > >> This way the drivers need not treat it as an error and all PHY ops can >> be NOPs. > > drivers will already be using if (IS_ERR()) construction, returning > -ENXIO when the API is disabled gives them an oportunity to *not* > request probe deferral since the API isn't enabled anyway. on second thoughts I agree with you. So the general understanding is that USB_PHY users without USB_PHY enabled is an error case. This means we need to allow controller drivers to select USB_PHY and minimize this possibility. > >> This will make it behave like other frameworks. e.g. clk. > > if we return NULL we will need IS_ERR_OR_NULL() which will cause > problems with people who aren't careful enough. > OK. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Felipe, On 04/11/2013 04:02 PM, Alexander Holler wrote: > Am 11.04.2013 14:42, schrieb Roger Quadros: >> On 04/11/2013 01:55 PM, Felipe Balbi wrote: > >>> I would avoid 'select' completely and just update omap2plus_defconfig >>> adding those two as modules. Setting USB_PHY as a module gives rise to these problems arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys': /work/linux-2.6/arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init': /work/linux-2.6/arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init': /work/linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `devkit8000_init': /work/linux-2.6/arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy' arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init': /work/linux-2.6/arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy' So USB_PHY shouldn't be tristate IMO or at least the platform registration stuff as the usb_bind_phy() part is used by platform code. >>> >> >> OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". > > Sorry, but this just will end up with many users having broken configs > because of disabled stuff they don't know why they have to enable them. > And thus with a never ending stream of questions and thus with a needed > FAQ entry. > Alexander, I agree with you that it can get difficult with users. But it is best for users do not disable anything they are not familiar with. As the USB_PHY option doesn't depend on anything, it is safe to select it from USB_EHCI_HCD_OMAP. However, the PHY drivers themselves must be selected from the board configs. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Hi, On Thu, Apr 11, 2013 at 04:18:33PM +0300, Roger Quadros wrote: > On 04/11/2013 03:42 PM, Roger Quadros wrote: > > On 04/11/2013 01:55 PM, Felipe Balbi wrote: > >> Hi, > >> > >> On Thu, Apr 11, 2013 at 01:51:16PM +0300, Roger Quadros wrote: > >>> On 04/11/2013 01:04 PM, Felipe Balbi wrote: > Hi, > > On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: > > Hi Greg, > > > > The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP > > is enabled. > > > > Patch is based on your usb-next branch and is needed for 3.10. > > > > From: Roger Quadros > > Date: Thu, 11 Apr 2013 12:08:19 +0300 > > Subject: [PATCH] USB: ehci-omap: Select USB_PHY > > > > As we need NOP_USB_XCEIV which depends on USB_PHY > > we need to select USB_PHY as well. > > > > Gets rid of the below warnings when USB_EHCI_HCD_OMAP > > is enabled. > > > > warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet > > direct dependencies (USB_SUPPORT && USB_PHY) > > warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet > > direct dependencies (USB_SUPPORT && USB_PHY) > > > > Signed-off-by: Roger Quadros > > Ideally, however, we wouldn't select any PHY in particular as different > boards might need a different PHY driver, even on OMAP ;-) > > >>> Right, but we need to select USB_PHY here as the driver uses > >>> the USB_PHY APIs. > >>> > >>> The NOP_USB_XCEIV selection could be done by the board config. > >> > >> I would avoid 'select' completely and just update omap2plus_defconfig > >> adding those two as modules. > >> > > > > OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". > > > > One more issue to clarify. > > if USB_PHY is not enabled, then all phy_get() API's should return NULL and not > -ENXIO as it does now. ENXIO means "No such device or address", looks alright to me ;-) > This way the drivers need not treat it as an error and all PHY ops can > be NOPs. drivers will already be using if (IS_ERR()) construction, returning -ENXIO when the API is disabled gives them an oportunity to *not* request probe deferral since the API isn't enabled anyway. > This will make it behave like other frameworks. e.g. clk. if we return NULL we will need IS_ERR_OR_NULL() which will cause problems with people who aren't careful enough. -- balbi signature.asc Description: Digital signature
Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using "no_console_suspend"
Kevin Hilman writes: > "Bedia, Vaibhav" writes: > >> Hi Sourav, >> >> On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote: >> [...] >>> Yes, had a look at that and found your situation similar to UART. >>> >>> But how exactly this gets used, I mean I don't see any drivers/ in mainline >>> making use of this compatible string "ti,am3352-ocmcram". ? >> >> OCMC clock is enabled during bootup (not sure whether that's the h/w >> default or ROM does it) since the initial bootloader runs from there. >> By marking the corresponding hwmod with HWMOD_INIT_NO_IDLE we leave the >> clock running. Right now the sram code under arch/arm/plat-omap/ is what >> manages the OCMC. I guess this needs to move somewhere under drivers/ >> and start managing the clocks. Even then we'll need a mechanism >> to leave the clocks running as part of the kernel suspend process >> since the assembly code which runs at the fag end of the suspend >> process runs out of OCMC and hence we can't cut its clock. >> >> On AM335x, the OCMC clock is cut to have PER power domain transition >> but that's done in the WKUP-M3 firmware when going down. During the >> wakeup sequence, WKUP-M3 re-enables the OCMC clock so that when the >> kernel resumes the h/w state is same. > > OK, but *today*, in *mainline*, where in the linux kernel (not the M3 > firmware) is the OCMRAM clock cut during suspend? > > From what I can see, there is no driver for this device, so there are no > system PM calls being done for that device, and thus no omap_device > calls being done for that device, so the no_idle_on_suspend has no > effect. OK, I think I confused things here, sorry. I was thinking runtime PM here, but wrote system PM. The no_idle_on_suspend feature only affects system PM, and the omap_device calls will still be called during system PM, even without a driver. That being said, the commit below[1], added in v3.6 should prevent the any automaic clock gating for devices without drivers bound. Since there is no driver for the OCM RAM block, you shouldn't be affected by the automatic idle on suspend anyways. So, my proposal is that Sourav remove that flag from the AM33xx hwmod when he removes this feature. Kevin [1] commit 72bb6f9b51c82c820ddef892455a85b115460904 Author: Kevin Hilman Date: Tue Jul 10 15:29:04 2012 -0700 ARM: OMAP: omap_device: don't attempt late suspend if no driver bound Currently, the omap_device PM domain layer uses the late suspend and early resume callbacks to ensure devices are in their low power states. However, this is attempted even in cases where a driver probe has failed. If a driver's ->probe() method fails, the driver is likely in a state where it is not expecting its runtime PM callbacks to be called, yet currently the omap_device PM domain code attempts to call the drivers callbacks. To fix, use the omap_device driver_status field to check whether a driver is bound to the omap_device before attempting to trigger driver callbacks. Reviewed-by: Paul Walmsley Signed-off-by: Kevin Hilman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/26] arm: Don't use create_proc_read_entry() [RFC]
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
Signed-off-by: David Howells
cc: Russell King
cc: Kevin Hilman
cc: Tony Lindgren
cc: linux-arm-ker...@lists.infradead.org
cc: linux-omap@vger.kernel.org
---
arch/arm/kernel/swp_emulate.c | 42 +-
arch/arm/mach-omap1/pm.c | 58 +
2 files changed, 43 insertions(+), 57 deletions(-)
diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
index 0bba47a..087fc32 100644
--- a/arch/arm/kernel/swp_emulate.c
+++ b/arch/arm/kernel/swp_emulate.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -79,27 +80,27 @@ static unsigned long abtcounter;
static pid_t previous_pid;
#ifdef CONFIG_PROC_FS
-static int proc_read_status(char *page, char **start, off_t off, int count,
- int *eof, void *data)
+static int proc_status_show(struct seq_file *m, void *v)
{
- char *p = page;
- int len;
-
- p += sprintf(p, "Emulated SWP:\t\t%lu\n", swpcounter);
- p += sprintf(p, "Emulated SWPB:\t\t%lu\n", swpbcounter);
- p += sprintf(p, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
+ seq_printf(m, "Emulated SWP:\t\t%lu\n", swpcounter);
+ seq_printf(m, "Emulated SWPB:\t\t%lu\n", swpbcounter);
+ seq_printf(m, "Aborted SWP{B}:\t\t%lu\n", abtcounter);
if (previous_pid != 0)
- p += sprintf(p, "Last process:\t\t%d\n", previous_pid);
-
- len = (p - page) - off;
- if (len < 0)
- len = 0;
-
- *eof = (len <= count) ? 1 : 0;
- *start = page + off;
+ seq_printf(m, "Last process:\t\t%d\n", previous_pid);
+ return 0;
+}
- return len;
+static int proc_status_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, proc_status_show, PDE_DATA(inode));
}
+
+static const struct file_operations proc_status_fops = {
+ .open = proc_status_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= seq_release,
+};
#endif
/*
@@ -266,12 +267,7 @@ static struct undef_hook swp_hook = {
static int __init swp_emulation_init(void)
{
#ifdef CONFIG_PROC_FS
- struct proc_dir_entry *res;
-
- res = create_proc_read_entry("cpu/swp_emulation", S_IRUGO, NULL,
- proc_read_status, NULL);
-
- if (!res)
+ if (!proc_create("cpu/swp_emulation", S_IRUGO, NULL, &proc_status_fops))
return -ENOMEM;
#endif /* CONFIG_PROC_FS */
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 7a7690a..2645e37 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -423,22 +424,11 @@ void omap1_pm_suspend(void)
}
#if defined(DEBUG) && defined(CONFIG_PROC_FS)
-static int g_read_completed;
-
/*
* Read system PM registers for debugging
*/
-static int omap_pm_read_proc(
- char *page_buffer,
- char **my_first_byte,
- off_t virtual_start,
- int length,
- int *eof,
- void *data)
+static int omap_pm_proc_show(struct seq_file *m, void *v)
{
- int my_buffer_offset = 0;
- char * const my_base = page_buffer;
-
ARM_SAVE(ARM_CKCTL);
ARM_SAVE(ARM_IDLECT1);
ARM_SAVE(ARM_IDLECT2);
@@ -479,10 +469,7 @@ static int omap_pm_read_proc(
MPUI1610_SAVE(EMIFS_CONFIG);
}
- if (virtual_start == 0) {
- g_read_completed = 0;
-
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ seq_printf(m,
"ARM_CKCTL_REG:0x%-8x \n"
"ARM_IDLECT1_REG: 0x%-8x \n"
"ARM_IDLECT2_REG: 0x%-8x \n"
@@ -512,8 +499,8 @@ static int omap_pm_read_proc(
ULPD_SHOW(ULPD_STATUS_REQ),
ULPD_SHOW(ULPD_POWER_CTRL));
- if (cpu_is_omap7xx()) {
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ if (cpu_is_omap7xx()) {
+ seq_printf(m,
"MPUI7XX_CTRL_REG 0x%-8x \n"
"MPUI7XX_DSP_STATUS_REG: 0x%-8x \n"
"MPUI7XX_DSP_BOOT_CONFIG_REG: 0x%-8x \n"
@@ -526,8 +513,8 @@ static int omap_pm_read_proc(
MPUI7XX_SHOW(MPUI_DSP_API_CONFIG),
MPUI7XX_SHOW(EMIFF_SDRAM_CONFIG),
MPUI7XX_SHOW(EMIFS_CONFIG));
- } else if (cpu_is_omap15xx()) {
- my_buffer_offset += sprintf(my_base + my_buffer_offset,
+ } else if (cpu_is_omap15xx()) {
+ seq_printf(m,
"MPUI1510_CTRL_REG
gpio/omap v2: map irq_enable/disable to mask/unmask.
Hi Santosh, I submitted the following patch a while back. https://patchwork.kernel.org/patch/1886421/ As already said, the patch is straight forward, but without it, we probably will not see decent SDIO performance on am335x chips. [why it is needed] The omap_hsmmc module is suspended whenever it is idle, its functional clock being turned off. In this mode it is not able to forwared IRQs to the system. For that to happen, it needs to tell the PRCM to restore it's fclk. -- | PRCM | -- | ^ fclk | | swakeup v | --- -- <-- IRQ -- | hsmmc | <-- CIRQ -- | card | --- -- This is done through the swakeup line, which can be configured to trigger for various events, among others; CIRQ. The problem is that on the AM335x family the swakeup line is missing, it has not been routed from the module to the PRCM. [solution] the simplest solution was to keep the fclk enabled all the time. But that was not accepted, instead this was suggested > > The alternative was to configure dat1 line as a GPIO, while > > waiting for an IRQ. Then configuring it back as dat1 to serve > > the SDIO card after it signalled an IRQ. Or when the host > > wants to start a transfer. > > The way to implement this is set named states in the .dts file > for the pins using pinctrl-single.c, then have the MMC driver > request states "default" "active" and "idle" during the probe, > then toggle between active and idle during the runtime. Surprisingly the induced overhead is quite small, the performance is similar to keeping the fclk enabled at all times. See here for full thread: http://www.spinics.net/lists/linux-omap/msg83363.html https://patchwork.kernel.org/patch/1901471/ ... or just the patch There are still open questions to gpio patch itself, see here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg87217.html So could we pls reopen that thread? It might be on the other side of your mailbox rgds, Andi -- 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] USB: ehci-omap: Select USB_PHY
On 04/11/2013 03:42 PM, Roger Quadros wrote: > On 04/11/2013 01:55 PM, Felipe Balbi wrote: >> Hi, >> >> On Thu, Apr 11, 2013 at 01:51:16PM +0300, Roger Quadros wrote: >>> On 04/11/2013 01:04 PM, Felipe Balbi wrote: Hi, On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: > Hi Greg, > > The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP > is enabled. > > Patch is based on your usb-next branch and is needed for 3.10. > > From: Roger Quadros > Date: Thu, 11 Apr 2013 12:08:19 +0300 > Subject: [PATCH] USB: ehci-omap: Select USB_PHY > > As we need NOP_USB_XCEIV which depends on USB_PHY > we need to select USB_PHY as well. > > Gets rid of the below warnings when USB_EHCI_HCD_OMAP > is enabled. > > warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct > dependencies (USB_SUPPORT && USB_PHY) > warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct > dependencies (USB_SUPPORT && USB_PHY) > > Signed-off-by: Roger Quadros Ideally, however, we wouldn't select any PHY in particular as different boards might need a different PHY driver, even on OMAP ;-) >>> Right, but we need to select USB_PHY here as the driver uses >>> the USB_PHY APIs. >>> >>> The NOP_USB_XCEIV selection could be done by the board config. >> >> I would avoid 'select' completely and just update omap2plus_defconfig >> adding those two as modules. >> > > OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". > One more issue to clarify. if USB_PHY is not enabled, then all phy_get() API's should return NULL and not -ENXIO as it does now. This way the drivers need not treat it as an error and all PHY ops can be NOPs. This will make it behave like other frameworks. e.g. clk. cheers, -roger. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Am 11.04.2013 14:42, schrieb Roger Quadros: > On 04/11/2013 01:55 PM, Felipe Balbi wrote: >> I would avoid 'select' completely and just update omap2plus_defconfig >> adding those two as modules. >> > > OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". Sorry, but this just will end up with many users having broken configs because of disabled stuff they don't know why they have to enable them. And thus with a never ending stream of questions and thus with a needed FAQ entry. Regards, Alexander -- 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] USB: ehci-omap: Select USB_PHY
On 04/11/2013 01:55 PM, Felipe Balbi wrote: > Hi, > > On Thu, Apr 11, 2013 at 01:51:16PM +0300, Roger Quadros wrote: >> On 04/11/2013 01:04 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: Hi Greg, The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP is enabled. Patch is based on your usb-next branch and is needed for 3.10. From: Roger Quadros Date: Thu, 11 Apr 2013 12:08:19 +0300 Subject: [PATCH] USB: ehci-omap: Select USB_PHY As we need NOP_USB_XCEIV which depends on USB_PHY we need to select USB_PHY as well. Gets rid of the below warnings when USB_EHCI_HCD_OMAP is enabled. warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT && USB_PHY) warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT && USB_PHY) Signed-off-by: Roger Quadros >>> >>> Ideally, however, we wouldn't select any PHY in particular as different >>> boards might need a different PHY driver, even on OMAP ;-) >>> >> Right, but we need to select USB_PHY here as the driver uses >> the USB_PHY APIs. >> >> The NOP_USB_XCEIV selection could be done by the board config. > > I would avoid 'select' completely and just update omap2plus_defconfig > adding those two as modules. > OK, makes sense. I will update the patch to remove "select NOP_USB_XCEIV". cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 5/5] omap dt changes for v3.10 merge window
Hi, On Mon, Apr 08, 2013 at 09:51:03PM -0700, Tony Lindgren wrote: > The following changes since commit 5852264f9d6139751796853fdfca9d5230cbfb97: > > Merge tag 'omap-devel-b-for-3.10' of > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into > for_3.10/dts_merged (2013-04-09 00:11:05 +0200) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.10/dt-signed-v2 > > for you to fetch changes up to 161e89a689bb88004b757986eefda2402448eef7: > > ARM/dts: OMAP3: fix pinctrl-single configuration (2013-04-08 17:00:22 -0700) > > > Device tree updates for omaps via Benoit Cousson . > > Note that the branch has dependencies to two other branches: > > - omap-devel-b-for-3.10 from Paul to get the AM33xx missing > hwmod and thus avoid a regression with Santosh's hwmod > cleanup including in this DT series [1]. It avoids breaking > bisect if this series is merged before Paul's fixes. Looks like this was part of omap/fixes-non-critical, the branch name from Paul just didn't percolate up. At least the topmost SHA from that merge in your history seems to be part of said branch. :) > - omap-for-v3.10/usb branch to avoid nasty merge conflict in > omap3.dtsi and omap4.dtsi due to the DTS patches contained > in the USB branch because of a screw up by the unnamed person > typing this signed tag based on Benoit's comments. Ok, it looks like this one was merged in next/drivers as omap/usb. So based on the above, I've merged in omap/fixes-non-critical and omap/usb as a base, and merged this on top. All of this has gone into next/dt2. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Hi, On Thu, Apr 11, 2013 at 01:51:16PM +0300, Roger Quadros wrote: > On 04/11/2013 01:04 PM, Felipe Balbi wrote: > > Hi, > > > > On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: > >> Hi Greg, > >> > >> The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP > >> is enabled. > >> > >> Patch is based on your usb-next branch and is needed for 3.10. > >> > >> From: Roger Quadros > >> Date: Thu, 11 Apr 2013 12:08:19 +0300 > >> Subject: [PATCH] USB: ehci-omap: Select USB_PHY > >> > >> As we need NOP_USB_XCEIV which depends on USB_PHY > >> we need to select USB_PHY as well. > >> > >> Gets rid of the below warnings when USB_EHCI_HCD_OMAP > >> is enabled. > >> > >> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct > >> dependencies (USB_SUPPORT && USB_PHY) > >> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct > >> dependencies (USB_SUPPORT && USB_PHY) > >> > >> Signed-off-by: Roger Quadros > > > > Ideally, however, we wouldn't select any PHY in particular as different > > boards might need a different PHY driver, even on OMAP ;-) > > > Right, but we need to select USB_PHY here as the driver uses > the USB_PHY APIs. > > The NOP_USB_XCEIV selection could be done by the board config. I would avoid 'select' completely and just update omap2plus_defconfig adding those two as modules. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: ehci-omap: Select USB_PHY
On 04/11/2013 01:04 PM, Felipe Balbi wrote: > Hi, > > On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: >> Hi Greg, >> >> The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP >> is enabled. >> >> Patch is based on your usb-next branch and is needed for 3.10. >> >> From: Roger Quadros >> Date: Thu, 11 Apr 2013 12:08:19 +0300 >> Subject: [PATCH] USB: ehci-omap: Select USB_PHY >> >> As we need NOP_USB_XCEIV which depends on USB_PHY >> we need to select USB_PHY as well. >> >> Gets rid of the below warnings when USB_EHCI_HCD_OMAP >> is enabled. >> >> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct >> dependencies (USB_SUPPORT && USB_PHY) >> warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct >> dependencies (USB_SUPPORT && USB_PHY) >> >> Signed-off-by: Roger Quadros > > Ideally, however, we wouldn't select any PHY in particular as different > boards might need a different PHY driver, even on OMAP ;-) > Right, but we need to select USB_PHY here as the driver uses the USB_PHY APIs. The NOP_USB_XCEIV selection could be done by the board config. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-omap: Select USB_PHY
Hi, On Thu, Apr 11, 2013 at 12:42:04PM +0300, Roger Quadros wrote: > Hi Greg, > > The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP > is enabled. > > Patch is based on your usb-next branch and is needed for 3.10. > > From: Roger Quadros > Date: Thu, 11 Apr 2013 12:08:19 +0300 > Subject: [PATCH] USB: ehci-omap: Select USB_PHY > > As we need NOP_USB_XCEIV which depends on USB_PHY > we need to select USB_PHY as well. > > Gets rid of the below warnings when USB_EHCI_HCD_OMAP > is enabled. > > warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct > dependencies (USB_SUPPORT && USB_PHY) > warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct > dependencies (USB_SUPPORT && USB_PHY) > > Signed-off-by: Roger Quadros Ideally, however, we wouldn't select any PHY in particular as different boards might need a different PHY driver, even on OMAP ;-) -- balbi signature.asc Description: Digital signature
Re: 4430sdp nfsroot broken with ff5c9059
On Thu, Apr 11, 2013 at 11:22 AM, Benoit Cousson wrote:
> Hi Javier,
>
> On 04/11/2013 01:58 AM, Javier Martinez Canillas wrote:
>> On Wed, Apr 10, 2013 at 7:31 PM, Jon Hunter wrote:
>>> Hi Tony,
>>>
>>> On 04/09/2013 04:23 PM, Tony Lindgren wrote:
Hi Jon,
Looks like at least 4430sdp nfsroot got broken with commit
ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells
property).
>>>
>>> Thanks for reporting. I am actually amazed that ethernet is
>>> working on any OMAP board (with device-tree) that requires a
>>> gpio as an interrupt because we have still not come to an
>>> agreement on [1]. Looking at the OMAP4 SDP I believe this is
>>> working by luck because there are other gpios in the same
>>> bank that are active and so the bank is enabled. If that were
>>> not the case then this would not work.
>>>
>>
>> Hi Jon,
>>
>> Ethernet is working on 4430sdp since the optional "gpio" property is
>> specified on the fixed regulator used by the eth device node.
>>
>> From arch/arm/boot/dts/omap4-sdp.dts:
>>
>> vdd_eth: fixedregulator-vdd-eth {
>> compatible = "regulator-fixed";
>> regulator-name = "VDD_ETH";
>> regulator-min-microvolt = <330>;
>> regulator-max-microvolt = <330>;
>> gpio = <&gpio2 16 0>; /* gpio line 48 */
>> enable-active-high;
>> regulator-boot-on;
>> };
>> ...
>> &mcspi1 {
>> eth@0 {
>> compatible = "ks8851";
>> spi-max-frequency = <2400>;
>> reg = <0>;
>> interrupt-parent = <&gpio2>;
>> interrupts = <2>; /* gpio line 34 */
>> vdd-supply = <&vdd_eth>;
>> };
>> };
>>
>> So is the regulator who is calling gpio_request() and enabling the
>> GPIO bank and no the ks881 ethernet driver. That's why it was working
>> although I think is just a DT hack and should be changed once we found
>> a proper solution to fhis.
>
> It is not really a hack. There is a regulator controlled by a GPIO that
> can control the Ethernet chip power. Both gpio48 and gpio34 are used for
> Ethernet. On some SDP version there is even a third line, but I was not
> able to find any evidence in the schematic I was using.
>
> Regards,
> Benoit
>
Hi Benoit,
I (wrongly) assumed that this was made just to bypass the fact that
neither the ks881 driver nor the DT core call omap_gpio_request() to
enable the GPIO bank module.
But now thanks to your explanation I understand that gpio48 is also
necessary to control the regulator and as Jon said the lucky fact is
that both GPIO 48 and 34 are from the same GPIO bank module (gpio2).
If that was not the case, this would probably not work.
I should learn to not comment without looking at the schematic first.
Thanks a lot and best regards,
Javier
--
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] USB: ehci-omap: Select USB_PHY
Hi Greg, The following patch gets rid of Kbuild warnings when USB_EHCI_HCD_OMAP is enabled. Patch is based on your usb-next branch and is needed for 3.10. From: Roger Quadros Date: Thu, 11 Apr 2013 12:08:19 +0300 Subject: [PATCH] USB: ehci-omap: Select USB_PHY As we need NOP_USB_XCEIV which depends on USB_PHY we need to select USB_PHY as well. Gets rid of the below warnings when USB_EHCI_HCD_OMAP is enabled. warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT && USB_PHY) warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT && USB_PHY) Signed-off-by: Roger Quadros --- drivers/usb/host/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index c0be25c..931b437 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -150,6 +150,7 @@ config USB_EHCI_MXC config USB_EHCI_HCD_OMAP tristate "EHCI support for OMAP3 and later chips" depends on ARCH_OMAP + select USB_PHY select NOP_USB_XCEIV default y ---help--- -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAPDSS: DPI: widen the pck search when using dss fck
When not using DSI PLL to generate the pixel clock, but DSS FCK, the
possible pixel clock rates are rather limited. DSS FCK is currently used
on OMAP2 and OMAP3.
When using Beagleboard with a monitor that supports high resolutions,
the clock rates do not match (at least for me) for the monitor's pixel
clocks within the current threshold in the code, which is +/- 1MHz.
This patch widens the search up to +/- 15MHz. The search is done in
steps, i.e. it first tries to find a rather exact clock, than a bit less
exact, etc. so this should not change the cases where a clock was
already found.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index abe1a4e2..e93c4de 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -222,10 +222,10 @@ static bool dpi_dss_clk_calc(unsigned long pck, struct
dpi_clk_calc_ctx *ctx)
* DSS fck gives us very few possibilities, so finding a good pixel
* clock may not be possible. We try multiple times to find the clock,
* each time widening the pixel clock range we look for, up to
-* +/- 1MHz.
+* +/- ~15MHz.
*/
- for (i = 0; i < 10; ++i) {
+ for (i = 0; i < 25; ++i) {
bool ok;
memset(ctx, 0, sizeof(*ctx));
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAPDSS: fix dss_fck clock rate rounding
DSS func clock is calculated with prate / div * m. However, the current
omapdss code calculates it with prate * m / div, which yields a slightly
different result when there's a remainder. For example, 43200 / 14 *
2 = 61714284, but 43200 * 2 / 14 = 61714285.
In addition to that, the clock framework wants the clock rate given with
clk_set_rate to be higher than the actual (truncated) end result. So, if
prate is 43200, and div is 14, the real result is 30857142.8571...
We need to call clk_set_rate with 30857143, which gives us a clock of
30857142. That's why we need to use DIV_ROUND_UP() when calling
clk_set_rate.
This patch fixes the clock calculation.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index fdd32e8..b9f6f24 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -480,6 +480,7 @@ bool dss_div_calc(unsigned long fck_min, dss_div_calc_func
func, void *data)
unsigned long fck_hw_max;
unsigned long fckd_hw_max;
unsigned long prate;
+ unsigned m;
if (dss.dpll4_m4_ck == NULL) {
/*
@@ -495,15 +496,16 @@ bool dss_div_calc(unsigned long fck_min,
dss_div_calc_func func, void *data)
fck_hw_max = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
fckd_hw_max = dss.feat->fck_div_max;
- prate = dss_get_dpll4_rate() * dss.feat->dss_fck_multiplier;
+ m = dss.feat->dss_fck_multiplier;
+ prate = dss_get_dpll4_rate();
fck_min = fck_min ? fck_min : 1;
- fckd_start = min(prate / fck_min, fckd_hw_max);
- fckd_stop = max(DIV_ROUND_UP(prate, fck_hw_max), 1ul);
+ fckd_start = min(prate * m / fck_min, fckd_hw_max);
+ fckd_stop = max(DIV_ROUND_UP(prate * m, fck_hw_max), 1ul);
for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
- fck = prate / fckd;
+ fck = prate / fckd * m;
if (func(fckd, fck, data))
return true;
@@ -521,7 +523,8 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
DSSDBG("dpll4_m4 = %ld\n", prate);
- r = clk_set_rate(dss.dpll4_m4_ck, prate / cinfo->fck_div);
+ r = clk_set_rate(dss.dpll4_m4_ck,
+ DIV_ROUND_UP(prate, cinfo->fck_div));
if (r)
return r;
} else {
@@ -531,7 +534,9 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
- WARN_ONCE(dss.dss_clk_rate != cinfo->fck, "clk rate mismatch");
+ WARN_ONCE(dss.dss_clk_rate != cinfo->fck,
+ "clk rate mismatch: %lu != %lu", dss.dss_clk_rate,
+ cinfo->fck);
DSSDBG("fck = %ld (%d)\n", cinfo->fck, cinfo->fck_div);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430sdp nfsroot broken with ff5c9059
Hi Javier,
On 04/11/2013 01:58 AM, Javier Martinez Canillas wrote:
> On Wed, Apr 10, 2013 at 7:31 PM, Jon Hunter wrote:
>> Hi Tony,
>>
>> On 04/09/2013 04:23 PM, Tony Lindgren wrote:
>>> Hi Jon,
>>>
>>> Looks like at least 4430sdp nfsroot got broken with commit
>>> ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells
>>> property).
>>
>> Thanks for reporting. I am actually amazed that ethernet is
>> working on any OMAP board (with device-tree) that requires a
>> gpio as an interrupt because we have still not come to an
>> agreement on [1]. Looking at the OMAP4 SDP I believe this is
>> working by luck because there are other gpios in the same
>> bank that are active and so the bank is enabled. If that were
>> not the case then this would not work.
>>
>
> Hi Jon,
>
> Ethernet is working on 4430sdp since the optional "gpio" property is
> specified on the fixed regulator used by the eth device node.
>
> From arch/arm/boot/dts/omap4-sdp.dts:
>
> vdd_eth: fixedregulator-vdd-eth {
> compatible = "regulator-fixed";
> regulator-name = "VDD_ETH";
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> gpio = <&gpio2 16 0>; /* gpio line 48 */
> enable-active-high;
> regulator-boot-on;
> };
> ...
> &mcspi1 {
> eth@0 {
> compatible = "ks8851";
> spi-max-frequency = <2400>;
> reg = <0>;
> interrupt-parent = <&gpio2>;
> interrupts = <2>; /* gpio line 34 */
> vdd-supply = <&vdd_eth>;
> };
> };
>
> So is the regulator who is calling gpio_request() and enabling the
> GPIO bank and no the ks881 ethernet driver. That's why it was working
> although I think is just a DT hack and should be changed once we found
> a proper solution to fhis.
It is not really a hack. There is a regulator controlled by a GPIO that
can control the Ethernet chip power. Both gpio48 and gpio34 are used for
Ethernet. On some SDP version there is even a third line, but I was not
able to find any evidence in the schematic I was using.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/11/2013 10:48 AM, Roger Quadros wrote: On 04/10/2013 08:39 PM, Nishanth Menon wrote: On 13:55-20130410, Roger Quadros wrote: On 04/10/2013 11:06 AM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-09 13:49:00) On 10:43-20130409, Tony Lindgren wrote: * Tony Lindgren [130409 09:54]: * Roger Quadros [130409 03:00]: On 04/05/2013 06:58 PM, Tony Lindgren wrote: Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt Yes I understand that. But the driver/clock/omap driver can just remap the DT device initially so the board specific clock is found from the clock alias table. Basically initially a passthrough driver that can be enhanced to parse DT clock bindings and load data from /lib/firmware. Actually probably the driver/clock/omap can even do even less initially. There probably even no need to remap clocks there. As long as the DT clock driver understands that a board specific auxclk is specified in the DT it can just call clk_add_alias() so the driver will get the right auxclk from cclock44xx_data.c. Then other features can be added later on like to allocate a clock entirely based on the binding etc. I did try to have an implementation for cpufreq using clock nodes. unfortunately, device tree wont let me have arguments of strings :( So, I am unable to do clock = <&clk mpu_dpll>; instead, I am forced to do clock = <&clk 249>; See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034 Awesome. Thanks for pointing this out Mike. Now all we need to do is create a named define for each clock index in the header file. Approach #3: Thanks to Tony for collaborating on this: Works for cpufreq-cpu0 - additional patches: http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on beagleXM) Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing this. Details in the patch below (Tony, I have added you as collaborator for helping in getting this working-clk_add_alias was'nt needed in the internal patch discussion we had - I have taken a bit of freedom in adding your contributions to the patch below) Folks, this does seem to be the best compromise we can achieve at this point in time. feedback on this approach is much appreciated - if folks are ok, I can post this as an formal patch series. This looks fine to me. Minor comments below. I like it. No IDs and can add clocks support in DT as needed. From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Tue, 9 Apr 2013 19:26:40 -0500 Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock data OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. However, this presents an obstacle for using these clock nodes in Device Tree definitions. There are many possible approaches to this problem as discussed in the following thread: http://marc.info/?t=13637032569&r=1&w=2 Highlights of the options: a) device specific clk_add_alias: cons: driver handling required b) using an generic clk node and indexing to reach the clock required. This is similar in approach taken by tegra and few other platforms. example clock = <&clk 5>; cons: potential to have mismatches in indexed table and associated dtb data. In addition, managing continued documentation in bindings as clock indexing increases. Even though readability angle could be improved by using preprocessing of DT using macros, indexed approach is inherently risky from cases like the following: clk indexes in kernel: 1 - mpu_dpll 2 - aux_clk1 3 - core_clk DT entry for peripheral x uses <&clk 2>, kernel updates to: 1 - mpu_dpll 2 - per_dpll 3 - aux_clk1 4 - core_clk using the old dtb(or dts missing an update), on new kernel which has updated indices will result in per_dpll now controlled for peripheral X without warning or any potential error detection and warning. Even though we can claim this is user error, such errors are hard to track down and fix. An alternate approach introduced here is to introduce device tree bindings corresponding to the clock nodes required in DT definition for SoC which automatically maps back to the definitions in cclockXYZ_data.c. The driver introduced here to do this mapping will eventually be the place where the clock handling will migrate to. We need to consider this angle as well so that the solution will be an valid transition point for moving the clock data out of kernel image (into device tree or firmware load etc..). Overall strategy introduced here is simple: an clock node described in typo: "an"->"a" device tree blob is used to identify the exact clock provided in the SoC specific data. This is then linked back using of_clk_add_provider to the device node to be accessible by of_clk_get.
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/10/2013 08:39 PM, Nishanth Menon wrote: > On 13:55-20130410, Roger Quadros wrote: >> On 04/10/2013 11:06 AM, Mike Turquette wrote: >>> Quoting Nishanth Menon (2013-04-09 13:49:00) On 10:43-20130409, Tony Lindgren wrote: > * Tony Lindgren [130409 09:54]: >> * Roger Quadros [130409 03:00]: >>> On 04/05/2013 06:58 PM, Tony Lindgren wrote: Can't you just use the clock name there to get it? >>> >>> In device tree we don't pass around clock names. You can either get >>> a phandle or an index to the clock. >>> >>> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt >> >> Yes I understand that. But the driver/clock/omap driver can just >> remap the DT device initially so the board specific clock is >> found from the clock alias table. Basically initially a passthrough >> driver that can be enhanced to parse DT clock bindings and load >> data from /lib/firmware. > > Actually probably the driver/clock/omap can even do even less > initially. There probably even no need to remap clocks there. > > As long as the DT clock driver understands that a board specific > auxclk is specified in the DT it can just call clk_add_alias() so > the driver will get the right auxclk from cclock44xx_data.c. > > Then other features can be added later on like to allocate a > clock entirely based on the binding etc. I did try to have an implementation for cpufreq using clock nodes. unfortunately, device tree wont let me have arguments of strings :( So, I am unable to do clock = <&clk mpu_dpll>; instead, I am forced to do clock = <&clk 249>; >>> >>> See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034 >>> >> >> Awesome. Thanks for pointing this out Mike. >> >> Now all we need to do is create a named define for each clock index in the >> header file. > Approach #3: Thanks to Tony for collaborating on this: > Works for cpufreq-cpu0 - additional patches: > http://pastebin.com/GHnTRVJf, http://pastebin.com/FZS89J6L (tested on > beagleXM) > Work for USB - http://pastebin.com/aJpDnXci - thanks Roger for testing > this. > Details in the patch below (Tony, I have added you as collaborator for > helping in getting this working-clk_add_alias was'nt needed in the > internal patch discussion we had - I have taken a bit of freedom in > adding your contributions to the patch below) > > Folks, this does seem to be the best compromise we can achieve at this > point in time. feedback on this approach is much appreciated - if folks > are ok, I can post this as an formal patch series. This looks fine to me. Minor comments below. > > From 130a41821bf57081ca45ef654029175d173135e6 Mon Sep 17 00:00:00 2001 > From: Nishanth Menon > Date: Tue, 9 Apr 2013 19:26:40 -0500 > Subject: [RFC PATCH] clk: OMAP: introduce device tree binding to kernel clock > data > > OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. > However, this presents an obstacle for using these clock nodes in > Device Tree definitions. There are many possible approaches to this > problem as discussed in the following thread: > http://marc.info/?t=13637032569&r=1&w=2 > Highlights of the options: > a) device specific clk_add_alias: > cons: driver handling required > b) using an generic clk node and indexing to reach the clock required. >This is similar in approach taken by tegra and few other platforms. >example clock = <&clk 5>; >cons: potential to have mismatches in indexed table and associated >dtb data. In addition, managing continued documentation in bindings >as clock indexing increases. Even though readability angle could be >improved by using preprocessing of DT using macros, indexed approach >is inherently risky from cases like the following: >clk indexes in kernel: >1 - mpu_dpll >2 - aux_clk1 >3 - core_clk >DT entry for peripheral x uses <&clk 2>, kernel updates to: >1 - mpu_dpll >2 - per_dpll >3 - aux_clk1 >4 - core_clk >using the old dtb(or dts missing an update), on new kernel which has >updated indices will result in per_dpll now controlled for peripheral >X without warning or any potential error detection and warning. > >Even though we can claim this is user error, such errors are hard to >track down and fix. > > An alternate approach introduced here is to introduce device tree bindings > corresponding to the clock nodes required in DT definition for SoC which > automatically maps back to the definitions in cclockXYZ_data.c. > > The driver introduced here to do this mapping will eventually be the > place where the clock handling will migrate to. We need to consider this > angle as well so that the solution will be an valid transition point for > moving the clock data out of kernel image (into device tree or firmware load > etc..). > > Overall strategy introduced here is simple: an clock node descr
