Re: [RFC 0/6] mmc: Field Firmware Update

[Olof Johansson]

[sigh, in cleartext this time.]


2015-12-22 0:57 GMT-08:00 Ulf Hansson :
> + Olof (forgot to add him last time)
>
> On 22 December 2015 at 09:55, Ulf Hansson  wrote:
>> + Gwendal, Grant, Olof, Seshagiri, Jon
>>
>> On 22 December 2015 at 09:15, Holger Schurig  wrote:
>>>
 Sorry for the delay.
>>>
>>> No problem, I was busy with many other projects as well.
>>>
 My advise right now is to try this out via the mmc ioctl in userspace,
 yes. Although, if you encounter any issues with that approach that it
 might not be reliable, I am open to look into the in-kernel solution
 again.
>>>
>>> I managed to update my Kingston eMMCs with a slighly modified patch to
>>> what I submitted. I however didn't bother to submit this, as I saw no
>>> chance of getting it applied.
>>>
>>> Also I once asked in the mailing list if there is some user-space
>>> example of how to use the multi-block feature that is supposed to enable
>>> this, but I haven't gotten an answer.
>>>
 Regarding mmc-utils as where I recommend you to implement this, I have
 been thinking of moving this tool into the tools directory in the
 kernel.
>>>
>>> Sounds good to me.
>>>
>>>
>>>
>>> Remotely related:
>>>
>>> Do you know that some google people made their own version of mmc-utils
>>> for ChromeOS?

"Make their own version" makes it sound like we've rewritten it. We
haven't. We've applied some patches locally over the last two years
based on work we've done for our products. It's not a deep fork.

We'd be happy to upstream them if there's interest from other users
and maintainers.

>> Perhaps by moving the code into the kernel tools dir and finding
>> someone who actively wants to maintain it, will enable improved
>> upstream activities!?


Hmm. If there's a well-defined userspace interface there's little
reason to bundle it directly, and I think that's the case here.

Chris has been busy with other stuff the last couple of years, is
there a lot of mmc-utils code that's out there that hasn't been picked
up?


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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] mmc: block: Add new ioctl to send combo commands

[Olof Johansson]

Hi,

On Wed, Sep 2, 2015 at 7:21 AM, Jon Hunter  wrote:
> From: Seshagiri Holi 
>
> Certain eMMC devices allow vendor specific device information to be read
> via a sequence of vendor commands. These vendor commands must be issued
> in sequence and an atomic fashion. One way to support this would be to
> add an ioctl function for sending a sequence of commands to the device
> atomically as proposed here. These combo commands are simple array of
> the existing mmc_ioc_cmd structure.

This seems reasonable to me, being able to do a sequence of
back-to-back operations without system read/writes slipping through.



> diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
> index 1f5e68923929..5943e51f22b3 100644
> --- a/include/uapi/linux/mmc/ioctl.h
> +++ b/include/uapi/linux/mmc/ioctl.h
> @@ -45,8 +45,23 @@ struct mmc_ioc_cmd {
>  };
>  #define mmc_ioc_cmd_set_data(ic, ptr) ic.data_ptr = (__u64)(unsigned long) 
> ptr
>
> -#define MMC_IOC_CMD _IOWR(MMC_BLOCK_MAJOR, 0, struct mmc_ioc_cmd)
> +/**
> + * struct mmc_ioc_combo_cmd - combo command information
> + * @num_of_cmds: number of commands to send
> + * @mmc_ioc_cmd_list: pointer to list of commands
> + */
> +struct mmc_ioc_combo_cmd {
> +   uint8_t num_of_cmds;
> +   struct mmc_ioc_cmd *mmc_ioc_cmd_list;
> +};

The size of this struct will depend on the pointer size of userspace.

It might be better to use a u64 for the pointer instead. Otherwise
you'd need a compat ioctl wrapper to copy a 32-bit pointer over on a
64-bit kernel.



-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

[Olof Johansson]

Hi,

On Thu, Aug 27, 2015 at 2:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Now return error only if the return value of
 devm_regulator_get_optional() is not the same as -ENODEV, since with
 -EPROBE_DEFER, the regulator can be obtained later and all other
 errors are fatal.

 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 Tested-by: Tony Lindgren t...@atomide.com

I bisected boot failures on Panda ES with multi_v7_defconfig down to
this commit on last night's -next build:

http://arm-soc.lixom.net/bootlogs/next/next-20150828/pandaes-arm-multi_v7_defconfig.html

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: dw_mmc: fix bug that cause mmc_test failture

[Olof Johansson]

Hi Addy,

On Mon, Jan 26, 2015 at 4:04 AM, Addy Ke addy...@rock-chips.com wrote:
 The STOP command can terminate a data transfer between a memory card and
 mmc controller.

 As show in Synopsys DesignWare Cores Mobile Stroage Host Databook:
 Data timeout and Data end-bit error will terminate further data transfer
 by mmc controller. So we should not send abort command to terminate a
 data transfer again if we got DRTO and EBE interrupt.

 After this patch, all mmc_test cases can pass on RK3288-Pink2 board.

 Signed-off-by: Addy Ke addy...@rock-chips.com

The drawback of having so many people on your to: list on a patch is
that it's unclear who you want to review and merge it. Sometimes less
is more.

In this case, it seems appropriate to have Ulf do so. Ulf, ping? This
seems like a reasonable patch for 3.20 given that it fixes undesired
behavior.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file

[Olof Johansson]

Hi,

On Thu, Nov 27, 2014 at 2:41 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 include/linux/platform_data/ is not a correct place to keep the API
 definitions for edma, it is meant to be only for the pdata for the device.
 Clean up this by moving the API to include/linux/edma.h

It's a nice net improvement, but it moves some things that should be
in _neither_ location to a new place where it doesn't belong either --
and the new location is even more global. See below.

...

 diff --git a/include/linux/edma.h b/include/linux/edma.h
 new file mode 100644
 index ..9df92198c117
 --- /dev/null
 +++ b/include/linux/edma.h
 @@ -0,0 +1,153 @@
 +/*
 + * TI EDMA definitions
 + *
 + * Copyright (C) 2006-2013 Texas Instruments.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation version 2.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +/*
 + * This EDMA3 programming framework exposes two basic kinds of resource:
 + *
 + *  ChannelTriggers transfers, usually from a hardware event but
 + * also manually or by chaining from DMA completions.
 + * Each channel is coupled to a Parameter RAM (PaRAM) slot.
 + *
 + *  Slot   Each PaRAM slot holds a DMA transfer descriptor (PaRAM
 + * set), source and destination addresses, a link to a
 + * next PaRAM slot (if any), options for the transfer, and
 + * instructions for updating those addresses.  There are
 + * more than twice as many slots as event channels.
 + *
 + * Each PaRAM set describes a sequence of transfers, either for one large
 + * buffer or for several discontiguous smaller buffers.  An EDMA transfer
 + * is driven only from a channel, which performs the transfers specified
 + * in its PaRAM slot until there are no more transfers.  When that last
 + * transfer completes, the link field may be used to reload the channel's
 + * PaRAM slot with a new transfer descriptor.
 + *
 + * The EDMA Channel Controller (CC) maps requests from channels into physical
 + * Transfer Controller (TC) requests when the channel triggers (by hardware
 + * or software events, or by chaining).  The two physical DMA channels 
 provided
 + * by the TCs are thus shared by many logical channels.
 + *
 + * DaVinci hardware also has a QDMA mechanism which is not currently
 + * supported through this interface.  (DSP firmware uses it though.)
 + */
 +
 +#ifndef __LINUX_EDMA_H_
 +#define __LINUX_EDMA_H_
 +
 +#include linux/platform_data/edma.h
 +
 +/* PaRAM slots are laid out like this */
 +struct edmacc_param {
 +   u32 opt;
 +   u32 src;
 +   u32 a_b_cnt;
 +   u32 dst;
 +   u32 src_dst_bidx;
 +   u32 link_bcntrld;
 +   u32 src_dst_cidx;
 +   u32 ccnt;
 +} __packed;
 +
 +/* fields in edmacc_param.opt */
 +#define SAMBIT(0)
 +#define DAMBIT(1)
 +#define SYNCDIMBIT(2)
 +#define STATIC BIT(3)
 +#define EDMA_FWID  (0x07  8)
 +#define TCCMODEBIT(11)
 +#define EDMA_TCC(t)((t)  12)
 +#define TCINTENBIT(20)
 +#define ITCINTEN   BIT(21)
 +#define TCCHEN BIT(22)
 +#define ITCCHENBIT(23)

This seems like the kind of thing that should go with the edma driver
instead of being globally exported to the kernel through a
include/linux header file.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix mmc hang during boot on socfpga

[Olof Johansson]

On Tue, Sep 9, 2014 at 5:19 AM, Pavel Machek pa...@ucw.cz wrote:

 Without this patch, boot hangs when trying to mount root filesystem on
 socfpga platform in about 50% cases.

I think this should have a better description than this -- this is too
vague. Did it use to always work, is this a new failure? You enable
some more error checking and improved stop handling, why was the
previous one inadequate on this platform?


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [STLinux Kernel] [PATCH v3 10/10] MAINTAINERS: Add sdhci-st file to ARCH/STI architecture

[Olof Johansson]

On Tue, Jul 22, 2014 at 5:13 AM, Maxime Coquelin maxime.coque...@st.com wrote:
 Hi Olof, Arnd, Kevin,

 I am preparing two tags for v3.17 regarding STi platform.
 One for DT, and one for defconfigs.

 Except this one, I have no patches for ARM-SoC.
 Can you take this patch directly?

 Or should I send a pull request with this one only?

We can apply directly. I'll do that in a moment here.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/2] pwrseq: Add subsystem to handle complex power sequences

[Olof Johansson]

On Fri, Jun 20, 2014 at 12:27 AM, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 06/19/2014 07:18 PM, Olof Johansson wrote:
 Hi,



 On Thu, Jun 19, 2014 at 6:04 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 The pwrseq subsystem handles complex power sequences, typically useful
 for subsystems that makes use of discoverable buses, like for example
 MMC and I2C.

 The pwrseq subsystem is dependant on CONFIG_OF to be able to parse a DT
 childnode to find out what power sequence method to bind for a device.

 From the DT childnode, the pwrseq DT parser tries to locate a
 power-method property, which string is matched towards the list of
 supported pwrseq methods.

 Each pwrseq method implements it's own power sequence and interfaces
 the pwrseq core through a few callback functions.

 To instantiate a pwrseq method, clients shall use the devm_pwrseq_get()
 API. If needed, clients can explicity drop the references to a pwrseq
 method using devm_pwrseq_put() API.

 Besides instantiation, the pwrseq API provides clients opportunity to
 select a certain power state. In this intial version, PWRSEQ_POWER_ON
 and PWRSEQ_POWER_OFF are supported. Those are also mandatory for each
 pwrseq method to support.

 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 ---
  .../devicetree/bindings/pwrseq/pwrseq.txt  |   48 ++
  drivers/Makefile   |2 +-
  drivers/pwrseq/Makefile|2 +
  drivers/pwrseq/core.c  |  175 
 
  drivers/pwrseq/core.h  |   37 +
  drivers/pwrseq/method.c|   38 +
  include/linux/pwrseq.h |   50 ++
  7 files changed, 351 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/pwrseq/pwrseq.txt
  create mode 100644 drivers/pwrseq/Makefile
  create mode 100644 drivers/pwrseq/core.c
  create mode 100644 drivers/pwrseq/core.h
  create mode 100644 drivers/pwrseq/method.c
  create mode 100644 include/linux/pwrseq.h

 diff --git a/Documentation/devicetree/bindings/pwrseq/pwrseq.txt 
 b/Documentation/devicetree/bindings/pwrseq/pwrseq.txt
 new file mode 100644
 index 000..80848ae
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/pwrseq/pwrseq.txt
 @@ -0,0 +1,48 @@
 +Power sequence DT bindings
 +
 +Each power sequence method has a corresponding power-method property 
 string.
 +This property shall be set in a subnode for a device. That subnode should 
 also
 +describe resourses which are specific to that power method.
 +
 +Do note, power sequences as such isn't encoded through DT. Instead those 
 are
 +implemented by each power method.
 +
 +Required subnode properties:
 +- power-method: should contain the string for the power method to bind.
 +
 +   Supported power methods: None.
 +
 +Example:
 +
 +Note, the clock power method in this example isn't actually supported, 
 but
 +used to visualize how a childnode could be described.
 +
 +// WLAN SDIO channel
 +sdi1_per2@80118000 {
 +   compatible = arm,pl18x, arm,primecell;
 +   reg = 0x80118000 0x1000;
 +   interrupts = 0 50 IRQ_TYPE_LEVEL_HIGH;
 +
 +   dmas = dma 32 0 0x2, /* Logical - DevToMem */
 +  dma 32 0 0x0; /* Logical - MemToDev */
 +   dma-names = rx, tx;
 +
 +   clocks = prcc_kclk 2 4, prcc_pclk 2 6;
 +   clock-names = sdi, apb_pclk;
 +
 +   arm,primecell-periphid = 0x10480180;
 +   max-frequency = 1;
 +   bus-width = 4;
 +   non-removable;
 +   pinctrl-names = default, sleep;
 +   pinctrl-0 = sdi1_default_mode;
 +   pinctrl-1 = sdi1_sleep_mode;
 +
 +   status = okay;
 +
 +   pwrseq: pwrseq1 {
 +   power-method = clock;
 +   clocks = someclk 1 2, someclk 3 4;
 +   clock-names = pwrseq1, pwrseq2;
 +   };

 I am strongly against the subnode approach as a general framework. We
 don't have a subnode for interrupts, nor for clocks or pinctrl. So why
 should we have it for the power sequencing?

 Sure, that fits the linux driver model better, but that's irrelevant
 w.r.t. describing the hardware.

 Actually this is about describing the hardware, when you have e.g. an
 mmc device which needs pwrseq, there will be 2 sets of certain
 resources, ie clocks for the host controller and clocks going directly
 to the mmc device. I think putting those both in the same subnode is
 a BAD idea, so we really do need a subnode to group the pwrseq resources
 together.

I disagree.

The clock is the input to the module, and it is what needs to be
enabled for the module to work. It's not the input to some
power-sequence component on the module, or next to the module on the
bus.

It probably makes sense to not use the standard names for the new
resources. I.e. I'm OK with using new property names that are needed
for the device vs what's needed for the MMC controller, but not with a
subnode. I.e

Re: [PATCH 23/38] mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function

[Olof Johansson]

On Thu, Jun 19, 2014 at 5:28 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
 Anyway, we did get some folks to test the patches and was thus fairly
 confident that we could merge them. Chris asked me to try to collect
 them in a PR for him, so I did. Sorry if I managed to screw some
 things up, there were several conflicts and actual regressions, which
 I tried to take care of.

 The mmc people were also very helping in sending patches to fixup
 related regressions, immediately after we merged your patchset. Thus
 together I think we managed to pull it off.

 I tend to look through slightly less rose-tinted glasses.

 The fact is... there's loads of ARM platforms which now fail in Olof's
 build/boot testing, and they all seem to have a very similar pattern:

 hummingboard:
 [1.149688] sdhci: Secure Digital Host Controller Interface driver
 [1.155901] sdhci: Copyright(c) Pierre Ossman
 ...
 [1.253630] Waiting for root device /dev/mmcblk0p2...
 [   60.325469] imx-sdma 20ec000.sdma: firmware not found
 ~$off
 # PYBOOT: Exception: timeout

 jetson:
 [2.261355] Waiting for root device /dev/mmcblk0p1...

 wandboard:
 [1.186870] sdhci: Secure Digital Host Controller Interface driver
 [1.193075] sdhci: Copyright(c) Pierre Ossman
 ...
 [1.291064] Waiting for root device /dev/mmcblk0p2...

 Whether these are caused by the patch set or not is anyone's guess,
 because we (a) don't know what's causing these failures, and (b)
 my patch series was never tested on anything but iMX6.

 I'm pretty certain that the hummingboard failure is not related to
 my series as that's one of the platforms I did test my series on.

 There's more failures which look like possibly something in core MMC is
 rather screwed, as OMAP5 (which doesn't use SDHCI) is also failing at
 a similar point.

 What these failures /do/ mean is that when I'm pushing my ARM for-next
 branch out, Olof's builder picks it up and runs a build across it, and
 the report returns a whole load of failures.  A whole load of failures
 means that those platforms haven't tested my changes, which means the
 quality of testing is much lower than it should be.

 With 26 passing and 15 failing, that's over 1/3 of platforms failing,
 which means 1/3 aren't getting tested.

 This level of failure has been going on for quite a while now, and (afaik)
 it remains uninvestigated and undiagnosed.  (This is one of the complaints
 I have about Olof's build/boot test system, much of the information about
 the build and boot is hidden away and unpublished, which makes it almost
 impossible for third parties to diagnose any problem there.  I've given up
 looking at most of Olof's build/boot mails because of this - it's just
 not interesting to see the same abbreviated boot failure logs which give
 no useful information time and time again.)

Most of this is because I want to avoid sending huuuge emails out with
the failures. I'll add a push of the full log to arm-soc.lixom.net and
include a link to it in the emails, similar to how I do the build
logs. I'll let you know when I've made that change.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/2] pwrseq: Add subsystem to handle complex power sequences

[Olof Johansson]

Hi,



On Thu, Jun 19, 2014 at 6:04 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 The pwrseq subsystem handles complex power sequences, typically useful
 for subsystems that makes use of discoverable buses, like for example
 MMC and I2C.

 The pwrseq subsystem is dependant on CONFIG_OF to be able to parse a DT
 childnode to find out what power sequence method to bind for a device.

 From the DT childnode, the pwrseq DT parser tries to locate a
 power-method property, which string is matched towards the list of
 supported pwrseq methods.

 Each pwrseq method implements it's own power sequence and interfaces
 the pwrseq core through a few callback functions.

 To instantiate a pwrseq method, clients shall use the devm_pwrseq_get()
 API. If needed, clients can explicity drop the references to a pwrseq
 method using devm_pwrseq_put() API.

 Besides instantiation, the pwrseq API provides clients opportunity to
 select a certain power state. In this intial version, PWRSEQ_POWER_ON
 and PWRSEQ_POWER_OFF are supported. Those are also mandatory for each
 pwrseq method to support.

 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 ---
  .../devicetree/bindings/pwrseq/pwrseq.txt  |   48 ++
  drivers/Makefile   |2 +-
  drivers/pwrseq/Makefile|2 +
  drivers/pwrseq/core.c  |  175 
 
  drivers/pwrseq/core.h  |   37 +
  drivers/pwrseq/method.c|   38 +
  include/linux/pwrseq.h |   50 ++
  7 files changed, 351 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/pwrseq/pwrseq.txt
  create mode 100644 drivers/pwrseq/Makefile
  create mode 100644 drivers/pwrseq/core.c
  create mode 100644 drivers/pwrseq/core.h
  create mode 100644 drivers/pwrseq/method.c
  create mode 100644 include/linux/pwrseq.h

 diff --git a/Documentation/devicetree/bindings/pwrseq/pwrseq.txt 
 b/Documentation/devicetree/bindings/pwrseq/pwrseq.txt
 new file mode 100644
 index 000..80848ae
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/pwrseq/pwrseq.txt
 @@ -0,0 +1,48 @@
 +Power sequence DT bindings
 +
 +Each power sequence method has a corresponding power-method property 
 string.
 +This property shall be set in a subnode for a device. That subnode should 
 also
 +describe resourses which are specific to that power method.
 +
 +Do note, power sequences as such isn't encoded through DT. Instead those are
 +implemented by each power method.
 +
 +Required subnode properties:
 +- power-method: should contain the string for the power method to bind.
 +
 +   Supported power methods: None.
 +
 +Example:
 +
 +Note, the clock power method in this example isn't actually supported, but
 +used to visualize how a childnode could be described.
 +
 +// WLAN SDIO channel
 +sdi1_per2@80118000 {
 +   compatible = arm,pl18x, arm,primecell;
 +   reg = 0x80118000 0x1000;
 +   interrupts = 0 50 IRQ_TYPE_LEVEL_HIGH;
 +
 +   dmas = dma 32 0 0x2, /* Logical - DevToMem */
 +  dma 32 0 0x0; /* Logical - MemToDev */
 +   dma-names = rx, tx;
 +
 +   clocks = prcc_kclk 2 4, prcc_pclk 2 6;
 +   clock-names = sdi, apb_pclk;
 +
 +   arm,primecell-periphid = 0x10480180;
 +   max-frequency = 1;
 +   bus-width = 4;
 +   non-removable;
 +   pinctrl-names = default, sleep;
 +   pinctrl-0 = sdi1_default_mode;
 +   pinctrl-1 = sdi1_sleep_mode;
 +
 +   status = okay;
 +
 +   pwrseq: pwrseq1 {
 +   power-method = clock;
 +   clocks = someclk 1 2, someclk 3 4;
 +   clock-names = pwrseq1, pwrseq2;
 +   };

I am strongly against the subnode approach as a general framework. We
don't have a subnode for interrupts, nor for clocks or pinctrl. So why
should we have it for the power sequencing?

Sure, that fits the linux driver model better, but that's irrelevant
w.r.t. describing the hardware.

Power method needs to be strongly defined, since that's really the ABI
here. They need to be documented, and you need to pre-populate the
common ones to make this a useful thing.

 +};
 diff --git a/drivers/Makefile b/drivers/Makefile
 index f98b50d..ac1bf5b 100644
 --- a/drivers/Makefile
 +++ b/drivers/Makefile
 @@ -128,7 +128,7 @@ endif
  obj-$(CONFIG_DCA)  += dca/
  obj-$(CONFIG_HID)  += hid/
  obj-$(CONFIG_PPC_PS3)  += ps3/
 -obj-$(CONFIG_OF)   += of/
 +obj-$(CONFIG_OF)   += of/ pwrseq/

This should probably be added to driver core instead of having yet
another drivers/ toplevel directory.

  obj-$(CONFIG_SSB)  += ssb/
  obj-$(CONFIG_BCMA) += bcma/
  obj-$(CONFIG_VHOST_RING)   += vhost/
 diff --git a/drivers/pwrseq/Makefile b/drivers/pwrseq/Makefile
 new file mode 100644
 index 000..afb914f
 --- /dev/null
 +++ 

Re: [linux-sunxi] [PATCH v2 1/4] dt: bindings: mmc: Document the practice of using subnodes for slots

[Olof Johansson]

On Sat, May 31, 2014 at 12:03 PM, Hans de Goede hdego...@redhat.com wrote:
 The following existing MMC host controller bindings use slot subnodes:

 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
 Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt

 This commit documents this practice in the standard mmc bindings 
 documentation.

 Signed-off-by: Hans de Goede hdego...@redhat.com

There are today only two drivers that use this kind of binding, dw_mmc
and the at91 one. Neither seems to actually ever have been used with
more than one slot. I doubt anyone building an exynos-based system
will ever do a multi-slot solution, and it seems that the at91 driver
doesn't actually handle more than one slot.

I'm personally not that excited about complicating the bindings by
opening up for this -- I would rather work towards removing the
concept of slots if it's one of those things that are going to remain
unused. We have actually been talking about reworking the dw_mmc
binding to remove the slot concept (and simplify the driver by doing
so).


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: representing sdio devices oob interrupt, clks, etc. in device tree

[Olof Johansson]

On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote:
 On Tue, May 27, 2014 at 03:50:33PM +0200, Ulf Hansson wrote:
 
  To describe the HW in DT, the embedded SDIO card (actually it could be
  any type of embedded card) shall be modelled as a child node to the
  mmc host in DT. Similar to what you have proposed, but with the
  difference that the child node _must_ contain a DT compatible string,
  which means a powerup-driver can be probed.
 
  Yes, I understand we might need one DT compatible string per board,
  but that's because we need to model the hardware - and it differs.
 
  To clarify my view, we do need a powerup-driver and the primary
  reason is that we must not model power up sequences within DT.
  Typically I see the powerup-driver as a simple platform driver
  attached to the platform bus, but I that could of course differ.
 
 This then either conflicts with cases where we need to describe the
 actual contents of the slot with a compatible string or means that the
 SDIO driver needs to handle powerup sequencing since we should be
 binding to the first compatible we find.  If the host controller driver
 and/or subsystem is going to deal with the powering up it's not clear
 that it specifically needs to be the compatible property that's used
 to determine the powerup method, it could just be a boolean or a
 'power-method = blah' property (where blah is one of a series of strings
 defining methods).  Alternatively we could have separate nodes for the
 slot and SDIO device but that feels meh.  What's the hard requirement
 for it to specifically be a compatible property?

+1. Just because we have a subnode in a device tree, we don't have to have
a driver bind against it. The MMC core code could go down into the subnodes,
find a power-method = foo property and go ahead and parse the rest of it.
There's no requirement that we do this through the Linux driver model of
probe(), etc.

  The slot will be the first level of child node under the mmc host,
  then each slot may have a child node which models the embedded card.
  But, let's leave that discussion for now. :-)
 
 OK, that's the separate node for the slot and device.
 
  Powerup driver's -probe():
  Typically the powerup driver will need to register a few callback
  functions towards the mmc core. Typically at mmc_of_parse(), those
  callbacks will have to be connected to a particular mmc host.
 
  I would like to see three different callbacks, mirroring each of the
  mmc_ios power_mode states MMC_POWER_OFF|UP|ON.
 
  The power up sequence, performed by the mmc core:
  The mmc_power_up|off functions, will invoke the registered powerup
  driver's callbacks if they exists for the particular host it operates
  on.
 
 There's also the need for the SDIO device to be able to get at the
 resources provided and actively work with them at runtime if it wants to
 manage things more actively (partial poweroff for low power states or
 managing clock rates for example).

Again, I think it gets overly complicated by using a full driver for the
power management. Abstracted out into something separate and scalable
as number of devices grow? Sure, definitely. As a driver? Not convinced.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] mmc: dove: fix missing MACH_DOVE dependency

