public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff
@ 2006-11-22 14:54 Anderson Briglia
  2006-11-25  8:59 ` Pierre Ossman
  0 siblings, 1 reply; 5+ messages in thread
From: Anderson Briglia @ 2006-11-22 14:54 UTC (permalink / raw)
  To: Linux-omap-open-source@linux.omap.com
  Cc: Russell King, Pierre Ossman, Tony Lindgren,
	Aguiar Carlos (EXT-INdT/Manaus), ext David Brownell,
	Lizardo Anderson (EXT-INdT/Manaus), linux-kernel

OMAP platform specific patch.
- Adjust the frame size for DMA transfers.

Signed-off-by: Anderson Briglia <anderson.briglia <at> indt.org.br>
Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar <at> indt.org.br>

Index: linux-omap-2.6.git/drivers/mmc/omap.c
===================================================================
--- linux-omap-2.6.git.orig/drivers/mmc/omap.c	2006-11-22 09:07:25.000000000 -0400
+++ linux-omap-2.6.git/drivers/mmc/omap.c	2006-11-22 09:19:03.000000000 -0400
@@ -629,6 +629,14 @@ mmc_omap_prepare_dma(struct mmc_omap_hos

  	data_addr = host->phys_base + OMAP_MMC_REG_DATA;
  	frame = data->blksz;
+
+#ifdef CONFIG_MMC_PASSWORDS
+	/* MMC LOCK/UNLOCK: Do frame size multiple of two. This is
+	 * needed for DMA transfers to work properly, once
+	 * the block size depends on MMC password length.
+	 */
+	frame += frame&0x1;
+#endif
  	count = sg_dma_len(sg);

  	if ((data->blocks == 1) && (count > (data->blksz)))


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff
  2006-11-22 14:54 [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff Anderson Briglia
@ 2006-11-25  8:59 ` Pierre Ossman
  2006-11-27 13:43   ` Anderson Briglia
  0 siblings, 1 reply; 5+ messages in thread
From: Pierre Ossman @ 2006-11-25  8:59 UTC (permalink / raw)
  To: Anderson Briglia
  Cc: Linux-omap-open-source@linux.omap.com, Russell King,
	Tony Lindgren, Aguiar Carlos (EXT-INdT/Manaus),
	ext David Brownell, Lizardo Anderson (EXT-INdT/Manaus),
	linux-kernel

Anderson Briglia wrote:
> OMAP platform specific patch.
> - Adjust the frame size for DMA transfers.
>
> Signed-off-by: Anderson Briglia <anderson.briglia <at> indt.org.br>
> Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar <at> indt.org.br>
>

This looks like a generic patch for OMAP and shouldn't be in this set.

> Index: linux-omap-2.6.git/drivers/mmc/omap.c
> ===================================================================
> --- linux-omap-2.6.git.orig/drivers/mmc/omap.c    2006-11-22
> 09:07:25.000000000 -0400
> +++ linux-omap-2.6.git/drivers/mmc/omap.c    2006-11-22
> 09:19:03.000000000 -0400
> @@ -629,6 +629,14 @@ mmc_omap_prepare_dma(struct mmc_omap_hos
>
>      data_addr = host->phys_base + OMAP_MMC_REG_DATA;
>      frame = data->blksz;
> +
> +#ifdef CONFIG_MMC_PASSWORDS
> +    /* MMC LOCK/UNLOCK: Do frame size multiple of two. This is
> +     * needed for DMA transfers to work properly, once
> +     * the block size depends on MMC password length.
> +     */
> +    frame += frame&0x1;
> +#endif
>      count = sg_dma_len(sg);
>
>      if ((data->blocks == 1) && (count > (data->blksz)))
>

Now this you're going to have to explain to me. Especially the part
where why this is specific to the lock commands.

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff
  2006-11-25  8:59 ` Pierre Ossman
@ 2006-11-27 13:43   ` Anderson Briglia
  2006-12-01 21:20     ` Pierre Ossman
  0 siblings, 1 reply; 5+ messages in thread
From: Anderson Briglia @ 2006-11-27 13:43 UTC (permalink / raw)
  To: ext Pierre Ossman
  Cc: Linux-omap-open-source@linux.omap.com, Russell King,
	Tony Lindgren, Aguiar Carlos (EXT-INdT/Manaus),
	ext David Brownell, Lizardo Anderson (EXT-INdT/Manaus),
	linux-kernel

ext Pierre Ossman wrote:
> Anderson Briglia wrote:
>> OMAP platform specific patch.
>> - Adjust the frame size for DMA transfers.
>>
>> Signed-off-by: Anderson Briglia <anderson.briglia <at> indt.org.br>
>> Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar <at> indt.org.br>
>>
> 
> This looks like a generic patch for OMAP and shouldn't be in this set.

This patch is needed only for lock/unlock commands. So, it's necessary to
make MMC omap works when using that feature. It's not a generic patch.
But I can take off this one from the series and send after (if) the series
is integrated.

