[PATCH 1/1] OMAPDSS: Return right error during connector probe
While using HDMI connector driver with sil9022 encoder
came across issue where connector driver is probed first.
This resulted in error. A deffered probe solved this.
Most connector drivers need a encoder driver as their
video source. This patch ensures we do a probe defferal
if video source is not present for connector drivers.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
.../video/omap2/displays-new/connector-analog-tv.c |2 +-
drivers/video/omap2/displays-new/connector-dvi.c |2 +-
drivers/video/omap2/displays-new/connector-hdmi.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c
b/drivers/video/omap2/displays-new/connector-analog-tv.c
index 5338f36..547a604 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -177,7 +177,7 @@ static int tvc_probe_pdata(struct platform_device *pdev)
in = omap_dss_find_output(pdata-source);
if (in == NULL) {
dev_err(pdev-dev, Failed to find video source\n);
- return -ENODEV;
+ return -EPROBE_DEFER;
}
ddata-in = in;
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
b/drivers/video/omap2/displays-new/connector-dvi.c
index bc5f8ce..63d88ee 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -263,7 +263,7 @@ static int dvic_probe_pdata(struct platform_device *pdev)
in = omap_dss_find_output(pdata-source);
if (in == NULL) {
dev_err(pdev-dev, Failed to find video source\n);
- return -ENODEV;
+ return -EPROBE_DEFER;
}
ddata-in = in;
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c
b/drivers/video/omap2/displays-new/connector-hdmi.c
index c582671..9abe2c0 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -290,7 +290,7 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
in = omap_dss_find_output(pdata-source);
if (in == NULL) {
dev_err(pdev-dev, Failed to find video source\n);
- return -ENODEV;
+ return -EPROBE_DEFER;
}
ddata-in = in;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 11.09.2013 19:42, schrieb Alexander Holler:
Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
So for example in an OMAP board DT you can define something like this:
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
};
Since each OMAP GPIO bank has 32 GPIO pins, then what you are defining
is that
the GPIO 176 (5 * 32 + 16) will be mapped as the IRQ line for the
ethernet
controller.
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
Would that be like below?
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
interrupt-parent = gpio7;
interrupts = 1 IRQF_TRIGGER_FALLING; /* GPIO7_1 */
};
So multiple definitions of interrupt-parent are allowed and the order
does matter? And such does work? Sorry for asking, but I'm relatively
new to DT. ;)
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi Kishon,
On Mon, Sep 2, 2013 at 9:13 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
I have a doubt here.
As i can see in the current phy drivers structuring, for OMAP there
are two phy drivers :
omap phy-omap-usb2 (talking to musb controller)
and phy-omap-usb3(talking to dwc3 controller).
Now dwc3 controller requests both usb2-phy (supported by phy-omap-usb2
?) and usb3-phy (supported by phy-omap-usb3 ?).
But phy-omap-usb2 is not the one designated to talk to DWC3
controller, then why does still DWC3 want to request usb2-phy, which
end of the day will be phy-omap-usb2.
May be i am wrong here since i don't have knowledge about OMAP h/w architecture.
Is it like phy-omap-usb2 includes UTMI phys for both musb controller
as well as dwc3 controller ?
Because if it is just for musb controller then which usb2-phy will
DWC3 be getting when it requests that type of phy.
As of now phy-samsung-usb3 driver is the interface for both UTMI+ and
PIPE3 phys for DWC3 DRD controller, and phy-samsung-usb2 driver is the
interface
for a separate USB 2.0 controller itself (not DWC3). So we have
something to correct things up for Samsung, since dwc3 initializing
the phy-samsung-usb2 is not a valid scenerio.
Can you please clarify things here ?
Thanks !!
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On Wednesday 11 September 2013 12:22 AM, Joel Fernandes wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. This patch fixes the issue, by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Signed-off-by: Joel Fernandes jo...@ti.com --- This patch is a repost of v2 with minor change of return value. Is this patch meant for merging? If yes, I see no resolution of the comments given in this thread: https://lkml.org/lkml/2013/7/30/9 It is better to send one version with all comments fixed. Helps avoid confusion. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Thursday 12 September 2013 02:57 PM, Vivek Gautam wrote:
Hi Kishon,
On Mon, Sep 2, 2013 at 9:13 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
I have a doubt here.
As i can see in the current phy drivers structuring, for OMAP there
are two phy drivers :
omap phy-omap-usb2 (talking to musb controller)
It talks to dwc3 controller also ;-)
and phy-omap-usb3(talking to dwc3 controller).
Now dwc3 controller requests both usb2-phy (supported by phy-omap-usb2
?) and usb3-phy (supported by phy-omap-usb3 ?).
But phy-omap-usb2 is not the one designated to talk to DWC3
controller, then why does still DWC3 want to request usb2-phy, which
end of the day will be phy-omap-usb2.
May be i am wrong here since i don't have knowledge about OMAP h/w
architecture.
Is it like phy-omap-usb2 includes UTMI phys for both musb controller
as well as dwc3 controller ?
right. It's needed for dwc3 too. The same USB2 PHY IP is used for both MUSB in
OMAP2+ platforms and DWC3 in OMAP5.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
On 09/12/2013 10:55 AM, Alexander Holler wrote:
Am 11.09.2013 19:42, schrieb Alexander Holler:
Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
So for example in an OMAP board DT you can define something like this:
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
};
Since each OMAP GPIO bank has 32 GPIO pins, then what you are defining
is that
the GPIO 176 (5 * 32 + 16) will be mapped as the IRQ line for the
ethernet
controller.
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
That is indeed a very good question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
interrupt-parent = gpio7;
interrupts = 1 IRQF_TRIGGER_FALLING; /* GPIO7_1 */
};
I just looked at
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and it
doesn't mention that use-case (same device using two different interrupts from
two different interrupt-controller).
So I went and look at the source in drivers/of/irq.c and noticed that the
interrupts property and its interrupt-parent is parsed by the
of_irq_map_one() function.
/**
* of_irq_map_one - Resolve an interrupt for a device
* @device: the device whose interrupt is to be resolved
* @index: index of the interrupt to resolve
* @out_irq: structure of_irq filled by this function
*
* This function resolves an interrupt, walking the tree, for a given
* device-tree node. It's the high level pendant to of_irq_map_raw().
*/
int of_irq_map_one(struct device_node *device, int index, struct of_irq
*out_irq)
{
struct device_node *p;
...
/* Get the interrupts property */
intspec = of_get_property(device, interrupts, intlen);
...
/* Look for the interrupt parent. */
p = of_irq_find_parent(device);
...
}
/**
* of_irq_find_parent - Given a device node, find its interrupt parent node
* @child: pointer to device node
*
* Returns a pointer to the interrupt parent node, or NULL if the interrupt
* parent could not be determined.
*/
struct device_node *of_irq_find_parent(struct device_node *child)
{
struct device_node *p;
const __be32 *parp;
if (!of_node_get(child))
return NULL;
do {
parp = of_get_property(child, interrupt-parent, NULL);
if (parp == NULL)
p = of_get_parent(child);
else {
if (of_irq_workarounds OF_IMAP_NO_PHANDLE)
p = of_node_get(of_irq_dflt_pic);
else
p = of_find_node_by_phandle(be32_to_cpup(parp));
}
of_node_put(child);
child = p;
} while (p of_get_property(p, #interrupt-cells, NULL) == NULL);
return p;
}
So, if I understood the code correctly the DT IRQ core doesn't expect a device
node to have more than one interrupt-parent property.
It *should* work though if you have multiple interrupts properties defined and
all of them have the same interrupt-parent:
interrupt-parent = gpio6;
interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */
since of_irq_map_one() will be called for each interrupts and the correct
interrupt-parent will get obtained by of_irq_find_parent().
So multiple definitions of interrupt-parent are allowed and the order
does matter? And such does work? Sorry for asking, but I'm relatively
new to DT. ;)
No worries, I'm very new to DT too so let's wait for Grant, Stephen or Linus to
give us a definite answer :)
Regards,
Alexander Holler
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
On 09/12/2013 10:55 AM, Alexander Holler wrote:
...
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
That is indeed a very good question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
interrupt-parent = gpio7;
interrupts = 1 IRQF_TRIGGER_FALLING; /* GPIO7_1 */
};
...
So, if I understood the code correctly the DT IRQ core doesn't expect a device
node to have more than one interrupt-parent property.
It *should* work though if you have multiple interrupts properties defined and
all of them have the same interrupt-parent:
interrupt-parent = gpio6;
interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */
since of_irq_map_one() will be called for each interrupts and the correct
interrupt-parent will get obtained by of_irq_find_parent().
I assumed that answer. So to make such a scenario possible, something
like this might be neccessary:
interrupts = gpio6 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = gpio7 2 IRQF_TRIGGER_LOW; /* GPIO7_2 */
or, to be compatible
interrupts = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */
interrupts = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */
Another problem is the naming. In all the above cases, the driver would
not know which IRQ he should use for what. Maybe the order defines it,
but that wouldn't be very verbose. And I think just changing the name
would make travelling the tree impossible, as only the driver itself
would know the name and it's meaning.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Thu, Sep 12, 2013 at 3:40 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Thursday 12 September 2013 02:57 PM, Vivek Gautam wrote:
Hi Kishon,
On Mon, Sep 2, 2013 at 9:13 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
I have a doubt here.
As i can see in the current phy drivers structuring, for OMAP there
are two phy drivers :
omap phy-omap-usb2 (talking to musb controller)
It talks to dwc3 controller also ;-)
Ok
and phy-omap-usb3(talking to dwc3 controller).
Now dwc3 controller requests both usb2-phy (supported by phy-omap-usb2
?) and usb3-phy (supported by phy-omap-usb3 ?).
But phy-omap-usb2 is not the one designated to talk to DWC3
controller, then why does still DWC3 want to request usb2-phy, which
end of the day will be phy-omap-usb2.
May be i am wrong here since i don't have knowledge about OMAP h/w
architecture.
Is it like phy-omap-usb2 includes UTMI phys for both musb controller
as well as dwc3 controller ?
right. It's needed for dwc3 too. The same USB2 PHY IP is used for both MUSB in
OMAP2+ platforms and DWC3 in OMAP5.
Ok, but on Samsung's exynos5 series of SoCs, the USB2.0 controller has
a separate USB-PHY interface talking to phy-samsung-usb2 driver;
and DWC3 drd controller has separate USB-PHY interface (including both
UTMI+ and PIPE3 control registers) talking to phy-samsung-usb3 driver.
So in this case DWC3 doesn't need phy-samsung-usb2 at all. It's phy is
configured by
Re: [PATCH 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if usb-phy property is added in the case of dt boot or if
platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 60
+-
drivers/usb/dwc3/platform_data.h |1 +
3 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..cfc16dd 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..428c29e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,38 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ if (of_property_read_bool(node, usb-phy)) {
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
Some DWC3 instances use only usb2_phy. e.g. on DRA7 the 2nd dwc3 instance
doesn't use usb3_phy.
This needs to be a valid case and driver shouldn't error out.
+ } else {
+ dwc-usb2_phy = NULL;
+ dwc-usb3_phy = NULL;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ if (pdata-has_phy) {
+ dwc-usb2_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB2);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB3);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
same here?
+ } else {
+ dwc-usb2_phy = NULL;
+ dwc-usb3_phy = NULL;
+ }
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
@@ -409,36 +431,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
- if (IS_ERR(dwc-usb2_phy)) {
- ret = PTR_ERR(dwc-usb2_phy);
-
- /*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb2 phy configured\n);
- return -EPROBE_DEFER;
- }
-
- if (IS_ERR(dwc-usb3_phy)) {
- ret = PTR_ERR(dwc-usb3_phy);
-
- /*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb3 phy configured\n);
- return -EPROBE_DEFER;
- }
-
dwc-xhci_resources[0].start = res-start;
dwc-xhci_resources[0].end = dwc-xhci_resources[0].start +
DWC3_XHCI_REGS_END;
diff --git a/drivers/usb/dwc3/platform_data.h
b/drivers/usb/dwc3/platform_data.h
index 7db34f0..5a5e068 100644
---
Re: [PATCH 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY
On Thu, Sep 12, 2013 at 4:06 PM, Roger Quadros rog...@ti.com wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if usb-phy property is added in the case of dt boot or if
platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 60
+-
drivers/usb/dwc3/platform_data.h |1 +
3 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..cfc16dd 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..428c29e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,38 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ if (of_property_read_bool(node, usb-phy)) {
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
Some DWC3 instances use only usb2_phy. e.g. on DRA7 the 2nd dwc3 instance
doesn't use usb3_phy.
This needs to be a valid case and driver shouldn't error out.
So, i think adding flexibility to DWC3 to have either
usb2-phy/usb3-phy or both of them seems to be valid point.
Any suggestions ?
+ } else {
+ dwc-usb2_phy = NULL;
+ dwc-usb3_phy = NULL;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ if (pdata-has_phy) {
+ dwc-usb2_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB2);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB3);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
same here?
+ } else {
+ dwc-usb2_phy = NULL;
+ dwc-usb3_phy = NULL;
+ }
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
@@ -409,36 +431,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
- if (IS_ERR(dwc-usb2_phy)) {
- ret = PTR_ERR(dwc-usb2_phy);
-
- /*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb2 phy configured\n);
- return -EPROBE_DEFER;
- }
-
- if (IS_ERR(dwc-usb3_phy)) {
- ret = PTR_ERR(dwc-usb3_phy);
-
- /*
- * if -ENXIO is returned, it means PHY layer wasn't
- * enabled, so it makes no sense to return -EPROBE_DEFER
- * in that case, since no PHY driver will ever probe.
- */
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb3 phy configured\n);
- return -EPROBE_DEFER;
- }
-
dwc-xhci_resources[0].start = res-start;
dwc-xhci_resources[0].end =
Re: [PATCH 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY
Hi,
On 09/12/2013 01:47 PM, Vivek Gautam wrote:
On Thu, Sep 12, 2013 at 4:06 PM, Roger Quadros rog...@ti.com wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if usb-phy property is added in the case of dt boot or if
platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy
layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 60
+-
drivers/usb/dwc3/platform_data.h |1 +
3 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..cfc16dd 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..428c29e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,38 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy,
0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy,
1);
+ if (of_property_read_bool(node, usb-phy)) {
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
Some DWC3 instances use only usb2_phy. e.g. on DRA7 the 2nd dwc3 instance
doesn't use usb3_phy.
This needs to be a valid case and driver shouldn't error out.
So, i think adding flexibility to DWC3 to have either
usb2-phy/usb3-phy or both of them seems to be valid point.
Any suggestions ?
For high speed operation we need only usb2_phy but for super speed we need both
usb2_phy
and usb3_phy.
Why would a dwc3 controller use only usb3_phy? A USB3.0 interface has to be
compatible with
USB2.0 as well, no?
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] RFC: interrupt consistency check for OF GPIO IRQs
Am 12.09.2013 12:28, schrieb Alexander Holler:
Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
On 09/12/2013 10:55 AM, Alexander Holler wrote:
...
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
That is indeed a very good question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
interrupt-parent = gpio7;
interrupts = 1 IRQF_TRIGGER_FALLING; /* GPIO7_1 */
};
...
So, if I understood the code correctly the DT IRQ core doesn't expect
a device
node to have more than one interrupt-parent property.
It *should* work though if you have multiple interrupts properties
defined and
all of them have the same interrupt-parent:
interrupt-parent = gpio6;
interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */
since of_irq_map_one() will be called for each interrupts and the
correct
interrupt-parent will get obtained by of_irq_find_parent().
I assumed that answer. So to make such a scenario possible, something
like this might be neccessary:
interrupts = gpio6 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = gpio7 2 IRQF_TRIGGER_LOW; /* GPIO7_2 */
or, to be compatible
interrupts = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */
interrupts = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */
Another problem is the naming. In all the above cases, the driver would
not know which IRQ he should use for what. Maybe the order defines it,
but that wouldn't be very verbose. And I think just changing the name
would make travelling the tree impossible, as only the driver itself
would know the name and it's meaning.
On a second look, travelling the tree is still possible if the solution
would be like above (without that interrupt-parent). So if a driver
requires two interrupts he could use
interrupt-foo = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */
interrupt-bar = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */
And travelling the tree will still be possible because walking from the
interrupt-controllers (those gpio) downwards would end up at the
interrupt definitions, so the name of them isn't needed to find them in
the tree.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-omap-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.
I would suggest to split the renaming and PHY adaptation into 2 separate
patches.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |5 +-
drivers/phy/Kconfig| 10 +
drivers/phy/Makefile |1 +
.../phy/phy-omap-usb3.c = phy/phy-omap-pipe3.c} | 206
+++-
how about naming it to phy-ti-pipe3.c as it is used on OMAP as well as non-OMAP
e.g. DRA7.
drivers/usb/phy/Kconfig| 11 --
drivers/usb/phy/Makefile |1 -
include/linux/phy/omap_pipe3.h | 52 +
7 files changed, 177 insertions(+), 109 deletions(-)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-omap-pipe3.c} (57%)
create mode 100644 include/linux/phy/omap_pipe3.h
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index c0245c8..36bdb17 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -21,10 +21,11 @@ usb2phy@4a0ad080 {
#phy-cells = 0;
};
-OMAP USB3 PHY
+OMAP PIPE3 PHY
Required properties:
- - compatible: Should be ti,omap-usb3
+ - compatible: Should be ti,omap-usb3, ti,omap-pipe3, ti,omap-sata
+ or ti,omap-pcie
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ac239ac..5c2e7a0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,6 +27,16 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_PIPE3
+ tristate OMAP PIPE3 PHY Driver
+ select GENERIC_PHY
+ select OMAP_CONTROL_USB
how about
depends on OMAP_CONTROL_USB
Also, if this is TI/OMAP it might as well depend on ARCH_OMAP.
+ help
+ Enable this to support the PIPE3 PHY that is part of SOC. This
worth mentioning TI OMAP/DRA SoCs.
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the OMAP Control PHY Driver to power
+ on/off the PHY.
+
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0dd8a98..48bf9f2 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
+obj-$(CONFIG_OMAP_PIPE3) += phy-omap-pipe3.o
obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-omap-pipe3.c
similarity index 57%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-omap-pipe3.c
index 4004f82..ee9a901 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-omap-pipe3.c
@@ -1,5 +1,5 @@
/*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * omap-pipe3 - PHY driver for SATA, USB and PCIE in OMAP platforms
*
* Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
* This program is free software; you can redistribute it and/or modify
@@ -19,7 +19,8 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/usb/omap_usb.h
+#include linux/phy/omap_pipe3.h
+#include linux/phy/phy.h
#include linux/of.h
#include linux/clk.h
#include linux/err.h
@@ -52,17 +53,17 @@
/*
* This is an Empirical value that works, need to confirm the actual
- * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status
- * to be correctly reflected in the USB3PHY_PLL_STATUS register.
+ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
+ * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
*/
# define PLL_IDLE_TIME 100;
-struct usb_dpll_map {
+struct pipe3_dpll_map {
unsigned long rate;
- struct usb_dpll_params params;
+ struct pipe3_dpll_params params;
};
-static struct usb_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map[] = {
{1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */
@@ -71,7 +72,7 @@ static struct usb_dpll_map dpll_map[] = {
{3840, {3125, 47, 4, 20,
Re: [PATCH 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY
Hi,
On Thu, Sep 12, 2013 at 4:34 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 09/12/2013 01:47 PM, Vivek Gautam wrote:
On Thu, Sep 12, 2013 at 4:06 PM, Roger Quadros rog...@ti.com wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if usb-phy property is added in the case of dt boot or if
platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy
layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 60
+-
drivers/usb/dwc3/platform_data.h |1 +
3 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..cfc16dd 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..428c29e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,38 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy,
0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy,
1);
+ if (of_property_read_bool(node, usb-phy)) {
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
Some DWC3 instances use only usb2_phy. e.g. on DRA7 the 2nd dwc3 instance
doesn't use usb3_phy.
This needs to be a valid case and driver shouldn't error out.
So, i think adding flexibility to DWC3 to have either
usb2-phy/usb3-phy or both of them seems to be valid point.
Any suggestions ?
For high speed operation we need only usb2_phy but for super speed we need
both usb2_phy
and usb3_phy.
Why would a dwc3 controller use only usb3_phy? A USB3.0 interface has to be
compatible with
USB2.0 as well, no?
True and for that reason we need both UTMI+ interface as well as PIPE3
interface, right ?
But as also mentioned in the thread:
https://lkml.org/lkml/2013/9/12/181, on Samsung exynos5
architecturally same block is managing UTMI+ and PIPE3 interfaces,
which is handled by phy-samsung-usb3 driver and denoted by usb3_phy:
usbphy@1210 node in arch/arm/boot/dts/exynos5250.dtsi.
So on exynos5250, DWC3 really needs just usb3-phy, which is compatible
for USB 2.0 as well.
cheers,
-roger
--
Best Regards
Vivek
--
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] RFC: interrupt consistency check for OF GPIO IRQs
Am 12.09.2013 13:09, schrieb Alexander Holler:
Am 12.09.2013 12:28, schrieb Alexander Holler:
Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
On 09/12/2013 10:55 AM, Alexander Holler wrote:
...
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
That is indeed a very good question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = smsc,lan9221, smsc,lan9115;
interrupt-parent = gpio6;
interrupts = 16 8;
interrupt-parent = gpio7;
interrupts = 1 IRQF_TRIGGER_FALLING; /* GPIO7_1 */
};
...
So, if I understood the code correctly the DT IRQ core doesn't expect
a device
node to have more than one interrupt-parent property.
It *should* work though if you have multiple interrupts properties
defined and
all of them have the same interrupt-parent:
interrupt-parent = gpio6;
interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */
since of_irq_map_one() will be called for each interrupts and the
correct
interrupt-parent will get obtained by of_irq_find_parent().
I assumed that answer. So to make such a scenario possible, something
like this might be neccessary:
interrupts = gpio6 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = gpio7 2 IRQF_TRIGGER_LOW; /* GPIO7_2 */
or, to be compatible
interrupts = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */
interrupts = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */
Another problem is the naming. In all the above cases, the driver would
not know which IRQ he should use for what. Maybe the order defines it,
but that wouldn't be very verbose. And I think just changing the name
would make travelling the tree impossible, as only the driver itself
would know the name and it's meaning.
On a second look, travelling the tree is still possible if the solution
would be like above (without that interrupt-parent). So if a driver
requires two interrupts he could use
interrupt-foo = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */
interrupt-bar = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */
And travelling the tree will still be possible because walking from the
interrupt-controllers (those gpio) downwards would end up at the
interrupt definitions, so the name of them isn't needed to find them in
the tree.
I've just seen how they solved it for dma:
dmas = edma0 16
edma0 17;
dma-names = rx, tx;
so it would be like
interrupts = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */
interrupts = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */
interrupt-names = foo, bar;
Or this would be possible:
interrupt-parent = gpio6 gpio7;
interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */
interrupts = 1 IRQF_TRIGGER_LOW; /* GPIO7_1 */
interrupt-names = foo, bar;
Regards,
Alexander
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 12.09.2013 13:26, schrieb Alexander Holler: Am 12.09.2013 13:09, schrieb Alexander Holler: Am 12.09.2013 12:28, schrieb Alexander Holler: Am 12.09.2013 12:11, schrieb Javier Martinez Canillas: On 09/12/2013 10:55 AM, Alexander Holler wrote: ... So, if I understood the code correctly the DT IRQ core doesn't expect a device node to have more than one interrupt-parent property. It *should* work though if you have multiple interrupts properties defined and all of them have the same interrupt-parent: interrupt-parent = gpio6; interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */ interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */ since of_irq_map_one() will be called for each interrupts and the correct interrupt-parent will get obtained by of_irq_find_parent(). I assumed that answer. So to make such a scenario possible, something like this might be neccessary: interrupts = gpio6 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */ interrupts = gpio7 2 IRQF_TRIGGER_LOW; /* GPIO7_2 */ or, to be compatible interrupts = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */ interrupts = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */ Another problem is the naming. In all the above cases, the driver would not know which IRQ he should use for what. Maybe the order defines it, but that wouldn't be very verbose. And I think just changing the name would make travelling the tree impossible, as only the driver itself would know the name and it's meaning. On a second look, travelling the tree is still possible if the solution would be like above (without that interrupt-parent). So if a driver requires two interrupts he could use interrupt-foo = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */ interrupt-bar = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */ And travelling the tree will still be possible because walking from the interrupt-controllers (those gpio) downwards would end up at the interrupt definitions, so the name of them isn't needed to find them in the tree. I've just seen how they solved it for dma: dmas = edma0 16 edma0 17; dma-names = rx, tx; so it would be like interrupts = 1 IRQF_TRIGGER_HIGH gpio6; /* GPIO6_1 */ interrupts = 1 IRQF_TRIGGER_LOW gpio7; /* GPIO7_1 */ interrupt-names = foo, bar; Or this would be possible: interrupt-parent = gpio6 gpio7; interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */ interrupts = 1 IRQF_TRIGGER_LOW; /* GPIO7_1 */ interrupt-names = foo, bar; And looking at how gpios are defined, I think it should be like that: interrupts = gpio6 1 IRQF_TRIGGER_HIGH gpio7 2 IRQF_TRIGGER_LOW ; interrupt-names = foo, bar; So without that interrupt-parent. Regards, Alexander -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/4] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
|(requires CONFIG_MTD_NAND_OMAP_BCH | | |
| ti,elm-id in DT) | | |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
This patch
- removes OMAP_ECC_HAMMING_CODE_DEFAULT and OMAP_ECC_HAMMING_CODE_HW_ROMCODE
- separates the configurations for other ECC schemes
- fixes dependency issues based on Kconfig options
- updates ELM device detection in is_elm_present()
- cleans redundant code
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 530 +--
include/linux/platform_data/mtd-nand-omap2.h | 7 +-
2 files changed, 260 insertions(+), 277 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4ecf0e5..420078f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,8 +25,10 @@
#include linux/of.h
#include linux/of_device.h
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
#endif
@@ -141,6 +143,9 @@
#define BCH_ECC_SIZE0 0x0 /* ecc_size0 = 0, no oob protection */
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
+#define BADBLOCK_MARKER_LENGTH 0x2
+#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
+
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +187,11 @@ struct omap_nand_info {
u_char *buf;
int buf_len;
struct gpmc_nand_regs reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
- struct bch_control *bch;
- struct nand_ecclayout ecclayout;
+ /* fields specific for BCHx_HW ECC scheme */
+ struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
-#endif
};
/**
@@ -1058,8 +1060,6 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
/**
* omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
* @mtd: MTD device structure
@@ -1141,6 +1141,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd,
int mode)
writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
}
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
* @mtd: MTD device structure
@@ -1227,6 +1228,62 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
}
/**
+ * omap3_correct_data_bch - Decode received data and correct errors
+ * @mtd: MTD device structure
+ * @data: page data
+ * @read_ecc: ecc read from nand flash
+ * @calc_ecc: ecc read from HW ECC registers
+ */
+static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
+ u_char *read_ecc, u_char *calc_ecc)
+{
+ int i, count;
+ /* cannot correct more than 8 errors */
+ unsigned int errloc[8];
+ struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
+ mtd);
+
+ count = decode_bch(info-bch, NULL, 512, read_ecc, calc_ecc, NULL,
+ errloc);
+ if (count 0) {
+ /* correct errors */
+ for (i = 0; i count; i++) {
+ /* correct data only, not ecc bytes */
+ if (errloc[i] 8*512)
+ data[errloc[i]/8] ^= 1 (errloc[i] 7);
+ pr_debug(corrected bitflip %u\n, errloc[i]);
+ }
+ } else if (count
[PATCH v6 3/4] mtd:nand:omap2: updated support for BCH4 ECC scheme
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error correction.
- OMAP_ECC_BCH4_CODE_HW
- uses GPMC H/W engine for calculating ECC.
- uses ELM H/W engine for error correction.
With this patch omap2-nand driver supports following ECC schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_DEFAULT |S/W|S/W|
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
|OMAP_ECC_HAMMING_CODE_HW_ROMCODE |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Important:
- Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm.
- Selection of OMAP_ECC_BCHx_CODE_HW requires,
Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/Kconfig | 30 ++-
drivers/mtd/nand/omap2.c | 136 ++-
2 files changed, 68 insertions(+), 98 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index d885298..5836039 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -96,35 +96,13 @@ config MTD_NAND_OMAP2
config MTD_NAND_OMAP_BCH
depends on MTD_NAND MTD_NAND_OMAP2 ARCH_OMAP3
- tristate Enable support for hardware BCH error correction
+ tristate Support hardware based BCH error correction
default n
select BCH
- select BCH_CONST_PARAMS
help
-Support for hardware BCH error correction.
-
-choice
- prompt BCH error correction capability
- depends on MTD_NAND_OMAP_BCH
-
-config MTD_NAND_OMAP_BCH8
- bool 8 bits / 512 bytes (recommended)
- help
-Support correcting up to 8 bitflips per 512-byte block.
-This will use 13 bytes of spare area per 512 bytes of page data.
-This is the recommended mode, as 4-bit mode does not work
-on some OMAP3 revisions, due to a hardware bug.
-
-config MTD_NAND_OMAP_BCH4
- bool 4 bits / 512 bytes
- help
-Support correcting up to 4 bitflips per 512-byte block.
-This will use 7 bytes of spare area per 512 bytes of page data.
-Note that this mode does not work on some OMAP3 revisions, due to a
-hardware bug. Please check your OMAP datasheet before selecting this
-mode.
-
-endchoice
+ Some devices have built-in ELM hardware engine, which can be used to
+ locate and correct errors when using BCH ECC scheme. This enables the
+ driver support for same.
if MTD_NAND_OMAP_BCH
config BCH_CONST_M
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 420078f..6f4596c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -27,6 +27,7 @@
#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#include linux/mtd/nand_bch.h
#endif
#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
@@ -144,7 +145,6 @@
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
#define BADBLOCK_MARKER_LENGTH 0x2
-#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
@@ -185,10 +185,9 @@ struct omap_nand_info {
OMAP_NAND_IO_WRITE, /* write */
} iomode;
u_char *buf;
- int buf_len;
+ int buf_len;
struct gpmc_nand_regs reg;
/* fields specific for BCHx_HW ECC scheme */
- struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
@@ -1227,58 +1226,6 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
return 0;
}
-/**
- * omap3_correct_data_bch - Decode received data and correct errors
- * @mtd: MTD device structure
- * @data: page data
- * @read_ecc: ecc read from nand flash
- *
[PATCH v6 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
*Changes v5 - v6* [PATCH 1/4]: - updated DT binding for gpmc-nand based on 'Olof Johansson's feedbacks http://lists.infradead.org/pipermail/linux-mtd/2013-August/048394.html - detection of ELM device via ti,elm-id DT node, moved to gpmc.c driver [PATCH 2/4] - removed: support for following obselete ECC schemes OMAP_ECC_HAMMING_CODE_DEFAULT (S/W based 1-bit Hamming ECC) OMAP_ECC_HAMMING_CODE_HW_ROMCODE (H/W based 1-bit Hamming ECC scheme) - updated: using omap_oobinfo as chip-ecc.layout for all ecc-schemes - clean: error messages [PATCH 3/4] cleaned to include changes for OMAP_ECC_BCH8_CODE_HW only [PATCH 4/4] updated to include DT property changes *Changes v4 - v5* - Rebased to linux-next IMPORTANT: Need to revert commit fb1585b, [PATCH 2/4] part of previous version http://lists.infradead.org/pipermail/linux-mtd/2013-July/047441.html - Swapped PATCH-1 PATCH-2 to maintain bisectibility compilation dependency http://lists.infradead.org/pipermail/linux-mtd/2013-July/047461.html - PATCH-2: re-ordered call to is_elm_present() for later updates ELM driver - dropped changes in include/linux/platform_data/elm.h (not needed) - PATCH-3: re-ordered call to is_elm_present() for later updates ELM driver - Re-formated patch description (replaced tabs with white-spaces) *Changes v3 - v4* (Resent with CC: devicetree-disc...@lists.ozlabs.org) - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 MTD_NAND_OMAP_BCH4 from nand/Kconfig ECC scheme selectable via nand DT (nand-ecc-opt). - [*] rebased for l2-mtd.git *Changes v2 - v3* (Resent with Author Name fixed) - PATCH-1: re-arranged code to remove redundancy, added NAND_BUSWIDTH_AUTO - PATCH-2: updated nand-ecc-opt DT mapping and Documentation - PATCH-3: code-cleaning + changes to match PATCH-1 - PATCH-4 DROPPED update DT attribute for ti,nand-ecc-opt - received feedback to keep DT mapping independent of linuxism - PATCH-4:NEW : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt - independent patch for AM335x-evm.dts update based on PATCH-2 *Changes v1 - v2* added [PATCH 3/4] and [PATCH 4/4] *Patches in this series* [PATCH 1/4]-[PATCH v5 2/4]: clean-up and optimization for supported ECC schemes. [PATCH 2/4]-[PATCH v5 1/4]: add separate DT options each supported ECC scheme. [PATCH 3/4]: update BCH4 ECC implementation (using ELM or using lib/bch.h) [PATCH 4/4]: ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt After this patch series, omap2-nand driver will supports following ECC schemes: +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ - Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires, Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm. - Selection of OMAP_ECC_BCHx_CODE_HW requires, Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module. Pekon Gupta (4): ARM: OMAP2+: cleaned-up DT support of various ECC schemes mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe mtd:nand:omap2: updated support for BCH4 ECC scheme ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt .../devicetree/bindings/mtd/gpmc-nand.txt | 14 +- arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/mach-omap2/board-flash.c | 2 +- arch/arm/mach-omap2/gpmc.c | 47 +- drivers/mtd/nand/Kconfig | 30 +- drivers/mtd/nand/omap2.c | 526 ++--- include/linux/platform_data/mtd-nand-omap2.h | 18 +- 7 files changed, 309 insertions(+), 330 deletions(-) -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/4] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
DT property values for OMAP based gpmc-nand have been updated
to match changes in commit:
6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..e28a2ac 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -268,7 +268,7 @@
nand@0,0 {
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
- ti,nand-ecc-opt = bch8;
+ ti,nand-ecc-scheme = bch8;
gpmc,device-nand = true;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAMMING_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
|(requires CONFIG_MTD_NAND_OMAP_BCH | | |
| ti,elm-id in DT) | | |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
This patch
- updates DT binding for selection of ecc-scheme
- updates DT binding for detection of ELM h/w engine
- removes following obselete ECC schemes
OMAP_ECC_HAMMING_CODE_DEFAULT (S/W based 1-bit Hamming ECC)
OMAP_ECC_HAMMING_CODE_HW_ROMCODE (H/W based 1-bit Hamming ECC scheme)
- updates DT binding documentation for mtd/gpmc-nand
Signed-off-by: Pekon Gupta pe...@ti.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 14 +++
arch/arm/mach-omap2/board-flash.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 47 +++---
include/linux/platform_data/mtd-nand-omap2.h | 23 +++
4 files changed, 56 insertions(+), 30 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb..958e5d5 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -21,11 +21,8 @@ Optional properties:
is wired that way. If not specified, a bus
width of 8 is assumed.
- - ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
-
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc hamming mode method romcode layout
+ - ti,nand-ecc-scheme: A string setting the ECC layout to use. One of:
+ ham1 1-bit Hamming ecc code
bch4 4-bit BCH ecc code
bch8 8-bit BCH ecc code
@@ -36,8 +33,11 @@ Optional properties:
prefetch-dma Prefetch enabled sDMA mode
prefetch-irq Prefetch enabled irq mode
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
+ - ti,elm-id: Specifies pHandle of the ELM devicetree node.
+ ELM is an on-chip hardware engine on TI SoC which is used for
+ locating ECC errors for BCHx algorithms. SoC devices which have
+ ELM hardware engines should specify this device node in .dtsi
+ Using ELM for ECC error correction frees some CPU cycles.
For inline partiton table parsing (optional):
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index fc20a61..ac82512 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -142,7 +142,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
+ board_nand_data.ecc_opt = OMAP_ECC_BCH8_CODE_HW;
gpmc_nand_init(board_nand_data, gpmc_t);
}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9f4795a..6409884 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1340,15 +1340,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
}
#ifdef CONFIG_MTD_NAND
-
-static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
- [OMAP_ECC_HAMMING_CODE_HW] = hw,
- [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = hw-romcode,
- [OMAP_ECC_BCH4_CODE_HW] = bch4,
- [OMAP_ECC_BCH8_CODE_HW] = bch8,
-};
-
RE: [PATCH v5 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
On Thu, Aug 22, 2013 at 07:56:57AM +, Gupta, Pekon wrote: If anything, the device entry should somehow describe the various ecc options that the hardware implements (if you can't derive that from the compatible value, which I think you can?). Also I'll try to explain how below ecc-scheme selection is linked to TI Hardware. TI SoC uses two separate H/W engines for calculating and correcting ECC. (a) GPMC: General Purpose Memory Controller which calculates ECC also. (b) ELM: Error Locator Module which just locates errors in BCHx code only. *Reason-1*: All OMAP platforms have (a) GPMC h/w engine, but some legacy OMAP platforms do not have (b) ELM h/w engine. Such older platforms use S/W lib/bch.c libraries for ECC error detection. Ok, so then you just need a binary elm-engine property to indicate that the hardware does have the engine. Therefore in-order to keep the driver consistent for all platforms we needed to keep so many ECC options alive. Like below you would see two versions of BCH8 and BCH4 - bch8_code_hw (supported on new devices with ELM h/w engine) - bch8_code_hw_detection_sw (kept for legacy devices) All you need to specify is what ECC format is used. I.e. BCH8. Whether the hardware or software will be used to calculate the checksums and detect/correct errors is a driver decision, and not something that the device tree needs to specify. *Reason-2*: Also H/W ECC schemes have different ECC layout, which is compatible to ROM code. Thus end-to-end NAND boot would work only with xx_code_hw schemes only. So you should describe what the layout in use is. Wouldn't it be possible to make the software handle the same layout as the hardware engine if needed? I.e. the decision of using HW or SW is not a property of the hardware and shouldn't be described in the device tree. Sorry I was caught up in some other priority work, therefore could not update this. But I have recently posted another version with your feedbacks incorporated. Please review them, whenever possible. http://lists.infradead.org/pipermail/linux-mtd/2013-September/048611.html Patch series at: http://lists.infradead.org/pipermail/linux-mtd/2013-September/048613.html Thank you With regards, pekon
RE: [PATCH v5 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
Hi,
[...]
You might also consider a future patch for utilizing devm_* functions
for the probe/remove routines in drivers/mtd/nand/omap2.c. That could
improve some of the stuff I looked at in this series.
Thanks for feedback.
I have not incorporated this particular update in v6, as I do not have much
knowledge about devm_* functions. But I'll keep it in my to-do(s) once
driver is complete feature wise.
with regards, pekon
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Hi Philipp, On Monday 09 September 2013 02:36 PM, Philipp Zabel wrote: So if I understand correctly, the only problem is that on OMAP the clock needs to be enabled to deassert the reset, but as long as the clock domain is in hardware supervised mode, it won't be enabled? Yes, enabling clock with reset deassertion might not reset the module if the clock domain is in hardware supervised mode. Would it be possible to create an internal API to switch the clock domain to software supervised mode, which can be used both by the code behind pm_runtime_get_sync and reset_control_deassert? I will see if that is acceptable. Another option that would have to be explored is invoking device_reset() (taking care of clear, deassert status checking as you suggested) midway through pm_run_time_get_sync(), when the clockdomain is in software supervised mode with reset driver taking care of any particular sequence in the case of multiple reset signals, instead of the IP driver requiring to take care of it. Regards Afzal -- 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: commit 5fe212364 causes division by zero with large bauds
Hi,
On Thu, Sep 12, 2013 at 07:32:54AM +0300, Alexey Pelykh wrote:
On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
Hi Felipe,
Thanks for finding this issue. Indeed, there is a bug on 3M+ baud
rates. First patch is close to a complete fix, but still contains
div-by-zero issue. Here is my version:
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 816d1a2..808a880 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,8 +240,8 @@ serial_omap_baud_is_mode16(struct uart_port
*port,
unsigned int baud)
{
unsigned int n13 = port-uartclk / (13 * baud);
unsigned int n16 = port-uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
+ int baudAbsDiff13 = n13 ? (baud - (port-uartclk / (13 *
n13))) : INT_MAX;
+ int baudAbsDiff16 = n16 ? (baud - (port-uartclk / (16 *
n16))) : INT_MAX;
IOW:
int baudAbsDiff13 = 0;
if (n13)
baudAbsDiff13 = (baud - (port-uartclk / (13 * n13)));
Not quite same code, INT_MAX instead of 0. With 0 a div-by-zero
exception will still occur on 3686400.
why, there's no division after that point, right ? Besides,
serial_omap_baud_is_mode16() is supposed to return a boolean value.
Setting baudAbsDiff1[36] to 0 will cause no problems, you're only using
that value with a boolean expression, no divisions whatsoever. Division
is done after using serial_omap_baud_is_mode16() to initialize divisor
to 13 or 16 (which is a misnamer, since that's the oversampling
parameter).
Yes, variables are a bit misnamed, that should be fixed someday.
Regarding 0 vs INT_MAX, in case of 0 values will be
300: divisor = 12307 (13)
600: divisor = 6153 (13)
1200: divisor = 3076 (13)
2400: divisor = 1538 (13)
4800: divisor = 625 (16)
9600: divisor = 384 (13)
14400: divisor = 256 (13)
19200: divisor = 192 (13)
28800: divisor = 128 (13)
38400: divisor = 96 (13)
57600: divisor = 64 (13)
115200: divisor = 32 (13)
230400: divisor = 16 (13)
460800: divisor = 8 (13)
921600: divisor = 4 (13)
100: divisor = 3 (16)
1843200: divisor = 2 (13)
300: divisor = 1 (16)
3686400: divisor = 0 (16) error here, should be 1 (13), as it is with
INT_MAX
I get it now... your boolean check wants to use the closer baud to
requested baud, so it's mode16 if the delta between baudAbsDiff16 and
requested rate is less than delta between baudAbsDiff13 and requested
baud.
which is exactly what my patch did. I fail to see where division by
zero
would be coming from.
if(baudAbsDiff13 0)
baudAbsDiff13 = -baudAbsDiff13;
if(baudAbsDiff16 0)
With 48MHz UART clock, it will give
300: divisor = 12307 (13), real rate 300 (0.00%)
600: divisor = 6153 (13), real rate 600 (0.00%)
1200: divisor = 3076 (13), real rate 1200 (0.00%)
2400: divisor = 1538 (13), real rate 2400 (0.00%)
TRM has these all set with oversampling of 16. In fact only 460800,
921600, 1843200 and 3686400 should be using oversampling of 13.
That's true, but TRM anyways does not contain all possible baud rates
(1M e.g.). IMO, as long as error rate is the same as in TRM,
it makes no difference what combination of (mode, divisor) to use.
--
balbi
A complex solution may be implemented: use LUT for baud rates that TRM
defines explicitly, and use calculation if lookup failed.
why would you try calculating anything if there is nothing in the table
which can support it ? Whatever is in the lookup table, are the only
baud rates the SoC supports, right ?
Actually, I haven't found any statement in TRM, which would mention
that listed baudrates in referenced table are the only supported baud
rates,
and all others are illegal.
The UART clocks are connected to produce a baud rate of up to 3.6 Mbps.
Table 24-122 lists the *supported* baud rates, requested divisor, and
corresponding error versus the standard baud rate.
At least 1M which I use extensively works perfectly, and I can not
figure out any idea why it would not do so.
it might very well work, but it's not officially *supported* by the IP.
That's true, but I don't see any reason why driver should disallow
usage of baud rates that are not supported, but possible by hardware:
The UART clocks are connected to produce a baud rate of up to 3.6M bits/s.
fair point.
I've changed calculation a bit to give priority to mode16, and now it
gives TRM table as-is + extra baud rates
300: divisor = 1 (16), real rate 300 (0.00%)
600: divisor = 5000 (16), real rate 600 (0.00%)
1200: divisor = 2500 (16), real rate
Re: commit 5fe212364 causes division by zero with large bauds
Hi,
On Thu, Sep 12, 2013 at 07:37:07AM +0300, Alexey Pelykh wrote:
Actually, here it is, but not formatted properly
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 816d1a2..146e712 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,14 +240,14 @@ serial_omap_baud_is_mode16(struct uart_port
*port, unsigned int baud)
{
unsigned int n13 = port-uartclk / (13 * baud);
unsigned int n16 = port-uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
+ int baudAbsDiff13 = n13 ? (baud - (port-uartclk / (13 * n13))) : INT_MAX;
+ int baudAbsDiff16 = n16 ? (baud - (port-uartclk / (16 * n16))) : INT_MAX;
if(baudAbsDiff13 0)
baudAbsDiff13 = -baudAbsDiff13;
if(baudAbsDiff16 0)
baudAbsDiff16 = -baudAbsDiff16;
- return (baudAbsDiff13 baudAbsDiff16);
+ return (baudAbsDiff13 = baudAbsDiff16);
}
/*
@@ -258,13 +258,13 @@ serial_omap_baud_is_mode16(struct uart_port
*port, unsigned int baud)
static unsigned int
serial_omap_get_divisor(struct uart_port *port, unsigned int baud)
{
- unsigned int divisor;
+ unsigned int mode;
if (!serial_omap_baud_is_mode16(port, baud))
- divisor = 13;
+ mode = 13;
else
- divisor = 16;
- return port-uartclk/(baud * divisor);
+ mode = 16;
+ return port-uartclk/(mode * baud);
}
static void serial_omap_enable_ms(struct uart_port *port)
looks good to me, but I'd split it as suggested as a reply to previous
email.
--
balbi
signature.asc
Description: Digital signature
Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)
On Tue, Mar 5, 2013 at 10:13 PM, Matt Porter mpor...@ti.com wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_conf_bus_power(host);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
- ret = -ENXIO;
- goto err_irq;
- }
- tx_req = res-start;
+ if (!pdev-dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
tx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA TX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ tx_req = res-start;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
- ret = -ENXIO;
- goto err_irq;
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
rx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA RX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ rx_req = res-start;
}
- rx_req = res-start;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
Now this is in mainline, I get (gcc 4.1.2):
drivers/mmc/host/omap_hsmmc.c: In function ‘omap_hsmmc_probe’:
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘rx_req’ may be used
uninitialized in this function
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘tx_req’ may be used
uninitialized in this function
Indeed, rx_req and tx_req are not initialized in the DT case.
Initializing them to zero is probably not the right fix. Where are the values
supposed to come from in the DT case?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY
On 09/12/2013 02:26 PM, Vivek Gautam wrote:
Hi,
On Thu, Sep 12, 2013 at 4:34 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 09/12/2013 01:47 PM, Vivek Gautam wrote:
On Thu, Sep 12, 2013 at 4:06 PM, Roger Quadros rog...@ti.com wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if usb-phy property is added in the case of dt boot or if
platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy
layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 60
+-
drivers/usb/dwc3/platform_data.h |1 +
3 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..cfc16dd 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..428c29e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,38 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy,
0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy,
1);
+ if (of_property_read_bool(node, usb-phy)) {
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy))
+ return PTR_ERR(dwc-usb2_phy);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy))
+ return PTR_ERR(dwc-usb3_phy);
Some DWC3 instances use only usb2_phy. e.g. on DRA7 the 2nd dwc3 instance
doesn't use usb3_phy.
This needs to be a valid case and driver shouldn't error out.
So, i think adding flexibility to DWC3 to have either
usb2-phy/usb3-phy or both of them seems to be valid point.
Any suggestions ?
For high speed operation we need only usb2_phy but for super speed we need
both usb2_phy
and usb3_phy.
Why would a dwc3 controller use only usb3_phy? A USB3.0 interface has to be
compatible with
USB2.0 as well, no?
True and for that reason we need both UTMI+ interface as well as PIPE3
interface, right ?
But as also mentioned in the thread:
https://lkml.org/lkml/2013/9/12/181, on Samsung exynos5
architecturally same block is managing UTMI+ and PIPE3 interfaces,
which is handled by phy-samsung-usb3 driver and denoted by usb3_phy:
usbphy@1210 node in arch/arm/boot/dts/exynos5250.dtsi.
So on exynos5250, DWC3 really needs just usb3-phy, which is compatible
for USB 2.0 as well.
I'm not familiar with exynos5250 dwc3, but looking at the dts file I can see
both usb3_phy
and usb2_phy nodes and both are referenced in the dwc3 node.
The ehci and ohci controllers don't reference any PHY.
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 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
+ } else {
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
usb_phy_set_suspend(dwc-usb2_phy, 0);
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_on(dwc-usb3_generic_phy);
+
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
@@ -576,6 +609,11 @@ static int dwc3_remove(struct platform_device *pdev)
usb_phy_set_suspend(dwc-usb2_phy, 1);
usb_phy_set_suspend(dwc-usb3_phy, 1);
+ if (dwc-usb2_generic_phy)
if (IS_ERR())
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
if (IS_ERR())
here and everywhere else in this patch.
+ phy_power_off(dwc-usb3_generic_phy);
+
pm_runtime_put(pdev-dev);
Re: [PATCH 4/7] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/omap-phy.txt
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Since now we have a separate folder for phy, move the PHY dt binding
documentation of OMAP to that folder.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/{usb/usb-phy.txt = phy/omap-phy.txt}|2
+-
1 file changed, 1 insertion(+), 1 deletion(-)
rename Documentation/devicetree/bindings/{usb/usb-phy.txt =
phy/omap-phy.txt} (96%)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/phy/omap-phy.txt
similarity index 96%
rename from Documentation/devicetree/bindings/usb/usb-phy.txt
rename to Documentation/devicetree/bindings/phy/omap-phy.txt
index 36bdb17..2c485ee 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/omap-phy.txt
ti-phy.txt?
@@ -1,4 +1,4 @@
-USB PHY
+OMAP PHY: DT DOCUMENTATION FOR PHYs in OMAP PLATFORM
TI PHY: PHYs in Texas Instruments SoCs
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 6/7] arm/dts: added dt properties to adapt to the new phy framwork
Hi,
Need some commit log.
cheers,
-roger
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 94abef5..9fe71ff 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -651,7 +651,8 @@
compatible = snps,dwc3;
reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
- usb-phy = usb2_phy, usb3_phy;
+ phys = usb2_phy, usb3_phy;
+ phy-names = usb2-phy, usb3-phy;
tx-fifo-resize;
};
};
@@ -667,6 +668,7 @@
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
ctrl-module = omap_control_usb2phy;
+ #phy-cells = 0;
};
usb3_phy: usb3phy@4a084400 {
@@ -676,6 +678,7 @@
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb3phy;
+ #phy-cells = 0;
};
};
--
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 7/7] drivers: phy: renamed struct omap_control_usb to struct omap_control_phy
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
renamed struct omap_control_usb to struct omap_control_phy since it can
be used to control PHY of USB, SATA and PCIE. Also moved the driver and
include files under *phy* and made the corresponding changes in the users
of phy-omap-control.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/Kconfig| 14 +-
drivers/phy/Makefile |1 +
drivers/{usb = }/phy/phy-omap-control.c | 164
++--
drivers/phy/phy-omap-pipe3.c |8 +-
drivers/phy/phy-omap-usb2.c|8 +-
drivers/usb/musb/omap2430.c|2 +-
drivers/usb/phy/Makefile |1 -
.../omap_control_usb.h = phy/omap_control_phy.h} | 32 ++--
8 files changed, 120 insertions(+), 110 deletions(-)
rename drivers/{usb = }/phy/phy-omap-control.c (55%)
rename include/linux/{usb/omap_control_usb.h = phy/omap_control_phy.h} (69%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5c2e7a0..fd11294 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,12 +15,22 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of this
framework should select this config.
+config OMAP_CONTROL_PHY
+ tristate OMAP CONTROL PHY Driver
+ depends on ARCH_OMAP2PLUS || COMPILE_TEST
+ help
+ Enable this to add support for the PHY part present in the control
+ module. This driver has API to power on the USB2 PHY and to write to
+ the mailbox. The mailbox is present only in omap4 and the register to
+ power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has
+ additional registers to power on PIPE3 PHYs.
+
config OMAP_USB2
tristate OMAP USB2 PHY Driver
depends on ARCH_OMAP2PLUS
select GENERIC_PHY
select USB_PHY
- select OMAP_CONTROL_USB
+ select OMAP_CONTROL_PHY
help
Enable this to support the transceiver that is part of SOC. This
driver takes care of all the PHY functionality apart from comparator.
@@ -30,7 +40,7 @@ config OMAP_USB2
config OMAP_PIPE3
tristate OMAP PIPE3 PHY Driver
select GENERIC_PHY
- select OMAP_CONTROL_USB
+ select OMAP_CONTROL_PHY
help
Enable this to support the PIPE3 PHY that is part of SOC. This
driver takes care of all the PHY functionality apart from comparator.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 48bf9f2..f0127f6 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
+obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_OMAP_PIPE3) += phy-omap-pipe3.o
obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/phy/phy-omap-control.c
similarity index 55%
rename from drivers/usb/phy/phy-omap-control.c
rename to drivers/phy/phy-omap-control.c
index 1a7e19a..ece3573 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -1,5 +1,5 @@
/*
- * omap-control-usb.c - The USB part of control module.
+ * phy-omap-control.c - The USB part of control module.
*
* Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
* This program is free software; you can redistribute it and/or modify
@@ -24,36 +24,36 @@
#include linux/err.h
#include linux/io.h
#include linux/clk.h
-#include linux/usb/omap_control_usb.h
+#include linux/phy/omap_control_phy.h
snip
#ifdef CONFIG_OF
-static const enum omap_control_usb_type omap4_data = OMAP_CTRL_TYPE_OMAP4;
-static const enum omap_control_usb_type usb2_data = OMAP_CTRL_TYPE_USB2;
-static const enum omap_control_usb_type usb3_data = OMAP_CTRL_TYPE_USB3;
-static const enum omap_control_usb_type dra7_data = OMAP_CTRL_TYPE_DRA7;
+static const enum omap_control_phy_type omap4_data = OMAP_CTRL_TYPE_OMAP4;
+static const enum omap_control_phy_type usb2_data = OMAP_CTRL_TYPE_USB2;
+static const enum omap_control_phy_type usb3_data = OMAP_CTRL_TYPE_USB3;
+static const enum omap_control_phy_type dra7_data = OMAP_CTRL_TYPE_DRA7;
-static const struct of_device_id omap_control_usb_id_table[] = {
+static const struct of_device_id omap_control_phy_id_table[] = {
{
.compatible = ti,omap4-control-usb,
.data = omap4_data,
@@ -286,31 +286,31 @@ static const struct of_device_id
omap_control_usb_id_table[] = {
},
{},
};
-MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
+MODULE_DEVICE_TABLE(of, omap_control_phy_id_table);
#endif
-static struct platform_driver omap_control_usb_driver = {
- .probe = omap_control_usb_probe,
Re: commit 5fe212364 causes division by zero with large bauds
On Thu, Sep 12, 2013 at 3:21 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Sep 12, 2013 at 07:37:07AM +0300, Alexey Pelykh wrote:
Actually, here it is, but not formatted properly
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 816d1a2..146e712 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,14 +240,14 @@ serial_omap_baud_is_mode16(struct uart_port
*port, unsigned int baud)
{
unsigned int n13 = port-uartclk / (13 * baud);
unsigned int n16 = port-uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
+ int baudAbsDiff13 = n13 ? (baud - (port-uartclk / (13 * n13))) : INT_MAX;
+ int baudAbsDiff16 = n16 ? (baud - (port-uartclk / (16 * n16))) : INT_MAX;
if(baudAbsDiff13 0)
baudAbsDiff13 = -baudAbsDiff13;
if(baudAbsDiff16 0)
baudAbsDiff16 = -baudAbsDiff16;
- return (baudAbsDiff13 baudAbsDiff16);
+ return (baudAbsDiff13 = baudAbsDiff16);
}
/*
@@ -258,13 +258,13 @@ serial_omap_baud_is_mode16(struct uart_port
*port, unsigned int baud)
static unsigned int
serial_omap_get_divisor(struct uart_port *port, unsigned int baud)
{
- unsigned int divisor;
+ unsigned int mode;
if (!serial_omap_baud_is_mode16(port, baud))
- divisor = 13;
+ mode = 13;
else
- divisor = 16;
- return port-uartclk/(baud * divisor);
+ mode = 16;
+ return port-uartclk/(mode * baud);
}
static void serial_omap_enable_ms(struct uart_port *port)
looks good to me, but I'd split it as suggested as a reply to previous
email.
Well, the fix of baud rate calculation (giving mode-16 priority) is a
simple = instead of .
But indeed, probably commits should be different in terms of their subject.
--
balbi
--
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: Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)
On Thursday 12 September 2013 06:11 PM, Geert Uytterhoeven wrote:
On Tue, Mar 5, 2013 at 10:13 PM, Matt Porter mpor...@ti.com wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_conf_bus_power(host);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
- ret = -ENXIO;
- goto err_irq;
- }
- tx_req = res-start;
+ if (!pdev-dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA TX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ tx_req = res-start;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
- ret = -ENXIO;
- goto err_irq;
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA RX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ rx_req = res-start;
}
- rx_req = res-start;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
Now this is in mainline, I get (gcc 4.1.2):
drivers/mmc/host/omap_hsmmc.c: In function ‘omap_hsmmc_probe’:
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘rx_req’ may be used
uninitialized in this function
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘tx_req’ may be used
uninitialized in this function
Indeed, rx_req and tx_req are not initialized in the DT case.
Initializing them to zero is probably not the right fix. Where are the values
supposed to come from in the DT case?
Hi,
rx_req and tx_req are not used in DT case [1].
dma_request_slave_channel is used to get dma info from mmc dt node.
__dma_request_channel is fallback case for non dt boot.
Note __dma_request_channel is called if dma info is not populated in
dts files.
static inline struct dma_chan
*__dma_request_slave_channel_compat(const dma_cap_mask_t *mask,
dma_filter_fn fn, void *fn_param,
struct device *dev, char *name)
{
struct dma_chan *chan;
chan = dma_request_slave_channel(dev, name);
if (chan)
return chan;
return __dma_request_channel(mask, fn, fn_param);
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: Uninitialized rx_req/tx_req (was: Re: [PATCH v2 2/3] mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case)
On Thursday 12 September 2013 06:11 PM, Geert Uytterhoeven wrote:
On Tue, Mar 5, 2013 at 10:13 PM, Matt Porter mpor...@ti.com wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
MMC driver probe will abort for DT case because of failed
platform_get_resource_byname() lookup. Fix it by skipping resource
byname lookup for device tree build.
Issue is hidden because hwmod popullates the IO resources which
helps to succeed platform_get_resource_byname() and probe.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e79b12d..8ae1225 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1896,21 +1896,23 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_conf_bus_power(host);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA TX channel\n);
- ret = -ENXIO;
- goto err_irq;
- }
- tx_req = res-start;
+ if (!pdev-dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA TX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ tx_req = res-start;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
- if (!res) {
- dev_err(mmc_dev(host-mmc), cannot get DMA RX channel\n);
- ret = -ENXIO;
- goto err_irq;
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
+ if (!res) {
+ dev_err(mmc_dev(host-mmc), cannot get DMA RX
channel\n);
+ ret = -ENXIO;
+ goto err_irq;
+ }
+ rx_req = res-start;
}
- rx_req = res-start;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
Now this is in mainline, I get (gcc 4.1.2):
drivers/mmc/host/omap_hsmmc.c: In function ‘omap_hsmmc_probe’:
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘rx_req’ may be used
uninitialized in this function
drivers/mmc/host/omap_hsmmc.c:1779: warning: ‘tx_req’ may be used
uninitialized in this function
Indeed, rx_req and tx_req are not initialized in the DT case.
Initializing them to zero is probably not the right fix. Where are the values
supposed to come from in the DT case?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] RFC: interrupt consistency check for OF GPIO IRQs
On 09/12/2013 05:37 AM, Alexander Holler wrote: Am 12.09.2013 13:26, schrieb Alexander Holler: Am 12.09.2013 13:09, schrieb Alexander Holler: Am 12.09.2013 12:28, schrieb Alexander Holler: Am 12.09.2013 12:11, schrieb Javier Martinez Canillas: On 09/12/2013 10:55 AM, Alexander Holler wrote: ... So, if I understood the code correctly the DT IRQ core doesn't expect a device node to have more than one interrupt-parent property. The root-cause is the binding definition, not the code. The interrupts property does not contain the phandle of the IRQ controller, but rather the interrupt-parent property does. Thus, there is a single interrupt parent for each node, unless you employ some tricks (see below). It *should* work though if you have multiple interrupts properties defined and all of them have the same interrupt-parent: interrupt-parent = gpio6; interrupts = 1 IRQF_TRIGGER_HIGH; /* GPIO6_1 */ interrupts = 2 IRQF_TRIGGER_LOW; /* GPIO6_2 */ DT is a key/value data structure, not a list of property (name, value) pairs. In other words, you can't have multiple properties of the same name in a node. At least in the compiled DTB; you /might/ be able to compile the DT above with dtc, but if so the second definition of the property will just over-write the first. ... I've just seen how they solved it for dma: dmas = edma0 16 edma0 17; dma-names = rx, tx; ... And looking at how gpios are defined, I think it should be like that: interrupts = gpio6 1 IRQF_TRIGGER_HIGH gpio7 2 IRQF_TRIGGER_LOW ; interrupt-names = foo, bar; So without that interrupt-parent. IRQs, DMA channels, and GPIOs are all different things. Their bindings are defined independently. While it's good to define new types of bindings consistently with other bindings, this hasn't always happened, so you can make zero assumptions about the IRQ bindings by reading the documentation for any other kind of binding. Multiple interrupts are defined as follows: // Optional; otherwise inherited from parent/grand-parent/... interrupt-parent = gpio6; // Must be in a fixed order, unless binding defines that the // optional interrupt-names property is to be used. interrupts = 1 IRQF_TRIGGER_HIGH 2 IRQF_TRIGGER_LOW; // Optional; binding for device defines whether it must // be present interrupt-names = foo, bar; If you need multiple interrupts, each with a different parent, you need to use an interrupt-map property (Google it for a more complete explanation I guess). Unlike interrupts, interrupt-map has a phandle in each entry, and hence each entry can refer to a different IRQ controller. You end up defining a dummy interrupt controller node (which may be the leaf node with multiple IRQ outputs, which then points at itself as the interrupt parent), pointing the leaf node's interrupt-parent at that node, and then having interrupt-map demux the N interrupt outputs to the various interrupt controllers. -- 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: omap DSS fails with tft410 driver panel?
Try adding kernel bootargs, lets say: vram=48M omapfb.vram=0:16M,1:16M,2:16M And see what happens. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] arm: bone: dts: add CD for mmc1
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
None, again a simple repost
Changes since v1:
None, simple repost
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 4
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..ced256c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,11 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +265,12 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..d34469c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -16,7 +16,3 @@
regulator-always-on;
};
-mmc1 {
- status = okay;
- vmmc-supply = ldo3_reg;
-};
--
1.8.2.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
[RFC PATCH 2/4] ARM: DTS: DRA: Add crossbar device binding
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. This models the crossbar as an interrupt
controller. This a cascaded irqchip where the peripheral interrupt
lines are connected to the crossbar and the crossbar's outputs
are in turn connected to the GIC.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..da977e1 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -84,6 +84,7 @@
#size-cells = 1;
ranges;
ti,hwmods = l3_main_1, l3_main_2;
+ interrupt-parent = crossbar_mpu;
counter32k: counter@4ae04000 {
compatible = ti,omap-counter32k;
@@ -491,5 +492,20 @@
dmas = sdma 70, sdma 71;
dma-names = tx0, rx0;
};
+
+ crossbar_mpu: @4a02 {
+ compatible = crossbar-irqchip;
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x4a002a48 0x130;
+ max-crossbar-lines = 512;
+ max-irqs = 160;
+ reg-size = 2;
+ irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ #address-cells = 1;
+ #size-cells = 1;
+ };
+
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. This series models the crossbar IP as a cascaded irqchip controller. The peripheral crossbar inputs are mapped on to the crossbar irq-domain. The driver then allocates a 'free' irq line and maps that to the actual interrupt controller's domain. So every external peripheral interrupt is routed through the crossbar handler. This series adds a crossbar driver and the DT bindings for the same. Also the DT nodes for DRA7xx SOC which has a IRQ crossbar has been added here. Sricharan R (4): DRIVERS: IRQCHIP: Add crossbar irqchip driver ARM: DTS: DRA: Add crossbar device binding ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs. ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx .../devicetree/bindings/arm/omap/irq-crossbar.txt | 39 ++ arch/arm/boot/dts/dra7.dtsi| 104 ++--- arch/arm/mach-omap2/Kconfig|1 + drivers/irqchip/Kconfig|9 + drivers/irqchip/Makefile |1 + drivers/irqchip/irq-crossbar.c | 407 6 files changed, 517 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt create mode 100644 drivers/irqchip/irq-crossbar.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/4] ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx
Enable the crossbar irqchip driver for DRA7xx soc. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8413252..b602168 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_SMP select COMMON_CLK + select IRQCHIP_CROSSBAR comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am 12.09.2013 17:19, schrieb Stephen Warren: IRQs, DMA channels, and GPIOs are all different things. Their bindings are defined independently. While it's good to define new types of bindings consistently with other bindings, this hasn't always happened, so you can make zero assumptions about the IRQ bindings by reading the documentation for any other kind of binding. Multiple interrupts are defined as follows: // Optional; otherwise inherited from parent/grand-parent/... interrupt-parent = gpio6; // Must be in a fixed order, unless binding defines that the // optional interrupt-names property is to be used. interrupts = 1 IRQF_TRIGGER_HIGH 2 IRQF_TRIGGER_LOW; // Optional; binding for device defines whether it must // be present interrupt-names = foo, bar; If you need multiple interrupts, each with a different parent, you need to use an interrupt-map property (Google it for a more complete explanation I guess). Unlike interrupts, interrupt-map has a phandle in each entry, and hence each entry can refer to a different IRQ controller. You end up defining a dummy interrupt controller node (which may be the leaf node with multiple IRQ outputs, which then points at itself as the interrupt parent), pointing the leaf node's interrupt-parent at that node, and then having interrupt-map demux the N interrupt outputs to the various interrupt controllers. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ What a mess. I assume that is the price that bindings don't have to change. Thanks for clarifying that, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] am335x-boneblack: add eMMC DT entry
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
add missing pinmux entries
Changes since v1:
dropped the ti,non-removable entry per Sekhars request
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ced256c..cfec441 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -112,6 +112,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins =
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ ;
+ };
};
ocp {
@@ -241,6 +256,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..f4703cf 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,17 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
1.8.2.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
[RFC PATCH 3/4] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs.
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 88 +--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index da977e1..2c541af 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -104,10 +104,10 @@
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
- interrupts = 0 12 0x4,
-0 13 0x4,
-0 14 0x4,
-0 15 0x4;
+ interrupts = 0 7 0x4,
+0 8 0x4,
+0 9 0x4,
+0 10 0x4;
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
@@ -116,7 +116,7 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
- interrupts = 0 29 0x4;
+ interrupts = 0 24 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -127,7 +127,7 @@
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
reg = 0x48055000 0x200;
- interrupts = 0 30 0x4;
+ interrupts = 0 25 0x4;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -138,7 +138,7 @@
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
reg = 0x48057000 0x200;
- interrupts = 0 31 0x4;
+ interrupts = 0 26 0x4;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -149,7 +149,7 @@
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
reg = 0x48059000 0x200;
- interrupts = 0 32 0x4;
+ interrupts = 0 27 0x4;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -160,7 +160,7 @@
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
reg = 0x4805b000 0x200;
- interrupts = 0 33 0x4;
+ interrupts = 0 28 0x4;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -171,7 +171,7 @@
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
reg = 0x4805d000 0x200;
- interrupts = 0 34 0x4;
+ interrupts = 0 29 0x4;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
@@ -182,7 +182,7 @@
gpio7: gpio@48051000 {
compatible = ti,omap4-gpio;
reg = 0x48051000 0x200;
- interrupts = 0 35 0x4;
+ interrupts = 0 30 0x4;
ti,hwmods = gpio7;
gpio-controller;
#gpio-cells = 2;
@@ -193,7 +193,7 @@
gpio8: gpio@48053000 {
compatible = ti,omap4-gpio;
reg = 0x48053000 0x200;
- interrupts = 0 121 0x4;
+ interrupts = 0 116 0x4;
ti,hwmods = gpio8;
gpio-controller;
#gpio-cells = 2;
@@ -204,7 +204,7 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
reg = 0x4806a000 0x100;
- interrupts = 0 72 0x4;
+ interrupts = 0 67 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
};
@@ -212,7 +212,7 @@
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
reg = 0x4806c000 0x100;
- interrupts = 0 73 0x4;
+ interrupts = 0 68 0x4;
ti,hwmods
[PATCH 4/4] ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers
This matches the vendor 3.8.x configuration that is shipping with the boards.
The LED layout is now:
USR0: heartbeat
USR1: mmc0 (micro-SD slot)
USR2: cpu0
USR3: mmc1 (eMMC)
The cpu0 triggers was put inbetween the mmc triggers to make is easier to see
where the disk activity is.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 80407ff..3057f30 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -203,12 +203,14 @@
led@4 {
label = beaglebone:green:usr2;
gpios = gpio1 23 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = cpu0;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
gpios = gpio1 24 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = mmc1;
default-state = off;
};
};
--
1.8.2.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
[PATCHv3 0/2] ARM: dts: Beaglebone MMC fixes
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 53aafdbc63c9b30c23f562855c8f359c0893bc40 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + 084f262cb1058e00cf082739cf7ee93cb70761c9 ARM: EDMA: Fix clearing of unused list for DT DMA resources + 6080eee0ef0ee3ab235cc267a69a0a7d3673266e ARM: dts: add AM33XX EDMA support + 7312f68fb49202b65498865bd64680c95ec2f7ea ARM: dts: add AM33XX SPI DMA support + 5580c3d400cefad5a1eb3c5a8e467353e22d526e ARM: dts: add AM33XX MMC support and documentation + a11eddaa0a89c24d2b9768a82519ac096bb793f1 arm: bone: dts: add CD for mmc1 + b1e87bfc52775c2666b6c4a89d409193319d33f2 am335x-boneblack: add eMMC DT entry + 090e095b74ba211b2cfbd2c87ae06c52d151453d ARM: am335x-bone-common: switch mmc1 to 4-bit mode + 39f747078f0b01724cfa94ce19fd2e6029ac0bee ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v2: Missing pinmux entries for eMMC added Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernelm=137889435710552w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (3): am335x-boneblack: add eMMC DT entry ARM: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers arch/arm/boot/dts/am335x-bone-common.dtsi | 39 +++ arch/arm/boot/dts/am335x-bone.dts | 4 arch/arm/boot/dts/am335x-boneblack.dts| 14 +++ 3 files changed, 53 insertions(+), 4 deletions(-) -- 1.8.2.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 3/4] ARM: am335x-bone-common: switch mmc1 to 4-bit mode
nitpick minor comment:
$subject: ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode
On 09/12/2013 10:42 AM, Koen Kooi wrote:
The micro-SD slot hooks up all four data pins so lets' use them.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index cfec441..80407ff 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -290,6 +290,7 @@
mmc1 {
status = okay;
+ bus-width = 0x4;
vmmc-supply = ldo3_reg;
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: bone: dts: add CD for mmc1
nitpick minor comment:
$subject: ARM: dts: am335x-bone: add card detect for mmc1
btw, please use V3 in $subject next time. --subject-prefix PATCH V3
when generating patch should do the job.
On 09/12/2013 10:42 AM, Koen Kooi wrote:
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
None, again a simple repost
Changes since v1:
None, simple repost
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 4
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..ced256c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,11 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
An EOL here would be nice to separate the nodes.
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +265,12 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..d34469c 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -16,7 +16,3 @@
regulator-always-on;
};
-mmc1 {
- status = okay;
- vmmc-supply = ldo3_reg;
-};
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] am335x-boneblack: add eMMC DT entry
Nitpick minor comment:
$subject:
ARM: dts: am335x-boneblack: add eMMC DT entry
On 09/12/2013 10:42 AM, Koen Kooi wrote:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Also might want to state that vmmcsd_fixed 3.3 voltage rail is present
in BeagleBone White and Black, however used for emmc in bone-black.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
Changes since v2:
add missing pinmux entries
Changes since v1:
dropped the ti,non-removable entry per Sekhars request
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ced256c..cfec441 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -112,6 +112,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins =
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ ;
+ };
};
ocp {
@@ -241,6 +256,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..f4703cf 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,17 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers
On 09/12/2013 10:42 AM, Koen Kooi wrote:
This matches the vendor 3.8.x configuration that is shipping with the boards.
The LED layout is now:
USR0: heartbeat
USR1: mmc0 (micro-SD slot)
USR2: cpu0
USR3: mmc1 (eMMC)
The cpu0 triggers was put inbetween the mmc triggers to make is easier to see
nitpick: sinbetween/in between/
where the disk activity is.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 80407ff..3057f30 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -203,12 +203,14 @@
led@4 {
label = beaglebone:green:usr2;
gpios = gpio1 23 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = cpu0;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
gpios = gpio1 24 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = mmc1;
default-state = off;
};
};
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: am335x-bone-common: switch mmc1 to 4-bit mode
The micro-SD slot hooks up all four data pins so lets' use them.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index cfec441..80407ff 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -290,6 +290,7 @@
mmc1 {
status = okay;
+ bus-width = 0x4;
vmmc-supply = ldo3_reg;
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
--
1.8.2.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
[RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
This models the crossbar IP as a cascaded irqchip controller.
The peripheral crossbar inputs are mapped on to the crossbar irq-domain.
The driver then allocates a 'free' irq line and maps that to the
actual interrupt controller's domain. So every external peripheral interrupt
is routed through the crossbar handler.
GIC - CROSSBAR - PERIPHERAL INTERRUPT LINES
peripheral's irq_of_parse_and_map()
|
|
crossbar_xlate()
|
|
saves the interrupt properties passed
peripheral's request_irq(crossbar_number)
|
|
crossbar_request_irq
|
|
allocates free irq and maps it to parent domain
|
|
request_irq(mapped interrupt number)
gic_interrupt_hanadler
|
|
crossbar_irq(interrupt number)
|
|
get crossbar number from interrupt number
|
|
handle_irq(crossbar_domain(crossbar number))
The irqchip callback hooks added here are just a redirection to the
parent irqchip.
This adds a extra translation in the fast path. The maximum increase in
the average interrupt latency due to the same was measured as around 1.63us
on a cpu running at 1GHZ.
cat /proc/interrupts looks like this, with both crossbar and interrupt number
CPU0 CPU1
45:267 0 GIC OMAP UART0
205:267 0 CROSSBAR OMAP UART0
Cc: Thomas Gleixner t...@linutronix.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
There is lockdep warning during the boot. This is because we try to
do one request_irq with in another and that results in kmalloc being
called from an atomic context, which generates the warning.
Any suggestions to overcome this will help.
WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xe8/0x108()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
.../devicetree/bindings/arm/omap/irq-crossbar.txt | 39 ++
drivers/irqchip/Kconfig|9 +
drivers/irqchip/Makefile |1 +
drivers/irqchip/irq-crossbar.c | 407
4 files changed, 456 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
create mode 100644 drivers/irqchip/irq-crossbar.c
diff --git a/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
new file mode 100644
index 000..5d465cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
@@ -0,0 +1,39 @@
+* IRQ CROSSBAR
+
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be irq-crossbar
+- interrupt-parent: phandle to crossbar's interrupt parent.
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupt-cells: Should be the same value as the interrupt parent.
+- reg: Base address and the size of the crossbar registers.
+- max-crossbar-lines: Total number of input lines of the crossbar.
+- max-irqs: Total number of irqs available at the interrupt controller.
+- reg-size: size of the crossbar registers.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+crossbar. These interrupt lines are reserved in the soc,
+so crossbar bar driver should not consider them as free
+lines.
+
+Examples:
+ crossbar_mpu: @4a02 {
+ compatible = irq-crossbar;
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x4a002a48 0x130;
+ max-crossbar-lines = 512;
+ max-irqs = 160;
+ reg-size = 2;
+ irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
+ #address-cells = 1;
+
[PATCH v4 0/2] ARM: dts: Beaglebone MMC fixes
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v3: Addressed Nishants nitpicks for commit messages Addressed Russ' comments about moving LDO3 for mmc1 out of the common dtsi Changes since v2: Missing pinmux entries for eMMC added Changes since v1: Removed ti,non-removable entry from eMMC node, see http://marc.info/?l=linux-arm-kernelm=137889435710552w=2 --- Alexander Holler (1): arm: bone: dts: add CD for mmc1 Koen Kooi (3): am335x-boneblack: add eMMC DT entry ARM: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers arch/arm/boot/dts/am335x-bone-common.dtsi | 39 +++ arch/arm/boot/dts/am335x-bone.dts | 1 - arch/arm/boot/dts/am335x-boneblack.dts| 14 +++ 3 files changed, 53 insertions(+), 1 deletion(-) -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] ARM: dts: am335x-bone: add CD for mmc1
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 1 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..0d95d54 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,12 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +266,11 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..0d63348 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -17,6 +17,5 @@
};
mmc1 {
- status = okay;
vmmc-supply = ldo3_reg;
};
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers
This matches the vendor 3.8.x configuration that is shipping with the boards.
The LED layout is now:
USR0: heartbeat
USR1: mmc0 (micro-SD slot)
USR2: cpu0
USR3: mmc1 (eMMC)
The cpu0 triggers was put in between the mmc triggers to make is easier to see
where the disk activity is.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 303df81..adce9fe 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -204,12 +204,14 @@
led@4 {
label = beaglebone:green:usr2;
gpios = gpio1 23 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = cpu0;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
gpios = gpio1 24 GPIO_ACTIVE_HIGH;
+ linux,default-trigger = mmc1;
default-state = off;
};
};
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode
The micro-SD slot hooks up all four data pins so lets' use them.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bc8d1a2..303df81 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -291,6 +291,7 @@
mmc1 {
status = okay;
+ bus-width = 0x4;
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
--
1.8.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] ARM: dts: am335x-boneblack: add eMMC DT entry
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22 ++
arch/arm/boot/dts/am335x-boneblack.dts| 14 ++
2 files changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 0d95d54..bc8d1a2 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -113,6 +113,21 @@
0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
;
};
+
+ emmc_pins: pinmux_emmc_pins {
+ pinctrl-single,pins =
+ 0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk, INPUT_PULLUP | MODE2 */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd, INPUT_PULLUP | MODE2 */
+ 0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0, INPUT_PULLUP | MODE1 */
+ 0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1, INPUT_PULLUP | MODE1 */
+ 0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2, INPUT_PULLUP | MODE1 */
+ 0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad3.mmc1_dat3, INPUT_PULLUP | MODE1 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad4.mmc1_dat4, INPUT_PULLUP | MODE1 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad5.mmc1_dat5, INPUT_PULLUP | MODE1 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad6.mmc1_dat6, INPUT_PULLUP | MODE1 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad7.mmc1_dat7, INPUT_PULLUP | MODE1 */
+ ;
+ };
};
ocp {
@@ -242,6 +257,13 @@
regulator-always-on;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
cpsw_emac0 {
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 197cadf..f4703cf 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -15,3 +15,17 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+mmc1 {
+ vmmc-supply = vmmcsd_fixed;
+};
+
+mmc2 {
+ vmmc-supply = vmmcsd_fixed;
+ pinctrl-names = default;
+ pinctrl-0 = emmc_pins;
+ bus-width = 8;
+ status = okay;
+ ti,vcc-aux-disable-is-sleep;
+};
+
--
1.8.2.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 v4 0/2] ARM: dts: Beaglebone MMC fixes
On 09/12/2013 01:35 PM, Koen Kooi wrote: Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline Changes since v3: Addressed Nishants nitpicks for commit messages Series: Reviewed-by: Nishanth Menon n...@ti.com -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Sricharan R wrote: Signed-off-by: Sricharan R r.sricha...@ti.com --- There is lockdep warning during the boot. This is because we try to do one request_irq with in another and that results in kmalloc being called from an atomic context, which generates the warning. Any suggestions to overcome this will help. You can't be serious about that. You post a patch series with a serious bug in it instead of asking in the first place how to solve the problem at hand. So why do you actually need to call request_irq() from inside request_irq() and how do you actually manage to do that at all? I have a hard time to figure out how request_irq() might call itself recursive. And I have no intention to look at your patch to figure out that you abuse an irq chip callback to do so, simply because that would force me to use abusive language which is frowned upon nowadays. Can you please explain what you are trying to solve without referring to your existing broken implementation. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Thomas, On Thursday 12 September 2013 04:18 PM, Thomas Gleixner wrote: On Thu, 12 Sep 2013, Sricharan R wrote: Signed-off-by: Sricharan R r.sricha...@ti.com --- There is lockdep warning during the boot. This is because we try to do one request_irq with in another and that results in kmalloc being called from an atomic context, which generates the warning. Any suggestions to overcome this will help. You can't be serious about that. You post a patch series with a serious bug in it instead of asking in the first place how to solve the problem at hand. So why do you actually need to call request_irq() from inside request_irq() and how do you actually manage to do that at all? I have a hard time to figure out how request_irq() might call itself recursive. And I have no intention to look at your patch to figure out that you abuse an irq chip callback to do so, simply because that would force me to use abusive language which is frowned upon nowadays. This is an outcome of the discussion on earlier patch set [1] which tried to add IRQ event router functionality. From beginning I was against the idea because I also felt that we are abusing the irqchip infrastructure and force fitting the cross-bar to be behave like an irqchip. But Linus W and few others strongly felt it to make it an irqchip implementation. Can you please explain what you are trying to solve without referring to your existing broken implementation. I will try to summaries the IP and its need here. On TI SOCs, we have an IP cross-bar which is essentially an even router(hardware). It can route the IRQ and DMA in existing implementation. Specifically for the IRQ case addressed here, the cross-bar IP sits between the interrupt controller and peripheral interrupts. CPU -- GIC - CROSSBAR - PERIPHERAL IRQs Just to expand it better, cross-bar input IRQ lines are more than what a GIC IRQ controller can support. e.q Total 250 peripheral IRQ lines out of which GIC support only 160 IRQ lines. So the idea here is to dynamically map the IRQ lines at cross-bar level to pick based on request_irq() so that one can optimize the use of limited IRQ lines at the GIC level. Strictly speaking the need is just establish the IRQ connection from peripheral to GIC and thats achieved at the request_irq() level. Earlier approach was to statically build this connections using the DT information in a separate driver probe but it had limitations of fixing the IRQ map and taking away flexibility what this IP provide. Hope this gives better picture to you behind the patch series. Just for others to know, use of IRQCHIP also forced to have all the irqchip handler redirection which is pure redirection including the irq-handler. And since it is *fast path* I asked Sricharan to measure the latency which is around ~2 uS( 1GHz CPU) overhead for every interrupt just because of redirections. Regards, Santosh [1] https://lkml.org/lkml/2013/7/18/362 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq = cb-crossbar_map[cb_no].hwirq;
+ int err;
+
+ err = request_threaded_irq(virq, crossbar_irq, NULL,
+0, CROSSBAR, irq);
this is wrong, why don't you just set crossbar up as a chained handler.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Felipe Balbi wrote:
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq = cb-crossbar_map[cb_no].hwirq;
+ int err;
+
+ err = request_threaded_irq(virq, crossbar_irq, NULL,
+ 0, CROSSBAR, irq);
this is wrong, why don't you just set crossbar up as a chained handler.
That's just a detail, which does not solve the underlying problem of
the crossbar - GIC mapping.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Felipe Balbi wrote:
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq = cb-crossbar_map[cb_no].hwirq;
+ int err;
+
+ err = request_threaded_irq(virq, crossbar_irq, NULL,
+0, CROSSBAR, irq);
this is wrong, why don't you just set crossbar up as a chained handler.
That's just a detail, which does not solve the underlying problem of
the crossbar - GIC mapping.
And actually the thing is the other way round:
GIC distributes to crossbar, so the underlying GIC irq would be the
chained handler.
Still does not solve the setup/request_irq issue.
Thanks,
tglx
--
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 0/2] ARM: dts: Beaglebone MMC fixes
Koen Kooi k...@dominion.thruhere.net writes: Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW, the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1 gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned. This series depends on: http://comments.gmane.org/gmane.linux.kernel.stable/63648 https://lkml.org/lkml/2013/9/10/454 http://comments.gmane.org/gmane.linux.kernel.mmc/22381 Or as git-cherry would put it: [koen@rrMBP patches]$ git cherry -v + 564fc88cc64387af5312e2abd8019c75a13223b2 ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black + e5133ed98acc1c3e01c370b851041a8ca629cd15 ARM: EDMA: Fix clearing of unused list for DT DMA resources + ac71bb58605d3bdd5d14af770a639fb3ff11c612 ARM: dts: add AM33XX EDMA support + 31a8270a299c57c7de7510f44d9dc36fd1787243 ARM: dts: add AM33XX SPI DMA support + 4fa0a4cb9ea17da30cf43085c03e5ec1361a4fc2 ARM: dts: add AM33XX MMC support and documentation + 0553f50bd45f019a0cc11050e2f20bddbf07dfe0 ARM: dts: am335x-bone: add CD for mmc1 + 7d64f765630a2921a63b82f93f9959a6de37f29d ARM: dts: am335x-boneblack: add eMMC DT entry + dc96cd4003e2668d8ec7e7fe19e402e97a198f81 ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode + f8262e78830cda56c936724549ba9f04e312 ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Also available as a git branch at https://github.com/koenkooi/linux/commits/mainline FWIW, tested this branch on BB black/white with MMC rootfs. Tested-by: Kevin Hilman khil...@linaro.org Koen, Thanks for your persistence getting this stuff merged. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Santosh Shilimkar wrote: Specifically for the IRQ case addressed here, the cross-bar IP sits between the interrupt controller and peripheral interrupts. CPU -- GIC - CROSSBAR - PERIPHERAL IRQs Just to expand it better, cross-bar input IRQ lines are more than what a GIC IRQ controller can support. e.q Total 250 peripheral IRQ lines out of which GIC support only 160 IRQ lines. So the idea here is to dynamically map the IRQ lines at cross-bar level to pick based on request_irq() so that one can optimize the use of limited IRQ lines at the GIC level. Strictly speaking the need is just establish the IRQ connection from peripheral to GIC and thats achieved at the request_irq() level. Earlier approach was to statically build this connections using the DT information in a separate driver probe but it had limitations of fixing the IRQ map and taking away flexibility what this IP provide. Hope this gives better picture to you behind the patch series. Yes. I halfways understand what you are trying to achieve. So CROSSBAR is a routing block between the peripheral and the GIC in order to expand the number of possible interrupts. Now the real question is, how that expansion mechanism is supposed to work. There are two possible scenarios: 1) Expand the number of handled interrupts beyond the GIC capacity: That requires a mechanism in CROSSBAR to map several CROSSBAR interrupts to a particular GIC interrupt and provide a demux mechanism to invoke the shared handlers. 2) Provide a mapping mechanism between possibly 250 interrupt numbers and a limitation of a total 160 active interrupts by the underlying GIC. What are you trying to achieve? Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote: On Thu, 12 Sep 2013, Santosh Shilimkar wrote: Specifically for the IRQ case addressed here, the cross-bar IP sits between the interrupt controller and peripheral interrupts. CPU -- GIC - CROSSBAR - PERIPHERAL IRQs Just to expand it better, cross-bar input IRQ lines are more than what a GIC IRQ controller can support. e.q Total 250 peripheral IRQ lines out of which GIC support only 160 IRQ lines. So the idea here is to dynamically map the IRQ lines at cross-bar level to pick based on request_irq() so that one can optimize the use of limited IRQ lines at the GIC level. Strictly speaking the need is just establish the IRQ connection from peripheral to GIC and thats achieved at the request_irq() level. Earlier approach was to statically build this connections using the DT information in a separate driver probe but it had limitations of fixing the IRQ map and taking away flexibility what this IP provide. Hope this gives better picture to you behind the patch series. Yes. I halfways understand what you are trying to achieve. So CROSSBAR is a routing block between the peripheral and the GIC in order to expand the number of possible interrupts. Now the real question is, how that expansion mechanism is supposed to work. There are two possible scenarios: 1) Expand the number of handled interrupts beyond the GIC capacity: That requires a mechanism in CROSSBAR to map several CROSSBAR interrupts to a particular GIC interrupt and provide a demux mechanism to invoke the shared handlers. This is not possible in hardware and not supported. Hardware has no notion of muxing multiple IRQ's to generate 1 IRQ or ack etc functionality. Its a simple MUX to tie knots between input and output wires. 2) Provide a mapping mechanism between possibly 250 interrupt numbers and a limitation of a total 160 active interrupts by the underlying GIC. This is the need and problem we are trying to solve. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thu, 12 Sep 2013, Santosh Shilimkar wrote: On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote: Now the real question is, how that expansion mechanism is supposed to work. There are two possible scenarios: 1) Expand the number of handled interrupts beyond the GIC capacity: That requires a mechanism in CROSSBAR to map several CROSSBAR interrupts to a particular GIC interrupt and provide a demux mechanism to invoke the shared handlers. This is not possible in hardware and not supported. Hardware has no notion of muxing multiple IRQ's to generate 1 IRQ or ack etc functionality. Its a simple MUX to tie knots between input and output wires. It's not a MUX. It's a ROUTING mechanism. That's similar to the mechanisms which are used by MSI[X]. We assign arbitrary interrupt numbers to a device and route them to some underlying limited hardware interrupt controller. 2) Provide a mapping mechanism between possibly 250 interrupt numbers and a limitation of a total 160 active interrupts by the underlying GIC. This is the need and problem we are trying to solve. Let me summarize: - GIC supports up to 160 interrupts - CROSSBAR supports up to 250 interrupts - CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones - Drivers request a CROSSBAR interrupt number which must be mapped to some arbitrary available GIC irq number So basically the CROSSBAR mechanism is pretty much the same as MSI[X] just in a different flavour and with a different set of semantics and limitations, i.e. poor mans MSI[X] with a new level of bogosity. So if CROSSBAR is going to be the new fangled SoC MSI[X] long term equivalent then you better provide some infrastructure for that and make the drivers ready to use it. Maybe check with the PCI/MSI folks to share some of the interfaces. If that whole thing is another onetime HW designers wet dream, then please go back to the limited but completely functional (Who is going to use more than 160 peripheral interrupts) device tree model. I really have no interest to support hardware designer brain farts. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote: On Thu, 12 Sep 2013, Santosh Shilimkar wrote: On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote: Now the real question is, how that expansion mechanism is supposed to work. There are two possible scenarios: 1) Expand the number of handled interrupts beyond the GIC capacity: That requires a mechanism in CROSSBAR to map several CROSSBAR interrupts to a particular GIC interrupt and provide a demux mechanism to invoke the shared handlers. This is not possible in hardware and not supported. Hardware has no notion of muxing multiple IRQ's to generate 1 IRQ or ack etc functionality. Its a simple MUX to tie knots between input and output wires. It's not a MUX. It's a ROUTING mechanism. That's similar to the mechanisms which are used by MSI[X]. We assign arbitrary interrupt numbers to a device and route them to some underlying limited hardware interrupt controller. 2) Provide a mapping mechanism between possibly 250 interrupt numbers and a limitation of a total 160 active interrupts by the underlying GIC. This is the need and problem we are trying to solve. Let me summarize: - GIC supports up to 160 interrupts - CROSSBAR supports up to 250 interrupts - CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones - Drivers request a CROSSBAR interrupt number which must be mapped to some arbitrary available GIC irq number Correct. So basically the CROSSBAR mechanism is pretty much the same as MSI[X] just in a different flavour and with a different set of semantics and limitations, i.e. poor mans MSI[X] with a new level of bogosity. So if CROSSBAR is going to be the new fangled SoC MSI[X] long term equivalent then you better provide some infrastructure for that and make the drivers ready to use it. Maybe check with the PCI/MSI folks to share some of the interfaces. If that whole thing is another onetime HW designers wet dream, then please go back to the limited but completely functional (Who is going to use more than 160 peripheral interrupts) device tree model. I really have no interest to support hardware designer brain farts. Thanks for clear NAK for irqchip approach. I should have looped you in the discussion where I was also suggesting against the irqchip approach. We will try to look at MSI stuff but if its get too complicated am going to fall-back to the initial probe based approach to achieve the functionality. Thanks again for clear direction and useful discussion. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