[Olof Johansson]

On Thu, May 22, 2014 at 2:09 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 19 May 2014 20:02, Sebastian Hesselbarth
 sebastian.hesselba...@gmail.com wrote:
 DT-enabled Dove moved over from ARCH_DOVE in mach-dove to MACH_DOVE in
 mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
 DT-only MACH_DOVE Kconfig. This slipped through the cracks and now is
 a fix to allow to build Dove's SDHCI driver for mach-mvebu on v3.15-rc.

 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 Acked-by: Jason Cooper ja...@lakedaemon.net

 Thanks! Picked up for the PR I send to Chris.

Ulf, you might consider adding your tree to linux-next if this is
going to be a common work flow for you guys.

It's partially up to Chris though, if he's OK with patches going into
your branch more or less being guaranteed to make it into his as well.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] mmc: dove: fix missing MACH_DOVE dependency

[Olof Johansson]

On Fri, May 23, 2014 at 6:41 AM, Jason Cooper ja...@lakedaemon.net wrote:
 On Fri, May 23, 2014 at 09:40:55AM +0200, Ulf Hansson wrote:
 On 23 May 2014 09:16, Olof Johansson o...@lixom.net wrote:
  On Thu, May 22, 2014 at 2:09 AM, Ulf Hansson ulf.hans...@linaro.org 
  wrote:
  On 19 May 2014 20:02, Sebastian Hesselbarth
  sebastian.hesselba...@gmail.com wrote:
  DT-enabled Dove moved over from ARCH_DOVE in mach-dove to MACH_DOVE in
  mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
  DT-only MACH_DOVE Kconfig. This slipped through the cracks and now is
  a fix to allow to build Dove's SDHCI driver for mach-mvebu on v3.15-rc.
 
  Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
  Acked-by: Jason Cooper ja...@lakedaemon.net
 
  Thanks! Picked up for the PR I send to Chris.
 
  Ulf, you might consider adding your tree to linux-next if this is
  going to be a common work flow for you guys.

 That's done already. :-) There are patches which makes this visible in
 the MAINTAINERS as well, queued for 3.16.

 git://git.linaro.org/people/ulf.hansson/mmc.git next

 Though due to merge conflicts, during this release cycle, I didn't
 want to queue any patches besides for the mmci host driver.

 
  It's partially up to Chris though, if he's OK with patches going into
  your branch more or less being guaranteed to make it into his as well.
 

 Yes, we need to figure out a good work flow when using two separate
 trees. Thanks for bringing this up!

 If you have any questions, please ask.  mvebu has been doing this for
 several release cycles now, and I'm also doing it for irqchip now.

 The biggest rule is that once you sign a tag and send a pull-request for
 it, the branch is immutable up to and including that tag.

...unless you get asked to respin based on review from the person
you're sending the request to.

This is the main problem with multi-level maintainer trees: It's hard
to run a stable non-rebasing tree as a downstream tree since there's
no actual guarantee that it'll go in as-is.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: representing sdio devices oob interrupt, clks, etc. in device tree

[Olof Johansson]

On Thu, May 22, 2014 at 07:20:55PM +0200, Tomasz Figa wrote:
 Hi,
 
 
 On 22.05.2014 13:38, Hans de Goede wrote:
  On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
  On Thu, May 22, 2014 at 5:49 PM, Hans de Goede hdego...@redhat.com wrote:
 
 snip
 
  I've been thinking a bit about this, and it is a non trivial problem since
  sdio devices are normally instantiated when probed, unlike ie spi devices
  which are instantiated from devicetree.
 
  Adding device tree instantiation of sdio devices seems like a bad idea, as
  then we get 2 vastly different device instantiation paths. Still we need 
  some
  way to get power and clks setup before the mmc host initializes.
 
 What about introducing some extra callbacks to mmc drivers to build
 driver data and control power?

The MMC bus is probable, and there should be no need to put any information in
the device tree to pair up the right driver with the right device. The only
thing we should need is hardware description w.r.t. reset/power/clock lines.

It's pretty common during development to have a couple of different vendor
modules. Reset sequences and requirements might not be identical between them,
but in reality they all work well enough using the common settings.


Besides, where it ends up in the kernel implementation is mostly irrelevant, in
some ways. We can refactor and move things as needed at any time. The only
thing that needs to be reasonably stable (and/or only be expanded on, not
redefined) is the DT binding. So I'd rather see something KISS go in now,
implementation-wise (with a sane and simple binding), then getting stuck in
this infinite polishing of just how the kernel-side implementation should be.

This is one of the major missing pieces to make a lot of ARM systems usable
with a mainline kernel, since everybody use some out-of-tree solution today
(not necessarily hacks, but still not shared code). I'd really like to see it
resolved soon.

I'm OK in principle with Hans' proposed solution, as long as it provides the
properties I need on exynos5250-snow (and the new peach_pit/pi platforms).


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

On Thu, Feb 13, 2014 at 05:13:14PM +0100, Arnd Bergmann wrote:
 On Thursday 13 February 2014 14:41:06 Russell King - ARM Linux wrote:
  On Thu, Feb 13, 2014 at 01:48:55PM +0100, Arnd Bergmann wrote:
   On Thursday 13 February 2014 10:42:48 Russell King - ARM Linux wrote:

What if we have a platform where things subtly change, like for 
instance,
the wiring on the SD slot to fix a problem with UHS-1 cards, which means
you don't have UHS-1 support for some platforms but do for others.

What if you have a platform which uses a brcm4329 chip for Wifi, but 
then
later in the production run switch to using a different Wifi chipset?
   
   As far as I can tell, the power sequencing is normally really
   dependent on the device. If someone has an on-board brcm4329
   that requires a specific set of clocks, resets, voltages etc
   to be routed to the chip and enabled in the correct order to
   allow probing, it seems unlikely that changing the wifi chipset
   to something else would keep the exact same requirements.
  
  That's your assertion - however, do we /know/ whether there's a situation
  where Olof's solution doesn't work because the sequencing is wrong?
  
  I see nothing unreasonable about the sequence:
  
  1. hold reset at low level
  2. apply power
  3. turn clock on
  4. apply reset
  5. release reset
 
 I was thinking of cases where you may need a more complex sequence:
 - wait for a device specific time between some of the steps
   (the cw1200 driver seems to need that, but we could probably
get away with waiting long enough for everyone)
 - have more than one of each, and turn them on in the right order.
   cw1200 seems to need two voltages, two gpio resets (reset
   and powerup).

Those two gpio resets are extremely common, but on snow (the chromebook) the
powerup gpio is hard-wired. So it's not all that unusual. As I mention in the
patch, a positive-sense powerup and a negative-sense reset aren't all that
different in practice.

   Again, we could specify a larger number of clocks that can be
   provided to the host, but if we make it a device specific
   property, we already know how many we need.
 
 I can't think of anything that would require significant changes
 to the procedure though, just refinements as we run into problems.

The main pain will be if there's a requirement to do
gpio-requlator-gpio-regulator. We could mandate that regulators are turned on
in order. (Also, see below).

 
  The points being:
  * never set a signal to a high level before power is applied, otherwise
we can end up supplying power through that signal (which may cause
damage.)  That goes for the reset and clock.
  * devices normally want clocks running to complete their reset sequencing.
  
  This is actually the sequence which MMC/SD cards do (except without the
  reset) anyway - it's spec'd that on the MMC/SD bus, power will be applied
  and will be stable before the clock signal is applied, and then the clock
  signal runs for a certain number of cycles before you even start talking
  to the card.
 
 It may be dangerous to refer to the spec, since we are talking
 specifically about devices that require something beyond what the
 spec says ;-) For instance in SD/MMC cards I'd assume the device clock
 to be derived from the bus clock. However we can expect that clock
 to work already (any working mmc host driver would provide that),
 but we may need to drive the device clock. It still sounds reasonable
 to assume that the sequencing is the same as for the bus clock.
 
  That all said, we do have the problem that once we decide, we need to
  support it because it becomes part of DT - this is one of the things I
  hate about DT, it requires over-design.
 
 Yes, I agree. It is a problem that we have to face all the time.
 We have in the past defined bindings of both types, overdesigned
 and not thought through enough.
 
   Your point is Olof's solution
  may break if we have a device which requires a different sequence which
  is a valid point which has to be considered from the DT perspective and
  addressed whether or not we actually have a device which meets that
  criteria.  I don't see an easy solution to this.
 
 I think either one will work. With Olof's suggestion that may mean we
 have to keep adding support for increasingly complex cases when we
 run into them, or it may all be easy. With my suggestion, we give
 more room for function drivers to mess things up, but at least we
 can keep the complexity in the places that need them and only need
 to change the core once.

I always anticipated the binding needing amendment over time -- for example if
a device needs longer delays between clock enable and reset release. But most
of those can be handled through bindings amendments as needed (with default
behavior for non-amended bindings the same as today).

Chances are that if we do a per-device binding, we'll likely end up having
shared helpers to parse the 

Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

On Tue, Jan 21, 2014 at 12:55 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
[pruning quotes a bit]
 Is the above regulator related to host-ocr_avail mask? Could the
 above regulator be replaced by vmmc?

 I have to admit that I don't know MMC as well as I could, but OCR seems to be
 something that's between the driver/controller/device, not related to 
 external
 power control in this case?

 This is related to the power of the card, typically external
 regulators controlled by the host driver.

 Both the card and the host supports a voltage range. This range is
 exactly what the OCR mask describes. At initialization of the card,
 the host ocr is validated against the card ocr.

Ok, so they specify the voltage needed, but there's no way to
determine what regulator is wired up to control. So that information
is still needed (possibly through vmmc though).


 At the moment host drivers uses mmc_regulator_get_supply(), which
 fetches regulators called vmmc and vqmmc. It is also common to
 have these defined in DT like vmmc-supply. This has not been
 properly documented for most host cases, and we should fix that. I
 also think it would make sense to include these in the documentation
 for the common mmc bindings, instead of host specific bindings.

 Hm, I had been of the impression that the vmmc stuff is to control
 power/voltage on the signal lines, not for external card power. Still, even 
 in
 that case there's need for the reset line handling and clock control.

 vmmc: the power to the card.
 vqmmc: the I/O voltage levels (for the signal lines).

Ah, ok. So vmmc seems like it's the same then. I'll try to get some
cycles to look at it today.


 Regarding reset, I agree, those seems to be needed.

 Regarding clock control. I suppose you are referring to separate
 external clocks, not affecting the SDIO/SD/MMC interface speed!?

 That could make sense, but still I wonder how those shall be handled
 in a fine grained power management setup. In other words, when shall
 those be gated/ungated? Is the mmc core able to take the correct
 decision about these?

The reference clock is in most cases I've seen 32kHz, and not
something that's under fine-grained power management. So it's not used
to regulate interface speed, etc.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

On Tue, Jan 21, 2014 at 10:34 AM, Tomasz Figa t.f...@samsung.com wrote:

 What do you think?

Sure, post the patches.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

On Mon, Jan 20, 2014 at 10:58 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 20 January 2014, Olof Johansson wrote:

 +Card power and reset control:
 +The following properties can be specified for cases where the MMC
 +peripheral needs additional reset, regulator and clock lines. It is for
 +example common for WiFi/BT adapters to have these separate from the main
 +MMC bus:
 +  - card-reset-gpios: Specify GPIOs for card reset (reset active low)
 +  - card-external-vcc-supply: Regulator to drive (independent) card VCC
 +  - clock with name card_ext_clock: External clock provided to the card

 I wonder whether the reset line should use the generic reset controller 
 binding
 rather than the gpio binding. There has been a recent discussion about a
 gpio-reset driver, which should generalize this at the reset level, and
 it would make it possible to use reset controllers that are not gpio driven.
 In general, any gpio can be used as a reset, but not every reset line can
 be a gpio. I don't know whether anyone would use an internal reset-controller
 for an external SDIO chip though, so maybe your approach is sufficient.

I'd expect most usage of this to be through gpios, since we're talking
about external independent modules here. I would prefer not to bring
in the reset controller stuff here -- it just adds another layer of
abstraction that seems unnecessary.

I would prefer if the reset framework was contained to only be the
on-chip SoC IP block resets, etc, as originally intended.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

On Mon, Jan 20, 2014 at 11:14 AM, Fabio Estevam feste...@gmail.com wrote:
 On Mon, Jan 20, 2014 at 1:56 AM, Olof Johansson o...@lixom.net wrote:

 +Card power and reset control:
 +The following properties can be specified for cases where the MMC
 +peripheral needs additional reset, regulator and clock lines. It is for
 +example common for WiFi/BT adapters to have these separate from the main
 +MMC bus:
 +  - card-reset-gpios: Specify GPIOs for card reset (reset active low)

 Wouldn't it be better not to assume that the card reset is always
 active low and read the GPIO_ACTIVE_xxx flags instead?

That's actually what the code does, I need to update the text. Thanks
for spotting it.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

