RE: [PATCH 7/7] usb: dwc3: exynos: add pm_runtime support
Hi Felipe,
> -static int dwc3_exynos_suspend(struct device *dev)
> +static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
> {
> - struct dwc3_exynos *exynos = dev_get_drvdata(dev);
> -
> clk_disable(exynos->clk);
>
> return 0;
> }
>
> +static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
> +{
> + return clk_enable(exynos->clk);
> +}
> +
> +static int dwc3_exynos_suspend(struct device *dev)
> +{
> + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
> +
> + return __dwc3_exynos_suspend(exynos);
If dwc3-exynos is runtime suspended, the clock will be disabled
second time here (unbalanced clk_enable/clk_disable).
> +}
> +
> static int dwc3_exynos_resume(struct device *dev)
> {
> struct dwc3_exynos *exynos = dev_get_drvdata(dev);
> + int ret;
>
> - clk_enable(exynos->clk);
> + ret = __dwc3_exynos_resume(exynos);
> + if (ret)
> + return ret;
>
> /* runtime set active to reflect active state. */
> pm_runtime_disable(dev);
> @@ -207,8 +238,24 @@ static int dwc3_exynos_resume(struct device *dev)
> return 0;
> }
>
> +static int dwc3_exynos_runtime_suspend(struct device *dev)
> +{
> + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
> +
> + return __dwc3_exynos_suspend(exynos);
> +}
> +
> +static int dwc3_exynos_runtime_resume(struct device *dev)
> +{
> + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
> +
> + return __dwc3_exynos_resume(exynos);
> +}
Thanks
--
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] usb: dwc3: pci: add pm_runtime support
On Thu, Dec 12, 2013 at 10:17:19PM -0600, Felipe Balbi wrote: > On Thu, Dec 12, 2013 at 05:56:05PM -0800, David Cohen wrote: > > On Thu, Dec 12, 2013 at 03:38:41PM -0600, Felipe Balbi wrote: > > > teach the PCI glue about pm_runtime so that > > > it's easier to teach dwc3 core about it > > > later. > > > > > > No functional changes otherwise. > > > > > > Signed-off-by: Felipe Balbi > > > > I was able to test this one with Intel Merrifield: > > Acked-by: David Cohen > > cool, thanks. Although that'd be a Tested-by. Is it ok to add your name > as Tested-by instead ? Yeah :) Br, David > > -- > 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: [PATCH 3/7] usb: dwc3: pci: add pm_runtime support
On Thu, Dec 12, 2013 at 05:56:05PM -0800, David Cohen wrote: > On Thu, Dec 12, 2013 at 03:38:41PM -0600, Felipe Balbi wrote: > > teach the PCI glue about pm_runtime so that > > it's easier to teach dwc3 core about it > > later. > > > > No functional changes otherwise. > > > > Signed-off-by: Felipe Balbi > > I was able to test this one with Intel Merrifield: > Acked-by: David Cohen cool, thanks. Although that'd be a Tested-by. Is it ok to add your name as Tested-by instead ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
Hi Tomi, On Thursday 12 December 2013 10:54:48 Tomi Valkeinen wrote: > On 2013-12-12 02:39, Laurent Pinchart wrote: > > On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote: > >> Hi, > >> > >> Here's a new version for DT support to OMAP Display Subsystem. See > >> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro > >> of the previous version, which contains thoughts about the related > >> problems. > >> > >> The major change in this version is the use of V4L2 and CDF style > >> port/endpoint style in the DT data. > > > > That's great, and I fully support that. This also calls for refactoring > > the V4L2 DT bindings and support code to share them with display devices. > > A bikeshedding question is where to put the common code. > > Thanks very much for review! > > I know drivers/video is in practice "fbdev", but drivers/video (the > words) sound like the best place for things related to video. That's an option as well, but I'm not sure I like the idea of mixing fbdev and generic video in a single directory. We could use a subdirectory of drivers/video. > We should establish a committee to ponder this important question. > > Btw, I don't know if you noticed (or did I mention it somewhere): I use > a bit shortened form of the V4L2 bindings. If there's just one endpoint, > I omit the port node. I think that's always unambiguous (compared to > also omitting the endpoint node, and having the properties in the main > node, as was mentioned in some other thread). Yes, I've seen that. I need to analyze this in detail, that's planned for when I'll work on sharing the DT parsing code. > I also don't supply the same data for both endpoints, when the data is about > the link. E.g. I think the V4L2 binding doc suggests to supply things like > bus-width for both endpoints. I only supply the data for the endpoint that > uses that data. With some encoders/panels the same data could be needed on > both ends, but not in these patches. How do you handle the situation where the two drivers (for each end of the link) need to know the bus width for instance ? > >> However, note that even if the DT data contains proper port & endpoint > >> data, the drivers only use the first endpoint. This is to simplify the > >> patches, as adding full support for the ports and endpoints to the > >> drivers will be a big task. > > > > That's perfectly fine, there's no need to implement unused features just > > for the sake of it, as long as the bindings are forward-compatible in > > that respect. > > > >> This approach still works with more or less all the boards, as the only > >> cases where the simpler model is an issue are the boards with multiple > >> display devices connected to a single output. > >> > >> Laurent, I'd appreciate if you could have a look at the .dts changes, to > >> see if there's anything that's clearly not CDF compatible. > > > > I've quickly reviewed the patch set, concentrating on the .dts changes. > > Overall it looks good to me, but I suspect that we will need quite some > > time to finalize standard bindings as there's lots of small details that > > need to be taken care of. > > Yes. I want to get this forward as it's becoming too much pain to manage > things without DSS DT support, when the rest of the OMAP platform code is > using DT. > > The most important thing in the DSS DT bindings for now is that they should > contain enough information so that any future DT bindings changes can be > handled with a boot-time conversion code. I'm afraid I can't give you any guarantee here. The bindings will be unstable for some time, and we'll have to deal with that somehow. > Actually, even the endpoint/port stuff is extra, as that could be deduced > even from the "video-source" method I used in earlier DT versions. > > > The major point that bothers we, as explained in my reply to one of the > > patches, is that I feel like the multi-device model (virtual DSS core + > > DSS modules) might not accurately represent the hardware. Departing from > > it probably sounds scary but might not be such a large change. > > There are actually two separate things here. One is the multi-device model, > having separate device for each DSS submodule. The other is having the > 'omapdss' "virtual" platform device. > > Note that the "dss_core" device is a real HW block, and depicted as the > "dss" node in DT data, whereas "omapdss" device is not present in the DT > data, and is created dynamically at boot time. That's a distinction I've missed. > The omapdss device is a legacy thing, but nowadays it is mainly used to pass > platform data. Removing omapdss device is not easy, but the only questions > around that is how to implement the required platform-data functionalities, > and it doesn't affect the DT data. The omapdss platform data structure contains the following fields - get_context_loss_count: What is that used for ? - num_devices, devices, default_device: What are those use
Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
Hi Tony, On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote: > On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote: > > On 2013-12-12 01:44, Laurent Pinchart wrote: > > > > So, are they independent? I don't know =). I think they lean on the > > independent side. dss_core is always needed for the submodules to work, > > but for example DSI could be used without DISPC, using system DMA to > > transfer data from memory to DSI. Not a very useful thing to do, but > > still, there are dedicated DMA channels for that. > > If they have separate hwmod entries, they should be considered separate > independent devices for sure. > > To summarize, here are few reasons why they need to be treated as > separate devices: Are you talking generally here, or about the DSS modules in particular ? > 1. The modules maybe clocked/powered/idled separately and can have their >own idle configuration so they can do the hardware based idling >separately. I don't think this applies to the DSS modules. > 2. Doing a readback after a write to one module will not flush the write >to the other modules on the (bus depending on the SoC version AFAIK). >That can lead to nasty bugs caused by the ordering. How does separate devices solve this ? > 3. If the devices are described in a different way in the .dts files >from the hwmod data, we will not have 1-to-1 mapping and will never >be able to replace ti,hwmods with just the compatible string. -- Regards, Laurent Pinchart -- 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 13/26] ARM: omap3.dtsi: add omapdss information
Hi Tomi, On Thursday 12 December 2013 10:38:34 Tomi Valkeinen wrote: > On 2013-12-12 01:44, Laurent Pinchart wrote: > >> The DSS subdevices depend on the dss_core. dss_core has to be powered up > >> for any of the subdevices to work. This is done automatically by the > >> runtime PM when the subdevices are children of the dss_core. > > > > I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is > > organized in a seemingly similar way, with the hardware subdivided in > > high-level more-or-less independent modules. However, from a system point > > of view, the ISP submodules are not standalone: they're part of the same > > power domain as the ISP core, with subclocks management and interrupts > > being handled by the ISP core. For those reasons we've modeled the ISP as > > a single platform device. > > > > Are the DSS submodules really independent, or are they organized similarly > > ? For instance do they each have a clock handled by the OMAP core clock > > IP, or are the clocks gated by the DSS core ? Do they have interrupts > > routed to the GIC, or does the DSS core driver demux the interrupts ? > > The DSS is "interesting". The TRM for various OMAP versions are the best > source of information, there's integration section in the very beginning > of the DSS chapter. > > We have the main dss_core (just DSS in the TRM, but for clarity we use > dss_core) module, which is kind of a wrapper/glue for all the > submodules. dss_core contains things like controlling muxes for signals > between submodules, or clocks coming from outside. And there's the DSS > power domain, containing all the DSS modules. > > Then we have DISPC, which reads the pixel data, manipulates it, and > outputs raw RGB data to encoder submodules. > > Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have > separate address spaces, some have dedicated PLLs, PHYs, and interrupts. The separate address spaces are not by themselves a clear indication that the submodules should be considered as separate devices, as the hardware might just group registers related to submodules together. The dedicated interrupts (for DSI and HDMI) and PRCM clocks (for VENC if I'm not mistaken, and HDMI on the OMAP4) are a clearer sign. > Then DPI, which I think is mostly just level shifters. It's really just > a port, as you say. > > SDI is a bit unclear to me. The registers for it are in the dss_core. > There's only a few registers, but it does have a PHY and a PLL. But I > guess it's also more of a port than a separate module. After a quick look at the documentation I would say so. I would be tempted to consider RFBI as part of the DSS core, but that's less clear. > As for the clocks, I'm not sure what the actual point is that you want > to clarify. DSS gets one "main" func clock from PRCM, which is used by > DISPC and in some cases other submodules. But then we have dedicated DSI > and HDMI PLLs, which, at least in DSI's case, can be used to fully > satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the > PRCM clock is not needed in all cases. > > The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have > their own interrupt line. In OMAP3, DISPC and DSI shared the same > interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt > status/enable is handled via the respective IP. > > The DSS submodules also are not really designed together. For example, > the HDMI IP is from one vendor, not TI. And the HDMI IP is different in > OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's > not like all the IPs were designed to work together, that's why we have > wrappers/glue blocks (e.g. around HDMI). > > So, are they independent? I don't know =). I think they lean on the > independent side. I agree with that, except for DPI, SDI and possibly RFBI. > dss_core is always needed for the submodules to work, but for example DSI > could be used without DISPC, using system DMA to transfer data from memory > to DSI. Not a very useful thing to do, but still, there are dedicated DMA > channels for that. Right. The real question is whether the DSI or HDMI IPs can be used in a system without the DSS core. If not, it might make sense to just merge the drivers into a single module (of course with a clear interface between the different parts to avoid spaghetti code). > > If the submodules are not independent, would it make sense to have a > > single DT node that would be matched with the DSS core driver ? You could > > list information about the submodules in subnodes, and possibly create > > platform devices internally in the DSS core, but a single platform device > > would be instantiated from DT, and the DSS core wouldn't need a > > "simple-bus" compatible string. My gut feeling is that this would be a > > better representation of the hardware, but I might not known enough about > > the DSS and be completely wrong. > > I have been wondering about this for a long time.
Re: [PATCH 10/26] OMAPDSS: add of helpers
Hi Tomi, On Thursday 12 December 2013 09:48:30 Tomi Valkeinen wrote: > On 2013-12-12 01:19, Laurent Pinchart wrote: > > On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote: > >> Add helpers to get ports and endpoints from DT data. > >> > >> While all the functions in dss-of.c might be useful for panel drivers if > >> they need to parse full port/endpoint data, at the moment we only need a > >> few of them outside dss-of.c, so only those functions are exported. > > > > I totally understand that it was easier to add this code to the OMAP DSS > > driver, but I believe we should refactor the existing drivers/media/v4l2- > > core/v4l2-of.c and move it to a non V4L2-specific location (what about > > drivers/media ?) sooner rather than later. That's on my to-do list for > > Saturday. > > I agree. I just didn't want to go that way yet =). > > Have you thought of the API? You had one version in your CDF series, but > I think that was a bit too limited (I don't remember right now how), so > I wrote my own versions. > > What I tried to do here is to add simple ways for the drivers to iterate > the ports and endpoints with omapdss_of_get_next_port and > omapdss_of_get_next_endpoint. > > But I'm not sure what the use pattern would be. If in most of the cases > the driver always goes through all the ports and all the endpoints, we > could as well have a helper function that goes through all the endpoints > in all the ports, and returns both the port and endpoint for each iteration. My plan is to keep it simple. I'll take the V4L2 code and add helpers needed by this patch series and by my Renesas KMS drivers. I'll then see whether refactoring makes sense, and will post the result. We will then add new helpers whenever needed on a case by case basis. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH 3/7] usb: dwc3: pci: add pm_runtime support
On Thu, Dec 12, 2013 at 03:38:41PM -0600, Felipe Balbi wrote: > teach the PCI glue about pm_runtime so that > it's easier to teach dwc3 core about it > later. > > No functional changes otherwise. > > Signed-off-by: Felipe Balbi I was able to test this one with Intel Merrifield: Acked-by: David Cohen -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3: split pinctrl for core into two parts
On 19:02-20131212, Nishanth Menon wrote:
> 3430 TRM(SWPU222W) states that control core module padconf
missed a typo in beagle-xm.dts which i failed to
commit --amend :( grr.. Apologies on the noise..
Fixed version below:
8<
>From f291c8f65e4bfe6c65eb5a485cec4cfb9fcb5e21 Mon Sep 17 00:00:00 2001
From: Nishanth Menon
Date: Mon, 9 Dec 2013 11:23:42 -0600
Subject: [PATCH v2] ARM: dts: omap3: split pinctrl for core into two parts
3430 TRM(SWPU222W) states that control core module padconf
registers have ranges:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
0x480025D8(CONTROL_PADCONF_ETK_CLK) to 0x480025F8.
AM3517 TRM(SPRUGR0C) states that control core module padconf
registers has a single range:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
3630 TRM(SWPU176AB) states that control core module padconf
registers have ranges:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
0x480025A0(CONTROL_PADCONF_SDRC_BA0) to 0x480025F8
We currently map 0x48002030 to 0x480025F8 resulting in the bug
reported in [1].
To fix this, we split this into a another pinctrl device region
specific to the SoC. update board files that get impacted with this
change to ensure bisectability is maintained.
[1] http://marc.info/?l=linux-omap&m=138689141531466&w=2
Reported-by: Tomi Valkeinen
Signed-off-by: Nishanth Menon
---
v2: fix typo in beagle-xm.dts which i missed to commit :(
v1: http://marc.info/?l=linux-omap&m=138689661332699&w=2
Applies on v3.13-rc3
Tested on the following platform:
Beagle-XM (OMAP3630): http://pastebin.mozilla.org/3764783
CraneBoard(AM3517): http://pastebin.mozilla.org/3764784
SDP3430 (OMAP3430): http://pastebin.mozilla.org/3764786
I have not been able to test function impacted by this, but I applied
the following delta for the impacted padconfs I could find:
3430: -0x5A8
3630: -0x570
arch/arm/boot/dts/omap3-beagle-xm.dts | 24 +++-
arch/arm/boot/dts/omap3-beagle.dts| 24 +++-
arch/arm/boot/dts/omap3-igep.dtsi |3 +++
arch/arm/boot/dts/omap3-igep0020.dts | 40 +++--
arch/arm/boot/dts/omap3-igep0030.dts |2 +-
arch/arm/boot/dts/omap3.dtsi |2 +-
arch/arm/boot/dts/omap34xx.dtsi | 13 +++
arch/arm/boot/dts/omap36xx.dtsi | 11 +
8 files changed, 88 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index df33a50..f5f349b 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -96,6 +96,24 @@
};
};
+&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins2
+ >;
+
+ hsusbb2_pins2: pinmux_hsusbb2_pins {
+ pinctrl-single,pins = <
+ 0x050 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x052 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x054 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x056 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x058 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x05a (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ >;
+ };
+};
+
&omap3_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
@@ -111,12 +129,6 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins = <
- 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
- 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
- 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
- 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
- 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
- 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 3ba4a62..7b9e418 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -90,6 +90,24 @@
};
};
+&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins2
+ >;
+
+ hsusbb2_pins2: pinmux_hsusbb2_pins2 {
+ pinctrl-sin
[PATCH] ARM: dts: omap3: split pinctrl for core into two parts
3430 TRM(SWPU222W) states that control core module padconf
registers have ranges:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
0x480025D8(CONTROL_PADCONF_ETK_CLK) to 0x480025F8.
AM3517 TRM(SPRUGR0C) states that control core module padconf
registers has a single range:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
3630 TRM(SWPU176AB) states that control core module padconf
registers have ranges:
0x48002030 to 0x48002264(CONTROL_PADCONF_SDRC_CKE1)
0x480025A0(CONTROL_PADCONF_SDRC_BA0) to 0x480025F8
We currently map 0x48002030 to 0x480025F8 resulting in the bug
reported in [1].
To fix this, we split this into a another pinctrl device region
specific to the SoC. update board files that get impacted with this
change to ensure bisectability is maintained.
[1] http://marc.info/?l=linux-omap&m=138689141531466&w=2
Reported-by: Tomi Valkeinen
Signed-off-by: Nishanth Menon
---
Applies on v3.13-rc3
Tested on the following platform:
Beagle-XM (OMAP3630): http://pastebin.mozilla.org/3764783
CraneBoard(AM3517): http://pastebin.mozilla.org/3764784
SDP3430 (OMAP3430): http://pastebin.mozilla.org/3764786
I have not been able to test function impacted by this, but I applied
the following delta for the impacted padconfs I could find:
3430: -0x5A8
3630: -0x570
The other option would be to modify pinctrl-single driver to accept multiple
reg ranges for the same device, which I think was not the intent
arch/arm/boot/dts/omap3-beagle-xm.dts | 24 +++-
arch/arm/boot/dts/omap3-beagle.dts| 24 +++-
arch/arm/boot/dts/omap3-igep.dtsi |3 +++
arch/arm/boot/dts/omap3-igep0020.dts | 40 +++--
arch/arm/boot/dts/omap3-igep0030.dts |2 +-
arch/arm/boot/dts/omap3.dtsi |2 +-
arch/arm/boot/dts/omap34xx.dtsi | 13 +++
arch/arm/boot/dts/omap36xx.dtsi | 11 +
8 files changed, 88 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index df33a50..2a9508b 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -96,6 +96,24 @@
};
};
+&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins2
+ >;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins = <
+ 0x050 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x052 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x054 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x056 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x058 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x05a (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+ >;
+ };
+};
+
&omap3_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
@@ -111,12 +129,6 @@
hsusbb2_pins: pinmux_hsusbb2_pins {
pinctrl-single,pins = <
- 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
- 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
- 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
- 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
- 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
- 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 3ba4a62..7b9e418 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -90,6 +90,24 @@
};
};
+&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusbb2_pins2
+ >;
+
+ hsusbb2_pins2: pinmux_hsusbb2_pins2 {
+ pinctrl-single,pins = <
+ 0x018 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x01a (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x01c (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+ 0x01e (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+ 0x020 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+ 0x022 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
On Thu, Dec 12, 2013 at 07:29:24PM -0500, Santosh Shilimkar wrote: > On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: > > A bare-minimum PM implementation which will > > server as building block for more complex > s/server/serve ;-) hah! :-) will fix in my branch. > > PM implementation in the future. > > > > At the least will not leave clocks on unnecessarily > > when e.g. a user write mem to /sys/power/state. > > > > Signed-off-by: Felipe Balbi > > --- > > > > improve error path a little bit. > > > We will test this out. Thanks for the > patch Felipe. thanks. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
On Thursday 12 December 2013 04:45 PM, Felipe Balbi wrote: > A bare-minimum PM implementation which will > server as building block for more complex s/server/serve ;-) > PM implementation in the future. > > At the least will not leave clocks on unnecessarily > when e.g. a user write mem to /sys/power/state. > > Signed-off-by: Felipe Balbi > --- > > improve error path a little bit. > We will test this out. Thanks for the patch Felipe. 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: debugfs pinctrl crash on beagle-xm
On 12/10/2013 04:41 AM, Tomi Valkeinen wrote: > Hi, > > On beagle-xm, v3.13-rc3, I see the following crash if I use the pinctrl > debugfs: > > # cat /debug/pinctrl/48002030.pinmux/pins > [ 16.464233] Unhandled fault: external abort on non-linefetch (0x1028) > at 0xfa002268 in 3630 TRM, There is a hole in the memory map between 0x48002264(CONTROL_PADCONF_SDRC_CKE1) and 0x480025A0(CONTROL_PADCONF_SDRC_BA0) which obviously generates abort when read at 0x48002268 on 3430, we should also see a crash in the hole region 0x48002264(CONTROL_PADCONF_SDRC_CKE1) to 0x480025D8(CONTROL_PADCONF_ETK_CLK). in dts, omap3_pmx_core: pinmux@48002030 describes the range as reg = <0x48002030 0x05cc> (which is the max range for the module) wish pinctrl-single driver could support handle multiple address ranges? [...] -- 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 13/26] ARM: omap3.dtsi: add omapdss information
On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote: > On 2013-12-12 01:44, Laurent Pinchart wrote: > > So, are they independent? I don't know =). I think they lean on the > independent side. dss_core is always needed for the submodules to work, > but for example DSI could be used without DISPC, using system DMA to > transfer data from memory to DSI. Not a very useful thing to do, but > still, there are dedicated DMA channels for that. If they have separate hwmod entries, they should be considered separate independent devices for sure. To summarize, here are few reasons why they need to be treated as separate devices: 1. The modules maybe clocked/powered/idled separately and can have their own idle configuration so they can do the hardware based idling separately. 2. Doing a readback after a write to one module will not flush the write to the other modules on the (bus depending on the SoC version AFAIK). That can lead to nasty bugs caused by the ordering. 3. If the devices are described in a different way in the .dts files from the hwmod data, we will not have 1-to-1 mapping and will never be able to replace ti,hwmods with just the compatible string. 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
[PATCH] usb: dwc3: omap: remove DEV_PM_OPS trickery
it's best to just remove all ifdefs and always
define our dev_pm_ops structure.
Signed-off-by: Felipe Balbi
---
one more patch
drivers/usb/dwc3/dwc3-omap.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index a9090a1..14a53ba 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -598,7 +598,6 @@ static const struct of_device_id of_dwc3_match[] = {
};
MODULE_DEVICE_TABLE(of, of_dwc3_match);
-#ifdef CONFIG_PM_SLEEP
static int dwc3_omap_prepare(struct device *dev)
{
struct dwc3_omap*omap = dev_get_drvdata(dev);
@@ -675,18 +674,13 @@ static const struct dev_pm_ops dwc3_omap_dev_pm_ops = {
NULL)
};
-#define DEV_PM_OPS (&dwc3_omap_dev_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM_SLEEP */
-
static struct platform_driver dwc3_omap_driver = {
.probe = dwc3_omap_probe,
.remove = dwc3_omap_remove,
.driver = {
.name = "omap-dwc3",
.of_match_table = of_dwc3_match,
- .pm = DEV_PM_OPS,
+ .pm = &dwc3_omap_dev_pm_ops,
},
};
--
1.8.4.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
Hi,
On Thu, Dec 12, 2013 at 03:45:55PM -0600, Felipe Balbi wrote:
> +static const struct dev_pm_ops kdwc3_dev_pm_ops = {
> + .prepare= kdwc3_prepare,
> + .complete = kdwc3_complete,
> +
> + SET_SYSTEM_SLEEP_PM_OPS(kdwc3_suspend, kdwc3_resume)
> + SET_RUNTIME_PM_OPS(kdwc3_runtime_suspend, kdwc3_runtime_resume, NULL)
> +};
did I really forget to use this ? Wonder why compiler didn't annoy me
:-(
there I go to v3. Will fix in my tree only to avoid the extra traffic in
the mailing list.
--
balbi
signature.asc
Description: Digital signature
[PATCH v2 1/7] usb: dwc3: keystone: add basic PM support
A bare-minimum PM implementation which will
server as building block for more complex
PM implementation in the future.
At the least will not leave clocks on unnecessarily
when e.g. a user write mem to /sys/power/state.
Signed-off-by: Felipe Balbi
---
improve error path a little bit.
drivers/usb/dwc3/dwc3-keystone.c | 94 ++--
1 file changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index 1fad161..3b3761c 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -118,13 +119,22 @@ static int kdwc3_probe(struct platform_device *pdev)
kdwc->clk = devm_clk_get(kdwc->dev, "usb");
- error = clk_prepare_enable(kdwc->clk);
+ error = clk_prepare(kdwc->clk);
if (error < 0) {
dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
error);
return error;
}
+ pm_runtime_enable(dev);
+
+ error = pm_runtime_get_sync(dev);
+ if (error < 0) {
+ dev_dbg(dev, "unable to pm_runtime_get_sync(), err %d\n",
+ error);
+ goto err_irq;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "missing irq\n");
@@ -151,8 +161,11 @@ static int kdwc3_probe(struct platform_device *pdev)
err_core:
kdwc3_disable_irqs(kdwc);
+
err_irq:
- clk_disable_unprepare(kdwc->clk);
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+ clk_unprepare(kdwc->clk);
return error;
}
@@ -172,7 +185,9 @@ static int kdwc3_remove(struct platform_device *pdev)
kdwc3_disable_irqs(kdwc);
device_for_each_child(&pdev->dev, NULL, kdwc3_remove_core);
- clk_disable_unprepare(kdwc->clk);
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ clk_unprepare(kdwc->clk);
platform_set_drvdata(pdev, NULL);
return 0;
@@ -184,6 +199,79 @@ static const struct of_device_id kdwc3_of_match[] = {
};
MODULE_DEVICE_TABLE(of, kdwc3_of_match);
+static int __kdwc3_suspend(struct dwc3_keystone *kdwc)
+{
+ clk_disable(kdwc->clk);
+
+ return 0;
+}
+
+static int __kdwc3_resume(struct dwc3_keystone *kdwc)
+{
+ return clk_enable(kdwc->clk);
+}
+
+static int kdwc3_prepare(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+
+ kdwc3_disable_irqs(kdwc);
+
+ return 0;
+}
+
+static void kdwc3_complete(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+
+ kdwc3_enable_irqs(kdwc);
+}
+
+static int kdwc3_suspend(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+
+ return __kdwc3_suspend(kdwc);
+}
+
+static int kdwc3_resume(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = __kdwc3_resume(kdwc);
+ if (ret)
+ return ret;
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int kdwc3_runtime_suspend(struct device *dev)
+{
+ struct dwc3_keystone *kdwc = dev_get_drvdata(dev);
+
+ return __kdwc3_suspend(kdwc);
+}
+
+static int kdwc3_runtime_resume(struct device *dev)
+{
+ struct dwc3_keystone *kdwc = dev_get_drvdata(dev);
+
+ return __kdwc3_resume(kdwc);
+}
+
+static const struct dev_pm_ops kdwc3_dev_pm_ops = {
+ .prepare= kdwc3_prepare,
+ .complete = kdwc3_complete,
+
+ SET_SYSTEM_SLEEP_PM_OPS(kdwc3_suspend, kdwc3_resume)
+ SET_RUNTIME_PM_OPS(kdwc3_runtime_suspend, kdwc3_runtime_resume, NULL)
+};
+
static struct platform_driver kdwc3_driver = {
.probe = kdwc3_probe,
.remove = kdwc3_remove,
--
1.8.4.GIT
--
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: keystone: add basic PM support
On Thu, Dec 12, 2013 at 03:38:39PM -0600, Felipe Balbi wrote:
> A bare-minimum PM implementation which will
> server as building block for more complex
> PM implementation in the future.
>
> At the least will not leave clocks on unnecessarily
> when e.g. a user write mem to /sys/power/state.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/dwc3/dwc3-keystone.c | 97
> ++--
> 1 file changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-keystone.c
> b/drivers/usb/dwc3/dwc3-keystone.c
> index 1fad161..361437f 100644
> --- a/drivers/usb/dwc3/dwc3-keystone.c
> +++ b/drivers/usb/dwc3/dwc3-keystone.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -118,13 +119,23 @@ static int kdwc3_probe(struct platform_device *pdev)
>
> kdwc->clk = devm_clk_get(kdwc->dev, "usb");
>
> - error = clk_prepare_enable(kdwc->clk);
> + error = clk_prepare(kdwc->clk);
> if (error < 0) {
> dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
> error);
> return error;
> }
>
> + pm_runtime_enable(dev);
> +
> + error = pm_runtime_get_sync(dev);
> + if (error < 0) {
> + dev_dbg(dev, "unable to pm_runtime_get_sync(), err %d\n",
> + error);
> + pm_runtime_put_sync(dev);
I can move this pm_runtime_sync() to error path, will refresh this
patch.
--
balbi
signature.asc
Description: Digital signature
[PATCH 6/7] usb: dwc3: exynos: remove DEV_PM_OPS hackery
it's best to just remove all ifdefs and always
define our dev_pm_ops structure.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-exynos.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 8b20c70..6ccfc64 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -184,7 +184,6 @@ static const struct of_device_id exynos_dwc3_match[] = {
MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
#endif
-#ifdef CONFIG_PM_SLEEP
static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
@@ -212,18 +211,13 @@ static const struct dev_pm_ops dwc3_exynos_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_exynos_suspend, dwc3_exynos_resume)
};
-#define DEV_PM_OPS (&dwc3_exynos_dev_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM_SLEEP */
-
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
.remove = dwc3_exynos_remove,
.driver = {
.name = "exynos-dwc3",
.of_match_table = of_match_ptr(exynos_dwc3_match),
- .pm = DEV_PM_OPS,
+ .pm = &dwc3_exynos_dev_pm_ops,
},
};
--
1.8.4.GIT
--
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: omap: add basic pm_runtime support
If we want to suspend/runtime in runtime, we
can do so, in OMAP's case at least, with the
same implementation we use for system pm.
This patch adds basic pm_runtime support with
that in mind.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-omap.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b269dbd..aea305d 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -617,20 +617,35 @@ static void dwc3_omap_complete(struct device *dev)
dwc3_omap_enable_irqs(omap);
}
-static int dwc3_omap_suspend(struct device *dev)
+static int __dwc3_omap_suspend(struct dwc3_omap *omap)
{
- struct dwc3_omap*omap = dev_get_drvdata(dev);
-
omap->utmi_otg_status = dwc3_omap_read_utmi_status(omap);
return 0;
}
+static int __dwc3_omap_resume(struct dwc3_omap *omap)
+{
+ dwc3_omap_write_utmi_status(omap, omap->utmi_otg_status);
+
+ return 0;
+}
+
+static int dwc3_omap_suspend(struct device *dev)
+{
+ struct dwc3_omap*omap = dev_get_drvdata(dev);
+
+ return __dwc3_omap_suspend(omap);
+}
+
static int dwc3_omap_resume(struct device *dev)
{
struct dwc3_omap*omap = dev_get_drvdata(dev);
+ int ret;
- dwc3_omap_write_utmi_status(omap, omap->utmi_otg_status);
+ ret = __dwc3_omap_resume(omap);
+ if (ret)
+ return ret;
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
@@ -639,11 +654,27 @@ static int dwc3_omap_resume(struct device *dev)
return 0;
}
+static int dwc3_omap_runtime_suspend(struct device *dev)
+{
+ struct dwc3_omap*omap = dev_get_drvdata(dev);
+
+ return __dwc3_omap_suspend(omap);
+}
+
+static int dwc3_omap_runtime_resume(struct device *dev)
+{
+ struct dwc3_omap*omap = dev_get_drvdata(dev);
+
+ return __dwc3_omap_resume(omap);
+}
+
static const struct dev_pm_ops dwc3_omap_dev_pm_ops = {
.prepare= dwc3_omap_prepare,
.complete = dwc3_omap_complete,
SET_SYSTEM_SLEEP_PM_OPS(dwc3_omap_suspend, dwc3_omap_resume)
+ SET_RUNTIME_PM_OPS(dwc3_omap_runtime_suspend, dwc3_omap_runtime_resume,
+ NULL)
};
#define DEV_PM_OPS (&dwc3_omap_dev_pm_ops)
--
1.8.4.GIT
--
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] usb: dwc3: pm_runtime implementation
hi all, these patches add pm_runtime support for all glue layers. I plan to add pm_runtime support for dwc3 after these patches are merged upstream. Please test. Felipe Balbi (7): usb: dwc3: keystone: add basic PM support usb: dwc3: omap: add basic pm_runtime support usb: dwc3: pci: add pm_runtime support usb: dwc3: omap: fix pm_runtime usage usb: dwc3: omap: fix order of pm_runtime vs child removal usb: dwc3: exynos: remove DEV_PM_OPS hackery usb: dwc3: exynos: add pm_runtime support drivers/usb/dwc3/dwc3-exynos.c | 73 +++--- drivers/usb/dwc3/dwc3-keystone.c | 97 ++-- drivers/usb/dwc3/dwc3-omap.c | 45 +++ drivers/usb/dwc3/dwc3-pci.c | 66 --- 4 files changed, 239 insertions(+), 42 deletions(-) -- 1.8.4.GIT -- 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] usb: dwc3: exynos: add pm_runtime support
teach Exynos glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-exynos.c | 65 --
1 file changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 6ccfc64..c93919a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -141,24 +141,40 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos->dev = dev;
exynos->clk = clk;
- clk_prepare_enable(exynos->clk);
+ ret = clk_prepare(exynos->clk);
+ if (ret) {
+ dev_err(dev, "failed to prepare clock\n");
+ goto err2;
+ }
+
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret) {
+ dev_err(dev, "failed to enable dwc3 device\n");
+ goto err3;
+ }
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
- goto err2;
+ goto err3;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
- goto err2;
+ goto err3;
}
return 0;
+err3:
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
err2:
- clk_disable_unprepare(clk);
+ clk_unprepare(clk);
+
err1:
return ret;
}
@@ -171,7 +187,9 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
- clk_disable_unprepare(exynos->clk);
+ pm_runtime_put_sync(exynos->dev);
+ pm_runtime_disable(exynos->dev);
+ clk_unprepare(exynos->clk);
return 0;
}
@@ -184,20 +202,33 @@ static const struct of_device_id exynos_dwc3_match[] = {
MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
#endif
-static int dwc3_exynos_suspend(struct device *dev)
+static int __dwc3_exynos_suspend(struct dwc3_exynos *exynos)
{
- struct dwc3_exynos *exynos = dev_get_drvdata(dev);
-
clk_disable(exynos->clk);
return 0;
}
+static int __dwc3_exynos_resume(struct dwc3_exynos *exynos)
+{
+ return clk_enable(exynos->clk);
+}
+
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_suspend(exynos);
+}
+
static int dwc3_exynos_resume(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ int ret;
- clk_enable(exynos->clk);
+ ret = __dwc3_exynos_resume(exynos);
+ if (ret)
+ return ret;
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
@@ -207,8 +238,24 @@ static int dwc3_exynos_resume(struct device *dev)
return 0;
}
+static int dwc3_exynos_runtime_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_suspend(exynos);
+}
+
+static int dwc3_exynos_runtime_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ return __dwc3_exynos_resume(exynos);
+}
+
static const struct dev_pm_ops dwc3_exynos_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_exynos_suspend, dwc3_exynos_resume)
+ SET_RUNTIME_PM_OPS(dwc3_exynos_runtime_suspend,
+ dwc3_exynos_runtime_resume, NULL)
};
static struct platform_driver dwc3_exynos_driver = {
--
1.8.4.GIT
--
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] usb: dwc3: pci: add pm_runtime support
teach the PCI glue about pm_runtime so that
it's easier to teach dwc3 core about it
later.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-pci.c | 66 ++---
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 665686e..78cd0b0 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -109,18 +109,17 @@ static int dwc3_pci_probe(struct pci_dev *pci,
glue->dev = dev;
- ret = pci_enable_device(pci);
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret) {
dev_err(dev, "failed to enable pci device\n");
return -ENODEV;
}
- pci_set_master(pci);
-
ret = dwc3_pci_register_phys(glue);
if (ret) {
dev_err(dev, "couldn't register PHYs\n");
- return ret;
+ goto err1;
}
dwc3 = platform_device_alloc("dwc3", PLATFORM_DEVID_AUTO);
@@ -167,7 +166,8 @@ static int dwc3_pci_probe(struct pci_dev *pci,
err3:
platform_device_put(dwc3);
err1:
- pci_disable_device(pci);
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
return ret;
}
@@ -175,11 +175,13 @@ err1:
static void dwc3_pci_remove(struct pci_dev *pci)
{
struct dwc3_pci *glue = pci_get_drvdata(pci);
+ struct device *dev = &pci->dev;
platform_device_unregister(glue->dwc3);
platform_device_unregister(glue->usb2_phy);
platform_device_unregister(glue->usb3_phy);
- pci_disable_device(pci);
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
}
static const struct pci_device_id dwc3_pci_id_table[] = {
@@ -193,24 +195,20 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
-#ifdef CONFIG_PM_SLEEP
-static int dwc3_pci_suspend(struct device *dev)
+static int __dwc3_pci_suspend(struct pci_dev *pci)
{
- struct pci_dev *pci = to_pci_dev(dev);
-
pci_disable_device(pci);
return 0;
}
-static int dwc3_pci_resume(struct device *dev)
+static int __dwc3_pci_resume(struct pci_dev *pci)
{
- struct pci_dev *pci = to_pci_dev(dev);
- int ret;
+ int ret;
ret = pci_enable_device(pci);
if (ret) {
- dev_err(dev, "can't re-enable device --> %d\n", ret);
+ dev_err(&pci->dev, "can't re-enable device --> %d\n", ret);
return ret;
}
@@ -218,10 +216,48 @@ static int dwc3_pci_resume(struct device *dev)
return 0;
}
-#endif /* CONFIG_PM_SLEEP */
+
+static int dwc3_pci_suspend(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+
+ return __dwc3_pci_suspend(pci);
+}
+
+static int dwc3_pci_resume(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+ int ret;
+
+ ret = __dwc3_pci_resume(pci);
+ if (ret)
+ return ret;
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_disable(dev);
+
+ return 0;
+}
+
+static int dwc3_pci_runtime_suspend(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+
+ return __dwc3_pci_suspend(pci);
+}
+
+static int dwc3_pci_runtime_resume(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+
+ return __dwc3_pci_resume(pci);
+}
static const struct dev_pm_ops dwc3_pci_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_pci_suspend, dwc3_pci_resume)
+ SET_RUNTIME_PM_OPS(dwc3_pci_runtime_suspend, dwc3_pci_runtime_resume,
+ NULL)
};
static struct pci_driver dwc3_pci_driver = {
--
1.8.4.GIT
--
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/7] usb: dwc3: keystone: add basic PM support
A bare-minimum PM implementation which will
server as building block for more complex
PM implementation in the future.
At the least will not leave clocks on unnecessarily
when e.g. a user write mem to /sys/power/state.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-keystone.c | 97 ++--
1 file changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index 1fad161..361437f 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -118,13 +119,23 @@ static int kdwc3_probe(struct platform_device *pdev)
kdwc->clk = devm_clk_get(kdwc->dev, "usb");
- error = clk_prepare_enable(kdwc->clk);
+ error = clk_prepare(kdwc->clk);
if (error < 0) {
dev_dbg(kdwc->dev, "unable to enable usb clock, err %d\n",
error);
return error;
}
+ pm_runtime_enable(dev);
+
+ error = pm_runtime_get_sync(dev);
+ if (error < 0) {
+ dev_dbg(dev, "unable to pm_runtime_get_sync(), err %d\n",
+ error);
+ pm_runtime_put_sync(dev);
+ goto err_runtime_get;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "missing irq\n");
@@ -151,8 +162,13 @@ static int kdwc3_probe(struct platform_device *pdev)
err_core:
kdwc3_disable_irqs(kdwc);
+
err_irq:
- clk_disable_unprepare(kdwc->clk);
+ pm_runtime_put_sync(dev);
+
+err_runtime_get:
+ pm_runtime_disable(dev);
+ clk_unprepare(kdwc->clk);
return error;
}
@@ -172,7 +188,9 @@ static int kdwc3_remove(struct platform_device *pdev)
kdwc3_disable_irqs(kdwc);
device_for_each_child(&pdev->dev, NULL, kdwc3_remove_core);
- clk_disable_unprepare(kdwc->clk);
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ clk_unprepare(kdwc->clk);
platform_set_drvdata(pdev, NULL);
return 0;
@@ -184,6 +202,79 @@ static const struct of_device_id kdwc3_of_match[] = {
};
MODULE_DEVICE_TABLE(of, kdwc3_of_match);
+static int __kdwc3_suspend(struct dwc3_keystone *kdwc)
+{
+ clk_disable(kdwc->clk);
+
+ return 0;
+}
+
+static int __kdwc3_resume(struct dwc3_keystone *kdwc)
+{
+ return clk_enable(kdwc->clk);
+}
+
+static int kdwc3_prepare(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+
+ kdwc3_disable_irqs(kdwc);
+
+ return 0;
+}
+
+static void kdwc3_complete(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+
+ kdwc3_enable_irqs(kdwc);
+}
+
+static int kdwc3_suspend(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+
+ return __kdwc3_suspend(kdwc);
+}
+
+static int kdwc3_resume(struct device *dev)
+{
+ struct dwc3_keystone*kdwc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = __kdwc3_resume(kdwc);
+ if (ret)
+ return ret;
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int kdwc3_runtime_suspend(struct device *dev)
+{
+ struct dwc3_keystone *kdwc = dev_get_drvdata(dev);
+
+ return __kdwc3_suspend(kdwc);
+}
+
+static int kdwc3_runtime_resume(struct device *dev)
+{
+ struct dwc3_keystone *kdwc = dev_get_drvdata(dev);
+
+ return __kdwc3_resume(kdwc);
+}
+
+static const struct dev_pm_ops kdwc3_dev_pm_ops = {
+ .prepare= kdwc3_prepare,
+ .complete = kdwc3_complete,
+
+ SET_SYSTEM_SLEEP_PM_OPS(kdwc3_suspend, kdwc3_resume)
+ SET_RUNTIME_PM_OPS(kdwc3_runtime_suspend, kdwc3_runtime_resume, NULL)
+};
+
static struct platform_driver kdwc3_driver = {
.probe = kdwc3_probe,
.remove = kdwc3_remove,
--
1.8.4.GIT
--
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 4/7] usb: dwc3: omap: fix pm_runtime usage
even if pm_runtime_get*() fails, it still increments
pm usage counter, so we must pm_runtime_put*()
in that case too. Fix that observation in dwc3-omap.c.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/dwc3-omap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index aea305d..076bb28 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -451,7 +451,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
dev_err(dev, "get_sync failed with err %d\n", ret);
- goto err0;
+ goto err1;
}
reg = dwc3_omap_readl(omap->base, USBOTGSS_REVISION);
@@ -566,8 +566,6 @@ err2:
err1:
pm_runtime_put_sync(dev);
-
-err0:
pm_runtime_disable(dev);
return ret;
--
1.8.4.GIT
--
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 5/7] usb: dwc3: omap: fix order of pm_runtime vs child removal
pm_runtime_put_sync() will kill dwc3's clocks and, since dwc3 core accesses registers during removal, we must make sure to unregister core before disabling clocks and pm_runtime. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/dwc3-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index 076bb28..a9090a1 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -580,9 +580,9 @@ static int dwc3_omap_remove(struct platform_device *pdev) if (omap->extcon_id_dev.edev) extcon_unregister_interest(&omap->extcon_id_dev); dwc3_omap_disable_irqs(omap); + device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core); pm_runtime_put_sync(&pdev->dev); pm_runtime_disable(&pdev->dev); - device_for_each_child(&pdev->dev, NULL, dwc3_omap_remove_core); return 0; } -- 1.8.4.GIT -- 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: WG: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
Hi Grazvydas,
Von: Grazvydas Ignotas [mailto:nota...@gmail.com]
Gesendet: Donnerstag, 12. Dezember 2013 01:21
An: linux-...@vger.kernel.org
Cc: Felipe Balbi; linux-omap@vger.kernel.org; Naumann Andreas; Grazvydas
Ignotas; sta...@vger.kernel.org
Betreff: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c "omap2+: save and restore OTG_INTERFSEL",
which introduces save/restore of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it is 0
(0 should never be saved in the context as it's invalid value,
so we use it as an indicator that context hasn't been saved yet).
This issue was originally found by Andreas Naumann:
http://marc.info/?l=linux-usb&m=138562574719654&w=2
Reported-and-bisected-by: Andreas Naumann
Signed-off-by: Grazvydas Ignotas
Cc:
---
This is a regression from 3.2, so should go to -rc and stable, IMO.
It's really annoying issue if you want to have a stable OTG behavior,
I've burned quite a lot of time on it myself over a year ago and gave up
eventually. Good thing Andreas finally found it, many thanks to him!
drivers/usb/musb/omap2430.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..737b3da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -672,7 +672,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb->mregs, OTG_INTERFSEL,
+ if (musb->context.otg_interfsel != 0)
+ musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
phy_power_on(musb->phy);
}
Oh, easy way out. I like it but I've also been thinking about your
comment on my original post, which was that initializing otg_interfsel
to the PHYSEL bits only might be dangerous because we cant be sure that
there are other bits in the register.
However, isnt assuming that 0 is invalid on all OMAPs just as dangerous?
After thinking about my patch again, I would propose to change
otg_interfsel into otg_physel and read-modify-write only those bits in
resume() as you suggested in your first answer. That way I could discard
the problematic first read in probe() while leaving other bits
untouched. If you agree I post a patch for this tomorrow.
cheers,
Andreas
--
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/3] arm: omap2: Export devconf1 bypass and acbias.
On Thu, Dec 12, 2013 at 09:31:02AM +0100, Belisko Marek wrote: > Hi Tony, > > On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren wrote: > > * Belisko Marek [131210 14:13]: > >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren wrote: > >> > > >> > It would be best to set it up as omap-ctrl.c driver under drivers > >> > somewhere with few functions exported for DSS and MMC drivers. > >> > >> I create small dummy driver based on phy-omap-control which can be > >> used but before sending patch (with more updates) I would like to get > >> some feedback if my direction is correct. > > > > Cool thanks. Yeah what you have can easily be combined with the patches > > Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap > > for the SCM register access. Maybe take a look at the work in progress > > patches in thread: > > > > [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup > > > > And also see my comments regarding using the SCM GENERAL register area > > as base for the syscon.c driver. That should work for your driver too, > > right? And then you can access the SYSCON1 register that way from your > > consumer driver ;) > > If I understand correclty I can use syscon driver (it will have in > range also devconf1 register) ad get rid of my custom driver > and then get regmap from syscon and update bits that I need for venc, right? Yeah something like that. Or since the sysconf1 register is shared, it might be best to still provide specific functions to access it if we cannot map just specific bits of it separately for drivers using regmap. But anyways this should for most part remove the need for a custom driver(s) unless the register is a regulator or a clock. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers: net: cpsw: fix for cpsw crash when build as modules
From: Felipe Balbi Date: Wed, 11 Dec 2013 22:09:05 -0600 > From: Mugunthan V N > > When CPSW and Davinci MDIO are build as modules, CPSW crashes when > accessing CPSW registers in CPSW probe. The same is working in built-in > as the CPSW clocks are enabled in Davindi MDIO probe, SO Enabling the > clocks before accessing the version register and moving out the other > register access to cpsw device open. > > Signed-off-by: Mugunthan V N > Signed-off-by: Felipe Balbi Applied, thanks. -- 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/RFT/PATCH V3] gpio: omap: refresh patch "be more aggressive with pm_runtime" against v3.12-rc5
On Thu, Dec 12, 2013 at 7:28 PM, Felipe Balbi wrote: > On Thu, Dec 12, 2013 at 07:19:35PM +0100, Linus Walleij wrote: >> One thing caught my eye, you add: >> >> > +static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank) >> > +static void _aggressive_pm_runtime_put(struct gpio_bank *bank) >> (..) >> >> Then everywhere: >> >> > + _aggressive_pm_runtime_get_sync(bank); >> (...) >> > + _aggressive_pm_runtime_put(bank); >> >> Aggressive, argh, runtime PM is agressive by definition. If you >> want to switch this on and off use the compile option >> to enable/disable runtime PM altogether and do not wrap it >> like this. > > heh, OMAP doesn't work without pm_runtime. Hm then maybe that needs to be fixed ... or the runtime PM people need to be convinced to support different levels of aggressiveness in the core? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT/PATCH V3] gpio: omap: refresh patch "be more aggressive with pm_runtime" against v3.12-rc5
On Thu, Dec 12, 2013 at 07:19:35PM +0100, Linus Walleij wrote: > On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu wrote: > > > From: Felipe Balbi > > > > try to keep gpio block suspended as much as possible. > > > > Tested with pandaboard and a sysfs exported gpio. > > > > Signed-off-by: Felipe Balbi > > > > [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added > > revision check to enable aggressive pm_runtime on OMAP4-only. Because > > am33xx_gpio_sysc.idlemodes seems to be wrongly marked as > > SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. > > Tested on Pandaboard rev A2.] > > Signed-off-by: Chao Xu > > --- > > changes since v2: > > *add wrapper function to avoid 'is_aggressive_pm' check everywhere, as > > suggested by Santosh Shilimkar > > *fix format issue in commit log > > I'm dropping this until you convince Kevin/Tony that this is > the way to go. > > One thing caught my eye, you add: > > > +static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank) > > +static void _aggressive_pm_runtime_put(struct gpio_bank *bank) > (..) > > Then everywhere: > > > + _aggressive_pm_runtime_get_sync(bank); > (...) > > + _aggressive_pm_runtime_put(bank); > > Aggressive, argh, runtime PM is agressive by definition. If you > want to switch this on and off use the compile option > to enable/disable runtime PM altogether and do not wrap it > like this. heh, OMAP doesn't work without pm_runtime. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/7] usb: dwc3: get "usb_phy" only if the platform indicates the presence of PHY's
On Mon, Dec 09, 2013 at 10:52:45AM +0200, Heikki Krogerus wrote: > Hi, > > On Fri, Dec 06, 2013 at 02:15:30PM -0600, Felipe Balbi wrote: > > On Tue, Dec 03, 2013 at 12:39:50PM +0200, Heikki Krogerus wrote: > > > On Thu, Oct 17, 2013 at 09:54:26AM -0500, Felipe Balbi wrote: > > > > On Wed, Oct 16, 2013 at 04:27:26PM +0300, Roger Quadros wrote: > > > > > On 10/16/2013 04:10 PM, Kishon Vijay Abraham I wrote: > > > > > Do you know if there are users of dwc3 other than exynos5250 and > > > > > omap5? > > > > > If not, we should get rid of the old USB PHY altogether. > > > > > > > > Intel's Baytrail, at least. But they don't use DT. > > > > > > I don't see any use for the generic-phy when the device is enumerated > > > from PCI. If dwc3 can live without phys, there should not be any > > > problem dropping the old USB PHY support. > > > > yeah, I don't want to drop PHY support, I want to require everybody to > > provide a PHY, otherwise we have too many options to handle and that's > > never clean. > > I have to clarify in case there was a misunderstanding. When I said > generic-phy I meant drivers/usb/phy/phy-generic.c and I was not > talking about Kishon's new generic PHY framework. > > So I was only saying that if the dwc3-pci.c is the only thing that > needs the old usb phy support, then there should not be any problem > dropping the support for it. oh, ok. Got it now, thanks. -- balbi signature.asc Description: Digital signature
Re: [RFC/RFT/PATCH V3] gpio: omap: refresh patch "be more aggressive with pm_runtime" against v3.12-rc5
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu wrote: > From: Felipe Balbi > > try to keep gpio block suspended as much as possible. > > Tested with pandaboard and a sysfs exported gpio. > > Signed-off-by: Felipe Balbi > > [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added > revision check to enable aggressive pm_runtime on OMAP4-only. Because > am33xx_gpio_sysc.idlemodes seems to be wrongly marked as > SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. > Tested on Pandaboard rev A2.] > Signed-off-by: Chao Xu > --- > changes since v2: > *add wrapper function to avoid 'is_aggressive_pm' check everywhere, as > suggested by Santosh Shilimkar > *fix format issue in commit log I'm dropping this until you convince Kevin/Tony that this is the way to go. One thing caught my eye, you add: > +static void _aggressive_pm_runtime_get_sync(struct gpio_bank *bank) > +static void _aggressive_pm_runtime_put(struct gpio_bank *bank) (..) Then everywhere: > + _aggressive_pm_runtime_get_sync(bank); (...) > + _aggressive_pm_runtime_put(bank); Aggressive, argh, runtime PM is agressive by definition. If you want to switch this on and off use the compile option to enable/disable runtime PM altogether and do not wrap it like this. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
On Thu, Dec 12, 2013 at 04:19:01PM +0200, Tomi Valkeinen wrote: > On 2013-12-12 16:15, Laurent Pinchart wrote: > > > As you mentioned in your previous e-mail, if the labels are used by omapfb > > only, I won't strongly push to keep them. I wonder, however, when using > > DRM/KMS, where do the connector labels that are displayed by xrandr for > > instance come from ? > > drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A", > for connectors and encoders. Maybe from those. The xrandr names are generated from the list Tomi mentioned. => drm_connector_enum_list This requires a mapping from omapdss types to DRM types, which is done in drivers/gpu/drm/omapdrm/omap_drv.c:get_connector_type(). Currently only HDMI and DVI are handled properly. -- Sebastian signature.asc Description: Digital signature
Re: need help to configure IRQ on gpio 139 pandaboard using device tree
On 12/12/2013 09:05 AM, Denis CIOCCA wrote: why is mcspi1 your interrupt parent when you did a padconf for GPIO? you want GPIO136, so you need the right gpio block as the interrupt parent and map interrupts in the correct map. see [1] for an example (omap2). Oh my god! Now I've understand how device tree works...I'm sorry Nishanth but the dt it's new for me...ok I'm using gpio5 and now it works! +interrupt-parent = <&gpio5>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 136 */ Thank you very much for your patience...;) glad to hear it worked, yeah, device tree is a little different, but logical in it's own way. 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/2] drivers: net: cpsw: fix dt probe for one port ethernet
Hi, On Thu, Dec 12, 2013 at 01:41:11PM +0530, Mugunthan V N wrote: > On Thursday 12 December 2013 09:39 AM, Felipe Balbi wrote: > > From: Mugunthan V N > > > > When only one port of the two port is pinned out, then dt probe is failing > > because second port phy is not found. fixing this by checking the number of > > slaves and breaking the loop. > > > > Signed-off-by: Mugunthan V N > > Signed-off-by: Felipe Balbi > > This patch is already applied to net branch and its commit id is > 3a27bfac17fe375539c4e0a53478679645eb5ae2. Ok, cool. Should it be backported to v3.12 stable tree ? I can see it's applicable there too. -- balbi signature.asc Description: Digital signature
[PATCH] ARM: configs: Select USB PHY for AM335x SoC
Enable this option as it's required to use USB on AM335x SoC. Signed-off-by: Ezequiel Garcia --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 12c848e..e427b95 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -223,6 +223,7 @@ CONFIG_USB_TEST=y CONFIG_NOP_USB_XCEIV=y CONFIG_OMAP_USB2=y CONFIG_OMAP_USB3=y +CONFIG_AM335X_PHY_USB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/7] regulator: add pbias regulator support
On Wednesday 11 December 2013 12:03 AM, Tony Lindgren wrote:
* Balaji T K [131210 06:36]:
pbias register controls internal power supply to sd card i/o pads
in most OMAPs (OMAP2-5, DRA7).
Control bits for selecting voltage level and
enabling/disabling are in the same PBIAS register.
Good to see this, few comments below.
+++ lo/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
2013-12-10 16:58:28.907927745 +0530
@@ -0,0 +1,21 @@
+PBIAS internal regulator for SD card i/o pads on OMAP SoCs.
+
+Required properties:
+- compatible:
+ - "regulator-pbias-omap2" for OMAP2
+ - "regulator-pbias-omap3" for OMAP3
+ - "regulator-pbias-omap4" for OMAP4
+ - "regulator-pbias-omap5" for OMAP5, DRA7
+- pbias-reg-offset: PBIAS control register offset from syscon base address
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ pbias_regulator: pbias_regulator {
+ pbias-reg-offset = <0>;
+ regulator-name = "pbias_regulator";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ };
This does not seem to support the other PBIAS controls the same
register has?
Hi Tony,
Thanks for the comments,
@@ -369,6 +369,15 @@ config REGULATOR_PALMAS
on the muxing. This is handled automatically in the driver by
reading the mux info from OTP.
+config REGULATOR_PBIAS
+ tristate "PBIAS OMAP regulator driver"
+ depends on (ARCH_OMAP || COMPILE_TEST) && MFD_SYSCON
+ help
+Say y here to support pbias regulator for mmc1:SD card i/o
+on OMAP SoCs.
+This driver provides support for OMAP pbias modelled
+regulators.
+
The PBIAS register is not just for MMC. Depending on the SoC revision,
yes, SIM pbias bit mapping are similar to MMC.
I will try to add sim pbias to my next version.
you may also have 2 - 3 PBIAS devices in the same register. Please check
the 2430 TRM, it has also I2C secondary pulls in this same register. And
This regulator driver will only control bits related to voltage settings
and is not touching other bits by using masks.
on 3430, there PBIAS register has also SIM voltage bits.
Certainly nothing stops from intially implementing the MMC pieces
as those are needed badly, but it should be done in a way where adding
support for the other PBIAS bits can be done easily.
yes, It can be easily done for SIM pbias control.
You're also missing the PBIAS interrupts, so it might be worth checking
the code from that point of view also to make sure adding the support
for interrupts won't require massive changes to the driver.
PBIAS interrupts were never used in non-dt case, so did not consider
while adapting for DT. However it can be added later on.
Thanks and Regards,
Balaji T K
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
> why is mcspi1 your interrupt parent when you did a padconf for GPIO? > you want GPIO136, so you need the right gpio block as the interrupt > parent and map interrupts in the correct map. > see [1] for an example (omap2). Oh my god! Now I've understand how device tree works...I'm sorry Nishanth but the dt it's new for me...ok I'm using gpio5 and now it works! +interrupt-parent = <&gpio5>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 136 */ Thank you very much for your patience...;) BR, Denis-- 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 5/7] ARM: dts: add pbias dt node
On Wednesday 11 December 2013 04:12 AM, Tony Lindgren wrote:
* Balaji T K [131210 02:17]:
Add pbias regulator node as a child of system control
module - syscon.
Signed-off-by: Balaji T K
---
arch/arm/boot/dts/dra7.dtsi | 14 ++
arch/arm/boot/dts/omap2430.dtsi | 14 ++
arch/arm/boot/dts/omap3.dtsi| 14 ++
arch/arm/boot/dts/omap4.dtsi| 14 ++
arch/arm/boot/dts/omap5.dtsi| 14 ++
5 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d0df4c4..1a52676 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -119,6 +119,19 @@
pinctrl-single,function-mask = <0x3fff>;
};
+ tisyscon: tisyscon@4A100600 {
+ compatible = "ti,control-syscon", "syscon",
"simple-bus";
+ reg = <0x4A002E00 0x4>;
This should map the whole GENERAL area of the SCM register space instead
in one or multiple sections or driver instances. This way the same driver
can be used for the misc SCM registers from other drivers.
Hi,
OK, make sense, others driver wont have to patch the base address later on.
If you don't define it that way now, you'll end up with broken child driver
offsets in the .dts files later on.
yes, Unless someone changes the base and not the offset, given that all are in
one dtsi
+ pbias_regulator: pbias_regulator {
+ compatible = "regulator-pbias-omap5";
+ pbias-reg-offset = <0>;
+ regulator-name = "pbias_regulator";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ regulator-enable-ramp-delay = <10>;
Then the pbias_regulator needs to have the standard reg property as an
offset from the SCM GENERAL base address.
OK
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
On 12/12/2013 08:27 AM, Denis CIOCCA wrote:
> Maybe, this is more correctly but still doesn't work...
>
>
> From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
> From: Denis Ciocca
> Date: Thu, 12 Dec 2013 14:52:39 +0100
> Subject: [PATCH] device tree
>
> ---
> arch/arm/boot/dts/omap4-panda-es.dts | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 816d1c9..82c3eb7 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -41,6 +41,12 @@
> 0xb6 (PIN_OUTPUT | MUX_MODE3)/* gpio_110 */
> >;
> };
> +
> +lsm6db0_pins: lsm6db0_pins {
> +pinctrl-single,pins = <
> +0xf6 (PIN_INPUT | MUX_MODE3) /* mcspi1_simo.gpio_136 */
> +>;
> +};
> };
>
> &led_wkgpio_pins {
> @@ -49,6 +55,22 @@
> >;
> };
>
> +&i2c4 {
> +pinctrl-names = "default";
> +pinctrl-0 = <&i2c4_pins>;
> +
> +clock-frequency = <40>;
> +
> +lsm6db0@03 {
> +pinctrl-names = "default";
> +pinctrl-0 = <&lsm6db0_pins>;
> +compatible = "st,lsm6db0";
> +reg = <0x03>;
> +interrupts = <&mcspi1 136 IRQ_TYPE_LEVEL_HIGH>;
> +interrupt-parent = <&mcspi1>;
why is mcspi1 your interrupt parent when you did a padconf for GPIO?
you want GPIO136, so you need the right gpio block as the interrupt
parent and map interrupts in the correct map.
see [1] for an example (omap2).
> +};
> +};
> +
> &leds {
> pinctrl-0 = <
> &led_gpio_pins
>
[1]
https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tree/arch/arm/boot/dts/omap2430-sdp.dts?id=omap-for-v3.14/omap3-board-removal-wl1251#n42
--
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: need help to configure IRQ on gpio 139 pandaboard using device tree
Maybe, this is more correctly but still doesn't work...
From 9f6e524fa86834c3ab9a5f710021620a103019b2 Mon Sep 17 00:00:00 2001
From: Denis Ciocca
Date: Thu, 12 Dec 2013 14:52:39 +0100
Subject: [PATCH] device tree
---
arch/arm/boot/dts/omap4-panda-es.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..82c3eb7 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,12 @@
0xb6 (PIN_OUTPUT | MUX_MODE3)/* gpio_110 */
>;
};
+
+lsm6db0_pins: lsm6db0_pins {
+pinctrl-single,pins = <
+0xf6 (PIN_INPUT | MUX_MODE3) /* mcspi1_simo.gpio_136 */
+>;
+};
};
&led_wkgpio_pins {
@@ -49,6 +55,22 @@
>;
};
+&i2c4 {
+pinctrl-names = "default";
+pinctrl-0 = <&i2c4_pins>;
+
+clock-frequency = <40>;
+
+lsm6db0@03 {
+pinctrl-names = "default";
+pinctrl-0 = <&lsm6db0_pins>;
+compatible = "st,lsm6db0";
+reg = <0x03>;
+interrupts = <&mcspi1 136 IRQ_TYPE_LEVEL_HIGH>;
+interrupt-parent = <&mcspi1>;
+};
+};
+
&leds {
pinctrl-0 = <
&led_gpio_pins
--
1.7.9.5
No one can help me?
Thanks,
Denis
--
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 06/26] OMAPDSS: if dssdev->name==NULL, use alias
On 2013-12-12 16:15, Laurent Pinchart wrote: > As you mentioned in your previous e-mail, if the labels are used by omapfb > only, I won't strongly push to keep them. I wonder, however, when using > DRM/KMS, where do the connector labels that are displayed by xrandr for > instance come from ? drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A", for connectors and encoders. Maybe from those. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
Hi Tomi,
On Thursday 12 December 2013 16:13:04 Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
> > On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> >>> A label property is still an option.
> >>
> >> Hmm, what do you mean? Label as in:
> >>
> >> foo : node {
> >> };
> >>
> >> Isn't that 'foo' label only visible in DT itself, as a shortcut?
> >
> > Some driver use a "label" property like this:
> >
> > foo : node {
> >
> > label = "lcd";
> >
> > ...
> >
> > };
> >
> > See for example
> >
> > Documentation/devicetree/bindings/leds/common.txt
> > Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
As you mentioned in your previous e-mail, if the labels are used by omapfb
only, I won't strongly push to keep them. I wonder, however, when using
DRM/KMS, where do the connector labels that are displayed by xrandr for
instance come from ?
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
On 2013-12-12 12:05, Sebastian Reichel wrote:
> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
>>> A label property is still an option.
>>
>> Hmm, what do you mean? Label as in:
>>
>> foo : node {
>> };
>>
>> Isn't that 'foo' label only visible in DT itself, as a shortcut?
>
> Some driver use a "label" property like this:
>
> foo : node {
> label = "lcd";
>
> ...
> };
>
> See for example
>
> Documentation/devicetree/bindings/leds/common.txt
> Documentation/devicetree/bindings/mtd/partition.txt
Ah, I see. That kind of label was actually the first thing I did when
starting to work on DSS DT. But I removed it, as it didn't describe the
hardware and I didn't see others using anything similar.
But I guess one could argue it does describe hardware, not in electrical
level but in conceptual level.
The question is, do we need labeling for displays? For backward
compatibility omapdss would need it, but in general? I'm quite content
with having just display0, display1 etc. Using the alias node, those can
be fixed and display0 is always the same display.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH/RFC] pwm: omap: Add PWM support using dual-mode timers
On Thu, Oct 24, 2013 at 05:36:20PM +1100, NeilBrown wrote:
>
> I submitted this in December last year. I got lots of good feedback
> and fixed some things, but it never got accepted. Not entirely sure
> why, maybe I dropped the ball.
>
> Anyway, here is again with device-tree support added.
>
> This is only an RFC and not a real submission for two reasons, both of which
> are really directed as Jon.
>
> 1/ I have to
>
> #include <../arch/arm/plat-omap/include/plat/dmtimer.h>
>
> which is incredibly ugly.
> Is there any reason this cannot be moved to include/linux/omap-dmtimer.h?
>
> 2/ I found that I need to call
>
> omap_dm_timer_write_counter(omap->dm_timer, DM_TIMER_LOAD_MIN);
>
> when using device-tree. This is because with devicetree
> omap_timer_restore_context() is called much more often and it sets the
> counter
> register to 0 .. it takes a long time to count up to DM_TIMER_LOAD_MIN from
> there.
>
> Now I don't object to calling omap_dm_timer_write_counter (though it might
> be nice if
> omap_dm_timer_set_load wrote the one value to both LOAD_REG and COUNTER_REG).
> However it seems wrong that I have to call it *after* starting the counter.
> Currently _write_counter refuses to run if the timer hasn't been started.
>
> So Jon:
>a/ can we change omap_dm_timer_write_counter to work when the timer isn't
> running?
>b/ can we have omap_dm_timer_set_load also set the counter?
>
>
> For anyone else generous enough to read my code: is this otherwise acceptable?
>
> Thanks,
> NeilBrown
>
> -
> This patch is based on an earlier patch by Grant Erickson
> which provided PWM devices using the 'legacy' interface.
>
> This driver instead uses the new framework interface.
>
> The choice of dmtimer to be used can be made through platform_data
> by requesting a specific timer, or though devicetree by giving
> the appropriate device-tree node.
>
> Lots of clean-ups and improvements thanks to Thierry Reding
> and Jon Hunter.
>
> Cc: Grant Erickson
> Signed-off-by: NeilBrown
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap.txt
> b/Documentation/devicetree/bindings/pwm/pwm-omap.txt
> new file mode 100644
> index 000..5f03048
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-omap.txt
> @@ -0,0 +1,32 @@
> +* PWM for OMAP using dmtimers
> +
> +TI's OMAP SoCs contains dual mode timers (dmtimers), some of
> +which can driver output pins and so provide services as
s/driver/drive/
> +a PWM. When using this driver it will normally be necessary
> +to programmer an appropriate pin to server as a timer output.
s/programmer/program/ and s/server/serve/
> +
> +Required properties:
> +- compatible: must be
> + "ti,omap-pwm"
> +
> +- timers: a device-tree node for the dmtimer to use
> +
> +- #pwm-cells: must be <2>.
The canonical form to write this these days is:
- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of
the cells format.
> +
> +Example:
> +
> + pwm: omap-pwm {
> + compatible = "ti,omap-pwm";
> + timers = <&timer11>;
> + #pwm-cells = <2>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm-pins>;
> + };
> +
> +...
> + pwm-pins: pinmux_pwm_pins {
I don't think dashes work in labels or phandles. They do work in node
names, though, so this could be:
pwm_pins: pinmux-pwm-pins {
...
};
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 75840b5..0e3cf83 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -110,6 +110,15 @@ config PWM_PCA9685
> To compile this driver as a module, choose M here: the module
> will be called pwm-pca9685.
>
> +config PWM_OMAP
This doesn't seem to be properly ordered now. I suspect that back when
you posted that last time PCA9685 support hadn't been merged yet and the
rebase messed this up.
I wonder: does the OMAP not have dedicated PWM hardware?
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 77a8c18..322ddf0 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
> obj-$(CONFIG_PWM_LPC32XX)+= pwm-lpc32xx.o
> obj-$(CONFIG_PWM_MXS)+= pwm-mxs.o
> obj-$(CONFIG_PWM_PCA9685)+= pwm-pca9685.o
> +obj-$(CONFIG_PWM_OMAP) += pwm-omap.o
> obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
Same ordering issue here.
> diff --git a/drivers/pwm/pwm-omap.c b/drivers/pwm/pwm-omap.c
[...]
> +/*
> + *Copyright (c) 2012 NeilBrown
I guess that'd include 2013 now?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
I'd prefer these to be sorted alphabetically.
> +#include <../arch/arm/plat-omap/include/plat/dmtimer.h>
> +
> +#define DM_TIMER_LOAD_MIN0xFFFE
> +
> +struct omap_chip {
> + struct omap_dm_timer
Re: need help to configure IRQ on gpio 139 pandaboard using device tree
Hi Nishant,
I've configured the device tree as you told me. Now, my device tree code
is that:
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..5644260 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -41,6 +41,12 @@
0xb6 (PIN_OUTPUT | MUX_MODE3)/* gpio_110 */
>;
};
+
+lsm6db0_pins: lsm6db0_pins {
+pinctrl-single,pins = <
+0xfc (PIN_INPUT | MUX_MODE3) /* mcspi1_cs2.gpio_139 */
+>;
+};
};
&led_wkgpio_pins {
@@ -49,6 +55,22 @@
>;
};
+&i2c4 {
+pinctrl-names = "default";
+pinctrl-0 = <&i2c4_pins>;
+
+clock-frequency = <40>;
+
+lsm6db0@03 {
+pinctrl-names = "default";
+pinctrl-0 = <&lsm6db0_pins>;
+compatible = "st,lsm6db0";
+reg = <0x03>;
+interrupts = <139 0x1>;
+interrupt-parent = <&lsm6db0_pins>;
+};
+};
+
&leds {
pinctrl-0 = <
&led_gpio_pins
I've also read the documentation file
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
but I'm confused about the gpio muxed with mcspi1.
Do you think my patch is correct?
Thanks,
Denis
--
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 06/26] OMAPDSS: if dssdev->name==NULL, use alias
On Thursday 12 December 2013 11:05:28 Sebastian Reichel wrote:
> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> > > A label property is still an option.
> >
> > Hmm, what do you mean? Label as in:
> >
> > foo : node {
> > };
> >
> > Isn't that 'foo' label only visible in DT itself, as a shortcut?
>
> Some driver use a "label" property like this:
>
> foo : node {
> label = "lcd";
>
> ...
> };
Yes, that's what I meant.
> See for example
>
> Documentation/devicetree/bindings/leds/common.txt
> Documentation/devicetree/bindings/mtd/partition.txt
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH/RFC] pwm: omap: Add PWM support using dual-mode timers
On Tue, Oct 29, 2013 at 02:23:18PM -0700, Tony Lindgren wrote: > * NeilBrown [131023 23:36]: > > > > I submitted this in December last year. I got lots of good feedback > > and fixed some things, but it never got accepted. Not entirely sure > > why, maybe I dropped the ball. > > > > Anyway, here is again with device-tree support added. > > > > This is only an RFC and not a real submission for two reasons, both of which > > are really directed as Jon. > > > > 1/ I have to > > > > #include <../arch/arm/plat-omap/include/plat/dmtimer.h> > > > > which is incredibly ugly. > > Is there any reason this cannot be moved to include/linux/omap-dmtimer.h? > > Yes that's what at least dw_apb_timer and sh_timer are doing. > > > 2/ I found that I need to call > > > > omap_dm_timer_write_counter(omap->dm_timer, DM_TIMER_LOAD_MIN); > > > > when using device-tree. This is because with devicetree > > omap_timer_restore_context() is called much more often and it sets the > > counter > > register to 0 .. it takes a long time to count up to DM_TIMER_LOAD_MIN > > from there. > > > > Now I don't object to calling omap_dm_timer_write_counter (though it might > > be nice if > > omap_dm_timer_set_load wrote the one value to both LOAD_REG and > > COUNTER_REG). > > However it seems wrong that I have to call it *after* starting the counter. > > Currently _write_counter refuses to run if the timer hasn't been started. > > > > So Jon: > >a/ can we change omap_dm_timer_write_counter to work when the timer isn't > > running? > >b/ can we have omap_dm_timer_set_load also set the counter? > > > > > > For anyone else generous enough to read my code: is this otherwise > > acceptable? > > Did not look beyond the dmtimer stuff, but let's start by moving dmtimer.c to > live under drivers and move the header, then do the pwm patches. Why does the driver have to move? There is certainly some precedent for having arch-specific code in arch/ but expose the public API via some header in include/linux. Sometimes there's just no proper place for the driver elsewhere, so rather than moving it somewhere more or less random keeping it in arch/arm/plat-omap is just as good. Thierry pgpgGVxwWFraD.pgp Description: PGP signature
[PATCH v2 2/3] ARM: OMAP2+: Add support to parse optional clk info from DT
With clocks for OMAP moving to DT, its now possible to pass all optional clock
data for each device from DT instead of having it in hwmod.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c | 65 --
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f22..271634f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -807,6 +807,64 @@ static int _init_interface_clks(struct omap_hwmod *oh)
return ret;
}
+static const char **_parse_opt_clks_dt(struct omap_hwmod *oh,
+ struct device_node *np,
+ int *opt_clks_cnt)
+{
+ int i, clks_cnt;
+ const char *clk_name;
+ const char **opt_clk_names;
+
+ clks_cnt = of_property_count_strings(np, "clock-names");
+ if (!clks_cnt)
+ return NULL;
+
+ opt_clk_names = kzalloc(sizeof(char *)*clks_cnt, GFP_KERNEL);
+ if (!opt_clk_names)
+ return NULL;
+
+ for (i = 0; i < clks_cnt; i++) {
+ of_property_read_string_index(np, "clock-names", i, &clk_name);
+ if (!strcmp(clk_name, "fck"))
+ continue;
+ opt_clks_cnt++;
+ opt_clk_names[i] = clk_name;
+ }
+ return opt_clk_names;
+}
+
+static int _init_opt_clks_dt(struct omap_hwmod *oh, struct device_node *np)
+{
+ struct clk *c;
+ int i, opt_clks_cnt = 0;
+ int ret = 0;
+ const char **opt_clk_names;
+
+ opt_clk_names = _parse_opt_clks_dt(oh, np, &opt_clks_cnt);
+ if (!opt_clk_names)
+ return -EINVAL;
+
+ oh->opt_clks = kzalloc(sizeof(struct omap_hwmod_opt_clk *)
+ * opt_clks_cnt, GFP_KERNEL);
+ if (!oh->opt_clks)
+ return -ENOMEM;
+
+ oh->opt_clks_cnt = opt_clks_cnt;
+
+ for (i = 0; i < oh->opt_clks_cnt; i++) {
+ c = of_clk_get_by_name(np, opt_clk_names[i]);
+ if (IS_ERR(c)) {
+ pr_warn("omap_hwmod: %s: cannot clk_get opt_clk %s\n",
+ oh->name, opt_clk_names[i]);
+ ret = -EINVAL;
+ }
+ oh->opt_clks[i]._clk = c;
+ oh->opt_clks[i].role = opt_clk_names[i];
+ clk_prepare(oh->opt_clks[i]._clk);
+ }
+ return ret;
+}
+
/**
* _init_opt_clk - get a struct clk * for the the hwmod's optional clocks
* @oh: struct omap_hwmod *
@@ -814,13 +872,16 @@ static int _init_interface_clks(struct omap_hwmod *oh)
* Called from _init_clocks(). Populates the @oh omap_hwmod_opt_clk
* clock pointers. Returns 0 on success or -EINVAL on error.
*/
-static int _init_opt_clks(struct omap_hwmod *oh)
+static int _init_opt_clks(struct omap_hwmod *oh, struct device_node *np)
{
struct omap_hwmod_opt_clk *oc;
struct clk *c;
int i;
int ret = 0;
+ if (of_get_property(np, "clocks", NULL))
+ return _init_opt_clks_dt(oh, np);
+
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
c = clk_get(NULL, oc->clk);
if (IS_ERR(c)) {
@@ -1590,7 +1651,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data,
ret |= _init_main_clk(oh, np);
ret |= _init_interface_clks(oh);
- ret |= _init_opt_clks(oh);
+ ret |= _init_opt_clks(oh, np);
if (!ret)
oh->_state = _HWMOD_STATE_CLKS_INITED;
--
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
[PATCH v2 3/3] ARM: OMAP4: dts: Add main and optional clock data into DT
With support to parse clock data from DT, move all main and optional
clock information from hwmod to DT.
We still retain clocks in hwmod for devices which do not have a DT node.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap4.dtsi | 100 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 122
2 files changed, 100 insertions(+), 122 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c2e3993..7eb7920 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -139,6 +139,8 @@
compatible = "ti,omap-counter32k";
reg = <0x4a304000 0x20>;
ti,hwmods = "counter_32k";
+ clocks = <&sys_32k_ck>;
+ clock-names = "fck";
};
omap4_pmx_core: pinmux@4a100040 {
@@ -172,6 +174,8 @@
#dma-cells = <1>;
#dma-channels = <32>;
#dma-requests = <127>;
+ clocks = <&l3_div_ck>;
+ clock-names = "fck";
};
gpio1: gpio@4a31 {
@@ -184,6 +188,8 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ clocks = <&l4_wkup_clk_mux_ck>, <&gpio1_dbclk>;
+ clock-names = "fck", "dbclk";
};
gpio2: gpio@48055000 {
@@ -195,6 +201,8 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ clocks = <&l4_div_ck>, <&gpio2_dbclk>;
+ clock-names = "fck", "dbclk";
};
gpio3: gpio@48057000 {
@@ -206,6 +214,8 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ clocks = <&l4_div_ck>, <&gpio3_dbclk>;
+ clock-names = "fck", "dbclk";
};
gpio4: gpio@48059000 {
@@ -217,6 +227,8 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ clocks = <&l4_div_ck>, <&gpio4_dbclk>;
+ clock-names = "fck", "dbclk";
};
gpio5: gpio@4805b000 {
@@ -228,6 +240,8 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ clocks = <&l4_div_ck>, <&gpio5_dbclk>;
+ clock-names = "fck", "dbclk";
};
gpio6: gpio@4805d000 {
@@ -239,6 +253,8 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ clocks = <&l4_div_ck>, <&gpio6_dbclk>;
+ clock-names = "fck", "dbclk";
};
gpmc: gpmc@5000 {
@@ -259,6 +275,8 @@
interrupts = ;
ti,hwmods = "uart1";
clock-frequency = <4800>;
+ clocks = <&func_48m_fclk>;
+ clock-names = "fck";
};
uart2: serial@4806c000 {
@@ -267,6 +285,8 @@
interrupts = ;
ti,hwmods = "uart2";
clock-frequency = <4800>;
+ clocks = <&func_48m_fclk>;
+ clock-names = "fck";
};
uart3: serial@4802 {
@@ -275,6 +295,8 @@
interrupts = ;
ti,hwmods = "uart3";
clock-frequency = <4800>;
+ clocks = <&func_48m_fclk>;
+ clock-names = "fck";
};
uart4: serial@4806e000 {
@@ -283,6 +305,8 @@
interrupts = ;
ti,hwmods = "uart4";
clock-frequency = <4800>;
+ clocks = <&func_48m_fclk>;
+ clock-names = "fck";
};
hwspinlock: spinlock@4a0f6000 {
@@ -298,6 +322,8 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
+ clocks = <&func_96m_fclk>;
+ clock-names = "fck";
};
i2c2: i2c@48072000 {
@@ -307,6 +333,8 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
+
[PATCH v2 0/3] OMAP2+: hwmod: Add support to parse clock info from DT
v1 of this series was posted a while back [1] but there wasn't much that was concluded if the approach used in the series was acceptable or if there are better alternatives. So I am just doing a repost of these to see if we can conclude this time around. Needless to say, patches are based off Teros omap-clocks-to-dt v10 series [2] and I also pulled in Tonys fix to handle DT nodes with multiple 'ti,hwmod' values [3]. The approach taken in the series *does not* work for cases with multiple 'ti,hwmod' values and hence [3] helps me skip those instances for now. But based on some of the recent discussions on multiple 'ti-hwmod' values [4] it looks like its generally agreed upon that having DT nodes with multiple 'ti-hwmod' property is wrong and that those instances need to be fixed up anyway. [1] http://www.spinics.net/lists/linux-omap/msg95746.html [2] http://www.spinics.net/lists/devicetree/msg13455.html [3] http://www.spinics.net/lists/arm-kernel/msg288036.html [4] http://www.spinics.net/lists/arm-kernel/msg288023.html Rajendra Nayak (3): ARM: OMAP2+: Add support to parse 'main_clk' info from DT ARM: OMAP2+: Add support to parse optional clk info from DT ARM: OMAP4: dts: Add main and optional clock data into DT arch/arm/boot/dts/omap4.dtsi | 100 +++ arch/arm/mach-omap2/omap_hwmod.c | 88 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 122 3 files changed, 180 insertions(+), 130 deletions(-) -- 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
[PATCH v2 1/3] ARM: OMAP2+: Add support to parse 'main_clk' info from DT
With clocks for OMAP moving to DT, its now possible to pass the 'main_clk'
data for each device from DT instead of having it in hwmod.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index dfa878b..f22 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -730,14 +730,18 @@ static int _del_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh)
* functional clock pointer) if a main_clk is present. Returns 0 on
* success or -EINVAL on error.
*/
-static int _init_main_clk(struct omap_hwmod *oh)
+static int _init_main_clk(struct omap_hwmod *oh, struct device_node *np)
{
int ret = 0;
- if (!oh->main_clk)
+ if (!oh->main_clk && !of_get_property(np, "clocks", NULL))
return 0;
- oh->_clk = clk_get(NULL, oh->main_clk);
+ if (oh->main_clk)
+ oh->_clk = clk_get(NULL, oh->main_clk);
+ else
+ oh->_clk = of_clk_get_by_name(np, "fck");
+
if (IS_ERR(oh->_clk)) {
pr_warning("omap_hwmod: %s: cannot clk_get main_clk %s\n",
oh->name, oh->main_clk);
@@ -1565,19 +1569,26 @@ static int _init_clkdm(struct omap_hwmod *oh)
* Resolves all clock names embedded in the hwmod. Returns 0 on
* success, or a negative error code on failure.
*/
-static int _init_clocks(struct omap_hwmod *oh, void *data)
+static int _init_clocks(struct omap_hwmod *oh, void *data,
+ int index, struct device_node *np)
{
int ret = 0;
if (oh->_state != _HWMOD_STATE_REGISTERED)
return 0;
+ if (index) {
+ pr_warn("omap_hwmod: %s unable to parse clock data from %s\n",
+ oh->name, np->name);
+ np = NULL;
+ }
+
pr_debug("omap_hwmod: %s: looking up clocks\n", oh->name);
if (soc_ops.init_clkdm)
ret |= soc_ops.init_clkdm(oh);
- ret |= _init_main_clk(oh);
+ ret |= _init_main_clk(oh, np);
ret |= _init_interface_clks(oh);
ret |= _init_opt_clks(oh);
@@ -2500,7 +2511,7 @@ static int __init _init(struct omap_hwmod *oh, void *data)
}
}
- r = _init_clocks(oh, NULL);
+ r = _init_clocks(oh, NULL, index, np);
if (r < 0) {
WARN(1, "omap_hwmod: %s: couldn't init clocks\n", oh->name);
return -EINVAL;
--
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] ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
Hi Rajendra,
On Thursday 12 December 2013 03:22 PM, Rajendra Nayak wrote:
> With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
> DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
> to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
>
> On DRA7 though, we seem to be missing this flag, and atleast on the DRA7 EVM
> where we use uart1 for console, boot fails with DEBUG_LL enabled.
>
> Reported-by: Lokesh Vutla
> Signed-off-by: Rajendra Nayak
Tested on DRA7 evm using Tero's V10 clock series.
Tested-by: Lokesh Vutla
Thanks and regards,
Lokesh
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index db32d53..18f333c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1637,7 +1637,7 @@ static struct omap_hwmod dra7xx_uart1_hwmod = {
> .class = &dra7xx_uart_hwmod_class,
> .clkdm_name = "l4per_clkdm",
> .main_clk = "uart1_gfclk_mux",
> - .flags = HWMOD_SWSUP_SIDLE_ACT,
> + .flags = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP2UART1_FLAGS,
> .prcm = {
> .omap4 = {
> .clkctrl_offs = DRA7XX_CM_L4PER_UART1_CLKCTRL_OFFSET,
>
--
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 06/26] OMAPDSS: if dssdev->name==NULL, use alias
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> > A label property is still an option.
>
> Hmm, what do you mean? Label as in:
>
> foo : node {
> };
>
> Isn't that 'foo' label only visible in DT itself, as a shortcut?
Some driver use a "label" property like this:
foo : node {
label = "lcd";
...
};
See for example
Documentation/devicetree/bindings/leds/common.txt
Documentation/devicetree/bindings/mtd/partition.txt
-- Sebastian
signature.asc
Description: Digital signature
[PATCH] ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon
to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
On DRA7 though, we seem to be missing this flag, and atleast on the DRA7 EVM
where we use uart1 for console, boot fails with DEBUG_LL enabled.
Reported-by: Lokesh Vutla
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index db32d53..18f333c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1637,7 +1637,7 @@ static struct omap_hwmod dra7xx_uart1_hwmod = {
.class = &dra7xx_uart_hwmod_class,
.clkdm_name = "l4per_clkdm",
.main_clk = "uart1_gfclk_mux",
- .flags = HWMOD_SWSUP_SIDLE_ACT,
+ .flags = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP2UART1_FLAGS,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L4PER_UART1_CLKCTRL_OFFSET,
--
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
очки будут необходимы Вам лишь Как деталька модного образа
Наша методология гарантирует Вам кристальное зрение http://vk.com/away.php?to=http://yoga.cn.ua/tmp/xjguq.htm -- 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 00/26] OMAPDSS: DT support (Christmas edition)
Hi, On 2013-12-12 02:39, Laurent Pinchart wrote: > Hi Tomi, > > On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote: >> Hi, >> >> Here's a new version for DT support to OMAP Display Subsystem. See >> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of >> the previous version, which contains thoughts about the related problems. >> >> The major change in this version is the use of V4L2 and CDF style >> port/endpoint style in the DT data. > > That's great, and I fully support that. This also calls for refactoring the > V4L2 DT bindings and support code to share them with display devices. A > bikeshedding question is where to put the common code. Thanks very much for review! I know drivers/video is in practice "fbdev", but drivers/video (the words) sound like the best place for things related to video. We should establish a committee to ponder this important question. Btw, I don't know if you noticed (or did I mention it somewhere): I use a bit shortened form of the V4L2 bindings. If there's just one endpoint, I omit the port node. I think that's always unambiguous (compared to also omitting the endpoint node, and having the properties in the main node, as was mentioned in some other thread). I also don't supply the same data for both endpoints, when the data is about the link. E.g. I think the V4L2 binding doc suggests to supply things like bus-width for both endpoints. I only supply the data for the endpoint that uses that data. With some encoders/panels the same data could be needed on both ends, but not in these patches. >> However, note that even if the DT data contains proper port & endpoint data, >> the drivers only use the first endpoint. This is to simplify the patches, as >> adding full support for the ports and endpoints to the drivers will be a big >> task. > > That's perfectly fine, there's no need to implement unused features just for > the sake of it, as long as the bindings are forward-compatible in that > respect. > >> This approach still works with more or less all the boards, as the only >> cases where the simpler model is an issue are the boards with multiple >> display devices connected to a single output. >> >> Laurent, I'd appreciate if you could have a look at the .dts changes, to see >> if there's anything that's clearly not CDF compatible. > > I've quickly reviewed the patch set, concentrating on the .dts changes. > Overall it looks good to me, but I suspect that we will need quite some time > to finalize standard bindings as there's lots of small details that need to > be > taken care of. Yes. I want to get this forward as it's becoming too much pain to manage things without DSS DT support, when the rest of the OMAP platform code is using DT. The most important thing in the DSS DT bindings for now is that they should contain enough information so that any future DT bindings changes can be handled with a boot-time conversion code. Actually, even the endpoint/port stuff is extra, as that could be deduced even from the "video-source" method I used in earlier DT versions. > The major point that bothers we, as explained in my reply to one of the > patches, is that I feel like the multi-device model (virtual DSS core + DSS > modules) might not accurately represent the hardware. Departing from it > probably sounds scary but might not be such a large change. There are actually two separate things here. One is the multi-device model, having separate device for each DSS submodule. The other is having the 'omapdss' "virtual" platform device. Note that the "dss_core" device is a real HW block, and depicted as the "dss" node in DT data, whereas "omapdss" device is not present in the DT data, and is created dynamically at boot time. The omapdss device is a legacy thing, but nowadays it is mainly used to pass platform data. Removing omapdss device is not easy, but the only questions around that is how to implement the required platform-data functionalities, and it doesn't affect the DT data. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
On 2013-12-12 01:44, Laurent Pinchart wrote: >> The DSS subdevices depend on the dss_core. dss_core has to be powered up >> for any of the subdevices to work. This is done automatically by the >> runtime PM when the subdevices are children of the dss_core. > > I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is > organized in a seemingly similar way, with the hardware subdivided in high- > level more-or-less independent modules. However, from a system point of view, > the ISP submodules are not standalone: they're part of the same power domain > as the ISP core, with subclocks management and interrupts being handled by > the > ISP core. For those reasons we've modeled the ISP as a single platform device. > > Are the DSS submodules really independent, or are they organized similarly ? > For instance do they each have a clock handled by the OMAP core clock IP, or > are the clocks gated by the DSS core ? Do they have interrupts routed to the > GIC, or does the DSS core driver demux the interrupts ? The DSS is "interesting". The TRM for various OMAP versions are the best source of information, there's integration section in the very beginning of the DSS chapter. We have the main dss_core (just DSS in the TRM, but for clarity we use dss_core) module, which is kind of a wrapper/glue for all the submodules. dss_core contains things like controlling muxes for signals between submodules, or clocks coming from outside. And there's the DSS power domain, containing all the DSS modules. Then we have DISPC, which reads the pixel data, manipulates it, and outputs raw RGB data to encoder submodules. Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have separate address spaces, some have dedicated PLLs, PHYs, and interrupts. Then DPI, which I think is mostly just level shifters. It's really just a port, as you say. SDI is a bit unclear to me. The registers for it are in the dss_core. There's only a few registers, but it does have a PHY and a PLL. But I guess it's also more of a port than a separate module. As for the clocks, I'm not sure what the actual point is that you want to clarify. DSS gets one "main" func clock from PRCM, which is used by DISPC and in some cases other submodules. But then we have dedicated DSI and HDMI PLLs, which, at least in DSI's case, can be used to fully satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the PRCM clock is not needed in all cases. The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have their own interrupt line. In OMAP3, DISPC and DSI shared the same interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt status/enable is handled via the respective IP. The DSS submodules also are not really designed together. For example, the HDMI IP is from one vendor, not TI. And the HDMI IP is different in OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's not like all the IPs were designed to work together, that's why we have wrappers/glue blocks (e.g. around HDMI). So, are they independent? I don't know =). I think they lean on the independent side. dss_core is always needed for the submodules to work, but for example DSI could be used without DISPC, using system DMA to transfer data from memory to DSI. Not a very useful thing to do, but still, there are dedicated DMA channels for that. > If the submodules are not independent, would it make sense to have a single > DT > node that would be matched with the DSS core driver ? You could list > information about the submodules in subnodes, and possibly create platform > devices internally in the DSS core, but a single platform device would be > instantiated from DT, and the DSS core wouldn't need a "simple-bus" > compatible > string. My gut feeling is that this would be a better representation of the > hardware, but I might not known enough about the DSS and be completely wrong. I have been wondering about this for a long time. The DSS modules have dependencies, and splitting them into separate devices/drivers brings the issue of probe order. We side-step that by having the virtual omapdss driver add the drivers for DSS modules in proper order. But then, I feel that they are quite independent and probably should be separate devices. And we've had omap hwmods, which I believe force us to have separate devices (although afaik hwmods are going away). >>> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods >>> property and do the lookup based on the compatible property instead ;) >>> So from that point of view we need to get the device mapping right in >>> the .dtsi files, and don't want to start mixing up separate devices into >>> single .dtsi entry. >> >> Hmm, was that just a general comment, or something that affects the DSS >> DT data I have in my patch? As far as I understand, the DSS nodes >> reflect the current hwmods correctly. >> >> With the exception that DPI and SDI do not have a matching hwmo
[PATCH 1/8] v4l: ti-vpe: create a scaler block library
VPE and VIP IPs in DAR7x contain a scaler(SC) sub block. Create a library which
will perform scaler block related configurations and hold SC register
definitions. The functions provided by this library will be called by the vpe
and vip drivers using a sc_data handle.
The vpe_dev holds the sc_data handle. The handle represents an instance of the
SC hardware, and the vpe driver uses it to access the scaler register offsets
or helper functions to configure these registers.
We move the SC register definitions to sc.h so that they aren't specific to
VPE anymore. The register offsets are now relative to the sub-block, and not the
VPE IP as a whole. In order for VPDMA to configure registers, it requires it's
offset from the top level VPE module. A macro called GET_OFFSET_TOP is added to
return the offset of the register relative to the VPE IP.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/Makefile | 2 +-
drivers/media/platform/ti-vpe/sc.c | 91
drivers/media/platform/ti-vpe/sc.h | 175 +++
drivers/media/platform/ti-vpe/vpe.c | 60 ---
drivers/media/platform/ti-vpe/vpe_regs.h | 149 --
5 files changed, 288 insertions(+), 189 deletions(-)
create mode 100644 drivers/media/platform/ti-vpe/sc.c
create mode 100644 drivers/media/platform/ti-vpe/sc.h
diff --git a/drivers/media/platform/ti-vpe/Makefile
b/drivers/media/platform/ti-vpe/Makefile
index cbf0a80..54c30b3 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
-ti-vpe-y := vpe.o vpdma.o
+ti-vpe-y := vpe.o sc.o vpdma.o
ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
diff --git a/drivers/media/platform/ti-vpe/sc.c
b/drivers/media/platform/ti-vpe/sc.c
new file mode 100644
index 000..f21dfbb
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/sc.c
@@ -0,0 +1,91 @@
+/*
+ * Scaler library
+ *
+ * Copyright (c) 2013 Texas Instruments Inc.
+ *
+ * David Griego,
+ * Dale Farnsworth,
+ * Archit Taneja,
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "sc.h"
+
+void sc_set_regs_bypass(struct sc_data *sc, u32 *sc_reg0)
+{
+ *sc_reg0 |= CFG_SC_BYPASS;
+}
+
+void sc_dump_regs(struct sc_data *sc)
+{
+ struct device *dev = &sc->pdev->dev;
+
+ u32 read_reg(struct sc_data *sc, int offset)
+ {
+ return ioread32(sc->base + offset);
+ }
+
+#define DUMPREG(r) dev_dbg(dev, "%-35s %08x\n", #r, read_reg(sc, CFG_##r))
+
+ DUMPREG(SC0);
+ DUMPREG(SC1);
+ DUMPREG(SC2);
+ DUMPREG(SC3);
+ DUMPREG(SC4);
+ DUMPREG(SC5);
+ DUMPREG(SC6);
+ DUMPREG(SC8);
+ DUMPREG(SC9);
+ DUMPREG(SC10);
+ DUMPREG(SC11);
+ DUMPREG(SC12);
+ DUMPREG(SC13);
+ DUMPREG(SC17);
+ DUMPREG(SC18);
+ DUMPREG(SC19);
+ DUMPREG(SC20);
+ DUMPREG(SC21);
+ DUMPREG(SC22);
+ DUMPREG(SC23);
+ DUMPREG(SC24);
+ DUMPREG(SC25);
+
+#undef DUMPREG
+}
+
+struct sc_data *sc_create(struct platform_device *pdev)
+{
+ struct sc_data *sc;
+
+ dev_dbg(&pdev->dev, "sc_create\n");
+
+ sc = devm_kzalloc(&pdev->dev, sizeof(*sc), GFP_KERNEL);
+ if (!sc) {
+ dev_err(&pdev->dev, "couldn't alloc sc_data\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ sc->pdev = pdev;
+
+ sc->res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sc");
+ if (!sc->res) {
+ dev_err(&pdev->dev, "missing platform resources data\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ sc->base = devm_ioremap_resource(&pdev->dev, sc->res);
+ if (!sc->base) {
+ dev_err(&pdev->dev, "failed to ioremap\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return sc;
+}
diff --git a/drivers/media/platform/ti-vpe/sc.h
b/drivers/media/platform/ti-vpe/sc.h
new file mode 100644
index 000..9248544
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/sc.h
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2013 Texas Instruments Inc.
+ *
+ * David Griego,
+ * Dale Farnsworth,
+ * Archit Taneja,
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#ifndef TI_SC_H
+#define TI_SC_H
+
+/* Scaler regs */
+#define CFG_SC00x0
+#define CFG_INTERLACE_O(1 << 0)
+#define CFG_LINEAR (1 << 1)
+#define CFG_SC_BYPASS (1 << 2)
+#define CFG_INVT_FID (1 << 3)
+#define CFG_USE_RAV(1 << 4)
+#define CFG_ENABLE_EV
[PATCH 7/8] v4l: ti-vpe: enable CSC support for VPE
Use the csc library functions to configure the CSC block in VPE.
Some changes are required in try_fmt to handle the pix->colorspace parameter
more correctly. Previously, we copied the source queue colorspace to the
destination queue colorspace as we didn't support RGB formats. Now, we configure
pix->colorspace based on the color format set(and the height of the image if
it's a YUV format).
Add basic RGB color formats to the list of supported vpe formats.
If the destination format is RGB colorspace, we also need to use the RGB output
port instead of the Luma and Chroma output ports. This requires configuring the
output data descriptors differently.
Also, make the default colorspace V4L2_COLORSPACE_SMPTE170M as that resembles
the Standard Definition colorspace more closely.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpe.c | 95 -
1 file changed, 72 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 6c4db57..1296c53 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -267,6 +267,38 @@ static struct vpe_fmt vpe_formats[] = {
.vpdma_fmt = { &vpdma_yuv_fmts[VPDMA_DATA_FMT_CY422],
},
},
+ {
+ .name = "RGB888 packed",
+ .fourcc = V4L2_PIX_FMT_RGB24,
+ .types = VPE_FMT_TYPE_CAPTURE,
+ .coplanar = 0,
+ .vpdma_fmt = { &vpdma_rgb_fmts[VPDMA_DATA_FMT_RGB24],
+ },
+ },
+ {
+ .name = "ARGB32",
+ .fourcc = V4L2_PIX_FMT_RGB32,
+ .types = VPE_FMT_TYPE_CAPTURE,
+ .coplanar = 0,
+ .vpdma_fmt = { &vpdma_rgb_fmts[VPDMA_DATA_FMT_ARGB32],
+ },
+ },
+ {
+ .name = "BGR888 packed",
+ .fourcc = V4L2_PIX_FMT_BGR24,
+ .types = VPE_FMT_TYPE_CAPTURE,
+ .coplanar = 0,
+ .vpdma_fmt = { &vpdma_rgb_fmts[VPDMA_DATA_FMT_BGR24],
+ },
+ },
+ {
+ .name = "ABGR32",
+ .fourcc = V4L2_PIX_FMT_BGR32,
+ .types = VPE_FMT_TYPE_CAPTURE,
+ .coplanar = 0,
+ .vpdma_fmt = { &vpdma_rgb_fmts[VPDMA_DATA_FMT_ABGR32],
+ },
+ },
};
/*
@@ -689,17 +721,20 @@ static void set_src_registers(struct vpe_ctx *ctx)
static void set_dst_registers(struct vpe_ctx *ctx)
{
struct vpe_mmr_adb *mmr_adb = ctx->mmr_adb.addr;
+ enum v4l2_colorspace clrspc = ctx->q_data[Q_DATA_DST].colorspace;
struct vpe_fmt *fmt = ctx->q_data[Q_DATA_DST].fmt;
u32 val = 0;
- /* select RGB path when color space conversion is supported in future */
- if (fmt->fourcc == V4L2_PIX_FMT_RGB24)
- val |= VPE_RGB_OUT_SELECT | VPE_CSC_SRC_DEI_SCALER;
+ if (clrspc == V4L2_COLORSPACE_SRGB)
+ val |= VPE_RGB_OUT_SELECT;
else if (fmt->fourcc == V4L2_PIX_FMT_NV16)
val |= VPE_COLOR_SEPARATE_422;
- /* The source of CHR_DS is always the scaler, whether it's used or not
*/
- val |= VPE_DS_SRC_DEI_SCALER;
+ /*
+* the source of CHR_DS and CSC is always the scaler, irrespective of
+* whether it's used or not
+*/
+ val |= VPE_DS_SRC_DEI_SCALER | VPE_CSC_SRC_DEI_SCALER;
if (fmt->fourcc != V4L2_PIX_FMT_NV12)
val |= VPE_DS_BYPASS;
@@ -813,7 +848,8 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
set_cfg_and_line_modes(ctx);
set_dei_regs(ctx);
- csc_set_coeff_bypass(ctx->dev->csc, &mmr_adb->csc_regs[5]);
+ csc_set_coeff(ctx->dev->csc, &mmr_adb->csc_regs[0],
+ s_q_data->colorspace, d_q_data->colorspace);
sc_set_hs_coeffs(ctx->dev->sc, ctx->sc_coeff_h.addr, src_w, dst_w);
sc_set_vs_coeffs(ctx->dev->sc, ctx->sc_coeff_v.addr, src_h, dst_h);
@@ -1095,9 +1131,13 @@ static void device_run(void *priv)
if (ctx->deinterlacing)
add_out_dtd(ctx, VPE_PORT_MV_OUT);
- add_out_dtd(ctx, VPE_PORT_LUMA_OUT);
- if (d_q_data->fmt->coplanar)
- add_out_dtd(ctx, VPE_PORT_CHROMA_OUT);
+ if (d_q_data->colorspace == V4L2_COLORSPACE_SRGB) {
+ add_out_dtd(ctx, VPE_PORT_RGB_OUT);
+ } else {
+ add_out_dtd(ctx, VPE_PORT_LUMA_OUT);
+ if (d_q_data->fmt->coplanar)
+ add_out_dtd(ctx, VPE_PORT_CHROMA_OUT);
+ }
/* input data descriptors */
if (ctx->deinterlacing) {
@@ -1133,9 +1173,16 @@ static void device_run(void *priv)
}
[PATCH 4/8] v4l: ti-vpe: enable basic scaler support
Add the required SC register configurations which lets us perform linear scaling
for the supported range of horizontal and vertical scaling ratios.
The horizontal scaler performs polyphase scaling using it's 8 tap 32 phase
filter, decimation is performed when downscaling passes beyond 2x or 4x.
The vertical scaler performs polyphase scaling using it's 5 tap 32 phase filter,
it switches to a simpler form of scaling using the running average filter when
the downscale ratio is more than 4x.
Many of the SC features like peaking, trimming and non-linear scaling aren't
implemented for now. Only the minimal register fields required for basic scaling
operation are configured.
The function to configure SC registers takes the sc_data handle, the source and
destination widths and heights, and the scaler address data block offsets for
the current context so that they can be configured.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/sc.c | 132 ++--
drivers/media/platform/ti-vpe/sc.h | 4 +-
drivers/media/platform/ti-vpe/vpe.c | 24 +--
3 files changed, 149 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/sc.c
b/drivers/media/platform/ti-vpe/sc.c
index 417feb9..93f0af54 100644
--- a/drivers/media/platform/ti-vpe/sc.c
+++ b/drivers/media/platform/ti-vpe/sc.c
@@ -20,11 +20,6 @@
#include "sc.h"
#include "sc_coeff.h"
-void sc_set_regs_bypass(struct sc_data *sc, u32 *sc_reg0)
-{
- *sc_reg0 |= CFG_SC_BYPASS;
-}
-
void sc_dump_regs(struct sc_data *sc)
{
struct device *dev = &sc->pdev->dev;
@@ -159,6 +154,133 @@ void sc_set_vs_coeffs(struct sc_data *sc, void *addr,
unsigned int src_h,
sc->load_coeff_v = true;
}
+void sc_config_scaler(struct sc_data *sc, u32 *sc_reg0, u32 *sc_reg8,
+ u32 *sc_reg17, unsigned int src_w, unsigned int src_h,
+ unsigned int dst_w, unsigned int dst_h)
+{
+ struct device *dev = &sc->pdev->dev;
+ u32 val;
+ int dcm_x, dcm_shift;
+ bool use_rav;
+ unsigned long lltmp;
+ u32 lin_acc_inc, lin_acc_inc_u;
+ u32 col_acc_offset;
+ u16 factor = 0;
+ int row_acc_init_rav = 0, row_acc_init_rav_b = 0;
+ u32 row_acc_inc = 0, row_acc_offset = 0, row_acc_offset_b = 0;
+ /*
+* location of SC register in payload memory with respect to the first
+* register in the mmr address data block
+*/
+ u32 *sc_reg9 = sc_reg8 + 1;
+ u32 *sc_reg12 = sc_reg8 + 4;
+ u32 *sc_reg13 = sc_reg8 + 5;
+ u32 *sc_reg24 = sc_reg17 + 7;
+
+ val = sc_reg0[0];
+
+ /* clear all the features(they may get enabled elsewhere later) */
+ val &= ~(CFG_SELFGEN_FID | CFG_TRIM | CFG_ENABLE_SIN2_VER_INTP |
+ CFG_INTERLACE_I | CFG_DCM_4X | CFG_DCM_2X | CFG_AUTO_HS |
+ CFG_ENABLE_EV | CFG_USE_RAV | CFG_INVT_FID | CFG_SC_BYPASS |
+ CFG_INTERLACE_O | CFG_Y_PK_EN | CFG_HP_BYPASS | CFG_LINEAR);
+
+ if (src_w == dst_w && src_h == dst_h) {
+ val |= CFG_SC_BYPASS;
+ sc_reg0[0] = val;
+ return;
+ }
+
+ /* we only support linear scaling for now */
+ val |= CFG_LINEAR;
+
+ /* configure horizontal scaler */
+
+ /* enable 2X or 4X decimation */
+ dcm_x = src_w / dst_w;
+ if (dcm_x > 4) {
+ val |= CFG_DCM_4X;
+ dcm_shift = 2;
+ } else if (dcm_x > 2) {
+ val |= CFG_DCM_2X;
+ dcm_shift = 1;
+ } else {
+ dcm_shift = 0;
+ }
+
+ lltmp = dst_w - 1;
+ lin_acc_inc = div64_u64(((u64)(src_w >> dcm_shift) - 1) << 24, lltmp);
+ lin_acc_inc_u = 0;
+ col_acc_offset = 0;
+
+ dev_dbg(dev, "hs config: src_w = %d, dst_w = %d, decimation = %s,
lin_acc_inc = %08x\n",
+ src_w, dst_w, dcm_shift == 2 ? "4x" :
+ (dcm_shift == 1 ? "2x" : "none"), lin_acc_inc);
+
+ /* configure vertical scaler */
+
+ /* use RAV for vertical scaler if vertical downscaling is > 4x */
+ if (dst_h < (src_h >> 2)) {
+ use_rav = true;
+ val |= CFG_USE_RAV;
+ } else {
+ use_rav = false;
+ }
+
+ if (use_rav) {
+ /* use RAV */
+ factor = (u16) ((dst_h << 10) / src_h);
+
+ row_acc_init_rav = factor + ((1 + factor) >> 1);
+ if (row_acc_init_rav >= 1024)
+ row_acc_init_rav -= 1024;
+
+ row_acc_init_rav_b = row_acc_init_rav +
+ (1 + (row_acc_init_rav >> 1)) -
+ (1024 >> 1);
+
+ if (row_acc_init_rav_b < 0) {
+ row_acc_init_rav_b += row_acc_init_rav;
+ row_acc_init_rav *= 2;
+ }
+
+ dev_dbg(dev, "vs config(RAV): src_h = %d, dst_h = %d, factor =
%d, acc_init = %08x,
[PATCH 6/8] v4l: ti-vpe: Add helper to perform color conversion
The CSC block can be used for color space conversion between YUV and RGB
formats.
It is configurable via a programmable set of coefficients. Add functionality to
choose the appropriate CSC coefficients and program them in the CSC registers.
We take the source and destination colorspace formats as the arguments, and
choose the coefficient table accordingly.
YUV to RGB coefficients are provided for standard and high definition
colorspaces. The coefficients can also be limited or full range. For now, only
full range coefficients are chosen. We would need some sort of control ioctl for
the user to specify the range needed. Not sure if there is a generic control
ioctl for this already?
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/csc.c | 120
drivers/media/platform/ti-vpe/csc.h | 3 +
2 files changed, 123 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/csc.c
b/drivers/media/platform/ti-vpe/csc.c
index 62e2fec..acfea50 100644
--- a/drivers/media/platform/ti-vpe/csc.c
+++ b/drivers/media/platform/ti-vpe/csc.c
@@ -16,9 +16,79 @@
#include
#include
#include
+#include
#include "csc.h"
+/*
+ * 16 coefficients in the order:
+ * a0, b0, c0, a1, b1, c1, a2, b2, c2, d0, d1, d2
+ * (we may need to pass non-default values from user space later on, we might
+ * need to make the coefficient struct more easy to populate)
+ */
+struct colorspace_coeffs {
+ u16 sd[12];
+ u16 hd[12];
+};
+
+/* VIDEO_RANGE: limited range, GRAPHICS_RANGE: full range */
+#defineCSC_COEFFS_VIDEO_RANGE_Y2R 0
+#defineCSC_COEFFS_GRAPHICS_RANGE_Y2R 1
+#defineCSC_COEFFS_VIDEO_RANGE_R2Y 2
+#defineCSC_COEFFS_GRAPHICS_RANGE_R2Y 3
+
+/* default colorspace coefficients */
+static struct colorspace_coeffs colorspace_coeffs[4] = {
+ [CSC_COEFFS_VIDEO_RANGE_Y2R] = {
+ {
+ /* SDTV */
+ 0x0400, 0x, 0x057D, 0x0400, 0x1EA7, 0x1D35,
+ 0x0400, 0x06EF, 0x1FFE, 0x0D40, 0x0210, 0x0C88,
+ },
+ {
+ /* HDTV */
+ 0x0400, 0x, 0x0629, 0x0400, 0x1F45, 0x1E2B,
+ 0x0400, 0x0742, 0x, 0x0CEC, 0x0148, 0x0C60,
+ },
+ },
+ [CSC_COEFFS_GRAPHICS_RANGE_Y2R] = {
+ {
+ /* SDTV */
+ 0x04A8, 0x1FFE, 0x0662, 0x04A8, 0x1E6F, 0x1CBF,
+ 0x04A8, 0x0812, 0x1FFF, 0x0C84, 0x0220, 0x0BAC,
+ },
+ {
+ /* HDTV */
+ 0x04A8, 0x, 0x072C, 0x04A8, 0x1F26, 0x1DDE,
+ 0x04A8, 0x0873, 0x, 0x0C20, 0x0134, 0x0B7C,
+ },
+ },
+ [CSC_COEFFS_VIDEO_RANGE_R2Y] = {
+ {
+ /* SDTV */
+ 0x0132, 0x0259, 0x0075, 0x1F50, 0x1EA5, 0x020B,
+ 0x020B, 0x1E4A, 0x1FAB, 0x, 0x0200, 0x0200,
+ },
+ {
+ /* HDTV */
+ 0x00DA, 0x02DC, 0x004A, 0x1F88, 0x1E6C, 0x020C,
+ 0x020C, 0x1E24, 0x1FD0, 0x, 0x0200, 0x0200,
+ },
+ },
+ [CSC_COEFFS_GRAPHICS_RANGE_R2Y] = {
+ {
+ /* SDTV */
+ 0x0107, 0x0204, 0x0064, 0x1F68, 0x1ED6, 0x01C2,
+ 0x01C2, 0x1E87, 0x1FB7, 0x0040, 0x0200, 0x0200,
+ },
+ {
+ /* HDTV */
+ 0x04A8, 0x, 0x072C, 0x04A8, 0x1F26, 0x1DDE,
+ 0x04A8, 0x0873, 0x, 0x0C20, 0x0134, 0x0B7C,
+ },
+ },
+};
+
void csc_dump_regs(struct csc_data *csc)
{
struct device *dev = &csc->pdev->dev;
@@ -45,6 +115,56 @@ void csc_set_coeff_bypass(struct csc_data *csc, u32
*csc_reg5)
*csc_reg5 |= CSC_BYPASS;
}
+/*
+ * set the color space converter coefficient shadow register values
+ */
+void csc_set_coeff(struct csc_data *csc, u32 *csc_reg0,
+ enum v4l2_colorspace src_colorspace,
+ enum v4l2_colorspace dst_colorspace)
+{
+ u32 *csc_reg5 = csc_reg0 + 5;
+ u32 *shadow_csc = csc_reg0;
+ struct colorspace_coeffs *sd_hd_coeffs;
+ u16 *coeff, *end_coeff;
+ enum v4l2_colorspace yuv_colorspace;
+ int sel = 0;
+
+ /*
+* support only graphics data range(full range) for now, a control ioctl
+* would be nice here
+*/
+ /* Y2R */
+ if (dst_colorspace == V4L2_COLORSPACE_SRGB &&
+ (src_colorspace == V4L2_COLORSPACE_SMPTE170M ||
+ src_colorspace == V4L2_COLORSPACE_REC709)) {
+ /* Y2R */
+ sel = 1;
+ yuv_colorspace = src_colorspace;
+ } else if ((dst_colorspace == V4L2_COLORSPACE_SMPTE170M ||
+
[PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion
The VPE and VIP IPs in DRA7x contain common scaler and color conversion hardware blocks. We create libraries for these components such that the vpe driver and the vip driver(in future) can use these library funcs to configure the blocks. There are some points for which I would like comments: - For VPE, setting the format and colorspace for the source and destination queues is enough to determine how these blocks need to be configured and whether they need to be bypassed or not. So it didn't make sense to represent them as media controller entities. For VIP(driver not upstream yet), it's possible that there are multiple data paths which may or may not include these blocks. However, the current use cases don't require such flexibility. There may be a need to re-consider a media controller like setup once we work on the VIP driver. Is it a good idea in terms of user-space compatibilty if we use media controller framework in the future. - These blocks will also require some custom control commands later on. For example, we may want to tell the scaler later on to perform bi-linear scaling, or perform peaking at a particular frequency. - The current series keeps the default scaler coefficients in a header file. These coefficients add a lot of lines of code in the kernel. Does it make more sense for the user application to pass the co-efficients to the kernel using an ioctl? Is there any driver which currenlty does this? The series is based on the branch: git://linuxtv.org/media_tree.git master Archit Taneja (8): v4l: ti-vpe: create a scaler block library v4l: ti-vpe: support loading of scaler coefficients v4l: ti-vpe: make vpe driver load scaler coefficients v4l: ti-vpe: enable basic scaler support v4l: ti-vpe: create a color space converter block library v4l: ti-vpe: Add helper to perform color conversion v4l: ti-vpe: enable CSC support for VPE v4l: ti-vpe: Add a type specifier to describe vpdma data format type drivers/media/platform/ti-vpe/Makefile |2 +- drivers/media/platform/ti-vpe/csc.c | 196 + drivers/media/platform/ti-vpe/csc.h | 68 ++ drivers/media/platform/ti-vpe/sc.c | 311 +++ drivers/media/platform/ti-vpe/sc.h | 208 + drivers/media/platform/ti-vpe/sc_coeff.h | 1342 ++ drivers/media/platform/ti-vpe/vpdma.c| 36 +- drivers/media/platform/ti-vpe/vpdma.h|7 + drivers/media/platform/ti-vpe/vpe.c | 251 -- drivers/media/platform/ti-vpe/vpe_regs.h | 187 - 10 files changed, 2335 insertions(+), 273 deletions(-) create mode 100644 drivers/media/platform/ti-vpe/csc.c create mode 100644 drivers/media/platform/ti-vpe/csc.h create mode 100644 drivers/media/platform/ti-vpe/sc.c create mode 100644 drivers/media/platform/ti-vpe/sc.h create mode 100644 drivers/media/platform/ti-vpe/sc_coeff.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] v4l: ti-vpe: create a color space converter block library
VPE and VIP IPs in DAR7x contain a color space converter(CSC) sub block. Create
a library which will perform CSC related configurations and hold CSC register
definitions. The functions provided by this library will be called by the vpe
and vip drivers using a csc_data handle.
The vpe_dev holds the csc_data handle. The handle represents an instance of the
CSC hardware, and the vpe driver uses it to access the CSC register offsets or
helper functions to configure these registers.
The CSC register offsets are now relative to the CSC block itself, so we need
to use the macro GET_OFFSET_TOP to get the CSC register offset relative to the
VPE IP in the vpe driver.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/Makefile | 2 +-
drivers/media/platform/ti-vpe/csc.c | 76
drivers/media/platform/ti-vpe/csc.h | 65 +++
drivers/media/platform/ti-vpe/vpe.c | 31 ++---
drivers/media/platform/ti-vpe/vpe_regs.h | 38
5 files changed, 155 insertions(+), 57 deletions(-)
create mode 100644 drivers/media/platform/ti-vpe/csc.c
create mode 100644 drivers/media/platform/ti-vpe/csc.h
diff --git a/drivers/media/platform/ti-vpe/Makefile
b/drivers/media/platform/ti-vpe/Makefile
index 54c30b3..be680f8 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
-ti-vpe-y := vpe.o sc.o vpdma.o
+ti-vpe-y := vpe.o sc.o csc.o vpdma.o
ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
diff --git a/drivers/media/platform/ti-vpe/csc.c
b/drivers/media/platform/ti-vpe/csc.c
new file mode 100644
index 000..62e2fec
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/csc.c
@@ -0,0 +1,76 @@
+/*
+ * Color space converter library
+ *
+ * Copyright (c) 2013 Texas Instruments Inc.
+ *
+ * David Griego,
+ * Dale Farnsworth,
+ * Archit Taneja,
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "csc.h"
+
+void csc_dump_regs(struct csc_data *csc)
+{
+ struct device *dev = &csc->pdev->dev;
+
+ u32 read_reg(struct csc_data *csc, int offset)
+ {
+ return ioread32(csc->base + offset);
+ }
+
+#define DUMPREG(r) dev_dbg(dev, "%-35s %08x\n", #r, read_reg(csc, CSC_##r))
+
+ DUMPREG(CSC00);
+ DUMPREG(CSC01);
+ DUMPREG(CSC02);
+ DUMPREG(CSC03);
+ DUMPREG(CSC04);
+ DUMPREG(CSC05);
+
+#undef DUMPREG
+}
+
+void csc_set_coeff_bypass(struct csc_data *csc, u32 *csc_reg5)
+{
+ *csc_reg5 |= CSC_BYPASS;
+}
+
+struct csc_data *csc_create(struct platform_device *pdev)
+{
+ struct csc_data *csc;
+
+ dev_dbg(&pdev->dev, "csc_create\n");
+
+ csc = devm_kzalloc(&pdev->dev, sizeof(*csc), GFP_KERNEL);
+ if (!csc) {
+ dev_err(&pdev->dev, "couldn't alloc csc_data\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ csc->pdev = pdev;
+
+ csc->res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "vpe_csc");
+ if (csc->res == NULL) {
+ dev_err(&pdev->dev, "missing platform resources data\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ csc->base = devm_ioremap_resource(&pdev->dev, csc->res);
+ if (!csc->base) {
+ dev_err(&pdev->dev, "failed to ioremap\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return csc;
+}
diff --git a/drivers/media/platform/ti-vpe/csc.h
b/drivers/media/platform/ti-vpe/csc.h
new file mode 100644
index 000..57b5ed6
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/csc.h
@@ -0,0 +1,65 @@
+/*
+ * Copyright (c) 2013 Texas Instruments Inc.
+ *
+ * David Griego,
+ * Dale Farnsworth,
+ * Archit Taneja,
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#ifndef TI_CSC_H
+#define TI_CSC_H
+
+/* VPE color space converter regs */
+#define CSC_CSC00 0x00
+#define CSC_A0_MASK0x1fff
+#define CSC_A0_SHIFT 0
+#define CSC_B0_MASK0x1fff
+#define CSC_B0_SHIFT 16
+
+#define CSC_CSC01 0x04
+#define CSC_C0_MASK0x1fff
+#define CSC_C0_SHIFT 0
+#define CSC_A1_MASK0x1fff
+#define CSC_A1_SHIFT 16
+
+#define CSC_CSC02 0x08
+#define CSC_B1_MASK0x1fff
+#define CSC_B1_SHIFT 0
+#define CSC_C1_MASK0x1fff
+#define CSC_C1_SHIFT 16
+
+#define CSC_CSC03 0x0c
+#define CSC_A2_MASK0x1fff
+#define CSC_A2_SHIFT 0
+#define CSC_B2_MASK0x1fff
+#define CSC_B2_SHIFT 16
+
+#d
[PATCH 3/8] v4l: ti-vpe: make vpe driver load scaler coefficients
Make the driver allocate dma buffers to store horizontal and scaler coeffs.
Use the scaler library api to choose and copy scaler coefficients to a
the above buffers based on the scaling ratio. Since the SC block comes after
the de-interlacer, make sure that the source height is doubled if de-interlacer
was used.
These buffers now need to be used by VPDMA to load the coefficients into the
SRAM within SC.
In device_run, add configuration descriptors which have payloads pointing to
the scaler coefficients in memory. Use the members in sc_data handle to prevent
addition of these descriptors if there isn't a need to re-load coefficients into
SC. This comes helps unnecessary re-loading of the coefficients when we switch
back and forth between vpe contexts.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpe.c | 47 -
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index ecb85f9..50d6d0e 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -356,6 +356,8 @@ struct vpe_ctx {
void*mv_buf[2]; /* virtual addrs of
motion vector bufs */
size_t mv_buf_size;/* current motion
vector buffer size */
struct vpdma_bufmmr_adb;/* shadow reg addr/data
block */
+ struct vpdma_bufsc_coeff_h; /* h coeff buffer */
+ struct vpdma_bufsc_coeff_v; /* v coeff buffer */
struct vpdma_desc_list desc_list; /* DMA descriptor list
*/
booldeinterlacing; /* using de-interlacer
*/
@@ -765,6 +767,10 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
struct vpe_q_data *s_q_data = &ctx->q_data[Q_DATA_SRC];
struct vpe_q_data *d_q_data = &ctx->q_data[Q_DATA_DST];
struct vpe_mmr_adb *mmr_adb = ctx->mmr_adb.addr;
+ unsigned int src_w = s_q_data->c_rect.width;
+ unsigned int src_h = s_q_data->c_rect.height;
+ unsigned int dst_w = d_q_data->c_rect.width;
+ unsigned int dst_h = d_q_data->c_rect.height;
size_t mv_buf_size;
int ret;
@@ -777,7 +783,6 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
const struct vpdma_data_format *mv =
&vpdma_misc_fmts[VPDMA_DATA_FMT_MV];
- ctx->deinterlacing = 1;
/*
* we make sure that the source image has a 16 byte aligned
* stride, we need to do the same for the motion vector buffer
@@ -788,6 +793,9 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
bytes_per_line = ALIGN((s_q_data->width * mv->depth) >> 3,
VPDMA_STRIDE_ALIGN);
mv_buf_size = bytes_per_line * s_q_data->height;
+
+ ctx->deinterlacing = 1;
+ src_h <<= 1;
} else {
ctx->deinterlacing = 0;
mv_buf_size = 0;
@@ -802,6 +810,8 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
set_cfg_and_line_modes(ctx);
set_dei_regs(ctx);
set_csc_coeff_bypass(ctx);
+ sc_set_hs_coeffs(ctx->dev->sc, ctx->sc_coeff_h.addr, src_w, dst_w);
+ sc_set_vs_coeffs(ctx->dev->sc, ctx->sc_coeff_v.addr, src_h, dst_h);
sc_set_regs_bypass(ctx->dev->sc, &mmr_adb->sc_regs[0]);
return 0;
@@ -1035,6 +1045,7 @@ static void disable_irqs(struct vpe_ctx *ctx)
static void device_run(void *priv)
{
struct vpe_ctx *ctx = priv;
+ struct sc_data *sc = ctx->dev->sc;
struct vpe_q_data *d_q_data = &ctx->q_data[Q_DATA_DST];
if (ctx->deinterlacing && ctx->src_vbs[2] == NULL) {
@@ -1057,6 +1068,26 @@ static void device_run(void *priv)
ctx->load_mmrs = false;
}
+ if (sc->loaded_coeff_h != ctx->sc_coeff_h.dma_addr ||
+ sc->load_coeff_h) {
+ vpdma_map_desc_buf(ctx->dev->vpdma, &ctx->sc_coeff_h);
+ vpdma_add_cfd_block(&ctx->desc_list, CFD_SC_CLIENT,
+ &ctx->sc_coeff_h, 0);
+
+ sc->loaded_coeff_h = ctx->sc_coeff_h.dma_addr;
+ sc->load_coeff_h = false;
+ }
+
+ if (sc->loaded_coeff_v != ctx->sc_coeff_v.dma_addr ||
+ sc->load_coeff_v) {
+ vpdma_map_desc_buf(ctx->dev->vpdma, &ctx->sc_coeff_v);
+ vpdma_add_cfd_block(&ctx->desc_list, CFD_SC_CLIENT,
+ &ctx->sc_coeff_v, SC_COEF_SRAM_SIZE >> 4);
+
+ sc->loaded_coeff_v = ctx->sc_coeff_v.dma_addr;
+ sc->load_coeff_v = false;
+ }
+
/* output data descriptors */
if (ctx->deinterlacing)
add_out_dtd(ctx, VPE_PORT_MV_OUT);
@@ -1180,6 +1211,8 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
[PATCH 8/8] v4l: ti-vpe: Add a type specifier to describe vpdma data format type
The struct vpdma_data_format holds the color format depth and the data_type
value needed to be programmed in the data descriptors. However, it doesn't
tell what type of color format is it, i.e, whether it is RGB, YUV or Misc.
This information is needed when by vpdma library when forming descriptors. We
modify the depth parameter for the chroma portion of the NV12 format. For this,
we check if the data_type value is C420. This isn't sufficient as there are
many YUV and RGB vpdma formats which have the same data_type value. Hence, we
need to hold the type of the color format for the above case, and possibly more
cases in the future.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpdma.c | 36 +--
drivers/media/platform/ti-vpe/vpdma.h | 7 +++
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index f97253f..a268f68 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -30,38 +30,47 @@
const struct vpdma_data_format vpdma_yuv_fmts[] = {
[VPDMA_DATA_FMT_Y444] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_Y444,
.depth = 8,
},
[VPDMA_DATA_FMT_Y422] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_Y422,
.depth = 8,
},
[VPDMA_DATA_FMT_Y420] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_Y420,
.depth = 8,
},
[VPDMA_DATA_FMT_C444] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_C444,
.depth = 8,
},
[VPDMA_DATA_FMT_C422] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_C422,
.depth = 8,
},
[VPDMA_DATA_FMT_C420] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_C420,
.depth = 4,
},
[VPDMA_DATA_FMT_YC422] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_YC422,
.depth = 16,
},
[VPDMA_DATA_FMT_YC444] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_YC444,
.depth = 24,
},
[VPDMA_DATA_FMT_CY422] = {
+ .type = VPDMA_DATA_FMT_TYPE_YUV,
.data_type = DATA_TYPE_CY422,
.depth = 16,
},
@@ -69,82 +78,102 @@ const struct vpdma_data_format vpdma_yuv_fmts[] = {
const struct vpdma_data_format vpdma_rgb_fmts[] = {
[VPDMA_DATA_FMT_RGB565] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_RGB16_565,
.depth = 16,
},
[VPDMA_DATA_FMT_ARGB16_1555] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_ARGB_1555,
.depth = 16,
},
[VPDMA_DATA_FMT_ARGB16] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_ARGB_,
.depth = 16,
},
[VPDMA_DATA_FMT_RGBA16_5551] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_RGBA_5551,
.depth = 16,
},
[VPDMA_DATA_FMT_RGBA16] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_RGBA_,
.depth = 16,
},
[VPDMA_DATA_FMT_ARGB24] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_ARGB24_,
.depth = 24,
},
[VPDMA_DATA_FMT_RGB24] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_RGB24_888,
.depth = 24,
},
[VPDMA_DATA_FMT_ARGB32] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_ARGB32_,
.depth = 32,
},
[VPDMA_DATA_FMT_RGBA24] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_RGBA24_,
.depth = 24,
},
[VPDMA_DATA_FMT_RGBA32] = {
+ .type = VPDMA_DATA_FMT_TYPE_RGB,
.data_type = DATA_TYPE_RGBA32_,
.depth = 32,
Re: [PATCHv2 07/10] drivers: mtd: m25p80: Adapt driver to support memory mapped read.
On Thu, Dec 12, 2013 at 01:45:24PM +0530, Sourav Poddar wrote: > On Thursday 12 December 2013 01:25 PM, Huang Shijie wrote: > >> > >>+ if (spi->master->configure_from_slave) > >>+ m25p80_fill_flash_information(flash); > >>+ > >You have add a configure_from_slave hook in the SPI, why you also need > >a same hook in the SPI-NOR framework? > > > We need a way to provoke this, currently it is placed in m25p80. If m25p80 > is removed, for where should I handle these in nor framework? The m25p80 is not removed. it is easy to move your code in the m25p_read. Please read the patch 4. > >And i think the enable_mmap/disable_mmap is not needed too. > > > >All the three hooks are used to set the SPI bus controller. > > >And the SPI-NOR framework only handles the issues between the > >SPI bus controller and the SPI-NOR, or the SPI-NOR controller and the > >SPI-NOR. > My controller can be used as spi flash controller as well as a spi > controller. > If you really think we need to do something before the do the real work. we can add two hooks : prepare/unprepare. for you, you can put the the enable_mmap/disable_mmap in the prepare/unprepare separately. for other driver, we can put the enable/disable clocks in the prepare/unprepare hooks. thanks Huang Shijie -- 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/3] arm: omap2: Export devconf1 bypass and acbias.
Hi Tony, On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren wrote: > * Belisko Marek [131210 14:13]: >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren wrote: >> > >> > It would be best to set it up as omap-ctrl.c driver under drivers >> > somewhere with few functions exported for DSS and MMC drivers. >> >> I create small dummy driver based on phy-omap-control which can be >> used but before sending patch (with more updates) I would like to get >> some feedback if my direction is correct. > > Cool thanks. Yeah what you have can easily be combined with the patches > Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap > for the SCM register access. Maybe take a look at the work in progress > patches in thread: > > [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup > > And also see my comments regarding using the SCM GENERAL register area > as base for the syscon.c driver. That should work for your driver too, > right? And then you can access the SYSCON1 register that way from your > consumer driver ;) If I understand correclty I can use syscon driver (it will have in range also devconf1 register) ad get rid of my custom driver and then get regmap from syscon and update bits that I need for venc, right? > > Regards, > > Tony BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 07/10] drivers: mtd: m25p80: Adapt driver to support memory mapped read.
On Thursday 12 December 2013 01:25 PM, Huang Shijie wrote:
On Fri, Dec 06, 2013 at 07:54:48PM +0530, Sourav Poddar wrote:
Adapt driver to do a memory mapped read.
@@ -109,6 +109,7 @@ struct m25p {
u8 program_opcode;
u8 *command;
enum read_type flash_read;
+ void __iomem *mem_addr;
I think we can remove this field.
You can use a local variable in the m25p80_read.
};
static inline struct m25p *mtd_to_m25p(struct mtd_info *mtd)
@@ -515,6 +516,7 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from,
size_t len,
size_t *retlen, u_char *buf)
{
struct m25p *flash = mtd_to_m25p(mtd);
+ struct spi_master *master = flash->spi->master;
struct spi_transfer t[2];
struct spi_message m;
uint8_t opcode;
@@ -523,6 +525,20 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from,
size_t len,
pr_debug("%s: %s from 0x%08x, len %zd\n", dev_name(&flash->spi->dev),
__func__, (u32)from, len);
+ if (master->mmap) {
+ mutex_lock(&flash->lock);
+ /* Wait till previous write/erase is done. */
+ if (wait_till_ready(flash)) {
+ mutex_unlock(&flash->lock);
+ return 1;
+ }
+ flash->mem_addr = master->get_buf(master);
+ memcpy(buf, flash->mem_addr + from, len);
+ master->put_buf(master);
+ *retlen = len;
+ goto out;
+ }
+
spi_message_init(&m);
memset(t, 0, (sizeof t));
@@ -558,6 +574,7 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from,
size_t len,
*retlen = m.actual_length - m25p_cmdsz(flash) - dummy;
+out:
mutex_unlock(&flash->lock);
return 0;
@@ -1286,6 +1303,9 @@ static int m25p_probe(struct spi_device *spi)
flash->addr_width = 3;
}
+ if (spi->master->configure_from_slave)
+ m25p80_fill_flash_information(flash);
+
You have add a configure_from_slave hook in the SPI, why you also need
a same hook in the SPI-NOR framework?
We need a way to provoke this, currently it is placed in m25p80. If m25p80
is removed, for where should I handle these in nor framework?
And i think the enable_mmap/disable_mmap is not needed too.
All the three hooks are used to set the SPI bus controller.
And the SPI-NOR framework only handles the issues between the
SPI bus controller and the SPI-NOR, or the SPI-NOR controller and the
SPI-NOR.
My controller can be used as spi flash controller as well as a spi
controller.
thanks
Huang Shijie
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drivers: net: cpsw: fix dt probe for one port ethernet
Balbi On Thursday 12 December 2013 09:39 AM, Felipe Balbi wrote: > From: Mugunthan V N > > When only one port of the two port is pinned out, then dt probe is failing > because second port phy is not found. fixing this by checking the number of > slaves and breaking the loop. > > Signed-off-by: Mugunthan V N > Signed-off-by: Felipe Balbi This patch is already applied to net branch and its commit id is 3a27bfac17fe375539c4e0a53478679645eb5ae2. Regards Mugunthan V N -- 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
