From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Shawn Lin <shawn.lin@rock-chips.com>,
bcm-kernel-feedback-list@broadcom.com,
linux-rpi-kernel@lists.infradead.org,
linux-mmc <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
P L Sai Krishna <lakshmi.sai.krishna.potthuri@xilinx.com>,
Wan Zongshun <vincent.wan@amd.com>
Subject: Re: [RFC PATCH 0/21] Totally remove SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk
Date: Thu, 28 Jan 2016 16:27:37 +0000 [thread overview]
Message-ID: <20160128162736.GK10826@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAPDyKFoBdJ-5sXyJpTNxDJVJSUA+Gsjc+0+uLedNZCHYcF+rvQ@mail.gmail.com>
On Thu, Jan 28, 2016 at 04:16:27PM +0100, Ulf Hansson wrote:
> That's really great news. Thank you very much Adrian!
>
> Perhaps Russell is willing to help co-maintain it?
Unfortunately, I'm not really in a position to co-maintain it, as
I'd be doing it in my spare time, and my spare time is already
spread thinly over much of the kernel (I've crypto, phy/sfp,
etnaviv drm, xf86-video-armada, etnaviv mesa, HDMI CEC, and DSA
stuff all wanting attention, and I'm having to tell people "sorry,
I won't be able to do anything on XYZ for a while".) I'm quite
sure the Marvell Dove maintainers are going to want some more
patches from me for the next merge window soon...
Of course, that could change if Linaro wishes to fund work in this
area, because it would then take priority... ;)
I'm more than willing to put whatever time I can into helping with
SDHCI, which is exactly why you get the occasional large series of
patches from me - the whole reason behind these patch series are to
improve SDHCI in an incremental fashion. However, I'd be lying if
I didn't say that there's an alterior motive behind it, which is to
get SDHCI on iMX6 stable. What I realise is that the current
situation is quite dire, and SDHCI needs improving if we're not
going to decend into a totally unmaintainable mess.
Just before Christmas, I was working on a way to change the way we
kick off commands in SDHCI in order to clean up those paths - the
patches which follow on from the 25 I've already posted, and are:
mmc: sdhci: move interrupt enable settings to task
mmc: sdhci: move command and argument to sdhci_cmd_task
mmc: sdhci: move block size and block count into sdhci task structure
mmc: sdhci: compute transfer mode separately from programming it
mmc: sdhci: replace 'set_timeout' method with 'calculate_timeout'
mmc: sdhci: validate command response type
mmc: sdhci: clean up
mmc: sdhci: rearrange sdhci_set_transfer_mode() a little
It's a work-in-progress, which is why I haven't posted these yet.
The outline of it is that we (currently) end up with:
+struct sdhci_cmd_task {
+ bool has_argument2;
+ bool has_data;
+ u32 ier;
+ u32 argument2;
+ u16 block_size;
+ u16 block_count;
+ u32 argument;
+ u16 transfer_mode;
+ u16 command;
+};
+
which allows separation of the preparation step for a MMC command from
touching the hardware - this means that quirkly SDHCI drivers can do
this instead of litering the core code with quirk tests:
struct sdhci_cmd_task task;
sdhci_prepare_command(sdhci, &task, mmc_command);
/* do whatever quirks */
sdhci_execute_command(sdhci, &task);
This structure means that (eg) some of the quirks such as
SDHCI_QUIRK2_SUPPORT_SINGLE,
SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD (which I'm sure is
actually a bug in the SDHCI driver) and eventually
SDHCI_QUIRK_BROKEN_TIMEOUT_VAL can all be eliminated from the core
code and moved out into their respective drivers - because we have
the core code preparing "the standard" set of register settings for
the command to be sent, and then the driver gets the opportunity to
tweak them according to the bugs it has.
... and even after all these changes, I still haven't solved the
problems which bugs me on iMX6, which were my motivation for coming
back to putting some more effort into SDHCI! :p
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2016-01-28 16:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 5:05 Shawn Lin
2016-01-27 5:06 ` [RFC PATCH 01/21] mmc: sdhci-pltfm: consolidate parsing path Shawn Lin
2016-01-27 5:06 ` [RFC PATCH 02/21] mmc: sdhci-iproc: " Shawn Lin
2016-01-27 5:06 ` [RFC PATCH 03/21] mmc: sdhci-msm: " Shawn Lin
2016-01-27 5:06 ` [RFC PATCH 04/21] mmc: sdhci-of-arasan: " Shawn Lin
2016-01-27 5:06 ` [RFC PATCH 05/21] mmc: sdhci-of-at91: " Shawn Lin
2016-01-27 5:07 ` [RFC PATCH 06/21] mmc: sdhci-of-esdhc: " Shawn Lin
2016-01-27 5:07 ` [RFC PATCH 07/21] mmc: sdhci-pxav3: " Shawn Lin
2016-01-27 5:44 ` Jisheng Zhang
2016-01-27 6:17 ` Shawn Lin
2016-01-27 5:07 ` [RFC PATCH 08/21] mmc: sdhci-sirf: check sdhci_get_of_property return value Shawn Lin
2016-01-27 5:07 ` [RFC PATCH 09/21] mmc: sdhci_f_sdh30: " Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 10/21] mmc: sdhci: remove SDHCI_QUIRK_BROKEN_CARD_DETECTION Shawn Lin
2016-01-27 7:11 ` Haibo Chen
2016-01-27 7:20 ` Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 11/21] mmc: sdhci-acpi: " Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 12/21] mmc: sdhci-bcm-kona: " Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 13/21] mmc: sdhci-bcm2835: " Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 14/21] mmc: sdhci-esdhc-imx: " Shawn Lin
2016-01-27 6:54 ` Haibo Chen
2016-01-27 6:58 ` Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 15/21] mmc: sdhci-msm: " Shawn Lin
2016-01-27 5:08 ` [RFC PATCH 16/21] mmc: sdhci-of-esdhc: " Shawn Lin
2016-01-27 5:09 ` [RFC PATCH 17/21] mmc: sdhci-pci-core: " Shawn Lin
2016-01-27 5:09 ` [RFC PATCH 18/21] mmc: sdhci-pltfm: " Shawn Lin
2016-01-27 5:09 ` [RFC PATCH 19/21] mmc: sdhci-pxav2: " Shawn Lin
2016-01-27 5:09 ` [RFC PATCH 20/21] mmc: sdhci-s3c: " Shawn Lin
2016-01-27 5:09 ` [RFC PATCH 21/21] mmc: sdhci.h: " Shawn Lin
2016-01-27 12:59 ` [RFC PATCH 0/21] Totally remove SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk Adrian Hunter
2016-01-27 13:23 ` Russell King - ARM Linux
2016-01-27 15:07 ` Ulf Hansson
2016-01-28 2:17 ` Shawn Lin
2016-01-28 11:29 ` One Thousand Gnomes
2016-01-28 15:03 ` Ulf Hansson
2016-01-28 15:54 ` One Thousand Gnomes
2016-01-28 12:03 ` Adrian Hunter
2016-01-28 15:16 ` Ulf Hansson
2016-01-28 16:27 ` Russell King - ARM Linux [this message]
2016-01-29 12:08 ` Adrian Hunter
2016-01-29 17:28 ` Russell King - ARM Linux
2016-02-01 12:32 ` Adrian Hunter
-- strict thread matches above, loose matches on Subject: below --
2016-01-27 5:04 Shawn Lin
2016-02-04 10:40 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160128162736.GK10826@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=adrian.hunter@intel.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=lakshmi.sai.krishna.potthuri@xilinx.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=shawn.lin@rock-chips.com \
--cc=ulf.hansson@linaro.org \
--cc=vincent.wan@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®