On Mon, Jan 20, 2014 at 09:44:23AM +0100, Ulf Hansson wrote:
 On 20 January 2014 04:56, Olof Johansson o...@lixom.net wrote:
  This patch enables support for power-on sequencing of SDIO peripherals 
  through DT.
 
  In general, it's quite common that wifi modules and other similar
  peripherals have several signals in addition to the SDIO interface that
  needs wiggling before the module will power on. It's common to have a
  reference clock, one or several power rails and one or several lines
  for reset/enable type functions.
 
  The binding as written today introduces a number of reset gpios,
  a regulator and a clock specifier. The code will handle up to 2 gpio
  reset lines, but it's trivial to increase to more than that if needed
  at some point.
 
  Implementation-wise, the MMC core has been changed to handle this during
  host power up, before the host interface is powered on. I have not yet
  implemented the power-down side, I wanted people to have a chance for
  reporting back w.r.t. issues (or comments on the bindings) first.
 
  I have not tested the regulator portion, since the system and module
  I'm working on doesn't need one (Samsung Chromebook with Marvell
  8797-based wifi). Testing of those portions (and reporting back) would
  be appreciated.
 
  Signed-off-by: Olof Johansson o...@lixom.net
  ---
   Documentation/devicetree/bindings/mmc/mmc.txt |   11 +++
   drivers/mmc/core/core.c   |   42 
  +
   drivers/mmc/core/host.c   |   30 +-
   include/linux/mmc/host.h  |5 +++
   4 files changed, 87 insertions(+), 1 deletion(-)
 
  diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
  b/Documentation/devicetree/bindings/mmc/mmc.txt
  index 458b57f..962e0ee 100644
  --- a/Documentation/devicetree/bindings/mmc/mmc.txt
  +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
  @@ -5,6 +5,8 @@ these definitions.
   Interpreted by the OF core:
   - reg: Registers location and length.
   - interrupts: Interrupts used by the MMC controller.
  +- clocks: Clocks needed for the host controller, if any.
  +- clock-names: Goes with clocks above.
 
   Card detection:
   If no property below is supplied, host native card detect is used.
  @@ -30,6 +32,15 @@ Optional properties:
   - cap-sdio-irq: enable SDIO IRQ signalling on this interface
   - full-pwr-cycle: full power cycle of the card is supported
 
  +Card power and reset control:
  +The following properties can be specified for cases where the MMC
  +peripheral needs additional reset, regulator and clock lines. It is for
  +example common for WiFi/BT adapters to have these separate from the main
  +MMC bus:
  +  - card-reset-gpios: Specify GPIOs for card reset (reset active low)
  +  - card-external-vcc-supply: Regulator to drive (independent) card VCC
  +  - clock with name card_ext_clock: External clock provided to the card
  +
   *NOTE* on CD and WP polarity. To use common for all SD/MMC host 
  controllers line
   polarity properties, we have to fix the meaning of the normal and 
  inverted
   line levels. We choose to follow the SDHCI standard, which specifies both 
  those
  diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
  index 098374b..c43e6c8 100644
  --- a/drivers/mmc/core/core.c
  +++ b/drivers/mmc/core/core.c
  @@ -13,11 +13,13 @@
   #include linux/module.h
   #include linux/init.h
   #include linux/interrupt.h
  +#include linux/clk.h
   #include linux/completion.h
   #include linux/device.h
   #include linux/delay.h
   #include linux/pagemap.h
   #include linux/err.h
  +#include linux/gpio.h
   #include linux/leds.h
   #include linux/scatterlist.h
   #include linux/log2.h
  @@ -1519,6 +1521,43 @@ void mmc_set_driver_type(struct mmc_host *host, 
  unsigned int drv_type)
  mmc_host_clk_release(host);
   }
 
  +static void mmc_card_power_up(struct mmc_host *host)
  +{
  +   int i;
  +   struct gpio_desc **gds = host-card_reset_gpios;
  +
  +   for (i = 0; i  ARRAY_SIZE(host-card_reset_gpios); i++) {
  +   if (gds[i]) {
  +   dev_dbg(host-parent, Asserting reset line %d, i);
  +   gpiod_set_value(gds[i], 1);
  +   }
  +   }
  +
  +   if (host-card_regulator) {
  +   dev_dbg(host-parent, Enabling external regulator);
  +   if (regulator_enable(host-card_regulator))
  +   dev_err(host-parent, Failed to enable external 
  regulator);
  +   }
  +
  +   if (host-card_clk) {
  +   dev_dbg(host-parent, Enabling external clock);
  +   clk_prepare_enable(host-card_clk);
  +   }
  +
  +   /* 2ms delay to let clocks and power settle */
  +   mmc_delay(20);
  +
  +   for (i = 0; i  ARRAY_SIZE(host-card_reset_gpios); i++) {
  +   if (gds[i]) {
  +   dev_dbg(host-parent, Deasserting reset line %d, 
  i

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

On Fri, Jan 17, 2014 at 8:58 AM, Nicolas Pitre n...@fluxnic.net wrote:
 On Fri, 17 Jan 2014, Rob Herring wrote:

 On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre n...@fluxnic.net wrote:
  On Thu, 16 Jan 2014, Olof Johansson wrote:
 
  for SDIO slots is somewhat misleading; nearly all controllers only
  do one slot/device per controller. The designware controller can do
  multiple slots, and that adds a bit of driver and binding complexity
  for something that seemingly not a single vendor has actually
  implemented.
 
  The Marvell 8688, just to name one, does both WIFI and BlueTooth over
  the same SDIO controller using separate functions/slots.

 But that is logical functions within a chip, not multiple discrete
 chips (i.e. slots) with their own reset, regulators, etc.

 OK.  If that's the definition of a slot in this context then I agree.

Correct -- the device that I've been doing the work in is actually the
combined wifi/bluetooth module on the Samsung Chromebook, which is a
Marvell 8797. It has multiple functions which still work well.

The multi-slot concept I was talking about was one host controller
for several physical slots. Seems like at91 implements _and_ uses this
but nobody else. However, it seems that they allocate one mmc host per
slot, so the same model still works.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

On Sun, Jan 19, 2014 at 09:28:53PM +0100, Arnd Bergmann wrote:
 On Sunday 19 January 2014, Olof Johansson wrote:
  The multi-slot concept I was talking about was one host controller
  for several physical slots. Seems like at91 implements and uses this
  but nobody else. However, it seems that they allocate one mmc host per
  slot, so the same model still works.
  
 
 IIRC dw-mci also has multiple slots, and it's a common host controller
 in a number of SoCs. I don't know how many of them actually support
 multiple slots rather than a simplified single-slot version of
 that controller.

Right, that's the main one i had in mind -- the binding, and the driver, allow
for multiple slots but we've been searching high and low for an actual SoC that
implements that, and none seem to do it. So the additional overhead is just
wasted, and there's been talk of bringing the binding more in line with
a single-slot driver instead. It makes a lot of sense to do.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote:
 On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
  The multi-slot concept I was talking about was one host controller
  for several physical slots. Seems like at91 implements _and_ uses this
  but nobody else. However, it seems that they allocate one mmc host per
  slot, so the same model still works.
  
 
 I think we need to be extra careful about the DT bindings then because
 adding a property in a slot is requiring handling that in the at91
 driver whereas adding a common property for the various mmc hosts can be
 done in the core code.
 
 From what I remember, it would be really good to put the DT parsing for
 the slots in the core code but I only had a really quick look at that.

The patches I have here do it all in the core per host with common
bindings. I hope to post them tonight. They should fit the at91 model
just fine as well, since they do each slot as a mmc_host, not as a separate
slot with a shared host controller.

(Some drivers don't seem to call mmc_of_parse(), which they will need to do to
take advantage of the common implementation. But that can be addressed driver
by driver as someone has a chance to test it).


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] mmc: add support for power-on sequencing through DT

[Olof Johansson]

This patch enables support for power-on sequencing of SDIO peripherals through 
DT.

In general, it's quite common that wifi modules and other similar
peripherals have several signals in addition to the SDIO interface that
needs wiggling before the module will power on. It's common to have a
reference clock, one or several power rails and one or several lines
for reset/enable type functions.

The binding as written today introduces a number of reset gpios,
a regulator and a clock specifier. The code will handle up to 2 gpio
reset lines, but it's trivial to increase to more than that if needed
at some point.

Implementation-wise, the MMC core has been changed to handle this during
host power up, before the host interface is powered on. I have not yet
implemented the power-down side, I wanted people to have a chance for
reporting back w.r.t. issues (or comments on the bindings) first.

I have not tested the regulator portion, since the system and module
I'm working on doesn't need one (Samsung Chromebook with Marvell
8797-based wifi). Testing of those portions (and reporting back) would
be appreciated.

Signed-off-by: Olof Johansson o...@lixom.net
---
 Documentation/devicetree/bindings/mmc/mmc.txt |   11 +++
 drivers/mmc/core/core.c   |   42 +
 drivers/mmc/core/host.c   |   30 +-
 include/linux/mmc/host.h  |5 +++
 4 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 458b57f..962e0ee 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -5,6 +5,8 @@ these definitions.
 Interpreted by the OF core:
 - reg: Registers location and length.
 - interrupts: Interrupts used by the MMC controller.
+- clocks: Clocks needed for the host controller, if any.
+- clock-names: Goes with clocks above.
 
 Card detection:
 If no property below is supplied, host native card detect is used.
@@ -30,6 +32,15 @@ Optional properties:
 - cap-sdio-irq: enable SDIO IRQ signalling on this interface
 - full-pwr-cycle: full power cycle of the card is supported
 
+Card power and reset control:
+The following properties can be specified for cases where the MMC
+peripheral needs additional reset, regulator and clock lines. It is for
+example common for WiFi/BT adapters to have these separate from the main
+MMC bus:
+  - card-reset-gpios: Specify GPIOs for card reset (reset active low)
+  - card-external-vcc-supply: Regulator to drive (independent) card VCC
+  - clock with name card_ext_clock: External clock provided to the card
+
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
line
 polarity properties, we have to fix the meaning of the normal and inverted
 line levels. We choose to follow the SDHCI standard, which specifies both those
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 098374b..c43e6c8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -13,11 +13,13 @@
 #include linux/module.h
 #include linux/init.h
 #include linux/interrupt.h
+#include linux/clk.h
 #include linux/completion.h
 #include linux/device.h
 #include linux/delay.h
 #include linux/pagemap.h
 #include linux/err.h
+#include linux/gpio.h
 #include linux/leds.h
 #include linux/scatterlist.h
 #include linux/log2.h
@@ -1519,6 +1521,43 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned 
int drv_type)
mmc_host_clk_release(host);
 }
 
+static void mmc_card_power_up(struct mmc_host *host)
+{
+   int i;
+   struct gpio_desc **gds = host-card_reset_gpios;
+
+   for (i = 0; i  ARRAY_SIZE(host-card_reset_gpios); i++) {
+   if (gds[i]) {
+   dev_dbg(host-parent, Asserting reset line %d, i);
+   gpiod_set_value(gds[i], 1);
+   }
+   }
+
+   if (host-card_regulator) {
+   dev_dbg(host-parent, Enabling external regulator);
+   if (regulator_enable(host-card_regulator))
+   dev_err(host-parent, Failed to enable external 
regulator);
+   }
+
+   if (host-card_clk) {
+   dev_dbg(host-parent, Enabling external clock);
+   clk_prepare_enable(host-card_clk);
+   }
+
+   /* 2ms delay to let clocks and power settle */
+   mmc_delay(20);
+
+   for (i = 0; i  ARRAY_SIZE(host-card_reset_gpios); i++) {
+   if (gds[i]) {
+   dev_dbg(host-parent, Deasserting reset line %d, i);
+   gpiod_set_value(gds[i], 0);
+   }
+   }
+
+   /* 2ms delay to after reset release */
+   mmc_delay(20);
+}
+
 /*
  * Apply power to the MMC stack.  This is a two-stage process.
  * First, we enable power to the card without the clock running.
@@ -1535,6 +1574,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr

[PATCH 2/3] mmc: dw_mmc: call mmc_of_parse to fill in common options

[Olof Johansson]

The shared of parse function fills in common options for capabilities,
etc, but it needs to be called from each driver that wants to make use
of it. dw_mmc was missing the call.

Signed-off-by: Olof Johansson o...@lixom.net
---
 drivers/mmc/host/dw_mmc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a776f24..7119f63 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2137,6 +2137,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned 
int id)
if (!mmc)
return -ENOMEM;
 
+   mmc_of_parse(mmc);
+
slot = mmc_priv(mmc);
slot-id = id;
slot-mmc = mmc;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] RFC/RFT: Powering on MMC Wifi/BT modules in MMC core

[Olof Johansson]

This is a small series enhancing the MMC core code to power on modules
before the host in cases where needed, and the corresponding DT bindings
changes.

I've got some other issues to debug on the Chromebook, i.e. the interface
doens't actually work. So far it seems unrelated to this patch set so
it's worth posting this and get things going since others need the same
functionality (i.e Cubox-i).

As mentioned in the patch in the series, I haven't implemented power-down
yet, I wanted to make sure that the power-on side will be adequate for
those who are looking to use it right away.

Comments/test reports/etc welcome.


-Olof

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: dts: exynos5250-snow: Enable wifi power-on

[Olof Johansson]

This adds the required specifications of reset-gpios on snow to enable wifi.

The wifi module is always powered, but it has three more signals needed:
- Enable line (active high)
- Reset line (active low)
- 32kHz reference clock

The enable and reset lines are in practice quite similar (i.e. both
need to be 1 for the module to be enabled), so treat them both as
reset gpios. The clock is specified using the new clock property on
MMC, which due to lack of append options right now has to duplicate the
first two clocks that are SoC generic.

Also, fix the pinctrl setting (that has moved from slot node to host
controller node), and add the two gpio lines to the pinctrl setup.

Signed-off-by: Olof Johansson o...@lixom.net
---
 arch/arm/boot/dts/exynos5250-cros-common.dtsi |   17 -
 arch/arm/boot/dts/exynos5250-snow.dts |   11 +--
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi 
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 2c1560d..b72f342 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -34,6 +34,20 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+   wifi_en: wifi-en {
+   samsung,pins = gpx0-1;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   wifi_rst: wifi-rst {
+   samsung,pins = gpx0-2;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
};
 
i2c@12C6 {
@@ -41,7 +55,7 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
 
-   max77686@09 {
+   pmic: max77686@09 {
compatible = maxim,max77686;
interrupt-parent = gpx3;
interrupts = 2 0;
@@ -284,6 +298,7 @@
num-slots = 1;
supports-highspeed;
broken-cd;
+   cap-sdio-irq;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 7e45eea..c150483 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -11,6 +11,7 @@
 /dts-v1/;
 #include exynos5250.dtsi
 #include exynos5250-cros-common.dtsi
+#include dt-bindings/gpio/gpio.h
 
 / {
model = Google Snow;
@@ -186,9 +187,15 @@
 */
mmc@1223 {
status = okay;
+   clocks = clock 280, clock 139, pmic 2;
+   clock-names = biu, ciu, card_ext_clock;
+   card-reset-gpios = gpx0 1 GPIO_ACTIVE_LOW, /* WIFI_EN */
+  gpx0 2 GPIO_ACTIVE_LOW; /* WIFI_RSTn */
+   pinctrl-names = default;
+   pinctrl-0 = sd3_clk sd3_cmd sd3_bus4 wifi_en wifi_rst;
slot@0 {
-   pinctrl-names = default;
-   pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
+   reg = 0;
+   bus-width = 4;
};
};
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

On Sun, Jan 19, 2014 at 3:30 PM, Olof Johansson o...@lixom.net wrote:
 On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote:
 On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
  The multi-slot concept I was talking about was one host controller
  for several physical slots. Seems like at91 implements _and_ uses this
  but nobody else. However, it seems that they allocate one mmc host per
  slot, so the same model still works.
 

 I think we need to be extra careful about the DT bindings then because
 adding a property in a slot is requiring handling that in the at91
 driver whereas adding a common property for the various mmc hosts can be
 done in the core code.

 From what I remember, it would be really good to put the DT parsing for
 the slots in the core code but I only had a really quick look at that.

 The patches I have here do it all in the core per host with common
 bindings. I hope to post them tonight.

Done. See RFC series at:

http://marc.info/?l=linux-mmcm=139019015915702w=2


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

[adding devicetree and mmc lists]

On Thu, Jan 16, 2014 at 6:02 AM, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 16 January 2014 13:36:49 Russell King - ARM Linux wrote:


 The Wifi/BT chip can only be detected via probing the SDIO connection, and
 only when the device has been powered up and released from reset - so we
 have to power up and reset the bcrm device before we probe via the SDIO
 bus.

 This is indeed a common problem, and while we've talked about solving
 it in the past, nothing has happened code-wise. It indeed needs an
 implementation in the sdio framework.

Yeah, this is what's keeping wifi from working on the ARM Chromebook
upstream as well, and it's been on my list to deal with for a long
time. So now is as good a time as any.

Generic SDIO framework solution/binding would be great, since these
constructs are quite common on systems these days (even x86 is
starting to get peripherals on SDIO).

 While it's possible to attach the power supply for the Wifi/BT chip to the
 vmmc-supply property of the host, it's not possible to do that with the
 oscillator supply.  Neither is there any provision for manipulating the
 GPIOs to deal with the resets.

 I can't find any examples of anything similar in our existing set of DT
 files, so I suspect either this is a device which no one supports on any
 DT platform, or there's some clever way to handle this.

 The former.

We've dealt with it with local code in our tree for Chrome OS, and I
suspect everyone else has too. It's definitely time to solve
generically.

 How do other people support this in DT?  Do they hack up some platform
 specific code (which isn't nice)?  What other solutions are there to get
 around this problem?  How does this kind of thing get represented in DT?

 (Don't suggest adding DT support to the bcrmfmac driver - this is a
 chicken-and-egg problem.  The driver isn't being probed at the moment
 because the device is powered down and/or held in reset, so is
 undetectable.  The kernel needs to power it up and release the reset
 so it becomes detectable.)

 The problem is two-fold:

 a) we need to add a generic mechanism to the SDIO probe code to
 allow specifying clocks, regulators and resets (possibly more)
 for an SDIO endpoint that get enabled before the probe starts.
 This parts needs a DT binding for SDIO slots as well as code.

for SDIO slots is somewhat misleading; nearly all controllers only
do one slot/device per controller. The designware controller can do
multiple slots, and that adds a bit of driver and binding complexity
for something that seemingly not a single vendor has actually
implemented.

So we can likely assume to keep these reset/power/clock lines per host
controller, no need to add a slot construct.

 b) We need to add a way to attach a device_node to an sdio_func,
 so that a function driver can find additional DT properties.
 This part should be relatively simple once (a) is done and
 should only need a little code but no new binding. The code
 would be similar to what we do for amba, i2c or spi devices.

This isn't actually needed for this functionality, but might be needed
for other things...

 Note that the same problem exists for a number of other discoverable
 buses that get used in nondiscoverable ways, e.g. USB, PCI,
 or even SCSI. It's normally a spec violation if those devices
 are wired up like this, but of course we still want to support
 the hardware.

... such as these. :)

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
 We've dealt with it with local code in our tree for Chrome OS, and I
 suspect everyone else has too. It's definitely time to solve
 generically.

 As there's no code for any Cubox-i or Hummingboard (they're both purely
 DT), what this means is that the answer to Wifi/BT support in mainline is
 that this is impossible at the moment...

 I guess this is becoming a higher priority issue which really needs to be
 solved somehow. :)

I'm looking at it right now actually, might as well sort it out while
people are paying attention. Patches a little later today unless I get
distrac^Winterrupted. :)


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to support SDIO wifi/bt in DT

[Olof Johansson]

On Thu, Jan 16, 2014 at 1:46 PM, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 16 January 2014 09:15:17 Olof Johansson wrote:

  b) We need to add a way to attach a device_node to an sdio_func,
  so that a function driver can find additional DT properties.
  This part should be relatively simple once (a) is done and
  should only need a little code but no new binding. The code
  would be similar to what we do for amba, i2c or spi devices.

 This isn't actually needed for this functionality, but might be needed
 for other things...


 There is at least one sdio driver (cw1200) that needs to get
 a MAC address from DT and has the same kind of hack that
 you mention to work around it at the moment (actually worse,
 it's not even using auxdata). The MAC address is certainly
 a property of the device, not the host. This is of course
 the same problem that we have on various development boards
 with USB ethernet controllers lacking an EEPROM.

Yeah, definitely overlap with the on-board usb ethernet adapters where
the vendor hasn't bothered with an eeprom.

 Getting the device to probe in the first place is more important,
 and this is a much simpler problem though.

Yes, agreed -- both needs solving but they're separate issues.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mmc: dw_mmc: use slot-gpio to handle cd pin

[Olof Johansson]

On Tue, Jan 14, 2014 at 7:58 AM, Kevin Hilman khil...@linaro.org wrote:
 On Thu, Jan 9, 2014 at 6:35 AM, Zhangfei Gao zhangfei@linaro.org wrote:
 Suggested by Jaehoon: Use slot-gpio to handle cd-gpio
 Add function dw_mci_of_get_cd_gpio to check cd-gpios from dts.
 mmc_gpio_request_cd and mmc_gpio_get_cd are used to handle cd pin

 Signed-off-by: Zhangfei Gao zhangfei@linaro.org
 Acked-by: Jaehoon Chung jh80.ch...@samsung.com

 The Samsung Arndale board started failing boot from MMC root tests
 starting with next-20140113 and I bisected it down to this patch.
 Reverting this patch on top of next-20140114 gets Arndale booting
 again from MMC.  Is there some supporting DT data that's missing for
 Arndale?

Rather, it looks like this patch changes behaviour and no longer uses
dw_mci_get_cd() to find out if there's a card attached -- it switches
to rely only on GPIO (see the last chunk in the patch). That seems
broken?


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: disable UHS on broadcom sdhci

[Olof Johansson]

Hi,

On Fri, Nov 15, 2013 at 03:56:22PM -0800, Grant Grundler wrote:
 From: Stephen Hurd sh...@broadcom.com
 
 Add two new quirks needed by BCM57785 card reader:
 SDHCI_QUIRK2_BROKEN_UHS:
 Disables all UHS modes.

This seems appropriate. You _could_ use SDHCI_QUIRK_MISSING_CAPS and
hardcode them instead, but it doesn't seem to be an improvement really.

 SDHCI_QUIRK2_BCM57785_CR:
 Bit twiddles some Broadcom-specific registers and supresses an error
 about the 64k bar0.

I think this can be done without spending a global SDHCI quirk bit. This
is just a one-time setup that needs to be done, isn't it? It's hard
to tell since there's no official errata described, but if it is, then
overriding the probe function is the way to go instead, flipping these
bits there and then call the regular probe.


[...]

 index 7a7fb4f..cf26c0f 100644
 --- a/drivers/mmc/host/sdhci.c
 +++ b/drivers/mmc/host/sdhci.c
 @@ -1144,6 +1144,27 @@ static void sdhci_set_clock(struct sdhci_host *host, 
 unsigned int clock)
   return;
   }
  
 + if (host-quirks2  SDHCI_QUIRK2_BCM57785_CR) {
 + u32 tmp;
 +
 + /*
 +  * Register descriptions from:
 +  * http://www.broadcom.com/collateral/pg/57785-PG103-R.pdf
 +  */

That's a 661 page document, that unfortunately doesn't really help decode any
of the bits below because they are all touching reserved or marked-internal
bits of registers. :-)

Still, good to see a doc link.

 + tmp = sdhci_readl(host, BCM57785_CR_MUX_CTL);
 + tmp = ~0x3000; /* bits 12:15 are reserved */
 + sdhci_writel(host, tmp, BCM57785_CR_MUX_CTL);
 + tmp = sdhci_readl(host, BCM57785_CR_CLK_CTL);
 + tmp = ~(0x01a03f30);   /* Internal debug for SD3.0 */
 + tmp |= (0x0050);
 +
 + if ((sdhci_readw(host, SDHCI_HOST_CONTROL2) 
 + SDHCI_CTRL_VDD_180)  (clock = 2))
 + tmp |= (124);
 + sdhci_writel(host, tmp, BCM57785_CR_CLK_CTL);
 + }
 +
   sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
  
   if (clock == 0)
