[PATCH 1/1] ARM: dts: dra7-evm: fix qspi device tree partition size
64KiB is allocated for qspi dtb partition which is not
sufficient, so updating the partition table size to 512KiB
for device tree partition.
This also aligns the QSPI partition definitions between
kernel and U-Boot.
Fixes: dc2dd5b8 (ARM: dts: dra7: Add qspi device)
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
This patch is tested on Linux next and the boot logs at [1]
[1] - http://pastebin.ubuntu.com/9567672/
---
arch/arm/boot/dts/dra7-evm.dts | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 736092b..235d001 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -499,23 +499,23 @@
};
partition@5 {
label = QSPI.u-boot-spl-os;
- reg = 0x0014 0x0001;
+ reg = 0x0014 0x0008;
};
partition@6 {
label = QSPI.u-boot-env;
- reg = 0x0015 0x0001;
+ reg = 0x001c 0x0001;
};
partition@7 {
label = QSPI.u-boot-env.backup1;
- reg = 0x0016 0x001;
+ reg = 0x001d 0x001;
};
partition@8 {
label = QSPI.kernel;
- reg = 0x0017 0x080;
+ reg = 0x001e 0x080;
};
partition@9 {
label = QSPI.file-system;
- reg = 0x0097 0x0169;
+ reg = 0x009e 0x0162;
};
};
};
--
2.2.1.62.g3f15098
--
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+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Lokesh, On 19/12/14 07:21, Lokesh Vutla wrote: Hi Roger, On Thursday 18 December 2014 09:22 PM, Roger Quadros wrote: Fixing up Paul's email id. cheers, -roger On 18/12/14 17:49, Roger Quadros wrote: There are quite a few hwmods that don't have sysconfig register and so _find_mpu_rt_port(oh) will return NULL thus preventing ready state check on those modules after the module is enabled. This can potentially cause a bus access error if the module is accessed before the module is ready. Get rid of the redundant _find_mpu_rt_port() check from the _wait_target_ready() funcion for all the SoCs. The following PRCM register access that checks the module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port. Yes, makes sense. This patch looks good to me. Tested this on AM437x-gp-evm. Tested-by: Lokesh Vutla lokeshvu...@ti.com Thanks. May be good idea to warn every time if enabling of module is failed? Unrelated to this patch though. Yes, failing to be ready is serious enough for a warning. Care to send a separate patch for that? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] CLK: TI: OMAP4: remove 'dss_fck' alias
'dss_fck' clock was recently removed, but a clock alias for it was left.
This causes a warning:
ti_dt_clocks_register: failed to lookup clock node dss_fck
Remove the unneeded clock alias.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/clk-44xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index 35a0f01bbaf4..b1169e87e2d4 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -126,7 +126,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, dss_tv_clk, dss_tv_clk),
DT_CLK(NULL, dss_dss_clk, dss_dss_clk),
DT_CLK(NULL, dss_48mhz_clk, dss_48mhz_clk),
- DT_CLK(NULL, dss_fck, dss_fck),
DT_CLK(NULL, fdif_fck, fdif_fck),
DT_CLK(NULL, gpio1_dbclk, gpio1_dbclk),
DT_CLK(NULL, gpio2_dbclk, gpio2_dbclk),
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] CLK: TI: remove 'ick' alias for 'omapdss_dss' device
The omapdss_dss driver has not used 'ick' clock for a long time, and
thus the clock alias for 'ick' is not needed and can be removed.
On OMAP4 the 'dss_fck' clock was recently removed, and as 'ick' was an
alias for 'dss_fck', it causes a warning:
ti_dt_clocks_register: failed to lookup clock node dss_fck
This patch removes that warning.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/clk-2xxx.c | 1 -
drivers/clk/ti/clk-3xxx.c | 2 --
drivers/clk/ti/clk-44xx.c | 1 -
3 files changed, 4 deletions(-)
diff --git a/drivers/clk/ti/clk-2xxx.c b/drivers/clk/ti/clk-2xxx.c
index c808ab3d2bb2..e3656851b2e0 100644
--- a/drivers/clk/ti/clk-2xxx.c
+++ b/drivers/clk/ti/clk-2xxx.c
@@ -48,7 +48,6 @@ static struct ti_dt_clk omap2xxx_clks[] = {
DT_CLK(NULL, gfx_3d_fck, gfx_3d_fck),
DT_CLK(NULL, gfx_2d_fck, gfx_2d_fck),
DT_CLK(NULL, gfx_ick, gfx_ick),
- DT_CLK(omapdss_dss, ick, dss_ick),
DT_CLK(NULL, dss_ick, dss_ick),
DT_CLK(NULL, dss1_fck, dss1_fck),
DT_CLK(NULL, dss2_fck, dss2_fck),
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 0d1750a8aea4..2ff8b60f62f3 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -265,7 +265,6 @@ static struct ti_dt_clk omap3430es1_clks[] = {
DT_CLK(NULL, ssi_ick, ssi_ick_3430es1),
DT_CLK(NULL, usb_l4_ick, usb_l4_ick),
DT_CLK(NULL, dss1_alwon_fck, dss1_alwon_fck_3430es1),
- DT_CLK(omapdss_dss, ick, dss_ick_3430es1),
DT_CLK(NULL, dss_ick, dss_ick_3430es1),
{ .node_name = NULL },
};
@@ -284,7 +283,6 @@ static struct ti_dt_clk
omap36xx_am35xx_omap3430es2plus_clks[] = {
DT_CLK(NULL, mmchs3_ick, mmchs3_ick),
DT_CLK(NULL, mmchs3_fck, mmchs3_fck),
DT_CLK(NULL, dss1_alwon_fck, dss1_alwon_fck_3430es2),
- DT_CLK(omapdss_dss, ick, dss_ick_3430es2),
DT_CLK(NULL, dss_ick, dss_ick_3430es2),
DT_CLK(NULL, usbhost_120m_fck, usbhost_120m_fck),
DT_CLK(NULL, usbhost_48m_fck, usbhost_48m_fck),
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index 02517a8206bd..35a0f01bbaf4 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -127,7 +127,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, dss_dss_clk, dss_dss_clk),
DT_CLK(NULL, dss_48mhz_clk, dss_48mhz_clk),
DT_CLK(NULL, dss_fck, dss_fck),
- DT_CLK(omapdss_dss, ick, dss_fck),
DT_CLK(NULL, fdif_fck, fdif_fck),
DT_CLK(NULL, gpio1_dbclk, gpio1_dbclk),
DT_CLK(NULL, gpio2_dbclk, gpio2_dbclk),
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bluetooth: Add hci_h4p driver
Hi!
And you want to set the QUIRK_INVALID_BADDR. At least you want to do that in
the final submission.
Ok, I found out that I can do it and result works, provided that I do
hciconfig hci0 up/down first.
I have trouble understanding... h4p_hci_open() seems to be called as
soon as I insmod the driver. Who does that? Is it some kind of udev
magic?
...
+#include hci_h4p.h
+
+#define BT_DBG(a...) do {} while(0)
Why is this needed? BT_DBG is hooked up with dynamic debug.
...
I did all the changes as requested. Thanks. I did't see harm in
include guards, but I removed them; it is not important.
+ if (info-rx_count == 0) {
+ /* H4+ devices should always send word aligned packets */
+ if (!(info-rx_skb-len % 2))
+ info-garbage_bytes++;
+ h4p_recv_frame(info, info-rx_skb);
The h4p_recv_frame should maybe done inline here since it only handles 2
exception packets. Also to make it easy, just leave the function if
(info-rx_count).
This packet processing feels like a bit of spaghetti code. I think that is
better handled in a proper function that goes through it and not with many
tiny sub functions.
Well, CodingStyle says something about functions that should be kept
short... And when manually inlined, the inner function would have to
be made less readable, as it uses return to shortcut processing.
To use __hci_cmd_sync()
+
+ SET_HCIDEV_DEV(hdev, info-dev);
+
+ if (hci_register_dev(hdev) = 0)
+ return 0;
+
+ dev_err(info-dev, hci_register failed %s.\n, hdev-name);
+ hci_free_dev(info-hdev);
+ return -ENODEV;
+}
And normally this is folded into the probe handling and not in a
separate function.
The probe function is too long, already...
+#include linux/delay.h
+#include linux/clk.h
+
+#include linux/io.h
+
+#include hci_h4p.h
Why is this a separate file? And if so, why not all UART specific details are
in this file. Including bunch of the defines you have in the header.
Well, you wanted less global functions, so I moved some as inlines to
headers. I guess I can merge nokia_core and nokia_uart if really wanted.
I did rest of requested changes.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: bluetooth: Add hci_h4p driver
Hi Pavel,
And you want to set the QUIRK_INVALID_BADDR. At least you want to do that in
the final submission.
Ok, I found out that I can do it and result works, provided that I do
hciconfig hci0 up/down first.
that should not be the case. Actually hciconfig uses old ioctl. A full
Bluetooth system running bluetoothd (from BlueZ 5) will never use any old
ioctl. Only an old system (BlueZ 4) will use ioctl.
I have trouble understanding... h4p_hci_open() seems to be called as
soon as I insmod the driver. Who does that? Is it some kind of udev
magic?
As soon as you do hci_register_dev, it will bring up the device and run the
basic initialization. That is needed to get the address, version information
and features. Otherwise the mgmt interface can not work. We need basic
information about the device.
So what the kernel will do internally when you find a device is bring it up,
get the basics and then bring it back down (in case nobody uses it). See
hci_power_on work.
...
+#include hci_h4p.h
+
+#define BT_DBG(a...) do {} while(0)
Why is this needed? BT_DBG is hooked up with dynamic debug.
...
I did all the changes as requested. Thanks. I did't see harm in
include guards, but I removed them; it is not important.
There is no harm in including the guards. We just don't do it for internal
files. And thus if anyone tries to be sneaky and build circular inclusion they
will fall flat on their faces. That is the only reason.
+ if (info-rx_count == 0) {
+ /* H4+ devices should always send word aligned packets */
+ if (!(info-rx_skb-len % 2))
+ info-garbage_bytes++;
+ h4p_recv_frame(info, info-rx_skb);
The h4p_recv_frame should maybe done inline here since it only handles 2
exception packets. Also to make it easy, just leave the function if
(info-rx_count).
This packet processing feels like a bit of spaghetti code. I think that is
better handled in a proper function that goes through it and not with many
tiny sub functions.
Well, CodingStyle says something about functions that should be kept
short... And when manually inlined, the inner function would have to
be made less readable, as it uses return to shortcut processing.
It also should not make me have to follow 3 functions to figure out what it is
actually doing.
To use __hci_cmd_sync()
+
+ SET_HCIDEV_DEV(hdev, info-dev);
+
+ if (hci_register_dev(hdev) = 0)
+ return 0;
+
+ dev_err(info-dev, hci_register failed %s.\n, hdev-name);
+ hci_free_dev(info-hdev);
+ return -ENODEV;
+}
And normally this is folded into the probe handling and not in a
separate function.
The probe function is too long, already...
Have you compared it to other functions. Normally probe() functions in general
are all pretty long since they have to do tons of stuff. Having all in one
function means you can read through it at once.
+#include linux/delay.h
+#include linux/clk.h
+
+#include linux/io.h
+
+#include hci_h4p.h
Why is this a separate file? And if so, why not all UART specific details
are in this file. Including bunch of the defines you have in the header.
Well, you wanted less global functions, so I moved some as inlines to
headers. I guess I can merge nokia_core and nokia_uart if really wanted.
Would this become easier when some of the OMAP specific stuff is moved out of
this driver? If that is possible.
Regards
Marcel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc
On 3 December 2014 at 00:42, Doug Anderson diand...@chromium.org wrote: Bing Zhao at Marvell found a problem with dw_mmc where interrupts weren't firing sometimes. He tracked it down to a read-modify-write problem with the INTMASK. These patches fix the problem. Note: I've picked up a 1-year old series here to make another attempt at landing it upstream. These patches have been in shipping Chromebooks for the last year. Note that v3 to v4 has no changes other than a rebase and a small commit message update. The first two patches extend the init_card() mechanism of MMC core to actually be called for all card types, not just SDIO. That could be applied any time and should fix at least one longstanding bug (untested). The third patch is a cleanup patch to use init_card() to move things around a bit so we don't need to handle SDIO cards in such a strange place. On earlier versions of this patch Seungwon brought up a few points which I have _not_ addressed. See https://patchwork.kernel.org/patch/3049071/. Other than talk of cards with out of band interrupts maybe being able to gate their clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING. I didn't do that because of the ordering of init_card() and when the quirks are set. Some users of init_card() like pandora_wl1251_init_card() rely on it being called very early in the process. pandora_wl1251_init_card() hardcodes a vendor and device and thus need to be called super early. On the other hand the code that adds quirks _reads_ the vendor and device. It can't possibly move before init_card(). If folks are willing to take an additional host op of init_card_late() I can certainly go that way, though. The fourth patch is (I think) reviewed and ready to go assuming the other two land. I have queued this up for 3.20. It was a bit hard to follow the updated the revisions, please don't send patches in-reply-to for future sets. In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4. Kind regards Uffe Changes in v5: - Split fixup to pandora_wl1251_init_card() into its own patch. Changes in v3: - Add fixup to pandora_wl1251_init_card(). Changes in v2: - mmc core change new for this version. - Fixed | to . - intmask_lock renamed to irq_lock Doug Anderson (4): ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only mmc: core: Support the optional init_card() callback for MMC and SD mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock arch/arm/mach-omap2/board-omap3pandora.c | 14 +++--- drivers/mmc/core/mmc.c | 6 +++ drivers/mmc/core/sd.c| 7 ++- drivers/mmc/host/dw_mmc.c| 80 +++- drivers/mmc/host/dw_mmc.h| 1 + include/linux/mmc/dw_mmc.h | 6 +++ 6 files changed, 74 insertions(+), 40 deletions(-) -- 2.2.0.rc0.207.ga3a616c -- 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/2] ARM: OMAP DSS hwmod reset fix
Hi, Here are similar patches for AM43xx and DRA7xxx than was done earlier for OMAP4/5 in 543b2847d4bdb07eb1b50003095bc65cf2a1e2c0 (ARM: OMAP4: hwmod: set DSS submodule parent hwmods) and 9ed69650897e8738c959fe8242ec41499f3f3f35 (ARM: OMAP5: hwmod: set DSS submodule parent hwmods) I don't think missing the reset causes any problems, but the boot time warnings are annoying. Tomi Tomi Valkeinen (2): ARM: AM43xx: hwmod: set DSS submodule parent hwmods ARM: DRA7xx: hwmod: set DSS submodule parent hwmods arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++ 2 files changed, 4 insertions(+) -- 2.2.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: AM43xx: hwmod: set DSS submodule parent hwmods
Set DSS core hwmod as the parent for all the DSS submodules. This fixes
the boot time DSS reset, removing the following warnings:
omap_hwmod: dss_dispc: cannot be enabled for reset (3)
omap_hwmod: dss_rfbi: cannot be enabled for reset (3)
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c8410160e..8eb85925e444 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -498,6 +498,7 @@ static struct omap_hwmod am43xx_dss_dispc_hwmod = {
},
},
.dev_attr = am43xx_dss_dispc_dev_attr,
+ .parent_hwmod = am43xx_dss_core_hwmod,
};
/* rfbi */
@@ -512,6 +513,7 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
.clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
},
},
+ .parent_hwmod = am43xx_dss_core_hwmod,
};
/* Interfaces */
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: DRA7xx: hwmod: set DSS submodule parent hwmods
Set DSS core hwmod as the parent for all the DSS submodules. This fixes
the boot time DSS reset, removing the following warnings:
omap_hwmod: dss_dispc: cannot be enabled for reset (3)
omap_hwmod: dss_hdmi: cannot be enabled for reset (3)
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index ffd6604cd546..41238d509cb5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -500,6 +500,7 @@ static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
},
},
.dev_attr = dss_dispc_dev_attr,
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
@@ -541,6 +542,7 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
--
2.2.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
Hi Everybody, After several test with IGEPv2 board (OMAP3) and linux kernel 3.17 and 3.18, the OTG works but, (from my point of view) with an weird behaviour. The OTG like a Host only is activated after load a gadget driver, I mean that, If I plug a USB memory dongle in the OTG port before load a Gadget driver like g_ether the dongle is not recognized. After load g_ether driver, the usb dongle is recognized without problems. I miss something in the configuration? It this the normal behaviour? Best Regards Eduard 2014-12-17 11:18 GMT+01:00 Agustà Fontquerni a...@iseebcn.com: Hi everybody, We are working on IGEPv2 board about OTG issue. 2014-11-19 18:53 GMT+01:00 Tony Lindgren t...@atomide.com: * Enric Balletbo Serra eballe...@gmail.com [141119 03:14]: 2014-11-18 16:42 GMT+01:00 Tony Lindgren t...@atomide.com: Checked again, and no luck. It's very weird because from the OTG point of view, OTG is exactly the same between Beagleboard-XM and IGEPv2. Can you confirm that you're using kernel 3.18-rc5 without other patches applied ? At this moment, I don't have a Beagleboard-XM to test, I'll try to get one because at this moment I'm a bit stuck with this problem. Yes it was with v3.18-rc5 and the defconfig patch I posted except I had to disable all the other MUSB platforms. Also tested it with built in modules. Maybe you need to check the .dts pinctrl entries for hsusb0_* lines? Command root@arm:/sys/kernel/debug/pinctrl# cat pinctrl-maps | grep -5 usb reports: device 480025a0.pinmux state default type MUX_GROUP (2) controlling device 480025a0.pinmux group pinmux_hsusbb1_pins function pinmux_hsusbb1_pins So, I think that is needed configure usb0 in lastest omap3-igep0020.dts Moreover, in old 2.6.37 kernel, we saw omap_mux pin configuration in /sys/kernel/debug/omap_mux/hsusb0_xxx. Now in newer 3.1x kernels, Where could it read omap_mux pin configuration ? Regards, Tony Best Regards, Agusti Fontquerni -- Eduard Gavin Carulla e: ega...@iseebcn.com t: +34 935 763 931 t: +34 935 763 932 www.isee.biz C/ Marcos Redondo, 5 Valldoreix CP. 08197 (Barcelona) - Spain Important notice: This message and any files transmitted with it are confidential and intended solely for the individual to whom it is addressed. Unauthorized publication, use, dissemination, forwarding, printing or copying of this email and its associated attachments is strictly prohibited. If you have received this email in error, please notify the sender and delete the original immediately. Thank you for your cooperation. -- 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] mmc: omap_hsmmc: use slot-gpio library for gpio support.
On 11 December 2014 at 22:43, NeilBrown ne...@suse.de wrote:
Using the common code removes some code duplication, and
makes it easier to switch to using mmc_of_parse() which
will remove more duplication.
As hsmmc has a slightly different interrupt service routine
for card-detect, enhance slot-gpio to allow an alternate
routine to be provided.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/mmc/core/slot-gpio.c | 24 ++-
drivers/mmc/host/omap_hsmmc.c | 67
+
include/linux/mmc/slot-gpio.h |2 +
3 files changed, 39 insertions(+), 54 deletions(-)
I like the looks of this patch, still I want the mmc core parts to be
separated into it's own patch. Can you please split this up.
Kind regards
Uffe
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 69bbf2adb329..f56323f5a996 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -23,6 +23,7 @@ struct mmc_gpio {
struct gpio_desc *cd_gpio;
bool override_ro_active_level;
bool override_cd_active_level;
+ irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
char *ro_label;
char cd_label[0];
};
@@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
irq = -EINVAL;
if (irq = 0) {
+ if (ctx-cd_gpio_isr == NULL)
+ ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
ret = devm_request_threaded_irq(host-class_dev, irq,
- NULL, mmc_gpio_cd_irqt,
+ NULL, ctx-cd_gpio_isr,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
ctx-cd_label, host);
if (ret 0)
@@ -171,6 +174,25 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
}
EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
+/* Register an alternate interrupt service routine for
+ * the card-detect GPIO.
+ */
+int mmc_gpio_request_cd_isr(struct mmc_host *host,
+ irqreturn_t (*isr)(int irq, void *dev_id))
+{
+ struct mmc_gpio *ctx;
+ int ret;
+
+ ret = mmc_gpio_alloc(host);
+ if (ret 0)
+ return ret;
+ ctx = host-slot.handler_priv;
+ if (ctx-cd_gpio_isr)
+ return -EBUSY;
+ ctx-cd_gpio_isr = isr;
+ return 0;
+}
+
/**
* mmc_gpio_request_cd - request a gpio for card-detection
* @host: mmc host
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 537cba8f1de1..32514b648e3c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/slot-gpio.h
#include linux/io.h
#include linux/irq.h
#include linux/gpio.h
@@ -251,28 +252,22 @@ static void omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host);
static int omap_hsmmc_card_detect(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host-pdata;
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-switch_pin);
+ return mmc_gpio_get_cd(host-mmc);
}
static int omap_hsmmc_get_wp(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host-pdata;
- /* NOTE: assumes write protect signal is active-high */
- return gpio_get_value_cansleep(mmc-gpio_wp);
+ return mmc_gpio_get_ro(host-mmc);
}
static int omap_hsmmc_get_cover_state(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host-pdata;
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-switch_pin);
+ return mmc_gpio_get_cd(host-mmc);
}
#ifdef CONFIG_REGULATOR
@@ -439,7 +434,10 @@ static inline int omap_hsmmc_have_reg(void)
#endif
-static int omap_hsmmc_gpio_init(struct omap_hsmmc_host *host,
+static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
+
+static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
+ struct omap_hsmmc_host *host,
struct omap_hsmmc_platform_data *pdata)
{
int ret;
@@ -452,46 +450,26 @@ static int omap_hsmmc_gpio_init(struct omap_hsmmc_host
*host,
host-card_detect = omap_hsmmc_card_detect;
host-card_detect_irq =
gpio_to_irq(pdata-switch_pin);
- ret = gpio_request(pdata-switch_pin, mmc_cd);
+ ret = mmc_gpio_request_cd_isr(mmc, omap_hsmmc_detect);
if (ret)
return ret;
-
Re: [PATCH 1/3] mmc: omap_hsmmc: remove prepare/complete system suspend support.
On 11 December 2014 at 22:43, NeilBrown ne...@suse.de wrote:
The only function of these 'prepare' and 'complete' is to
disable the 'card detect' irq during suspend.
The commit which added this,
commit a48ce884d5819d5df2cf1139ab3c43f8e9e419b3
mmc: omap_hsmmc: Introduce omap_hsmmc_prepare/complete
justified it by the need to avoid the registration of new devices
during suspend.
However mmc_pm_notify will set -rescan_disable in the 'prepare'
stage and clear it in the 'complete' stage, so no card detection
will actually happen.
Also the interrupt will be disabled before final suspend as part
of common suspend processing.
So this disabling of the interrupt is unnecessary, and interferes
with a transition to using common code for card-detect management.
Cc: Felipe Balbi ba...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Chris Ball c...@laptop.org
Signed-off-by: NeilBrown ne...@suse.de
Thanks! Queued for 3.20.
Kind regards
Uffe
---
drivers/mmc/host/omap_hsmmc.c | 50
include/linux/platform_data/mmc-omap.h |4 ---
2 files changed, 54 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7c71dcdcba8b..537cba8f1de1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -275,31 +275,6 @@ static int omap_hsmmc_get_cover_state(struct device *dev)
return !gpio_get_value_cansleep(mmc-switch_pin);
}
-#ifdef CONFIG_PM
-
-static int omap_hsmmc_suspend_cdirq(struct device *dev)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
- disable_irq(host-card_detect_irq);
- return 0;
-}
-
-static int omap_hsmmc_resume_cdirq(struct device *dev)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
- enable_irq(host-card_detect_irq);
- return 0;
-}
-
-#else
-
-#define omap_hsmmc_suspend_cdirq NULL
-#define omap_hsmmc_resume_cdirqNULL
-
-#endif
-
#ifdef CONFIG_REGULATOR
static int omap_hsmmc_set_power(struct device *dev, int power_on, int vdd)
@@ -2234,8 +2209,6 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
Unable to grab MMC CD IRQ\n);
goto err_irq_cd;
}
- host-suspend = omap_hsmmc_suspend_cdirq;
- host-resume = omap_hsmmc_resume_cdirq;
}
omap_hsmmc_disable_irq(host);
@@ -2322,25 +2295,6 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
}
#ifdef CONFIG_PM
-static int omap_hsmmc_prepare(struct device *dev)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
- if (host-suspend)
- return host-suspend(dev);
-
- return 0;
-}
-
-static void omap_hsmmc_complete(struct device *dev)
-{
- struct omap_hsmmc_host *host = dev_get_drvdata(dev);
-
- if (host-resume)
- host-resume(dev);
-
-}
-
static int omap_hsmmc_suspend(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -2398,8 +2352,6 @@ static int omap_hsmmc_resume(struct device *dev)
}
#else
-#define omap_hsmmc_prepare NULL
-#define omap_hsmmc_completeNULL
#define omap_hsmmc_suspend NULL
#define omap_hsmmc_resume NULL
#endif
@@ -2484,8 +2436,6 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
- .prepare= omap_hsmmc_prepare,
- .complete = omap_hsmmc_complete,
.runtime_suspend = omap_hsmmc_runtime_suspend,
.runtime_resume = omap_hsmmc_runtime_resume,
};
diff --git a/include/linux/platform_data/mmc-omap.h
b/include/linux/platform_data/mmc-omap.h
index 5c188f4e9bec..929469291406 100644
--- a/include/linux/platform_data/mmc-omap.h
+++ b/include/linux/platform_data/mmc-omap.h
@@ -31,10 +31,6 @@ struct omap_mmc_platform_data {
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
- /* To handle board related suspend/resume functionality for MMC */
- int (*suspend)(struct device *dev, int slot);
- int (*resume)(struct device *dev, int slot);
-
/* Return context loss count due to PM states changing */
int (*get_context_loss_count)(struct device *dev);
--
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/2] phy: ti-pipe3: fixes for 3.19-rc
Hi, During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain active on the DRA7 platform. This is because the pipe3 driver doesn't shut them off as part of .suspend(). Patch 1 addresses this issue. SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a system suspend/resume or if AHCI_PLATFORM driver is used as module. Patch 2 fixes it. Hope to get these 2 patches in through the 3.19-rc cycle. Tony, patch 2 touches dra7.dtsi and omap5.dts and will need your Ack. Hopefully it can go in through Kishon's PHY tree. cheers, -roger Roger Quadros (2): phy: ti-pipe3: Disable clocks on system suspend phy: ti-pipe3: Fix SATA across suspend/resume arch/arm/boot/dts/dra7.dtsi | 4 +- arch/arm/boot/dts/omap5.dtsi | 4 +- drivers/phy/phy-ti-pipe3.c | 138 +-- 3 files changed, 111 insertions(+), 35 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] phy: ti-pipe3: Disable clocks on system suspend
On system suspend, the runtime_suspend() driver hook doesn't get
called and so the clocks are not disabled in the driver.
This causes the L3INIT_960M_GFCLK and L3INIT_480M_GFCLK to remain
active on the DRA7 platform while in system suspend.
Add suspend/resume hooks to the driver.
In case of pcie-phy, the runtime_suspend hook gets called after
the suspend hook so we introduce a flag phy-enabled to keep
track if our clocks are enabled or not to prevent multiple
enable/disables.
Move enabling/disabling clock code into helper functions.
Reported-by: Nishant Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-ti-pipe3.c | 99 +++---
1 file changed, 77 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 1387b4d..e60ff14 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/phy/omap_control_phy.h
#include linux/of_platform.h
+#include linux/spinlock.h
#definePLL_STATUS 0x0004
#definePLL_GO 0x0008
@@ -83,6 +84,8 @@ struct ti_pipe3 {
struct clk *div_clk;
struct pipe3_dpll_map *dpll_map;
u8 id;
+ bool enabled;
+ spinlock_t lock;/* serialize clock enable/disable */
};
static struct pipe3_dpll_map dpll_map_usb[] = {
@@ -303,6 +306,7 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return -ENOMEM;
phy-dev= pdev-dev;
+ spin_lock_init(phy-lock);
if (!of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
match = of_match_device(of_match_ptr(ti_pipe3_id_table),
@@ -425,24 +429,14 @@ static int ti_pipe3_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
-static int ti_pipe3_runtime_suspend(struct device *dev)
+static int ti_pipe3_enable_clocks(struct ti_pipe3 *phy)
{
- struct ti_pipe3 *phy = dev_get_drvdata(dev);
-
- if (!IS_ERR(phy-wkupclk))
- clk_disable_unprepare(phy-wkupclk);
- if (!IS_ERR(phy-refclk))
- clk_disable_unprepare(phy-refclk);
- if (!IS_ERR(phy-div_clk))
- clk_disable_unprepare(phy-div_clk);
-
- return 0;
-}
+ int ret = 0;
+ unsigned long flags;
-static int ti_pipe3_runtime_resume(struct device *dev)
-{
- u32 ret = 0;
- struct ti_pipe3 *phy = dev_get_drvdata(dev);
+ spin_lock_irqsave(phy-lock, flags);
+ if (phy-enabled)
+ goto err1;
if (!IS_ERR(phy-refclk)) {
ret = clk_prepare_enable(phy-refclk);
@@ -467,6 +461,9 @@ static int ti_pipe3_runtime_resume(struct device *dev)
goto err3;
}
}
+
+ phy-enabled = true;
+ spin_unlock_irqrestore(phy-lock, flags);
return 0;
err3:
@@ -478,19 +475,77 @@ err2:
clk_disable_unprepare(phy-refclk);
err1:
+ spin_unlock_irqrestore(phy-lock, flags);
+ return ret;
+}
+
+static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(phy-lock, flags);
+ if (!phy-enabled) {
+ spin_unlock_irqrestore(phy-lock, flags);
+ return;
+ }
+
+ if (!IS_ERR(phy-wkupclk))
+ clk_disable_unprepare(phy-wkupclk);
+ if (!IS_ERR(phy-refclk))
+ clk_disable_unprepare(phy-refclk);
+ if (!IS_ERR(phy-div_clk))
+ clk_disable_unprepare(phy-div_clk);
+ phy-enabled = false;
+ spin_unlock_irqrestore(phy-lock, flags);
+}
+
+static int ti_pipe3_runtime_suspend(struct device *dev)
+{
+ struct ti_pipe3 *phy = dev_get_drvdata(dev);
+
+ ti_pipe3_disable_clocks(phy);
+ return 0;
+}
+
+static int ti_pipe3_runtime_resume(struct device *dev)
+{
+ struct ti_pipe3 *phy = dev_get_drvdata(dev);
+ int ret = 0;
+
+ ret = ti_pipe3_enable_clocks(phy);
return ret;
}
+static int ti_pipe3_suspend(struct device *dev)
+{
+ struct ti_pipe3 *phy = dev_get_drvdata(dev);
+
+ ti_pipe3_disable_clocks(phy);
+ return 0;
+}
+
+static int ti_pipe3_resume(struct device *dev)
+{
+ struct ti_pipe3 *phy = dev_get_drvdata(dev);
+ int ret;
+
+ ret = ti_pipe3_enable_clocks(phy);
+ if (ret)
+ return ret;
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ return 0;
+}
+#endif
+
static const struct dev_pm_ops ti_pipe3_pm_ops = {
SET_RUNTIME_PM_OPS(ti_pipe3_runtime_suspend,
ti_pipe3_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(ti_pipe3_suspend, ti_pipe3_resume)
};
-#define DEV_PM_OPS (ti_pipe3_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif
-
#ifdef CONFIG_OF
static const struct of_device_id
[PATCH 2/2] phy: ti-pipe3: Fix SATA across suspend/resume
Failed test case: Boot without SATA drive connected. Suspend/resume
the board and then connect SATA drive. It fails to enumerate.
Due to Errata i783 SATA Lockup After SATA DPLL Unlock/Relock
we can't allow SATA DPLL to be in the unlocked state.
The SATA refclk (sata_ref_clk) is the source of the SATA_DPLL.
Till now this clock was controlled by the AHCI SATA driver and was being
shut off during system suspend (if the SATA drive was not already attached)
causing the SATA DPLL to be unlocked and so causing errata i783.
To prevent sata_ref_clk from being disabled, we move the control of
this clock from the SATA AHCI driver to the SATA PHY driver and prevent
it from being disabled.
This also fixes the issue of SATA not working on OMAP5/DRA7 when
AHCI platform driver is built as a module.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
arch/arm/boot/dts/omap5.dtsi | 4 ++--
drivers/phy/phy-ti-pipe3.c | 53 +++-
3 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 63bf99b..8c35b84 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1090,8 +1090,8 @@
0x4A096800 0x40; /* pll_ctrl */
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_sata;
- clocks = sys_clkin1;
- clock-names = sysclk;
+ clocks = sys_clkin1, sata_ref_clk;
+ clock-names = sysclk, refclk;
#phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b321fdf..bb498e7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -929,8 +929,8 @@
0x4A096800 0x40; /* pll_ctrl */
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_sata;
- clocks = sys_clkin;
- clock-names = sysclk;
+ clocks = sys_clkin, sata_ref_clk;
+ clock-names = sysclk, refclk;
#phy-cells = 0;
};
};
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index e60ff14..e08edd9 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -85,6 +85,7 @@ struct ti_pipe3 {
struct pipe3_dpll_map *dpll_map;
u8 id;
bool enabled;
+ bool refclk_enabled;/* this flag is needed specifically for SATA */
spinlock_t lock;/* serialize clock enable/disable */
};
@@ -333,21 +334,20 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
}
+ phy-refclk = devm_clk_get(phy-dev, refclk);
+ if (IS_ERR(phy-refclk)) {
+ dev_err(pdev-dev, unable to get refclk\n);
+ return PTR_ERR(phy-refclk);
+ }
+
if (!of_device_is_compatible(node, ti,phy-pipe3-sata)) {
phy-wkupclk = devm_clk_get(phy-dev, wkupclk);
if (IS_ERR(phy-wkupclk)) {
dev_err(pdev-dev, unable to get wkupclk\n);
return PTR_ERR(phy-wkupclk);
}
-
- phy-refclk = devm_clk_get(phy-dev, refclk);
- if (IS_ERR(phy-refclk)) {
- dev_err(pdev-dev, unable to get refclk\n);
- return PTR_ERR(phy-refclk);
- }
} else {
phy-wkupclk = ERR_PTR(-ENODEV);
- phy-refclk = ERR_PTR(-ENODEV);
}
if (of_device_is_compatible(node, ti,phy-pipe3-pcie)) {
@@ -428,6 +428,29 @@ static int ti_pipe3_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM
+static int ti_pipe3_enable_refclk(struct ti_pipe3 *phy)
+{
+ if (!IS_ERR(phy-refclk) !phy-refclk_enabled) {
+ int ret;
+
+ ret = clk_prepare_enable(phy-refclk);
+ if (ret) {
+ dev_err(phy-dev, Failed to enable refclk %d\n, ret);
+ return ret;
+ }
+ phy-refclk_enabled = true;
+ }
+
+ return 0;
+}
+
+static void ti_pipe3_disable_refclk(struct ti_pipe3 *phy)
+{
+ if (!IS_ERR(phy-refclk))
+ clk_disable_unprepare(phy-refclk);
+
+ phy-refclk_enabled = false;
+}
static int ti_pipe3_enable_clocks(struct ti_pipe3 *phy)
{
@@ -438,13 +461,9 @@ static int ti_pipe3_enable_clocks(struct ti_pipe3 *phy)
if (phy-enabled)
goto err1;
- if (!IS_ERR(phy-refclk)) {
- ret =
[PATCH] ARM: OMAP2+: hwmod: print error if wait_target_ready() failed
Fixed pr_debug to pr_err when hwmod returns an error when enabling a module. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index cbb908d..06157af 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2155,8 +2155,8 @@ static int _enable(struct omap_hwmod *oh) if (soc_ops.disable_module) soc_ops.disable_module(oh); _disable_clocks(oh); - pr_debug(omap_hwmod: %s: _wait_target_ready: %d\n, -oh-name, r); + pr_err(omap_hwmod: %s: _wait_target_ready failed: %d\n, + oh-name, r); if (oh-clkdm) clkdm_hwmod_disable(oh-clkdm, oh); -- 1.9.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: regression: Clock changes in next-20141205 break at least omap4
On Wed, 17 Dec 2014, Tero Kristo wrote: The dual parent issue required by the DPLL code is caused by the introduction of determine-rate / set-parent / set-rate-and-parent logic to OMAP DPPLs. I took a short-cut here, making the assumption that every DPLL has both of these clocks defined (which basically they do have, as every DPLL technically has both reference and bypass clocks, but which can be the same clock = thus the declaration itself is missing in some cases.) The clock data is modelled like this for every other TI SoC (which use DT clock data), except for omap3 legacy clock data, thus the patch to tweak the clock data itself. It would be much harder to modify the clock code itself to take this into account, rather than just add the missing parents to the clock data, thus the approach taken in the patch. We can of course discuss whether it is okay to have DPLLs modelled as they are right now. I think them as composite clocks containing mux, gate and divider/multiplier logic within a single black box, we could split them up, but I don't see much need for that. If it works, don't break it. Regarding the omap3 clock data patch, I have also just posted new patch set that will move the omap3 legacy clock data under clock driver, until we figure out what to finally do with this (use the DT clocks, or introduce loadable clock data modules or something.) Thus, the data patch is kind of a temporary one, or thats the intention at least, but I wouldn't call it a hack. It is there to fix the issues introduced by the set-parent / set-rate-and-parent logic, which was required by the changes to the core clock set-rate. OK, I understand now why the OMAP3 clock DT data takes two of the same clock - one is for the reference and one is for bypass. So I retract my earlier statement about it being a hack, and am fine with Tero's original patch. I suppose I should resuscitate the uImage booter for the OMAP3 boards here at least. I dropped those out of the testbed thinking that we'd switch over to DT-only fairly quickly; that turned out not to be the case. - 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
Re: [PATCH v5 0/4] Fixes for SDIO interrupts for dw_mmc
Ulf, On Fri, Dec 19, 2014 at 2:17 AM, Ulf Hansson ulf.hans...@linaro.org wrote: On 3 December 2014 at 00:42, Doug Anderson diand...@chromium.org wrote: Bing Zhao at Marvell found a problem with dw_mmc where interrupts weren't firing sometimes. He tracked it down to a read-modify-write problem with the INTMASK. These patches fix the problem. Note: I've picked up a 1-year old series here to make another attempt at landing it upstream. These patches have been in shipping Chromebooks for the last year. Note that v3 to v4 has no changes other than a rebase and a small commit message update. The first two patches extend the init_card() mechanism of MMC core to actually be called for all card types, not just SDIO. That could be applied any time and should fix at least one longstanding bug (untested). The third patch is a cleanup patch to use init_card() to move things around a bit so we don't need to handle SDIO cards in such a strange place. On earlier versions of this patch Seungwon brought up a few points which I have _not_ addressed. See https://patchwork.kernel.org/patch/3049071/. Other than talk of cards with out of band interrupts maybe being able to gate their clocks, he wanted to use MMC_QUIRK_BROKEN_CLK_GATING. I didn't do that because of the ordering of init_card() and when the quirks are set. Some users of init_card() like pandora_wl1251_init_card() rely on it being called very early in the process. pandora_wl1251_init_card() hardcodes a vendor and device and thus need to be called super early. On the other hand the code that adds quirks _reads_ the vendor and device. It can't possibly move before init_card(). If folks are willing to take an additional host op of init_card_late() I can certainly go that way, though. The fourth patch is (I think) reviewed and ready to go assuming the other two land. I have queued this up for 3.20. Thanks! It was a bit hard to follow the updated the revisions, please don't send patches in-reply-to for future sets. Very strange. I didn't send out anything in-reply-to other than what git-send-email usually does. I believe I had: [0] - no in reply to. [1] - in reply to [0] [2] - in reply to [0] [3] - in reply to [0] [4] - in reply to [0] Is there some other way you'd prefer? Looking full headers in https://patchwork.kernel.org/patch/5425241/, I confirm it is in-reply-to 1417563767-32181-1-git-send-email-diand...@chromium.org. Patchwork doesn't keep cover letters, but you can see at http://www.spinics.net/lists/linux-mmc/msg29699.html) that there is no in-reply-to. I'm more than happy to adjust my workflow if you can give me some specifics. Thanks! :) In v5, I don't find a patch 1/4. Anyway, I have taken patch 2-4. Ah, maybe because it wasn't sent to linux-mmc? I messed that up and will try to do better in the future. Sorry. :( You were in the To line, though. You can see at https://patchwork.kernel.org/patch/5425241/. Do you want me to repost it and CC linux-mmc with Tony's Ack? --- Note: patchwork seems to find all my patches: pwclient list -w diand...@chromium.org -p 5425241 New [v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only 5425291 New [v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only 5425311 New [v5,1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only 5425231 New [v5,2/4] mmc: core: Support the optional init_card() callback for MMC and SD 5425301 New [v5,2/4] mmc: core: Support the optional init_card() callback for MMC and SD 5425271 New [v5,3/4] mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts 5425281 New [v5,3/4] mmc: dw_mmc: Cleanup disable of low power mode w/ SDIO interrupts 5425251 New [v5,4/4] mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock 5425261 New [v5,4/4] mmc: dw_mmc: Protect read-modify-write of INTMASK with a lock -- 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
linux-next: add the omap-pending tree
Hi Stephen, Might you be willing to include this branch in your linux-next builds? git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git#for-next It will include OMAP clock, bus architecture, and low-level power management patches that are planned to be included in pull requests to the OMAP upstream maintainer, Tony Lindgren. He in turn will submit pull requests to the arm-soc tree. The objective in including this branch is to get these patches integration-tested earlier than they would be otherwise. regards, - 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
Re: linux-next: add the omap-pending tree
* Paul Walmsley p...@pwsan.com [141219 11:30]: Hi Stephen, Might you be willing to include this branch in your linux-next builds? git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git#for-next It will include OMAP clock, bus architecture, and low-level power management patches that are planned to be included in pull requests to the OMAP upstream maintainer, Tony Lindgren. He in turn will submit pull requests to the arm-soc tree. The objective in including this branch is to get these patches integration-tested earlier than they would be otherwise. Makes sense to me. The delay in getting omap stuff into Linux next via arm-soc for-next is just too long because of the large number of pending pull requests for various ARM SoCs. While at it, can you please also (re-)add omap for-next too: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git#for-next 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] ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode
If the boot loader enables HYP mode on the boot CPU, the secondary CPU also needs to call into the ROM to switch to HYP mode before booting. The firmwares on the omap5 and dra7xx unfortunately do not take care of this, so it has to be handled by the kernel. This patch is based on [PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs by Santosh Shilimkar santosh.shilim...@ti.com, except this version does not require a compile time CONFIG to control if it should enable HYP mode or not, it simply does it based on the mode of the boot CPU, so it works whether the CPU boots in SVC or HYP mode, and should even work as a guest kernel inside kvm if qemu decides to support emulating the omap5 or dra7xx. Signed-off-by: Len Sorensen lsore...@csclub.uwaterloo.ca --- arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/omap-headsmp.S | 21 + arch/arm/mach-omap2/omap-smp.c | 13 +++-- 3 files changed, 33 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 377eea8..db57741 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -249,6 +249,7 @@ extern void omap4_cpu_die(unsigned int cpu); extern struct smp_operations omap4_smp_ops; extern void omap5_secondary_startup(void); +extern void omap5_secondary_hyp_startup(void); #endif #if defined(CONFIG_SMP) defined(CONFIG_PM) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 4993d4b..6d1dffc 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -22,6 +22,7 @@ /* Physical address needed since MMU not enabled yet on secondary core */ #define AUX_CORE_BOOT0_PA 0x48281800 +#define API_HYP_ENTRY 0x102 /* * OMAP5 specific entry point for secondary CPU to jump from ROM @@ -41,6 +42,26 @@ wait:ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 b secondary_startup ENDPROC(omap5_secondary_startup) /* + * Same as omap5_secondary_startup except we call into the ROM to + * enable HYP mode first. This is called instead of + * omap5_secondary_startup if the primary CPU was put into HYP mode by + * the boot loader. + */ +ENTRY(omap5_secondary_hyp_startup) +wait_2:ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 + ldr r0, [r2] + mov r0, r0, lsr #5 + mrc p15, 0, r4, c0, c0, 5 + and r4, r4, #0x0f + cmp r0, r4 + bne wait_2 + ldr r12, =API_HYP_ENTRY + adr r0, hyp_boot + smc #0 +hyp_boot: + b secondary_startup +ENDPROC(omap5_secondary_hyp_startup) +/* * OMAP4 specific entry point for secondary CPU to jump from ROM * code. This routine also provides a holding flag into which * secondary core is held until we're ready for it to initialise. diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c index 256e84e..5305ec7 100644 --- a/arch/arm/mach-omap2/omap-smp.c +++ b/arch/arm/mach-omap2/omap-smp.c @@ -22,6 +22,7 @@ #include linux/irqchip/arm-gic.h #include asm/smp_scu.h +#include asm/virt.h #include omap-secure.h #include omap-wakeupgen.h @@ -227,8 +228,16 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus) if (omap_secure_apis_support()) omap_auxcoreboot_addr(virt_to_phys(startup_addr)); else - writel_relaxed(virt_to_phys(omap5_secondary_startup), - base + OMAP_AUX_CORE_BOOT_1); + /* +* If the boot CPU is in HYP mode then start secondary +* CPU in HYP mode as well. +*/ + if ((__boot_cpu_mode MODE_MASK) == HYP_MODE) + writel_relaxed(virt_to_phys(omap5_secondary_hyp_startup), + base + OMAP_AUX_CORE_BOOT_1); + else + writel_relaxed(virt_to_phys(omap5_secondary_startup), + base + OMAP_AUX_CORE_BOOT_1); } -- 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 2b/3] mmc: omap_hsmmc: use slot-gpio library for gpio support.
Using the common code removes some code duplication, and
makes it easier to switch to using mmc_of_parse() which
will remove more duplication.
This uses the new mmc_gpio_request_cd_isr to provide a non-standard
interrupt service routine for card-detect interrupts.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/mmc/host/omap_hsmmc.c | 67 +
1 file changed, 14 insertions(+), 53 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 537cba8f1de1..32514b648e3c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -36,6 +36,7 @@
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
+#include linux/mmc/slot-gpio.h
#include linux/io.h
#include linux/irq.h
#include linux/gpio.h
@@ -251,28 +252,22 @@ static void omap_hsmmc_start_dma_transfer(struct
omap_hsmmc_host *host);
static int omap_hsmmc_card_detect(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host-pdata;
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-switch_pin);
+ return mmc_gpio_get_cd(host-mmc);
}
static int omap_hsmmc_get_wp(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host-pdata;
- /* NOTE: assumes write protect signal is active-high */
- return gpio_get_value_cansleep(mmc-gpio_wp);
+ return mmc_gpio_get_ro(host-mmc);
}
static int omap_hsmmc_get_cover_state(struct device *dev)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- struct omap_hsmmc_platform_data *mmc = host-pdata;
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-switch_pin);
+ return mmc_gpio_get_cd(host-mmc);
}
#ifdef CONFIG_REGULATOR
@@ -439,7 +434,10 @@ static inline int omap_hsmmc_have_reg(void)
#endif
-static int omap_hsmmc_gpio_init(struct omap_hsmmc_host *host,
+static irqreturn_t omap_hsmmc_detect(int irq, void *dev_id);
+
+static int omap_hsmmc_gpio_init(struct mmc_host *mmc,
+ struct omap_hsmmc_host *host,
struct omap_hsmmc_platform_data *pdata)
{
int ret;
@@ -452,46 +450,26 @@ static int omap_hsmmc_gpio_init(struct omap_hsmmc_host
*host,
host-card_detect = omap_hsmmc_card_detect;
host-card_detect_irq =
gpio_to_irq(pdata-switch_pin);
- ret = gpio_request(pdata-switch_pin, mmc_cd);
+ ret = mmc_gpio_request_cd_isr(mmc, omap_hsmmc_detect);
if (ret)
return ret;
- ret = gpio_direction_input(pdata-switch_pin);
+ ret = mmc_gpio_request_cd(mmc, pdata-switch_pin, 0);
if (ret)
- goto err_free_sp;
+ return ret;
} else {
pdata-switch_pin = -EINVAL;
}
if (gpio_is_valid(pdata-gpio_wp)) {
host-get_ro = omap_hsmmc_get_wp;
- ret = gpio_request(pdata-gpio_wp, mmc_wp);
- if (ret)
- goto err_free_cd;
- ret = gpio_direction_input(pdata-gpio_wp);
+ ret = mmc_gpio_request_ro(mmc, pdata-gpio_wp);
if (ret)
- goto err_free_wp;
+ return ret;
} else {
pdata-gpio_wp = -EINVAL;
}
return 0;
-
-err_free_wp:
- gpio_free(pdata-gpio_wp);
-err_free_cd:
- if (gpio_is_valid(pdata-switch_pin))
-err_free_sp:
- gpio_free(pdata-switch_pin);
- return ret;
-}
-
-static void omap_hsmmc_gpio_free(struct omap_hsmmc_host *host,
-struct omap_hsmmc_platform_data *pdata)
-{
- if (gpio_is_valid(pdata-gpio_wp))
- gpio_free(pdata-gpio_wp);
- if (gpio_is_valid(pdata-switch_pin))
- gpio_free(pdata-switch_pin);
}
/*
@@ -2066,7 +2044,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host-next_data.cookie = 1;
host-pbias_enabled = 0;
- ret = omap_hsmmc_gpio_init(host, pdata);
+ ret = omap_hsmmc_gpio_init(mmc, host, pdata);
if (ret)
goto err_gpio;
@@ -2197,20 +2175,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
- /* Request IRQ for card detect */
- if (host-card_detect_irq) {
- ret = devm_request_threaded_irq(pdev-dev,
- host-card_detect_irq,
- NULL, omap_hsmmc_detect,
- IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING
[PATCH 2a/3] mmc: core: Allow host driver to provide isr for card-detect interrupts.
One of the reasons omap_hsmmc doesn't use the slot-gpio library
is that it has some non-standard functionality in the card-detect
interrupt service routine.
To make it possible for omap_hsmmc (and maybe others) to be converted
to use slot-gpio, add 'mmc_gpio_request_cd_isr' which provide an
alternate isr to be register by the slot-gpio code.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/mmc/core/slot-gpio.c | 24 +++-
include/linux/mmc/slot-gpio.h |2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
This and following are the result of splitting the previous
'2/3' into to patches: core and omap_hsmmc as requested.
NeilBrown
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 69bbf2adb329..f56323f5a996 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -23,6 +23,7 @@ struct mmc_gpio {
struct gpio_desc *cd_gpio;
bool override_ro_active_level;
bool override_cd_active_level;
+ irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
char *ro_label;
char cd_label[0];
};
@@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
irq = -EINVAL;
if (irq = 0) {
+ if (ctx-cd_gpio_isr == NULL)
+ ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
ret = devm_request_threaded_irq(host-class_dev, irq,
- NULL, mmc_gpio_cd_irqt,
+ NULL, ctx-cd_gpio_isr,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
ctx-cd_label, host);
if (ret 0)
@@ -171,6 +174,25 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
}
EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
+/* Register an alternate interrupt service routine for
+ * the card-detect GPIO.
+ */
+int mmc_gpio_request_cd_isr(struct mmc_host *host,
+ irqreturn_t (*isr)(int irq, void *dev_id))
+{
+ struct mmc_gpio *ctx;
+ int ret;
+
+ ret = mmc_gpio_alloc(host);
+ if (ret 0)
+ return ret;
+ ctx = host-slot.handler_priv;
+ if (ctx-cd_gpio_isr)
+ return -EBUSY;
+ ctx-cd_gpio_isr = isr;
+ return 0;
+}
+
/**
* mmc_gpio_request_cd - request a gpio for card-detection
* @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index e56fa24c9322..9e55db60deb0 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -28,6 +28,8 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char
*con_id,
int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
unsigned int idx, bool override_active_level,
unsigned int debounce, bool *gpio_invert);
+int mmc_gpio_request_cd_isr(struct mmc_host *host,
+ irqreturn_t (*isr)(int irq, void *dev_id));
void mmc_gpiod_free_cd(struct mmc_host *host);
void mmc_gpiod_request_cd_irq(struct mmc_host *host);
--
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
