Re: [PATCH 12/18] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
On 03/26/2014 12:36 AM, Tony Lindgren wrote: * Tero Kristo [140304 08:23]: There is a solitary write to this register every wakeup from off-mode, which isn't doing anything, so remove it. Argh, this chunk of code is for sure the the thing that's blocking all the voltage scaling for idle modes that twl4030 is supposed to do! AFAIK we must have AUTO_SLEEP, AUTO_RET and AUTO_OFF bits set in PRM_VOLTCTRL for twl4030 to scale anything. They must be set if we're scaling over I2C4 or using the pins as triggers. Unless these bits are set, VC won't send any SLEEP, RET or OFF commands. Looks like we're not even set these bits anywhere like we should? I think we should enabled these bits in vc.c init, and never clear? The bits should be set according to the target sleep mode I believe, e.g. for retention we should set only AUTO_RET, and for off-mode AUTO_OFF. You can't have AUTO_OFF enabled if you are going to retention only as far as I recall, this potentially caused some problems. -Tero Nishant and Kevin, any comments? Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/pm34xx.c |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 0eecf6f..2fa9478 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -282,10 +282,6 @@ void omap_sram_idle(void) omap3_sram_restore_context(); omap2_sms_restore_context(); } - if (core_next_state == PWRDM_POWER_OFF) - omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK, - OMAP3430_GR_MOD, - OMAP3_PRM_VOLTCTRL_OFFSET); } omap3_intc_resume_idle(); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: dwc3: core: Fix gadget for system suspend/resume
During system resume, if the event buffers are not setup before
the gadget controller starts then we start with invalid context
and this can lead to bus access errors. This is especially true for
platforms that loose the controller context during system suspend.
e.g. AM437x.
The following backtrace was found when the system is suspended
and resumed with g_zero loaded on AM437x-evm (USB cable connected
to host all the while).
[ 120.981506] WARNING: CPU: 0 PID: 1656 at drivers/bus/omap_l3_noc.c:137
l3_interrupt_handler+0x198/0x28c()
[ 120.981514] L3 custom error: MASTER:USB0 WR TARGET:GPMC
[ 120.981638] Modules linked in: g_mass_storage usb_f_mass_storage
libcomposite configfs bufferclass_ti(O) omaplfb(O) cryptodev(O) dwc3
snd_soc_evm snd_soc_omap snd_pe
[ 120.981659] CPU: 0 PID: 1656 Comm: sh Tainted: G O
3.12.10-gc559824 #1
[ 120.981669] Backtrace:
[ 120.981705] [] (dump_backtrace+0x0/0x10c) from []
(show_stack+0x18/0x1c)
[ 120.981730] r6:c02819ac r5:0009 r4:ec137cb8 r3:
[ 120.981767] [] (show_stack+0x0/0x1c) from []
(dump_stack+0x20/0x28)
[ 120.981802] [] (dump_stack+0x0/0x28) from []
(warn_slowpath_common+0x70/0x90)
[ 120.981830] [] (warn_slowpath_common+0x0/0x90) from []
(warn_slowpath_fmt+0x38/0x40)
[ 120.981856] r8:c0855eb0 r7:0002 r6:f1000700 r5:0007 r4:80080003
[ 120.981886] [] (warn_slowpath_fmt+0x0/0x40) from []
(l3_interrupt_handler+0x198/0x28c)
[ 120.981900] r3:c0801ab8 r2:c06cb354
[ 120.981936] [] (l3_interrupt_handler+0x0/0x28c) from []
(handle_irq_event_percpu+0x54/0x1b8)
[ 120.981962] [] (handle_irq_event_percpu+0x0/0x1b8) from
[] (handle_irq_event+0x30/0x40)
[ 120.981993] [] (handle_irq_event+0x0/0x40) from []
(handle_fasteoi_irq+0x74/0x128)
[ 120.982006] r4:ed0056c0 r3:
[ 120.982033] [] (handle_fasteoi_irq+0x0/0x128) from []
(generic_handle_irq+0x28/0x38)
[ 120.982046] r4:002a r3:c0073fe4
[ 120.982085] [] (generic_handle_irq+0x0/0x38) from []
(handle_IRQ+0x38/0x8c)
[ 120.982098] r4:c080137c r3:0182
[ 120.982124] [] (handle_IRQ+0x0/0x8c) from []
(gic_handle_irq+0x30/0x5c)
[ 120.982145] r6:ec137dd0 r5:c07ac480 r4:fa24010c r3:0100
[ 120.982169] [] (gic_handle_irq+0x0/0x5c) from []
(__irq_svc+0x40/0x54)
[ 120.982179] Exception stack(0xec137dd0 to 0xec137e18)
[ 120.982195] 7dc0: a1d3
0004
[ 120.982216] 7de0: a153 ec1d9010 c080de90 ec137e30 c080debc
ed756e44 ec137e2c
[ 120.982232] 7e00: ec137de0 ec137e18 bf1150e4 bf115474 6153
[ 120.982253] r7:ec137e04 r6: r5:6153 r4:bf115474
[ 120.982327] [] (dwc3_complete+0x0/0x40 [dwc3]) from []
(dpm_complete+0xd4/0x19c)
[ 120.982341] r5:ed756e10 r4:ed756e64
[ 120.982370] [] (dpm_complete+0x0/0x19c) from []
(dpm_resume_end+0x1c/0x20)
[ 120.982400] [] (dpm_resume_end+0x0/0x20) from []
(suspend_devices_and_enter+0x118/0x33c)
[ 120.982412] r4:c0833da4 r3:
[ 120.982436] [] (suspend_devices_and_enter+0x0/0x33c) from
[] (pm_suspend+0x218/0x254)
[ 120.982458] [] (pm_suspend+0x0/0x254) from []
(state_store+0x70/0xc0)
[ 120.982478] r6:c057a6cc r5:c06a8320 r4:0003 r3:006d
[ 120.982515] [] (state_store+0x0/0xc0) from []
(kobj_attr_store+0x1c/0x28)
[ 120.982546] [] (kobj_attr_store+0x0/0x28) from []
(sysfs_write_file+0x170/0x1a4)
[ 120.982583] [] (sysfs_write_file+0x0/0x1a4) from []
(vfs_write+0xb8/0x190)
[ 120.982611] [] (vfs_write+0x0/0x190) from []
(SyS_write+0x44/0x78)
[ 120.982641] [] (SyS_write+0x0/0x78) from []
(ret_fast_syscall+0x0/0x30)
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d001417..10e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -821,6 +821,7 @@ static void dwc3_complete(struct device *dev)
spin_lock_irqsave(&dwc->lock, flags);
+ dwc3_event_buffers_setup(dwc);
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
case USB_DR_MODE_OTG:
@@ -828,7 +829,6 @@ static void dwc3_complete(struct device *dev)
/* FALLTHROUGH */
case USB_DR_MODE_HOST:
default:
- dwc3_event_buffers_setup(dwc);
break;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: OMAP: raw read and write endian fix
On 01/08/2014 02:39 AM, Tony Lindgren wrote: > * Taras Kondratiuk [131223 10:20]: >> On 23 December 2013 20:10, Taras Kondratiuk >> wrote: >>> This series does trivial replacement of __raw_xxx functions with xxx_relaxed >>> endian-neutral variants in 'mach-omap2' and 'plat-omap' directories. >>> Some code here most probably won't be used in BE mode (like debug-leds for >>> OMAP1 boards), but changes are made anyway to remove __raw_xxx() functions >>> completely and simplify future grep'ing for new __raw_xxx() entries. > > Sorry for the delay on these, applying into omap-for-v3.14/be. > These are trivial, and it's actually nice that you left out the > assembly related changes as those should be acked by the PM > people in case there are some issues dealing with the ROM code > etc. Hi Tony, It seems omap-for-v3.14/be didn't get into 3.14-rc8. Is there any issue with them? -- Taras Kondratiuk -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 01/12] phy: phy-omap-pipe3: Add support for PCIe PHY
PCIe PHY uses an external pll instead of the internal pll used by SATA
and USB3. So added support in pipe3 PHY to use external pll
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
drivers/phy/phy-ti-pipe3.c | 99 +-
2 files changed, 84 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 788fb0f..e628a23 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -49,8 +49,8 @@ usb2phy@4a0ad080 {
TI PIPE3 PHY
Required properties:
- - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata".
- "ti,omap-usb3" is deprecated.
+ - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or
+ "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated.
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in "reg".
@@ -62,6 +62,10 @@ Required properties:
* "wkupclk" - wakeup clock.
* "sysclk" - system clock.
* "refclk" - reference clock.
+ * "dpll_ref" - external dpll ref clk
+ * "dpll_ref_m2" - external dpll ref clk
+ * "phy-div" - divider for apll
+ * "div-clk" - apll clock
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 5913676..d43019d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -80,6 +80,7 @@ struct ti_pipe3 {
struct clk *wkupclk;
struct clk *sys_clk;
struct clk *refclk;
+ struct clk *div_clk;
struct pipe3_dpll_map *dpll_map;
};
@@ -215,6 +216,9 @@ static int ti_pipe3_init(struct phy *x)
u32 val;
int ret = 0;
+ if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie"))
+ return 0;
+
/* Bring it out of IDLE if it is IDLE */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
if (val & PLL_IDLE) {
@@ -238,8 +242,11 @@ static int ti_pipe3_exit(struct phy *x)
u32 val;
unsigned long timeout;
- /* SATA DPLL can't be powered down due to Errata i783 */
- if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata"))
+ /* SATA DPLL can't be powered down due to Errata i783 and PCIe
+* does not have internal DPLL
+*/
+ if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata") ||
+ of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie"))
return 0;
/* Put DPLL in IDLE mode */
@@ -286,32 +293,41 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct device_node *control_node;
struct platform_device *control_pdev;
const struct of_device_id *match;
-
- match = of_match_device(of_match_ptr(ti_pipe3_id_table), &pdev->dev);
- if (!match)
- return -EINVAL;
+ struct clk *clk;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
dev_err(&pdev->dev, "unable to alloc mem for TI PIPE3 PHY\n");
return -ENOMEM;
}
+ phy->dev= &pdev->dev;
- phy->dpll_map = (struct pipe3_dpll_map *)match->data;
- if (!phy->dpll_map) {
- dev_err(&pdev->dev, "no DPLL data\n");
- return -EINVAL;
- }
+ if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+ match = of_match_device(of_match_ptr(ti_pipe3_id_table),
+ &pdev->dev);
+ if (!match)
+ return -EINVAL;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pll_ctrl");
- phy->pll_ctrl_base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(phy->pll_ctrl_base))
- return PTR_ERR(phy->pll_ctrl_base);
+ phy->dpll_map = (struct pipe3_dpll_map *)match->data;
+ if (!phy->dpll_map) {
+ dev_err(&pdev->dev, "no DPLL data\n");
+ return -EINVAL;
+ }
- phy->dev= &pdev->dev;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "pll_ctrl");
+ phy->pll_ctrl_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(phy->pll_ctrl_base))
+ return PTR_ERR(phy->pll_ctrl_base);
- if (!of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
+ phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
+ if (IS_ERR(phy->sys_clk)) {
+ dev_err(&pdev->dev, "unable to get sysclk\n");
+
[RFC PATCH 12/12] ARM: OMAP: Enable PCI for DRA7
Now that we have added PCIe driver for DRA7 SOCs, enable PCI on DRA7 SOCs. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/mach-omap2/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 46f8c53..352f252 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -86,6 +86,8 @@ config SOC_DRA7XX select HAVE_SMP select HAVE_ARM_ARCH_TIMER select IRQ_CROSSBAR + select MIGHT_HAVE_PCI + select ARCH_SUPPORTS_MSI config ARCH_OMAP2PLUS bool -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 11/12] ARM: dts: dra7: Add dt data for PCIe controller
Added dt data for PCIe controller. This node contains dt data for
both the DRA7 part of designware controller and for the designware core.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 7ac372b..10def39 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -701,6 +701,30 @@
};
};
+ pcie@5100 {
+ compatible = "ti,dra7xx-pcie";
+ reg = <0x51002000 0x14c>, <0x5100 0x2000>,
<0x4A002540 0x1f>;
+ reg-names = "ti_conf", "rc_dbics", "mmr_unlock";
+ interrupts = <0 232 0x4>, <0 233 0x4>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ti,device_type = <3>;
+ ranges = <0x0800 0 0x20001000 0x20001000 0
0x2000
+ 0x8100 0 0 0x20003000 0
0x0001
+ 0x8200 0 0x20013000 0x20013000 0
0xffed000>;
+ #interrupt-cells = <1>;
+ base-mask = <0x 0x0fff>;
+ num-lanes = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0x0 0 &gic 233>;
+ ti,hwmods = "pcie1";
+ phys = <&pcie1_phy>;
+ phy-names = "pcie-phy";
+ resets = <&prm_resets &device_reset>;
+ reset-names = "reset";
+ };
+
sata: sata@4a141100 {
compatible = "snps,dwc-ahci";
reg = <0x4a14 0x1100>, <0x4a141100 0x7>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 10/12] ARM: dts: dra7: Add dt data for PCIe PHY
Added dt data for PCIe PHY as a child node of ocp2scp3.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 73c61d0..7ac372b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -683,6 +683,22 @@
clock-names = "sysclk";
#phy-cells = <0>;
};
+
+ pcie1_phy: pciephy@4a094000 {
+ compatible = "ti,phy-pipe3-pcie";
+ ctrl-module = <&omap_control_pcie1phy>;
+ clocks = <&dpll_pcie_ref_ck>,
+<&dpll_pcie_ref_m2ldo_ck>,
+<&optfclk_pciephy_32khz>,
+<&optfclk_pciephy_clk>,
+<&optfclk_pciephy_div_clk>,
+<&optfclk_pciephy_div>;
+ clock-names = "dpll_ref", "dpll_ref_m2",
+ "wkupclk", "refclk",
+ "div-clk", "phy-div";
+ #phy-cells = <0>;
+ ti,hwmods = "pcie1-phy";
+ };
};
sata: sata@4a141100 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 09/12] ARM: dts: dra7: Add dt data for PCIe PHY control module
Added dt data for PCIe PHY control module used by PCIe PHY.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f3565ac..73c61d0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -656,6 +656,14 @@
clock-names = "sysclk";
};
+ omap_control_pcie1phy: omap-control-pciephy@0x4a003c40 {
+ compatible = "ti,control-phy-pipe3";
+ reg = <0x4a003c40 0x4>;
+ reg-names = "power";
+ clocks = <&sys_clkin1>;
+ clock-names = "sysclk";
+ };
+
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile|1 +
drivers/pci/host/pcie-dra7xx.c | 411 ++
4 files changed, 457 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
create mode 100644 drivers/pci/host/pcie-dra7xx.c
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
b/Documentation/devicetree/bindings/pci/ti-pci.txt
new file mode 100644
index 000..0528c47
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -0,0 +1,35 @@
+TI PCI Controllers
+
+PCIe Designware Controller
+This node should have the properties described in "designware-pcie.txt".
+ - compatible: Should be "ti,dra7xx-pcie""
+ - reg : Address and length of the register set for the device.
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
+ - resets: phandle used if reset is handled be soc
+ - reset-names: name given to the phandle
+ - ti,device-type: Should be 1 - EP TYPE, 2 - LEG EP TYPE OR 3 - RC TYPE
+
+Example:
+pcie@5100 {
+ compatible = "ti,dra7xx-pcie";
+ reg = <0x51002000 0x14c>, <0x5100 0x2000>, <0x4A002540 0x1f>,
<0x4A003c24 0x4>, <0x4AE07310 0x4>;
+ interrupts = <0 129 0x4>, <0 134 0x4>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ti,device_type = <3>;
+ ranges = <0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
+ 0x8100 0 0 0x20003000 0 0x0001 /* IO Space
*/
+ 0x8200 0 0x20013000 0x20013000 0 0xffed000>; /* MEM Space
*/
+ #interrupt-cells = <1>;
+ num-lanes = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0x0 0 &gic 134>;
+ ti,hwmods = "pcie1";
+ phys = <&pcie1_phy>;
+ phy-names = "pcie-phy";
+ resets = <&prm_resets &device_reset>;
+ reset-names = "reset";
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 47d46c6..5066a3c 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -1,6 +1,16 @@
menu "PCI host controller drivers"
depends on PCI
+config PCIE_DRA7XX
+ bool "TI DRA7xx PCIe controller"
+ select PCIE_DW
+ depends on OF || HAS_IOMEM || TI_PIPE3
+ help
+Enables support for the PCIE controller present in DRA7xx SoC. There
+are two instances of PCIE controller in DRA7xx. This controller can
+act both as EP and RC. This reuses the same Designware core as used
+by other SoCs.
+
config PCI_MVEBU
bool "Marvell EBU PCIe controller"
depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 13fb333..90a275d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_PCIE_DW) += pcie-designware.o
+obj-$(CONFIG_PCIE_DRA7XX) += pcie-dra7xx.o
obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
diff --git a/drivers/pci/host/pcie-dra7xx.c b/drivers/pci/host/pcie-dra7xx.c
new file mode 100644
index 000..69f3720
--- /dev/null
+++ b/drivers/pci/host/pcie-dra7xx.c
@@ -0,0 +1,411 @@
+/*
+ * pcie-dra7xx - PCIe controller driver for TI DRA7xx SoCs
+ *
+ * Copyright (C) 2013-2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors: Kishon Vijay Abraham I
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-designware.h"
+
+/* PCIe controller wrapper TI configuration registers */
+
+#definePCIECTRL_TI_CONF_IRQSTATUS_MAIN 0x0024
+#definePCIECTRL_TI_CONF_IRQENABLE_SET_MAIN 0x0028
+#defineERR_SYS BIT(0)
+#defineERR_FATAL BIT(1)
+#defineERR_NONFATALBIT(2)
+#defineERR_COR BIT(3)
+#defineERR_AXI BIT(4)
+#defineERR_ECRCBIT(5)
+#definePME_TURN_OFFBIT(8)
+#definePME_TO_ACK BIT(9)
+#definePM_PME BIT(10)
+#defineLINK_REQ_RST
[RFC PATCH 05/12] ARM: dts: DRA7: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
From: Keerthy
Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
from dpll_pcie_ref_ck.
Signed-off-by: Keerthy
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index d909484..9e0bb09 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1152,7 +1152,7 @@
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = "ti,mux-clock";
- clocks = <&dpll_pcie_ref_ck>, <&pciesref_acs_clk_ck>;
+ clocks = <&dpll_pcie_ref_m2ldo_ck>, <&pciesref_acs_clk_ck>;
#clock-cells = <0>;
reg = <0x021c 0x4>;
ti,bit-shift = <7>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 07/12] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 9397265..c789b00 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+ .name = "pcie",
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+ .name = "pcie1",
+ .class = &dra7xx_pcie_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+ .name = "pcie2",
+ .class = &dra7xx_pcie_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'PCIE PHY' class
*
*/
@@ -2459,6 +2496,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie1_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie2_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg -> pcie1 phy */
static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = &dra7xx_l4_cfg_hwmod,
@@ -2824,6 +2877,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
&dra7xx_l4_cfg__ocp2scp3,
+ &dra7xx_l4_cfg__pcie1,
+ &dra7xx_l4_cfg__pcie2,
&dra7xx_l4_cfg__pcie1_phy,
&dra7xx_l4_cfg__pcie2_phy,
&dra7xx_l3_main_1__qspi,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 08/12] ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY
Added missing 32khz clock used by PCIe PHY.
The documention for this node can be found @ ../bindings/clock/ti/gate.txt.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 9e0bb09..5f13189 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1165,6 +1165,14 @@
reg = <0x021c>, <0x0220>;
};
+ optfclk_pciephy_32khz: optfclk_pciephy_32khz@4a0093b0 {
+ compatible = "ti,gate-clock";
+ clocks = <&sys_32k_ck>;
+ #clock-cells = <0>;
+ reg = <0x13b0>;
+ ti,bit-shift = <8>;
+ };
+
optfclk_pciephy_div: optfclk_pciephy_div@4a00821c {
compatible = "ti,divider-clock";
clocks = <&apll_pcie_ck>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 06/12] arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/cm2_7xx.h |4 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 57 +
arch/arm/mach-omap2/prm7xx.h |4 ++
3 files changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/cm2_7xx.h b/arch/arm/mach-omap2/cm2_7xx.h
index 9ad7594..e966e3a 100644
--- a/arch/arm/mach-omap2/cm2_7xx.h
+++ b/arch/arm/mach-omap2/cm2_7xx.h
@@ -357,6 +357,10 @@
#define DRA7XX_CM_L3INIT_SATA_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0088)
#define DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET0x00a0
#define DRA7XX_CM_PCIE_STATICDEP_OFFSET0x00a4
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET0x00b0
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b0)
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET0x00b8
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b8)
#define DRA7XX_CM_GMAC_CLKSTCTRL_OFFSET0x00c0
#define DRA7XX_CM_GMAC_STATICDEP_OFFSET0x00c4
#define DRA7XX_CM_GMAC_DYNAMICDEP_OFFSET 0x00c8
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index befe7ce..9397265 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,45 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE PHY' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
+ .name = "pcie-phy",
+};
+
+/* pcie1 phy */
+static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
+ .name = "pcie1-phy",
+ .class = &dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 phy */
+static struct omap_hwmod dra7xx_pcie2_phy_hwmod = {
+ .name = "pcie2-phy",
+ .class = &dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS2_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'qspi' class
*
*/
@@ -2420,6 +2459,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> pcie1 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie1_phy_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> pcie2 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2_phy = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_pcie2_phy_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2769,6 +2824,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
&dra7xx_l4_cfg__ocp2scp3,
+ &dra7xx_l4_cfg__pcie1_phy,
+ &dra7xx_l4_cfg__pcie2_phy,
&dra7xx_l3_main_1__qspi,
&dra7xx_l4_cfg__sata,
&dra7xx_l4_cfg__smartreflex_core,
diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h
index d92a840..4bb50fbf 100644
--- a/arch/arm/mach-omap2/prm7xx.h
+++ b/arch/arm/mach-omap2/prm7xx.h
@@ -374,6 +374,10 @@
#define DRA7XX_RM_L3INIT_IEEE1500_2_OCP_CONTEXT_OFFSET 0x007c
#define DRA7XX_PM_L3INIT_SATA_WKDEP_OFFSET 0x0088
#define DRA7XX_RM_L3INIT_SATA_CONTEXT_OFFSET 0x008c
+#define DRA7XX_PM_L3INIT_PCIESS1_WKDEP_OFFSET 0x00b0
+#define DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET0x00b4
+#define DRA7XX_PM_L3INIT_PCIESS2_WKDEP_OFFSET 0x00b8
+#define DRA7XX_RM_L3INIT_PCIESS2_CO
[RFC PATCH 03/12] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit
address. So whenever the cpu issues a read/write request, the 4 most
significant bits are used by L3 to determine the target controller.
For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but
the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming
the outbound translation window the *base* should be programmed as 0x000_.
Whenever we try to write to say 0x2000_, it will be translated to whatever
we have programmed in the translation window with base as 0x000_.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/pci/designware-pcie.txt|1 +
drivers/pci/host/pcie-designware.c | 39 ++--
drivers/pci/host/pcie-designware.h |1 +
3 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13..c574dd3 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -27,6 +27,7 @@ Optional properties for fsl,imx6q-pcie
- power-on-gpio: gpio pin number of power-enable signal
- wake-up-gpio: gpio pin number of incoming wakeup signal
- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
+- base-mask: address mask for the PCIe controller target port
Example:
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 17ce88f..98b661c 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -464,6 +464,9 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
return -EINVAL;
}
+ if (of_property_read_u64(np, "base-mask", &pp->base_mask))
+ pp->base_mask = ~(0x0ULL);
+
if (IS_ENABLED(CONFIG_PCI_MSI)) {
pp->irq_domain = irq_domain_add_linear(pp->dev->of_node,
MAX_MSI_IRQS, &msi_domain_ops,
@@ -503,12 +506,15 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
static void dw_pcie_prog_viewport_cfg0(struct pcie_port *pp, u32 busdev)
{
+ u64 cfg0_base;
+
+ cfg0_base = pp->cfg0_base & pp->base_mask;
/* Program viewport 0 : OUTBOUND : CFG0 */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, pp->cfg0_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->cfg0_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->cfg0_base + pp->config.cfg0_size - 1,
+ dw_pcie_writel_rc(pp, cfg0_base, PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, (cfg0_base >> 32), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, cfg0_base + pp->config.cfg0_size - 1,
PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
@@ -518,14 +524,17 @@ static void dw_pcie_prog_viewport_cfg0(struct pcie_port
*pp, u32 busdev)
static void dw_pcie_prog_viewport_cfg1(struct pcie_port *pp, u32 busdev)
{
+ u64 cfg1_base;
+
+ cfg1_base = pp->cfg1_base & pp->base_mask;
/* Program viewport 1 : OUTBOUND : CFG1 */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_CFG1, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
- dw_pcie_writel_rc(pp, pp->cfg1_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->cfg1_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->cfg1_base + pp->config.cfg1_size - 1,
+ dw_pcie_writel_rc(pp, cfg1_base, PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, (cfg1_base >> 32), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, cfg1_base + pp->config.cfg1_size - 1,
PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
@@ -533,14 +542,17 @@ static void dw_pcie_prog_viewport_cfg1(struct pcie_port
*pp, u32 busdev)
static void dw_pcie_prog_viewport_mem_outbound(struct pcie_port *pp)
{
+ u64 mem_base;
+
+ mem_base = pp->mem_base & pp->base_mask;
/* Program viewport 0 : OUTBOUND : MEM */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
- dw_pcie_writel_rc(pp, pp->mem_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp->mem_base >> 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp->mem_base + pp->config.mem_size
[RFC PATCH 00/12] PCIe support for DRA7xx
This patch series adds support for PCIe in DRA7xx including drivers and dt data. PCIe in DRA7xx uses desingware IP and hence this re-uses the pcie desingware driver (pcie-designware.c) by Jingoo. This patch series depends on a few patches that is already in -next. Tested broadcom PCIe card and XIO2000 bridge along with DGE530T ethernet card. Keerthy (2): ARM: dts: DRA7: Add divider table to optfclk_pciephy_div clock ARM: dts: DRA7: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck Kishon Vijay Abraham I (10): phy: phy-omap-pipe3: Add support for PCIe PHY pci: host: pcie-dra7xx: add support for pcie-dra7xx controller pci: host: pcie-designware: Use *base-mask* for configuring the iATU arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY ARM: dts: dra7: Add dt data for PCIe PHY control module ARM: dts: dra7: Add dt data for PCIe PHY ARM: dts: dra7: Add dt data for PCIe controller ARM: OMAP: Enable PCI for DRA7 .../devicetree/bindings/pci/designware-pcie.txt|1 + Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++ Documentation/devicetree/bindings/phy/ti-phy.txt |8 +- arch/arm/boot/dts/dra7.dtsi| 48 +++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 11 +- arch/arm/mach-omap2/Kconfig|2 + arch/arm/mach-omap2/cm2_7xx.h |4 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 112 ++ arch/arm/mach-omap2/prm7xx.h |4 + drivers/pci/host/Kconfig | 10 + drivers/pci/host/Makefile |1 + drivers/pci/host/pcie-designware.c | 39 +- drivers/pci/host/pcie-designware.h |1 + drivers/pci/host/pcie-dra7xx.c | 411 drivers/phy/phy-ti-pipe3.c | 99 - 15 files changed, 750 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt create mode 100644 drivers/pci/host/pcie-dra7xx.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 04/12] ARM: dts: DRA7: Add divider table to optfclk_pciephy_div clock
From: Keerthy Add divider table to optfclk_pciephy_div clock. Signed-off-by: Keerthy Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/dra7xx-clocks.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi index e96da9a..d909484 100644 --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi @@ -1170,6 +1170,7 @@ clocks = <&apll_pcie_ck>; #clock-cells = <0>; reg = <0x021c>; + ti,dividers = <2>, <1>; ti,bit-shift = <8>; ti,max-div = <2>; }; -- 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: [RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Wed, Mar 26, 2014 at 8:57 AM, Kishon Vijay Abraham I wrote:
> Added support for pcie controller in dra7xx. This driver re-uses
> the designware core code that is already present in kernel.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
> drivers/pci/host/Kconfig | 10 +
> drivers/pci/host/Makefile|1 +
> drivers/pci/host/pcie-dra7xx.c | 411
> ++
> 4 files changed, 457 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
> create mode 100644 drivers/pci/host/pcie-dra7xx.c
>
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
> b/Documentation/devicetree/bindings/pci/ti-pci.txt
> new file mode 100644
> index 000..0528c47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -0,0 +1,35 @@
> +TI PCI Controllers
> +
> +PCIe Designware Controller
> +This node should have the properties described in "designware-pcie.txt".
> + - compatible: Should be "ti,dra7xx-pcie""
> + - reg : Address and length of the register set for the device.
> + - phys : the phandle for the PHY device (used by generic PHY framework)
> + - phy-names : the names of the PHY corresponding to the PHYs present in the
> + *phy* phandle.
> + - resets: phandle used if reset is handled be soc
s/be/by/ ?
> + - reset-names: name given to the phandle
> + - ti,device-type: Should be 1 - EP TYPE, 2 - LEG EP TYPE OR 3 - RC TYPE
I don't think this makes sense. I'd imagine we'd need the binding to
look quite a bit different if endpoint mode was actually supported. I
think I would start defining endpoint mode with a different compatible
string and go from there.
> +
> +Example:
> +pcie@5100 {
> + compatible = "ti,dra7xx-pcie";
> + reg = <0x51002000 0x14c>, <0x5100 0x2000>, <0x4A002540 0x1f>,
> <0x4A003c24 0x4>, <0x4AE07310 0x4>;
This is different number of entries from your actual dts. You need to
define how many reg entries, what they are, and the order.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Wednesday 26 March 2014 08:15 PM, Rob Herring wrote:
> On Wed, Mar 26, 2014 at 8:57 AM, Kishon Vijay Abraham I wrote:
>> Added support for pcie controller in dra7xx. This driver re-uses
>> the designware core code that is already present in kernel.
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
>> drivers/pci/host/Kconfig | 10 +
>> drivers/pci/host/Makefile|1 +
>> drivers/pci/host/pcie-dra7xx.c | 411
>> ++
>> 4 files changed, 457 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
>> create mode 100644 drivers/pci/host/pcie-dra7xx.c
>>
>> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
>> b/Documentation/devicetree/bindings/pci/ti-pci.txt
>> new file mode 100644
>> index 000..0528c47
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
>> @@ -0,0 +1,35 @@
>> +TI PCI Controllers
>> +
>> +PCIe Designware Controller
>> +This node should have the properties described in "designware-pcie.txt".
>> + - compatible: Should be "ti,dra7xx-pcie""
>> + - reg : Address and length of the register set for the device.
>> + - phys : the phandle for the PHY device (used by generic PHY framework)
>> + - phy-names : the names of the PHY corresponding to the PHYs present in the
>> + *phy* phandle.
>> + - resets: phandle used if reset is handled be soc
>
> s/be/by/ ?
>
>> + - reset-names: name given to the phandle
>> + - ti,device-type: Should be 1 - EP TYPE, 2 - LEG EP TYPE OR 3 - RC TYPE
>
> I don't think this makes sense. I'd imagine we'd need the binding to
> look quite a bit different if endpoint mode was actually supported. I
right, it makes sense to remove the ti,device-type altogether as this driver
only supports RC.
> think I would start defining endpoint mode with a different compatible
> string and go from there.
>
>> +
>> +Example:
>> +pcie@5100 {
>> + compatible = "ti,dra7xx-pcie";
>> + reg = <0x51002000 0x14c>, <0x5100 0x2000>, <0x4A002540 0x1f>,
>> <0x4A003c24 0x4>, <0x4AE07310 0x4>;
>
> This is different number of entries from your actual dts. You need to
> define how many reg entries, what they are, and the order.
Ok. Will fix it.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 0/2] Move dai-link level properties away from dai subnodes
On Mon, 24 Mar 2014 12:15:23 +0200 Jyri Sarha wrote: > This patch is implemented on top of late patches from Jean-Francois > Moine [1]. > > These patches implement the main part of the simple-card changes > discussed in alsa-devel mailing list [2]. Acked-by: Jean-Francois Moine -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 12/18] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
* Tero Kristo [140326 01:04]: > On 03/26/2014 12:36 AM, Tony Lindgren wrote: > >* Tero Kristo [140304 08:23]: > >>There is a solitary write to this register every wakeup from off-mode, > >>which isn't doing anything, so remove it. > > > >Argh, this chunk of code is for sure the the thing that's blocking all > >the voltage scaling for idle modes that twl4030 is supposed to do! > > > >AFAIK we must have AUTO_SLEEP, AUTO_RET and AUTO_OFF bits set in > >PRM_VOLTCTRL for twl4030 to scale anything. They must be set if we're > >scaling over I2C4 or using the pins as triggers. Unless these bits > >are set, VC won't send any SLEEP, RET or OFF commands. > > > >Looks like we're not even set these bits anywhere like we should? > > > >I think we should enabled these bits in vc.c init, and never clear? > > The bits should be set according to the target sleep mode I believe, > e.g. for retention we should set only AUTO_RET, and for off-mode > AUTO_OFF. You can't have AUTO_OFF enabled if you are going to > retention only as far as I recall, this potentially caused some > problems. OK. So it seems that the idle code needs to constantly modify this register based on the idle mode. Any ideas how the idle code is going to update this register? Register a callback using platform_data? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] mmc: host: omap_hsmmc: set max_blk_size correctly
now that we can finally read the new registers for
new versions of the mmc IP, we can set max_blk_size
correctly depending on the version of the IP we're
running on.
Signed-off-by: Felipe Balbi
---
drivers/mmc/host/omap_hsmmc.c | 45 ++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d32f6ac..ae5583e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,18 @@
#define OMAP_HSMMC_AC120x013C
#define OMAP_HSMMC_CAPA0x0140
+/* OMAP HSMMC Host Controller Register (NEW)
+ *
+ * NOTE: DO NOT READ THESE WITH OFFSET
+ */
+#define OMAP_HSMMC_HL_REV 0x
+#define OMAP_HSMMC_HL_HWINFO 0x0004
+# define OMAP_HSMMC_HL_HWINFO_MADMA_EN(1 << 0)
+# define OMAP_HSMMC_HL_HWINFO_MERGE_MEM (1 << 1)
+# define OMAP_HSMMC_HL_HWINFO_MEM_SIZE(x) (((x) & (0x0f << 2)) >> 2)
+# define OMAP_HSMMC_HL_HWINFO_RETMODE (1 << 6)
+#define OMAP_HSMMC_HL_SYSCONFIG0x0010
+
#define VS18 (1 << 26)
#define VS30 (1 << 25)
#define HSS(1 << 21)
@@ -1867,6 +1879,37 @@ static inline struct omap_mmc_platform_data
}
#endif
+static void omap_hsmmc_set_max_blk_size(struct omap_hsmmc_host *host)
+{
+ struct mmc_host *mmc = host->mmc;
+
+ if (of_device_is_compatible(host->dev->of_node, "ti,omap4-hsmmc")) {
+ u32 mem;
+ u32 reg;
+
+ reg = omap_hsmmc_read_no_offset(host, OMAP_HSMMC_HL_HWINFO);
+ mem = OMAP_HSMMC_HL_HWINFO_MEM_SIZE(reg);
+
+ switch (mem) {
+ case 1:
+ mmc->max_blk_size = 512;
+ break;
+ case 2:
+ mmc->max_blk_size = 1024;
+ break;
+ case 4:
+ /* FALLTHROUGH */
+ case 8:
+ /* FALLTHROUGH */
+ default:
+ mmc->max_blk_size = 2048;
+ break;
+ }
+ } else {
+ mmc->max_blk_size = 512; /* Block Length at max can be
1024 */
+ }
+}
+
static int omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1986,7 +2029,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
* as we want. */
mmc->max_segs = 1024;
- mmc->max_blk_size = 512; /* Block Length at max can be 1024 */
+ omap_hsmmc_set_max_blk_size(host);
mmc->max_blk_count = 0x;/* No. of Blocks is 16 bits */
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
mmc->max_seg_size = mmc->max_req_size;
--
1.9.1.286.g5172cb3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] mmc: host: omap_hsmmc: switch over to new accessors
the newly introduced accessor funtions will help
dealing with register access which shouldn't be
done with offset in consideration.
Signed-off-by: Felipe Balbi
---
drivers/mmc/host/omap_hsmmc.c | 200 --
1 file changed, 96 insertions(+), 104 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e596c6a..d32f6ac 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -148,15 +148,6 @@
*/
#define mmc_slot(host) (host->pdata->slots[host->slot_id])
-/*
- * MMC Host controller read/write API's
- */
-#define OMAP_HSMMC_READ(host, reg) \
- __raw_readl((host)->base + OMAP_HSMMC_##reg + host->reg_offset)
-
-#define OMAP_HSMMC_WRITE(host, reg, val) \
- __raw_writel((val), (host)->base + OMAP_HSMMC_##reg + host->reg_offset)
-
struct omap_hsmmc_next {
unsigned intdma_len;
s32 cookie;
@@ -529,8 +520,8 @@ static void omap_hsmmc_gpio_free(struct
omap_mmc_platform_data *pdata)
*/
static void omap_hsmmc_start_clock(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host, SYSCTL,
- OMAP_HSMMC_READ(host, SYSCTL) | CEN);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_SYSCTL,
+ omap_hsmmc_read_offset(host, OMAP_HSMMC_SYSCTL) | CEN);
}
/*
@@ -538,9 +529,9 @@ static void omap_hsmmc_start_clock(struct omap_hsmmc_host
*host)
*/
static void omap_hsmmc_stop_clock(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host, SYSCTL,
- OMAP_HSMMC_READ(host, SYSCTL) & ~CEN);
- if ((OMAP_HSMMC_READ(host, SYSCTL) & CEN) != 0x0)
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_SYSCTL,
+ omap_hsmmc_read_offset(host, OMAP_HSMMC_SYSCTL) & ~CEN);
+ if ((omap_hsmmc_read_offset(host, OMAP_HSMMC_SYSCTL) & CEN) != 0x0)
dev_dbg(mmc_dev(host->mmc), "MMC Clock is not stopped\n");
}
@@ -558,16 +549,16 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
if (cmd->opcode == MMC_ERASE)
irq_mask &= ~DTO_EN;
- OMAP_HSMMC_WRITE(host, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host, ISE, irq_mask);
- OMAP_HSMMC_WRITE(host, IE, irq_mask);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_STAT, STAT_CLEAR);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_ISE, irq_mask);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_IE, irq_mask);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host, ISE, 0);
- OMAP_HSMMC_WRITE(host, IE, 0);
- OMAP_HSMMC_WRITE(host, STAT, STAT_CLEAR);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_ISE, 0);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_IE, 0);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_STAT, STAT_CLEAR);
}
/* Calculate divisor for the given clock frequency */
@@ -595,17 +586,17 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
omap_hsmmc_stop_clock(host);
- regval = OMAP_HSMMC_READ(host, SYSCTL);
+ regval = omap_hsmmc_read_offset(host, OMAP_HSMMC_SYSCTL);
regval = regval & ~(CLKD_MASK | DTO_MASK);
clkdiv = calc_divisor(host, ios);
regval = regval | (clkdiv << 6) | (DTO << 16);
- OMAP_HSMMC_WRITE(host, SYSCTL, regval);
- OMAP_HSMMC_WRITE(host, SYSCTL,
- OMAP_HSMMC_READ(host, SYSCTL) | ICE);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_SYSCTL, regval);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_SYSCTL,
+ omap_hsmmc_read_offset(host, OMAP_HSMMC_SYSCTL) | ICE);
/* Wait till the ICS bit is set */
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host, SYSCTL) & ICS) != ICS
+ while ((omap_hsmmc_read_offset(host, OMAP_HSMMC_SYSCTL) & ICS) != ICS
&& time_before(jiffies, timeout))
cpu_relax();
@@ -620,14 +611,14 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
*/
if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
(ios->timing != MMC_TIMING_UHS_DDR50) &&
- ((OMAP_HSMMC_READ(host, CAPA) & HSS) == HSS)) {
- regval = OMAP_HSMMC_READ(host, HCTL);
+ ((omap_hsmmc_read_offset(host, OMAP_HSMMC_CAPA) & HSS) == HSS)) {
+ regval = omap_hsmmc_read_offset(host, OMAP_HSMMC_HCTL);
if (clkdiv && (clk_get_rate(host->fclk)/clkdiv) > 2500)
regval |= HSPE;
else
regval &= ~HSPE;
- OMAP_HSMMC_WRITE(host, HCTL, regval);
+ omap_hsmmc_write_offset(host, OMAP_HSMMC_HCTL, regval);
}
omap_hsmmc_start_clock(host);
@@ -638,24 +629,24 @@ static void omap_hsmmc_set_bus_width(struct
omap_hsmmc_host *host)
struct mmc_ios *ios = &host->mmc->ios;
u32 con;
- con = OMAP_HSMMC_READ(host, CON);
+ con =
[PATCH 3/5] mmc: host: omap_hsmmc: introduce new accessor functions
we introduce new accessors which provide for register
access with and without offsets.
This is just to make sure newer versions of the IP
can access the new registers prepended at the beginning
of the address space.
Signed-off-by: Felipe Balbi
---
drivers/mmc/host/omap_hsmmc.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d46f768..e596c6a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -211,6 +211,42 @@ struct omap_hsmmc_host {
struct omap_mmc_platform_data *pdata;
};
+static inline int _omap_hsmmc_read(struct omap_hsmmc_host *host,
+ u32 reg, bool offset)
+{
+ return readl(host->base + reg + (offset ? host->reg_offset : 0));
+}
+
+static inline void _omap_hsmmc_write(struct omap_hsmmc_host *host,
+ u32 reg, u32 val, bool offset)
+{
+ writel(val, host->base + reg + (offset ? host->reg_offset : 0));
+}
+
+static inline int omap_hsmmc_read_offset(struct omap_hsmmc_host *host,
+ u32 reg)
+{
+ return _omap_hsmmc_read(host, reg, true);
+}
+
+static inline void omap_hsmmc_write_offset(struct omap_hsmmc_host *host,
+ u32 reg, u32 val)
+{
+ _omap_hsmmc_write(host, reg, val, true);
+}
+
+static inline int omap_hsmmc_read_no_offset(struct omap_hsmmc_host *host,
+ u32 reg)
+{
+ return _omap_hsmmc_read(host, reg, false);
+}
+
+static inline void omap_hsmmc_write_no_offset(struct omap_hsmmc_host *host,
+ u32 reg, u32 val)
+{
+ _omap_hsmmc_write(host, reg, val, false);
+}
+
struct omap_mmc_of_data {
u32 reg_offset;
u8 controller_flags;
--
1.9.1.286.g5172cb3
--
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/5] mmc: host: omap_hsmmc: pass host as an argument
This patch is in preparation for a larger series
of cleanups on the omap_hsmmc.c driver.
In newer instances of this IP, there's a lot of
configuration details which we can grab by reading
some new registers which were prepended to the
address space.
Signed-off-by: Felipe Balbi
---
drivers/mmc/host/omap_hsmmc.c | 198 +-
1 file changed, 99 insertions(+), 99 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e91ee21..a8f1e08 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -151,11 +151,11 @@
/*
* MMC Host controller read/write API's
*/
-#define OMAP_HSMMC_READ(base, reg) \
- __raw_readl((base) + OMAP_HSMMC_##reg)
+#define OMAP_HSMMC_READ(host, reg) \
+ __raw_readl((host)->base + OMAP_HSMMC_##reg)
-#define OMAP_HSMMC_WRITE(base, reg, val) \
- __raw_writel((val), (base) + OMAP_HSMMC_##reg)
+#define OMAP_HSMMC_WRITE(host, reg, val) \
+ __raw_writel((val), (host)->base + OMAP_HSMMC_##reg)
struct omap_hsmmc_next {
unsigned intdma_len;
@@ -492,8 +492,8 @@ static void omap_hsmmc_gpio_free(struct
omap_mmc_platform_data *pdata)
*/
static void omap_hsmmc_start_clock(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host->base, SYSCTL,
- OMAP_HSMMC_READ(host->base, SYSCTL) | CEN);
+ OMAP_HSMMC_WRITE(host, SYSCTL,
+ OMAP_HSMMC_READ(host, SYSCTL) | CEN);
}
/*
@@ -501,9 +501,9 @@ static void omap_hsmmc_start_clock(struct omap_hsmmc_host
*host)
*/
static void omap_hsmmc_stop_clock(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host->base, SYSCTL,
- OMAP_HSMMC_READ(host->base, SYSCTL) & ~CEN);
- if ((OMAP_HSMMC_READ(host->base, SYSCTL) & CEN) != 0x0)
+ OMAP_HSMMC_WRITE(host, SYSCTL,
+ OMAP_HSMMC_READ(host, SYSCTL) & ~CEN);
+ if ((OMAP_HSMMC_READ(host, SYSCTL) & CEN) != 0x0)
dev_dbg(mmc_dev(host->mmc), "MMC Clock is not stopped\n");
}
@@ -521,16 +521,16 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
if (cmd->opcode == MMC_ERASE)
irq_mask &= ~DTO_EN;
- OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
- OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
+ OMAP_HSMMC_WRITE(host, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host, IE, irq_mask);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host->base, ISE, 0);
- OMAP_HSMMC_WRITE(host->base, IE, 0);
- OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host, ISE, 0);
+ OMAP_HSMMC_WRITE(host, IE, 0);
+ OMAP_HSMMC_WRITE(host, STAT, STAT_CLEAR);
}
/* Calculate divisor for the given clock frequency */
@@ -558,17 +558,17 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
omap_hsmmc_stop_clock(host);
- regval = OMAP_HSMMC_READ(host->base, SYSCTL);
+ regval = OMAP_HSMMC_READ(host, SYSCTL);
regval = regval & ~(CLKD_MASK | DTO_MASK);
clkdiv = calc_divisor(host, ios);
regval = regval | (clkdiv << 6) | (DTO << 16);
- OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
- OMAP_HSMMC_WRITE(host->base, SYSCTL,
- OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
+ OMAP_HSMMC_WRITE(host, SYSCTL, regval);
+ OMAP_HSMMC_WRITE(host, SYSCTL,
+ OMAP_HSMMC_READ(host, SYSCTL) | ICE);
/* Wait till the ICS bit is set */
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host->base, SYSCTL) & ICS) != ICS
+ while ((OMAP_HSMMC_READ(host, SYSCTL) & ICS) != ICS
&& time_before(jiffies, timeout))
cpu_relax();
@@ -583,14 +583,14 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
*/
if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
(ios->timing != MMC_TIMING_UHS_DDR50) &&
- ((OMAP_HSMMC_READ(host->base, CAPA) & HSS) == HSS)) {
- regval = OMAP_HSMMC_READ(host->base, HCTL);
+ ((OMAP_HSMMC_READ(host, CAPA) & HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host, HCTL);
if (clkdiv && (clk_get_rate(host->fclk)/clkdiv) > 2500)
regval |= HSPE;
else
regval &= ~HSPE;
- OMAP_HSMMC_WRITE(host->base, HCTL, regval);
+ OMAP_HSMMC_WRITE(host, HCTL, regval);
}
omap_hsmmc_start_clock(host);
@@ -601,24 +601,24 @@ static void omap_hsmmc_set_bus_width(struct
omap_hsmmc_host *host)
struct mmc_ios *ios = &host->mmc->ios;
u32 con;
- con = OMAP_HSMMC_READ(host->base, CON);
+ con = OMAP_HSMMC_READ(host, CON);
if (ios->timing == MMC_T
[PATCH 0/5] mmc: host: omap_hsmmc: a few improvements
Hi, this series lets us access the newer registers introduced back in OMAP4 which give us some valid information about the OMAP HSMMC IP like max block size, support for ADMA, support for Retention. Right now, only setting max_blk_size correctly as supporting ADMA and Retention will take a lot of work. Tested on OMAP5 uEVM. Felipe Balbi (5): mmc: host: omap_hsmmc: pass host as an argument mmc: host: omap_hsmmc: add reg_offset field mmc: host: omap_hsmmc: introduce new accessor functions mmc: host: omap_hsmmc: switch over to new accessors mmc: host: omap_hsmmc: set max_blk_size correctly drivers/mmc/host/omap_hsmmc.c | 291 ++ 1 file changed, 182 insertions(+), 109 deletions(-) -- 1.9.1.286.g5172cb3 -- 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/5] mmc: host: omap_hsmmc: add reg_offset field
by saving reg_offset inside our host structure
we can ioremap the correct area, make use of
resource_size() and make sure newer versions
of the IP have access to the new set of registers
which were added back in OMAP4.
Signed-off-by: Felipe Balbi
---
drivers/mmc/host/omap_hsmmc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a8f1e08..d46f768 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -152,10 +152,10 @@
* MMC Host controller read/write API's
*/
#define OMAP_HSMMC_READ(host, reg) \
- __raw_readl((host)->base + OMAP_HSMMC_##reg)
+ __raw_readl((host)->base + OMAP_HSMMC_##reg + host->reg_offset)
#define OMAP_HSMMC_WRITE(host, reg, val) \
- __raw_writel((val), (host)->base + OMAP_HSMMC_##reg)
+ __raw_writel((val), (host)->base + OMAP_HSMMC_##reg + host->reg_offset)
struct omap_hsmmc_next {
unsigned intdma_len;
@@ -184,6 +184,7 @@ struct omap_hsmmc_host {
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
+ unsigned intreg_offset;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -1354,8 +1355,8 @@ static int omap_hsmmc_setup_dma_transfer(struct
omap_hsmmc_host *host,
chan = omap_hsmmc_get_dma_chan(host, data);
- cfg.src_addr = host->mapbase + OMAP_HSMMC_DATA;
- cfg.dst_addr = host->mapbase + OMAP_HSMMC_DATA;
+ cfg.src_addr = host->mapbase + OMAP_HSMMC_DATA + host->reg_offset;
+ cfg.dst_addr = host->mapbase + OMAP_HSMMC_DATA + host->reg_offset;
cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
cfg.src_maxburst = data->blksz / 4;
@@ -1903,8 +1904,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->dma_ch= -1;
host->irq = irq;
host->slot_id = 0;
- host->mapbase = res->start + pdata->reg_offset;
- host->base = ioremap(host->mapbase, SZ_4K);
+ host->reg_offset = pdata->reg_offset;
+ host->mapbase = res->start;
+ host->base = ioremap(res->start, resource_size(res));
host->power_mode = MMC_POWER_OFF;
host->next_data.cookie = 1;
host->pbias_enabled = 0;
--
1.9.1.286.g5172cb3
--
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 5/5] mmc: host: omap_hsmmc: set max_blk_size correctly
Hi,
On Wed, Mar 26, 2014 at 07:04:50PM -0500, Felipe Balbi wrote:
> @@ -1867,6 +1879,37 @@ static inline struct omap_mmc_platform_data
> }
> #endif
>
> +static void omap_hsmmc_set_max_blk_size(struct omap_hsmmc_host *host)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (of_device_is_compatible(host->dev->of_node, "ti,omap4-hsmmc")) {
> + u32 mem;
> + u32 reg;
> +
> + reg = omap_hsmmc_read_no_offset(host, OMAP_HSMMC_HL_HWINFO);
> + mem = OMAP_HSMMC_HL_HWINFO_MEM_SIZE(reg);
> +
> + switch (mem) {
> + case 1:
> + mmc->max_blk_size = 512;
> + break;
> + case 2:
> + mmc->max_blk_size = 1024;
> + break;
> + case 4:
> + /* FALLTHROUGH */
> + case 8:
> + /* FALLTHROUGH */
> + default:
> + mmc->max_blk_size = 2048;
> + break;
> + }
> + } else {
> + mmc->max_blk_size = 512; /* Block Length at max can be
> 1024 */
looks like here, we could read CAPA register to figure out if older
devices support bigger block sizes. According to TRM, omap3 should
support 1024 just fine.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 09/11] bluetooth: hci_ldisc: fix deadlock condition
[ +to Marcel Holtmann ]
On 03/20/2014 03:30 PM, Felipe Balbi wrote:
LDISCs shouldn't call tty->ops->write() from within
->write_wakeup().
->write_wakeup() is called with port lock taken and
IRQs disabled, tty->ops->write() will try to acquire
the same port lock and we will deadlock.
Reviewed-by: Peter Hurley
Reported-by: Huang Shijie
Signed-off-by: Felipe Balbi
I just noticed this patch wasn't addressed to Marcel;
seems like this should go through the bluetooth tree (but not
through bluetooth-next because it fixes an oops).
Marcel,
You may want to build on top of this patch split handling;
I noticed some of the protocol drivers are calling
hci_uart_tx_wakeup() from work functions already (so don't
need to schedule another work...)
Regards,
Peter Hurley
---
drivers/bluetooth/hci_ldisc.c | 24 +++-
drivers/bluetooth/hci_uart.h | 1 +
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 6e06f6f..77af52f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -118,10 +118,6 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
- struct tty_struct *tty = hu->tty;
- struct hci_dev *hdev = hu->hdev;
- struct sk_buff *skb;
-
if (test_and_set_bit(HCI_UART_SENDING, &hu->tx_state)) {
set_bit(HCI_UART_TX_WAKEUP, &hu->tx_state);
return 0;
@@ -129,6 +125,22 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
BT_DBG("");
+ schedule_work(&hu->write_work);
+
+ return 0;
+}
+
+static void hci_uart_write_work(struct work_struct *work)
+{
+ struct hci_uart *hu = container_of(work, struct hci_uart, write_work);
+ struct tty_struct *tty = hu->tty;
+ struct hci_dev *hdev = hu->hdev;
+ struct sk_buff *skb;
+
+ /* REVISIT: should we cope with bad skbs or ->write() returning
+* and error value ?
+*/
+
restart:
clear_bit(HCI_UART_TX_WAKEUP, &hu->tx_state);
@@ -153,7 +165,6 @@ restart:
goto restart;
clear_bit(HCI_UART_SENDING, &hu->tx_state);
- return 0;
}
static void hci_uart_init_work(struct work_struct *work)
@@ -281,6 +292,7 @@ static int hci_uart_tty_open(struct tty_struct *tty)
tty->receive_room = 65536;
INIT_WORK(&hu->init_ready, hci_uart_init_work);
+ INIT_WORK(&hu->write_work, hci_uart_write_work);
spin_lock_init(&hu->rx_lock);
@@ -318,6 +330,8 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (hdev)
hci_uart_close(hdev);
+ cancel_work_sync(&hu->write_work);
+
if (test_and_clear_bit(HCI_UART_PROTO_SET, &hu->flags)) {
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, &hu->flags))
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index fffa61f..12df101 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -68,6 +68,7 @@ struct hci_uart {
unsigned long hdev_flags;
struct work_struct init_ready;
+ struct work_struct write_work;
struct hci_uart_proto *proto;
void*priv;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 0/2] Move dai-link level properties away from dai subnodes
On Mon, Mar 24, 2014 at 12:15:23PM +0200, Jyri Sarha wrote: > This patch is implemented on top of late patches from Jean-Francois > Moine [1]. Applied both, thanks. signature.asc Description: Digital signature
Re: [PATCH 09/11] bluetooth: hci_ldisc: fix deadlock condition
Hi, On Wed, Mar 26, 2014 at 08:47:15PM -0400, Peter Hurley wrote: > [ +to Marcel Holtmann ] > > On 03/20/2014 03:30 PM, Felipe Balbi wrote: > >LDISCs shouldn't call tty->ops->write() from within > >->write_wakeup(). > > > >->write_wakeup() is called with port lock taken and > >IRQs disabled, tty->ops->write() will try to acquire > >the same port lock and we will deadlock. > > > >Reviewed-by: Peter Hurley > >Reported-by: Huang Shijie > >Signed-off-by: Felipe Balbi > > I just noticed this patch wasn't addressed to Marcel; > seems like this should go through the bluetooth tree (but not > through bluetooth-next because it fixes an oops). read the archives: http://marc.info/?l=linux-bluetooth&m=139534449409583&w=2 > Marcel, > > You may want to build on top of this patch split handling; > I noticed some of the protocol drivers are calling > hci_uart_tx_wakeup() from work functions already (so don't > need to schedule another work...) I don't think that should be part of $subject, though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 10/11] Revert "serial: omap: unlock the port lock"
Hi, On Wed, Mar 26, 2014 at 08:39:11PM -0400, Peter Hurley wrote: > On 03/25/2014 02:28 PM, Tony Lindgren wrote: > >* Felipe Balbi [140320 12:39]: > >>This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e. > >> > >>That commit tried to fix a deadlock problem when using > >>hci_ldisc, but it turns out the bug was in hci_ldsic > >>all along where it was calling ->write() from within > >>->write_wakeup() callback. > >> > >>The problem is that ->write_wakeup() was called with > >>port lock held and ->write() tried to grab the same > >>port lock. > > > >Should this and the next patch be earlier in the series > >as a fix for the v3.15-rc cycle? Should they be cc: stable > >as well? > > Well, right now the other fix has had _zero_ testing > so not really a -stable candidate just yet. how can you even say that ? Unless you work for some 3 letter acronym organizations, you have no clue about the fact that this was tested on a keystone 2 platform. How else would we have found the issue to start with ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 09/11] bluetooth: hci_ldisc: fix deadlock condition
On 03/26/2014 10:09 PM, Felipe Balbi wrote: I just noticed this patch wasn't addressed to Marcel; seems like this should go through the bluetooth tree (but not through bluetooth-next because it fixes an oops). read the archives: http://marc.info/?l=linux-bluetooth&m=139534449409583&w=2 Sorry. I did actually get Marcel's reply but Thunderbird didn't parent the reply properly in my inbox and I forgot about it. Marcel, You may want to build on top of this patch split handling; I noticed some of the protocol drivers are calling hci_uart_tx_wakeup() from work functions already (so don't need to schedule another work...) I don't think that should be part of $subject, though. I don't understand what you mean here. Regards, Peter Hurley -- 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 10/11] Revert "serial: omap: unlock the port lock"
On 03/26/2014 10:10 PM, Felipe Balbi wrote: Hi, On Wed, Mar 26, 2014 at 08:39:11PM -0400, Peter Hurley wrote: On 03/25/2014 02:28 PM, Tony Lindgren wrote: * Felipe Balbi [140320 12:39]: This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e. That commit tried to fix a deadlock problem when using hci_ldisc, but it turns out the bug was in hci_ldsic all along where it was calling ->write() from within ->write_wakeup() callback. The problem is that ->write_wakeup() was called with port lock held and ->write() tried to grab the same port lock. Should this and the next patch be earlier in the series as a fix for the v3.15-rc cycle? Should they be cc: stable as well? Well, right now the other fix has had _zero_ testing so not really a -stable candidate just yet. how can you even say that ? I misunderstood when you wrote: On 03/20/2014 02:11 PM, Felipe Balbi wrote: > here's a build-tested only patch which is waiting for testing from other > colleagues who've got a platform to reproduce the problem: and then the version I reviewed had no Tested-by: tags. Unless you work for some 3 letter acronym organizations, you have no clue about the fact that this was tested on a keystone 2 platform. Ok. How else would we have found the issue to start with ? Bug report? Regards, Peter Hurley -- 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 10/11] Revert "serial: omap: unlock the port lock"
On 03/25/2014 02:28 PM, Tony Lindgren wrote: * Felipe Balbi [140320 12:39]: This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e. That commit tried to fix a deadlock problem when using hci_ldisc, but it turns out the bug was in hci_ldsic all along where it was calling ->write() from within ->write_wakeup() callback. The problem is that ->write_wakeup() was called with port lock held and ->write() tried to grab the same port lock. Should this and the next patch be earlier in the series as a fix for the v3.15-rc cycle? Should they be cc: stable as well? Well, right now the other fix has had _zero_ testing so not really a -stable candidate just yet. -- 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 09/11] bluetooth: hci_ldisc: fix deadlock condition
Hi, On Wed, Mar 26, 2014 at 10:20:15PM -0400, Peter Hurley wrote: > >>You may want to build on top of this patch split handling; > >>I noticed some of the protocol drivers are calling > >>hci_uart_tx_wakeup() from work functions already (so don't > >>need to schedule another work...) > > > >I don't think that should be part of $subject, though. > > I don't understand what you mean here. it seemed, at first, like you suggested to redo this patch modifying the protocol drivers to avoid two workqueues. But now that I read it again you _did_ write "on top of this patch". -- balbi signature.asc Description: Digital signature
Re: [PATCH 10/11] Revert "serial: omap: unlock the port lock"
Hi, On Wed, Mar 26, 2014 at 10:27:13PM -0400, Peter Hurley wrote: > On 03/26/2014 10:10 PM, Felipe Balbi wrote: > >Hi, > > > >On Wed, Mar 26, 2014 at 08:39:11PM -0400, Peter Hurley wrote: > >>On 03/25/2014 02:28 PM, Tony Lindgren wrote: > >>>* Felipe Balbi [140320 12:39]: > This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e. > > That commit tried to fix a deadlock problem when using > hci_ldisc, but it turns out the bug was in hci_ldsic > all along where it was calling ->write() from within > ->write_wakeup() callback. > > The problem is that ->write_wakeup() was called with > port lock held and ->write() tried to grab the same > port lock. > >>> > >>>Should this and the next patch be earlier in the series > >>>as a fix for the v3.15-rc cycle? Should they be cc: stable > >>>as well? > >> > >>Well, right now the other fix has had _zero_ testing > >>so not really a -stable candidate just yet. > > > >how can you even say that ? > > I misunderstood when you wrote: > > On 03/20/2014 02:11 PM, Felipe Balbi wrote: > > here's a build-tested only patch which is waiting for testing from other > > colleagues who've got a platform to reproduce the problem: > > and then the version I reviewed had no Tested-by: tags. I wouldn't add that tag myself, but Murali (in Cc) did help testing together with other colleagues. > >How else would we have found the issue to start with ? > > Bug report? touchè :-) -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Wednesday, March 26, 2014 10:58 PM, Kishon Vijay Abraham I wrote:
>
> Added support for pcie controller in dra7xx. This driver re-uses
> the designware core code that is already present in kernel.
>
> Signed-off-by: Kishon Vijay Abraham I
Hi Kishon,
Long time no see! I added trivial comments.
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
> drivers/pci/host/Kconfig | 10 +
> drivers/pci/host/Makefile|1 +
> drivers/pci/host/pcie-dra7xx.c | 411
> ++
How about using 'pci-' prefix?
As it was discussed earlier, 'pci-' prefix is more proper.
> 4 files changed, 457 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
> create mode 100644 drivers/pci/host/pcie-dra7xx.c
[.]
> --- /dev/null
> +++ b/drivers/pci/host/pcie-dra7xx.c
[.]
> +#define PCIECTRL_TI_CONF_IRQSTATUS_MAIN 0x0024
> +#define PCIECTRL_TI_CONF_IRQENABLE_SET_MAIN 0x0028
I don't think that it's good to add vendor names such as TI
to SFR names.
How about adding 'DRA7XX' or just removing 'TI'?
1. PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN
2. PCIECTRL_CONF_IRQSTATUS_MAIN
[.]
> +enum dra7xx_pcie_device_type {
> + DRA7XX_PCIE_UNKNOWN_TYPE,
> + DRA7XX_PCIE_EP_TYPE,
> + DRA7XX_PCIE_LEG_EP_TYPE,
> + DRA7XX_PCIE_RC_TYPE,
> +};
This driver can support only RC mode, so, these enum can be removed.
[.]
> + of_property_read_u32(node, "ti,device-type", &device_type);
> + switch (device_type) {
> + case DRA7XX_PCIE_RC_TYPE:
> + dra7xx_pcie_writel(dra7xx->base,
> + PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_RC);
> + break;
> + case DRA7XX_PCIE_EP_TYPE:
> + dra7xx_pcie_writel(dra7xx->base,
> + PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_EP);
> + break;
> + case DRA7XX_PCIE_LEG_EP_TYPE:
> + dra7xx_pcie_writel(dra7xx->base,
> + PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_LEG_EP);
> + break;
> + default:
> + dev_dbg(dev, "UNKNOWN device type %d\n", device_type);
> + }
Thus, this switch can be removed.
Others look good.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Thursday 27 March 2014 09:13 AM, Jingoo Han wrote:
> On Wednesday, March 26, 2014 10:58 PM, Kishon Vijay Abraham I wrote:
>>
>> Added support for pcie controller in dra7xx. This driver re-uses
>> the designware core code that is already present in kernel.
>>
>> Signed-off-by: Kishon Vijay Abraham I
>
> Hi Kishon,
> Long time no see! I added trivial comments.
yeah, these were in my TODO for a long time. Sorry for it though.
>
>> ---
>> Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
>> drivers/pci/host/Kconfig | 10 +
>> drivers/pci/host/Makefile|1 +
>> drivers/pci/host/pcie-dra7xx.c | 411
>> ++
>
> How about using 'pci-' prefix?
> As it was discussed earlier, 'pci-' prefix is more proper.
>
>> 4 files changed, 457 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
>> create mode 100644 drivers/pci/host/pcie-dra7xx.c
>
> [.]
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-dra7xx.c
>
> [.]
>
>> +#define PCIECTRL_TI_CONF_IRQSTATUS_MAIN 0x0024
>> +#define PCIECTRL_TI_CONF_IRQENABLE_SET_MAIN 0x0028
>
> I don't think that it's good to add vendor names such as TI
> to SFR names.
>
> How about adding 'DRA7XX' or just removing 'TI'?
>
> 1. PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN
ok.
>
> 2. PCIECTRL_CONF_IRQSTATUS_MAIN
>
> [.]
>
>> +enum dra7xx_pcie_device_type {
>> +DRA7XX_PCIE_UNKNOWN_TYPE,
>> +DRA7XX_PCIE_EP_TYPE,
>> +DRA7XX_PCIE_LEG_EP_TYPE,
>> +DRA7XX_PCIE_RC_TYPE,
>> +};
>
> This driver can support only RC mode, so, these enum can be removed.
>
> [.]
>
>> +of_property_read_u32(node, "ti,device-type", &device_type);
>> +switch (device_type) {
>> +case DRA7XX_PCIE_RC_TYPE:
>> +dra7xx_pcie_writel(dra7xx->base,
>> +PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_RC);
>> +break;
>> +case DRA7XX_PCIE_EP_TYPE:
>> +dra7xx_pcie_writel(dra7xx->base,
>> +PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_EP);
>> +break;
>> +case DRA7XX_PCIE_LEG_EP_TYPE:
>> +dra7xx_pcie_writel(dra7xx->base,
>> +PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_LEG_EP);
>> +break;
>> +default:
>> +dev_dbg(dev, "UNKNOWN device type %d\n", device_type);
>> +}
>
> Thus, this switch can be removed.
sure.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