[...]
 diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
 index 3e781b8..664003a 100644
 --- a/include/linux/mmc/sdhci.h
 +++ b/include/linux/mmc/sdhci.h
 @@ -98,6 +98,12 @@ struct sdhci_host {
  #define SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON(14)
  /* Controller has a non-standard host control register */
  #define SDHCI_QUIRK2_BROKEN_HOST_CONTROL (15)
 +/* UHS modes do not work */
 +#define SDHCI_QUIRK2_BROKEN_UHS  (16)
 +/* hacks for Broadcom-specific card reader bugs */
 +#define SDHCI_QUIRK2_BCM57785_CR (17)
 +#defineBCM57785_CR_MUX_CTL 0x198  /* Card Reader MUX control */
 +#defineBCM57785_CR_CLK_CTL 0x19c  /* Card Reader Clock Status/Ctl */

These two defines should not be in a global include file; they should likely go
in the c file instead.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/8] sdhci: Use threaded IRQ handler

[Olof Johansson]

Hi,

On Mon, Oct 21, 2013 at 8:25 AM, Jeremie Samuel
jeremie.samuel@parrot.com wrote:
 We only need atomic context to disable SDHCI interrupts, after that
 we can run in a kernel thread.

 Note that irq handler still grabs an irqsave spinlock, we'll deal
 with it in a subsequent patch.

 Patch based on: http://thread.gmane.org/gmane.linux.kernel.mmc/2579.

 Signed-off-by: Anton Vorontsov avoront...@mvista.com
 Signed-off-by: Jeremie Samuel jeremie.samuel@parrot.com

It seems like this patch is causing problems on Marvell Dove (such as
SolidRun Cubox). I've bisected a boot issue on that hardware down on
linux-next.

A good boot without this patch (i.e. with this patch reverted)
contains two spurious interrupts at probe time, both of them with
timeout+error set.

Below is the output with MMC_DEBUG turned on. Given the proximity to
the merge window, if we can't sort this out I think I'd prefer to see
this patch merged and retargeted to 3.14...


Good boot without this patch:

[0.962882] sdhci: Secure Digital Host Controller Interface driver
[0.969045] sdhci: Copyright(c) Pierre Ossman
[0.973375] sdhci-pltfm: SDHCI platform and OF driver helper
[0.979149] sdhci [sdhci_add_host()]: mmc0: Auto-CMD23 unavailable
[0.985320] mmc0: no vqmmc regulator found
[0.989396] mmc0: no vmmc regulator found
[0.993409] sdhci: === REGISTER DUMP (mmc0)===
[0.999221] sdhci: Sys addr: 0x | Version:  0x
[1.005035] sdhci: Blk size: 0x | Blk cnt:  0x
[1.010840] sdhci: Argument: 0x | Trn mode: 0x0001
[1.016656] sdhci: Present:  0x017f | Host ctl: 0x
[1.022461] sdhci: Power:0x000c | Blk gap:  0x
[1.028275] sdhci: Wake-up:  0x | Clock:0x0100
[1.034080] sdhci: Timeout:  0x000e | Int stat: 0x
[1.039888] sdhci: Int enab: 0x00ff0003 | Sig enab: 0x00ff0003
[1.045701] sdhci: AC12 err: 0x | Slot int: 0x
[1.051500] sdhci: Caps: 0x01e032b2 | Caps_1:   0x
[1.057313] sdhci: Cmd:  0x | Max curr: 0x
[1.063111] sdhci: Host ctl2: 0x
[1.067014] sdhci: ===
[1.073201] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width
0 timing 0
[1.094119] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 21
width 0 timing 0
[1.114117] mmc0: SDHCI controller on f1092000.sdio-host
[f1092000.sdio-host] using DMA
[1.122155] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
[1.128750] mmc0: starting CMD52 arg 0c00 flags 0195
[1.134710] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00018000
[1.140953] mmc0: Unexpected interrupt 0x8000.
[1.145717] sdhci: === REGISTER DUMP (mmc0)===
[1.151516] sdhci: Sys addr: 0x | Version:  0x
[1.157313] sdhci: Blk size: 0x | Blk cnt:  0x
[1.163110] sdhci: Argument: 0x0c00 | Trn mode: 0x0001
[1.168908] sdhci: Present:  0x01ff | Host ctl: 0x0001
[1.174705] sdhci: Power:0x000f | Blk gap:  0x
[1.180503] sdhci: Wake-up:  0x | Clock:0x4007
[1.186300] sdhci: Timeout:  0x000e | Int stat: 0x
[1.192099] sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083
[1.197903] sdhci: AC12 err: 0x | Slot int: 0x
[1.203702] sdhci: Caps: 0x01e032b2 | Caps_1:   0x
[1.209499] sdhci: Cmd:  0x341a | Max curr: 0x
[1.215295] sdhci: Host ctl2: 0x
[1.219191] sdhci: ===
[1.225037] mmc0: req done (CMD52): -110:    
[1.232144] mmc0: starting CMD52 arg 8c08 flags 0195
[1.237807] ata1: SATA link down (SStatus 0 SControl F300)
[1.243266] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00018000
[1.249503] mmc0: Unexpected interrupt 0x8000.
[1.254270] sdhci: === REGISTER DUMP (mmc0)===
[1.260069] sdhci: Sys addr: 0x | Version:  0x
[1.265866] sdhci: Blk size: 0x | Blk cnt:  0x
[1.271664] sdhci: Argument: 0x8c08 | Trn mode: 0x0001
[1.277462] sdhci: Present:  0x01ff | Host ctl: 0x0001
[1.283266] sdhci: Power:0x000f | Blk gap:  0x
[1.289064] sdhci: Wake-up:  0x | Clock:0x4007
[1.294862] sdhci: Timeout:  0x000e | Int stat: 0x
[1.300660] sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083
[1.306456] sdhci: AC12 err: 0x | Slot int: 0x
[1.312255] sdhci: Caps: 0x01e032b2 | Caps_1:   0x
[1.318052] sdhci: Cmd:  0x341a | Max curr: 0x
[1.323848] sdhci: Host ctl2: 0x
[1.327745] sdhci: ===


A bad boot with this patch applied instead only gives:

[0.962875] sdhci: Secure Digital 

Re: Shutdown regression due to mmc workqueue/locking changes

[Olof Johansson]

On Wed, Oct 30, 2013 at 2:05 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 When I run shutdown -h now in next-20131030, I get a hung task.

 git bisect shows that the first problem that shows up is due to 35a8fca
 mmc: sdhci: Turn tuning timeout timer into delayed work, which yields
 the following crash immediately that poweroff happens:

 [  76.314514] BUG: scheduling while atomic: halt/1367/0x0002
 [  76.320614] Modules linked in:
 [  76.323802] CPU: 2 PID: 1367 Comm: halt Not tainted 
 3.12.0-rc2-00141-g35a8fca #147
 [  76.331682] [c00158f0] (unwind_backtrace+0x0/0xf8) from [c00117a8] 
 (show_stack+0x10/0x14)
 [  76.340501] [c00117a8] (show_stack+0x10/0x14) from [c053a6a4] 
 (dump_stack+0x80/0xc4)
 [  76.348860] [c053a6a4] (dump_stack+0x80/0xc4) from [c0539034] 
 (__schedule_bug+0x48/0x60)
 [  76.357559] [c0539034] (__schedule_bug+0x48/0x60) from [c053eb8c] 
 (__schedule+0x64c/0x6d0)
 [  76.366404] [c053eb8c] (__schedule+0x64c/0x6d0) from [c053bb54] 
 (schedule_timeout+0x174/0x1ec)
 [  76.375552] [c053bb54] (schedule_timeout+0x174/0x1ec) from [c053e2d8] 
 (wait_for_common+0xb8/0x14c)
 [  76.385074] [c053e2d8] (wait_for_common+0xb8/0x14c) from [c0037ed4] 
 (__flush_work+0xa4/0x12c)
 [  76.394078] [c0037ed4] (__flush_work+0xa4/0x12c) from [c038677c] 
 (sdhci_do_set_ios+0x90/0x6fc)
 [  76.403220] [c038677c] (sdhci_do_set_ios+0x90/0x6fc) from [c0386e08] 
 (sdhci_set_ios+0x20/0x2c)
 [  76.412380] [c0386e08] (sdhci_set_ios+0x20/0x2c) from [c0374610] 
 (mmc_power_off+0x70/0x90)
 [  76.421212] [c0374610] (mmc_power_off+0x70/0x90) from [c03763a0] 
 (_mmc_suspend+0xb4/0x274)
 [  76.430037] [c03763a0] (_mmc_suspend+0xb4/0x274) from [c0375450] 
 (mmc_bus_shutdown+0x40/0x68)
 [  76.439129] [c0375450] (mmc_bus_shutdown+0x40/0x68) from [c029f324] 
 (device_shutdown+0x34/0x188)
 [  76.448478] [c029f324] (device_shutdown+0x34/0x188) from [c0044fcc] 
 (kernel_power_off+0x2c/0x70)
 [  76.457814] [c0044fcc] (kernel_power_off+0x2c/0x70) from [c00452b8] 
 (SyS_reboot+0x108/0x1d4)
 [  76.466812] [c00452b8] (SyS_reboot+0x108/0x1d4) from [c000e5e0] 
 (ret_fast_syscall+0x0/0x30)

 A few commits later, 769303b mmc: sdhci: Turn host-lock into a mutex
 changes this to a hang, followed by a hung task being detected:

 [ 240.870402] INFO: task kworker/1:1:70 blocked for more than 120 seconds.
 [ 240.877203]  Not tainted 3.12.0-rc7-next-20131030 #133
 [ 240.882886] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables 
 this message.
 [ 240.890824] kworker/1:1D c0554ec00   70 2 0x
 [ 240.897345] Workqueue: events sdhci_tuning_timeout_work
 [ 240.902734] [c0554ec0] (__schedule+0x300/0x674) from [c0555614] 
 (schedule_preempt_disabled+0x24/0x34)
 [ 240.912461] [c0555614] (schedule_preempt_disabled+0x24/0x34) from 
 [c0554034] (__mutex_lock_slowpath+0x17c/0x374)
 [ 240.923146] [c0554034] (__mutex_lock_slowpath+0x17c/0x374) from 
 [c0554238] (mutex_lock+0xc/0x24)
 [ 240.932430] [c0554238] (mutex_lock+0xc/0x24) from [c0393614] 
 (sdhci_tuning_timeout_work+0x14/0x2c)
 [ 240.941890] [c0393614] (sdhci_tuning_timeout_work+0x14/0x2c) from 
 [c00398b4] (process_one_work+0xfc/0x34c)
 [ 240.952033] [c00398b4] (process_one_work+0xfc/0x34c) from [c0039b28] 
 (process_scheduled_works+0x24/0x34)
 [ 240.961998] [c0039b28] (process_scheduled_works+0x24/0x34) from 
 [c0039ff4] (worker_thread+0x228/0x384)
 [ 240.971787] [c0039ff4] (worker_thread+0x228/0x384) from [c003f748] 
 (kthread+0xc4/0xe0)
 [ 240.980160] [c003f748] (kthread+0xc4/0xe0) from [c000e6f8] 
 (ret_from_fork+0x14/0x3c)
 [ 240.988366] INFO: task halt:1272 blocked for more than 120 seconds.
 [ 240.994724]  Not tainted 3.12.0-rc7-next-20131030 #133
 [ 241.000373] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables 
 this message.
 [ 241.008273] halt   D c0554ec00 1272  1270 0x
 [ 241.014820] [c0554ec0] (__schedule+0x300/0x674) from [c05521e4] 
 (schedule_timeout+0x174/0x1ec)
 [ 241.023919] [c05521e4] (schedule_timeout+0x174/0x1ec) from [c0554958] 
 (wait_for_common+0xb8/0x14c)
 [ 241.033359] [c0554958] (wait_for_common+0xb8/0x14c) from [c003839c] 
 (__flush_work+0xa4/0x12c)
 [ 241.042362] [c003839c] (__flush_work+0xa4/0x12c) from [c0396c4c] 
 (sdhci_do_set_ios+0x8c/0x6e8)
 [ 241.051448] [c0396c4c] (sdhci_do_set_ios+0x8c/0x6e8) from [c03972c8] 
 (sdhci_set_ios+0x20/0x2c)
 [ 241.060553] [c03972c8] (sdhci_set_ios+0x20/0x2c) from [c03846c0] 
 (mmc_power_off+0x5c/0x7c)
 [ 241.069275] [c03846c0] (mmc_power_off+0x5c/0x7c) from [c0386634] 
 (_mmc_suspend+0x194/0x2a0)
 [ 241.078110] [c0386634] (_mmc_suspend+0x194/0x2a0) from [c03855e8] 
 (mmc_bus_shutdown+0x40/0x68)
 [ 241.087339] [c03855e8] (mmc_bus_shutdown+0x40/0x68) from [c02acd38] 
 (device_shutdown+0x34/0x188)
 [ 241.096627] [c02acd38] (device_shutdown+0x34/0x188) from [c0044e94] 
 (kernel_power_off+0x2c/0x70)
 [ 241.105893] [c0044e94] (kernel_power_off+0x2c/0x70) from [c0045180] 
 (SyS_reboot+0x108/0x1d4)
 [ 241.114814] [c0045180] (SyS_reboot+0x108/0x1d4) from [c000e660] 
 

Re: [PATCH v2 1/4] rename ARCH_BCM to ARCH_BCM_MOBILE (mach-bcm)

[Olof Johansson]

Hi,

Replying here but since this is a part of your pull request. There's
still time to get this in since it's a fairly small self-contained
change, so let's try to get it right from the get-go. See comments
below.

On Mon, Sep 23, 2013 at 10:20 AM, Christian Daudt b...@fixthebug.org wrote:
 Currently ARCH_BCM has been used for Broadcom
 Mobile V7 based SoCs. In order to allow other Broadcom
 SoCs to also use mach-bcm directory and files, this patch
 renames the original ARCH_BCM to ARCH_BCM_MOBILE, and
 uses ARCH_BCM to define any Broadcom chip residing
 in mach-bcm directory.

 Signed-off-by: Christian Daudt b...@fixthebug.org
 Acked-by: Olof Johansson o...@lixom.net

 Changes from v1:
  - fix alpha ordering in dts/Makefile
  - break into 4 patches for separate subsys

 diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
 index 6e49310..efb0132 100644
 --- a/arch/arm/configs/bcm_defconfig
 +++ b/arch/arm/configs/bcm_defconfig
 @@ -27,6 +27,7 @@ CONFIG_MODULE_UNLOAD=y
  CONFIG_PARTITION_ADVANCED=y
  CONFIG_EFI_PARTITION=y
  CONFIG_ARCH_BCM=y
 +CONFIG_ARCH_BCM_MOBILE=y
  CONFIG_ARM_THUMBEE=y
  CONFIG_ARM_ERRATA_743622=y
  CONFIG_PREEMPT=y
 diff --git a/arch/arm/configs/multi_v7_defconfig 
 b/arch/arm/configs/multi_v7_defconfig
 index 6e572c6..89a5064 100644
 --- a/arch/arm/configs/multi_v7_defconfig
 +++ b/arch/arm/configs/multi_v7_defconfig
 @@ -6,6 +6,7 @@ CONFIG_ARCH_MVEBU=y
  CONFIG_MACH_ARMADA_370=y
  CONFIG_MACH_ARMADA_XP=y
  CONFIG_ARCH_BCM=y
 +CONFIG_ARCH_BCM_MOBILE=y
  CONFIG_GPIO_PCA953X=y
  CONFIG_ARCH_HIGHBANK=y
  CONFIG_ARCH_KEYSTONE=y
 diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
 index 69d67f7..af86cda 100644
 --- a/arch/arm/mach-bcm/Kconfig
 +++ b/arch/arm/mach-bcm/Kconfig
 @@ -1,5 +1,17 @@
  config ARCH_BCM
 -   bool Broadcom SoC if ARCH_MULTI_V7
 +   bool Broadcom SoC Support
 +   select ARCH_MULTIPLATFORM

This should be the other way around -- all other platforms seem to
depend on ARCH_MULTIPLATFORM instead of selecting it.

 +   help
 + This enables support for Broadcom ARM based SoC
 +  chips
 +
 +if ARCH_BCM
 +
 +menu Broadcom SoC Selection
 +
 +config ARCH_BCM_MOBILE
 +   bool Broadcom Mobile SoC if ARCH_MULTI_V7
 +   default y

This shouldn't be default y, since it makes it less obvious in configs
such as multi_v7_defconfig that the platform is enabled.

Also, since you have default y here, the addition of
CONFIG_ARCH_BCM_MOBILE=y in the defconfigs doesn't actually look
accurate, they would fall out. As a matter of fact, the patch after
this in your branch you requested us to merge removes them again. :)

 depends on MMU
 select ARCH_REQUIRE_GPIOLIB
 select ARM_ERRATA_754322
 @@ -14,7 +26,11 @@ config ARCH_BCM
 select TICK_ONESHOT
 select CACHE_L2X0
 help
 - This enables support for system based on Broadcom SoCs.
 + This enables support for systems based on Broadcom mobile SoCs.
   It currently supports the 'BCM281XX' family, which includes
   BCM11130, BCM11140, BCM11351, BCM28145 and
   BCM28155 variants.
 +
 +endmenu
 +
 +endif


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources

[Olof Johansson]

On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote:
 HWMOD removal for MMC is breaking edma_start as the events are being manually
 triggered due to unused channel list not being clear.

 The above issue is fixed by reading the dmas property from the DT node if it
 exists and clearing the bits in the unused channel list if the dma controller
 used by any device is EDMA. For this purpose we use the of_* helpers to parse
 the arguments in the dmas phandle list.

 Also introduced is a minor clean up of a checkpatch error in old code.

 Reviewed-by: Sekhar Nori nsek...@ti.com
 Reported-by: Balaji T K balaj...@ti.com
 Cc: Sekhar Nori nsek...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Olof Johansson o...@lixom.net
 Cc: Nishanth Menon n...@ti.com
 Cc: Pantel Antoniou pa...@antoniou-consulting.com
 Cc: Jason Kridner jkrid...@beagleboard.org
 Cc: Koen Kooi k...@dominion.thruhere.net
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
 Just resending this patch after discussing with Sekhar and Olof.

Actually, the patch you talked to me about was v3 of this. It seems
that you have reposted v6 but labelled it v3. This is very confusing.

 AM335x is being booted by many users such as the beaglebone community. DT is
 the only boot method available for all these users.  EDMA is required for the
 operation for many common peripherals in AM335x SoC such as McASP, MMC and
 Crypto.

 Although EDMA DT nodes are going in only for 3.13, in reality the kernel has
 been used for more than a year with EDMA code and out of tree EDMA DTS 
 patches.
 Hence though the DT nodes are still not in mainline, this patch can be still 
 be
 considered a critical fix as such and it would be great if it could be 
 included
 in 3.12-rc release. Thanks.

This is really the root of this problem. If you sit on code out of
tree for a year, and something breaks that we couldn't even have
detected since we didn't have the out-of-tree pieces. We'll help you
the first few times (such as now) but we will eventually stop caring.

If I was in a worse mood, then I'd just say that since your users
already has to have out-of-tree code to even use this functionality,
they could just add this fix on top of that stack of patches. But I'm
in a slightly better mood than that and I'll pick it up this time. :)

 More details about why this broke an existing feature folks were using:
 Previously the DMA resources for platform devices were being populated through
 HWMOD, however with the recent clean ups with HWMOD, this data has been moved
 to Device tree. The EDMA code though is not aware of this so it fails to fetch
 the DMA resources correctly which it needs to prepare the unused channel list
 (basically doesn't properly clear the channels that are in use, in the unused
 list).

So that we can learn for next time: What should we (as in us
maintainers and you TI) have done differently to avoid this?


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rename ARCH_BCM to ARCH_BCM_MOBILE

[Olof Johansson]

On Fri, Sep 20, 2013 at 4:04 PM, Christian Daudt c...@broadcom.com wrote:
 Currently ARCH_BCM has been used for Broadcom
 Mobile V7 based SoCs. In order to allow other Broadcom
 SoCs to also use mach-bcm directory and files, this patch
 renames the original ARCH_BCM to ARCH_BCM_MOBILE, and
 uses ARCH_BCM to define any Broadcom chip residing
 in mach-bcm directory.

 Signed-off-by: Christian Daudt c...@broadcom.com

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index cc0f1fb..dd00e22 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -42,8 +42,6 @@ dtb-$(CONFIG_ARCH_AT91)   += sama5d34ek.dtb
  dtb-$(CONFIG_ARCH_AT91)+= sama5d35ek.dtb

  dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 -dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb \
 -   bcm28155-ap.dtb
  dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 da850-evm.dtb
  dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 @@ -101,6 +99,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
 kirkwood-ts219-6282.dtb \
 kirkwood-openblocks_a6.dtb
  dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
 +dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm11351-brt.dtb \
 +   bcm28155-ap.dtb

