Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964979AbbBDJwJ (ORCPT ); Wed, 4 Feb 2015 04:52:09 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:61438 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964915AbbBDJwA (ORCPT ); Wed, 4 Feb 2015 04:52:00 -0500 X-AuditID: cbfee68e-f79b46d000002b74-1b-54d1ebbe033f Message-id: <54D1EBBE.9050505@samsung.com> Date: Wed, 04 Feb 2015 18:51:58 +0900 From: Jaehoon Chung User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-version: 1.0 To: Paul Osmialowski , Chris Ball , Ulf Hansson , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Dooks Subject: Re: [PATCH RESEND] mmc: sdhci-s3c: solve problem with sleeping in atomic context References: <1423041419-31522-1-git-send-email-p.osmialowsk@samsung.com> In-reply-to: <1423041419-31522-1-git-send-email-p.osmialowsk@samsung.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42JZI2JSpLvv9cUQg9XNahbLT39msZhweTuj xeVdc9gsjvzvZ7SY8OYAs8XxteEObB53ru1h87jxaiGTR9+WVYwe599MZfH4vEkugDWKyyYl NSezLLVI3y6BK2P3paesBTc1K158/M/WwNit3MXIySEhYCJx9/F7FghbTOLCvfVsXYxcHEIC SxklNi54zw5T1PJjLQtEYhGjxM/lF5lBEkICrxklLv/zA7F5BbQker49Ze1i5OBgEVCVaPtd ARJmE9CR2P7tOBOILSoQJjHx5mNWiHJBiR+T74HNFBE4zyhx+t40sCuEBaIlzrzYyw4x30Oi be95sGZOAU+JWzO6mUHmMwvoSdy/qAUSZhaQl9i85i0zyBwJgX3sEufWrGAESbAICEh8m3yI BaReQkBWYtMBZohfJCUOrrjBMoFRdBaSM2YhTJ2FZOoCRuZVjKKpBckFxUnpRUZ6xYm5xaV5 6XrJ+bmbGIHxdPrfs74djDcPWB9iFOBgVOLhFci/GCLEmlhWXJl7iNEU6IiJzFKiyfnAqM0r iTc0NjOyMDUxNTYytzRTEudNkPoZLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGRdUnJZ36r aXoiomqurhtnC5/5NNPoaKocq//lkKUHFpw7c1RoSoVm/Mri40v7r1RIzX+hcPnlvyP3A1Ni e+55Rh0J/SbxYaJJ1f/m2vNzl9/VsSidsvbsViZtt13TjyUdPz3zUbfVE4d3OrNUrtw+EXSb rXLD7YqzddeOqSxYYJDwxvSXh/4lVyWW4oxEQy3mouJEAINVWHKiAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsVy+t9jAd19ry+GGFw6IWux/PRnFosJl7cz WlzeNYfN4sj/fkaLCW8OMFscXxvuwOZx59oeNo8brxYyefRtWcXocf7NVBaPz5vkAlijGhht MlITU1KLFFLzkvNTMvPSbZW8g+Od403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AuUFIoS8wp BQoFJBYXK+nbYZoQGuKmawHTGKHrGxIE12NkgAYS1jBm7L70lLXgpmbFi4//2RoYu5W7GDk5 JARMJFp+rGWBsMUkLtxbz9bFyMUhJLCIUeLn8ovMIAkhgdeMEpf/+YHYvAJaEj3fnrJ2MXJw sAioSrT9rgAJswnoSGz/dpwJxBYVCJOYePMxK0S5oMSPyfdYQGaKCJxnlDh9bxrYMmGBaIkz L/ayQ8z3kGjbex6smVPAU+LWjG5mkPnMAnoS9y9qgYSZBeQlNq95yzyBkX8WkrGzEKpmIala wMi8ilE0tSC5oDgpPddIrzgxt7g0L10vOT93EyM4Wp9J72Bc1WBxiFGAg1GJh1cg/2KIEGti WXFl7iFGCQ5mJRHe6mNAId6UxMqq1KL8+KLSnNTiQ4ymQD9PZJYSTc4HJpK8knhDYxMzI0sj c0MLI2NzJXFeJfu2ECGB9MSS1OzU1ILUIpg+Jg5OqQbGme1NTofvKJkvcPw0r7Zlo3Gk4Hn2 XXqXHperC/4w2Lv//qQHnOyWm8xtp165uJMjN2HWfoeanfo5/+RtF2m4Pat4bztd13B3/OPF tw4cSzGNmipQnu+/mqvj3BF2jYoFrIn+fbNjnvSmzF3vUFKyLmjGs9hdCg8u10i2Xms+mbAy NPWz3JNpSizFGYmGWsxFxYkAewIlYOwCAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5485 Lines: 102 Hi. Tested-by: Jaehoon Chung (with exynos4 board) Acked-by: Jaehoon Chung Best Regards, Jaehoon Chung On 02/04/2015 06:16 PM, Paul Osmialowski wrote: > This change addresses following problem: > > [ 2.560726] ------------[ cut here ]------------ > [ 2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744 lockdep_trace_alloc+0xec/0x118() > [ 2.574439] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > [ 2.579821] Modules linked in: > [ 2.583038] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.18.0-next-20141216-00002-g4ff197fc1902-dirty #1318 > [ 2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 2.599892] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [ 2.607612] [] (show_stack) from [] (dump_stack+0x70/0xbc) > [ 2.614822] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0) > [ 2.622885] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40) > [ 2.631569] [] (warn_slowpath_fmt) from [] (lockdep_trace_alloc+0xec/0x118) > [ 2.640246] [] (lockdep_trace_alloc) from [] (__kmalloc+0x3c/0x1cc) > [ 2.648240] [] (__kmalloc) from [] (clk_fetch_parent_index+0xb8/0xd4) > [ 2.656390] [] (clk_fetch_parent_index) from [] (clk_calc_new_rates+0xe0/0x1fc) > [ 2.665415] [] (clk_calc_new_rates) from [] (clk_calc_new_rates+0x1b4/0x1fc) > [ 2.674181] [] (clk_calc_new_rates) from [] (clk_set_rate+0x50/0xc8) > [ 2.682265] [] (clk_set_rate) from [] (sdhci_cmu_set_clock+0x68/0x16c) > [ 2.690503] [] (sdhci_cmu_set_clock) from [] (sdhci_do_set_ios+0xf0/0x64c) > [ 2.699095] [] (sdhci_do_set_ios) from [] (sdhci_set_ios+0x20/0x2c) > [ 2.707080] [] (sdhci_set_ios) from [] (mmc_power_up+0x118/0x1fc) > [ 2.714889] [] (mmc_power_up) from [] (mmc_start_host+0x44/0x6c) > [ 2.722615] [] (mmc_start_host) from [] (mmc_add_host+0x58/0x7c) > [ 2.730341] [] (mmc_add_host) from [] (sdhci_add_host+0x968/0xd94) > [ 2.738240] [] (sdhci_add_host) from [] (sdhci_s3c_probe+0x354/0x52c) > [ 2.746406] [] (sdhci_s3c_probe) from [] (platform_drv_probe+0x48/0xa4) > [ 2.754733] [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x37c) > [ 2.763585] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98) > [ 2.772003] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88) > [ 2.780163] [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200) > [ 2.788322] [] (bus_add_driver) from [] (driver_register+0x78/0xf4) > [ 2.796308] [] (driver_register) from [] (do_one_initcall+0xac/0x1f0) > [ 2.804473] [] (do_one_initcall) from [] (kernel_init_freeable+0x10c/0x1d8) > [ 2.813153] [] (kernel_init_freeable) from [] (kernel_init+0x28/0x108) > [ 2.821398] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) > [ 2.828939] ---[ end trace 03cc00e539849d1f ]--- > > clk_set_rate() tries to take clk's prepare_lock mutex while being in atomic > context entered in sdhci_do_set_ios(). > > The solution is inspired by similar situation in sdhci_set_power() also called > from sdhci_do_set_ios(): > > spin_unlock_irq(&host->lock); > mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd); > spin_lock_irq(&host->lock); > > Note that since sdhci_s3c_set_clock() sets SDHCI_CLOCK_CARD_EN, proposed change > first resets this bit. It is reset anyway (by setting SDHCI_CLOCK_INT_EN bit > only) after call to clk_set_rate() in order to wait for the clock to stabilize > and is set again as soon as the clock becomes stable. > > Signed-off-by: Paul Osmialowski > --- > drivers/mmc/host/sdhci-s3c.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c > index c45b893..115f556 100644 > --- a/drivers/mmc/host/sdhci-s3c.c > +++ b/drivers/mmc/host/sdhci-s3c.c > @@ -12,6 +12,7 @@ > * published by the Free Software Foundation. > */ > > +#include > #include > #include > #include > @@ -312,7 +313,14 @@ static void sdhci_cmu_set_clock(struct sdhci_host *host, unsigned int clock) > > sdhci_s3c_set_clock(host, clock); > > + /* Reset SD Clock Enable */ > + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL); > + clk &= ~SDHCI_CLOCK_CARD_EN; > + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL); > + > + spin_unlock_irq(&host->lock); > ret = clk_set_rate(ourhost->clk_bus[ourhost->cur_clk], clock); > + spin_lock_irq(&host->lock); > if (ret != 0) { > dev_err(dev, "%s: failed to set clock rate %uHz\n", > mmc_hostname(host->mmc), clock); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/