> 
>> Index: linux-omap-2.6.git/drivers/mmc/omap.c
>> ===================================================================
>> --- linux-omap-2.6.git.orig/drivers/mmc/omap.c    2006-11-22
>> 09:07:25.000000000 -0400
>> +++ linux-omap-2.6.git/drivers/mmc/omap.c    2006-11-22
>> 09:19:03.000000000 -0400
>> @@ -629,6 +629,14 @@ mmc_omap_prepare_dma(struct mmc_omap_hos
>>
>>      data_addr = host->phys_base + OMAP_MMC_REG_DATA;
>>      frame = data->blksz;
>> +
>> +#ifdef CONFIG_MMC_PASSWORDS
>> +    /* MMC LOCK/UNLOCK: Do frame size multiple of two. This is
>> +     * needed for DMA transfers to work properly, once
>> +     * the block size depends on MMC password length.
>> +     */
>> +    frame += frame&0x1;
>> +#endif
>>      count = sg_dma_len(sg);
>>
>>      if ((data->blocks == 1) && (count > (data->blksz)))
>>
> 
> Now this you're going to have to explain to me. Especially the part
> where why this is specific to the lock commands.

frame depends on data->blksz. When we were using data->blksz_bits everything was
ok because we always had a multiple of 16 bits (2 bytes). Once a pwd can has a size
not multiple of 2, the value must be rounded.
According to MMC OMAP Technical Reference Manual, because of each DMA transfer is of
equal size, it is necessary to have the block size of the transfer be a multiple of
the DMA write access size (which is 2 bytes).

I'm not a DMA expert, If I misunderstand something, please, correct me.

Best Regards,

Anderson Briglia


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff
  2006-11-27 13:43   ` Anderson Briglia
@ 2006-12-01 21:20     ` Pierre Ossman
  2006-12-04 16:22       ` Anderson Briglia
  0 siblings, 1 reply; 5+ messages in thread
From: Pierre Ossman @ 2006-12-01 21:20 UTC (permalink / raw)
  To: Anderson Briglia
  Cc: Linux-omap-open-source@linux.omap.com, Russell King,
	Tony Lindgren, Aguiar Carlos (EXT-INdT/Manaus),
	ext David Brownell, Lizardo Anderson (EXT-INdT/Manaus),
	linux-kernel

Anderson Briglia wrote:
>
> This patch is needed only for lock/unlock commands. So, it's necessary to
> make MMC omap works when using that feature. It's not a generic patch.
> But I can take off this one from the series and send after (if) the
> series
> is integrated.
>

The patches are marked "[RFC]" which I interpret as that I shouldn't
merge it. Is this incorrect?

>
> frame depends on data->blksz. When we were using data->blksz_bits
> everything was
> ok because we always had a multiple of 16 bits (2 bytes). Once a pwd
> can has a size
> not multiple of 2, the value must be rounded.
> According to MMC OMAP Technical Reference Manual, because of each DMA
> transfer is of
> equal size, it is necessary to have the block size of the transfer be
> a multiple of
> the DMA write access size (which is 2 bytes).
>

This sounds very generic and not something that is specific to the
password command.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff
  2006-12-01 21:20     ` Pierre Ossman
@ 2006-12-04 16:22       ` Anderson Briglia
  0 siblings, 0 replies; 5+ messages in thread
From: Anderson Briglia @ 2006-12-04 16:22 UTC (permalink / raw)
  To: ext Pierre Ossman
  Cc: Linux-omap-open-source@linux.omap.com, Russell King,
	Tony Lindgren, Aguiar Carlos (EXT-INdT/Manaus),
	ext David Brownell, Lizardo Anderson (EXT-INdT/Manaus),
	linux-kernel

ext Pierre Ossman wrote:
> Anderson Briglia wrote:
>> This patch is needed only for lock/unlock commands. So, it's necessary to
>> make MMC omap works when using that feature. It's not a generic patch.
>> But I can take off this one from the series and send after (if) the
>> series
>> is integrated.
>>
> 
> The patches are marked "[RFC]" which I interpret as that I shouldn't
> merge it. Is this incorrect?

Yes, you're right. But I believe this code is almost "ready" to be applied, do
you agree?
The next series I'll send without the "[RFC]" mark, what do you think?

> 
>> frame depends on data->blksz. When we were using data->blksz_bits
>> everything was
>> ok because we always had a multiple of 16 bits (2 bytes). Once a pwd
>> can has a size
>> not multiple of 2, the value must be rounded.
>> According to MMC OMAP Technical Reference Manual, because of each DMA
>> transfer is of
>> equal size, it is necessary to have the block size of the transfer be
>> a multiple of
>> the DMA write access size (which is 2 bytes).
>>
> 
> This sounds very generic and not something that is specific to the
> password command.

I'm still investigating where is the problem.
Actually this patch will not be included on the next series, as you
suggested. But it is still needed to make MMC lock/unlock works for
OMAP.

Best regards,

Anderson Briglia

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-12-04 16:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-22 14:54 [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff Anderson Briglia
2006-11-25  8:59 ` Pierre Ossman
2006-11-27 13:43   ` Anderson Briglia
2006-12-01 21:20     ` Pierre Ossman
2006-12-04 16:22       ` Anderson Briglia

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox