Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote: diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..5635202 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,10 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: phandle to 60MHz functional clock to the USB Host module. + +- clock-names: must be init_60m_fclk + Required properties if child node exists: - #address-cells: Must be 1 I have some questions: What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't all of those be provided by via the DT phandle? Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the driver? This would potentially remove the need of the init_60m_fclk name. $ grep clk_get drivers/mfd/omap-usb-host.c omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck); omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk); omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk); omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck); omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck); omap-init_60m_fclk = clk_get(dev, init_60m_fclk); omap-utmi_clk[i] = clk_get(dev, clkname); omap-hsic480m_clk[i] = clk_get(dev, clkname); omap-hsic60m_clk[i] = clk_get(dev, clkname); -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2] mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
pm_runtime_get/put_sync() can sleep so don't hold spinlock while calling them. This patch prevents a BUG() during system suspend when CONFIG_DEBUG_ATOMIC_SLEEP is enabled. Bug is present in Kernel versions v3.9 onwards. Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Tested-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: sta...@vger.kernel.org # 3.9+ --- drivers/mfd/omap-usb-tll.c | 36 1 file changed, 12 insertions(+), 24 deletions(-) Patch looks good to me now. Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] gpio: add GPIO hogging mechanism
On Mon, Dec 30, 2013 at 10:48 AM, boris brezillon b.brezil...@overkiz.com wrote: On 19/12/2013 19:22, Felipe Balbi wrote: that's quite a weird argument from Linus W, considering you _do_ have a discrete mux on the board. We have quite a few of such crazy scenarios here at TI and we were going to send a pinctrl-gpio driver. Hm I'm all in the blue as to what a pinctrl-gpio driver is ... I'm confused :-) If that's not acceptable, then I suppose there is no way to boot from NAND on a board where NAND signals go through a discrete mux where the select signal is a GPIO pin. One problem I have is that I still don't really understand if this is a pin mux, i.e. changing the connection to a certain device onto some actual *PIN* or just some other mux muxing some certain line from one silicon block to another. Linus, tell me if I'm wrong, but I think, the pinctrl-gpio is the right way to solve the at91rm9200ek board use case. I don't know, because I don't know exactly what you mean by pinctrl-gpio. 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On Wed, Jan 08, 2014 at 06:15:38AM +, Roger Quadros wrote: The omap-usb-host driver expects the 60MHz functional clock of the USB host module to be named as init_60m_fclk. Add this information in the DT binding document. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..5635202 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,10 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: phandle to 60MHz functional clock to the USB Host module. + +- clock-names: must be init_60m_fclk + Nit: clocks aren't just phandles, there's a clock-specifier too. Also, it would be nicer if clocks was defined in terms of clock-names, as it makes the relationship between clocks and clock-names clear, and makes it easier to extend the list in future. Something like: - clocks: a list of phandles + clock-specifiers, one for each entry in clock-names - clock-names: should include: * init_60m_fclk - the 60MHz functional clock to the USB host module. Thanks, Mark. -- 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
+Tero Hi Sebastian, On 01/08/2014 02:38 PM, Sebastian Reichel wrote: On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote: diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..5635202 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,10 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: phandle to 60MHz functional clock to the USB Host module. + +- clock-names: must be init_60m_fclk + Required properties if child node exists: - #address-cells: Must be 1 I have some questions: What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't all of those be provided by via the DT phandle? All those clocks are identically named across the OMAP SoCs and are unique for each SoC, so providing DT phandle for all of them is not required. The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for this binding. Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the driver? This would potentially remove the need of the init_60m_fclk name. If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as well to explicitly provide the clock phandle. For now we make use of the fact that SoC clock data names the clock rightly i.e. init_60m_fclk. $ grep clk_get drivers/mfd/omap-usb-host.c omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck); omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk); omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk); omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck); omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck); omap-init_60m_fclk = clk_get(dev, init_60m_fclk); omap-utmi_clk[i] = clk_get(dev, clkname); omap-hsic480m_clk[i] = clk_get(dev, clkname); omap-hsic60m_clk[i] = clk_get(dev, clkname); 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
Hi Mark, On 01/08/2014 03:26 PM, Mark Rutland wrote: On Wed, Jan 08, 2014 at 06:15:38AM +, Roger Quadros wrote: The omap-usb-host driver expects the 60MHz functional clock of the USB host module to be named as init_60m_fclk. Add this information in the DT binding document. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..5635202 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,10 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: phandle to 60MHz functional clock to the USB Host module. + +- clock-names: must be init_60m_fclk + Nit: clocks aren't just phandles, there's a clock-specifier too. Also, it would be nicer if clocks was defined in terms of clock-names, as it makes the relationship between clocks and clock-names clear, and makes it easier to extend the list in future. Something like: - clocks: a list of phandles + clock-specifiers, one for each entry in clock-names - clock-names: should include: * init_60m_fclk - the 60MHz functional clock to the USB host module. OK, I'll update it as per your suggestion. 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote: What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't all of those be provided by via the DT phandle? All those clocks are identically named across the OMAP SoCs and are unique for each SoC, so providing DT phandle for all of them is not required. The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for this binding. What do you mean it was renamed? Is it a different version of the omap-usb-host device then? Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the driver? This would potentially remove the need of the init_60m_fclk name. If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as well to explicitly provide the clock phandle. For now we make use of the fact that SoC clock data names the clock rightly i.e. init_60m_fclk. I'm getting the feeling that init_60m_fclk is not the name of the clock input of the omap-usb-host device at all, but rather the name of a signal on the omap soc, which would not be an appropriate identifier for the binding. Arnd -- 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On 01/08/2014 03:49 PM, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:39:36 Roger Quadros wrote:
What about the other clocks acquired in drivers/mfd/omap-usb-host.c?
Shouldn't
all of those be provided by via the DT phandle?
All those clocks are identically named across the OMAP SoCs and are unique
for each
SoC, so providing DT phandle for all of them is not required.
The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the
need for
this binding.
What do you mean it was renamed? Is it a different version of the
omap-usb-host
device then?
I meant the clock gates name on the SoC was renamed. The omap-usb-host device
version
is revised as well.
Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
driver? This would potentially remove the need of the init_60m_fclk name.
If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and
OMAP3 as
well to explicitly provide the clock phandle. For now we make use of the
fact that
SoC clock data names the clock rightly i.e. init_60m_fclk.
I'm getting the feeling that init_60m_fclk is not the name of the clock input
of the omap-usb-host device at all, but rather the name of a signal on the
omap soc, which would not be an appropriate identifier for the binding.
It is a clock gate defined like so in the DT clock data
on OMAP4
init_60m_fclk: init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};
on OMAP5
l3init_60m_fclk: l3init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};
So you can see that it is the same thing with a different name.
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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On Wednesday 08 January 2014 15:57:19 Roger Quadros wrote:
It is a clock gate defined like so in the DT clock data
on OMAP4
init_60m_fclk: init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};
on OMAP5
l3init_60m_fclk: l3init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};
So you can see that it is the same thing with a different name.
Right, but init_60m_fclk is the name of the clock output of the
divider here, which is /not/ what you should put in the clock-names
property of the consumer. The clock input name should reflect what
the clock is used for instead.
Arnd
--
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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
Hi, On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote: What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't all of those be provided by via the DT phandle? All those clocks are identically named across the OMAP SoCs and are unique for each SoC, so providing DT phandle for all of them is not required. The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for this binding. I understand the intention of this patch. I was just wondering if all the clocks should be referenced from DT even if that is not strictly needed at the moment. This would make clocks similar to other resources like regulators, gpios, irqs, ... Having the clocks referenced from DT looks cleaner to me. It means I can check the DT file for any resources used by a driver. It also creates some kind of consistency in the kernel. Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the driver? This would potentially remove the need of the init_60m_fclk name. If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 as well to explicitly provide the clock phandle. I'm aware of this. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On Wednesday 08 January 2014 11:52:44 Sebastian Reichel wrote: On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote: What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't all of those be provided by via the DT phandle? All those clocks are identically named across the OMAP SoCs and are unique for each SoC, so providing DT phandle for all of them is not required. The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for this binding. I understand the intention of this patch. I was just wondering if all the clocks should be referenced from DT even if that is not strictly needed at the moment. This would make clocks similar to other resources like regulators, gpios, irqs, ... Having the clocks referenced from DT looks cleaner to me. It means I can check the DT file for any resources used by a driver. It also creates some kind of consistency in the kernel. I think that would be best, yes. AFAIK most other platforms do this already, OMAP is a bit behind because it started using clocks when the infrastructure for doing this right was still incomplete. Arnd -- 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On 01/08/2014 04:10 PM, Arnd Bergmann wrote:
On Wednesday 08 January 2014 15:57:19 Roger Quadros wrote:
It is a clock gate defined like so in the DT clock data
on OMAP4
init_60m_fclk: init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};
on OMAP5
l3init_60m_fclk: l3init_60m_fclk {
#clock-cells = 0;
compatible = ti,divider-clock;
clocks = dpll_usb_m2_ck;
reg = 0x0104;
ti,dividers = 1, 8;
};
So you can see that it is the same thing with a different name.
Right, but init_60m_fclk is the name of the clock output of the
divider here, which is /not/ what you should put in the clock-names
property of the consumer. The clock input name should reflect what
the clock is used for instead.
Ah, now I get it. :). I agree that the name should reflect the function.
Looking more closely, the driver doesn't enable/disable the init_60m_fclk but
just
uses it to configure the parent of utmi_p1_gfclk which is a clock input to the
USB module.
Based on this I would call it refclk_int for internal reference clock.
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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On 01/08/2014 04:25 PM, Arnd Bergmann wrote: On Wednesday 08 January 2014 11:52:44 Sebastian Reichel wrote: On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote: What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't all of those be provided by via the DT phandle? All those clocks are identically named across the OMAP SoCs and are unique for each SoC, so providing DT phandle for all of them is not required. The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need for this binding. I understand the intention of this patch. I was just wondering if all the clocks should be referenced from DT even if that is not strictly needed at the moment. This would make clocks similar to other resources like regulators, gpios, irqs, ... Having the clocks referenced from DT looks cleaner to me. It means I can check the DT file for any resources used by a driver. It also creates some kind of consistency in the kernel. I think that would be best, yes. AFAIK most other platforms do this already, OMAP is a bit behind because it started using clocks when the infrastructure for doing this right was still incomplete. OK. I'll update the binding information to reflect all the clocks. But what about clk_get() vs of_clk_get_by_name() ? 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On Wednesday 08 January 2014, Roger Quadros wrote: OK. I'll update the binding information to reflect all the clocks. But what about clk_get() vs of_clk_get_by_name() ? I think the convention these days is to just use clk_get(), which calls of_clk_get_by_name() internally. Not sure if that's what you are asking. Arnd -- 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 v4 1/5] mfd: omap-usb-host: Update DT clock binding information
On 01/08/2014 05:05 PM, Arnd Bergmann wrote: On Wednesday 08 January 2014, Roger Quadros wrote: OK. I'll update the binding information to reflect all the clocks. But what about clk_get() vs of_clk_get_by_name() ? I think the convention these days is to just use clk_get(), which calls of_clk_get_by_name() internally. Not sure if that's what you are asking. OK fine. I'll continue to use clk_get() then. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] driver-core: platform: Resolve DT interrupt references late
When devices are probed from the device tree, any interrupts that they reference are resolved at device creation time. This causes problems if the interrupt provider hasn't been registered yet at that time, which results in the interrupt being set to 0. This is especially bad for platform devices because they are created at a very early stage during boot when the majority of interrupt providers haven't had a chance to be probed yet. One of the platform where this causes major issues is OMAP. Note that this patch is the easy way out to fix a large part of the problems for now. A more proper solution for the long term would be to transition drivers to an API that always resolves resources of any kind (not only interrupts) at probe time. For some background and discussion on possible solutions, see: https://lkml.org/lkml/2013/11/22/520 Acked-by: Rob Herring robherri...@gmail.com Signed-off-by: Thierry Reding tred...@nvidia.com --- Note that this is somewhat urgent and should if at all possible go into v3.13 before the release. drivers/base/platform.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 3a94b799f166..c894d1af3a5e 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -13,6 +13,7 @@ #include linux/string.h #include linux/platform_device.h #include linux/of_device.h +#include linux/of_irq.h #include linux/module.h #include linux/init.h #include linux/dma-mapping.h @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num) return -ENXIO; return dev-archdata.irqs[num]; #else - struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num); + struct resource *r; + + if (IS_ENABLED(CONFIG_OF) dev-dev.of_node) + return irq_of_parse_and_map(dev-dev.of_node, num); + + r = platform_get_resource(dev, IORESOURCE_IRQ, num); return r ? r-start : -ENXIO; #endif -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP
Hi Tony, On Wednesday 08 January 2014 05:25 AM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140107 15:10]: * Sricharan R r.sricha...@ti.com [131229 22:30]: On Friday 27 December 2013 07:19 PM, Sricharan R wrote: On Thursday 26 December 2013 11:14 PM, Santosh Shilimkar wrote: On Wednesday 25 December 2013 11:52 PM, Sricharan R wrote: On Wednesday 18 December 2013 02:49 PM, Sricharan R wrote: I have addressed all the comments on this series, can this be merged now ? Ping.. Thomas has already given his reviewed-by tag so the patches can be taken via arm-soc tree considering OMAP and GIC changes. Can you create a branch with all these patches applied and send it to Tony ? Ok, i will send out a branch for this. I have pushed the below branch git://github.com/Sricharanti/sricharan.git branch: crossbar This is on top of Tony's linux-omap master branch The linux-omap master branch cannot be used as a base as it contains tons of commit history not in mainline. So I'll manually applied these patches into omap-for-v3.14/crosbar branch. Oops, I noticed some errors on these: WARNING: drivers/built-in.o(.text+0xcd0): Section mismatch in reference from the function irqcrossbar_init() to the function .init.text:crossbar_of_init() The function irqcrossbar_init() references the function __init crossbar_of_init(). This is often because irqcrossbar_init lacks a __init annotation or the annotation of crossbar_of_init is wrong. WARNING: drivers/built-in.o(.text+0xcdc): Section mismatch in reference from the function irqcrossbar_init() to the (unknown reference) .init.rodata:(unknown) The function irqcrossbar_init() references the (unknown reference) __initconst (unknown). This is often because irqcrossbar_init lacks a __initconst annotation or the annotation of (unknown) is wrong. So I've dropped them for now. Care to fix up those errors and base your patches against let's say v3.13-rc5? Very Sorry for the section mismatch warning. I have fixed it and pushed a new branch below based on v3.13-rc5 git://github.com/Sricharanti/sricharan.git branch: crossbar_3.13_rc5 Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] drm/omap: fix issues in omap_drv probe/remove
On 2014-01-02 11:19, Archit Taneja wrote: At the moment, the omapdrm driver doesn't work on panda/beagle when built-in the kernel. The problem is that omapdrm doesn't defer probe if resources like regulator/I2C etc are missing. The first patch fixes that. The next 3 patches make sure that omapdrm module can be inserted and removed successively, and that omapdss is left in a consistent state when omapdrm is removed. In the previous version of this series, there was a warning related to apply_irq being registered seen while removing omapdrm. This was a relatively scary warning, therefore, the change dev_unload order patch was added to make sure we don't see that. After these fixes, I still see the warning below once in a while. I don't know how to fix it at the moment, but it's harmless and omapdrm is now usable again. These are critical fixes which I have posted since 3.12-rcs, it would be nice if they can go in as soon as possible. These look ok to me: Reviewed-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature
Re: [pandaboard] audio initialization fails due to TWL6040
On 01/08/2014 12:53 AM, Tony Lindgren wrote: Well we cannot sanely deprecate the ti,hwmods and move on to matching hwmod data with DT data based on the compatible flag. So it's a bit of a blocker for v3.15 or so time frame. Due to a 'hw feature' around the sidetone this is not as straight forward as it sounds... OK. The driver(s) should still be able to coordinate things to sort it out hopefully? After a quick look at the code: - sidetone _is_ broken when we boot with DT for sure already. - sidetone works only if we boot in legacy mode. While it is true that ST block has it's own address space and even dedicated irq line, but.. ST can be enabled from the McBSP address space (via SSELCR_REG). When ST is enabled we need to disable the corresponding McBSP's autoidle. The reason for this is that the ST block is clocked from the McBSP IP's interface clock. If the interface clock of the McBSP is idling there will be glitches in the sidetone generation due to not having continuously running clock for it's internals. For legacy boot we had this handled by a custom callback to disable autoidle for the McBSP when the ST starts and enable it back when ST is stopped: arch/arm/mach-omap2/mcbsp.c:omap3_enable_st_clock() is the callback we call. Normal audio will work via McBSP if we get rid of hwmod, the driver can load and operate that way. As for the sidetone functionality: it is broken when we boot with DT and the removal of hwmod will have no effect on this. The Sidetone address space also have sysconfig register with AUTOIDLE bit, but it has no effect on the McBSP_ICLK autoidle itself. In theory we can handle the sidetone as we do right now, but we need one thing: an API so drivers can disable/enable autoidle of an already enabled clock. CCing Tero for this, he might have pointers or idea on how we can do this. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote: When devices are probed from the device tree, any interrupts that they reference are resolved at device creation time. This causes problems if the interrupt provider hasn't been registered yet at that time, which results in the interrupt being set to 0. Thanks for looking at this problem, it has bothered a lot of people for a long time. I'm sorry I wasn't there for the discussion in November, but when it came up before, I suggested a different solution that apparently didn't get implemented. Note that this patch is the easy way out to fix a large part of the problems for now. A more proper solution for the long term would be to transition drivers to an API that always resolves resources of any kind (not only interrupts) at probe time. For some background and discussion on possible solutions, see: https://lkml.org/lkml/2013/11/22/520 I hope I read this thread correctly, sorry if I missed an important part. My idea was to add the code not in platform_get_irq() but add the resource in platform_drv_probe(), and just bail out with -EPROBE_DEFER there if necessary. We could then skip adding the resources at device creation time. Is this something you already plan to do later, or is there a reason it wouldn't work? In the meantime, I don't see anything with your patch, but it also wouldn't hurt to do it now if it solves all the problems. Arnd -- 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] omapdss: dispc: Preload more data in pipeline DMAs for OMAP4+ SoCs
On 2013-12-17 13:10, Archit Taneja wrote:
DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
region before the start of each frame. The preload ensures the pipeline
doesn't
underflow when the active region of the display starts.
DISPC_GFX/VIDp_PRELOAD registers allow us to program how many bytes of data
should be preloaded for each pipeline. Calculating a precise preload value
would be a complex function of the pixel clock of the connected display, the
vertical blanking duration and the interconnect traffic at that instance. If
the register is left untouched, a default value is preloaded.
We observe underflows for OMAP4+ SoCs for certain bandwidth intensive use
cases
with many other initiators active, and in situations where memory access isn't
very efficient(like accessing Tiler mapped buffers and EMIF configured in
non-interleaved more). The cause of the underflow is because the default
preload
value isn't sufficient for the DMA to reach a steady state. We configure the
PRELOAD register such that the pipelines preload data up to the high threshold
of the FIFO.
Preloading lot of data for older SoCs can have a negative impact. Due to
slower
interconnects, it's possible that the DISPC DMA cannot preload up to the high
threshold within the vertical blanking region of the panel. We leave the
PRELOAD
registers to their reset values since we haven't faced underflows with these
SoCs because of low value of PRELOAD.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6578540..ace179e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -90,6 +90,8 @@ struct dispc_features {
/* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
bool mstandby_workaround:1;
+
+ bool set_max_preload:1;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1200,6 +1202,15 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane
plane, u32 low, u32 high)
dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
FLD_VAL(high, hi_start, hi_end) |
FLD_VAL(low, lo_start, lo_end));
+
+ /*
+ * configure the preload to the pipeline's high threhold, if HT it's too
+ * large for the preload field, set the threshold to the maximum value
+ * that can be held by the preload register
+ */
+ if (dss_has_feature(FEAT_PRELOAD) dispc.feat-set_max_preload
+ plane != OMAP_DSS_WB)
+ dispc_write_reg(DISPC_OVL_PRELOAD(plane), min(high, 0xfff));
This causes compile warning:
drivers/video/omap2/dss/dispc.c: In function ‘dispc_ovl_set_fifo_threshold’:
drivers/video/omap2/dss/dispc.c:1213:152: warning: comparison of
distinct pointer types lacks a cast
I fixed it by changing 0xfff to 0xfffu
Queued for 3.14.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
On 2014-01-08 01:59, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131230 05:21]: The omapfb driver uses dma_alloc to reserve memory for the framebuffers. However, on some use cases, even when CMA is in use, it's quite probable that omapfb fails to allocate the fb, either due to not enough free dma memory, fragmented dma memory, or CMA failing to make enough contiguous space. This patch adds a kernel cmdline parameter 'omapfb_vram' which can be used to give the size of a memory area reserved exclusively for omapfb, and optionally a physical address where the memory area is reserved. The memory area is reserved with memblock, and assigned to omapfb with dma_declare_coherent_memory. The dma_alloc function will first try to allocate the fb from the coherent memory area, and if that fails, it'll use the normal method of allocation. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@abv.bg Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren t...@atomide.com Thanks. This introduces new kernel boot parameter, and I haven't really had time to test and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd rather leave this for 3.15 as adding new parameter that we need to support forever should be thought a bit more. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7 5/7] ARM: dts: add pbias dt node
On Tuesday 07 January 2014 05:53 PM, Balaji T K wrote:
On Tuesday 07 January 2014 04:27 PM, Mark Rutland wrote:
On Tue, Jan 07, 2014 at 10:18:15AM +, Balaji T K wrote:
On Monday 06 January 2014 11:49 PM, Mark Rutland wrote:
On Fri, Dec 20, 2013 at 05:35:53PM +, Balaji T K wrote:
Add pbias regulator node as a child of system control
module - syscon.
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 18 ++
arch/arm/boot/dts/omap2430.dtsi | 18 ++
arch/arm/boot/dts/omap3.dtsi| 18 ++
arch/arm/boot/dts/omap4.dtsi| 18 ++
arch/arm/boot/dts/omap5.dtsi| 18 ++
5 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d0df4c4..4e68df1 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -110,6 +110,23 @@
ti,hwmods = counter_32k;
};
+dra7_ctrl_general: tisyscon@4a002e00 {
+compatible = ti,control-syscon, syscon, simple-bus;
Please, don't use simple-bus like that. The components below this node
depend on it. It is _NOT_ a simple bus. Make the ti,control-syscon
driver probe it's children.
Hi Mark,
Actually ti,control-syscon driver does not exist, so I can remove it,
and simple-bus is needed for child creation.
This still shows up as a syscon node, with a reg property, and syscon is
not an extension of simple-bus.
There are properties in the parent node that children depend on, and
that makes me wary of describing it as a simple bus. I'd expect to be
able to move child nodes out of a simple-bus if ranges provided an
idmap, and I can't do that here.
Hi Mark,
Not sure if I am understanding here, can you please add more info.
Hi Mark,
From Documentation/devicetree/bindings.. , I could get below info about
simple-bus
- simple-bus compatible value (to ensure creation of the children)
compatible = simple-bus;
Thanks,
Mark.
+reg = 0x4a002e00 0x7c;
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+pbias_regulator: pbias_regulator {
+compatible = ti,pbias-omap;
+reg = 0 0x4;
+pbias_mmc_reg: pbias_mmc_omap5 {
+regulator-name = pbias_mmc_omap5;
+regulator-min-microvolt = 180;
+regulator-max-microvolt = 300;
+};
+};
+};
+
Thanks,
Mark.
--
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] driver-core: platform: Resolve DT interrupt references late
On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote: When devices are probed from the device tree, any interrupts that they reference are resolved at device creation time. This causes problems if the interrupt provider hasn't been registered yet at that time, which results in the interrupt being set to 0. Thanks for looking at this problem, it has bothered a lot of people for a long time. I'm sorry I wasn't there for the discussion in November, but when it came up before, I suggested a different solution that apparently didn't get implemented. Note that this patch is the easy way out to fix a large part of the problems for now. A more proper solution for the long term would be to transition drivers to an API that always resolves resources of any kind (not only interrupts) at probe time. For some background and discussion on possible solutions, see: https://lkml.org/lkml/2013/11/22/520 I hope I read this thread correctly, sorry if I missed an important part. My idea was to add the code not in platform_get_irq() but add the resource in platform_drv_probe(), and just bail out with -EPROBE_DEFER there if necessary. One of the reasons we can't do that just yet is that we don't actually get back an accurate error code from the OF IRQ helpers. Therefore if we want to support deferred probing we either have to return -EPROBE_DEFER for all errors (which is a bad idea because some errors just can't be resolved by deferral) or we change the OF IRQ functions to propagate the error code properly so that we know exactly when -EPROBE_DEFER makes sense (i.e. the IRQ domain for an interrupt-parent hasn't been registered yet). Actually I posted a round of patches quite a while back that did exactly this for interrupts. The changes were somewhat involved because it means propagating an error code from fairly deep down in the OF code back to the various higher-level helpers. If you're interested, the last version of that is here: https://lkml.org/lkml/2013/9/18/216 Grant in particular seemed to be uncomfortable about how invasive the patch series is. Perhaps I should step back for a minute and provide some background on how the initial idea came about. This was first triggered by the IOMMU probe ordering issue that you may have heard about. One of the reasons to do this for interrupts was because they are an existing type of resource yet suffer from a very similar problem, so I wanted to solve the issue for interrupts and thereby get a better overview of what needed to be done for IOMMUs. The most logical place for this code to reside seemed to be in the probe path of platform devices (or I2C and other devices for that matter). The patch series introduced an of_platform_probe() function that's called from platform_drv_probe(). This would automatically give us deferred probe support provided that we could propagate the appropriate error code while at the same time giving us some flexibility to hook up other resource types (such as IOMMUs). One problem with the IOMMU patches is that they've received some strong pushback from both Greg and Grant, arguing that it doesn't belong in the core. If you want to read up on that, here's a link to the latest version: https://lkml.org/lkml/2013/12/12/74 Some things had been discussed in earlier iterations of that series, but this should give you the basic idea. It stands to reason that if they push back on the IOMMU variant of what is essentially the same thing, they will push back on the IRQ variant as well. One alternative I proposed was to, just as you suggested earlier, move the code into platform_drv_probe() or rather a function called from it. That proposal never got any replies, though. https://lkml.org/lkml/2013/12/14/39 We could then skip adding the resources at device creation time. Is this something you already plan to do later, or is there a reason it wouldn't work? The current thread here suggests that it would be preferable not to have any static allocations at all, but rather introduce a new API to resolve things at probe time if necessary. I think the idea was to have a set of functions like: int device_get_irq(struct device *dev, unsigned int num); struct resource *device_get_mem_region(struct device *dev, unsigned int num); Or even possible the more generic: struct resource *device_get_resource(struct device *dev, unsigned int type, unsigned int num); If every driver used these functions, all resources could trivially be resolved at probe time. That solution is also the most invasive one of course, because it requires all existing drivers to be converted. At least the API would be all new and therefore the conversion could happen piecemeal. One downside of
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote: On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote: I hope I read this thread correctly, sorry if I missed an important part. My idea was to add the code not in platform_get_irq() but add the resource in platform_drv_probe(), and just bail out with -EPROBE_DEFER there if necessary. One of the reasons we can't do that just yet is that we don't actually get back an accurate error code from the OF IRQ helpers. Therefore if we want to support deferred probing we either have to return -EPROBE_DEFER for all errors (which is a bad idea because some errors just can't be resolved by deferral) or we change the OF IRQ functions to propagate the error code properly so that we know exactly when -EPROBE_DEFER makes sense (i.e. the IRQ domain for an interrupt-parent hasn't been registered yet). I see. Actually I posted a round of patches quite a while back that did exactly this for interrupts. The changes were somewhat involved because it means propagating an error code from fairly deep down in the OF code back to the various higher-level helpers. If you're interested, the last version of that is here: https://lkml.org/lkml/2013/9/18/216 Grant in particular seemed to be uncomfortable about how invasive the patch series is. Interesting. It seems like a worthwhile thing to do, but I can understand Grant's reluctance. One problem with the IOMMU patches is that they've received some strong pushback from both Greg and Grant, arguing that it doesn't belong in the core. If you want to read up on that, here's a link to the latest version: https://lkml.org/lkml/2013/12/12/74 Some things had been discussed in earlier iterations of that series, but this should give you the basic idea. I'm skipping that discussion for now and stick with your summary It stands to reason that if they push back on the IOMMU variant of what is essentially the same thing, they will push back on the IRQ variant as well. One alternative I proposed was to, just as you suggested earlier, move the code into platform_drv_probe() or rather a function called from it. That proposal never got any replies, though. https://lkml.org/lkml/2013/12/14/39 I guess putting it into the platform_drv_probe function seems reasonable, I would be more scared of the implications of a notifier based method. We could then skip adding the resources at device creation time. Is this something you already plan to do later, or is there a reason it wouldn't work? The current thread here suggests that it would be preferable not to have any static allocations at all, but rather introduce a new API to resolve things at probe time if necessary. I think the idea was to have a set of functions like: int device_get_irq(struct device *dev, unsigned int num); struct resource *device_get_mem_region(struct device *dev, unsigned int num); Or even possible the more generic: struct resource *device_get_resource(struct device *dev, unsigned int type, unsigned int num); If every driver used these functions, all resources could trivially be resolved at probe time. That solution is also the most invasive one of course, because it requires all existing drivers to be converted. At least the API would be all new and therefore the conversion could happen piecemeal. Right, that does sound nice, and has the added benefit of saving some memory allocations. I'd prefer the less generic variant here, but I haven't given it much thought. One downside of that approach is that, while it maps well to platform devices or generic devices that have some sort of firmware interface such as OF or ACPI, I don't see how it can be made to work with an I2C client that's registered from board setup code for example. Well, I suppose that problem could be solved by throwing another lookup table at it, just like we do for clocks, regulators, PWMs and GPIOs. Wouldn't you still be able to attach resources in the traditional way for those, but use the same new interface to get at them? The good thing about it would be more consistency between the various types of resources. Eventually I could imagine that we could even get rid of struct resource (or at least only use it for a single type of resource). But as I said, it'll take quite a bit of work to convert everything to that. struct resource is a structure with a long and complex history. I'd certainly like to put some of it behind us and do something that fits better into the 'struct device' concept which it predates. I agree it would be a big effort though. In the meantime, I don't see anything with your patch, but it also wouldn't hurt to do it now if it solves all the
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote: On Wed, Jan 08, 2014 at 02:41:19PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014 13:51:17 Thierry Reding wrote: [...] Actually I posted a round of patches quite a while back that did exactly this for interrupts. The changes were somewhat involved because it means propagating an error code from fairly deep down in the OF code back to the various higher-level helpers. If you're interested, the last version of that is here: https://lkml.org/lkml/2013/9/18/216 Grant in particular seemed to be uncomfortable about how invasive the patch series is. Interesting. It seems like a worthwhile thing to do, but I can understand Grant's reluctance. To be fair, Grant didn't say outright no. Given how easily this could turn into a regression nightmare I do understand the reluctance as well. Merging things piece by piece would make it somewhat less risky but at the same time makes it hard to keep at it. It stands to reason that if they push back on the IOMMU variant of what is essentially the same thing, they will push back on the IRQ variant as well. One alternative I proposed was to, just as you suggested earlier, move the code into platform_drv_probe() or rather a function called from it. That proposal never got any replies, though. https://lkml.org/lkml/2013/12/14/39 I guess putting it into the platform_drv_probe function seems reasonable, I would be more scared of the implications of a notifier based method. I fully agree. Of course if we decide against moving things into the core and in favour of a more generic API that drivers should use, then this issue goes away silently at least for resources that the driver needs to use explicitly (memory-mapped regions, interrupts, ...). The issue remains for IOMMU which is meant to be used transparently through the DMA API. Perhaps a good compromise would be to have some sort of generic helper that can be called to initialize IOMMU support for a particular device and support probe deferral on error. Something like this perhaps: int iommu_attach(struct device *dev); int iommu_detach(struct device *dev); I still don't like very much how that needs to be done in each driver explicitly, but if we can't do it in the core, then the only other clean way to handle it would be to treat it like any other sort of resource and handle it explicitly. Perhaps handing out some sort of cookie would be preferable to just an error code? We could then skip adding the resources at device creation time. Is this something you already plan to do later, or is there a reason it wouldn't work? The current thread here suggests that it would be preferable not to have any static allocations at all, but rather introduce a new API to resolve things at probe time if necessary. I think the idea was to have a set of functions like: int device_get_irq(struct device *dev, unsigned int num); struct resource *device_get_mem_region(struct device *dev, unsigned int num); Or even possible the more generic: struct resource *device_get_resource(struct device *dev, unsigned int type, unsigned int num); If every driver used these functions, all resources could trivially be resolved at probe time. That solution is also the most invasive one of course, because it requires all existing drivers to be converted. At least the API would be all new and therefore the conversion could happen piecemeal. Right, that does sound nice, and has the added benefit of saving some memory allocations. I'd prefer the less generic variant here, but I haven't given it much thought. I do prefer the less generic ones as well. They seem to be more convenient to use. One downside of that approach is that, while it maps well to platform devices or generic devices that have some sort of firmware interface such as OF or ACPI, I don't see how it can be made to work with an I2C client that's registered from board setup code for example. Well, I suppose that problem could be solved by throwing another lookup table at it, just like we do for clocks, regulators, PWMs and GPIOs. Wouldn't you still be able to attach resources in the traditional way for those, but use the same new interface to get at them? I wouldn't know how. For instance platform devices store the IRQ number within a struct resource of type IORESOURCE_IRQ, whereas I2C clients store them in the struct i2c_client's .irq field. So without actually introspecting the struct device (possibly using the .bus field for example) and upcasting you won't know how to get at the resources. One possibility to remedy that would be to try and unify the resources within struct
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
* Thierry Reding thierry.red...@gmail.com [140108 04:55]: When devices are probed from the device tree, any interrupts that they reference are resolved at device creation time. This causes problems if the interrupt provider hasn't been registered yet at that time, which results in the interrupt being set to 0. This is especially bad for platform devices because they are created at a very early stage during boot when the majority of interrupt providers haven't had a chance to be probed yet. One of the platform where this causes major issues is OMAP. Note that this patch is the easy way out to fix a large part of the problems for now. A more proper solution for the long term would be to transition drivers to an API that always resolves resources of any kind (not only interrupts) at probe time. For some background and discussion on possible solutions, see: https://lkml.org/lkml/2013/11/22/520 Acked-by: Rob Herring robherri...@gmail.com Signed-off-by: Thierry Reding tred...@nvidia.com --- Note that this is somewhat urgent and should if at all possible go into v3.13 before the release. drivers/base/platform.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 3a94b799f166..c894d1af3a5e 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -13,6 +13,7 @@ #include linux/string.h #include linux/platform_device.h #include linux/of_device.h +#include linux/of_irq.h #include linux/module.h #include linux/init.h #include linux/dma-mapping.h @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num) return -ENXIO; return dev-archdata.irqs[num]; #else - struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num); + struct resource *r; + + if (IS_ENABLED(CONFIG_OF) dev-dev.of_node) + return irq_of_parse_and_map(dev-dev.of_node, num); + + r = platform_get_resource(dev, IORESOURCE_IRQ, num); return r ? r-start : -ENXIO; #endif Hmm actually testing this patch, it does not fix fix the $Subject bug :( irq: no irq domain found for /ocp/pinmux@48002030 ! [0.301361] [ cut here ] [0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184() [0.301422] Modules linked in: [0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-2-g4d998a6 #17 [0.301513] [c0015c04] (unwind_backtrace+0x0/0xf4) from [c00127b0] (show_stack+0x14/0x1c) [0.301544] [c00127b0] (show_stack+0x14/0x1c) from [c05685a4] (dump_stack+0x6c/0xa0) [0.301574] [c05685a4] (dump_stack+0x6c/0xa0) from [c00425b4] (warn_slowpath_common+0x64/0x84) [0.301605] [c00425b4] (warn_slowpath_common+0x64/0x84) from [c00425f0] (warn_slowpath_null+0x1c/0x24) [0.301635] [c00425f0] (warn_slowpath_null+0x1c/0x24) from [c0485210] (of_device_alloc+0x144/0x184) [0.301635] [c0485210] (of_device_alloc+0x144/0x184) from [c0485294] (of_platform_device_create_pdata+0x44/0x9c) [0.301666] [c0485294] (of_platform_device_create_pdata+0x44/0x9c) from [c04853bc] (of_platform_bus_create+0xd0/0x170) [0.301696] [c04853bc] (of_platform_bus_create+0xd0/0x170) from [c0485418] (of_platform_bus_create+0x12c/0x170) [0.301727] [c0485418] (of_platform_bus_create+0x12c/0x170) from [c04854bc] (of_platform_populate+0x60/0x98) [0.301757] [c04854bc] (of_platform_populate+0x60/0x98) from [c07ca53c] (pdata_quirks_init+0x28/0x78) [0.301788] [c07ca53c] (pdata_quirks_init+0x28/0x78) from [c07bab20] (customize_machine+0x20/0x48) [0.301818] [c07bab20] (customize_machine+0x20/0x48) from [c000882c] (do_one_initcall+0x2c/0x150) [0.301849] [c000882c] (do_one_initcall+0x2c/0x150) from [c07b75d8] (do_basic_setup+0x94/0xd4) [0.301879] [c07b75d8] (do_basic_setup+0x94/0xd4) from [c07b7694] (kernel_init_freeable+0x7c/0x120) [0.301910] [c07b7694] (kernel_init_freeable+0x7c/0x120) from [c05667ec] (kernel_init+0x8/0x120) [0.301940] [c05667ec] (kernel_init+0x8/0x120) from [c000e908] (ret_from_fork+0x14/0x2c) [0.302124] ---[ end trace 2b87f5de2f86f809 ]--- ... There's nothing wrong with the interrupt related code paths, we're just trying to call the functions at a wrong time when thing are not yet initialized. Below is a repost of what works for me without using notifiers. Anybody got any better ideas for a minimal fix? Regards, Tony 8 --- From: Tony Lindgren t...@atomide.com Date: Tue, 7 Jan 2014 17:07:18 -0800 Subject: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts Currently we get the following kind of errors if we try to use interrupt phandles to irqchips that have not yet initialized: irq: no irq domain found for /ocp/pinmux@48002030 ! [ cut here ] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wednesday 08 January 2014, Thierry Reding wrote: On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote: It stands to reason that if they push back on the IOMMU variant of what is essentially the same thing, they will push back on the IRQ variant as well. One alternative I proposed was to, just as you suggested earlier, move the code into platform_drv_probe() or rather a function called from it. That proposal never got any replies, though. https://lkml.org/lkml/2013/12/14/39 I guess putting it into the platform_drv_probe function seems reasonable, I would be more scared of the implications of a notifier based method. I fully agree. Of course if we decide against moving things into the core and in favour of a more generic API that drivers should use, then this issue goes away silently at least for resources that the driver needs to use explicitly (memory-mapped regions, interrupts, ...). The issue remains for IOMMU which is meant to be used transparently through the DMA API. Perhaps a good compromise would be to have some sort of generic helper that can be called to initialize IOMMU support for a particular device and support probe deferral on error. Something like this perhaps: int iommu_attach(struct device *dev); int iommu_detach(struct device *dev); I still don't like very much how that needs to be done in each driver explicitly, but if we can't do it in the core, then the only other clean way to handle it would be to treat it like any other sort of resource and handle it explicitly. Perhaps handing out some sort of cookie would be preferable to just an error code? The more I think about the iommu case, the more I am convinced that it does belong into the core, in whatever form we can find. As far as I can tell from the little reliable information I have on the topic, I would assume that we can keep it in the DT probing code, as there won't be a need for multiple arbitrary IOMMUs with ACPI or with board files. One downside of that approach is that, while it maps well to platform devices or generic devices that have some sort of firmware interface such as OF or ACPI, I don't see how it can be made to work with an I2C client that's registered from board setup code for example. Well, I suppose that problem could be solved by throwing another lookup table at it, just like we do for clocks, regulators, PWMs and GPIOs. Wouldn't you still be able to attach resources in the traditional way for those, but use the same new interface to get at them? I wouldn't know how. For instance platform devices store the IRQ number within a struct resource of type IORESOURCE_IRQ, whereas I2C clients store them in the struct i2c_client's .irq field. Good point, I forgot about the special case for i2c_client-irq. I looked now and noticed that very few i2c devices actually use this field, but larger number uses platform_data, which has a similar problem. So without actually introspecting the struct device (possibly using the .bus field for example) and upcasting you won't know how to get at the resources. One possibility to remedy that would be to try and unify the resources within struct device. But that doesn't feel right. One other thing I had considered at one point was to extend the bus_type structure and give it a way to obtain resources in a bus-specific way, but that feel even more wrong. Perhaps I'm missing something obvious, though, and this is actually much more trivial to solve. No trivial solution that I can see. I think we can deal with the case where platform code uses platform_device-resources, and everything else comes down to having multiple code branches in the driver, as we already have to deal with platform_data and DT properties describing stuff that doesn't fit in the resources. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pandaboard] audio initialization fails due to TWL6040
* Peter Ujfalusi peter.ujfal...@ti.com [140108 05:25]: On 01/08/2014 12:53 AM, Tony Lindgren wrote: Well we cannot sanely deprecate the ti,hwmods and move on to matching hwmod data with DT data based on the compatible flag. So it's a bit of a blocker for v3.15 or so time frame. Due to a 'hw feature' around the sidetone this is not as straight forward as it sounds... OK. The driver(s) should still be able to coordinate things to sort it out hopefully? After a quick look at the code: - sidetone _is_ broken when we boot with DT for sure already. - sidetone works only if we boot in legacy mode. While it is true that ST block has it's own address space and even dedicated irq line, but.. ST can be enabled from the McBSP address space (via SSELCR_REG). When ST is enabled we need to disable the corresponding McBSP's autoidle. The reason for this is that the ST block is clocked from the McBSP IP's interface clock. If the interface clock of the McBSP is idling there will be glitches in the sidetone generation due to not having continuously running clock for it's internals. It seems that this you may be able to sort out just by exporting a function from the ST code for the McBSP to call, and for the autoidle, can't you.. For legacy boot we had this handled by a custom callback to disable autoidle for the McBSP when the ST starts and enable it back when ST is stopped: arch/arm/mach-omap2/mcbsp.c:omap3_enable_st_clock() is the callback we call. ..just use runtime PM calls from the ST module? Normal audio will work via McBSP if we get rid of hwmod, the driver can load and operate that way. As for the sidetone functionality: it is broken when we boot with DT and the removal of hwmod will have no effect on this. OK The Sidetone address space also have sysconfig register with AUTOIDLE bit, but it has no effect on the McBSP_ICLK autoidle itself. Yes that's because they're separate hardware modules like we have them in the hwmod code :) In theory we can handle the sidetone as we do right now, but we need one thing: an API so drivers can disable/enable autoidle of an already enabled clock. CCing Tero for this, he might have pointers or idea on how we can do this. It seems that runtime PM should be able to do that. But maybe I'm missing something 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] ARM: dts: OMAP2: fix interrupt number for rng
Tony, On 01/07/2014 06:28 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [131223 15:01]: The irq data for rng module defined in hwmod data previously missed the OMAP_INTC_START relative offset, so the interrupt number is probably misconfigured during the DT node addition adjusting for this OMAP_INTC_START. Interrupt #36 is associated with a watchdog timer, so fix the rng module's interrupt to the appropriate interrupt #52. Hmm indeed as the .dtsi files were generated from the hwmod data. Are the other interrupts fixed earlier OK? GPMC DT nodes are already configured properly, the ISP MMU one needs fixing. I left it out to be fixed as part of Florian's patch that corrects the ISP MMU DT node. There is no IVA MMU DT node yet, and will add the correct number when we add the DT node. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
* Heikki Krogerus heikki.kroge...@linux.intel.com [131209 07:10]:
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
This seems safe to queue via the USB list:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..972430b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup_table twl4030_usb_lookup = {
+ .dev_id = musb-hdrc.0,
+ .table = PHY_LOOKUP(phy-twl4030_usb.0, NULL),
};
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
};
static int omap3_batt_table[] = {
@@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_add_lookup_table(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
1.8.5.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] ARM: dts: OMAP2: fix interrupt number for rng
* Anna, Suman s-a...@ti.com [140108 09:33]: Tony, On 01/07/2014 06:28 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [131223 15:01]: The irq data for rng module defined in hwmod data previously missed the OMAP_INTC_START relative offset, so the interrupt number is probably misconfigured during the DT node addition adjusting for this OMAP_INTC_START. Interrupt #36 is associated with a watchdog timer, so fix the rng module's interrupt to the appropriate interrupt #52. Hmm indeed as the .dtsi files were generated from the hwmod data. Are the other interrupts fixed earlier OK? GPMC DT nodes are already configured properly, the ISP MMU one needs fixing. I left it out to be fixed as part of Florian's patch that corrects the ISP MMU DT node. There is no IVA MMU DT node yet, and will add the correct number when we add the DT node. OK thanks, adding this into omap-for-v3.14/dt as it won't be needed earlier. 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 RESEND] arm: omap2plus_defconfig: enable AM33xx SOC EVM audio
* Jyri Sarha jsa...@ti.com [131105 00:43]: Modifying the omap2plus_defconfig to enable the audio support for AM335x EVM and other AM33xx based devices with TLV320AIC3X connected to McASP. Signed-off-by: Jyri Sarha jsa...@ti.com Thanks applying into omap-for-v3.14/fixes-not-urgent. Tony --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 254cf05..4443b92 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -210,6 +210,8 @@ CONFIG_SND_DEBUG=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_SOC=m CONFIG_SND_OMAP_SOC=m +CONFIG_SND_AM33XX_SOC_EVM=m +CONFIG_SND_DAVINCI_SOC=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m -- -- 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 0/3] omap2: Assorted GPMC cleanups
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [131027 17:52]: (I'm CCing the MTD list, because GPMC is the memory controller used for NOR, NAND and OneNAND devices). Hi all, Just a small patchset containing two small cleanups and a minor fix for the GPMC memory controller. The first two are cleanups and can be considered as preparation work for the fix. The fix is patch 3/3: Move legacy GPMC width setting. It makes explicit use of the DT property gpmc,device-width and removes the subsequent (and redundant) setting of the GPMC width, based in the NAND bus widht. Thanks and sorry for the delay. Applying these all into branch omap-for-v3.14/fixes-not-urgent. Regards, Tony Tested in AM335x (using DT) so I'd appreciate if someone can test using a board-file, on a device with NAND flash. Jon: If you happen to read this, I'd like if you could take a look at patch 1/3, since you were the last to touch that part of the code. Thanks! Ezequiel Garcia (3): omap2: gpmc: Move initialization outside the gpmc_t condition omap2: gpmc: Introduce gpmc_set_legacy() omap2: gpmc: Move legacy GPMC width setting arch/arm/mach-omap2/gpmc-nand.c | 50 +++-- 1 file changed, 28 insertions(+), 22 deletions(-) -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/4] DRIVERS: IRQCHIP: Add support for crossbar IP
* Sricharan R r.sricha...@ti.com [140108 05:20]: On Wednesday 08 January 2014 05:25 AM, Tony Lindgren wrote: Oops, I noticed some errors on these: WARNING: drivers/built-in.o(.text+0xcd0): Section mismatch in reference from the function irqcrossbar_init() to the function .init.text:crossbar_of_init() The function irqcrossbar_init() references the function __init crossbar_of_init(). This is often because irqcrossbar_init lacks a __init annotation or the annotation of crossbar_of_init is wrong. WARNING: drivers/built-in.o(.text+0xcdc): Section mismatch in reference from the function irqcrossbar_init() to the (unknown reference) .init.rodata:(unknown) The function irqcrossbar_init() references the (unknown reference) __initconst (unknown). This is often because irqcrossbar_init lacks a __initconst annotation or the annotation of (unknown) is wrong. So I've dropped them for now. Care to fix up those errors and base your patches against let's say v3.13-rc5? Very Sorry for the section mismatch warning. I have fixed it and pushed a new branch below based on v3.13-rc5 git://github.com/Sricharanti/sricharan.git branch: crossbar_3.13_rc5 Thanks, applying again. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/2] ARM: OMAP2+/dts: standardize SoC naming
* Nishanth Menon n...@ti.com [140106 16:49]: Hi Benoit, Tony, On Wed, Dec 4, 2013 at 6:49 PM, Nishanth Menon n...@ti.com wrote: Originally attempted partially in [1], the missing binding were reported as part of Rob's report in [2]. Would you like me to send this series again since I do not see this in: https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.14/dts No need to and sorry for the delays. I'm applying these into omap-for-v3.14/fixes-not-urgent as they should not conflict with other DT related patches. Regards, Tony patchwork links: https://patchwork.kernel.org/patch/3286051/ https://patchwork.kernel.org/patch/3286061/ So, here is take two of the series, lacking an standard causes issues that was fixed such as [3]. Ideally, we should never again introduce a board file without a exact compatible SoC match. I have stayed a bit away from updating board and SoC dts files yet to look at the direction we'd like to go here. If we feel things are good, I would gladly try to clean our mess up. Nishanth Menon (2): Documentation: dt: OMAP: explicitly state SoC compatible strings ARM: OMAP2+: board-generic: update SoC compatibility strings .../devicetree/bindings/arm/omap/omap.txt | 53 arch/arm/mach-omap2/board-generic.c|7 +++ 2 files changed, 60 insertions(+) [1] https://patchwork.kernel.org/patch/2998201/ [2] http://marc.info/?l=linux-arm-kernelm=138378029113665w=2 [3] https://patchwork.kernel.org/patch/3279281/ -- 1.7.9.5 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] arm: omap2plus_defconfig: enable more drivers
* Felipe Balbi ba...@ti.com [131025 08:51]: Hi, On Fri, Oct 25, 2013 at 07:44:26AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131025 07:20]: enable a few more drivers as modules on omap2plus_defconfig, this helps us getting more platforms working out of the box by just building omap2plus_defconfig. Signed-off-by: Felipe Balbi ba...@ti.com --- Hi Tony, would you consider enabling these drivers ? I didn't, yet, make sure that these drivers won't cause PM regressions. Wanted to make sure you'd be ok enabling so many of them. Sure, we should have all common drivers enabled, preferrably as loadable modules where possible. Probably at least MUSB gadgets need to be loadable modulees as at least I have my test setup in a rack with USB cables connected all the time. That way the PM tests can be done without the USB modules loaded. Or maybe we can just PM runtime suspend the USB drivers for PM tests? I'd rather just unload the drivers if they cause issues. The thing is that with a patch like $subject, we get more working out-of-the-box and since most everything is really already in mainline (at least after v3.13 merge window) except for DTS (which should go up on v3.14, all the pending stuff), then we should be in really good shape after enabling all the necessary modules. Just to update the status on this, I've been hoping to get the omap3 PM regression issues out of the way before enabling drivers so we can test for the regressions easily. I've applied patches to enable some of these in omap-for-v3.14/fixes-not-urgent, so this patch will eventually need to be slightly updated. 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] driver-core: platform: Resolve DT interrupt references late
On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote: * Thierry Reding thierry.red...@gmail.com [140108 04:55]: When devices are probed from the device tree, any interrupts that they reference are resolved at device creation time. This causes problems if the interrupt provider hasn't been registered yet at that time, which results in the interrupt being set to 0. This is especially bad for platform devices because they are created at a very early stage during boot when the majority of interrupt providers haven't had a chance to be probed yet. One of the platform where this causes major issues is OMAP. Note that this patch is the easy way out to fix a large part of the problems for now. A more proper solution for the long term would be to transition drivers to an API that always resolves resources of any kind (not only interrupts) at probe time. For some background and discussion on possible solutions, see: https://lkml.org/lkml/2013/11/22/520 Acked-by: Rob Herring robherri...@gmail.com Signed-off-by: Thierry Reding tred...@nvidia.com --- Note that this is somewhat urgent and should if at all possible go into v3.13 before the release. drivers/base/platform.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 3a94b799f166..c894d1af3a5e 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -13,6 +13,7 @@ #include linux/string.h #include linux/platform_device.h #include linux/of_device.h +#include linux/of_irq.h #include linux/module.h #include linux/init.h #include linux/dma-mapping.h @@ -87,7 +88,12 @@ int platform_get_irq(struct platform_device *dev, unsigned int num) return -ENXIO; return dev-archdata.irqs[num]; #else - struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num); + struct resource *r; + + if (IS_ENABLED(CONFIG_OF) dev-dev.of_node) + return irq_of_parse_and_map(dev-dev.of_node, num); + + r = platform_get_resource(dev, IORESOURCE_IRQ, num); return r ? r-start : -ENXIO; #endif Hmm actually testing this patch, it does not fix fix the $Subject bug :( irq: no irq domain found for /ocp/pinmux@48002030 ! [0.301361] [ cut here ] [0.301391] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184() [0.301422] Modules linked in: [0.301452] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc7-2-g4d998a6 #17 [0.301513] [c0015c04] (unwind_backtrace+0x0/0xf4) from [c00127b0] (show_stack+0x14/0x1c) [0.301544] [c00127b0] (show_stack+0x14/0x1c) from [c05685a4] (dump_stack+0x6c/0xa0) [0.301574] [c05685a4] (dump_stack+0x6c/0xa0) from [c00425b4] (warn_slowpath_common+0x64/0x84) [0.301605] [c00425b4] (warn_slowpath_common+0x64/0x84) from [c00425f0] (warn_slowpath_null+0x1c/0x24) [0.301635] [c00425f0] (warn_slowpath_null+0x1c/0x24) from [c0485210] (of_device_alloc+0x144/0x184) [0.301635] [c0485210] (of_device_alloc+0x144/0x184) from [c0485294] (of_platform_device_create_pdata+0x44/0x9c) [0.301666] [c0485294] (of_platform_device_create_pdata+0x44/0x9c) from [c04853bc] (of_platform_bus_create+0xd0/0x170) [0.301696] [c04853bc] (of_platform_bus_create+0xd0/0x170) from [c0485418] (of_platform_bus_create+0x12c/0x170) [0.301727] [c0485418] (of_platform_bus_create+0x12c/0x170) from [c04854bc] (of_platform_populate+0x60/0x98) [0.301757] [c04854bc] (of_platform_populate+0x60/0x98) from [c07ca53c] (pdata_quirks_init+0x28/0x78) [0.301788] [c07ca53c] (pdata_quirks_init+0x28/0x78) from [c07bab20] (customize_machine+0x20/0x48) [0.301818] [c07bab20] (customize_machine+0x20/0x48) from [c000882c] (do_one_initcall+0x2c/0x150) [0.301849] [c000882c] (do_one_initcall+0x2c/0x150) from [c07b75d8] (do_basic_setup+0x94/0xd4) [0.301879] [c07b75d8] (do_basic_setup+0x94/0xd4) from [c07b7694] (kernel_init_freeable+0x7c/0x120) [0.301910] [c07b7694] (kernel_init_freeable+0x7c/0x120) from [c05667ec] (kernel_init+0x8/0x120) [0.301940] [c05667ec] (kernel_init+0x8/0x120) from [c000e908] (ret_from_fork+0x14/0x2c) [0.302124] ---[ end trace 2b87f5de2f86f809 ]--- ... There's nothing wrong with the interrupt related code paths, we're just trying to call the functions at a wrong time when thing are not yet initialized. The patch won't get rid of that warning, but it should at least restore things to a working state at runtime. At least for well-behaved drivers that use platform_get_irq() rather than those that try to access the resources directly. Below is a repost of what works for me without using notifiers. Anybody got any better ideas for a minimal fix? That patch is somewhat big for something that should be a minimal fix. Being the size that it is it might have
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014, Thierry Reding wrote: On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote: On Wednesday 08 January 2014 15:55:27 Thierry Reding wrote: It stands to reason that if they push back on the IOMMU variant of what is essentially the same thing, they will push back on the IRQ variant as well. One alternative I proposed was to, just as you suggested earlier, move the code into platform_drv_probe() or rather a function called from it. That proposal never got any replies, though. https://lkml.org/lkml/2013/12/14/39 I guess putting it into the platform_drv_probe function seems reasonable, I would be more scared of the implications of a notifier based method. I fully agree. Of course if we decide against moving things into the core and in favour of a more generic API that drivers should use, then this issue goes away silently at least for resources that the driver needs to use explicitly (memory-mapped regions, interrupts, ...). The issue remains for IOMMU which is meant to be used transparently through the DMA API. Perhaps a good compromise would be to have some sort of generic helper that can be called to initialize IOMMU support for a particular device and support probe deferral on error. Something like this perhaps: int iommu_attach(struct device *dev); int iommu_detach(struct device *dev); I still don't like very much how that needs to be done in each driver explicitly, but if we can't do it in the core, then the only other clean way to handle it would be to treat it like any other sort of resource and handle it explicitly. Perhaps handing out some sort of cookie would be preferable to just an error code? The more I think about the iommu case, the more I am convinced that it does belong into the core, in whatever form we can find. As far as I can tell from the little reliable information I have on the topic, I would assume that we can keep it in the DT probing code, as there won't be a need for multiple arbitrary IOMMUs with ACPI or with board files. I think part of the problem is that we don't have any DT probing code yet. of_platform_probe() would have been that code. Perhaps if you weigh in Grant and Greg will reconsider. One downside of that approach is that, while it maps well to platform devices or generic devices that have some sort of firmware interface such as OF or ACPI, I don't see how it can be made to work with an I2C client that's registered from board setup code for example. Well, I suppose that problem could be solved by throwing another lookup table at it, just like we do for clocks, regulators, PWMs and GPIOs. Wouldn't you still be able to attach resources in the traditional way for those, but use the same new interface to get at them? I wouldn't know how. For instance platform devices store the IRQ number within a struct resource of type IORESOURCE_IRQ, whereas I2C clients store them in the struct i2c_client's .irq field. Good point, I forgot about the special case for i2c_client-irq. I looked now and noticed that very few i2c devices actually use this field, but larger number uses platform_data, which has a similar problem. Yeah. It's kind of messy. The more I think about it, the more I begin to like the lookup table option. One big advantage of that is that we could actually unify much of the lookup code, much like we do for other types of resources. It's a pattern that has worked fairly well in a number of cases, so it seems natural to use it for interrupts as well. An even more extreme option would be to go all the way and introduce struct irq, along the same lines of the new struct gpiod. That would allow nice things such as storing trigger types and such within the IRQ handle and propagate them automatically. So without actually introspecting the struct device (possibly using the .bus field for example) and upcasting you won't know how to get at the resources. One possibility to remedy that would be to try and unify the resources within struct device. But that doesn't feel right. One other thing I had considered at one point was to extend the bus_type structure and give it a way to obtain resources in a bus-specific way, but that feel even more wrong. Perhaps I'm missing something obvious, though, and this is actually much more trivial to solve. No trivial solution that I can see. I think we can deal with the case where platform code uses platform_device-resources, and everything else comes down to having multiple code branches in the driver, as we already have to deal with platform_data and DT properties describing stuff that doesn't fit in the resources. That would be another argument in favour of the lookup table. It would provide a unified mechanism to define static interrupts if no
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014, Thierry Reding wrote:
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
The more I think about the iommu case, the more I am convinced that it
does belong into the core, in whatever form we can find. As far as I
can tell from the little reliable information I have on the topic, I
would assume that we can keep it in the DT probing code, as there won't
be a need for multiple arbitrary IOMMUs with ACPI or with board files.
I think part of the problem is that we don't have any DT probing code
yet. of_platform_probe() would have been that code. Perhaps if you weigh
in Grant and Greg will reconsider.
For all I know, we don't even have a binding proposal, but I may
have missed that.
Good point, I forgot about the special case for i2c_client-irq.
I looked now and noticed that very few i2c devices actually use this
field, but larger number uses platform_data, which has a similar
problem.
Yeah. It's kind of messy. The more I think about it, the more I begin to
like the lookup table option. One big advantage of that is that we could
actually unify much of the lookup code, much like we do for other types
of resources. It's a pattern that has worked fairly well in a number of
cases, so it seems natural to use it for interrupts as well.
An even more extreme option would be to go all the way and introduce
struct irq, along the same lines of the new struct gpiod. That would
allow nice things such as storing trigger types and such within the IRQ
handle and propagate them automatically.
We already have struct irq_desc, and I believe everybody who works
with interrupts supports migrating from irq number interfaces to
irq descriptors as soon as we can find someone willing to do that
work.
No trivial solution that I can see. I think we can deal with the case
where platform code uses platform_device-resources, and everything else
comes down to having multiple code branches in the driver, as we already
have to deal with platform_data and DT properties describing stuff that
doesn't fit in the resources.
That would be another argument in favour of the lookup table. It would
provide a unified mechanism to define static interrupts if no firmware
interface is available *independent* of the device type. You could have
something like:
static const struct irq_lookup board_irq_lookup[] = {
IRQ_LOOKUP(gpio, 0, 0-0040, NULL), /* I2C client via GPIO
expander */
IRQ_LOOKUP(intc, 0, ehci.1, NULL), /* platform device via
INTC */
};
Along with:
struct irq *irq_get(struct device *dev, const char *con_id);
To look it up via DT, ACPI, lookup table. That obviously means a more or
less complete change in how interrupts are handled in the kernel, and it
may not be worth it in the end.
It would certainly need a long migration period, and a plan for how to
get there without breaking things in the meantime. Rather than a lookup
table like the kind we have for clocks, I'd prefer a general way to
attach named properties to devices. My feeling is that building upon
devres would be a good plan, since it already provides a way to attach
arbitrary data to a device.
Arnd
--
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] driver-core: platform: Resolve DT interrupt references late
On Wed, Jan 08, 2014 at 09:09:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
On Wednesday 08 January 2014, Thierry Reding wrote:
On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
The more I think about the iommu case, the more I am convinced that it
does belong into the core, in whatever form we can find. As far as I
can tell from the little reliable information I have on the topic, I
would assume that we can keep it in the DT probing code, as there won't
be a need for multiple arbitrary IOMMUs with ACPI or with board files.
I think part of the problem is that we don't have any DT probing code
yet. of_platform_probe() would have been that code. Perhaps if you weigh
in Grant and Greg will reconsider.
For all I know, we don't even have a binding proposal, but I may
have missed that.
Yeah, last time I checked there was no concensus on that. I'll try to
dig up the thread and get it going again, adding you on Cc if you don't
mind (and in case you weren't Cc'ed in the first place anyway).
Good point, I forgot about the special case for i2c_client-irq.
I looked now and noticed that very few i2c devices actually use this
field, but larger number uses platform_data, which has a similar
problem.
Yeah. It's kind of messy. The more I think about it, the more I begin to
like the lookup table option. One big advantage of that is that we could
actually unify much of the lookup code, much like we do for other types
of resources. It's a pattern that has worked fairly well in a number of
cases, so it seems natural to use it for interrupts as well.
An even more extreme option would be to go all the way and introduce
struct irq, along the same lines of the new struct gpiod. That would
allow nice things such as storing trigger types and such within the IRQ
handle and propagate them automatically.
We already have struct irq_desc, and I believe everybody who works
with interrupts supports migrating from irq number interfaces to
irq descriptors as soon as we can find someone willing to do that
work.
I didn't know that. I had always assumed irq_desc was only for internal
use by the IRQ code. Perhaps I'll look into that at some point.
No trivial solution that I can see. I think we can deal with the case
where platform code uses platform_device-resources, and everything else
comes down to having multiple code branches in the driver, as we already
have to deal with platform_data and DT properties describing stuff that
doesn't fit in the resources.
That would be another argument in favour of the lookup table. It would
provide a unified mechanism to define static interrupts if no firmware
interface is available *independent* of the device type. You could have
something like:
static const struct irq_lookup board_irq_lookup[] = {
IRQ_LOOKUP(gpio, 0, 0-0040, NULL), /* I2C client via GPIO
expander */
IRQ_LOOKUP(intc, 0, ehci.1, NULL), /* platform device via
INTC */
};
Along with:
struct irq *irq_get(struct device *dev, const char *con_id);
To look it up via DT, ACPI, lookup table. That obviously means a more or
less complete change in how interrupts are handled in the kernel, and it
may not be worth it in the end.
It would certainly need a long migration period, and a plan for how to
get there without breaking things in the meantime. Rather than a lookup
table like the kind we have for clocks, I'd prefer a general way to
attach named properties to devices. My feeling is that building upon
devres would be a good plan, since it already provides a way to attach
arbitrary data to a device.
The problem with devres, or any other solution for that matter, is that
for the cases where we'd need something like this (that is, statically
allocated devices in board setup code) we don't have a fully initialized
struct device. We need at least device_initialize() to have been called
before devres can be used. Therefore we still need some sort of lookup
table that can be used to seed devres objects. Also devres will go away
completely when a driver is unloaded, so it'll have to be repopulated
everytime.
I don't think that would buy us much over a simple table lookup.
Thierry
pgp1duHtWnTs9.pgp
Description: PGP signature
Re: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Any pointers? Still present in 3.13-rc7. On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote: +Kishon On 12/03/2013 11:33 PM, Belisko Marek wrote: Hi, current 3.13-rcX break usb support on gta04 board (similar to beagleboard) when booting via board file. In console we can see messages: [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5232.936096] omap_musb_mailbox: musb core is not yet ready [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock Any pointer what could cause that? (in 3.12 usb works fine) BR, marek BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] driver-core: platform: Resolve DT interrupt references late
On Wednesday 08 January 2014 21:24:08 Thierry Reding wrote: The problem with devres, or any other solution for that matter, is that for the cases where we'd need something like this (that is, statically allocated devices in board setup code) we don't have a fully initialized struct device. We need at least device_initialize() to have been called before devres can be used. Therefore we still need some sort of lookup table that can be used to seed devres objects. Also devres will go away completely when a driver is unloaded, so it'll have to be repopulated everytime. I don't think that would buy us much over a simple table lookup. I would think we can come up with a way to add data to a device that ends up in devres by the time the device gets registered. The question is more whether you want a global table (or a set of global tables for that matter) or rather have all the data local to the devices you register. I generally prefer the latter. There is an interesting question about what subsystems you'd want to include in this mechanism. We have a growing number of subsystems that want data represented in DT (clock, regulator, dmaengine, reset, led, pwm, irq, iommu, ...), most of which don't have a 'struct resource' equivalent. We could either try to create something generic enough to easily cover all of them, or we declare that if you actually want to use all of them you should really use DT, and we make it hard to add another subsystem specific lookup mechanism. Arnd -- 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] driver-core: platform: Resolve DT interrupt references late
* Thierry Reding thierry.red...@gmail.com [140108 11:32]: On Wed, Jan 08, 2014 at 08:40:41AM -0800, Tony Lindgren wrote: There's nothing wrong with the interrupt related code paths, we're just trying to call the functions at a wrong time when thing are not yet initialized. The patch won't get rid of that warning, but it should at least restore things to a working state at runtime. At least for well-behaved drivers that use platform_get_irq() rather than those that try to access the resources directly. Well the problem I'm seeing is these nasty warnings. BTW, I think the issue you're talking about regarding platform_get_irq() got fixed by 4a43d686fe33 (of/irq: Pass trigger type in IRQ resource flags). Below is a repost of what works for me without using notifiers. Anybody got any better ideas for a minimal fix? That patch is somewhat big for something that should be a minimal fix. Being the size that it is it might have undesired side-effects that may not get noticed until it's way too late, so I'm hesitant to have something like this merged at this point in the release cycle. Yes I agree it's rather invasive, but we also do have things pretty badly broken in the kernel for device tree based booting. And it seems that nobody has a smaller patch that would fix it. 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 0/3] omap2: Assorted GPMC cleanups
On Wed, Jan 08, 2014 at 11:18:37AM -0800, Tony Lindgren wrote: * Ezequiel Garcia ezequiel.gar...@free-electrons.com [131027 17:52]: (I'm CCing the MTD list, because GPMC is the memory controller used for NOR, NAND and OneNAND devices). Hi all, Just a small patchset containing two small cleanups and a minor fix for the GPMC memory controller. The first two are cleanups and can be considered as preparation work for the fix. The fix is patch 3/3: Move legacy GPMC width setting. It makes explicit use of the DT property gpmc,device-width and removes the subsequent (and redundant) setting of the GPMC width, based in the NAND bus widht. Thanks and sorry for the delay. Applying these all into branch omap-for-v3.14/fixes-not-urgent. No problem. I'll give this a test/review next week. Do we still need the board-file (legacy) workaround in this patchset? I was actually waiting for you to clean-up completely that, before re-sending the series, without the board-file workaround. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] omap2: Assorted GPMC cleanups
* Ezequiel Garcia ezequiel.gar...@free-electrons.com [140108 15:39]: On Wed, Jan 08, 2014 at 11:18:37AM -0800, Tony Lindgren wrote: * Ezequiel Garcia ezequiel.gar...@free-electrons.com [131027 17:52]: (I'm CCing the MTD list, because GPMC is the memory controller used for NOR, NAND and OneNAND devices). Hi all, Just a small patchset containing two small cleanups and a minor fix for the GPMC memory controller. The first two are cleanups and can be considered as preparation work for the fix. The fix is patch 3/3: Move legacy GPMC width setting. It makes explicit use of the DT property gpmc,device-width and removes the subsequent (and redundant) setting of the GPMC width, based in the NAND bus widht. Thanks and sorry for the delay. Applying these all into branch omap-for-v3.14/fixes-not-urgent. No problem. I'll give this a test/review next week. Do we still need the board-file (legacy) workaround in this patchset? I was actually waiting for you to clean-up completely that, before re-sending the series, without the board-file workaround. Yes we still need it for a little bit longer. 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
[GIT PULL 1/4] non-urgent omap fixes for v3.14 merge window
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/fixes-not-urgent-signed for you to fetch changes up to bbc28cdbd003be5ceeaf644be3533e898c25da2b: ARM: OMAP2+: gpmc: Move legacy GPMC width setting (2014-01-08 09:49:47 -0800) Some non-urgent fixes to enable am335x features, update documentation, and to remove unnecessary double initialization for the GPMC code. Ezequiel Garcia (4): ARM: OMAP2+: Select USB PHY for AM335x SoC ARM: OMAP2+: gpmc: Move initialization outside the gpmc_t condition ARM: OMAP2+: gpmc: Introduce gpmc_set_legacy() ARM: OMAP2+: gpmc: Move legacy GPMC width setting Jyri Sarha (1): ARM: OMAP2+: enable AM33xx SOC EVM audio Nishanth Menon (2): Documentation: dt: OMAP: explicitly state SoC compatible strings ARM: OMAP2+: board-generic: update SoC compatibility strings .../devicetree/bindings/arm/omap/omap.txt | 53 ++ arch/arm/configs/omap2plus_defconfig | 3 ++ arch/arm/mach-omap2/board-generic.c| 7 +++ arch/arm/mach-omap2/gpmc-nand.c| 50 +++- 4 files changed, 91 insertions(+), 22 deletions(-) -- 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
[GIT PULL 2/4] omap device tree fixes for v3.14 merge window
The following changes since commit adfe9361b236154215d4b0fc8b6d79995394b15c: ARM: dts: Add basic devices on am3517-evm (2013-12-08 14:15:46 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/dt-signed for you to fetch changes up to e37e1cb0ee231ffdc9b5ef1da63a0c7e1077c603: ARM: dts: OMAP2: fix interrupt number for rng (2014-01-08 10:24:44 -0800) Split omap3 core padconf area into two as some of the registers in the padconf area are not accessible and used for other devices. Also fix the interrupt number for omap2 RNG, and add basic support for sbc-3xxx with cm-t3730. Note that the minor merge conflicts for omap_hwmod_2xxx_ipblock_data.c can be solved by just dropping the legacy hwmod data for interrupts for v3.14. Laurent Pinchart (1): ARM: dts: Split omap3 pinmux core device Suman Anna (1): ARM: dts: OMAP2: fix interrupt number for rng Tony Lindgren (2): ARM: dts: Add support for sbc-3xxx with cm-t3730 ARM: dts: Add omap specific pinctrl defines to use padconf addresses arch/arm/boot/dts/Makefile| 2 + arch/arm/boot/dts/omap2.dtsi | 2 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 40 - arch/arm/boot/dts/omap3-beagle.dts| 40 - arch/arm/boot/dts/omap3-cm-t3730.dts | 104 ++ arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 95 +++ arch/arm/boot/dts/omap3-igep.dtsi | 2 - arch/arm/boot/dts/omap3-igep0020.dts | 52 + arch/arm/boot/dts/omap3-igep0030.dts | 10 ++-- arch/arm/boot/dts/omap3-sb-t35.dtsi | 40 + arch/arm/boot/dts/omap3-sbc-t3730.dts | 30 ++ arch/arm/boot/dts/omap3-zoom3.dts | 23 +--- arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/boot/dts/omap34xx.dtsi | 13 + arch/arm/boot/dts/omap36xx.dtsi | 11 arch/arm/mach-omap2/pdata-quirks.c| 31 ++ include/dt-bindings/pinctrl/omap.h| 20 +++ 17 files changed, 450 insertions(+), 67 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-cm-t3730.dts create mode 100644 arch/arm/boot/dts/omap3-cm-t3x30.dtsi create mode 100644 arch/arm/boot/dts/omap3-sb-t35.dtsi create mode 100644 arch/arm/boot/dts/omap3-sbc-t3730.dts -- 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
[GIT PULL 3/4] trivial omap big endian changes for v3.14 merge window
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/be-signed for you to fetch changes up to fc6ca98c81bf0ea8b46064915b5947b971594101: ARM: OMAP: debug-leds: raw read and write endian fix (2014-01-07 16:09:45 -0800) Trivial search and replace of read and write functions to allow further patches to make omaps work also in big endian mode. Victor Kamensky (4): ARM: OMAP2+: raw read and write endian fix ARM: OMAP: dmtimer: raw read and write endian fix ARM: OMAP: counter-32k: raw read and write endian fix ARM: OMAP: debug-leds: raw read and write endian fix arch/arm/mach-omap2/board-flash.c | 4 +-- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 2 +- arch/arm/mach-omap2/clkt2xxx_osc.c| 8 +++--- arch/arm/mach-omap2/clkt2xxx_sys.c| 2 +- arch/arm/mach-omap2/clkt_clksel.c | 10 arch/arm/mach-omap2/clkt_dpll.c | 6 ++--- arch/arm/mach-omap2/clkt_iclk.c | 8 +++--- arch/arm/mach-omap2/clock.c | 16 ++-- arch/arm/mach-omap2/clock36xx.c | 6 ++--- arch/arm/mach-omap2/cm2xxx_3xxx.h | 4 +-- arch/arm/mach-omap2/cm33xx.c | 4 +-- arch/arm/mach-omap2/cm3xxx.c | 8 +++--- arch/arm/mach-omap2/cm44xx.c | 8 +++--- arch/arm/mach-omap2/cminst44xx.c | 4 +-- arch/arm/mach-omap2/control.c | 20 +++ arch/arm/mach-omap2/dma.c | 4 +-- arch/arm/mach-omap2/dpll3xxx.c| 32 +++ arch/arm/mach-omap2/dpll44xx.c| 12 - arch/arm/mach-omap2/gpmc.c| 8 +++--- arch/arm/mach-omap2/id.c | 2 +- arch/arm/mach-omap2/irq.c | 4 +-- arch/arm/mach-omap2/mux.c | 8 +++--- arch/arm/mach-omap2/omap-hotplug.c| 4 +-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 18 ++--- arch/arm/mach-omap2/omap-smp.c| 4 +-- arch/arm/mach-omap2/omap-wakeupgen.c | 42 +++ arch/arm/mach-omap2/omap4-common.c| 16 ++-- arch/arm/mach-omap2/omap_hwmod.c | 10 arch/arm/mach-omap2/omap_phy_internal.c | 6 ++--- arch/arm/mach-omap2/prcm_mpu44xx.c| 4 +-- arch/arm/mach-omap2/prm2xxx.h | 2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h| 4 +-- arch/arm/mach-omap2/prm33xx.c | 4 +-- arch/arm/mach-omap2/prm3xxx.h | 2 +- arch/arm/mach-omap2/prm44xx.c | 4 +-- arch/arm/mach-omap2/prminst44xx.c | 4 +-- arch/arm/mach-omap2/sdrc.h| 8 +++--- arch/arm/mach-omap2/sdrc2xxx.c| 4 +-- arch/arm/mach-omap2/sr_device.c | 2 +- arch/arm/mach-omap2/sram.c| 16 ++-- arch/arm/mach-omap2/timer.c | 8 +++--- arch/arm/mach-omap2/vc.c | 4 +-- arch/arm/mach-omap2/wd_timer.c| 8 +++--- arch/arm/plat-omap/counter_32k.c | 6 ++--- arch/arm/plat-omap/debug-leds.c | 14 +-- arch/arm/plat-omap/dmtimer.c | 8 +++--- arch/arm/plat-omap/include/plat/dmtimer.h | 16 ++-- 47 files changed, 199 insertions(+), 199 deletions(-) -- 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
[GIT PULL 4/4] GIC crossbar support for v3.14 merge window
The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/crossbar-signed for you to fetch changes up to 70d4545544853e2d95909b919d4565ff32c3e3c5: ARM: DRA: Enable Crossbar IP support for DRA7XX (2014-01-08 09:21:42 -0800) Add support for GIC crossbar that routes interrupts on newer omaps. Sricharan R (4): irqchip: irq-gic: Add support for routable irqs irqchip: crossbar: Add support for Crossbar IP ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number ARM: DRA: Enable Crossbar IP support for DRA7XX Documentation/devicetree/bindings/arm/gic.txt | 6 + .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++ arch/arm/mach-omap2/Kconfig| 1 + arch/arm/mach-omap2/omap-wakeupgen.c | 4 +- arch/arm/mach-omap2/omap4-common.c | 4 + drivers/irqchip/Kconfig| 8 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-crossbar.c | 208 + drivers/irqchip/irq-gic.c | 82 +++- include/linux/irqchip/arm-gic.h| 7 +- include/linux/irqchip/irq-crossbar.h | 11 ++ 11 files changed, 346 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt create mode 100644 drivers/irqchip/irq-crossbar.c create mode 100644 include/linux/irqchip/irq-crossbar.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
-Original Message- From: Valkeinen, Tomi Sent: Wednesday, January 08, 2014 7:44 PM To: Tony Lindgren; Ivaylo Dimitrov Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-fb...@vger.kernel.org Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support On 2014-01-08 01:59, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131230 05:21]: The omapfb driver uses dma_alloc to reserve memory for the framebuffers. However, on some use cases, even when CMA is in use, it's quite probable that omapfb fails to allocate the fb, either due to not enough free dma memory, fragmented dma memory, or CMA failing to make enough contiguous space. This patch adds a kernel cmdline parameter 'omapfb_vram' which can be used to give the size of a memory area reserved exclusively for omapfb, and optionally a physical address where the memory area is reserved. The memory area is reserved with memblock, and assigned to omapfb with dma_declare_coherent_memory. The dma_alloc function will first try to allocate the fb from the coherent memory area, and if that fails, it'll use the normal method of allocation. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Ivaylo Dimitrov freemangor...@abv.bg Feel free to queue this along with the DSS patches: Acked-by: Tony Lindgren t...@atomide.com Thanks. This introduces new kernel boot parameter, and I haven't really had time to test and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd rather leave this for 3.15 as adding new parameter that we need to support forever should be thought a bit more. Tomi, I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using omapfb_vram=10M@0xA000, and I believe it is correct way of usage. Thanks, Vaibhav Tomi -- 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: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi Marek, I have no idea what is happening there. Have you tried using device tree boot? Board file boot support would be dropped eventually. Did you try if I2C read write to the twl4030 device works and all necessary clocks/supplies are present? Kishon, do you know what is causing the USB DPLL failure there? cheers, -roger On 01/09/2014 02:31 AM, Belisko Marek wrote: Any pointers? Still present in 3.13-rc7. On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote: +Kishon On 12/03/2013 11:33 PM, Belisko Marek wrote: Hi, current 3.13-rcX break usb support on gta04 board (similar to beagleboard) when booting via board file. In console we can see messages: [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5232.936096] omap_musb_mailbox: musb core is not yet ready [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock Any pointer what could cause that? (in 3.12 usb works fine) BR, marek BR, marek -- 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: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
On 09.01.2014 07:06, Hiremath, Vaibhav wrote: Tomi, I am seeing underflow issue on AM43x device if I use omapfb_vram argument. Did you see this on OMAP? I am using omapfb_vram=10M@0xA000, and I believe it is correct way of usage. Thanks, Vaibhav AFAIK underflow interrupts could come from badly calculated DSS core clock or bad HW resizer setup and should be unrelated to the memory allocation. It might be something similar to the problem I have on N900 - see https://lkml.org/lkml/2014/1/6/173 Is it possible to upload the video you have problems with, so me to test it on N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case you're not aware), no matter the resolution of the videos I played(up to 720p), however I didn't test the part that allocates the memory on a pre-defined address. Though I don't think that should matter. Ivo -- 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