This reordering looks off. The entries should be alphabetically
ordered, so if anything it should move up above BCM2835.


 diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
 index 704d6d3..4207ab4 100644
 --- a/drivers/clocksource/Makefile
 +++ b/drivers/clocksource/Makefile
 @@ -25,7 +25,7 @@ obj-$(CONFIG_SUN4I_TIMER) += sun4i_timer.o
  obj-$(CONFIG_ARCH_TEGRA)   += tegra20_timer.o
  obj-$(CONFIG_VT8500_TIMER) += vt8500_timer.o
  obj-$(CONFIG_ARCH_NSPIRE)  += zevio-timer.o
 -obj-$(CONFIG_ARCH_BCM) += bcm_kona_timer.o
 +obj-$(CONFIG_ARCH_BCM_MOBILE)  += bcm_kona_timer.o
  obj-$(CONFIG_CADENCE_TTC_TIMER)+= cadence_ttc_timer.o
  obj-$(CONFIG_CLKSRC_EXYNOS_MCT)+= exynos_mct.o
  obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)   += samsung_pwm_timer.o
 diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
 index 7fc5099..7e89650 100644
 --- a/drivers/mmc/host/Kconfig
 +++ b/drivers/mmc/host/Kconfig
 @@ -251,7 +251,7 @@ config MMC_SDHCI_S3C_DMA

  config MMC_SDHCI_BCM_KONA
 tristate SDHCI support on Broadcom KONA platform
 -   depends on ARCH_BCM
 +   depends on ARCH_BCM_MOBILE
 select MMC_SDHCI_PLTFM
 help
   This selects the Broadcom Kona Secure Digital Host Controller

Since nothing breaks (i.e. ARCH_BCM is still there, and will be
enabled for any ARCH_BCM_MOBILE platform), the above two can go
through the corresponding subsystem trees as separate patches.


With the above fixed:

Acked-by: Olof Johansson o...@lixom.net



-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dts: Fix misspelling of Synopsys

[Olof Johansson]

On Mon, Sep 16, 2013 at 03:57:48PM -0500, dingu...@altera.com wrote:
 From: Dinh Nguyen dingu...@altera.com
 
 s/Synopsis/Synopsys
 s/synopsis/synopsys
 
 Signed-off-by: Dinh Nguyen dingu...@altera.com
 Cc: Pavel Machek pa...@denx.de
 CC: Arnd Bergmann a...@arndb.de
 CC: Olof Johansson o...@lixom.net
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Ian Campbell ian.campb...@citrix.com
 Cc: Chris Ball c...@laptop.org
 Cc: Jaehoon Chung jh80.ch...@samsung.com
 Cc: Seungwon Jeon tgih@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: devicet...@vger.kernel.org
 Cc: linux-mmc@vger.kernel.org
 CC: linux-arm-ker...@lists.infradead.org

Acked-by: Olof Johansson o...@lixom.net


Looks like this is best taken through the DT tree, but if they don't have any
other fixes we can take it through arm-soc, just let me know.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: dw_mmc-exynos: Common bindings for dw-mshc timing

[Olof Johansson]

On Mon, Aug 12, 2013 at 05:15:01PM -0600, Stephen Warren wrote:
 On 08/08/2013 04:55 PM, dingu...@altera.com wrote:
  From: Dinh Nguyen dingu...@altera.com
  
  Remove the samsung in samsung,dw-mshc-ciu-div, 
  samsung,dw-mshc-sdr-timing,
  and samsung,dw-mshc-ddr-timing. These characteristics are not applicable 
  to
  just Samsung platforms, but to any platform that uses the Synopsis SD/MMC 
  IP.
 
 But the properties aren't globally standard; they apply specifically
 anywhere that this particular Synopsis IP is present. As such, I think
 at least a synopsis, prefix is warranted.

A prefix is only really needed when a vendor is making a vendor-specific
extension on a shared binding. Since the whole binding is
synopsis-specific, I don't think there's need for a prefix here.

 And the driver should probably support both the old and new property
 names for backwards-compatibility?

Yes, that sounds appropriate if the binding is considered stable and
otherwise good.

The alternative is to have everybody just use the samsung,*
properties. There's nothing wrong with that per se, besides the fact
that if it had been caught when creating the binding, there should have
been no prefix and the properties should have been common.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dw_mmc: Does anyone use multiple slots?

[Olof Johansson]

On Thu, Aug 8, 2013 at 5:16 PM, Doug Anderson diand...@google.com wrote:

 I guess my overall question is: if there are no actual implementations
 of multislot, shouldn't we kill it and simplify the code a whole lot?
 If someone out there has a real multislot device they can step back in
 and do it more correctly?

 Of course we need to find someone to actually go through and do the
 killing of multislot, but finding that person might be easier if there
 was some agreement that it was good to do.

There clearly seems to be no in-tree users of multislot. If someone
new comes in, we have the code in the history and can revert the
removal (or at least use it as reference for re-introduction).

I vote for removing it. It adds really annoying complexity for
something that nobody uses.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: tmio: fix compiler warning

[Olof Johansson]

On Mon, Jul 8, 2013 at 2:38 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 This patch fixes a compiler warning:

 drivers/mmc/host/tmio_mmc_pio.c: In function 'tmio_mmc_power_on':
 drivers/mmc/host/tmio_mmc_pio.c:798:19: warning: ignoring return value of
 'regulator_enable', declared with attribute warn_unused_result 
 [-Wunused-result]

 Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com

Acked-by: Olof Johansson o...@lixom.net

Chris, this warniong is staring at me from my inbox every morning.
Would you mind picking it up for 3.11?


Thanks!

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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: pxa: propagate errors from regulator_enable() to pxamci

[Olof Johansson]

On Fri, Jul 5, 2013 at 8:53 AM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Fri, Jul 05 2013, Arnd Bergmann wrote:
 The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
 call regulator_enable(), which may return an error that must
 be checked.

 This changes the em_x270_usb_hub_init() function to bail out
 if it fails, and changes the pxamci_platform_data-setpower
 callback so that the a failed em_x270_mci_setpower call
 can be propagated by the pxamci driver into the mmc core.

 Signed-off-by: Arnd Bergmann a...@arndb.de

 For pxamci:

 Acked-by: Chris Ball c...@laptop.org

Applied with your ack to arm-soc fixes branch for 3.11, after fixing
the set/test ordering pointed out in the thread.

Thanks!

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support

[Olof Johansson]

On Tue, Jul 16, 2013 at 10:20:41AM +0900, Simon Horman wrote:
 On Wed, Jul 10, 2013 at 11:09:12AM +0900, Simon Horman wrote:
  From: Guennadi Liakhovetski g.liakhovet...@gmx.de
  
  On platforms with no support for the shdma dmaengine driver build is
  currently failing with
  
  drivers/built-in.o: In function `sh_mobile_sdhi_probe':
  drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference 
  to`shdma_chan_filter'
  
  Fix the breakage by defining shdma_chan_filter to NULL in such
  configurations.
  
  Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
  [horms+rene...@verge.net.au: Apply change to shdma-base.h instead of 
  sh_dma.h]
  Signed-off-by: Simon Horman horms+rene...@verge.net.au
  ---
   include/linux/shdma-base.h | 4 
   1 file changed, 4 insertions(+)
 
  
  Hi Vinod,
  
  please consider this fix from Guennadi for v3.11 which I have rebased on 
  top of
  next-20130709. It fixes a build problem on a number of shmobile defconfigs
  including bockw.
 
 Ping.
 
 Would it be appropriate for me to take this change through my tree?
 It seems to resolve a regression in v3.11-rc1.

I'll take it through arm-soc since there's no response from Vinod. I've
applied it in the fixes branch we have.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fix for v3.11 (repost)] dmaengine: shdma: fix a build failure on platforms with no DMA support

[Olof Johansson]

On Thu, Jul 18, 2013 at 08:50:58AM +0900, Simon Horman wrote:
 From: Guennadi Liakhovetski g.liakhovet...@gmx.de
 
 On platforms with no support for the shdma dmaengine driver build is
 currently failing with
 
 drivers/built-in.o: In function `sh_mobile_sdhi_probe':
 drivers/mmc/host/sh_mobile_sdhi.c:170: undefined reference 
 to`shdma_chan_filter'
 
 Fix the breakage by defining shdma_chan_filter to NULL in such
 configurations.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
 [horms+rene...@verge.net.au: Apply change to shdma-base.h instead of sh_dma.h]
 Signed-off-by: Simon Horman horms+rene...@verge.net.au
 ---
  include/linux/shdma-base.h | 4 
  1 file changed, 4 insertions(+)
 
 Hi Vinod,
 
 please consider this fix from Guennadi for v3.11 which I have rebased on top 
 of
 next-20130709. It fixes a build problem on a number of shmobile defconfigs
 including bockw.
 
 Alternatively, I would be happy to take this through the renesas tree.
 
 I posted this patch last week but I'm wondering if you missed it somehow.
 This patch resolves a regression in v3.11-rc1.

As mentioned on the other thread, I have applied this in the arm-soc fixes
branch for 3.11 now.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: shdma: fix a build failure on platforms with no DMA support

[Olof Johansson]

On Thu, Jul 4, 2013 at 9:53 PM, Vinod Koul vinod.k...@intel.com wrote:
 On Wed, Jun 19, 2013 at 09:32:18PM +0200, Guennadi Liakhovetski wrote:
 Hi Vinod

 On Wed, 19 Jun 2013, Kevin Hilman wrote:

  On Thu, May 30, 2013 at 7:44 PM, Simon Horman ho...@verge.net.au wrote:
 
  [...]
 
   thanks for this. I will wait for a refresh (as we discussed earlier 
   today).
   Can I confirm that this is a fix for v3.10? If so, could ou note
   that when you post your revised patch?
 
  Any progress on this patch?
 
  The SH-mobile defconfigs are still all failing in linux-next.

 In

 https://patchwork.kernel.org/patch/2640061/
 And you havent CC maintainers on this patch, so I dont have it!

 I proposed a simple immediate fix for this problem. Arnd at the same time
 developed an alternative solution:

 https://patchwork.kernel.org/patch/2644121/
 https://patchwork.kernel.org/patch/2644111/
 Reading these patches I agree with Arnd that client drivers should not depend 
 on
 dma slave drivers. Existing issue need to be fixed

 Arnd, Have you merged these changes?

Looks like we now have breakage in linux-next for this again (new
breakage due to the header file move being applied by you on Friday,
Vinod? Are you planning on sending the code in for 3.11? If not, you
shouldn't apply patches right now).

bockw_defconfig, kota2_defconfig, marzen_defconfig and others are
currently broken.

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: core: Fixup Oops for SDIO shutdown

[Olof Johansson]

On Tue, Jul 2, 2013 at 8:15 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 07/02/2013 04:53 AM, Ulf Hansson wrote:
 Commit mmc: core: Handle card shutdown from mmc_bus introduced an
 Oops in the shutdown sequence for SDIO.

 The drv pointer, does not exist for SDIO since the probing of the SDIO
 card from the mmc_bus perspective is expected to fail by returning
 -ENODEV.

 This patch adds the proper check for the pointer before calling it.

 Tested-by: Stephen Warren swar...@nvidia.com

Acked-by: Olof Johansson o...@lixom.net

Chris, I hit this on the 0705 linux-next. Can you pick up this patch
soonish please? Thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: core: Fixup Oops for SDIO shutdown

[Olof Johansson]

On Sun, Jul 7, 2013 at 10:25 AM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Sun, Jul 07 2013, Olof Johansson wrote:
 On Tue, Jul 2, 2013 at 8:15 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 07/02/2013 04:53 AM, Ulf Hansson wrote:
 Commit mmc: core: Handle card shutdown from mmc_bus introduced an
 Oops in the shutdown sequence for SDIO.

 The drv pointer, does not exist for SDIO since the probing of the SDIO
 card from the mmc_bus perspective is expected to fail by returning
 -ENODEV.

 This patch adds the proper check for the pointer before calling it.

 Tested-by: Stephen Warren swar...@nvidia.com

 Acked-by: Olof Johansson o...@lixom.net

 Chris, I hit this on the 0705 linux-next. Can you pick up this patch
 soonish please? Thanks!

 Sorry for the delay -- I merged this on Friday, so it'll be in
 tonight's -next.

Great, thanks!


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 1/2] ARM: davinci: move private EDMA API to arm/common

[Olof Johansson]

On Mon, Jun 17, 2013 at 03:36:10PM +0530, Sekhar Nori wrote:
 From: Matt Porter mpor...@ti.com
 
 Move mach-davinci/dma.c to common/edma.c so it can be used
 by OMAP (specifically AM33xx) as well.
 
 Signed-off-by: Matt Porter mpor...@ti.com
 Acked-by: Chris Ball c...@laptop.org # davinci_mmc.c
 [nsek...@ti.com: dropped davinci sffsdr changes]
 Signed-off-by: Sekhar Nori nsek...@ti.com

Acked-by: Olof Johansson o...@lixom.net

Tiny nit below, no need to respin just for that.

I suppose we should take this through arm-soc.

 ---
  arch/arm/Kconfig   |1 +
  arch/arm/common/Kconfig|3 +
  arch/arm/common/Makefile   |1 +
  arch/arm/{mach-davinci/dma.c = common/edma.c} |2 +-
  arch/arm/mach-davinci/Makefile |2 +-
  arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
  arch/arm/mach-davinci/davinci.h|2 +-
  arch/arm/mach-davinci/devices-tnetv107x.c  |2 +-
  arch/arm/mach-davinci/devices.c|6 +-
  arch/arm/mach-davinci/dm355.c  |2 +-
  arch/arm/mach-davinci/dm365.c  |2 +-
  arch/arm/mach-davinci/dm644x.c |2 +-
  arch/arm/mach-davinci/dm646x.c |2 +-
  arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
  drivers/dma/edma.c |2 +-
  drivers/mmc/host/davinci_mmc.c |1 +
  include/linux/mfd/davinci_voicecodec.h |3 +-
  .../mach = include/linux/platform_data}/edma.h|   89 
 +---
  include/linux/platform_data/spi-davinci.h  |2 +-
  sound/soc/davinci/davinci-evm.c|1 +
  sound/soc/davinci/davinci-pcm.c|1 +
  sound/soc/davinci/davinci-pcm.h|2 +-
  22 files changed, 29 insertions(+), 103 deletions(-)
  rename arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)
  rename {arch/arm/mach-davinci/include/mach = 
 include/linux/platform_data}/edma.h (59%)
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index 49d993c..b1c66a4 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -840,6 +840,7 @@ config ARCH_DAVINCI
   select GENERIC_IRQ_CHIP
   select HAVE_IDE
   select NEED_MACH_GPIO_H
 + select TI_PRIV_EDMA

What does PRIV here mean? Privileged? Private? I think it can be shortened to
TI_EDMA.

   select USE_OF
   select ZONE_DMA
   help
 diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
 index 9353184..c3a4e9c 100644
 --- a/arch/arm/common/Kconfig
 +++ b/arch/arm/common/Kconfig
 @@ -17,3 +17,6 @@ config SHARP_PARAM
  
  config SHARP_SCOOP
   bool
 +
 +config TI_PRIV_EDMA
 + bool
 diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
 index 48434cb..8c60f47 100644
 --- a/arch/arm/common/Makefile
 +++ b/arch/arm/common/Makefile
 @@ -16,3 +16,4 @@ obj-$(CONFIG_ARM_TIMER_SP804)   += timer-sp.o
  obj-$(CONFIG_MCPM)   += mcpm_head.o mcpm_entry.o mcpm_platsmp.o 
 vlock.o
  AFLAGS_mcpm_head.o   := -march=armv7-a
  AFLAGS_vlock.o   := -march=armv7-a
 +obj-$(CONFIG_TI_PRIV_EDMA)   += edma.o



--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 1/2] ARM: davinci: move private EDMA API to arm/common

[Olof Johansson]

On Mon, Jun 17, 2013 at 10:55 AM, Fernandes, Joel A joelag...@ti.com wrote:
 Hi Olof,

 -Original Message-
 From: Olof Johansson [mailto:o...@lixom.net]
 Sent: Monday, June 17, 2013 12:03 PM
 To: Nori, Sekhar
 Cc: Russell King; Vinod Koul; Chris Ball; Liam Girdwood; Mark Brown; Kevin
 Hilman; Matt Porter; Fernandes, Joel A; linux-arm-ker...@lists.infradead.org;
 davinci-linux-open-sou...@linux.davincidsp.com; linux-mmc@vger.kernel.org;
 alsa-de...@alsa-project.org; Arnd Bergmann
 Subject: Re: [PATCH v10 1/2] ARM: davinci: move private EDMA API to
 arm/common

 On Mon, Jun 17, 2013 at 03:36:10PM +0530, Sekhar Nori wrote:
  From: Matt Porter mpor...@ti.com
 
  Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP
  (specifically AM33xx) as well.
 
  Signed-off-by: Matt Porter mpor...@ti.com
  Acked-by: Chris Ball c...@laptop.org # davinci_mmc.c
  [nsek...@ti.com: dropped davinci sffsdr changes]
  Signed-off-by: Sekhar Nori nsek...@ti.com

 Acked-by: Olof Johansson o...@lixom.net

 Tiny nit below, no need to respin just for that.

 I suppose we should take this through arm-soc.

  ---
   arch/arm/Kconfig   |1 +
   arch/arm/common/Kconfig|3 +
   arch/arm/common/Makefile   |1 +
   arch/arm/{mach-davinci/dma.c = common/edma.c} |2 +-
   arch/arm/mach-davinci/Makefile |2 +-
   arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
   arch/arm/mach-davinci/davinci.h|2 +-
   arch/arm/mach-davinci/devices-tnetv107x.c  |2 +-
   arch/arm/mach-davinci/devices.c|6 +-
   arch/arm/mach-davinci/dm355.c  |2 +-
   arch/arm/mach-davinci/dm365.c  |2 +-
   arch/arm/mach-davinci/dm644x.c |2 +-
   arch/arm/mach-davinci/dm646x.c |2 +-
   arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
   drivers/dma/edma.c |2 +-
   drivers/mmc/host/davinci_mmc.c |1 +
   include/linux/mfd/davinci_voicecodec.h |3 +-
   .../mach = include/linux/platform_data}/edma.h|   89 
  +---
   include/linux/platform_data/spi-davinci.h  |2 +-
   sound/soc/davinci/davinci-evm.c|1 +
   sound/soc/davinci/davinci-pcm.c|1 +
   sound/soc/davinci/davinci-pcm.h|2 +-
   22 files changed, 29 insertions(+), 103 deletions(-)  rename
  arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)  rename
  {arch/arm/mach-davinci/include/mach =
  include/linux/platform_data}/edma.h (59%)
 
  diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
  49d993c..b1c66a4 100644
  --- a/arch/arm/Kconfig
  +++ b/arch/arm/Kconfig
  @@ -840,6 +840,7 @@ config ARCH_DAVINCI
  select GENERIC_IRQ_CHIP
  select HAVE_IDE
  select NEED_MACH_GPIO_H
  +   select TI_PRIV_EDMA

 What does PRIV here mean? Privileged? Private? I think it can be shortened to
 TI_EDMA.

  [Joel] TI_EDMA already exists. It is used to build drivers/dma/edma.
 I have a patch that reuses the TI_EDMA option instead of the PRIV one . I will
 include that In my v11 series for EDMA (v10 was just posted) . If its ok, let 
 us
 merge Sekhar's patch as-is, and then mine will get rid of the PRIV option
 (among other things).

Ok, fair enough. As I said, small nit.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/7] clk: add basic Rockchip rk3066a clock support

[Olof Johansson]

On Thu, Jun 13, 2013 at 12:45:41AM +0200, Heiko Stübner wrote:
 Part of me simply wants to wait for this - but rockchip stuff might be to 
 late 
 for 3.11 anyway, as we're near rc6.

For a new platform like this, it's useful to get some of the drivers to land
even if the main platform code isn't. Where things tend to get messy is when we
have to add a lot of code late in the cycle that has a lot of external
dependencies, since everybody then has to scramble about getting things sorted
out.

It's not too late for 3.11 yet, and in particular it'd be nice to see things
like clock and pinctrl stuff go in even if some other stuff misses the train.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv6 6/6] mmc: dw_mmc: Add support DW SD/MMC driver on SOCFPGA

[Olof Johansson]

Hi,

