The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host. Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.
In contrast, SD Cards must begin with 3.3v signalling and
Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure. Additionally, use the
common mmc_regulator_get_supply function to get the regulators and set
the ocr_avail mask.
This change sets the ocr_avail directly based upon the voltage r
On Thu, Apr 24, 2014 at 1:34 AM, Ulf Hansson wrote:
> On 18 April 2014 02:46, Tim Kryger wrote:
>> This series updates SDHCI to use the common regulator infrastructure that mmc
>> core provides.
>>
>> Tim Kryger (2):
>> mmc: sdhci: Use supplies in common mmc_host struct
>> mmc: sdhci: Use com
On Thu, Apr 24, 2014 at 1:38 AM, Ulf Hansson wrote:
> On 18 April 2014 20:58, Tim Kryger wrote:
>> void mmc_power_up(struct mmc_host *host, u32 ocr)
>> {
>> + int err;
>> +
>
> The variable err is not needed, since we don't plan on printing it nor
> returning it. Please remove and handle
On Thu, Apr 24, 2014 at 09:31:54AM +0900, Jaehoon Chung wrote:
> Dear, Russell.
>
> I didn't know which version you have checked.
As I said in the cover, this series is based on v3.15-rc1. It's
based there because it's part of a much larger set of patches that
need to be based on a common point
On Thu, Apr 24, 2014 at 08:51:25PM +0530, Balaji T K wrote:
> On Tuesday 22 April 2014 09:18 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote:
> >>On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>On Wed, Mar 26, 2014 at 07:04:
On Tuesday 22 April 2014 09:18 PM, Felipe Balbi wrote:
Hi,
On Tue, Apr 22, 2014 at 09:00:12PM +0530, Balaji T K wrote:
On Monday 21 April 2014 11:02 PM, Felipe Balbi wrote:
Hi,
On Wed, Mar 26, 2014 at 07:04:45PM -0500, Felipe Balbi wrote:
this series lets us access the newer registers introd
On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:
we introduce new accessors which provide for register
access with and without offsets.
This is just to make sure newer versions of the IP
can access the new registers prepended at the beginning
of the address space.
Signed-off-by: Felipe B
On Thu, Apr 24, 2014 at 08:13:16PM +0530, Balaji T K wrote:
> On Thursday 24 April 2014 08:09 PM, Felipe Balbi wrote:
> >On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote:
> >>On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>this series lets us access the newer r
On Thursday 24 April 2014 08:09 PM, Felipe Balbi wrote:
On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote:
On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:
Hi,
this series lets us access the newer registers introduced
back in OMAP4 which give us some valid information about
the
On Thu, Apr 24, 2014 at 08:01:19PM +0530, Balaji T K wrote:
> On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:
> >Hi,
> >
> >this series lets us access the newer registers introduced
> >back in OMAP4 which give us some valid information about
> >the OMAP HSMMC IP like max block size, support
On Thursday 27 March 2014 05:34 AM, Felipe Balbi wrote:
Hi,
this series lets us access the newer registers introduced
back in OMAP4 which give us some valid information about
the OMAP HSMMC IP like max block size, support for ADMA,
support for Retention.
"Support for Retention" looks interesti
On 24 April 2014 14:27, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 01:32:02PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 13:18, Russell King - ARM Linux
>> wrote:
>> > That may be the case, but that would be an additional modification, and so
>> > should be a separate patch.
>>
On Thu, Apr 24, 2014 at 01:32:02PM +0200, Ulf Hansson wrote:
> On 24 April 2014 13:18, Russell King - ARM Linux
> wrote:
> > That may be the case, but that would be an additional modification, and so
> > should be a separate patch.
>
> I just thought it make sense to include it here - it's reall
On 9 April 2014 15:54, Jonas Jensen wrote:
> Add SD/MMC driver for MOXA ART SoCs.
>
> The "MOXA ART MMC controller" is likely a faraday "ftsdc010",
> a controller with support in U-Boot:
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/ftsdc010_mci.c
>
> Signed-off-by: Jonas Jensen
Acke
On 24 April 2014 13:18, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 09:32:30AM +0200, Ulf Hansson wrote:
>> On 23 April 2014 21:08, Russell King wrote:
>> > We don't need these hooks in order to insert code in these paths, we
>> > can just provide our own handlers and call the main
On Thu, Apr 24, 2014 at 09:32:30AM +0200, Ulf Hansson wrote:
> On 23 April 2014 21:08, Russell King wrote:
> > We don't need these hooks in order to insert code in these paths, we
> > can just provide our own handlers and call the main sdhci handlers as
> > appropriate.
> >
> > Signed-off-by: Russ
On 24 April 2014 12:57, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 12:17, Russell King - ARM Linux
>> wrote:
>> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> >> I have looked though the patches up until p
On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:17, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> >> I have looked though the patches up until patch 33 and this is clearly
> >> a nice piece of clean-up /fixe
On 24 April 2014 12:17, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> I have looked though the patches up until patch 33 and this is clearly
>> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> comments per patch, I don't have a
In addition to user area, General purpose partition can be
be marked with enhanced attribute, retain enhanced attributes of
gp partition while creating enhanced user area and add
check for max enhanced area of the device.
Signed-off-by: Balaji T K
---
mmc.h | 16 ++
mmc_cmds.c |
create gp partition if needed with enhanced / extended attribute.
Signed-off-by: Balaji T K
---
mmc.c |5 ++
mmc.h |2 +
mmc_cmds.c | 135
mmc_cmds.h |1 +
4 files changed, 143 insertions(+), 0 deletions(-)
diff
Add support to create general purpose partition on eMMC device.
gp partition if needed can be marked with either enhanced or
extended attributes.
Note:
creation of gp partition with enhanced attribute has been tested.
Due to lack of access to eMMC device with extended attribute,
I could not test g
On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> I have looked though the patches up until patch 33 and this is clearly
> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> comments per patch, I don't have any objections code-review wise to
> proceed merging them.
>
>
>> The "status" here could be useful information about the status
>> register, which is not considered while printing errors by the "higher
>> levels". An option could be to print the error, but not when you
>> perform tuning.
>>
>> No big deal though, just a thought.
>
> Right, I could potentially
Hi Russell,
On Wed, Apr 23, 2014 at 08:09:04PM +0100, Russell King wrote:
> From: 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
On 24 April 2014 10:46, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 09:58:55AM +0200, Ulf Hansson wrote:
>> On 23 April 2014 21:06, Russell King wrote:
>> > + if (!(host->caps2 & MMC_CAP2_SDIO_NOTHREAD)) {
>> > + atomic_set(&host->sdio_irq_thread_
On Thu, Apr 24, 2014 at 09:58:55AM +0200, Ulf Hansson wrote:
> On 23 April 2014 21:06, Russell King wrote:
> > + if (!(host->caps2 & MMC_CAP2_SDIO_NOTHREAD)) {
> > + atomic_set(&host->sdio_irq_thread_abort, 0);
> > + host->sdio_irq_thread =
On 18 April 2014 20:58, Tim Kryger wrote:
> The eMMC signalling voltage is determined by VCCQ which is provided to
> the card by the host. Signalling is not required to begin at 3.3v and,
> if the host and card both support a particular VCC/VCCQ combination, it
> can be used immediately.
>
> In c
On 18 April 2014 02:46, Tim Kryger wrote:
> This series updates SDHCI to use the common regulator infrastructure that mmc
> core provides.
>
> Tim Kryger (2):
> mmc: sdhci: Use supplies in common mmc_host struct
> mmc: sdhci: Use common mmc_regulator_get_supply
Both patches looks good, but I
On 23 April 2014 20:55, Russell King - ARM Linux wrote:
> All,
>
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appear
On 23 April 2014 21:06, Russell King wrote:
> Rather than the SDIO support spawning it's own thread for handling card
> interrupts, use the generic IRQ infrastructure for this, triggering it
> from the host interface's interrupt handling directly.
>
> This avoids a race between the parent thread w
On 23 April 2014 21:08, Russell King wrote:
> The only user (sdhci-of-esdhc) no longer uses these callbacks, so lets
> remove them to discourage any further use.
>
> Signed-off-by: Russell King
Acked-by: Ulf Hansson
> ---
> drivers/mmc/host/sdhci.c | 6 --
> drivers/mmc/host/sdhci.h | 2 -
On 23 April 2014 21:08, Russell King wrote:
> We don't need these hooks in order to insert code in these paths, we
> can just provide our own handlers and call the main sdhci handlers as
> appropriate.
>
> Signed-off-by: Russell King
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 55
>
34 matches
Mail list logo
