Re: [RFC 00/22] OMAPDSS: DT support
* Tomi Valkeinen tomi.valkei...@ti.com [130830 02:55]: On 13/08/13 10:54, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130809 01:46]: So as is evident, I have things in my mind that should be improved. Maybe the most important question for short term future is: Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us some proper testing of the related code, and would also allow us to remove the related hacks (which don't even work quite right). However, I have no idea yet when the unstable DSS bindings would turn stable. If we shouldn't add the bindings as unstable, when should the bindings be added? Wait until CDF is in the mainline, and use that? I don't think we should add any temporary bindings as it's going to be a pain to support those in the long run. I suggest you initially just stick to established bindings for the basic hardware IO address and interrupts etc, then those should still be valid with the generic panel bindings later on. I don't understand what does it matter if the bindings are temporary, or basic established bindings. In both cases the DT data needs to be changed when the CDF is taken into use. Yes but the old bindings still need to be supported because people are doing devices using those. So any kind of temporary binding will be a pain to support. Well, one difference is that the temporary bindings would give us working display, but having only basic bindings would not. So I don't see any reason to add only the basic bindings. Or how would it work? You might be able to use just a minimal binding for now using the basic reg, interrupt and entries for the various components. Those will be still valid when the CDF bindings are available. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/22] OMAPDSS: DT support
On 02/09/13 09:15, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130830 02:55]: On 13/08/13 10:54, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [130809 01:46]: So as is evident, I have things in my mind that should be improved. Maybe the most important question for short term future is: Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us some proper testing of the related code, and would also allow us to remove the related hacks (which don't even work quite right). However, I have no idea yet when the unstable DSS bindings would turn stable. If we shouldn't add the bindings as unstable, when should the bindings be added? Wait until CDF is in the mainline, and use that? I don't think we should add any temporary bindings as it's going to be a pain to support those in the long run. I suggest you initially just stick to established bindings for the basic hardware IO address and interrupts etc, then those should still be valid with the generic panel bindings later on. I don't understand what does it matter if the bindings are temporary, or basic established bindings. In both cases the DT data needs to be changed when the CDF is taken into use. Yes but the old bindings still need to be supported because people are doing devices using those. So any kind of temporary binding will be a pain to support. If old bindings need to be supported, then we also need to support the current state for Panda and SDP, i.e. there are no DSS related DT bindings, but displays still work. Which means we'll have to keep the current hacky DSS device construction mechanism for Panda and SDP. Although maybe it's cleaner to somehow inject the DSS DT nodes for Panda and SDP in case they are missing from the real DT data. Doesn't supporting old bindings also mean that we can never get rid of the hwmods? Or will there be code that injects the missing interrupt etc. entries? Well, one difference is that the temporary bindings would give us working display, but having only basic bindings would not. So I don't see any reason to add only the basic bindings. Or how would it work? You might be able to use just a minimal binding for now using the basic reg, interrupt and entries for the various components. Those will be still valid when the CDF bindings are available. Well, the entries will be valid, but the displays won't work with just the basic bindings. I could perhaps add a new hack that creates the required panel devices and video pipeline connections dynamically in code for Panda and SDP, a bit like what the code does now, except the basic DSS entries would be in the DT. But that would just add another set of DT data that I would need to support in the future, and there would be three different cases to support for Panda and SDP: - DT data with no DSS related nodes - DT data with basic DSS related nodes - DT data with full DSS So... If old bindings have to be supported, I'd rather try to minimize the pain, and not add anything but the final bindings. In retrospect, it was a bit of a mistake to add the hacky DT display support for Panda and SDP, as it won't be very nice to keep supporting those. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 0/3] cleanup of gpio_pcf857x.c
Hi Sorry for my many response. This patch series - removes the irq_demux_work - Uses devm_request_threaded_irq - Call the user handler iff gpio_to_irq is done. v1 -- v2 Split v1 to 3 patches v2 -- v3 Remove the unnecessary dts patches. George Cherian (3): gpio: pcf857x: change to devm_request_threaded_irq gpio: pcf857x: remove the irq_demux_work gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done drivers/gpio/gpio-pcf857x.c | 51 +++-- 1 file changed, 26 insertions(+), 25 deletions(-) Basically, I have no objection about these patches, but I have 2 opinions - I guess we can merge #1 and #2 patches ? (as is is very OK for me though) - we don't need gpio-irq any more ? (additional patch is very OK for me) Best regards --- Kuninori Morimoto -- 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: omap4 ehci sporadic resume issue
Hi Michael, On 08/30/2013 08:59 PM, Michael Trimarchi wrote: Hi Roger On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi mich...@amarulasolutions.com wrote: Hi On 07/02/2013 05:03 PM, Roger Quadros wrote: On 07/02/2013 05:49 PM, Michael Trimarchi wrote: Hi Roger On 07/02/2013 04:42 PM, Roger Quadros wrote: On 06/28/2013 07:47 PM, Michael Trimarchi wrote: Hi I'm working on PM consumption of other subsystem because it's a very complex device. Right now the pm consumption is sleep mode is 6mA just for (off mode disabled) omap4 + LPDDR2 and TWL6032 I don't exactly know if they have updated the last bootloader but I think so. I have tried to work on STP signal and re-enable it just before resume but nothing change Anyway my idea is the problem is releated on 18clk counter and an invalid state of the hw. I will try to implement save restore register by hand instead using the sar. There are 2 erratas related to the issues you mentioned. i693 - USB HOST EHCI - Port Resume Fails On Second Resume Iteration i719 - HS USB: Multiple OFF Mode Transitions Introduce Corruption cheers, -roger Michael When you said earlier that the problem doesn't happen when one of the ULPIs is used did you try both of them individually. e.g. case 1: port 1 only enabled, case 2: port 2 only enabled. Did it work in both the cases? Yes, so I don't think could be a problem of ulpi pins and why this happen on both at the same time? Seems more connected to somenthing else. Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline. Yes, our aim is to get it working with mainline as well. Last question: If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode? SAR restore will only happen when the Device enters OFF mode. Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter 3.9.3 Device OFF State Management in the TRM. What happen if we ask to go in off mode for all domains but one doesn't go in off mode so the device will not go in off mode and the sar will not be used? How can work the restore? I have added a check of CM_RESTORE_ST. This register need to be clear before going in OFF mode and then show if the status of phase1 2a and 2b is completed. So before proceed with system resume and after resetting OFF_MODE bit I have tried to wait on this register, but without success. Michael 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 v3 0/3] cleanup of gpio_pcf857x.c
On 9/2/2013 12:25 PM, Kuninori Morimoto wrote: Hi Sorry for my many response. No Issues. and thanks for the review. This patch series - removes the irq_demux_work - Uses devm_request_threaded_irq - Call the user handler iff gpio_to_irq is done. v1 -- v2 Split v1 to 3 patches v2 -- v3 Remove the unnecessary dts patches. George Cherian (3): gpio: pcf857x: change to devm_request_threaded_irq gpio: pcf857x: remove the irq_demux_work gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done drivers/gpio/gpio-pcf857x.c | 51 +++-- 1 file changed, 26 insertions(+), 25 deletions(-) Basically, I have no objection about these patches, but I have 2 opinions - I guess we can merge #1 and #2 patches ? (as is is very OK for me though) - we don't need gpio-irq any more ? (additional patch is very OK for me) I will sent one patch removing gpio-irq too. Best regards --- Kuninori Morimoto -- -George -- 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 00/22] OMAPDSS: DT support
On 22/08/13 00:07, Laurent Pinchart wrote: Thanks for the comments! The exception to the above are DSI and DBI. DSI and DBI are combined control and video busses, but the use of the busses for control purposes is not independent of the video stream. Also, the the busses are, in practice, one-to-one links. And last, DSI and DBI display entities are often also controllable via, say, i2c. For these reasons there is no real Linux bus for DSI and DBI and thus the DSI and DBI devices are either platform devices or i2c devices. That's something I'm less convinced about, but I don't have a too strong feeling. The best implementation should get to mainline, I won't nack this architecture just for theoretical reasons. Ok. I posted a response to your DBI bus patch about the issues I see. DSI Module ID = On OMAP4 we have two DSI modules. To configure the clock routing and pin muxing, we need to know the hardware module ID for the DSI device, i.e. is this Linux platform device DSI1 or DSI2. The same issue exists with other SoCs with multiple outputs of the same kind. With non-DT case, we used the platform device's ID directly. With DT, that doesn't work. I don't currently have a good solution for this, so as a temporary solution the DSI driver contains a table, from which it can find the HW module ID by using the device's base address. You could add two output ports to the DSS, one for each DSI, and link the DSI modules to the DSS output ports in DT. That would represent the hardware topology, and would allow the DSI driver to know its ID based on the DSS output port it's connected to. It's still a bit hackish in the sense that the DSI driver will use information provided by the DSS (the output port number), but not more than the current method. Hmm, yep. That's kind of the same as having an explicit 'module-id' property in the DSI node. I had implemented that solution at some point, but considered it too ugly. But I agree that deducing the module-id from the DSS output port is a bit cleaner, as it doesn't need any special properties. And it's maybe also better than the address table I have now, as the address table requires special code for each SoC. I have to try the V4L2 ports to understand fully how to use them. In the end, I hope to get rid of the module-id totally. It's really not a DSI-thing at all. The DSI hardware does not use the module-id for anything, it's more about how the DSI module is glued in the DSS/SoC. I have some ideas how to deduce the DSS version by poking to certain DSS registers, but it is not yet tested so I don't know if it will work. That might be a stupid question, but can't you just encode the version in the compatible string of the DSS DT node (the one currently compatible with ti,omap[34]-dss) ? That would require having separate DT files for each revision. For example, we have Beagle boards with different OMAP reversions. It's fine to have the version encoded in the compatible string for major versions, but having all minor revisions encoded there could result in a mess. Version information might also need to be split/duplicated in several of the DSS DT nodes. A quick grep through the driver source code shows that the version is used by the submodules to infer SoC glue information. For instance dsi_get_channel() uses the version to find the DSI module channel ID. That information could possibly be retrieved from the links between the DSS DT nodes. Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3, TV (depending on the SoC). These outputs go to encoders, and the routing can be configured. If we consider only DSI encoders on OMAP4, the LCD2 output can be configured to go to DSI1 or DSI2 modules. LCD1 output can be configured to go to DSI1 (but not to DSI2). Because the routing has restrictions like mentioned above, it's somewhat difficult to allocate the DISPC output channels during runtime in a totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1, and later we'd want to use DSI2, there would be no DISPC output to use. That's why we currently have them hardcoded in the driver, and it works ok in all the use cases we have now. However, some board could need to setup the channels in some other way for some particular use case. So, I'm not totally comfortable with hardcoding the DISPC output - DSS encoder connections in the DT data. While it'd work for most cases, it doesn't work for all. Then again, if the connections in the DT data would be considered more like a default set of connections, and they could be changed later from the kernel/userspace, then it'd be fine. Some of the DSS modules are actually a combination of multiple smaller modules. For example, the DSI module contains DSI protocol, DSI PHY and DSI PLL modules, each in their own address space. These could perhaps be presented as separate DT nodes and Linux devices, but I am not sure if that is a
Re: [PATCH v4 3/6] ARM: edma: Add function to manually trigger an EDMA channel
On 8/30/2013 4:35 AM, Joel Fernandes wrote: Manual trigger for events missed as a result of splitting a scatter gather list and DMA'ing it in batches. Add a helper function to trigger a channel incase any such events are missed. Signed-off-by: Joel Fernandes jo...@ti.com Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Hi,
This is an attempt to achieve reset on AM43x/AM335x based SoC's with
reset driver making use of the reset framework.
prcm node is added in device tree, which would hold reset bindings.
Initially node was made as a one that represents reset functionality
of SoC. but ended up with node for prcm (which is felt to be natural
choice) instead. I am a bit doubtful whether placement of prcm node in
root node as in this series is the right thing.
Reset driver gets probed for specific prcm node, the same defines
register details to be used for a particular SoC (using .data field
associated with .compatible in driver match table).
Another option to handle different SoC's would be to add register
details to DT and let the driver extract it from DT. I vaguely
remember seeing a thread mentioning that putting register details in
DT is not preferred. But open to putting register level details
instead in DT if that is being generally preferred. This would have
advantage that adding reset support for a new SoC would be easier, but
would have to put more thought before doing so as DT bindings should
not change.
With the approach taken here, for supporting a new SoC with new prcm
register details, driver would have to be updated much like the way a
pci based ethernet driver would have to be updated to handle a new IP
version that is not register level compatible with the existing ones.
In this series out of the three IP's (gfx, m3, pruss) that would need
reset support, here as a proof of concept only gfx is taken care.
Other's can be easily supported by adding new register data array
entries.
Two new reset API's are provided to check whether reset is ready and
to clear reset. This would be required in case IP needs to mix reset
handling procedure with power/clock managment procedure to achieve
proper reset and these procedures are sometimes IP specific that would
make it difficult to handle reset fully in pm_runtime platform support.
*--*
client IP handling s/w (DT based) should do as follows:
1. Specify reset handle in the relevant DT node, for eg.
myip@deadbeef {
:
:
/* here prcm is the handle to reset binding node */
resets = prcm 0;
};
2. In driver, that require reset to be deasserted,
(this is the sequence required for gfx on AM43x/AM335x, this would
depend on requirements of the IP)
mydriver_probe(struct platform device *pdev)
{
:
:
reset_control_get(pdev-dev, NULL);
reset_control_clear_reset();
reset_control_deassert();
pm_runtime_get_sync();
if (reset_control_is_reset() != true)
goto err;
reset_control_put();
:
:
}
*--*
May be removing reset handling in hwmod can be considered by making
use of reset driver.
Or as another extreme, perhaps, other logic's in the prcm can be
handled by a new prcm driver and then this reset driver can be a child
of it.
Regards
Afzal
Afzal Mohammed (6):
reset: is_reset and clear_reset api's
doc: dt: binding: omap: am43x/am335x prcm reset
reset: am43x/am335x support
ARM: OMAP2+: AM43x/AM335x: have reset controller
ARM: dts: AM335x: prcm node (for reset)
ARM: dts: AM4372: prcm node (for reset)
.../devicetree/bindings/arm/omap/prcm.txt | 13 ++
arch/arm/boot/dts/am33xx.dtsi | 6 +
arch/arm/boot/dts/am4372.dtsi | 6 +
arch/arm/mach-omap2/Kconfig| 2 +
drivers/reset/Kconfig | 14 ++
drivers/reset/Makefile | 1 +
drivers/reset/amx3_reset.c | 157 +
drivers/reset/core.c | 32 +
include/linux/reset-controller.h | 2 +
include/linux/reset.h | 2 +
10 files changed, 235 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt
create mode 100644 drivers/reset/amx3_reset.c
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 1/6] reset: is_reset and clear_reset api's
Enhance reset framework with is_reset and clear_reset api's.
is_reset - used by client driver to know reset status
clear_reset - used by client driver to clear reset status
These functionalities may sometimes be achieved by using existing api
like deassert. But in some scenarios, steps to achieve reset requires
clearing reset, deassert reset, enabling clock to module and then
checking reset status. Here enabling clock module is coming in between
reset procedure, hence enhance framework with additional api's.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/reset/core.c | 32
include/linux/reset-controller.h | 2 ++
include/linux/reset.h| 2 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index d1b6089..ba12171 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -127,6 +127,38 @@ int reset_control_deassert(struct reset_control *rstc)
EXPORT_SYMBOL_GPL(reset_control_deassert);
/**
+ * reset_control_is_reset - check reset status
+ * @rstc: reset controller
+ *
+ * Returns a boolean or negative error code
+ *
+ */
+int reset_control_is_reset(struct reset_control *rstc)
+{
+ if (rstc-rcdev-ops-is_reset)
+ return rstc-rcdev-ops-is_reset(rstc-rcdev, rstc-id);
+
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_is_reset);
+
+/**
+ * reset_control_clear_reset - clear the reset
+ * @rstc: reset controller
+ *
+ * Returns zero on success or negative error code
+ *
+ */
+int reset_control_clear_reset(struct reset_control *rstc)
+{
+ if (rstc-rcdev-ops-clear_reset)
+ return rstc-rcdev-ops-clear_reset(rstc-rcdev, rstc-id);
+
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(reset_control_clear_reset);
+
+/**
* reset_control_get - Lookup and obtain a reference to a reset controller.
* @dev: device to be reset by the controller
* @id: reset line name
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index 2f61311..c9bbadb 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -17,6 +17,8 @@ struct reset_control_ops {
int (*reset)(struct reset_controller_dev *rcdev, unsigned long id);
int (*assert)(struct reset_controller_dev *rcdev, unsigned long id);
int (*deassert)(struct reset_controller_dev *rcdev, unsigned long id);
+ int (*is_reset)(struct reset_controller_dev *rcdev, unsigned long id);
+ int (*clear_reset)(struct reset_controller_dev *rcdev, unsigned long i);
};
struct module;
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 6082247..da59f9f 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -7,6 +7,8 @@ struct reset_control;
int reset_control_reset(struct reset_control *rstc);
int reset_control_assert(struct reset_control *rstc);
int reset_control_deassert(struct reset_control *rstc);
+int reset_control_is_reset(struct reset_control *rstc);
+int reset_control_clear_reset(struct reset_control *rstc);
struct reset_control *reset_control_get(struct device *dev, const char *id);
void reset_control_put(struct reset_control *rstc);
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 2/6] doc: dt: binding: omap: am43x/am335x prcm reset
prcm reset binding for AM43x/AM335x SoC's.
This was started with an attempt to add reset binding without a clear
idea on the device node where binding should appear. So a new node
with compatible am4372-reset to represent reset managment in prcm
was added. But finally ended up with a node to represent prcm (with
compatible am4372-prcm) which was felt to be the natural one.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Documentation/devicetree/bindings/arm/omap/prcm.txt | 13 +
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt
b/Documentation/devicetree/bindings/arm/omap/prcm.txt
new file mode 100644
index 000..ad25abc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt
@@ -0,0 +1,13 @@
+TI Power Reset Clock Manager (PRCM)
+
+Properties:
+- compatible: ti,am4372-prcm for prcm in am43x SoC's
+ ti,am3352-prcm for prcm in am335x SoC's
+- #reset-cells: 1 (refer generic reset bindings for details)
+
+example:
+ prcm: prcm@44df {
+ compatible = ti,am4372-prcm;
+ reg = 0x44df 0xa000;
+ #reset-cells = 1;
+ };
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 3/6] reset: am43x/am335x support
Driver to handle reset block in prcm of AM43x, AM335x SoC's. There are
three reset's that can be handled by this reset driver - gfx, m3 and
pruss. Of this only gfx has been handled here, adding support for the
remaining only require adding array entries with details of pruss and
m3.
Signed-off-by: Afzal Mohammed af...@ti.com
---
drivers/reset/Kconfig | 14
drivers/reset/Makefile | 1 +
drivers/reset/amx3_reset.c | 157 +
3 files changed, 172 insertions(+)
create mode 100644 drivers/reset/amx3_reset.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..2af81b9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,17 @@ menuconfig RESET_CONTROLLER
via GPIOs or SoC-internal reset controller modules.
If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_AMX3
+ bool AMx3 reset controller
+ help
+ Reset controller support for AM43x/AM335x SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x
+
+ If unsure, say no.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b8c1afe 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_AMX3) += amx3_reset.o
diff --git a/drivers/reset/amx3_reset.c b/drivers/reset/amx3_reset.c
new file mode 100644
index 000..4e476a5
--- /dev/null
+++ b/drivers/reset/amx3_reset.c
@@ -0,0 +1,157 @@
+/*
+ * PRCM reset driver for AM335x AM43x SoC's
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/device.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/reset.h
+#include linux/reset-controller.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#define DRIVER_NAME amx3_reset
+
+struct amx3_reset_reg_data {
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u8 rstctrl_bit;
+ u8 rstst_bit;
+};
+
+struct amx3_reset_data {
+ struct amx3_reset_reg_data *reg_data;
+ u8 nr_resets;
+};
+
+static void __iomem *reg_base;
+static const struct amx3_reset_data *amx3_reset_data;
+
+static struct amx3_reset_reg_data am335x_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x1104,
+ .rstst_offs = 0x1114,
+ .rstctrl_bit= 0,
+ .rstst_bit = 0,
+ },
+};
+
+static struct amx3_reset_data am335x_reset_data = {
+ .reg_data = am335x_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(am335x_reset_reg_data),
+};
+
+static struct amx3_reset_reg_data am43x_reset_reg_data[] = {
+ {
+ .rstctrl_offs = 0x410,
+ .rstst_offs = 0x414,
+ .rstctrl_bit= 0,
+ .rstst_bit = 0,
+ },
+};
+
+static struct amx3_reset_data am43x_reset_data = {
+ .reg_data = am43x_reset_reg_data,
+ .nr_resets = ARRAY_SIZE(am43x_reset_reg_data),
+};
+
+static int amx3_reset_clear_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ void __iomem *reg = amx3_reset_data-reg_data[id].rstst_offs + reg_base;
+ u8 bit = amx3_reset_data-reg_data[id].rstst_bit;
+ u32 val = readl(reg);
+
+ val = ~(1 bit);
+ val |= 1 bit;
+ writel(val, reg);
+ return 0;
+}
+
+static int amx3_reset_is_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ void __iomem *reg = amx3_reset_data-reg_data[id].rstst_offs + reg_base;
+ u8 bit = amx3_reset_data-reg_data[id].rstst_bit;
+ u32 val = readl(reg);
+
+ val = (1 bit);
+ return !!val;
+}
+
+static int amx3_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ void __iomem *reg = amx3_reset_data-reg_data[id].rstctrl_offs +
+ reg_base;
+ u8 bit = amx3_reset_data-reg_data[id].rstctrl_bit;
+ u32 val = readl(reg);
+
+ val = ~(1 bit);
+ writel(val, reg);
+ return 0;
+}
+
+static struct reset_control_ops amx3_reset_ops = {
+ .deassert = amx3_reset_deassert,
+ .is_reset = amx3_reset_is_reset,
+ .clear_reset = amx3_reset_clear_reset,
+};
+
+static struct reset_controller_dev amx3_reset_controller = {
+ .ops = amx3_reset_ops,
+};
+
+static const struct of_device_id amx3_reset_of_match[] = {
+ { .compatible = ti,am3352-prcm, .data = am335x_reset_data,},
+ { .compatible = ti,am4372-prcm, .data = am43x_reset_data,},
+ {},
+};
+
+static int
[PATCH RFC 4/6] ARM: OMAP2+: AM43x/AM335x: have reset controller
AM43x, AM335x have reset block as part of prcm, let reset driver be usable with these SoC's. Signed-off-by: Afzal Mohammed af...@ti.com --- arch/arm/mach-omap2/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3eed000..fa28d1d 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -72,6 +72,7 @@ config SOC_AM33XX select CPU_V7 select MULTI_IRQ_HANDLER select COMMON_CLK + select ARCH_HAS_RESET_CONTROLLER config SOC_AM43XX bool TI AM43x @@ -82,6 +83,7 @@ config SOC_AM43XX select ARM_GIC select COMMON_CLK select MACH_OMAP_GENERIC + select ARCH_HAS_RESET_CONTROLLER config ARCH_OMAP2PLUS bool -- 1.8.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 6/6] ARM: dts: AM4372: prcm node (for reset)
Add AM4372 prcm node with reset binding.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5a68fde..d0d11b3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -411,6 +411,12 @@
ti,hwmods = epwmss5;
status = disabled;
};
+
+ prcm: prcm@44df {
+ compatible = ti,am4372-prcm;
+ reg = 0x44df 0xa000;
+ #reset-cells = 1;
+ };
};
clocks {
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 5/6] ARM: dts: AM335x: prcm node (for reset)
Add AM335x prcm node with reset binding.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4701e3c..c2ccf94 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -530,6 +530,12 @@
#size-cells = 1;
status = disabled;
};
+
+ prcm: prcm@44e0 {
+ compatible = ti,am3352-prcm;
+ reg = 0x44e0 0x1300;
+ #reset-cells = 1;
+ };
};
clocks {
--
1.8.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Make dwc3 use Generic PHY Framework and misc cleanup
Modified dwc3 core to find PHYs only if the platform indicates that it has
to use a PHY. Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also
changed the name of USB3 PHY driver to PIPE3 PHY driver since the same driver
has to be used for SATA and PCIE too.
This series also includes a bunch of misc cleanups and also renamed
omap_control_usb to omap_control_phy (done on top of rogers patches [1])
Did g_zero enumeration testing on OMAP4 PANDA and did xhci testing in
OMAP5 uEvm.
I have pushed this branch to http://git.gitorious.org/linuxphy/linuxphy.git
dwc3_generic_phy
[1] - git://github.com/rogerq/linux.git usb-control-module
Kishon Vijay Abraham I (7):
usb: dwc3: get usb_phy only if the platform indicates the presence
of PHY
usb: dwc3: adapt dwc3 core to use Generic PHY Framework
drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
Documentation: dt bindings: move ..usb/usb-phy.txt to
..phy/omap-phy.txt
phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
arm/dts: added dt properties to adapt to the new phy framwork
drivers: phy: renamed struct omap_control_usb to struct
omap_control_phy
.../bindings/{usb/usb-phy.txt = phy/omap-phy.txt} |7 +-
Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
arch/arm/boot/dts/omap5.dtsi |5 +-
drivers/phy/Kconfig| 22 +-
drivers/phy/Makefile |2 +
drivers/{usb = }/phy/phy-omap-control.c | 164 +++
.../phy/phy-omap-usb3.c = phy/phy-omap-pipe3.c} | 212 +++-
drivers/phy/phy-omap-usb2.c| 10 +-
drivers/usb/dwc3/Kconfig |2 +
drivers/usb/dwc3/core.c| 109 ++
drivers/usb/dwc3/core.h|7 +
drivers/usb/dwc3/platform_data.h |1 +
drivers/usb/musb/omap2430.c|2 +-
drivers/usb/phy/Kconfig| 11 -
drivers/usb/phy/Makefile |2 -
drivers/usb/phy/phy-twl6030-usb.c |2 +-
.../omap_control_usb.h = phy/omap_control_phy.h} | 32 +--
include/linux/{usb/omap_usb.h = phy/omap_pipe3.h} | 33 +--
include/linux/{usb = phy}/omap_usb.h |3 -
19 files changed, 348 insertions(+), 284 deletions(-)
rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/omap-phy.txt}
(88%)
rename drivers/{usb = }/phy/phy-omap-control.c (55%)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-omap-pipe3.c} (55%)
rename include/linux/{usb/omap_control_usb.h = phy/omap_control_phy.h} (69%)
copy include/linux/{usb/omap_usb.h = phy/omap_pipe3.h} (52%)
rename include/linux/{usb = phy}/omap_usb.h (95%)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] drivers: phy: renamed struct omap_control_usb to struct omap_control_phy
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
/**
- * omap_control_usb_phy_power - power on/off the phy using control module reg
+ * omap_control_phy_power - power on/off the phy using control module reg
* @dev: the control module device
* @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb_phy_power(struct device *dev, int on)
+void omap_control_phy_power(struct device *dev, int on)
{
u32 val, val_aux;
unsigned long rate;
- struct omap_control_usb *control_usb;
+ struct omap_control_phy *control_phy;
if (IS_ERR(dev) || !dev) {
pr_err(%s: invalid device\n, __func__);
return;
}
- control_usb = dev_get_drvdata(dev);
- if (!control_usb) {
+ control_phy = dev_get_drvdata(dev);
+ if (!control_phy) {
dev_err(dev, %s: invalid control usb device\n, __func__);
return;
}
- if (control_usb-type == OMAP_CTRL_TYPE_OMAP4)
+ if (control_phy-type == OMAP_CTRL_TYPE_OMAP4)
return;
- val = readl(control_usb-power);
+ val = readl(control_phy-power);
- switch (control_usb-type) {
+ switch (control_phy-type) {
case OMAP_CTRL_TYPE_USB2:
if (on)
val = ~OMAP_CTRL_DEV_PHY_PD;
@@ -62,24
[PATCH 5/7] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/phy-omap-usb2.c |2 +-
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/{usb = phy}/omap_usb.h |3 ---
3 files changed, 2 insertions(+), 5 deletions(-)
rename include/linux/{usb = phy}/omap_usb.h (95%)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index b25d623..6c78584 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/io.h
-#include linux/usb/omap_usb.h
+#include linux/phy/omap_usb.h
#include linux/usb/phy_companion.h
#include linux/clk.h
#include linux/err.h
diff --git a/drivers/usb/phy/phy-twl6030-usb.c
b/drivers/usb/phy/phy-twl6030-usb.c
index 16dbc93..b5ad3eb 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -26,8 +26,8 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/usb/musb-omap.h
+#include linux/phy/omap_usb.h
#include linux/usb/phy_companion.h
-#include linux/usb/omap_usb.h
#include linux/i2c/twl.h
#include linux/regulator/consumer.h
#include linux/err.h
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
struct omap_usb {
struct usb_phy phy;
struct phy_companion*comparator;
- void __iomem*pll_ctrl_base;
struct device *dev;
struct device *control_dev;
struct clk *wkupclk;
- struct clk *sys_clk;
struct clk *optclk;
- u8 is_suspended:1;
};
#definephy_to_omapusb(x) container_of((x), struct omap_usb, phy)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] arm/dts: added dt properties to adapt to the new phy framwork
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;
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
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.
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 +++-
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
+ 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.
+ 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, 92843} }, /* 38.4 MHz */
};
-static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(unsigned long rate)
{
int i;
@@ -83,110 +84,113 @@ static struct usb_dpll_params
*omap_usb3_get_dpll_params(unsigned long rate)
return 0;
}
-static int omap_usb3_suspend(struct usb_phy *x, int suspend)
+static int omap_pipe3_power_off(struct phy *x)
{
- struct
[PATCH 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY
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);
+ } 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);
+ } 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
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,5 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool
[PATCH 4/7] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/omap-phy.txt
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
@@ -1,4 +1,4 @@
-USB PHY
+OMAP PHY: DT DOCUMENTATION FOR PHYs in OMAP PLATFORM
OMAP USB2 PHY
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
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)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
+
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
@@ -673,6 +711,11 @@ static int dwc3_suspend(struct device *dev)
usb_phy_shutdown(dwc-usb3_phy);
Re: [PATCH v2 2/3] ARM: OMAP4+: Move SRAM data to DT
On 8/29/2013 7:21 PM, Santosh Shilimkar wrote:
On Thursday 29 August 2013 09:50 AM, Rajendra Nayak wrote:
On Thursday 29 August 2013 07:01 PM, Santosh Shilimkar wrote:
On Thursday 29 August 2013 09:26 AM, Sekhar Nori wrote:
On 8/29/2013 4:53 PM, Rajendra Nayak wrote:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1ba6a77 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -126,6 +126,11 @@
pinctrl-single,function-mask = 0x7fff;
};
+ ocmcram: ocmcram@40304000 {
This can now be changed to 0x4030 now that you have moved to
gen_pool_alloc()?
NO.
It won't work on secure devices since first 16 KB is occupied for
default configuration. Its not worth trouble also to handle
secure/non-secure considering the use of SRAM which is actually just
limited to errata. 40304000 will work for both devices.
Right. Sekhar, you might have confused because of the existing buggy code
in sram.c and sram.h which did this (and is removed in this series)
from sram.c
---
#define OMAP2_SRAM_PUB_PA (OMAP2_SRAM_PA + 0xf800)
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
-#ifdef CONFIG_OMAP4_ERRATA_I688
-#define OMAP4_SRAM_PUB_PA OMAP4_SRAM_PA
-#else
-#define OMAP4_SRAM_PUB_PA (OMAP4_SRAM_PA + 0x4000)
-#endif
-#define OMAP5_SRAM_PA 0x4030
from sram.h
---
#define OMAP2_SRAM_PA 0x4020
#define OMAP3_SRAM_PA 0x4020
-#ifdef CONFIG_OMAP4_ERRATA_I688
-#define OMAP4_SRAM_PA 0x40304000
-#define OMAP4_SRAM_VA 0xfe404000
-#else
-#define OMAP4_SRAM_PA 0x4030
-#endif
I am not sure where the checks for CONFIG_OMAP4_ERRATA_I688
came in from, but these are done, like Santosh said, to handle
secure and non-secure sram across GP and HS devices and in
no way related to handling errata I688.
The check was to ensure that with errata enabled, we don't care
about first 16 KB ;-)
Hi Rajendra, thanks for the explanation. Other devices like AM437x which
have HS variants might need such adjustment too. It will be nice to
check that.
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
OMAP baseline test results for v3.11
Here are some basic OMAP test results for Linux v3.11. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.11/20130902150604/ Test summary Build: zImage: Pass ( 1/ 1): omap2plus_defconfig Build: uImage: Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Build: uImage+dtb: Pass ( 3/ 3): am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Boot to userspace: skip ( 1/ 1): 5912osk Pass (10/10): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517 PM: chip retention via suspend: FAIL ( 2/ 6): 2430sdp, 4430es2panda Pass ( 4/ 6): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 3/ 6): 2430sdp, 4430es2panda, 4460pandaes Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 2/ 4): 4430es2panda, 4460pandaes Pass ( 2/ 4): 3530es3beagle, 37xxevm PM: chip off via dynamic idle: FAIL ( 2/ 4): 4430es2panda, 4460pandaes Pass ( 2/ 4): 3530es3beagle, 37xxevm vmlinux object size (delta in bytes from test_v3.11-rc7 (d8dfad3876e438b759da3c833d62fb8b2267)): text data bsstotal kernel +5600 +56 n800_multi_omap2xxx +5600 +56 n800_only_a +849 +80 +857 omap1_defconfig +785 +80 +793 omap1_defconfig_1510innovator_only +817 +160 +833 omap1_defconfig_5912osk_only +633 -240 +609 omap2plus_defconfig +625 +80 +633 omap2plus_defconfig_2430sdp_only +633 -240 +609 omap2plus_defconfig_cpupm +633 +80 +641 omap2plus_defconfig_no_pm +633 +80 +641 omap2plus_defconfig_omap2_4_only +697 -240 +673 omap2plus_defconfig_omap3_4_only +2360 +20 +256 rmk_omap3430_ldp_allnoconfig +341 +80 +349 rmk_omap3430_ldp_oldconfig +2280 +28 +256 rmk_omap4430_sdp_allnoconfig Boot-time memory difference (delta in bytes from test_v3.11-rc7 (d8dfad3876e438b759da3c833d62fb8b2267)) avail rsrvd high freed board kconfig (no differences) -- 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
Pandaboard Kernel 3.8.13.6 no HDMI
The Pandaboard list seems dormant so I am seeking help here. The previous kernel with HDMI video output was 3.2.7x5. I built and installed this new kernel with this xorg.conf, it does not work. Section Device Identifier fb0 Driver omapfb Option fb /dev/fb0 EndSection Section Monitor Identifier HP ModeLine 1920x1080 148.501 1920 2008 2052 2200 1080 1084 1089 1125 -HSync -VSync EndSection Section Screen Identifier screen0 Device fb0 Monitor HP DefaultDepth16 SubSection Display Depth 16 Modes 1920x1080 800x480 EndSubSection EndSection Mode 800x480 # D: 29.001 MHz, H: 31.251 kHz, V: 59.525 Hz DotClock 29.002 HTimings 800 840 888 928 VTimings 480 503 506 525 Flags-HSync -VSync EndMode Using the udlfb driver and an xorg.conf for the Lilliput USB 7 screen there is no problem, LXDE is up and running and CRTL-ALT-F1 etc. all OK, but I need the USB screen for the Beaglebone. root@panda:/etc/X11# lsmod Module Size Used by omapdss 253516 0 udlfb 17703 2 bluetooth 221172 6 snd_usb_audio 115881 0 snd_usbmidi_lib18680 1 snd_usb_audio snd_rawmidi21747 1 snd_usbmidi_lib snd_hwdep 6190 1 snd_usb_audio snd_pcm_oss42617 0 snd_mixer_oss 14244 1 snd_pcm_oss snd_pcm84961 2 snd_pcm_oss,snd_usb_audio snd_page_alloc 5296 1 snd_pcm snd_timer 20277 1 snd_pcm snd61483 8 snd_pcm_oss,snd_usb_audio,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_usbmidi_lib,snd_mixer_oss soundcore 7260 1 snd ehci_hcd 54613 0 ohci_hcd 31836 0 root@panda:/etc/X11# ls /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/ backlight omap2 udlfb.ko root@panda:/etc/X11# ll /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/omap2/omapfb total 64 drwxr-xr-x 2 root root 4096 Sep 2 10:18 ./ drwxr-xr-x 5 root root 4096 Sep 2 10:18 ../ -rw-r--r-- 1 root root 56916 Sep 2 02:52 omapfb.ko root@panda:/etc/X11# modprobe omapfb ERROR: could not insert 'omapfb': No such device root@panda:/etc/X11# insmod /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/omap2/omapfb/omapfb.ko Error: could not insert module /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/omap2/omapfb/omapfb.ko: No such device root@panda:/1/ubuntu-raring# grep CONFIG_FB .config CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_ARMCLCD=y CONFIG_FB_UVESA=y CONFIG_FB_TMIO=y CONFIG_FB_TMIO_ACCELL=y CONFIG_FB_UDL=m CONFIG_FB_VIRTUAL=y CONFIG_OMAP2_VRFB=y CONFIG_OMAP2_DSS_RFBI=y CONFIG_FB_OMAP2=m CONFIG_FB_OMAP2_DEBUG_SUPPORT=y CONFIG_FB_OMAP2_NUM_FBS=3 root@panda:/etc/X11# grep HDMI /1/ubuntu-raring/.config CONFIG_OMAP4_DSS_HDMI=y ONFIG_ARCH_OMAP4=y CONFIG_MACH_OMAP4_PANDA=y Displayed on the serial console === root@panda:~# [34587.439270] omapdss error: timeout reading edid [34587.445220] omapfb omapfb: failed to allocate framebuffer [34587.450958] omapfb omapfb: failed to allocate fbmem [34587.456604] omapfb omapfb: failed to setup omapfb [34587.461853] failed to register omapfb driver Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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 2/6] dma: edma: Write out and handle MAX_NR_SG at a given time
On Thu, Aug 29, 2013 at 06:05:41PM -0500, Joel Fernandes wrote:
Process SG-elements in batches of MAX_NR_SG if they are greater
than MAX_NR_SG. Due to this, at any given time only those many
slots will be used in the given channel no matter how long the
scatter list is. We keep track of how much has been written
inorder to process the next batch of elements in the scatter-list
and detect completion.
For such intermediate transfer completions (one batch of MAX_NR_SG),
make use of pause and resume functions instead of start and stop
when such intermediate transfer is in progress or completed as we
donot want to clear any pending events.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 79
--
1 file changed, 53 insertions(+), 26 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e522ad5..732829b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -56,6 +56,7 @@ struct edma_desc {
struct list_headnode;
int absync;
int pset_nr;
+ int processed;
struct edmacc_param pset[0];
};
@@ -104,22 +105,34 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
/* Dispatch a queued descriptor to the controller (caller holds lock) */
static void edma_execute(struct edma_chan *echan)
{
- struct virt_dma_desc *vdesc = vchan_next_desc(echan-vchan);
+ struct virt_dma_desc *vdesc;
struct edma_desc *edesc;
- int i;
-
- if (!vdesc) {
- echan-edesc = NULL;
- return;
+ struct device *dev = echan-vchan.chan.device-dev;
+ int i, j, left, nslots;
+
+ /* If either we processed all psets or we're still not started */
+ if (!echan-edesc ||
+ echan-edesc-pset_nr == echan-edesc-processed) {
+ /* Get next vdesc */
+ vdesc = vchan_next_desc(echan-vchan);
+ if (!vdesc) {
+ echan-edesc = NULL;
+ return;
+ }
+ list_del(vdesc-node);
+ echan-edesc = to_edma_desc(vdesc-tx);
}
- list_del(vdesc-node);
+ edesc = echan-edesc;
- echan-edesc = edesc = to_edma_desc(vdesc-tx);
+ /* Find out how many left */
+ left = edesc-pset_nr - edesc-processed;
+ nslots = min(MAX_NR_SG, left);
/* Write descriptor PaRAM set(s) */
- for (i = 0; i edesc-pset_nr; i++) {
- edma_write_slot(echan-slot[i], edesc-pset[i]);
+ for (i = 0; i nslots; i++) {
+ j = i + edesc-processed;
+ edma_write_slot(echan-slot[i], edesc-pset[j]);
dev_dbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
chnum\t%d\n
@@ -132,24 +145,31 @@ static void edma_execute(struct edma_chan *echan)
bidx\t%08x\n
cidx\t%08x\n
lkrld\t%08x\n,
- i, echan-ch_num, echan-slot[i],
- edesc-pset[i].opt,
- edesc-pset[i].src,
- edesc-pset[i].dst,
- edesc-pset[i].a_b_cnt,
- edesc-pset[i].ccnt,
- edesc-pset[i].src_dst_bidx,
- edesc-pset[i].src_dst_cidx,
- edesc-pset[i].link_bcntrld);
+ j, echan-ch_num, echan-slot[i],
+ edesc-pset[j].opt,
+ edesc-pset[j].src,
+ edesc-pset[j].dst,
+ edesc-pset[j].a_b_cnt,
+ edesc-pset[j].ccnt,
+ edesc-pset[j].src_dst_bidx,
+ edesc-pset[j].src_dst_cidx,
+ edesc-pset[j].link_bcntrld);
/* Link to the previous slot if not the last set */
- if (i != (edesc-pset_nr - 1))
+ if (i != (nslots - 1))
edma_link(echan-slot[i], echan-slot[i+1]);
/* Final pset links to the dummy pset */
else
edma_link(echan-slot[i], echan-ecc-dummy_slot);
}
- edma_start(echan-ch_num);
+ edesc-processed += nslots;
+
+ edma_resume(echan-ch_num);
+
+ if (edesc-processed = MAX_NR_SG) {
+ dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+ edma_start(echan-ch_num);
+ }
}
static int edma_terminate_all(struct edma_chan *echan)
@@ -368,19 +388,26 @@ static void edma_callback(unsigned ch_num, u16
ch_status, void *data)
struct edma_desc *edesc;
unsigned long flags;
- /* Stop the channel */
- edma_stop(echan-ch_num);
+ /* Pause the channel */
+ edma_pause(echan-ch_num);
switch (ch_status) {
case
Re: Pandaboard Kernel 3.8.13.6 no HDMI
Hi, There are a couple of options here. On Tuesday 03 September 2013 06:14 AM, Sid Boyce wrote: The Pandaboard list seems dormant so I am seeking help here. The previous kernel with HDMI video output was 3.2.7x5. I built and installed this new kernel with this xorg.conf, it does not work. Section Device Identifier fb0 Driver omapfb Option fb /dev/fb0 EndSection Looks like the problem below was buffer allocation. You could use omapdrm instead of omapfb which should allocate buffers successfully. I think the omapdrm drivers was in staging at that point. You could search for it in the .config, and set NUM_CRTCS to 2. Section Monitor Identifier HP ModeLine 1920x1080 148.501 1920 2008 2052 2200 1080 1084 1089 1125 -HSync -VSync EndSection Section Screen Identifier screen0 Device fb0 Monitor HP DefaultDepth16 SubSection Display Depth 16 Modes 1920x1080 800x480 EndSubSection EndSection Mode 800x480 # D: 29.001 MHz, H: 31.251 kHz, V: 59.525 Hz DotClock 29.002 HTimings 800 840 888 928 VTimings 480 503 506 525 Flags-HSync -VSync EndMode Using the udlfb driver and an xorg.conf for the Lilliput USB 7 screen there is no problem, LXDE is up and running and CRTL-ALT-F1 etc. all OK, but I need the USB screen for the Beaglebone. root@panda:/etc/X11# lsmod Module Size Used by omapdss 253516 0 udlfb 17703 2 bluetooth 221172 6 snd_usb_audio 115881 0 snd_usbmidi_lib18680 1 snd_usb_audio snd_rawmidi21747 1 snd_usbmidi_lib snd_hwdep 6190 1 snd_usb_audio snd_pcm_oss42617 0 snd_mixer_oss 14244 1 snd_pcm_oss snd_pcm84961 2 snd_pcm_oss,snd_usb_audio snd_page_alloc 5296 1 snd_pcm snd_timer 20277 1 snd_pcm snd61483 8 snd_pcm_oss,snd_usb_audio,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_usbmidi_lib,snd_mixer_oss soundcore 7260 1 snd ehci_hcd 54613 0 ohci_hcd 31836 0 root@panda:/etc/X11# ls /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/ backlight omap2 udlfb.ko root@panda:/etc/X11# ll /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/omap2/omapfb total 64 drwxr-xr-x 2 root root 4096 Sep 2 10:18 ./ drwxr-xr-x 5 root root 4096 Sep 2 10:18 ../ -rw-r--r-- 1 root root 56916 Sep 2 02:52 omapfb.ko root@panda:/etc/X11# modprobe omapfb ERROR: could not insert 'omapfb': No such device root@panda:/etc/X11# insmod /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/omap2/omapfb/omapfb.ko Error: could not insert module /lib/modules/3.8.13.6x-dirty/kernel/drivers/video/omap2/omapfb/omapfb.ko: No such device root@panda:/1/ubuntu-raring# grep CONFIG_FB .config CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_ARMCLCD=y CONFIG_FB_UVESA=y CONFIG_FB_TMIO=y CONFIG_FB_TMIO_ACCELL=y CONFIG_FB_UDL=m CONFIG_FB_VIRTUAL=y CONFIG_OMAP2_VRFB=y CONFIG_OMAP2_DSS_RFBI=y CONFIG_FB_OMAP2=m CONFIG_FB_OMAP2_DEBUG_SUPPORT=y CONFIG_FB_OMAP2_NUM_FBS=3 The other option is to figure out why it's not working with omapfb. Could you add a CONFIG_OMAP2_DSS_DEBUG in order to get additional DSS prints? root@panda:/etc/X11# grep HDMI /1/ubuntu-raring/.config CONFIG_OMAP4_DSS_HDMI=y ONFIG_ARCH_OMAP4=y CONFIG_MACH_OMAP4_PANDA=y Displayed on the serial console === root@panda:~# [34587.439270] omapdss error: timeout reading edid [34587.445220] omapfb omapfb: failed to allocate framebuffer [34587.450958] omapfb omapfb: failed to allocate fbmem [34587.456604] omapfb omapfb: failed to setup omapfb [34587.461853] failed to register omapfb driver The debug prints will help with the edid timeout. About the allocation of buffers, I think it should work if you enable CMA. And set CONFIG_CMA_SIZE_MBYTES to say, 24 Mb. That should allocate the buffers successfully. Archit -- 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