On Wed, Jun 05, 2013 at 10:02:58AM -0500, dingu...@altera.com wrote:
 From: Dinh Nguyen dingu...@altera.com
 
 Add platform specific functionality for the DW SD/MMC driver for
 SoCFPGA. Move SDMMC_CMD_USE_HOLD_REG to dw_mmc.h so other platforms
 can use this define.
 
 Signed-off-by: Dinh Nguyen dingu...@altera.com
 CC: Seungwon Jeon tgih@samsung.com
 CC: Jaehoon Chung jh80.ch...@samsung.com
 CC: Arnd Bergmann a...@arndb.de
 CC: Olof Johansson o...@lixom.net
 CC: Pavel Machek pa...@denx.de
 CC: linux-mmc@vger.kernel.org

Acked-by: Olof Johansson o...@lixom.net

This one should be sent to (and applied by) Chris Ball, the MMC maintainer. The
driver is standalone and can go in independently on the platform code that will
configure it, so he can merge it without dependencies.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv6 6/6] mmc: dw_mmc: Add support DW SD/MMC driver on SOCFPGA

[Olof Johansson]

On Tue, Jun 11, 2013 at 07:08:16PM -0500, Dinh Nguyen wrote:
 Hi Olof,
 
 On Tue, 2013-06-11 at 16:27 -0700, Olof Johansson wrote:
  Hi,
  
  On Wed, Jun 05, 2013 at 10:02:58AM -0500, dingu...@altera.com wrote:
   From: Dinh Nguyen dingu...@altera.com
   
   Add platform specific functionality for the DW SD/MMC driver for
   SoCFPGA. Move SDMMC_CMD_USE_HOLD_REG to dw_mmc.h so other platforms
   can use this define.
   
   Signed-off-by: Dinh Nguyen dingu...@altera.com
   CC: Seungwon Jeon tgih@samsung.com
   CC: Jaehoon Chung jh80.ch...@samsung.com
   CC: Arnd Bergmann a...@arndb.de
   CC: Olof Johansson o...@lixom.net
   CC: Pavel Machek pa...@denx.de
   CC: linux-mmc@vger.kernel.org
  
  Acked-by: Olof Johansson o...@lixom.net
  
  This one should be sent to (and applied by) Chris Ball, the MMC maintainer. 
  The
  driver is standalone and can go in independently on the platform code that 
  will
  configure it, so he can merge it without dependencies.
 
 Thanks Olof. I will send to Chris Ball. I kinda thought that since
 Jaehoon and Seungwon were maintainers of the dw_mmc driver that I didn't
 need to send to Chris.

Ah, no, it should probably go up through his tree in this case. It's
still good to have their Acked-by though, since they know the details
of the DW side.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 12/13] mmc: add DT bindings for more MMC capability flags

[Olof Johansson]

Hi,


On Fri, Feb 15, 2013 at 7:14 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Many MMC capability flags are platform-dependent and are traditionally set
 in platform data. With DT often each such capability requires a special
 binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED,
 MMC_CAP_POWER_OFF_CARD and MMC_CAP_SDIO_IRQ capabilities. Also add code to
 DT parser to look up keep-power-in-suspend and enable-sdio-wakeup
 bindings and set MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively,
 if found.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

I just came across this patch after it was merged (with no review from
any device tree maintainer :()

 ---
  Documentation/devicetree/bindings/mmc/mmc.txt |4 
  drivers/mmc/core/host.c   |   13 +
  2 files changed, 17 insertions(+), 0 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
 b/Documentation/devicetree/bindings/mmc/mmc.txt
 index 24c8552..d9ab51f 100644
 --- a/Documentation/devicetree/bindings/mmc/mmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
 @@ -25,6 +25,10 @@ Optional properties:
  - max-frequency: maximum operating clock frequency
  - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
 +- cap-sd-highspeed: SD high-speed timing is supported
 +- cap-mmc-highspeed: MMC high-speed timing is supported
 +- cap-power-off-card: powering off the card is safe
 +- cap-sdio-irq: enable SDIO IRQ signalling on this interface

These are bad names for describing hardware properties. There is no
reason to carry over the cap prefix from the internal usage of the
hardware characteristics in the kernel.

Other drivers use, for example supports-highspeed, which this
duplicates to some extent. More work should have been done to
commonalize them. Etc.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] clk: add basic Rockchip rk3066a clock support

[Olof Johansson]

On Mon, Jun 03, 2013 at 01:00:31AM +0200, Heiko Stübner wrote:
 This adds basic support for clocks on Rockchip rk3066 SoCs.
 The clock handling thru small dt nodes is heavily inspired by the
 sunxi clk code.
 
 The clock specifiers are named as x-cortex-a9-x, because the clock
 semantics are the same thru the whole cortex-a9 series (rk30xx,
 rk3188, rk2928; but not the other rk29 SoCs, which are Cortex-A8 based).

Hi,

I think you're better off naming them after the first SoC of that series.
Otherwise, if there's an A9-based platform in the future that is not
compatible, things will get complicated.

It's pretty common that we do this for other kinds of devices, so it seems
appropriate for clock drivers too.


-Olof

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] mmc: dw_mmc: Add disable-wp device tree property

[Olof Johansson]

On Fri, Jan 11, 2013 at 09:03:50AM -0800, Doug Anderson wrote:
 The disable-wp property is used to specify that a given SD card slot
 doesn't have a concept of write protect.  This eliminates the need for
 special case code for SD slots that should never be write protected
 (like a micro SD slot or a dev board).
 
 The dw_mmc driver is special in needing to specify disable-wp
 because the lack of a wp-gpios property means to use the special
 purpose write protect line.  On some other mmc devices the lack of
 wp-gpios means that write protect should be disabled.
 
 Signed-off-by: Doug Anderson diand...@chromium.org
 Acked-by: Seungwon Jeon tgih@samsung.com

Acked-by: Olof Johansson o...@lixom.net

Nit below.

 @@ -825,7 +828,13 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
   struct dw_mci_board *brd = slot-host-pdata;
  
   /* Use platform get_ro function, else try on board write protect */
 - if (brd-quirks  DW_MCI_QUIRK_NO_WRITE_PROTECT)
 +
 + /*
 +  * NOTE: DW_MCI_QUIRK_NO_WRITE_PROTECT will be removed in a future
 +  * patch in the series once reference to it is removed.
 +  */
 + if ((brd-quirks  DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
 + (slot-quirks  DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))

Given that it never worked properly, you could have nuked it first and avoid
the extra churn. Still, not a strong enough reason to respin the series, IMHO.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] mmc: dw_mmc: exynos: Remove code for wp-gpios

[Olof Johansson]

On Fri, Jan 11, 2013 at 09:03:52AM -0800, Doug Anderson wrote:
 The exynos code claimed the write protect with devm_gpio_request() but
 never did anything with it.  That meant that anyone using a write
 protect GPIO would effectively be write protected all the time.
 
 The handling for wp-gpios belongs in the main dw_mmc driver and has
 been moved there.
 
 Signed-off-by: Doug Anderson diand...@chromium.org
 Acked-by: Seungwon Jeon tgih@samsung.com

Acked-by: Olof Johansson o...@lixom.net


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/5] ARM: dts: Add disable-wp for sd card slot on smdk5250

[Olof Johansson]

On Fri, Jan 11, 2013 at 09:03:51AM -0800, Doug Anderson wrote:
 The next change will remove the code from the dw_mmc-exynos that added
 the DW_MCI_QUIRK_NO_WRITE_PROTECT.  Keep existing functionality of
 having no write protect pin on smdk5250 by adding the disable-wp
 property.
 
 Signed-off-by: Doug Anderson diand...@chromium.org
 Acked-by: Seungwon Jeon tgih@samsung.com

Acked-by: Olof Johansson o...@lixom.net


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/5] mmc: dw_mmc: Handle wp-gpios from device tree

[Olof Johansson]

On Fri, Jan 11, 2013 at 09:03:53AM -0800, Doug Anderson wrote:
 On some SoCs (like exynos5250) you need to use an external GPIO for
 write protect.  Add support for wp-gpios to the core dw_mmc driver
 since it could be useful across multiple SoCs.
 
 With this change I am able to make use of the write protect for the
 external SD slot on exynos5250-snow.
 
 Signed-off-by: Doug Anderson diand...@chromium.org
 Acked-by: Seungwon Jeon tgih@samsung.com

Acked-by: Olof Johansson o...@lixom.net
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT

[Olof Johansson]

On Fri, Jan 11, 2013 at 09:03:54AM -0800, Doug Anderson wrote:
 The original quirk was added in the change 'mmc: dw_mmc: add quirk to
 indicate missing write protect line'.  The original quirk was added at
 a controller level even though each slot has its own write protect (so
 the quirk should be at the slot level).  A recent change (mmc: dw_mmc:
 Add disable-wp device tree property) added a slot-level quirk and
 support for the quirk directly to dw_mmc.
 
 Signed-off-by: Doug Anderson diand...@chromium.org

Acked-by: Olof Johansson o...@lixom.net
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REPOST PATCH v3 1/4] mmc: dw_mmc: Add disable-wp device tree property

[Olof Johansson]

On Thu, Jan 10, 2013 at 10:24:26AM -0800, Doug Anderson wrote:
 The disable-wp property is used to specify that a given SD card slot
 doesn't have a concept of write protect.  This eliminates the need for
 special case code for SD slots that should never be write protected
 (like a micro SD slot or a dev board).
 
 The dw_mmc driver is special in needing to specify disable-wp
 because the lack of a wp-gpios property means to use the special
 purpose write protect line.  On some other mmc devices the lack of
 wp-gpios means that write protect should be disabled.

Hi,

The previous code used the controller-common quirk field to set a
per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to
do this per-slot? And if so, please explain in the commit message why
there is need for a brand new quirk for the same functionality.

It's even uncertain if there are any systems out there that uses the
multi-slot functionality of this driver to date, most seem to map one
slot per controller in the first place...


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL v2] at91: fixes for 3.7-rc7

[Olof Johansson]

Hi,


On Tue, Nov 20, 2012 at 09:59:27AM +0100, Nicolas Ferre wrote:
 Arnd, Olof,
 
 Just for the record, I do not want to put pressure at a such late time in
 the 3.7-rc process. So, I just reworked that pull-request because the previous
 one was wrong:
 - wrong patch content (DT nodes with wrong size)
 - not all tags in patches (Jean-Christophe and Arnd tags were missing...)
 
 Just to start from a sane base if I have to rebase this work for 3.8, I let 
 you know
 that I have updated this tag...
 
 The following changes since commit 641f3ce64b050961d454a0716bb6dbf528315aac:
 
   ARM: at91/usbh: fix overcurrent gpio setup (2012-11-16 10:46:29 +0100)
 
 are available in the git repository at:
 
   git://github.com/at91linux/linux-at91.git tags/at91-fixes

The new patches seem to belong in an at91/dt branch, not in a fixes one.

I can pull in the previous fixes branch as an at91/fixes-non-critical for 3.8
if you want. There's no need to rebase them for this, is there? What is the
pinctrl dependency that you are talking about, are some of these patches needed
as prerequisites for pinctrl changes or the other way around?

Sorry if I've missed more elaborate emails on this and are asking repeat
questions. ;)

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] at91: fixes for 3.7-rc7

[Olof Johansson]

Hi Nicolas,

On Mon, Nov 19, 2012 at 8:31 AM, Nicolas Ferre nicolas.fe...@atmel.com wrote:
 Arnd, Olof,

 Here is another fixes pull request for AT91. It enables the sd/mmc driver
 for Device Tree enabled platforms. Those patches where part of a series that
 was split in two for reaching upstream: the MMC part is already in Linus' tree
 and this is the arm-soc part.
 I have placed these patches on top of the fixes that you already have for 
 AT91.

What regressions do these fixes resolve?

It looks more like they are DT-enablement patches to me, and thus 3.8
material, not 3.7. I'll be happy to queue them up in next/dt though.

Thanks,

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support

[Olof Johansson]

Hi,

On Fri, Sep 21, 2012 at 9:53 AM, Shawn Guo shawn@linaro.org wrote:
 On Sat, Sep 22, 2012 at 12:46:26AM +0800, Shawn Guo wrote:
 I just published the branch below with this series rebased on top of
 the necessary dependant branches.

   git://git.linaro.org/people/shawnguo/linux-2.6.git 
 staging/imx-multiplatform

 The dependant branches include:


 Forgot the base:

   * arm-soc/next/multiplatform

 Shawn

 * arm-soc/multiplatform/platform-data

 * arm-soc/multiplatform/smp_ops

 * git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7

   It contains dependant patch ASoC: mx27vis: retrieve gpio numbers
   from platform_data

 * git://git.infradead.org/mtd-2.6.git master

   The series is based on this tree to solve some non-trivial conflicts
   on mxc_nand driver.  Because mtd tree completely missed 3.6 merge
   window, having the series base on 3.6-rc actually means 3.5 code base
   in term of mtd support.  There are currently two cycles changes
   accumulated on mtd, and we need to base the series on it to sort out
   the conflicts.

 * git://linuxtv.org/mchehab/media-next.git master

   The media tree renames mx2/mx3 camera drivers twice.  I'm not sure
   if git merge can detect them, so I just rebased the series on media
   tree to solve that.  The bonus point is that a number of trivial
   conflicts with imx27-coda support on media tree gets solved as well.

 I'm not requesting you to pull the branch into arm-soc as a stable
 branch but staging one, because the external dependencies which might
 not be stable.  I attempt to use it for exposing the series on
 linux-next, so that we can send it to Linus for 3.7 if there is chance
 for us to (e.g. all the dependant branches hit mainline early during
 3.7 merge window).

I've pulled this in now as staging/imx-multiplatform.

As you mention, it might or might not make sense to send this up. It
also accrued a few more merge conflicts with other branches in
arm-soc, so we'll see how things play out.

Either way, we'll for sure queue it for 3.8.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support

[Olof Johansson]

On Fri, Sep 21, 2012 at 1:01 AM, Shawn Guo shawn@linaro.org wrote:
 On Thu, Sep 20, 2012 at 03:56:56PM +, Arnd Bergmann wrote:
 Ok, fair enough. I think we can put it in arm-soc/for-next as a staging
 branch anyway to give it some exposure to linux-next, and then we can
 decide whether a rebase is necessary before sending it to Linus.

 I just saw the announcement from Olof - no more major merge for 3.7
 will be accepted from now on.  Can this be an exception or should I
 plan this for 3.8?


I'll take a look at merging it tomorrow after I've dealt with smp_ops;
if it looks reasonably conflict-free I'll pull it in. We need the
sound dependency sorted out (or agreed upon) first though.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: core: Add a capability for disabling mmc cards

[Olof Johansson]

On Wed, Aug 22, 2012 at 11:25 AM, Nicolas Pitre n...@fluxnic.net wrote:
 On Wed, 22 Aug 2012, Olof Johansson wrote:

 On Wed, Aug 22, 2012 at 9:00 AM, Philip Rakity prak...@marvell.com wrote:
 
  On Aug 22, 2012, at 8:44 AM, Doug Anderson diand...@chromium.org wrote:
 
  Thanks for your feedback.  In this case I have a card that is an MMC
  card so mmc_attach_sdio() and mmc_attach_sd() will fail.  If I let
  mmc_attach_mmc() run it will actually find the MMC card.  However, on
  this platform it is not valid to recognize MMC cards.
 
 
 
  Understand.
 
  Can you explain why the change is needed.  Is it for technical
  reasons that MMC is not allowed -- if so then I do not understand how SD 
  can work
  and MMC cannot.
 
  If it is for marketing reasons -- then --- oh well .
 
 
  Could you add some additional comments to the commit message.
  I think it makes sense to handle all 3 cases
  a) SDIO not allowed
  b) SD not allowed
  c) MMC not allowed

 We are working with a system manufacturer who wishes to only support
 SD cards in their product, and need to accommodate that. It made sense
 for us to contribute this work upstream since others might want to do
 the same in the future for some reason.

 Adding all three cases makes sense if others foresee a use case for it.

 Isn't this rather revolting?

 Personally I find such feature totally ridiculous. If said
 manufacturer doesn't want to support MMC cards, they just have to not
 advertise it, period.  Or if they really mean it, then they only have to
 state it explicitly in their user manual, and repeat it if ever problems
 are reported.

 Dumbing down kernel functionality to serve marketing purpose or
 technology lock-ins is utterly stupid.  Purposely restricting
 interoperability might even be ruled illegal in some jurisdictions.

 I therefore insist on providing a vehement NAK on such patches.

Ok, thanks. We'll keep carrying it locally instead then.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 24/29] mmc: add a simple generic OF parser

[Olof Johansson]

On Thu, May 3, 2012 at 8:05 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
 Many MMC host drivers already use OF data to obtain their platform-specific
 configuration. Each of them is doing this in its special way, whereas many
 parameters are identical and can easily be generalised. This patch adds
 such a generic parser. So far it only adds and handles very few basic
 properties. New ones can be added in the future as required.

The bindings need to be documented under Documentation/devicetree/mmc

It's common to use dashes (-) instead of underscores (_) in properties

Also, no need to prefix with mmc. But also:


 +       if (of_get_property(node, mmc,4_bit_data, NULL))
 +               mmc-caps |= MMC_CAP_4_BIT_DATA;
 +       if (of_get_property(node, mmc,8_bit_data, NULL))
 +               mmc-caps |= MMC_CAP_8_BIT_DATA;

In the device tree, do these encode the capability of the controller,
or how the device under the controller is wired up? It's not uncommon
to have an 4-bit device on a controller that could possibly support
8-bit devices. It needs to be clear from the property name which is
which to not confuse everyone all the time.

 +       if (of_get_property(node, mmc,sdio_irq, NULL))
 +               mmc-caps |= MMC_CAP_SDIO_IRQ;

supports-sdio-interrupts

 +       if (of_get_property(node, mmc,nonremovable, NULL))
 +               mmc-caps |= MMC_CAP_NONREMOVABLE;

This is a property of the card (well, how the card is connected), not
the controller, right? Again, see above regarding confusion.

 +       if (of_get_property(node, mmc,needs_poll, NULL))
 +               mmc-caps |= MMC_CAP_NEEDS_POLL;

This should be implicit from lack of interrupt property in the device node.

 +       if (of_get_property(node, mmc,inverted_cd, NULL))
 +               mmc-caps2 |= MMC_CAP2_INVERTED_CD;
 +       if (of_get_property(node, mmc,inverted_ro, NULL))
 +               mmc-caps2 |= MMC_CAP2_INVERTED_RO;

The GPIO specifiers should be able to encode polarity. Is this needed
for other cases as well?


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/7] mmc: dw_mmc: add samsung exynos5250 specific extentions

[Olof Johansson]

Hi,

On Tue, May 1, 2012 at 10:07 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 The instantiation of the Synopsis Designware controller on Exynos5250
 include extension for SDR and DDR specific tx/rx phase shift timing
 and CIU internal divider. In addition to that, the option to skip the
 command hold stage is also introduced. Add support for these Exynos5250
 specfic extenstions.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   33 
 +++-
  drivers/mmc/host/dw_mmc-pltfm.c                    |    8 +
  drivers/mmc/host/dw_mmc.c                          |   32 ++-
  drivers/mmc/host/dw_mmc.h                          |   13 
  include/linux/mmc/dw_mmc.h                         |    6 +++
  5 files changed, 89 insertions(+), 3 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 index c1ed70e..465fc31 100644
 --- a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 @@ -7,6 +7,8 @@ Required Properties:

  * compatible: should be one of the following
        - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
 +       - synopsis,dw-mshc-exynos5250: for controllers with Samsung
 +         Exynos5250 specific extentions.

It makes more sense to use your own manufacturer prefix here:

samsung,exynos5250-dw-mshc


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/11] gpio: tegra: Hide tegra_gpio_enable/disable()

[Olof Johansson]

On Fri, Mar 30, 2012 at 05:00:00PM -0600, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 Recent pinctrl discussions concluded that gpiolib APIs should in fact do
 whatever is required to mux a GPIO onto pins, by calling pinctrl APIs if
 required. This change implements this for the Tegra GPIO driver, and removes
 calls to the Tegra-specific APIs from drivers and board files.
 
 Cc: Chris Ball c...@laptop.org
 Cc: linux-mmc@vger.kernel.org
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
 v2: Adjusted per changes to latest version of Documentation/gpio.txt.
 Fixed tegra_board_pinmux_bus_notify() to still check the device name,
 so it waits for the pinmux device to be registered, not just /any/ device.

Acked-by: Olof Johansson o...@lixom.net

I'm quite glad to see this happen. Erik had the intention to keep pin setup
separate from gpio drivers, but in the end it just results in duplicate setup
of the same stuff in different places. In hindsight this does seem quite a bit
cleaner.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sdhci-tegra: fix linux/module.h included twice

[Olof Johansson]

On Wed, Feb 15, 2012 at 9:54 AM, Danny Kukawka danny.kuka...@bisect.de wrote:
 Remove double include of linux/module.h.

 Signed-off-by: Danny Kukawka danny.kuka...@bisect.de

Obviously correct, not that Chris needs it but anyway:

