2011/9/30 Adrian Hunter adrian.hun...@intel.com:
Perhaps rebase against Chris' mmc-next branch
I made this patch after rebasing Chris'mmc-next yesterday.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo
thanks for reply Jaehoon,
The reason I had hard coded was the PCI card that I was using had a
single SD/MMC slot. I will make necessary change and submit another
patch.
On Fri, Sep 30, 2011 at 7:21 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Shashidhar.
On 09/30/2011 02:40 AM,
2011/9/30 NamJae Jeon linkinj...@gmail.com:
2011/9/30 Adrian Hunter adrian.hun...@intel.com:
Perhaps rebase against Chris' mmc-next branch
I made this patch after rebasing Chris'mmc-next yesterday.
Hi. Adrian.
There is the overlapped code between your patch and my patch.
What should we do ?
Hi James,
2011/9/29 J Freyensee james_p_freyen...@linux.intel.com:
As I've been playing around with with buffering/caching, it seems to me an
opportunity to simplify things in the MMC space is to eliminate the need for
a mmc_blk_request struct or mmc_request struct. With looking through the
In dw_mmc 2.40a spec, Data register's offset is changed.
Now we used Data register offset is 0x100. but if somebody use 2.40a
controller, must use 0x200 for Data register.
This patch is added version-id checking point and write/read function
with data_offset for DATA register.(e.g
Hi
On 09/29/2011 06:40 PM, Shashidhar Hiremath wrote:
Support of PCI mode for the dw_mmc driver This Patch adds the support for the
scenario where the Synopsys Designware IP is present on the PCI bus.The patch
adds the minimal modifications necessary for the driver to work on PCI
platform.
On 30/09/11 11:11, NamJae Jeon wrote:
2011/9/30 NamJae Jeonlinkinj...@gmail.com:
2011/9/30 Adrian Hunteradrian.hun...@intel.com:
Perhaps rebase against Chris' mmc-next branch
I made this patch after rebasing Chris'mmc-next yesterday.
Hi. Adrian.
There is the overlapped code between your
Hi,
Thanks for sending the patch.
On 09/30/2011 09:37 AM, Jaehoon Chung wrote:
In dw_mmc 2.40a spec, Data register's offset is changed.
Now we used Data register offset is 0x100. but if somebody use 2.40a
controller, must use 0x200 for Data register.
This patch is added version-id checking
Hi James.
Can I suggest that instead of having 6 new macros with offset parameters
from the reg parameter (after all, the caller can just add the offset to
the reg argument just as easily), you simply store the data register
offset (what is currently DATA+host-data_offset) instead of
Hi
On 09/30/2011 11:01 AM, Jaehoon Chung wrote:
Hi James.
Can I suggest that instead of having 6 new macros with offset parameters
from the reg parameter (after all, the caller can just add the offset to
the reg argument just as easily), you simply store the data register
offset (what is
This patch is added the use_hold_reg bit in CMD register.
In 2.40a, bit[29] of CMD register is used the use_hold_reg.
Some SoC is affected by this bit.
(This bit means whether use hold register when send data and cmd.
And related with cclk_in_drv phase)
if set IMPLEMENT_HOLD_REG in HCON
Hi,
On 09/30/2011 11:46 AM, Jaehoon Chung wrote:
This patch is added the use_hold_reg bit in CMD register.
In 2.40a, bit[29] of CMD register is used the use_hold_reg.
Some SoC is affected by this bit.
(This bit means whether use hold register when send data and cmd.
And related with
On Thu, Sep 29, 2011 at 9:50 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110929 07:11]:
MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF.
It allows gerneral purpose partitions in MMC Device.
And I try to simpliy make mmc_blk_alloc_parts using mmc_part structure
suggested by Andrei Warkentin.
After patching, we can see general purpose partitions like this.
cat /proc/partitions
179 0 847872 mmcblk0
179 192 4096
It allows gerneral purpose partitions in MMC Device.
And I try to simpliy make mmc_blk_alloc_parts using mmc_part structure
suggested by Andrei Warkentin.
After patching, we can see general purpose partitions like this.
cat /proc/partitions
179 0 847872 mmcblk0
179 192 4096
Hi Namjae,
Why don't you update card-nr_parts inside mmc_part_add? You're making
this too complicated. There
is also no need for the part_cfg array.
2011/9/30 Namjae Jeon linkinj...@gmail.com:
It allows gerneral purpose partitions in MMC Device.
And I try to simpliy make mmc_blk_alloc_parts
Hi,
2011/9/28 Barry Song barry.s...@csr.com:
From: Barry Song baohua.s...@csr.com
now we wait 1ms after every loop, in the worst case, 1ms will be wasted.
that both decreases sd performance and increases cpu usage.
This patch shorten the interval to 1us, then in the worst case, only 1us
is
On 09/30/2011 01:22 AM, Andrei E. Warkentin wrote:
Hi James,
2011/9/29 J Freyenseejames_p_freyen...@linux.intel.com:
As I've been playing around with with buffering/caching, it seems to me an
opportunity to simplify things in the MMC space is to eliminate the need for
a mmc_blk_request struct
18 matches
Mail list logo
