Re: [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:18 PM, Benoit Cousson wrote:
Hi Lokesh,
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Renaming elpida_ecb240abacn.dtsi file generic, so that the
same file can be reused for other parts from different vendors.
Could you elaborate a little bit?
Are these settings purely reflecting lpddr2 spec timings?
The basic idea is to group data for all the lpddr2 devices in a single
file instead of creating separate file for each lpddr2 device.
Right now the file elpida_ecb240abacn.dtsi contains only data for
lpddr2-s4 2G parts from Elpida.
I wanted to add data for lpddr2-s4 4G parts from Samsung.
So I renamed the file elpida_ecb240abacn.dtsi as lpddr2_data.dtsi.
Please let me know if more clarification is needed.
Thanks,
Lokesh
Regards,
Benoit
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} |0
arch/arm/boot/dts/omap4-panda.dts |2 +-
arch/arm/boot/dts/omap4-sdp.dts |2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} (100%)
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
similarity index 100%
rename from arch/arm/boot/dts/elpida_ecb240abacn.dtsi
rename to arch/arm/boot/dts/lpddr2_data.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..09d3a32 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ "omap4.dtsi"
-/include/ "elpida_ecb240abacn.dtsi"
+/include/ "lpddr2_data.dtsi"
/ {
model = "TI OMAP4 PandaBoard";
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..dd749fc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ "omap4.dtsi"
-/include/ "elpida_ecb240abacn.dtsi"
+/include/ "lpddr2_data.dtsi"
/ {
model = "TI OMAP4 SDP board";
--
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/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:31 PM, Benoit Cousson wrote:
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
I am really sorry about this.
I ll make sure that all patch descriptions will be clear in V2 of this
patch series.
In this patch I am adding device tree data for LPDDR2 memory devices
attached to omap5-sevm and also adding device tree data for EMIF sdram
controllers in OMAP5.
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64 +++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
- elpida_ECB240ABACN: lpddr2 {
+ elpida_ECB240ABACN: lpddr2@0 {
compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4";
density = <2048>;
io-width= <32>;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = <6000>;
};
};
+
+ samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
Yes, I wanted to group data for all lppdr2 devices in a single file than
creating separate file for each device.
May be a dumb question, Why can't we group data for all the lpddr2
devices in a single file?
+ compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
+ density = <4096>;
+ io-width= <32>;
+
+ tRPab-min-tck = <3>;
+ tRCD-min-tck= <3>;
+ tWR-min-tck = <3>;
+ tRASmin-min-tck = <3>;
+ tRRD-min-tck= <2>;
+ tWTR-min-tck= <2>;
+ tXP-min-tck = <2>;
+ tRTP-min-tck= <2>;
+ tCKE-min-tck= <3>;
+ tCKESR-min-tck = <3>;
+ tFAW-min-tck= <8>;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq= <1000>;
+ max-freq= <5>;
+ tRPab = <21000>;
+ tRCD= <18000>;
+ tWR = <15000>;
+ tRAS-min= <42000>;
+ tRRD= <1>;
+ tWTR= <7500>;
+ tXP = <7500>;
+ tRTP= <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW= <5>;
+ tZQCS = <9>;
+ tZQCL = <36>;
+ tZQinit = <100>;
+ tRAS-max-ns = <7>;
+ tDQSCK-max-derated = <5620>;
+ };
+
+ timings_samsung_K3PE0E000B_266mhz: lpddr2-timings@1 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq= <1000>;
+ max-freq= <2>;
+ tRPab = <21000>;
+ tRCD= <18000>;
+ tWR = <15000>;
+ tRAS-min= <42000>;
+ tRRD= <1>;
+ tWTR= <7500>;
+ tXP = <7500>;
+ tRTP= <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW= <5>;
+ tZQCS = <9>;
+ tZQCL = <36>;
+ tZQinit = <100>;
+ tRAS-max-ns = <7>;
+ tDQSCK-max-derated = <6000>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..8a952f8 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ "omap5.dtsi"
+/include/ "lpddr2_data.dtsi"
/ {
model
RE: [PATCH 4/4] mtd: nand: omap2: Add data correction support
On Wed, Oct 10, 2012 at 22:38:06, Ivan Djelic wrote: > On Tue, Oct 09, 2012 at 01:36:50PM +0100, Philip, Avinash wrote: > (...) > > > There are at least 2 potential problems when reading an erased page with > > > bitflips: > > > > > > 1. bitflip in data area and no bitflip in spare area (all 0xff) > > > Your code will not perform any ECC correction. > > > UBIFS does not like finding bitflips in empty pages, see for instance > > > http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html. > > > > In case of error correction using ELM, syndrome vector calculated after > > reading > > Data area & OOB area. So handling of erased page requires a software > > workaround. > > I am planning something as follows. > > > > I will first check calculated ecc, which would be zero for non error pages. > > Then I would check 0xFF in OOB area (for erased page) by checking number of > > bit zeros in OOB area. If it is 0xFF (number of bit zero count is zero), > > set entire page as 0xFF if number of bit zeros is less than max bit flips > > (8 or 4) by counting the number of bit zero's in data area. > > > > This logic is implemented in fsmc_nand.c > > > > See commit > > mtd: fsmc: Newly erased page read algorithm implemented > > > > > > > > 2. bitflip in ECC bytes in spare area > > > Your code will report an uncorrectable error upon reading; if this > > > happens while reading a partially programmed UBI block, > > > I guess you will lose data. > > > > In case of uncorrectable errors due to bit flips in spare area, > > I can go on checking number of bit zero's in data area + OOB area > > are less than max bit flips (8 or 4), I can go on setting the entire > > page as 0xFF. > > > > OK, sounds reasonable. > Another simple strategy could use the fact that you add a 14th zero byte to > the 13 BCH bytes for RBL compatibility: RBL compatibility (14th byte) is applicable only for BCH8 ecc scheme. So I am planning adding an extra byte (0) for BCH4 ecc scheme. So with this we can go for same approaches in BCH4 & BCH8 ecc scheme. If I understood correctly, software BCH ecc scheme is modifying calculated ecc data to handle bit flips in erased pages. If that is the only reason, whether same logic can go for same ECC calculation (remove modification of calculated ecc in case of software ecc correction) by adding an extra byte (0) in spare area to handle erased pages. So can you share if I am missing something? > > Upon reading: > - if this 14th byte is zero (*) => page was programmed: perform ECC >correction as usual > - else, page was not programmed: do not perform ECC, read entire data+spare >area, and set it to 0xff if less than 8 or 4 (max bitflips) zero bits >were found > > (*) for robustness to bitflip in 14th byte, replace condition > "14th byte is zero" by e.g. "14th byte has less than 4 bits set to 1". > > What do you think ? This seems logically good. Thanks Avinash > > BR, > -- > Ivan > -- 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 00/14] OMAP-GPMC related cleanup for common zImage
On Wed, Oct 10, 2012 at 22:08:41, Ivan Djelic wrote: > On Mon, Oct 08, 2012 at 07:08:08AM +0100, Mohammed, Afzal wrote: > > Please verify that BCH[48] works as earlier with this series. > I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2 > tag. > All BCH error correcting tests passed successfully. > > I occasionally had weird read errors though, especially when reading blank > pages: > the omap driver returned 512-byte sectors containing something like: > I was able to reproduce the problem also on l2-mtd tip, albeit less often. > The problem seems to occur quite randomly, it may be a hardware issue on > my board... > > Anyway, the ECC handling part looks OK to me. Thanks Ivan Regards Afzal
Re: [PATCH 1/4] usb: phy: add a new driver for usb3 phy
Hi,
* Kishon Vijay Abraham I [120919 04:32]:
> Added a driver for usb3 phy that handles the interaction between usb phy
> device and dwc3 controller.
>
> This also includes device tree support for usb3 phy driver and
> the documentation with device tree binding information is updated.
>
> Currently writing to control module register is taken care in this
> driver which will be removed once the control module driver is in place.
You may be able to set up the control module register with one
of the following Linux standard frameworks:
1. Fixed regulator defined in mach-omap2/control.c
In this case the PHY driver can pick up the regulator by name.
2. A mux mapped with pinctrl framework using pinctrl-single,bits
binding
And in this case the PHY driver can request the named pinctrl
states like "enabled" and "disabled".
> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
> @@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
> reg = <0x4a0ad080 0x58>,
> <0x4a002300 0x4>;
> };
The comments also apply to the omap_usb2.c driver for
0x4a002300 above.
> +
> +OMAP USB3 PHY
> +
> +Required properties:
> + - compatible: Should be "ti,omap-usb3"
> + - reg : Address and length of the register set for the device. Also
> +add the address of control module phy power register until a driver for
> +control module is added
> +
> +This is usually a subnode of ocp2scp to which it is connected.
> +
> +usb3phy@4a084400 {
> + compatible = "ti,omap-usb3";
> + reg = <0x0x4a084400 0x80>,
> + <0x4a084800 0x64>,
> + <0x4a084c00 0x40>,
> + <0x4a002370 0x4>;
> +};
And register 0x4a002370 here. Care to post some info what the
0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
on omap4, or does it have other bits there too?
The advantage for using regulator fwk and pinctrl fwk is
that the regulator and mux can be children of the SCM
core driver when we have it. And no direct register tinkering
or omap specific custom exported functions are needed ;)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
Hi,
* Kishon Vijay Abraham I [121007 23:01]:
> In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
> is assigned a device attribute to represent the attached devices.
...
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -2681,6 +2682,32 @@ static struct omap_hwmod_class
> omap44xx_ocp2scp_hwmod_class = {
> .sysc = &omap44xx_ocp2scp_sysc,
> };
>
> +/* ocp2scp dev_attr */
> +static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
> + {
> + .name = "usb_phy",
> + .start = 0x4a0ad080,
> + .end= 0x4a0ae000,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + /* XXX: Remove this once control module driver is in place */
> + .name = "ctrl_dev",
> + .start = 0x4a002300,
> + .end= 0x4a002303,
> + .flags = IORESOURCE_MEM,
> + },
> + { }
> +};
Why don't you set the CONTROL_DEV_CONF as a fixed regulator?
That way you can define the fixed regulator in mach-omap2/control.c
and the driver can just pick it up by name.
The 4470 TRM says that this register "power down entire USB
PHY" and "controls USB2PHYCORE.PD pin".
That way you can also get rid of the mysterious mdelay(200)
in omap_usb_phy_power() in omap-usb2.c driver.
However one thing needs to be checked first.
If CONTROL_DEV_CONF is not a regulator but is a signal mux,
then you can map the register with mux framework using the
pinctrl-single. See the pinctrl-single,bits binding that
was recently merged to mainline.
In the mux case you can set up the named states "default" and
"disabled" that the PHY driver can then manipulate with
pinctrl_select_state().
Note that for the mux case we don't have a non-device tree
pinctrl framework solution available, so you're probably
better off setting it up as a fixed regulator with comments
in case it really is a mux.
BTW, the reason I'm thinking CONTROL_DEV_CONF may be a mux
is because omap3 has registers named CONTROL_DEVCONF0 and
CONTROL_DEVCONF1 that mux signals for various devices.
But maybe that naming is just a coincidence.
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 v4 2/3] omap3isp: Add PHY routing configuration
Hi Sakari,
Thanks for the patch.
On Wednesday 10 October 2012 23:01:41 Sakari Ailus wrote:
> Add PHY routing configuration for both 3430 and 3630. Also add register bit
> definitions of CSIRXFE and CAMERA_PHY_CTRL registers on OMAP 3430 and 3630,
> respectively.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/platform/omap3isp/ispcsiphy.c | 92
> drivers/media/platform/omap3isp/ispreg.h| 22 +++
> 2 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> b/drivers/media/platform/omap3isp/ispcsiphy.c index 348f67e..12ae394 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -32,6 +32,98 @@
> #include "ispreg.h"
> #include "ispcsiphy.h"
>
> +static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
> + bool ccp2_strobe)
> +{
> + u32 reg = isp_reg_readl(
> + phy->isp, OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> + u32 shift, mode;
> +
> + switch (iface) {
> + case ISP_INTERFACE_CCP2B_PHY1:
> + reg &= ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
> + break;
> + case ISP_INTERFACE_CSI2C_PHY1:
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
> + mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
> + break;
> + case ISP_INTERFACE_CCP2B_PHY2:
> + reg |= OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
> + break;
> + case ISP_INTERFACE_CSI2A_PHY2:
> + shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
> + mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
> + break;
> + }
> +
> + /* Select data/clock or data/strobe mode for CCP2 */
> + switch (iface) {
> + case ISP_INTERFACE_CCP2B_PHY1:
> + case ISP_INTERFACE_CCP2B_PHY2:
> + if (ccp2_strobe)
> + mode =
> OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
> + else
> + mode =
> OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
> + }
> +
> + reg &= ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK << shift);
> + reg |= mode << shift;
> +
> + isp_reg_writel(phy->isp, reg,
> +OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> +}
> +
> +static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool
> on,
> + bool ccp2_strobe)
> +{
> + uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
> + | OMAP343X_CONTROL_CSIRXFE_RESET;
Anything wrong with u32 ? :-)
(I would also align the | with the = but that's nitpicking)
> +
> + /* Nothing to configure here. */
> + if (iface == ISP_INTERFACE_CSI2A_PHY2)
> + return;
> +
> + if (iface != ISP_INTERFACE_CCP2B_PHY1)
> + return;
Can't you get rid of the first check ?
> + if (!on) {
> + isp_reg_writel(phy->isp, 0,
> +OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
> + return;
> + }
> +
> + if (ccp2_strobe)
> + csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
> +
> + isp_reg_writel(phy->isp, csirxfe,
> +OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
> +}
> +
> +/**
> + * Configure OMAP 3 CSI PHY routing.
> + *
> + * Note that the underlying routing configuration registers are part
> + * of the control (SCM) register space and part of the CORE power
> + * domain on both 3430 and 3630, so they will not hold their contents
> + * in off-mode.
Could you please add a sentence to explain why that's not an issue ?
> + * @phy: relevant phy device
> + * @iface: ISP_INTERFACE_*
> + * @on: power on or off
> + * @ccp2_strobe: false: data/clock, true: data/strobe
> + */
> +static void csiphy_routing_cfg(struct isp_csiphy *phy, u32 iface, bool on,
> +bool ccp2_strobe)
> +{
> + if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
> + && on)
> + return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
> + if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE])
> + return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
> +}
> +
> /*
> * csiphy_lanes_config - Configuration of CSIPHY lanes.
> *
> diff --git a/drivers/media/platform/omap3isp/ispreg.h
> b/drivers/media/platform/omap3isp/ispreg.h index e2c57f3..148108b 100644
> --- a/drivers/media/platform/omap3isp/ispreg.h
> +++ b/drivers/media/platform/omap3isp/ispreg.h
> @@ -1583,4 +1583,26 @@
> #define ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_MASK\
> (0x7f << ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_SHIFT)
>
Re: [PATCH v4 3/3] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
Thanks for the patch.
On Wednesday 10 October 2012 23:01:42 Sakari Ailus wrote:
> Configure CSI-2 phy based on platform data in the ISP driver. For that, the
> new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
> was configured from the board code.
>
> This patch is dependent on "omap3: Provide means for changing CSI2 PHY
> configuration".
Is it still ?
> Signed-off-by: Sakari Ailus
> Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/omap3isp/isp.h |3 -
> drivers/media/platform/omap3isp/ispcsiphy.c | 148
> drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
> 3 files changed, 78 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 6fed222..accb3b0 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -129,9 +129,6 @@ struct isp_reg {
>
> struct isp_platform_callback {
> u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
> - int (*csiphy_config)(struct isp_csiphy *phy,
> - struct isp_csiphy_dphy_cfg *dphy,
> - struct isp_csiphy_lanes_cfg *lanes);
> };
>
> /*
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> b/drivers/media/platform/omap3isp/ispcsiphy.c index 12ae394..754d7a1 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -125,36 +125,6 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
> u32 iface, bool on, }
>
> /*
> - * csiphy_lanes_config - Configuration of CSIPHY lanes.
> - *
> - * Updates HW configuration.
> - * Called with phy->mutex taken.
> - */
> -static void csiphy_lanes_config(struct isp_csiphy *phy)
> -{
> - unsigned int i;
> - u32 reg;
> -
> - reg = isp_reg_readl(phy->isp, phy->cfg_regs, ISPCSI2_PHY_CFG);
> -
> - for (i = 0; i < phy->num_data_lanes; i++) {
> - reg &= ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
> - ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
> - reg |= (phy->lanes.data[i].pol <<
> - ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
> - reg |= (phy->lanes.data[i].pos <<
> - ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
> - }
> -
> - reg &= ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
> - ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
> - reg |= phy->lanes.clk.pol << ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
> - reg |= phy->lanes.clk.pos << ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
> -
> - isp_reg_writel(phy->isp, reg, phy->cfg_regs, ISPCSI2_PHY_CFG);
> -}
> -
> -/*
> * csiphy_power_autoswitch_enable
> * @enable: Sets or clears the autoswitch function enable flag.
> */
> @@ -199,43 +169,28 @@ static int csiphy_set_power(struct isp_csiphy *phy,
> u32 power) }
>
> /*
> - * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
> - *
> - * Called with phy->mutex taken.
> + * TCLK values are OK at their reset values
> */
> -static void csiphy_dphy_config(struct isp_csiphy *phy)
> -{
> - u32 reg;
> -
> - /* Set up ISPCSIPHY_REG0 */
> - reg = isp_reg_readl(phy->isp, phy->phy_regs, ISPCSIPHY_REG0);
> -
> - reg &= ~(ISPCSIPHY_REG0_THS_TERM_MASK |
> - ISPCSIPHY_REG0_THS_SETTLE_MASK);
> - reg |= phy->dphy.ths_term << ISPCSIPHY_REG0_THS_TERM_SHIFT;
> - reg |= phy->dphy.ths_settle << ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
> -
> - isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG0);
> -
> - /* Set up ISPCSIPHY_REG1 */
> - reg = isp_reg_readl(phy->isp, phy->phy_regs, ISPCSIPHY_REG1);
> -
> - reg &= ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
> - ISPCSIPHY_REG1_TCLK_MISS_MASK |
> - ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
> - reg |= phy->dphy.tclk_term << ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
> - reg |= phy->dphy.tclk_miss << ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
> - reg |= phy->dphy.tclk_settle << ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
> +#define TCLK_TERM0
> +#define TCLK_MISS1
> +#define TCLK_SETTLE 14
>
> - isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
> -}
> -
> -static int csiphy_config(struct isp_csiphy *phy,
> - struct isp_csiphy_dphy_cfg *dphy,
> - struct isp_csiphy_lanes_cfg *lanes)
> +static int omap3isp_csiphy_config(struct isp_csiphy *phy)
> {
> + struct isp_csi2_device *csi2 = phy->csi2;
> + struct isp_pipeline *pipe = to_isp_pipeline(&csi2->subdev.entity);
> + struct isp_v4l2_subdevs_group *subdevs = pipe->external->host_priv;
> + struct isp_csiphy_lanes_cfg *lanes;
> + int csi2_ddrclk_khz;
> unsigned int used_lanes = 0;
> unsigned int i;
> + u32 reg;
> +
> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1
> + || subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
> + lanes = &subdevs->bus.ccp2.lanecfg;
[PATCH v4 2/3] omap3isp: Add PHY routing configuration
Add PHY routing configuration for both 3430 and 3630. Also add register bit
definitions of CSIRXFE and CAMERA_PHY_CTRL registers on OMAP 3430 and 3630,
respectively.
Signed-off-by: Sakari Ailus
---
drivers/media/platform/omap3isp/ispcsiphy.c | 92 +++
drivers/media/platform/omap3isp/ispreg.h| 22 +++
2 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 348f67e..12ae394 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -32,6 +32,98 @@
#include "ispreg.h"
#include "ispcsiphy.h"
+static void csiphy_routing_cfg_3630(struct isp_csiphy *phy, u32 iface,
+ bool ccp2_strobe)
+{
+ u32 reg = isp_reg_readl(
+ phy->isp, OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
+ u32 shift, mode;
+
+ switch (iface) {
+ case ISP_INTERFACE_CCP2B_PHY1:
+ reg &= ~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ break;
+ case ISP_INTERFACE_CSI2C_PHY1:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ case ISP_INTERFACE_CCP2B_PHY2:
+ reg |= OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ break;
+ case ISP_INTERFACE_CSI2A_PHY2:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ }
+
+ /* Select data/clock or data/strobe mode for CCP2 */
+ switch (iface) {
+ case ISP_INTERFACE_CCP2B_PHY1:
+ case ISP_INTERFACE_CCP2B_PHY2:
+ if (ccp2_strobe)
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
+ else
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
+ }
+
+ reg &= ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK << shift);
+ reg |= mode << shift;
+
+ isp_reg_writel(phy->isp, reg,
+ OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
+}
+
+static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool on,
+ bool ccp2_strobe)
+{
+ uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
+ | OMAP343X_CONTROL_CSIRXFE_RESET;
+
+ /* Nothing to configure here. */
+ if (iface == ISP_INTERFACE_CSI2A_PHY2)
+ return;
+
+ if (iface != ISP_INTERFACE_CCP2B_PHY1)
+ return;
+
+ if (!on) {
+ isp_reg_writel(phy->isp, 0,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
+ return;
+ }
+
+ if (ccp2_strobe)
+ csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+
+ isp_reg_writel(phy->isp, csirxfe,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
+}
+
+/**
+ * Configure OMAP 3 CSI PHY routing.
+ *
+ * Note that the underlying routing configuration registers are part
+ * of the control (SCM) register space and part of the CORE power
+ * domain on both 3430 and 3630, so they will not hold their contents
+ * in off-mode.
+ *
+ * @phy: relevant phy device
+ * @iface: ISP_INTERFACE_*
+ * @on: power on or off
+ * @ccp2_strobe: false: data/clock, true: data/strobe
+ */
+static void csiphy_routing_cfg(struct isp_csiphy *phy, u32 iface, bool on,
+ bool ccp2_strobe)
+{
+ if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
+ && on)
+ return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
+ if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE])
+ return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
+}
+
/*
* csiphy_lanes_config - Configuration of CSIPHY lanes.
*
diff --git a/drivers/media/platform/omap3isp/ispreg.h
b/drivers/media/platform/omap3isp/ispreg.h
index e2c57f3..148108b 100644
--- a/drivers/media/platform/omap3isp/ispreg.h
+++ b/drivers/media/platform/omap3isp/ispreg.h
@@ -1583,4 +1583,26 @@
#define ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_MASK \
(0x7f << ISPCSIPHY_REG2_CCP2_SYNC_PATTERN_SHIFT)
+/*
-
+ * CONTROL registers for CSI-2 phy routing
+ */
+
+/* OMAP343X_CONTROL_CSIRXFE */
+#define OMAP343X_CONTROL_CSIRXFE_CSIB_INV (1 << 7)
+#define OMAP343X_CONTROL_CSIRXFE_RESENABLE (1 << 8)
+#define OMAP343X_CONTROL_CSIRXFE_SELFORM (1 << 10)
+#define OMAP343X_CONTROL_CSIRXFE_PWRDNZ(1 << 12)
+#define OMAP
[PATCH v4 3/3] omap3isp: Configure CSI-2 phy based on platform data
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
This patch is dependent on "omap3: Provide means for changing CSI2 PHY
configuration".
Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
---
drivers/media/platform/omap3isp/isp.h |3 -
drivers/media/platform/omap3isp/ispcsiphy.c | 148 ++-
drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
3 files changed, 78 insertions(+), 83 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 6fed222..accb3b0 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -129,9 +129,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes);
};
/*
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 12ae394..754d7a1 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -125,36 +125,6 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy, u32
iface, bool on,
}
/*
- * csiphy_lanes_config - Configuration of CSIPHY lanes.
- *
- * Updates HW configuration.
- * Called with phy->mutex taken.
- */
-static void csiphy_lanes_config(struct isp_csiphy *phy)
-{
- unsigned int i;
- u32 reg;
-
- reg = isp_reg_readl(phy->isp, phy->cfg_regs, ISPCSI2_PHY_CFG);
-
- for (i = 0; i < phy->num_data_lanes; i++) {
- reg &= ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
-ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
- reg |= (phy->lanes.data[i].pol <<
- ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
- reg |= (phy->lanes.data[i].pos <<
- ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
- }
-
- reg &= ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
-ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
- reg |= phy->lanes.clk.pol << ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
- reg |= phy->lanes.clk.pos << ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
-
- isp_reg_writel(phy->isp, reg, phy->cfg_regs, ISPCSI2_PHY_CFG);
-}
-
-/*
* csiphy_power_autoswitch_enable
* @enable: Sets or clears the autoswitch function enable flag.
*/
@@ -199,43 +169,28 @@ static int csiphy_set_power(struct isp_csiphy *phy, u32
power)
}
/*
- * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
- *
- * Called with phy->mutex taken.
+ * TCLK values are OK at their reset values
*/
-static void csiphy_dphy_config(struct isp_csiphy *phy)
-{
- u32 reg;
-
- /* Set up ISPCSIPHY_REG0 */
- reg = isp_reg_readl(phy->isp, phy->phy_regs, ISPCSIPHY_REG0);
-
- reg &= ~(ISPCSIPHY_REG0_THS_TERM_MASK |
-ISPCSIPHY_REG0_THS_SETTLE_MASK);
- reg |= phy->dphy.ths_term << ISPCSIPHY_REG0_THS_TERM_SHIFT;
- reg |= phy->dphy.ths_settle << ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
-
- isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG0);
-
- /* Set up ISPCSIPHY_REG1 */
- reg = isp_reg_readl(phy->isp, phy->phy_regs, ISPCSIPHY_REG1);
-
- reg &= ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
-ISPCSIPHY_REG1_TCLK_MISS_MASK |
-ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
- reg |= phy->dphy.tclk_term << ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
- reg |= phy->dphy.tclk_miss << ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
- reg |= phy->dphy.tclk_settle << ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE14
- isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
-}
-
-static int csiphy_config(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes)
+static int omap3isp_csiphy_config(struct isp_csiphy *phy)
{
+ struct isp_csi2_device *csi2 = phy->csi2;
+ struct isp_pipeline *pipe = to_isp_pipeline(&csi2->subdev.entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe->external->host_priv;
+ struct isp_csiphy_lanes_cfg *lanes;
+ int csi2_ddrclk_khz;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 reg;
+
+ if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = &subdevs->bus.ccp2.lanecfg;
+ else
+ lanes = &subdevs->bus.csi2.lanecfg;
/* Clock and data lanes verification */
for (i = 0; i < phy->num_data_lanes; i++) {
@@ -254,10 +209,56 @@ static int csiphy_config(struct isp_csiphy *phy,
[PATCH v4 1/3] omap3isp: Add CSI configuration registers from control block to ISP resources
Add the registers used to configure the CSI-2 receiver PHY on OMAP3430 and
3630 and map them in the ISP driver. The register is part of the control
block but it only is needed by the ISP driver.
Signed-off-by: Sakari Ailus
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c | 10 ++
drivers/media/platform/omap3isp/isp.c |6 --
drivers/media/platform/omap3isp/isp.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..9e4d5da 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -201,6 +201,16 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
+ .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
+ .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
+ 3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL,
+ .end= OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
.start = INT_34XX_CAM_IRQ,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 6034dca..972e7b5 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -100,7 +100,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_RESZ |
1 << OMAP3_ISP_IOMEM_SBL |
1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
- 1 << OMAP3_ISP_IOMEM_CSIPHY2,
+ 1 << OMAP3_ISP_IOMEM_CSIPHY2 |
+ 1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
},
{
.isp_rev = ISP_REVISION_15_0,
@@ -117,7 +118,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
1 << OMAP3_ISP_IOMEM_CSIPHY1 |
- 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
+ 1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
},
};
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..6fed222 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -72,6 +72,8 @@ enum isp_mem_resources {
OMAP3_ISP_IOMEM_CSI2C_REGS1,
OMAP3_ISP_IOMEM_CSIPHY1,
OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
+ OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
OMAP3_ISP_IOMEM_LAST
};
--
1.7.2.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 v4 0/3] OMAP 3 CSI-2 configuration
Hi all, This is an update to an old patchset for CSI-2 configuration for OMAP 3430 and 3630. The patches have been tested on the 3630 only so far, and I don't plan to test them on 3430 in the near future. Changes made based on Kevin's and Laurent's comments since v3. Comments, questions and other kind of feedback is very welcome. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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.6.0- 0/6] ARM: use module_platform_driver macro
Hi On Wed, 10 Oct 2012, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > Running below Coccinelle lookup pattern like below on the > latest kernel showed about 52 hits. This patch series is a subset > of those 52 patches, so that it will be easy for maintainers to review. so the idea looks okay to me, but several of the patches aren't addressed to the right people. You can use the MAINTAINERS file to figure out the right place to send them. The PXA patches need to go to the appropriate PXA people, who are probably: M: Eric Miao M: Russell King M: Haojian Zhuang L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) The OMAP RNG patch needs to go to M: Deepak Saxena M: Matt Mackall M: Herbert Xu As far as the remaining three OMAP patches go, they look okay to me but Tony Lindgren is the maintainer of these files and so he's the right person to merge them. > Hopefully these patches will get rid of some code duplication in kernel. One other comment - the description on the patches isn't quite accurate. The patches don't remove code duplication per se, they just replace some boilerplate code with a macro. - Paul -- 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.6.0- 6/6] omap_rng: use module_platform_driver macro
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
drivers/char/hw_random/omap-rng.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index a5effd8..29732c6 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -217,19 +217,7 @@ static struct platform_driver omap_rng_driver = {
.probe = omap_rng_probe,
.remove = __exit_p(omap_rng_remove),
};
-
-static int __init omap_rng_init(void)
-{
- return platform_driver_register(&omap_rng_driver);
-}
-
-static void __exit omap_rng_exit(void)
-{
- platform_driver_unregister(&omap_rng_driver);
-}
-
-module_init(omap_rng_init);
-module_exit(omap_rng_exit);
+module_platform_driver(omap_rng_driver);
MODULE_AUTHOR("Deepak Saxena (and others)");
MODULE_LICENSE("GPL");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6.0- 5/6] ARM/omap: use module_platform_driver macro
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/plat-omap/dmtimer.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 938b50a..c89fc6a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -786,19 +786,8 @@ static struct platform_driver omap_dm_timer_driver = {
},
};
-static int __init omap_dm_timer_driver_init(void)
-{
- return platform_driver_register(&omap_dm_timer_driver);
-}
-
-static void __exit omap_dm_timer_driver_exit(void)
-{
- platform_driver_unregister(&omap_dm_timer_driver);
-}
-
early_platform_init("earlytimer", &omap_dm_timer_driver);
-module_init(omap_dm_timer_driver_init);
-module_exit(omap_dm_timer_driver_exit);
+module_platform_driver(omap_dm_timer_driver);
MODULE_DESCRIPTION("OMAP Dual-Mode Timer Driver");
MODULE_LICENSE("GPL");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6.0- 4/6] ARM/pxa: use module_platform_driver macro
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/mach-pxa/tosa-bt.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-pxa/tosa-bt.c b/arch/arm/mach-pxa/tosa-bt.c
index b9b1e5c..fe2a9e1 100644
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,17 +132,4 @@ static struct platform_driver tosa_bt_driver = {
.owner = THIS_MODULE,
},
};
-
-
-static int __init tosa_bt_init(void)
-{
- return platform_driver_register(&tosa_bt_driver);
-}
-
-static void __exit tosa_bt_exit(void)
-{
- platform_driver_unregister(&tosa_bt_driver);
-}
-
-module_init(tosa_bt_init);
-module_exit(tosa_bt_exit);
+module_platform_driver(tosa_bt_driver);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6.0- 3/6] ARM/pxa: use module_platform_driver macro
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/mach-pxa/pxa3xx-ulpi.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index 7dbe3cc..e329cce 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -384,18 +384,7 @@ static struct platform_driver pxa3xx_u2d_ulpi_driver = {
.probe = pxa3xx_u2d_probe,
.remove = pxa3xx_u2d_remove,
};
-
-static int pxa3xx_u2d_ulpi_init(void)
-{
- return platform_driver_register(&pxa3xx_u2d_ulpi_driver);
-}
-module_init(pxa3xx_u2d_ulpi_init);
-
-static void __exit pxa3xx_u2d_ulpi_exit(void)
-{
- platform_driver_unregister(&pxa3xx_u2d_ulpi_driver);
-}
-module_exit(pxa3xx_u2d_ulpi_exit);
+module_platform_driver(pxa3xx_u2d_ulpi_driver);
MODULE_DESCRIPTION("PXA3xx U2D ULPI driver");
MODULE_AUTHOR("Igor Grinberg");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6.0- 2/6] ARM/omap2: use module_platform_driver macro
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/mach-omap2/mailbox.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..eb64ca9 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -409,19 +409,7 @@ static struct platform_driver omap2_mbox_driver = {
.name = "omap-mailbox",
},
};
-
-static int __init omap2_mbox_init(void)
-{
- return platform_driver_register(&omap2_mbox_driver);
-}
-
-static void __exit omap2_mbox_exit(void)
-{
- platform_driver_unregister(&omap2_mbox_driver);
-}
-
-module_init(omap2_mbox_init);
-module_exit(omap2_mbox_exit);
+module_platform_driver(omap2_mbox_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap2/3/4 architecture specific functions");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6.0- 1/6] ARM/omap1: use module_platform_driver macro
From: Srinivas Kandagatla
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/mach-omap1/mailbox.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index e962926..45c8719 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -179,19 +179,7 @@ static struct platform_driver omap1_mbox_driver = {
.name = "omap-mailbox",
},
};
-
-static int __init omap1_mbox_init(void)
-{
- return platform_driver_register(&omap1_mbox_driver);
-}
-
-static void __exit omap1_mbox_exit(void)
-{
- platform_driver_unregister(&omap1_mbox_driver);
-}
-
-module_init(omap1_mbox_init);
-module_exit(omap1_mbox_exit);
+module_platform_driver(omap1_mbox_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap1 architecture specific functions");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.6.0- 0/6] ARM: use module_platform_driver macro
From: Srinivas Kandagatla
Running below Coccinelle lookup pattern like below on the
latest kernel showed about 52 hits. This patch series is a subset
of those 52 patches, so that it will be easy for maintainers to review.
Hopefully these patches will get rid of some code duplication in kernel.
@ @
- initfunc(void)
- { return platform_driver_register(&dr); }
...
- module_init(initfunc);
...
- exitfunc(void)
- { platform_driver_unregister(&dr); }
...
- module_exit(exitfunc);
+ module_platform_driver(dr);
Srinivas Kandagatla (6):
ARM/omap1: use module_platform_driver macro
ARM/omap2: use module_platform_driver macro
ARM/pxa: use module_platform_driver macro
ARM/pxa: use module_platform_driver macro
ARM/omap: use module_platform_driver macro
omap_rng: use module_platform_driver macro
arch/arm/mach-omap1/mailbox.c | 14 +-
arch/arm/mach-omap2/mailbox.c | 14 +-
arch/arm/mach-pxa/pxa3xx-ulpi.c | 13 +
arch/arm/mach-pxa/tosa-bt.c | 15 +--
arch/arm/plat-omap/dmtimer.c | 13 +
drivers/char/hw_random/omap-rng.c | 14 +-
6 files changed, 6 insertions(+), 77 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Sourav, Sourav writes: [...] > Boot Tested this patch series against v3.6 tag(applied cleanly) on > panda board and > PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. > > Note, I also tested the patches against the current master but only > after rebasing, since the current master includes serial patches from > Felipe Balbi[1]. > [1] https://lkml.org/lkml/2012/8/24/139 > > Tested-by: Sourav Poddar Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
Tomi Valkeinen writes: > On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote: >> Hi Tomi, >> >> Tomi Valkeinen writes: >> >> > This patch converts vrfb library into a platform device, in an effort to >> > remove omap dependencies. >> > >> > The platform device is registered in arch/arm/plat-omap/fb.c and >> > assigned resources depending on whether running on omap2 or omap3. >> > >> > The vrfb driver will parse those resources and use them to access vrfb >> > configuration registers and the vrfb virtual rotation areas. >> > >> > Signed-off-by: Tomi Valkeinen >> > Cc: Tony Lindgren >> >> [...] >> >> I was having a quick look at this for the context save/restore piece in >> order to understand how this driver's context is being saved/restored. >> >> Looking at mainline, I don't see where omap_vrfb_restore_context() is >> being called currently. Am I missing something? > > No, the driver is missing something. I noticed the same thing. It seems > ctx restore for vrfb has never been functional in mainline. I don't > really have any recollection if this was left out intentionally from > mainline (possibly because we didn't have a good way to handle it at > that point), or was it just a mistake. > > Nobody has complained about it, though, so it can't be a major problem > =). heh > Vrfb is a platform device/driver after this patch. Do you see any > problem with handling the context restore in runtime PM's runtime_resume > callback? No, that's the right way to handle it IMO. In fact, that's what I was going to check on when reviewing this patch when I noticed that the restore function wasn't being used. > Hmm, I guess then we could have a problem if omapdss and > omapfb are resumed before vrfb. Possibly, but this could be handled by adding some sanity checks, or having VRFB functions return -EAGAIN if it hasn't been resumed. Or better yet, VRFB functions should be using runtime PM get/put themselves, if they're used by omapdss/omapfb, a runtime resume (and context restore) is forced. (disclaimer: I don't actually know how VRFB works, so maybe this isn't possible.) > Any way to manage the suspend/resume ordering of unrelated (i.e. no > parent/child relation) devices? No good way at the moment. And to make things interesting: static suspend/resume ordering is not dependent on parent/child. It's based on driver discover/probe order. runtime PM ordering manages parent/child relationships. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: xhci: Add the suspend/resume functionality
On Wed, Oct 10, 2012 at 07:35:48PM +0530, Vikas C Sajjan wrote:
> From: Vikas Sajjan
>
> Adding the suspend and resume functionality for the XHCI driver
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vikas C Sajjan
> CC: Doug Anderson
Acked-by: Sarah Sharp
Felipe, you want to take this?
> ---
> drivers/usb/host/xhci-plat.c | 44
> ++
> 1 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index df90fe5..384cf4d 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -185,11 +185,55 @@ static int xhci_plat_remove(struct platform_device *dev)
> return 0;
> }
>
> +#ifdef CONFIG_PM
> +static int xhci_plat_suspend(struct device *dev)
> +{
> + struct usb_hcd *hcd;
> + struct xhci_hcd *xhci;
> +
> + hcd = dev_get_drvdata(dev);
> + if (!hcd)
> + return -EINVAL;
> +
> + xhci = hcd_to_xhci(hcd);
> +
> + /* Make sure that the HCD Core as set state HC_STATE_SUSPENDED */
> + if (hcd->state != HC_STATE_SUSPENDED ||
> + xhci->shared_hcd->state != HC_STATE_SUSPENDED)
> + return -EINVAL;
> +
> + return xhci_suspend(xhci);
> +}
> +
> +static int xhci_plat_resume(struct device *dev)
> +{
> + struct usb_hcd *hcd;
> + struct xhci_hcd *xhci;
> +
> + hcd = dev_get_drvdata(dev);
> +
> + if (!hcd)
> + return -EINVAL;
> +
> + xhci = hcd_to_xhci(hcd);
> +
> + return xhci_resume(xhci, 0);
> +}
> +
> +static const struct dev_pm_ops xhci_plat_pm_ops = {
> + .suspend= xhci_plat_suspend,
> + .resume = xhci_plat_resume,
> +};
> +#endif
> +
> static struct platform_driver usb_xhci_driver = {
> .probe = xhci_plat_probe,
> .remove = xhci_plat_remove,
> .driver = {
> .name = "xhci-hcd",
> +#ifdef CONFIG_PM
> + .pm = &xhci_plat_pm_ops,
> +#endif
> },
> };
> MODULE_ALIAS("platform:xhci-hcd");
> --
> 1.7.6.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 4/4] mtd: nand: omap2: Add data correction support
On Tue, Oct 09, 2012 at 01:36:50PM +0100, Philip, Avinash wrote: (...) > > There are at least 2 potential problems when reading an erased page with > > bitflips: > > > > 1. bitflip in data area and no bitflip in spare area (all 0xff) > > Your code will not perform any ECC correction. > > UBIFS does not like finding bitflips in empty pages, see for instance > > http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html. > > In case of error correction using ELM, syndrome vector calculated after > reading > Data area & OOB area. So handling of erased page requires a software > workaround. > I am planning something as follows. > > I will first check calculated ecc, which would be zero for non error pages. > Then I would check 0xFF in OOB area (for erased page) by checking number of > bit zeros in OOB area. If it is 0xFF (number of bit zero count is zero), > set entire page as 0xFF if number of bit zeros is less than max bit flips > (8 or 4) by counting the number of bit zero's in data area. > > This logic is implemented in fsmc_nand.c > > See commit > mtd: fsmc: Newly erased page read algorithm implemented > > > > > 2. bitflip in ECC bytes in spare area > > Your code will report an uncorrectable error upon reading; if this happens > > while reading a partially programmed UBI block, > > I guess you will lose data. > > In case of uncorrectable errors due to bit flips in spare area, > I can go on checking number of bit zero's in data area + OOB area > are less than max bit flips (8 or 4), I can go on setting the entire > page as 0xFF. > OK, sounds reasonable. Another simple strategy could use the fact that you add a 14th zero byte to the 13 BCH bytes for RBL compatibility: Upon reading: - if this 14th byte is zero (*) => page was programmed: perform ECC correction as usual - else, page was not programmed: do not perform ECC, read entire data+spare area, and set it to 0xff if less than 8 or 4 (max bitflips) zero bits were found (*) for robustness to bitflip in 14th byte, replace condition "14th byte is zero" by e.g. "14th byte has less than 4 bits set to 1". What do you think ? BR, -- Ivan -- 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 00/14] OMAP-GPMC related cleanup for common zImage
On Mon, Oct 08, 2012 at 07:08:08AM +0100, Mohammed, Afzal wrote: > Hi Ivan, > > On Mon, Oct 08, 2012 at 11:05:56, Mohammed, Afzal wrote: > > > This series cleans up omap-gpmc related code so that omap can > > be a part of common zImage. > > > This series moves gpmc.h from plat-omap/include/plat to mach-omap2 > > so that header file is local. > > > Patches 7 & 8 cleans up the already moved platform data header files > > to contain only platform data. Also gpmc-nand information is moved > > to nand platform data header. > > > > Patches 9-13 makes nand driver independent of gpmc header file > > > > And the final patch localizes gpmc header. > > BCH[48] support that you have added on OMAP using gpmc exported > symbols has been changed such that nand driver now takes care > of BCH support without relying on gpmc exported symbols. > > This is more or less a cut & paste of your implementation, which was > necessitated now due to common ARM zImage cleanup w.r.t header files. > > Please verify that BCH[48] works as earlier with this series. Hi Afzal, I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2 tag. All BCH error correcting tests passed successfully. I occasionally had weird read errors though, especially when reading blank pages: the omap driver returned 512-byte sectors containing something like: 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff instead of: I was able to reproduce the problem also on l2-mtd tip, albeit less often. The problem seems to occur quite randomly, it may be a hardware issue on my board... Anyway, the ECC handling part looks OK to me. Best regards, -- Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
You should CC devicetree-disc...@lists.ozlabs.org for any Device tree patches. This is applicable for the whole series. On 10/10/2012 02:05 PM, Lokesh Vutla wrote: > Patch 1: > Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi > Patch 2: > Correcting size of memory defined for omap5 > Patch 3: > EMIF and LPDDR2 device tree data for OMAP5 boards > There is not point to list the patch subject in a cover letter. You should just introduce the series and ideally give details about the test like you have done below. The cover letter should mostly be written like an email. Benoit > Testing: > - Boot tested on omap5-sevm board > - Built emif as a module > > Lokesh Vutla (3): > ARM: dts: Renaming elpida_ecb240abacn.dts as lpddr2_data.dtsi > ARM: dts: Correcting size of memory defined for omap5 > ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards > > arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 --- > arch/arm/boot/dts/lpddr2_data.dtsi| 129 > + > arch/arm/boot/dts/omap4-panda.dts |2 +- > arch/arm/boot/dts/omap4-sdp.dts |2 +- > arch/arm/boot/dts/omap5-evm.dts | 13 ++- > arch/arm/boot/dts/omap5.dtsi | 18 > 6 files changed, 161 insertions(+), 70 deletions(-) > delete mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi > create mode 100644 arch/arm/boot/dts/lpddr2_data.dtsi > -- 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/3] ARM: dts: Correcting size of memory defined for omap5
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
> Memory present for omap5 is 2GB. But in dt file
omap5 -> OMAP5
dt -> dts
And this patch is about omap5-evm so you should be more specific in your
changelog and even in the subject:
ARM: dts: omap5-evm: Fix size of memory defined for EVM
> it is specified as 1GB. Correcting the same
> in this patch
No "patch" in the changelog, please add a dot at the end of a sentence
and make a correct sentence.
Regards,
Benoit
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/boot/dts/omap5-evm.dts |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index 9c41a3f..6f87e1a 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -15,7 +15,7 @@
>
> memory {
> device_type = "memory";
> - reg = <0x8000 0x4000>; /* 1 GB */
> + reg = <0x8000 0x8000>; /* 2 GB */
> };
>
> vmmcsd_fixed: fixedregulator-mmcsd {
>
--
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/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
> Device tree data for the EMIF sdram controllers in OMAP5
> and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/boot/dts/lpddr2_data.dtsi | 64
> +++-
> arch/arm/boot/dts/omap5-evm.dts| 11 +++
> arch/arm/boot/dts/omap5.dtsi | 18 ++
> 3 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
> b/arch/arm/boot/dts/lpddr2_data.dtsi
> index f97f70f..8e8c1bc 100644
> --- a/arch/arm/boot/dts/lpddr2_data.dtsi
> +++ b/arch/arm/boot/dts/lpddr2_data.dtsi
> @@ -3,7 +3,7 @@
> */
>
> / {
> - elpida_ECB240ABACN: lpddr2 {
> + elpida_ECB240ABACN: lpddr2@0 {
> compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4";
> density = <2048>;
> io-width= <32>;
> @@ -64,4 +64,66 @@
> tDQSCK-max-derated = <6000>;
> };
> };
> +
> + samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
> + compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
> + density = <4096>;
> + io-width= <32>;
> +
> + tRPab-min-tck = <3>;
> + tRCD-min-tck= <3>;
> + tWR-min-tck = <3>;
> + tRASmin-min-tck = <3>;
> + tRRD-min-tck= <2>;
> + tWTR-min-tck= <2>;
> + tXP-min-tck = <2>;
> + tRTP-min-tck= <2>;
> + tCKE-min-tck= <3>;
> + tCKESR-min-tck = <3>;
> + tFAW-min-tck= <8>;
> +
> + timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
> + compatible = "jedec,lpddr2-timings";
> + min-freq= <1000>;
> + max-freq= <5>;
> + tRPab = <21000>;
> + tRCD= <18000>;
> + tWR = <15000>;
> + tRAS-min= <42000>;
> + tRRD= <1>;
> + tWTR= <7500>;
> + tXP = <7500>;
> + tRTP= <7500>;
> + tCKESR = <15000>;
> + tDQSCK-max = <5500>;
> + tFAW= <5>;
> + tZQCS = <9>;
> + tZQCL = <36>;
> + tZQinit = <100>;
> + tRAS-max-ns = <7>;
> + tDQSCK-max-derated = <5620>;
> + };
> +
> + timings_samsung_K3PE0E000B_266mhz: lpddr2-timings@1 {
> + compatible = "jedec,lpddr2-timings";
> + min-freq= <1000>;
> + max-freq= <2>;
> + tRPab = <21000>;
> + tRCD= <18000>;
> + tWR = <15000>;
> + tRAS-min= <42000>;
> + tRRD= <1>;
> + tWTR= <7500>;
> + tXP = <7500>;
> + tRTP= <7500>;
> + tCKESR = <15000>;
> + tDQSCK-max = <5500>;
> + tFAW= <5>;
> + tZQCS = <9>;
> + tZQCL = <36>;
> + tZQinit = <100>;
> + tRAS-max-ns = <7>;
> + tDQSCK-max-derated = <6000>;
> + };
> + };
> };
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index 6f87e1a..8a952f8 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -8,6 +8,7 @@
> /dts-v1/;
>
> /include/ "omap5.dtsi"
> +/include/ "lpddr2_data.dtsi"
>
> / {
> model = "TI OMAP5 EVM board";
> @@ -82,3 +83,13 @@
> 0x020700d9>;/* SEARCH */
> linux,input-no-autorepeat;
> };
> +
> +&emif1 {
> + cs1-used;
> + device-handle = <&samsung_K3PE0E000B>;
> +};
> +
> +&emif2 {
> + cs1-used;
> + device-handle = <&samsung_K3PE0E000B>;
> +};
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 5db33f4..40b41c2 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -319,5 +319,23 @@
>
Re: [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
Hi Lokesh,
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
> Renaming elpida_ecb240abacn.dtsi file generic, so that the
> same file can be reused for other parts from different vendors.
Could you elaborate a little bit?
Are these settings purely reflecting lpddr2 spec timings?
Regards,
Benoit
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} |0
> arch/arm/boot/dts/omap4-panda.dts |2 +-
> arch/arm/boot/dts/omap4-sdp.dts |2 +-
> 3 files changed, 2 insertions(+), 2 deletions(-)
> rename arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} (100%)
>
> diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
> b/arch/arm/boot/dts/lpddr2_data.dtsi
> similarity index 100%
> rename from arch/arm/boot/dts/elpida_ecb240abacn.dtsi
> rename to arch/arm/boot/dts/lpddr2_data.dtsi
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 20b966e..09d3a32 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -8,7 +8,7 @@
> /dts-v1/;
>
> /include/ "omap4.dtsi"
> -/include/ "elpida_ecb240abacn.dtsi"
> +/include/ "lpddr2_data.dtsi"
>
> / {
> model = "TI OMAP4 PandaBoard";
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 94a23b3..dd749fc 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -8,7 +8,7 @@
> /dts-v1/;
>
> /include/ "omap4.dtsi"
> -/include/ "elpida_ecb240abacn.dtsi"
> +/include/ "lpddr2_data.dtsi"
>
> / {
> model = "TI OMAP4 SDP board";
>
--
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: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On Wed, Oct 10, 2012 at 10:35:01AM -0400, Matt Porter wrote: > On Wed, Oct 10, 2012 at 02:19:40PM +, Vaibhav Hiremath wrote: > > On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote: > > > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote: > > > > With recent changes in omap gpmc driver code, in case of DT > > > > boot mode, where bootloader does not configure gpmc cs space > > > > will result into kernel BUG() inside gpmc_mem_init() function, > > > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and > > > > gpmc_config7[0].baseaddress is set to '0' on reset. > > > > > > > > This use-case is applicable for any board/EVM which doesn't have > > > > any peripheral connected to gpmc cs0, for example BeagleXM and > > > > BeagleBone, so DT boot mode fails. > > > > > > > > This patch adds of_have_populated_dt() check before creating > > > > device, so that for DT boot mode, gpmc probe will not be called > > > > which is expected behavior, as gpmc is not supported yet from DT. > > > > > > > > Signed-off-by: Vaibhav Hiremath > > > > Cc: Afzal Mohammed > > > > Cc: Tony Lindgren > > > > Cc Paul Walmsley > > > > --- > > > > This should go in for rc1, as this breaks AM33xx boot. > > > > > > Fixes BeagleBone on mainline. > > > > > > Tested-by: Matt Porter > > > > > > > Thanks Matt and Afzal, > > > > Tony can this be picked up for rc1?? I know you have already sent pull > > request for rc1, but by any chance you are planning to send another request? > > I also found a separate problem with the mcasp clock data that's needed > for rc1. I just posted a patch for that as I need both this patch and the > clock data fix to boot from current mainline. Disregard now that you got me pointed to the pull request with this :) -Matt -- 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: OMAP2+: AM33XX: clock data: fix mcasp entries
On Wed, Oct 10, 2012 at 02:33:54PM +, Vaibhav Hiremath wrote: > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > > exposes a bug in the AM33XX clock data for mcasp. After moving to > > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > > due to incorrect clock data causing clk_get() to fail. This causes all > > successive hwmods to fail to _init() leaving them in a bad state. > > > > This patch updates the mcasp clock entries so clk_get() will succeed. > > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > > boot. > > > > Matt, > > I have already submitted patch for this and it is accepted and merged in > Tony's pull request. > > https://patchwork.kernel.org/patch/1499271/ Heh, ok. My search skills failed badly when I ran into this. Thanks :) -Matt -- 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: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On Wed, Oct 10, 2012 at 02:19:40PM +, Vaibhav Hiremath wrote: > On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote: > > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote: > > > With recent changes in omap gpmc driver code, in case of DT > > > boot mode, where bootloader does not configure gpmc cs space > > > will result into kernel BUG() inside gpmc_mem_init() function, > > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and > > > gpmc_config7[0].baseaddress is set to '0' on reset. > > > > > > This use-case is applicable for any board/EVM which doesn't have > > > any peripheral connected to gpmc cs0, for example BeagleXM and > > > BeagleBone, so DT boot mode fails. > > > > > > This patch adds of_have_populated_dt() check before creating > > > device, so that for DT boot mode, gpmc probe will not be called > > > which is expected behavior, as gpmc is not supported yet from DT. > > > > > > Signed-off-by: Vaibhav Hiremath > > > Cc: Afzal Mohammed > > > Cc: Tony Lindgren > > > Cc Paul Walmsley > > > --- > > > This should go in for rc1, as this breaks AM33xx boot. > > > > Fixes BeagleBone on mainline. > > > > Tested-by: Matt Porter > > > > Thanks Matt and Afzal, > > Tony can this be picked up for rc1?? I know you have already sent pull > request for rc1, but by any chance you are planning to send another request? I also found a separate problem with the mcasp clock data that's needed for rc1. I just posted a patch for that as I need both this patch and the clock data fix to boot from current mainline. -Matt -- 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: OMAP2+: AM33XX: clock data: fix mcasp entries
On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> exposes a bug in the AM33XX clock data for mcasp. After moving to
> clk_get() usage, the _init() of all registered hwmods fails on mcasp0
> due to incorrect clock data causing clk_get() to fail. This causes all
> successive hwmods to fail to _init() leaving them in a bad state.
>
> This patch updates the mcasp clock entries so clk_get() will succeed.
> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
> boot.
>
Matt,
I have already submitted patch for this and it is accepted and merged in
Tony's pull request.
https://patchwork.kernel.org/patch/1499271/
Thanks,
Vaibhav
> Signed-off-by: Matt Porter
> ---
> arch/arm/mach-omap2/clock33xx_data.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock33xx_data.c
> b/arch/arm/mach-omap2/clock33xx_data.c
> index b87b88c..0a64139 100644
> --- a/arch/arm/mach-omap2/clock33xx_data.c
> +++ b/arch/arm/mach-omap2/clock33xx_data.c
> @@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = {
> CLK("481d.d_can", NULL, &dcan1_fck, CK_AM33XX),
> CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX),
> CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk,
> CK_AM33XX),
> - CLK("davinci-mcasp.0", NULL, &mcasp0_fck,CK_AM33XX),
> - CLK("davinci-mcasp.1", NULL, &mcasp1_fck,CK_AM33XX),
> + CLK(NULL, "mcasp0_fck", &mcasp0_fck,CK_AM33XX),
> + CLK(NULL, "mcasp1_fck", &mcasp1_fck,CK_AM33XX),
> CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
> CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX),
> CLK(NULL, "smartreflex0_fck", &smartreflex0_fck,
> CK_AM33XX),
> --
> 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] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
exposes a bug in the AM33XX clock data for mcasp. After moving to
clk_get() usage, the _init() of all registered hwmods fails on mcasp0
due to incorrect clock data causing clk_get() to fail. This causes all
successive hwmods to fail to _init() leaving them in a bad state.
This patch updates the mcasp clock entries so clk_get() will succeed.
It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
boot.
Signed-off-by: Matt Porter
---
arch/arm/mach-omap2/clock33xx_data.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b87b88c..0a64139 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1033,8 +1033,8 @@ static struct omap_clk am33xx_clks[] = {
CLK("481d.d_can", NULL, &dcan1_fck, CK_AM33XX),
CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX),
CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk,
CK_AM33XX),
- CLK("davinci-mcasp.0", NULL, &mcasp0_fck,CK_AM33XX),
- CLK("davinci-mcasp.1", NULL, &mcasp1_fck,CK_AM33XX),
+ CLK(NULL, "mcasp0_fck", &mcasp0_fck,CK_AM33XX),
+ CLK(NULL, "mcasp1_fck", &mcasp1_fck,CK_AM33XX),
CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX),
CLK(NULL, "smartreflex0_fck", &smartreflex0_fck,
CK_AM33XX),
--
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: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote: > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote: > > With recent changes in omap gpmc driver code, in case of DT > > boot mode, where bootloader does not configure gpmc cs space > > will result into kernel BUG() inside gpmc_mem_init() function, > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and > > gpmc_config7[0].baseaddress is set to '0' on reset. > > > > This use-case is applicable for any board/EVM which doesn't have > > any peripheral connected to gpmc cs0, for example BeagleXM and > > BeagleBone, so DT boot mode fails. > > > > This patch adds of_have_populated_dt() check before creating > > device, so that for DT boot mode, gpmc probe will not be called > > which is expected behavior, as gpmc is not supported yet from DT. > > > > Signed-off-by: Vaibhav Hiremath > > Cc: Afzal Mohammed > > Cc: Tony Lindgren > > Cc Paul Walmsley > > --- > > This should go in for rc1, as this breaks AM33xx boot. > > Fixes BeagleBone on mainline. > > Tested-by: Matt Porter > Thanks Matt and Afzal, Tony can this be picked up for rc1?? I know you have already sent pull request for rc1, but by any chance you are planning to send another request? Thanks, Vaibhav > -Matt > -- 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/3] exynos5: usb: dwc3: Add the suspend/resume functionality
From: Vikas Sajjan
Adding the suspend and resume functionality to exynos dwc3 driver
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vikas C Sajjan
CC: Doug Anderson
---
drivers/usb/dwc3/dwc3-exynos.c | 60
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..1154cee 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -200,11 +201,70 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos_data *pdata = dev->platform_data;
+ struct dwc3_exynos *exynos;
+ struct platform_device *pdev = to_platform_device(dev);
+
+ exynos = dev_get_drvdata(dev);
+
+ if (!exynos)
+ return -EINVAL;
+
+ if (pdata && pdata->phy_exit)
+ pdata->phy_exit(pdev, pdata->phy_type);
+
+ clk_disable(exynos->clk);
+
+ return 0;
+}
+
+static int dwc3_exynos_resume(struct device *dev)
+{
+ struct dwc3_exynos_data *pdata = dev->platform_data;
+ struct dwc3_exynos *exynos;
+ struct platform_device *pdev = to_platform_device(dev);
+
+ exynos = dev_get_drvdata(dev);
+
+ if (!exynos)
+ return -EINVAL;
+
+ clk_enable(exynos->clk);
+
+ /* PHY initialization */
+ if (!pdata) {
+ dev_dbg(&pdev->dev, "missing platform data\n");
+ } else {
+ if (pdata->phy_init)
+ pdata->phy_init(pdev, pdata->phy_type);
+ }
+
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops dwc3_exynos_pm_ops = {
+ .suspend= dwc3_exynos_suspend,
+ .resume = dwc3_exynos_resume,
+};
+#endif /* CONFIG_PM */
+
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name = "exynos-dwc3",
+#ifdef CONFIG_PM
+ .pm = &dwc3_exynos_pm_ops,
+#endif
+
},
};
--
1.7.6.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 2/3] usb: xhci: Add the suspend/resume functionality
From: Vikas Sajjan
Adding the suspend and resume functionality for the XHCI driver
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vikas C Sajjan
CC: Doug Anderson
---
drivers/usb/host/xhci-plat.c | 44 ++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..384cf4d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -185,11 +185,55 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_PM
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd;
+ struct xhci_hcd *xhci;
+
+ hcd = dev_get_drvdata(dev);
+ if (!hcd)
+ return -EINVAL;
+
+ xhci = hcd_to_xhci(hcd);
+
+ /* Make sure that the HCD Core as set state HC_STATE_SUSPENDED */
+ if (hcd->state != HC_STATE_SUSPENDED ||
+ xhci->shared_hcd->state != HC_STATE_SUSPENDED)
+ return -EINVAL;
+
+ return xhci_suspend(xhci);
+}
+
+static int xhci_plat_resume(struct device *dev)
+{
+ struct usb_hcd *hcd;
+ struct xhci_hcd *xhci;
+
+ hcd = dev_get_drvdata(dev);
+
+ if (!hcd)
+ return -EINVAL;
+
+ xhci = hcd_to_xhci(hcd);
+
+ return xhci_resume(xhci, 0);
+}
+
+static const struct dev_pm_ops xhci_plat_pm_ops = {
+ .suspend= xhci_plat_suspend,
+ .resume = xhci_plat_resume,
+};
+#endif
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
+#ifdef CONFIG_PM
+ .pm = &xhci_plat_pm_ops,
+#endif
},
};
MODULE_ALIAS("platform:xhci-hcd");
--
1.7.6.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 1/3] usb: dwc3: Add the suspend/resume functionality
From: Vikas Sajjan
Adding the suspend and resume funtionality to DWC3 core.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Vikas C Sajjan
CC: Doug Anderson
---
drivers/usb/dwc3/core.c | 268 +-
1 files changed, 169 insertions(+), 99 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b415c0c..58b51e1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, "Maximum supported speed.");
static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
-int dwc3_get_device_id(void)
-{
- int id;
-
-again:
- id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
- if (id < DWC3_DEVS_POSSIBLE) {
- int old;
-
- old = test_and_set_bit(id, dwc3_devs);
- if (old)
- goto again;
- } else {
- pr_err("dwc3: no space for new device\n");
- id = -ENOMEM;
- }
-
- return id;
-}
-EXPORT_SYMBOL_GPL(dwc3_get_device_id);
-
-void dwc3_put_device_id(int id)
-{
- int ret;
-
- if (id < 0)
- return;
-
- ret = test_bit(id, dwc3_devs);
- WARN(!ret, "dwc3: ID %d not in use\n", id);
- smp_mb__before_clear_bit();
- clear_bit(id, dwc3_devs);
-}
-EXPORT_SYMBOL_GPL(dwc3_put_device_id);
-
-void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
+static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
{
- u32 reg;
+ struct dwc3_hwparams*parms = &dwc->hwparams;
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
- reg |= DWC3_GCTL_PRTCAPDIR(mode);
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ parms->hwparams0 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS0);
+ parms->hwparams1 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS1);
+ parms->hwparams2 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS2);
+ parms->hwparams3 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS3);
+ parms->hwparams4 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS4);
+ parms->hwparams5 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS5);
+ parms->hwparams6 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS6);
+ parms->hwparams7 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS7);
+ parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
}
-
/**
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
@@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
+static int dwc3_core_reset(struct dwc3 *dwc)
+{
+ unsigned long timeout;
+ u32 reg;
+
+ /* issue device SoftReset too */
+ timeout = jiffies + msecs_to_jiffies(500);
+ dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ break;
+
+ if (time_after(jiffies, timeout)) {
+ dev_err(dwc->dev, "Reset Timed Out\n");
+ return -ETIMEDOUT;
+ }
+
+ cpu_relax();
+ } while (true);
+
+ dwc3_core_soft_reset(dwc);
+
+ dwc3_cache_hwparams(dwc);
+
+ reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+ reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
+ reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+ switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) {
+ case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
+ reg &= ~DWC3_GCTL_DSBLCLKGTNG;
+ break;
+ default:
+ dev_dbg(dwc->dev, "No power optimization available\n");
+ }
+
+ /*
+* WORKAROUND: DWC3 revisions <1.90a have a bug
+* where the device can fail to connect at SuperSpeed
+* and falls back to high-speed mode which causes
+* the device to enter a Connect/Disconnect loop
+*/
+ if (dwc->revision < DWC3_REVISION_190A)
+ reg |= DWC3_GCTL_U2RSTECN;
+
+ dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+
+ return 0;
+}
+
+int dwc3_get_device_id(void)
+{
+ int id;
+
+again:
+ id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
+ if (id < DWC3_DEVS_POSSIBLE) {
+ int old;
+
+ old = test_and_set_bit(id, dwc3_devs);
+ if (old)
+ goto again;
+ } else {
+ pr_err("dwc3: no space for new device\n");
+ id = -ENOMEM;
+ }
+
+ return id;
+}
+EXPORT_SYMBOL_GPL(dwc3_get_device_id);
+
+void dwc3_put_device_id(int id)
+{
+ int ret;
+
+ if (id < 0)
+ return;
+
+ ret = test_bit(id, dwc3_devs);
+ WARN(!ret, "dwc3: ID %d not in use\n", id);
+ smp_mb__before_clear_bit();
+ clear_bit(id, dwc3_devs);
+}
+EXPORT_
[PATCH 0/3] USB: dwc3: Add suspend/resume support
From: Vikas Sajjan This patchset adds suspend/resume functionality to dwc3-core layer and xhci-platform driver. It also adds S2R support to dwc3-exynos glue layer. Based on 'usb-next' branch. Vikas Sajjan (3): usb: dwc3: Add the suspend/resume functionality usb: xhci: Add the suspend/resume functionality exynos5: usb: dwc3: Add the suspend/resume functionality drivers/usb/dwc3/core.c| 268 +--- drivers/usb/dwc3/dwc3-exynos.c | 60 + drivers/usb/host/xhci-plat.c | 44 +++ 3 files changed, 273 insertions(+), 99 deletions(-) -- 1.7.6.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: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote: > With recent changes in omap gpmc driver code, in case of DT > boot mode, where bootloader does not configure gpmc cs space > will result into kernel BUG() inside gpmc_mem_init() function, > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and > gpmc_config7[0].baseaddress is set to '0' on reset. > > This use-case is applicable for any board/EVM which doesn't have > any peripheral connected to gpmc cs0, for example BeagleXM and > BeagleBone, so DT boot mode fails. > > This patch adds of_have_populated_dt() check before creating > device, so that for DT boot mode, gpmc probe will not be called > which is expected behavior, as gpmc is not supported yet from DT. > > Signed-off-by: Vaibhav Hiremath > Cc: Afzal Mohammed > Cc: Tony Lindgren > Cc Paul Walmsley > --- > This should go in for rc1, as this breaks AM33xx boot. Fixes BeagleBone on mainline. Tested-by: Matt Porter -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] OMAP DSS for v3.7
Hi Tomi, On 10/01/2012 07:45 PM, Tomi Valkeinen wrote: > Hi Florian, > > Here are omapdss changes for 3.7 merge window. Merged. > There's something funny with the diff stat, though. I can see a few > changes there that I have not made, for example to > drivers/video/console/fbcon.c. I believe they come from my "Merge branch > 'fbdev-for-linus' of git://github.com/schandinat/linux-2.6", although I > don't know why they show up in the diff stat. Yeah, I know this sort of stuff, had some similar problem some time ago, it happens when you base on multiple branches. Basically you created your pull request as if you asked Linus to pull it as you started with a commit that is in Linus' tree (but not in mine). If you would take the HEAD of my tree you wouldn't see the fb stuff but others as you merged from Linus in the meantime. > Merge with v3.6 goes without conflicts, but there will be some conflicts > with OMAP platform stuff, at least according to linux-next reports. > Those conflicts are trivial, though. Good. Thanks, Florian Tobias Schandinat > > Tomi > > The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: > > Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) > > are available in the git repository at: > > git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7 > > for you to fetch changes up to 13b1ba7de8d0ecc42e4f9c002d5b0c1a48f05e58: > > OMAPDSS: add missing include for string.h (2012-09-28 10:03:03 +0300) > > > Omapdss driver changes for the 3.7 merge window. > > Notable changes: > > * Basic writeback support for DISPC level. Writeback is not yet usable, > though, > as we need higher level code to actually expose the writeback feature to > userspace. > * Rewriting the omapdss output drivers. We're trying to remove the hard links > between the omapdss and the panels, and this rewrite work moves us closer to > that goal. > * Cleanup and restructuring patches that have been made while working on > device > tree support for omapdss. Device tree support is still some way ahead, but > these patches are good cleanups in themselves. > * Basic OMAP5 DSS support for DPI and DSI outputs. > * Workaround for the problem that GFX overlay's fifo is too small for high > resolution scenarios, causing underflows. > * Cleanups that remove dependencies to omap platform code. > > > Archit Taneja (70): > OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings > OMAPDSS: DPI: Add locking for DPI interface > OMAPDSS: Displays: Add locking in generic DPI panel driver > OMAPDSS: DPI: Maintain our own timings field in driver data > OMAPDSS: DPI displays: Take care of panel timings in the driver itself > OMAPDSS: DSI: Maintain own copy of timings in driver data > OMAPDSS: DSI: Add function to set panel size for command mode panels > OMAPDSS: DSI: Update manager timings on a manual update > OMAPDSS: HDMI: Use our own omap_video_timings field when setting > interface timings > OMAPDSS: HDMI: Add locking for hdmi interface set timing functions > OMAPDSS: SDI: Create a function to set timings > OMAPDSS: SDI: Maintain our own timings field in driver data > OMAPDSS: VENC: Split VENC into interface and panel driver > OMAPDSS: VENC: Maintain our own timings field in driver data > OMAPDSS: RFBI: Remove partial update support > OMAPDSS: RFBI: Add function to set panel size > OMAPDSS: DSI: Maintain copy of pixel format in driver data > OMAPDSS: RFBI: Maintain copy of pixel size in driver data > OMAPDSS: RFBI: Maintain copy of number of data lines in driver data > OMAPDSS: DPI: Maintain copy of number of data lines in driver data > OMAPDSS: SDI: Maintain copy of data pairs in driver data > OMAPDSS: DSI: Maintain copy of operation mode in driver data > OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings > OMAPDSS: DSI: Maintain copy of video mode timings in driver data > OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data > OMAPDSS: VENC: Maintain copy of venc type in driver data > OMAPDSS: VENC: Maintian copy of video output polarity info in private > data > OMAPFB: Clear framebuffers before they are registered > OMAPDSS: Add basic omap5 features to dss and dispc > OMAPDSS: DSI: Pass dsi platform device wherever possible > OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go > functions > OMAPDSS: outputs: Create a new entity called outputs > OMAPDSS: outputs: Create and register output instances > OMAPDSS: output: Add set/unset device ops for omap_dss_output > OMAPDSS: APPLY: Add manager set/unset output ops for > omap_overlay_manager > OMAPDSS: Remove manager->device references >
[PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the i2c bus irq gets enabled before the threaded
i2c device irq, causing a flood of i2c bus interrupts as the
threaded irq that should clear the event is not enabled yet.
Fixed the issue by adding suspend_noirq and resume_early
functions that keep i2c bus interrupts disabled until
resume_noirq has run completely.
Issue was detected doing a wake up from autosleep with
twl4030 power key on N9. Patch tested on N9.
Signed-off-by: Kalle Jokiniemi
---
drivers/i2c/busses/i2c-omap.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a0e49f6..991341b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
+static int omap_i2c_suspend_noirq(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /* Disabling irq here to balance the enable in resume_early */
+ disable_irq(_dev->irq);
+ return 0;
+}
+
+static int omap_i2c_resume_early(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /*
+* The noirq_resume enables the interrupts one by one,
+* this causes a interrupt flood if the SW irq actually reading
+* event from i2c device is enabled only after i2c bus irq, as the
+* irq that should clear the event is still disabled. We have to
+* keep the bus irq disabled until all other irqs have been enabled.
+*/
+ enable_irq(_dev->irq);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_PM_RUNTIME
static int omap_i2c_runtime_suspend(struct device *dev)
{
@@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device *dev)
#endif /* CONFIG_PM_RUNTIME */
static struct dev_pm_ops omap_i2c_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+ .suspend_noirq = omap_i2c_suspend_noirq,
+ .resume_early = omap_i2c_resume_early,
+#endif
SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
omap_i2c_runtime_resume, NULL)
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: i2c: fix interrupt flood during resume
ke, 2012-10-10 kello 14:54 +0300, Kalle Jokiniemi kirjoitti:
> ke, 2012-10-10 kello 14:46 +0300, Kalle Jokiniemi kirjoitti:
> > The resume_noirq enables interrupts one-by-one starting from
> > first one. Now if the wake up event for suspend came from i2c
> > device, the i2c bus irq gets enabled before the threaded
> > i2c device irq, causing a flood of i2c bus interrupts as the
> > threaded irq that should clear the event is not enabled yet.
> >
> > Fixed the issue by adding suspend_late and resume_early
> > functions that keep i2c bus interrupts disabled until
> > resume_noirq has run completely.
Ugh, forgot to update commit message. Version 3 coming shortly...
- Kalle
> >
> > Issue was detected doing a wake up from autosleep with
> > twl4030 power key on N9. Patch tested on N9.
>
> I did this now on top of latest linux-omap, should apply also to Jean's
> staging tree. Let me know if something more is needed.
>
> - Kalle
>
> >
> > Signed-off-by: Kalle Jokiniemi
> > ---
> > drivers/i2c/busses/i2c-omap.c | 34 ++
> > 1 files changed, 34 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index a0e49f6..991341b 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct
> > platform_device *pdev)
> > }
> >
> > #ifdef CONFIG_PM
> > +#ifdef CONFIG_PM_SLEEP
> > +static int omap_i2c_suspend_noirq(struct device *dev)
> > +{
> > +
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> > +
> > + /* Disabling irq here to balance the enable in resume_early */
> > + disable_irq(_dev->irq);
> > + return 0;
> > +}
> > +
> > +static int omap_i2c_resume_early(struct device *dev)
> > +{
> > +
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> > +
> > + /*
> > +* The noirq_resume enables the interrupts one by one,
> > +* this causes a interrupt flood if the SW irq actually reading
> > +* event from i2c device is enabled only after i2c bus irq, as the
> > +* irq that should clear the event is still disabled. We have to
> > +* keep the bus irq disabled until all other irqs have been enabled.
> > +*/
> > + enable_irq(_dev->irq);
> > +
> > + return 0;
> > +}
> > +#endif
> > #ifdef CONFIG_PM_RUNTIME
> > static int omap_i2c_runtime_suspend(struct device *dev)
> > {
> > @@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device
> > *dev)
> > #endif /* CONFIG_PM_RUNTIME */
> >
> > static struct dev_pm_ops omap_i2c_pm_ops = {
> > +#ifdef CONFIG_PM_SLEEP
> > + .suspend_noirq = omap_i2c_suspend_noirq,
> > + .resume_early = omap_i2c_resume_early,
> > +#endif
> > SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
> >omap_i2c_runtime_resume, NULL)
> > };
>
>
> --
> 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
--
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/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64 +++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
- elpida_ECB240ABACN: lpddr2 {
+ elpida_ECB240ABACN: lpddr2@0 {
compatible = "Elpida,ECB240ABACN","jedec,lpddr2-s4";
density = <2048>;
io-width= <32>;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = <6000>;
};
};
+
+ samsung_K3PE0E000B: lpddr2@1 {
+ compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
+ density = <4096>;
+ io-width= <32>;
+
+ tRPab-min-tck = <3>;
+ tRCD-min-tck= <3>;
+ tWR-min-tck = <3>;
+ tRASmin-min-tck = <3>;
+ tRRD-min-tck= <2>;
+ tWTR-min-tck= <2>;
+ tXP-min-tck = <2>;
+ tRTP-min-tck= <2>;
+ tCKE-min-tck= <3>;
+ tCKESR-min-tck = <3>;
+ tFAW-min-tck= <8>;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq= <1000>;
+ max-freq= <5>;
+ tRPab = <21000>;
+ tRCD= <18000>;
+ tWR = <15000>;
+ tRAS-min= <42000>;
+ tRRD= <1>;
+ tWTR= <7500>;
+ tXP = <7500>;
+ tRTP= <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW= <5>;
+ tZQCS = <9>;
+ tZQCL = <36>;
+ tZQinit = <100>;
+ tRAS-max-ns = <7>;
+ tDQSCK-max-derated = <5620>;
+ };
+
+ timings_samsung_K3PE0E000B_266mhz: lpddr2-timings@1 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq= <1000>;
+ max-freq= <2>;
+ tRPab = <21000>;
+ tRCD= <18000>;
+ tWR = <15000>;
+ tRAS-min= <42000>;
+ tRRD= <1>;
+ tWTR= <7500>;
+ tXP = <7500>;
+ tRTP= <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW= <5>;
+ tZQCS = <9>;
+ tZQCL = <36>;
+ tZQinit = <100>;
+ tRAS-max-ns = <7>;
+ tDQSCK-max-derated = <6000>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..8a952f8 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ "omap5.dtsi"
+/include/ "lpddr2_data.dtsi"
/ {
model = "TI OMAP5 EVM board";
@@ -82,3 +83,13 @@
0x020700d9>;/* SEARCH */
linux,input-no-autorepeat;
};
+
+&emif1 {
+ cs1-used;
+ device-handle = <&samsung_K3PE0E000B>;
+};
+
+&emif2 {
+ cs1-used;
+ device-handle = <&samsung_K3PE0E000B>;
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5db33f4..40b41c2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -319,5 +319,23 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp3";
};
+
+ emif1: emif@0x4c00 {
+ compatible = "ti,emif-4d5";
+ ti,hwmods = "emif1";
+ phy-type= <2>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+
[PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
Renaming elpida_ecb240abacn.dtsi file generic, so that the
same file can be reused for other parts from different vendors.
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} |0
arch/arm/boot/dts/omap4-panda.dts |2 +-
arch/arm/boot/dts/omap4-sdp.dts |2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{elpida_ecb240abacn.dtsi => lpddr2_data.dtsi} (100%)
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
similarity index 100%
rename from arch/arm/boot/dts/elpida_ecb240abacn.dtsi
rename to arch/arm/boot/dts/lpddr2_data.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..09d3a32 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ "omap4.dtsi"
-/include/ "elpida_ecb240abacn.dtsi"
+/include/ "lpddr2_data.dtsi"
/ {
model = "TI OMAP4 PandaBoard";
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..dd749fc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ "omap4.dtsi"
-/include/ "elpida_ecb240abacn.dtsi"
+/include/ "lpddr2_data.dtsi"
/ {
model = "TI OMAP4 SDP board";
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: Correcting size of memory defined for omap5
Memory present for omap5 is 2GB. But in dt file
it is specified as 1GB. Correcting the same
in this patch
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/omap5-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 9c41a3f..6f87e1a 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -15,7 +15,7 @@
memory {
device_type = "memory";
- reg = <0x8000 0x4000>; /* 1 GB */
+ reg = <0x8000 0x8000>; /* 2 GB */
};
vmmcsd_fixed: fixedregulator-mmcsd {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
Patch 1: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi Patch 2: Correcting size of memory defined for omap5 Patch 3: EMIF and LPDDR2 device tree data for OMAP5 boards Testing: - Boot tested on omap5-sevm board - Built emif as a module Lokesh Vutla (3): ARM: dts: Renaming elpida_ecb240abacn.dts as lpddr2_data.dtsi ARM: dts: Correcting size of memory defined for omap5 ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 --- arch/arm/boot/dts/lpddr2_data.dtsi| 129 + arch/arm/boot/dts/omap4-panda.dts |2 +- arch/arm/boot/dts/omap4-sdp.dts |2 +- arch/arm/boot/dts/omap5-evm.dts | 13 ++- arch/arm/boot/dts/omap5.dtsi | 18 6 files changed, 161 insertions(+), 70 deletions(-) delete mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi create mode 100644 arch/arm/boot/dts/lpddr2_data.dtsi -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: i2c: fix interrupt flood during resume
ke, 2012-10-10 kello 14:46 +0300, Kalle Jokiniemi kirjoitti:
> The resume_noirq enables interrupts one-by-one starting from
> first one. Now if the wake up event for suspend came from i2c
> device, the i2c bus irq gets enabled before the threaded
> i2c device irq, causing a flood of i2c bus interrupts as the
> threaded irq that should clear the event is not enabled yet.
>
> Fixed the issue by adding suspend_late and resume_early
> functions that keep i2c bus interrupts disabled until
> resume_noirq has run completely.
>
> Issue was detected doing a wake up from autosleep with
> twl4030 power key on N9. Patch tested on N9.
I did this now on top of latest linux-omap, should apply also to Jean's
staging tree. Let me know if something more is needed.
- Kalle
>
> Signed-off-by: Kalle Jokiniemi
> ---
> drivers/i2c/busses/i2c-omap.c | 34 ++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a0e49f6..991341b 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct
> platform_device *pdev)
> }
>
> #ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
> +static int omap_i2c_suspend_noirq(struct device *dev)
> +{
> +
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> +
> + /* Disabling irq here to balance the enable in resume_early */
> + disable_irq(_dev->irq);
> + return 0;
> +}
> +
> +static int omap_i2c_resume_early(struct device *dev)
> +{
> +
> + struct platform_device *pdev = to_platform_device(dev);
> + struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> +
> + /*
> + * The noirq_resume enables the interrupts one by one,
> + * this causes a interrupt flood if the SW irq actually reading
> + * event from i2c device is enabled only after i2c bus irq, as the
> + * irq that should clear the event is still disabled. We have to
> + * keep the bus irq disabled until all other irqs have been enabled.
> + */
> + enable_irq(_dev->irq);
> +
> + return 0;
> +}
> +#endif
> #ifdef CONFIG_PM_RUNTIME
> static int omap_i2c_runtime_suspend(struct device *dev)
> {
> @@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device *dev)
> #endif /* CONFIG_PM_RUNTIME */
>
> static struct dev_pm_ops omap_i2c_pm_ops = {
> +#ifdef CONFIG_PM_SLEEP
> + .suspend_noirq = omap_i2c_suspend_noirq,
> + .resume_early = omap_i2c_resume_early,
> +#endif
> SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
> omap_i2c_runtime_resume, NULL)
> };
--
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] ARM: OMAP: i2c: fix interrupt flood during resume
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the i2c bus irq gets enabled before the threaded
i2c device irq, causing a flood of i2c bus interrupts as the
threaded irq that should clear the event is not enabled yet.
Fixed the issue by adding suspend_late and resume_early
functions that keep i2c bus interrupts disabled until
resume_noirq has run completely.
Issue was detected doing a wake up from autosleep with
twl4030 power key on N9. Patch tested on N9.
Signed-off-by: Kalle Jokiniemi
---
drivers/i2c/busses/i2c-omap.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a0e49f6..991341b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
+static int omap_i2c_suspend_noirq(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /* Disabling irq here to balance the enable in resume_early */
+ disable_irq(_dev->irq);
+ return 0;
+}
+
+static int omap_i2c_resume_early(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /*
+* The noirq_resume enables the interrupts one by one,
+* this causes a interrupt flood if the SW irq actually reading
+* event from i2c device is enabled only after i2c bus irq, as the
+* irq that should clear the event is still disabled. We have to
+* keep the bus irq disabled until all other irqs have been enabled.
+*/
+ enable_irq(_dev->irq);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_PM_RUNTIME
static int omap_i2c_runtime_suspend(struct device *dev)
{
@@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device *dev)
#endif /* CONFIG_PM_RUNTIME */
static struct dev_pm_ops omap_i2c_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+ .suspend_noirq = omap_i2c_suspend_noirq,
+ .resume_early = omap_i2c_resume_early,
+#endif
SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
omap_i2c_runtime_resume, NULL)
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Beagleboard xM crashes when being set to 800MHz with smartreflex on linux-omap-3.6-rc6
2012/10/2 Kevin Hilman : > "Maximilian Schwerin" writes: > >> Hi, >> >> I've just built a linux-omap kernel at 3.6-rc6 using omap2plus_defconfig >> as basis for the kernel config. >> >> When I enable smartreflex and switch to 800MHz via >> >> echo 1 > /sys/kernel/debug/smartreflex/smartreflex_core/autocomp >> echo 1 > /sys/kernel/debug/smartreflex/smartreflex_mpu_iva/autocomp >> cpufreq-set -f 800MHz >> >> the board crashes. If I switch to 800MHz and enable smartreflex later >> nothing happens. This used to work in my 3.3 based kernel. > > SmartReflex is kwown to be unstable in mainline and there are several > errata that still need fixing for it to be stable. > > I strongly recommend you simply leave SR disabled. > Does it apply to a device always at opp1G ? Ie if I boot @1GHz and then enable smart reflex, is it ok ? > Kevin > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 0/5] OMAPDSS: Enable dynamic debug printing
Tomi, Chandrabhanu, On Friday 05 October 2012 06:16 PM, Tomi Valkeinen wrote: On Sat, 2012-09-29 at 16:19 +0530, Chandrabhanu Mahapatra wrote: Hi everyone, this patch series aims at cleaning up of DSS of printk()'s enabled with dss_debug and replace them with generic dynamic debug printing. Except for the missing debug print conversions in dsi.c this looks good. Do you want me to apply the current series and you can send the dsi.c patch later, or do you want to fix the dsi.c also before I apply? With the change for DSI, please feel free to add Reviewed-by: Sumit Semwal BR, ~Sumit. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 4/5] OMAPDSS: Replace multi part debug prints with pr_debug
The various functions in dispc and dsi such as print_irq_status(),
print_irq_status_vc(), print_irq_status_cio() and _dsi_print_reset_status()
consist of a number of debug prints which need to be enabled all at once or none
at all. So, these debug prints in corresponding functions are replaced with one
dynamic debug enabled pr_debug() each.
Signed-off-by: Chandrabhanu Mahapatra
---
Changes from V4 to V5:
* replaced prints in dsi functions print_irq_status, print_irq_status_vc() and
print_irq_status_cio() with single pr_debug()
* replaced macro VERBOSE_IRQ with static variable verbose_irq
drivers/video/omap2/dss/dispc.c | 32 +++-
drivers/video/omap2/dss/dsi.c | 168 ++-
2 files changed, 90 insertions(+), 110 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a173a94..67d9f3b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3675,26 +3675,20 @@ static void print_irq_status(u32 status)
if ((status & dispc.irq_error_mask) == 0)
return;
- printk(KERN_DEBUG "DISPC IRQ: 0x%x: ", status);
-
-#define PIS(x) \
- if (status & DISPC_IRQ_##x) \
- printk(#x " ");
- PIS(GFX_FIFO_UNDERFLOW);
- PIS(OCP_ERR);
- PIS(VID1_FIFO_UNDERFLOW);
- PIS(VID2_FIFO_UNDERFLOW);
- if (dss_feat_get_num_ovls() > 3)
- PIS(VID3_FIFO_UNDERFLOW);
- PIS(SYNC_LOST);
- PIS(SYNC_LOST_DIGIT);
- if (dss_has_feature(FEAT_MGR_LCD2))
- PIS(SYNC_LOST2);
- if (dss_has_feature(FEAT_MGR_LCD3))
- PIS(SYNC_LOST3);
+#define PIS(x) (status & DISPC_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DISPC IRQ: 0x%x: %s%s%s%s%s%s%s%s%s\n",
+ status,
+ PIS(OCP_ERR),
+ PIS(GFX_FIFO_UNDERFLOW),
+ PIS(VID1_FIFO_UNDERFLOW),
+ PIS(VID2_FIFO_UNDERFLOW),
+ dss_feat_get_num_ovls() > 3 ? PIS(VID3_FIFO_UNDERFLOW) : "",
+ PIS(SYNC_LOST),
+ PIS(SYNC_LOST_DIGIT),
+ dss_has_feature(FEAT_MGR_LCD2) ? PIS(SYNC_LOST2) : "",
+ dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : "");
#undef PIS
-
- printk("\n");
}
#endif
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b0345f3..19daee9 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -45,7 +45,6 @@
#include "dss.h"
#include "dss_features.h"
-/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
struct dsi_reg { u16 idx; };
@@ -526,42 +525,38 @@ static inline void dsi_perf_show(struct platform_device
*dsidev,
}
#endif
+static int verbose_irq;
+
static void print_irq_status(u32 status)
{
if (status == 0)
return;
-#ifndef VERBOSE_IRQ
- if ((status & ~DSI_IRQ_CHANNEL_MASK) == 0)
+ if (!verbose_irq && (status & ~DSI_IRQ_CHANNEL_MASK) == 0)
return;
-#endif
- printk(KERN_DEBUG "DSI IRQ: 0x%x: ", status);
-#define PIS(x) \
- if (status & DSI_IRQ_##x) \
- printk(#x " ");
-#ifdef VERBOSE_IRQ
- PIS(VC0);
- PIS(VC1);
- PIS(VC2);
- PIS(VC3);
-#endif
- PIS(WAKEUP);
- PIS(RESYNC);
- PIS(PLL_LOCK);
- PIS(PLL_UNLOCK);
- PIS(PLL_RECALL);
- PIS(COMPLEXIO_ERR);
- PIS(HS_TX_TIMEOUT);
- PIS(LP_RX_TIMEOUT);
- PIS(TE_TRIGGER);
- PIS(ACK_TRIGGER);
- PIS(SYNC_LOST);
- PIS(LDO_POWER_GOOD);
- PIS(TA_TIMEOUT);
+#define PIS(x) (status & DSI_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI IRQ: 0x%x: %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ status,
+ verbose_irq ? PIS(VC0) : "",
+ verbose_irq ? PIS(VC1) : "",
+ verbose_irq ? PIS(VC2) : "",
+ verbose_irq ? PIS(VC3) : "",
+ PIS(WAKEUP),
+ PIS(RESYNC),
+ PIS(PLL_LOCK),
+ PIS(PLL_UNLOCK),
+ PIS(PLL_RECALL),
+ PIS(COMPLEXIO_ERR),
+ PIS(HS_TX_TIMEOUT),
+ PIS(LP_RX_TIMEOUT),
+ PIS(TE_TRIGGER),
+ PIS(ACK_TRIGGER),
+ PIS(SYNC_LOST),
+ PIS(LDO_POWER_GOOD),
+ PIS(TA_TIMEOUT));
#undef PIS
-
- printk("\n");
}
static void print_irq_status_vc(int channel, u32 status)
@@ -569,28 +564,24 @@ static void print_irq_status_vc(int channel, u32 status)
if (status == 0)
return;
-#ifndef VERBOSE_IRQ
- if ((status & ~DSI_VC_IRQ_PACKET_SENT) == 0)
+ if (!verbose_irq && (status & ~DSI_VC_IRQ_PACKET_SENT) == 0)
return;
-#endif
- printk(KERN_DEBUG "DSI VC(%d) IRQ 0x%x: ", channel, status);
-#define PIS(x) \
- if (status & DSI_VC_IRQ_##x) \
- printk(#x " ");
- PIS(CS);
- PIS(ECC_CORR);
-#ifdef VERBOSE_IRQ
-
Re: [PATCH] ARM: OMAP: resolve sparse warning concerning debug_card_init()
On 10/09/12 22:29, Paul Walmsley wrote:
>
> Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
> debug_card_init() function") results in the following new sparse
> warning:
>
> arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init'
> was not declared. Should it be static?
>
> Fix by implementing Tony's suggestion to add a "sideways include" to the
> new location of the debug-devices.h file in arch/arm/mach-omap2/.
>
> Signed-off-by: Paul Walmsley
> Cc: Igor Grinberg
> Cc: Tony Lindgren
Acked-by: Igor Grinberg
> ---
> arch/arm/plat-omap/debug-devices.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/plat-omap/debug-devices.c
> b/arch/arm/plat-omap/debug-devices.c
> index c7a4c09..5a4678e 100644
> --- a/arch/arm/plat-omap/debug-devices.c
> +++ b/arch/arm/plat-omap/debug-devices.c
> @@ -16,6 +16,7 @@
> #include
>
> #include
> +#include "../mach-omap2/debug-devices.h"
>
> /* Many OMAP development platforms reuse the same "debug board"; these
> * platforms include H2, H3, H4, and Perseus2.
--
Regards,
Igor.
--
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