Acked-by: Olof Johansson o...@lixom.net


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] arm/tegra: Move gpio-names.h into mach/gpio-tegra.h

[Olof Johansson]

Hi,

On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren swar...@nvidia.com wrote:
 This centralizes all SoC-level GPIO-related definitions into a single
 header file.

 Signed-off-by: Stephen Warren swar...@nvidia.com

  arch/arm/mach-tegra/gpio-names.h              |  247 
 -
  arch/arm/mach-tegra/include/mach/gpio-tegra.h |  225 ++
  11 files changed, 226 insertions(+), 257 deletions(-)
  delete mode 100644 arch/arm/mach-tegra/gpio-names.h

The main reason that gpio-names.h was only in the mach directory and
not under include in the first place, is to discourage use outside of
the base platform code and board definitions.

There should be no need for drivers and non-mach-tegra code to use the
file, so doing a current-directory include of it should be OK. Or do
you have other plans for it?


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] arm/tegra: Move EN_VDD_1V05_GPIO to board-harmony.h

[Olof Johansson]

On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren swar...@nvidia.com wrote:
 This centralizes all GPIO naming in one header.

 Signed-off-by: Stephen Warren swar...@nvidia.com

Acked-by: Olof Johansson o...@lixom.net

 ---
 This patch series relies on various previous changes to the Tegra GPIO
 driver that were made in Russell's GPIO tree. I assume this series will
 go in through that tree.

 This first patch is cleanup which makes the second slightly cleaner (no
 need to edit board-harmony-pcie.c in patch 2). Usually, it would go in
 through the Tegra tree, but I think it makes sense to merge these 3
 patches all together in one place.

Works for me. Or I could stage it in a topic branch that would be
merged after Russell's GPIO tree.

Russell, Arnd, got any preferences for one or the other?


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] arm/tegra: Replace mach/gpio.h with mach/gpio-tegra.h

[Olof Johansson]

On Wed, Sep 21, 2011 at 12:33 PM, Stephen Warren swar...@nvidia.com wrote:
 This will eventually allow mach/gpio.h to be deleted. This mirrors
 LinusW's recent equivalent work on various other ARM platforms.

 Signed-off-by: Stephen Warren swar...@nvidia.com

Acked-by: Olof Johansson o...@lixom.net
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings

[Olof Johansson]

On Tue, Sep 20, 2011 at 2:01 PM, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 20 September 2011, Arnd Bergmann wrote:
 On Tuesday 20 September 2011, Grant Likely wrote:
  On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote:
   On Tuesday 20 September 2011, Stephen Warren wrote:
The bindings were recently updated to have separate properties for each
type of GPIO. Update the Device Tree source to match that.
   
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
---
I'd previously sent these to Grant assuming they'd go in his dt/next 
branch,
but perhaps these should go in through Arnd's arm-soc next/dt branch?
   
  
   Which tree has the update that changed the bindings? I think it should
   go into the same one.
  
   If it's already upstream, I can take it into the fixes branch.
 
  Already upstream

 Ok, I see. I've applied both patches to the fixes branch and will send
 it out with the next pull request for 3.1 to Linus then.

 Sorry, I just noticed that the second patch is not a bug fix, so I took it out
 again and kept only patch 1/2 in the fixes branch for 3.1.

 Should I take the other one as well? It's probably better to let that
 go the proper way through the tegra tree for 3.2, right?

Given that you have a public tree right now, and I don't (since
kernel.org is down), please feel free to start a tegra/for-3.2 branch
for me and apply it there. I'll base further work on top of that if
needed.

(There also aren't a whole lot of other patches queued for 3.2 right now).

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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/2] arm/dt: Tegra: Update SDHCI nodes to match bindings

[Olof Johansson]

On Tue, Aug 23, 2011 at 11:15 AM, Stephen Warren swar...@nvidia.com wrote:
 The bindings were recently updated to be more in-line with other SDHCI
 bindings that are already merged.

 Signed-off-by: Stephen Warren swar...@nvidia.com

Acked-by: Olof Johansson o...@lixom.net
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resume issue with brcmfmac *not* loaded

[Olof Johansson]

Hi,

First, the below were pure guesses on my behalf, but browsing around
the sources for a few minutes seems to confirm that caps are... well,
caps. flags are currently active flags.

On Mon, Jun 13, 2011 at 5:26 PM, Grant Grundler grund...@chromium.org wrote:
 When the driver is loaded, suspend and resume (echo mem  /sys/state/power)
 work fine.

 However, without the driver loaded, resume works, but 10 seconds later,
 the kernel hangs a little, and spits out the errors quoted at the end of
 this email. The hangs interfere with other devices on the system; e.g.
 audio DMA gets starved and causes audible artifacts.

 I tracked this down to brcmfmac's suspend function wl_cfg80211_suspend()
 calling sdioh_sdio_set_host_pm_flags(MMC_PM_KEEP_POWER).

 Broadcom and/or Olofj might have insight in this. It's not clear to me
 why loading the driver on resume would break this.  Loading the driver
 at boot time works fine for me and should essentially be exercising
 the same code path from the driver PoV.

Sounds to me like loading the driver isn't what is breaking things,
it's the suspend/resume without a driver at all.

That slot lacks a CD GPIO, which means that the MMC code will poll for
cards present. It seems like one of those polls are what's causing
problem in this case.

The wifi adapter will stay powered across the suspend/resume (external
power feed, not part of MMC). So the MMC interface will go down but
the card will remain powered.

 I note that the MMC controller suspend/resume path are influenced by
 MMC_PM_KEEP_POWER, but only when the driver for the attached SDIO device
 specify that flag, hence it's in host-pm_flags and not just in
 host-pm_caps.

 Sorry, I don't know the difference and assume Olof does.


 If I hack all the MMC core code to look for (host-pm_caps 
 MMC_PM_KEEP_POWER) instead of (host-pm_flags  MMC_PM_KEEP_POWER), then
 suspend/resume works fine even without the brcmfmac driver loaded.

 Olof (just walked by) suspects pm_caps means it's supported and
 pm_flags indicates state (enabled).

Right -- it sounds to me like checking caps at resume time is the
wrong way to go about it -- caps are just caps, and flags are the
current actual setting.

 I imagine such a change isn't blanket appropriate for the MMC core. Can
 anyone clue me in on:

 * Is the call to sdioh_sdio_set_host_pm_flags() just something that masks
 a somewhat unrelated problem that should be investigated, or a direct fix
 for this issue?

Sounds to me like there's another problem going on here. I wonder if
the card gets confused if the host goes away and comes back without it
having been power cycled as well.

This should be simple for Broadcom to reproduce, and they are the ones
with the knowledge of how their adapter behaves. So I'd like to hear
from them about this.

 Note that the call to sdioh_sdio_set_host_pm_flags() was introduced to
 staging-2.6.git in commit 6b5a5a3eb77ea69382da9d2a64d74107e49cedaa
 STAGING: brcm80211 v2 keep power on in suspend state.

Reverting that change won't make a difference in this case, will it?


Sounds like the solution here might instead be:

* Specify the power_gpio properly for the slot in question (it does
have one wired up if I'm reading the right schematics, it's just not
specified in the board file)
* Add a suspend/resume function to the sdhci-tegra driver currently
not in use, that disables power to the slot during suspend if the
pm_flags don't have MMC_KEEP_POWER set.


That should take care of this issue, but it would also be good to hear
from Broadcom above as to why the current behavior causes problems.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tegra/mmc: add pm_flags

[Olof Johansson]

[Gah, now without HTML formatting.]

On Fri, Mar 25, 2011 at 5:07 PM, Grant Grundler grund...@google.com wrote:

 Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.

 This part allows the mach-tegra support tell the tegra MMC host controller
 to NOT turn off power for the MMC controller the WIFI part lives behind.
 Thus bcm4329 firmware doesn't need to be reloaded.

 Signed-off-by: Venkat Rao vrao@broadcom
 Tested-by: Grant Grundler grund...@chromium.org
 Reviewed-by: Olof Johansson ol...@chromium.org
 
 I'm not certain if this should go through tegra or mmc tree.
 Can you advise please?

Chris, please take it through the MMC tree.

Feel free to s/ol...@chromium.org/o...@lixom.net/ above, either way works.

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tegra/mmc: add pm_flags

[Olof Johansson]

On Fri, Mar 25, 2011 at 5:27 PM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Fri, Mar 25 2011, Grant Grundler wrote:
 Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.

 This part allows the mach-tegra support tell the tegra MMC host controller
 to NOT turn off power for the MMC controller the WIFI part lives behind.
 Thus bcm4329 firmware doesn't need to be reloaded.

 Signed-off-by: Venkat Rao vrao@broadcom
 Tested-by: Grant Grundler grund...@chromium.org
 Reviewed-by: Olof Johansson ol...@chromium.org
 
 I'm not certain if this should go through tegra or mmc tree.
 Can you advise please?

 I'm happy to take it through the MMC tree for .40, but would like
 an Acked-by: from an arch/arm/mach-tegra maintainer to show Linus.
 Olof is one such person, so getting an Acked-by from him would work.

 (Also, Venkat's e-mail address is malformed in the S-o-b.)

Acked-by: Olof Johansson o...@lixom.net


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] SDHCI: Suspend/Resume needs to save/restore INT_ENABLE on ARM/Tegra2

[Olof Johansson]

Hi,

On Wed, Mar 9, 2011 at 3:11 PM, Andrei Warkentin andr...@motorola.com wrote:

 Does kernel.org still need something to deal with state of
 SDHCI_QUIRK_NO_SDIO_IRQ quirk bit?

 I'm confused. I see this quirk added as part of Tegra sdhci support in
 our K36 tree. I suppose with this patch the should be no need for this
 quirk. I'll apply your change today and see what I get.

Next time, feel free to cc me. :)

I removed the quirk during driver cleanup because, based on my
testing, it was no longer needed. I also asked nvidia why the quirk
was ever needed (took a while to get a response):

Turns out it was left over from hardware errata on a previous product
using the same IP block (i.e. Tegra 1), and is no longer required for
Tegra 2 (since the block gap interrupt is enabled).

So, no, it should not be needed in the upstream driver. The patch from
Grant is though.

If it's unappetizing for sdhci-wide consumption, we could add
suspend/resume hooks for sdhci-tegra only and save/restore it there.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci-tegra: free irq on error and remove

[Olof Johansson]

On Sun, Feb 20, 2011 at 11:21 PM, Wolfram Sang w.s...@pengutronix.de wrote:
 On Thu, Feb 10, 2011 at 06:07:30PM +0100, Wolfram Sang wrote:
 Signed-off-by: Wolfram Sang w.s...@pengutronix.de
 Cc: Olof Johansson o...@lixom.net
 Cc: Chris Ball c...@laptop.org
 ---

 Found the leak while working on the esdhc-imx driver. Not even compile 
 tested,
 please check.

 Olof, do you have a minute for this one?

Yeah, my bad -- I thought I had already acked it.

Acked-by: Olof Johansson o...@lixom.net
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: MMC_BLOCK_MINORS should depend on MMC_BLOCK.

[Olof Johansson]

On Tue, Jan 4, 2011 at 10:02 AM, Chris Ball c...@laptop.org wrote:
 Signed-off-by: Chris Ball c...@laptop.org

Acked-by: Olof Johansson o...@lixom.net


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: tegra: harmony: add sdhci devices

[Olof Johansson]

Add platform devices for SDIO{1,2,4} on harmony, which goes to wifi and
the two card connectors on the board. SDIO4 (the non-bayonet connector)
is wired for 8-bit cards, SDIO2 is not.

Originally from:
Signed-off-by: Colin Cross ccr...@android.com

SDIO1 pieces from:
Signed-off-by: Gary King gk...@nvidia.com

Cleanup, move of GPIO setup to sdhci-plftm driver, etc:
Signed-off-by: Olof Johansson o...@lixom.net
---

Depends on the driver that has been merged into mmc-next.

 arch/arm/mach-tegra/Makefile   |1 +
 arch/arm/mach-tegra/board-harmony-pinmux.c |   11 ++-
 arch/arm/mach-tegra/board-harmony-sdhci.c  |  117 
 arch/arm/mach-tegra/board-harmony.c|1 +
 arch/arm/mach-tegra/board-harmony.h|1 +
 5 files changed, 126 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-tegra/board-harmony-sdhci.c

diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index cdbc68e..3b60d61 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_TEGRA_PCI)   += pcie.o
 obj-${CONFIG_MACH_HARMONY}  += board-harmony.o
 obj-${CONFIG_MACH_HARMONY}  += board-harmony-pinmux.o
 obj-${CONFIG_MACH_HARMONY}  += board-harmony-pcie.o
+obj-${CONFIG_MACH_HARMONY} += board-harmony-sdhci.o
diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c 
b/arch/arm/mach-tegra/board-harmony-pinmux.c
index 50b15d5..78980e4 100644
--- a/arch/arm/mach-tegra/board-harmony-pinmux.c
+++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
@@ -15,11 +15,12 @@
  */
 
 #include linux/kernel.h
+#include linux/init.h
 #include mach/pinmux.h
 
 #include board-harmony.h
 
-static struct tegra_pingroup_config harmony_pinmux[] = {
+static __initdata struct tegra_pingroup_config harmony_pinmux[] = {
{TEGRA_PINGROUP_ATA,   TEGRA_MUX_IDE,   TEGRA_PUPD_NORMAL,
TEGRA_TRI_NORMAL},
{TEGRA_PINGROUP_ATB,   TEGRA_MUX_SDIO4, TEGRA_PUPD_NORMAL,
TEGRA_TRI_NORMAL},
{TEGRA_PINGROUP_ATC,   TEGRA_MUX_NAND,  TEGRA_PUPD_NORMAL,
TEGRA_TRI_NORMAL},
@@ -34,10 +35,10 @@ static struct tegra_pingroup_config harmony_pinmux[] = {
{TEGRA_PINGROUP_DAP3,  TEGRA_MUX_DAP3,  TEGRA_PUPD_NORMAL,
TEGRA_TRI_TRISTATE},
{TEGRA_PINGROUP_DAP4,  TEGRA_MUX_DAP4,  TEGRA_PUPD_NORMAL,
TEGRA_TRI_TRISTATE},
{TEGRA_PINGROUP_DDC,   TEGRA_MUX_I2C2,  TEGRA_PUPD_PULL_UP,   
TEGRA_TRI_NORMAL},
-   {TEGRA_PINGROUP_DTA,   TEGRA_MUX_SDIO2, TEGRA_PUPD_PULL_UP,   
TEGRA_TRI_TRISTATE},
-   {TEGRA_PINGROUP_DTB,   TEGRA_MUX_RSVD1, TEGRA_PUPD_NORMAL,
TEGRA_TRI_TRISTATE},
+   {TEGRA_PINGROUP_DTA,   TEGRA_MUX_SDIO2, TEGRA_PUPD_PULL_UP,   
TEGRA_TRI_NORMAL},
+   {TEGRA_PINGROUP_DTB,   TEGRA_MUX_RSVD1, TEGRA_PUPD_NORMAL,
TEGRA_TRI_NORMAL},
{TEGRA_PINGROUP_DTC,   TEGRA_MUX_RSVD1, TEGRA_PUPD_NORMAL,
TEGRA_TRI_TRISTATE},
-   {TEGRA_PINGROUP_DTD,   TEGRA_MUX_SDIO2, TEGRA_PUPD_PULL_UP,   
TEGRA_TRI_TRISTATE},
+   {TEGRA_PINGROUP_DTD,   TEGRA_MUX_SDIO2, TEGRA_PUPD_PULL_UP,   
TEGRA_TRI_NORMAL},
{TEGRA_PINGROUP_DTE,   TEGRA_MUX_RSVD1, TEGRA_PUPD_NORMAL,
TEGRA_TRI_TRISTATE},
{TEGRA_PINGROUP_DTF,   TEGRA_MUX_I2C3,  TEGRA_PUPD_NORMAL,
TEGRA_TRI_TRISTATE},
{TEGRA_PINGROUP_GMA,   TEGRA_MUX_SDIO4, TEGRA_PUPD_NORMAL,
TEGRA_TRI_NORMAL},
@@ -138,7 +139,7 @@ static struct tegra_pingroup_config harmony_pinmux[] = {
{TEGRA_PINGROUP_XM2D,  TEGRA_MUX_NONE,  TEGRA_PUPD_NORMAL,
TEGRA_TRI_NORMAL},
 };
 
-void harmony_pinmux_init(void)
+void __init harmony_pinmux_init(void)
 {
tegra_pinmux_config_table(harmony_pinmux, ARRAY_SIZE(harmony_pinmux));
 }
diff --git a/arch/arm/mach-tegra/board-harmony-sdhci.c 
b/arch/arm/mach-tegra/board-harmony-sdhci.c
new file mode 100644
index 000..3a0c1b1
--- /dev/null
+++ b/arch/arm/mach-tegra/board-harmony-sdhci.c
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2010-2011 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/resource.h
+#include linux/platform_device.h
+#include mach/irqs.h
+#include mach/iomap.h
+#include mach/sdhci.h
+
+#include board-harmony.h
+#include gpio-names.h
+
+static struct resource sdhci_resource1[] = {
+   [0] = {
+   .start  = INT_SDMMC1,
+   .end= INT_SDMMC1,
+   .flags  = IORESOURCE_IRQ

Re: [PATCH 2/2] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

On Thu, Dec 23, 2010 at 3:23 AM, Wolfram Sang w.s...@pengutronix.de wrote:

 Changes since v2:
       * Whitespace fixes
       * Changed order of test in get_ro

 What benefit has the reordering? (And just to make sure: You still
 return -1 meaning read-only. I assume this is intentional)

Looking at drivers/mmc/core/sd.c:mmc_sd_setup_card(), returning 0
means no RO detection, and will print a warning to that effect. If no
other RO-related quirks are included (i.e. such as
SDHCI_QUIRK_INVERTED_WRITE_PROTECT), the value will be passed up
through sdhci_get_ro and thus handled appropriately.

So on second look the code as it is seems correct to me.

Still, I have a 8-bit fix to incorporate, so I'll repost a v4 anyway.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 v4] Add SDHCI driver for Tegra

[Olof Johansson]

Here we go again. Just a couple of minor changes to the 8-bit code, i.e.
allow boards to pass in which slots are actually wired 8-bit.

Changes since v1:
* Rewrote for sdhci-pltfm

Changes since v2:
* Whitespace fixes
* Changed order of test in get_ro
* 8-bit support
* Set gpio directions

Changes since v3:
* Add platform structure member for 8bit capabilities


--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 v4] sdhci: add quirk for max len ADMA descriptors

[Olof Johansson]

Some controllers misparse segment length 0 as being 0, not 65536. Add
a quirk to deal with it.

Change-Id: I1422c9c605095addc133e844c66fc49f187dc17d
Signed-off-by: Olof Johansson o...@lixom.net
---
 drivers/mmc/host/sdhci.c  |   10 +++---
 include/linux/mmc/sdhci.h |2 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a25db426..c0094c1 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1928,10 +1928,14 @@ int sdhci_add_host(struct sdhci_host *host)
 * of bytes. When doing hardware scatter/gather, each entry cannot
 * be larger than 64 KiB though.
 */
-   if (host-flags  SDHCI_USE_ADMA)
-   mmc-max_seg_size = 65536;
-   else
+   if (host-flags  SDHCI_USE_ADMA) {
+   if (host-quirks  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC)
+   mmc-max_seg_size = 65535;
+   else
+   mmc-max_seg_size = 65536;
+   } else {
mmc-max_seg_size = mmc-max_req_size;
+   }
 
/*
 * Maximum block size. This varies from controller to controller and
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 1fdc673..dfb2106 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -83,6 +83,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (128)
 /* Controller doesn't have HISPD bit field in HI-SPEED SD card */
 #define SDHCI_QUIRK_NO_HISPD_BIT   (129)
+/* Controller treats ADMA descriptors with length h incorrectly */
+#define SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC   (130)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.7.3.GIT

--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 v4] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

SDHCI driver for Tegra. This driver plugs in as a new variant of
sdhci-pltfm, using the platform data structure passed in to specify the
GPIOs to use for card detect, write protect and card power enablement.

Original driver (of which only the header file is left):
Signed-off-by: Yvonne Yip y...@palm.com

The rest, which has been rewritten by now:
Signed-off-by: Olof Johansson o...@lixom.net
Reviewed-by: Wolfram Sang w.s...@pengutronix.de
Acked-by: Mike Rapoport m...@compulab.co.il

---

SDHCI driver for Tegra. Pretty straight forward, a few pieces of
functionality left to fill in but nothing that stops it from going
upstream. Board enablement submitted separately.

Changes since v1:
* Rewrote for sdhci-pltfm

Changes since v2:
* Whitespace fixes
* Changed order of test in get_ro
* 8-bit support
* Set gpio directions

Changes since v3:
* Add platform structure member for 8bit capabilities

Change-Id: I18b322b57a7285d80c530bafaba04a6d84f668d5
---
 arch/arm/mach-tegra/include/mach/sdhci.h |   29 
 drivers/mmc/host/Kconfig |   10 ++
 drivers/mmc/host/Makefile|1 +
 drivers/mmc/host/sdhci-pltfm.c   |3 +
 drivers/mmc/host/sdhci-pltfm.h   |1 +
 drivers/mmc/host/sdhci-tegra.c   |  257 ++
 6 files changed, 301 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-tegra/include/mach/sdhci.h
 create mode 100644 drivers/mmc/host/sdhci-tegra.c

diff --git a/arch/arm/mach-tegra/include/mach/sdhci.h 
b/arch/arm/mach-tegra/include/mach/sdhci.h
new file mode 100644
index 000..3ad086e
--- /dev/null
+++ b/arch/arm/mach-tegra/include/mach/sdhci.h
@@ -0,0 +1,29 @@
+/*
+ * include/asm-arm/arch-tegra/include/mach/sdhci.h
+ *
+ * Copyright (C) 2009 Palm, Inc.
+ * Author: Yvonne Yip y...@palm.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#ifndef __ASM_ARM_ARCH_TEGRA_SDHCI_H
+#define __ASM_ARM_ARCH_TEGRA_SDHCI_H
+
+#include linux/mmc/host.h
+
+struct tegra_sdhci_platform_data {
+   int cd_gpio;
+   int wp_gpio;
+   int power_gpio;
+   int is_8bit;
+};
+
+#endif
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d618e86..25c6a2a 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -140,6 +140,16 @@ config MMC_SDHCI_ESDHC_IMX
 
  If unsure, say N.
 
+config MMC_SDHCI_TEGRA
+   tristate SDHCI platform support for the Tegra SD/MMC Controller
+   depends on MMC_SDHCI_PLTFM  ARCH_TEGRA
+   select MMC_SDHCI_IO_ACCESSORS
+   help
+ This selects the Tegra SD/MMC controller. If you have a Tegra
+ platform with SD or MMC devices, say Y or M here.
+
+ If unsure, say N.
+
 config MMC_SDHCI_S3C
tristate SDHCI support on Samsung S3C SoC
depends on MMC_SDHCI  PLAT_SAMSUNG
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 7b645ff..fc8f8f0 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_MMC_SDHCI_PLTFM) += 
sdhci-platform.o
 sdhci-platform-y   := sdhci-pltfm.o
 sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
 sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC_IMX)   += sdhci-esdhc-imx.o
+sdhci-platform-$(CONFIG_MMC_SDHCI_TEGRA)   += sdhci-tegra.o
 
 obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
 sdhci-of-y := sdhci-of-core.o
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 0502f89..d9e6e88 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -170,6 +170,9 @@ static const struct platform_device_id sdhci_pltfm_ids[] = {
 #ifdef CONFIG_MMC_SDHCI_ESDHC_IMX
{ sdhci-esdhc-imx, (kernel_ulong_t)sdhci_esdhc_imx_pdata },
 #endif
+#ifdef CONFIG_MMC_SDHCI_TEGRA
+   { sdhci-tegra, (kernel_ulong_t)sdhci_tegra_pdata },
+#endif
{ },
 };
 MODULE_DEVICE_TABLE(platform, sdhci_pltfm_ids);
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index c1bfe48..6f631e3 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -22,5 +22,6 @@ struct sdhci_pltfm_host {
 
 extern struct sdhci_pltfm_data sdhci_cns3xxx_pdata;
 extern struct sdhci_pltfm_data sdhci_esdhc_imx_pdata;
+extern struct sdhci_pltfm_data sdhci_tegra_pdata;
 
 #endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
new file mode 100644
index 000

Re: [PATCH 2/2 v4] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

On Sat, Jan 1, 2011 at 9:43 PM, Chris Ball c...@laptop.org wrote:
 Hi Olof,

 On Sat, Jan 01, 2011 at 06:37:33PM -0600, Olof Johansson wrote:
 SDHCI driver for Tegra. This driver plugs in as a new variant of
 sdhci-pltfm, using the platform data structure passed in to specify the
 GPIOs to use for card detect, write protect and card power enablement.

 I've pushed this patchset to mmc-next for .38 now.  Thanks!  I removed
 the Change-Id: tags from both commit messages, matching Linus' policy:
 http://thread.gmane.org/gmane.linux.kernel/1075380.

Crap, stupid repo -- I forgot to remove them by hand. Sorry about that.

 Also:

 --- /dev/null
 +++ b/drivers/mmc/host/sdhci-tegra.c
 @@ -0,0 +1,257 @@
 +/*
 + * Copyright (C) 2010 The Chromium OS Authors chromium-os-...@chromium.org
 + *
 + * This software is licensed under the terms of the GNU General Public
 + * License version 2, as published by the Free Software Foundation, and
 + * may be copied, distributed, and modified under those terms.

 As discussed on IRC, this is the first time this attribution line's been
 used in mainline, so I'd like to hear more about whether The Chromium OS
 Authors is actually a copyright-holding entity.

Yep, I'll follow up on this.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

Hi,

On Wed, Dec 22, 2010 at 10:20 PM, Mike Rapoport m...@compulab.co.il wrote:

 Only one comment below, otherwise feel free to add
 Acked-by: Mike Rapoport m...@compulab.co.il

Thanks!

 +     if (gpio_is_valid(plat-wp_gpio)) {
 +             rc = gpio_request(plat-wp_gpio, sdhci_wp);
 +             if (rc) {
 +                     dev_err(mmc_dev(host-mmc),
 +                             failed to allocate wp gpio\n);
 +                     goto out_cd;
 +             }
 +             tegra_gpio_enable(plat-wp_gpio);

 gpio_direction_input?

Yep, for cd_gpio too.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] sdhci: add quirk for max len ADMA descriptors

[Olof Johansson]

On Thu, Dec 23, 2010 at 3:26 AM, Wolfram Sang w.s...@pengutronix.de wrote:
 On Thu, Dec 23, 2010 at 03:27:54AM -0600, Olof Johansson wrote:
 Some controllers misparse segment length 0 as being 0, not 65536. Add
 a quirk to deal with it.

 Signed-off-by: Olof Johansson o...@lixom.net

 I tend to NACK it (but I am not the maintainer). I'd prefer to see a
 draft of your idea of a sdhci_add_host_fixup()-function :)

See, I tend to get annoyed when I get asked to clean up others' messes
because something I do is all of the sudden held to a higher standard
than they have been.

So, I see one of three options:

* This go in, and I clean up some of the other drivers separately, _as promised_
* I do a sdhci_host_fixup() function, and only clean up my driver and
the rest will be cleaned up... never, probably
* I just remove this quirk, repost my driver without it, carry the
quirk out of tree and get on with other things that I actually care
about


So, don't overdo it. I already promised I would help clean up this
subsystem. Ok?


Thanks,

-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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/2] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

On Thu, Dec 23, 2010 at 3:23 AM, Wolfram Sang w.s...@pengutronix.de wrote:

 Changes since v2:
       * Whitespace fixes
       * Changed order of test in get_ro

 What benefit has the reordering? (And just to make sure: You still
 return -1 meaning read-only. I assume this is intentional)\

Uh, thanks for the vague feedback last time. I thought that's what
your concern with it was.

But yeah, defaulting to RW makes more sense. v4 coming once I know if
you want me to rip out the new quirk or not.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3 v2] Add SDHCI driver for Tegra

[Olof Johansson]

This is the second version of the SDHCI driver for tegra. I moved it
over to a sdhci-pltfm variant, which turned out to be feasible -- at
least as long as the platform_data is never required by sdhci-pltfm and
can be used by the sub-driver.

I also did away with wone of the quirks, since based on current testing
it seems to no longer be required. If needed it can be reintroduced in
some way or other later on instead.

The one remaining quirk is of the kind that can be moved entirely into
the driver, and I will look at doing so when I get around to cleaning
up other quirks together with it. Until then, at least we have one more
bit left to allocate. :-)


Thanks,

-Olof

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] sdhci: add quirk for max len ADMA descriptors

[Olof Johansson]

Some controllers misparse segment length 0 as being 0, not 65536. Add
a quirk to deal with it.

Signed-off-by: Olof Johansson o...@lixom.net
---
 drivers/mmc/host/sdhci.c  |   10 +++---
 include/linux/mmc/sdhci.h |2 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a25db426..c0094c1 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1928,10 +1928,14 @@ int sdhci_add_host(struct sdhci_host *host)
 * of bytes. When doing hardware scatter/gather, each entry cannot
 * be larger than 64 KiB though.
 */
-   if (host-flags  SDHCI_USE_ADMA)
-   mmc-max_seg_size = 65536;
-   else
+   if (host-flags  SDHCI_USE_ADMA) {
+   if (host-quirks  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC)
+   mmc-max_seg_size = 65535;
+   else
+   mmc-max_seg_size = 65536;
+   } else {
mmc-max_seg_size = mmc-max_req_size;
+   }
 
/*
 * Maximum block size. This varies from controller to controller and
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 1fdc673..dfb2106 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -83,6 +83,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (128)
 /* Controller doesn't have HISPD bit field in HI-SPEED SD card */
 #define SDHCI_QUIRK_NO_HISPD_BIT   (129)
+/* Controller treats ADMA descriptors with length h incorrectly */
+#define SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC   (130)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.7.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] sdhci: don't finish commands in flight

[Olof Johansson]

Don't schedule the finish_tasklet unless the command complete bit is
set in the interrupt status register.

Signed-off-by: Olof Johansson o...@lixom.net
---
 drivers/mmc/host/sdhci.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c0094c1..562aaea 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1432,7 +1432,8 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 
intmask)
host-cmd-error = -EILSEQ;
 
if (host-cmd-error) {
-   tasklet_schedule(host-finish_tasklet);
+   if (intmask  SDHCI_INT_RESPONSE)
+   tasklet_schedule(host-finish_tasklet);
return;
}
 
-- 
1.7.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

SDHCI driver for Tegra. Pretty straight forward, a few pieces of
functionality left to fill in but nothing that stops it from going
upstream. Board enablement submitted separately.

This driver plugs in as a new variant of sdhci-pltfm, using the platform
data structure passed in to specify the GPIOs to use for card detect,
write protect and card power enablement.

Original driver (of which only the header file is left):
Signed-off-by: Yvonne Yip y...@palm.com

The rest, which has been rewritten by now:
Signed-off-by: Olof Johansson o...@lixom.net
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Mike Rapoport m...@compulab.co.il

---

 arch/arm/mach-tegra/include/mach/sdhci.h |   28 
 drivers/mmc/host/Kconfig |   10 ++
 drivers/mmc/host/Makefile|1 +
 drivers/mmc/host/sdhci-pltfm.c   |3 +
 drivers/mmc/host/sdhci-pltfm.h   |1 +
 drivers/mmc/host/sdhci-tegra.c   |  219 ++
 6 files changed, 262 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-tegra/include/mach/sdhci.h
 create mode 100644 drivers/mmc/host/sdhci-tegra.c

diff --git a/arch/arm/mach-tegra/include/mach/sdhci.h 
b/arch/arm/mach-tegra/include/mach/sdhci.h
new file mode 100644
index 000..02f6ef27
--- /dev/null
+++ b/arch/arm/mach-tegra/include/mach/sdhci.h
@@ -0,0 +1,28 @@
+/*
+ * include/asm-arm/arch-tegra/include/mach/sdhci.h
+ *
+ * Copyright (C) 2009 Palm, Inc.
+ * Author: Yvonne Yip y...@palm.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#ifndef __ASM_ARM_ARCH_TEGRA_SDHCI_H
+#define __ASM_ARM_ARCH_TEGRA_SDHCI_H
+
+#include linux/mmc/host.h
+
+struct tegra_sdhci_platform_data {
+   int cd_gpio;
+   int wp_gpio;
+   int power_gpio;
+};
+
+#endif
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d618e86..25c6a2a 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -140,6 +140,16 @@ config MMC_SDHCI_ESDHC_IMX
 
  If unsure, say N.
 
+config MMC_SDHCI_TEGRA
+   tristate SDHCI platform support for the Tegra SD/MMC Controller
+   depends on MMC_SDHCI_PLTFM  ARCH_TEGRA
+   select MMC_SDHCI_IO_ACCESSORS
+   help
+ This selects the Tegra SD/MMC controller. If you have a Tegra
+ platform with SD or MMC devices, say Y or M here.
+
+ If unsure, say N.
+
 config MMC_SDHCI_S3C
tristate SDHCI support on Samsung S3C SoC
depends on MMC_SDHCI  PLAT_SAMSUNG
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 7b645ff..fc8f8f0 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_MMC_SDHCI_PLTFM) += 
sdhci-platform.o
 sdhci-platform-y   := sdhci-pltfm.o
 sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
 sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC_IMX)   += sdhci-esdhc-imx.o
+sdhci-platform-$(CONFIG_MMC_SDHCI_TEGRA)   += sdhci-tegra.o
 
 obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
 sdhci-of-y := sdhci-of-core.o
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 0502f89..d9e6e88 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -170,6 +170,9 @@ static const struct platform_device_id sdhci_pltfm_ids[] = {
 #ifdef CONFIG_MMC_SDHCI_ESDHC_IMX
{ sdhci-esdhc-imx, (kernel_ulong_t)sdhci_esdhc_imx_pdata },
 #endif
+#ifdef CONFIG_MMC_SDHCI_TEGRA
+   { sdhci-tegra, (kernel_ulong_t)sdhci_tegra_pdata },
+#endif
{ },
 };
 MODULE_DEVICE_TABLE(platform, sdhci_pltfm_ids);
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index c1bfe48..6f631e3 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -22,5 +22,6 @@ struct sdhci_pltfm_host {
 
 extern struct sdhci_pltfm_data sdhci_cns3xxx_pdata;
 extern struct sdhci_pltfm_data sdhci_esdhc_imx_pdata;
+extern struct sdhci_pltfm_data sdhci_tegra_pdata;
 
 #endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
new file mode 100644
index 000..1b79663
--- /dev/null
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) 2010 The Chromium OS Authors chromium-os-...@chromium.org
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program

Re: [PATCH 2/3] sdhci: don't finish commands in flight

[Olof Johansson]

Hi,

On Wed, Dec 22, 2010 at 12:08 AM, Chris Ball c...@laptop.org wrote:
 Hi Olof,

 On Wed, Dec 22, 2010 at 02:01:10AM -0600, Olof Johansson wrote:
 Don't schedule the finish_tasklet unless the command complete bit is
 set in the interrupt status register.

 Signed-off-by: Olof Johansson o...@lixom.net

 Could we have some more detail here, please?  What are the symptoms of
 running without this patch?  Should we apply it to the stable tree too?

Hmm, good question. I hadn't gotten to the bottom of why this specific
change was needed in the past -- it's something the original driver
did that I just ended up inheriting behavior from. Thanks for asking.
:-)

From some further investigation, it seems like the underlying problem
is that the controller reports spurious timeout and crc errors, in
spite of the transactions completing successfully.

My main worry with this fix as it was is that it would disable
behavior on controllers where the error bits are set and handled
correctly. So, what I think I will do instead is that I will simply
mask those two errors from generating interrupts (i.e. masking the two
bits when writing the SDHCI_SIGNAL_ENABLE register). That seems to
result in the equivalent behavior, and I no longer see the spurious
interrupts and controller resets. In case of real timeouts and/or CRC
errors, the existing software timer should take care of eventually
unfreezing the controller if need be.

I'll repost the series with these changes after letting this version
sit out for review for a bit longer.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

Hi,

Thanks for the review. All good points (and I forgot to do a last run
through checkpatch, my bad).

All have been addressed in the next version (not yet posted).

-Olof

On Wed, Dec 22, 2010 at 8:22 AM, Wolfram Sang w.s...@pengutronix.de wrote:
 Hi Olof,

 looks good to me. Just some minor comments, but in general

 Reviewed-by: Wolfram Sang w.s...@pengutronix.de

 On Wed, Dec 22, 2010 at 02:01:11AM -0600, Olof Johansson wrote:
 SDHCI driver for Tegra. Pretty straight forward, a few pieces of
 functionality left to fill in but nothing that stops it from going
 upstream. Board enablement submitted separately.

 I'd think this can go below the --- line?

 ...
 This driver plugs in as a new variant of sdhci-pltfm, using the platform
 data structure passed in to specify the GPIOs to use for card detect,
 write protect and card power enablement.

 Original driver (of which only the header file is left):
 Signed-off-by: Yvonne Yip y...@palm.com

 The rest, which has been rewritten by now:
 Signed-off-by: Olof Johansson o...@lixom.net
 Cc: Wolfram Sang w.s...@pengutronix.de
 Cc: Mike Rapoport m...@compulab.co.il
 +static unsigned int tegra_sdhci_get_ro(struct sdhci_host *sdhci)
 +{
 +     struct platform_device *pdev = to_platform_device(mmc_dev(sdhci-mmc));
 +     struct tegra_sdhci_platform_data *plat;
 +
 +     plat = pdev-dev.platform_data;
 +
 +     if (gpio_is_valid(plat-wp_gpio))
 +             return gpio_get_value(plat-wp_gpio);
 +
 +     return -1;

 So, read_only is the default case? I would have gone for returning 0.
 Well, safety vs. convenience...

 ...
 +             if (rc) {
 +                     dev_err(mmc_dev(host-mmc),

 Trailing white space

 +                             failed to allocate power gpio\n);
 +                     goto out;
 +             }
 +             tegra_gpio_enable(plat-power_gpio);
 +             gpio_direction_output(plat-power_gpio, 1);
 +     }
 +
 +     if (gpio_is_valid(plat-cd_gpio)) {
 +             rc = gpio_request(plat-cd_gpio, sdhci_cd);
 +             if (rc) {
 +                     dev_err(mmc_dev(host-mmc),

 ditto

 +                             failed to allocate cd gpio\n);
 +                     goto out_power;
 +             }
 +             tegra_gpio_enable(plat-cd_gpio);
 +
 +             rc = request_irq(gpio_to_irq(plat-cd_gpio), carddetect_irq,
 +                              IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
 +                              mmc_hostname(host-mmc), host);
 +
 +             if (rc) {
 +                     dev_err(mmc_dev(host-mmc), request irq error\n);
 +                     goto out_cd;
 +             }
 +
 +     }
 +
 +     if (gpio_is_valid(plat-wp_gpio)) {
 +             rc = gpio_request(plat-wp_gpio, sdhci_wp);
 +             if (rc) {
 +                     dev_err(mmc_dev(host-mmc),

 ditto

 Kind regards,

   Wolfram

 --
 Pengutronix e.K.                           | Wolfram Sang                |
 Industrial Linux Solutions                 | http://www.pengutronix.de/  |

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAk0SJccACgkQD27XaX1/VRtnbgCdH8+R7hjsq4YjJIjvQgtkwOrF
 GHwAoJBRrdEv6+5d2sxZ5J/AqWsTXLb4
 =RLqI
 -END PGP SIGNATURE-


--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3 v2] Add SDHCI driver for Tegra

[Olof Johansson]

Hi,

On Wed, Dec 22, 2010 at 8:05 AM, Wolfram Sang w.s...@pengutronix.de wrote:

 The one remaining quirk is of the kind that can be moved entirely into
 the driver, and I will look at doing so when I get around to cleaning
 up other quirks together with it. Until then, at least we have one more
 bit left to allocate. :-)

 [BAZAAR MODE]

 So, when are going to remove them? And how many? And what happens if
 not? ;)

 [/BAZAAR MODE]


I'll probably take a go at a few of them over the holiday if I get bored.

If it doesn't happen, we'll run out of bits and someone will be forced
to clean up, or increase the data type. We already had that
discussion. :)


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

Hi,

On Wed, Dec 15, 2010 at 09:35:46AM +0100, Wolfram Sang wrote:

 Can't you just use sdhci-pltfm?

Not if I want to hide some of the SoC-specific errata with driver-local
workarounds instead of polluting the global quirk namespace with them.

Otherwise, yeah, it'd be a good candidate for it.


-Olof

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] mmc: add sdhci-tegra driver for Tegra SoCs

[Olof Johansson]

On Wed, Dec 15, 2010 at 02:43:07AM -0600, Olof Johansson wrote:
 Hi,
 
 On Wed, Dec 15, 2010 at 09:35:46AM +0100, Wolfram Sang wrote:
 
  Can't you just use sdhci-pltfm?
 
 Not if I want to hide some of the SoC-specific errata with driver-local
 workarounds instead of polluting the global quirk namespace with them.
 
 Otherwise, yeah, it'd be a good candidate for it.

Hm, on second look, it seems as if the -pltfm can take the ops structure
from the platform data.

Still, I don't see the point -- the amount of code would be about the
same between wrapping it with a coat of workarounds and op structures,
gpio setup, etc, and just doing a separate simple driver. The code shared
is really just the resource allocation pieces.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html