> >> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
> >>
> >> commit did use
> >> mutex_unlock() in tasklet, but mutex_unlock() can't used in
> >> tasklet(atomic context). The driver need use mutex to avoid concurrency,
> >> so we can't use tasklet here, the patch need to be removed
On 29 April 2014 09:36, Ulf Hansson wrote:
> On 29 April 2014 03:54, wrote:
>> From: Micky Ching
>>
>> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>>
>> commit did use
>> mutex_unlock() in tasklet, but mutex_unlock() can't used in
>> tasklet(atomic context). The driver need u
On 29 April 2014 03:54, wrote:
> From: Micky Ching
>
> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>
> commit did use
> mutex_unlock() in tasklet, but mutex_unlock() can't used in
> tasklet(atomic context). The driver need use mutex to avoid concurrency,
> so we can't use task
From: Micky Ching
This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
commit did use
mutex_unlock() in tasklet, but mutex_unlock() can't used in
tasklet(atomic context). The driver need use mutex to avoid concurrency,
so we can't use tasklet here, the patch need to be removed.
The sp
On 28 April 2014 14:29, Lee Jones wrote:
>> >> From: Micky Ching
>> >>
>> >> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>> >
>> > Why was this patch even merged without an MFD Ack?
>> >
>> >> commit did use
>> >> mutex_unlock() in tasklet, but mutex_unlock() can't used in
>> >
> >> From: Micky Ching
> >>
> >> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
> >
> > Why was this patch even merged without an MFD Ack?
> >
> >> commit did use
> >> mutex_unlock() in tasklet, but mutex_unlock() can't used in
> >> tasklet(atomic context). The driver need use mute
On Mon, Apr 28, 2014 at 11:53:50AM +0100, Lee Jones wrote:
> > From: Micky Ching
> >
> > This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>
> Why was this patch even merged without an MFD Ack?
I think process questions like this are very important.
These patches touch both mmc and
On 28 April 2014 12:53, Lee Jones wrote:
>> From: Micky Ching
>>
>> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>
> Why was this patch even merged without an MFD Ack?
>
>> commit did use
>> mutex_unlock() in tasklet, but mutex_unlock() can't used in
>> tasklet(atomic context).
> From: Micky Ching
>
> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
Why was this patch even merged without an MFD Ack?
> commit did use
> mutex_unlock() in tasklet, but mutex_unlock() can't used in
> tasklet(atomic context). The driver need use mutex to avoid concurrency,
> s
On 28 April 2014 09:36, wrote:
> From: Micky Ching
>
> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>
> commit did use
> mutex_unlock() in tasklet, but mutex_unlock() can't used in
> tasklet(atomic context). The driver need use mutex to avoid concurrency,
> so we can't use task
From: Micky Ching
This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
commit did use
mutex_unlock() in tasklet, but mutex_unlock() can't used in
tasklet(atomic context). The driver need use mutex to avoid concurrency,
so we can't use tasklet here, the patch need to be removed.
The sp
Hi Peter,
I'm considering not using spinlock to get it work and will resend the
patch later.
Thank you.
Best Regards.
micky
On 04/19/2014 07:13 AM, Peter Wu wrote:
So, I reverted c42deffd5b53c9e583d83c7964854ede2f12410d ("mmc: rtsx: add
support for pre_req and post_req") on t
So, I reverted c42deffd5b53c9e583d83c7964854ede2f12410d ("mmc: rtsx: add
support for pre_req and post_req") on top of v3.15-rc1-49-g10ec34f and the
hang issue went away.
There is something that is possibly problematic. All three tasklets (cmd,
data, finish) try to spinlock on
On 03/01/2014 04:35 AM, Dan Carpenter wrote:
Hello Micky Ching,
The patch c42deffd5b53: "mmc: rtsx: add support for pre_req and
post_req" from Feb 17, 2014, leads to the following static checker
warning:
drivers/mmc/host/rtsx_pci_sdmmc.c:525 sd_pre_dma_transfer()
Hello Micky Ching,
The patch c42deffd5b53: "mmc: rtsx: add support for pre_req and
post_req" from Feb 17, 2014, leads to the following static checker
warning:
drivers/mmc/host/rtsx_pci_sdmmc.c:525 sd_pre_dma_transfer()
warn: we tested 'next' before and it was
On Tue, Feb 25, 2014 at 09:52:12AM +0800, micky wrote:
> Hi Dan,
>
> I'm wondering how to get this warning info, so I can check before
> sending patch.
> Can you give me some idea?
>
This is a smatch thing, but you it's a cross function bug so you have to
build the database first and that takes
patch c42deffd5b53: "mmc: rtsx: add support for pre_req and
post_req" from Feb 17, 2014, leads to the following Smatch complaint:
drivers/mmc/host/rtsx_pci_sdmmc.c:194 sd_finish_request()
error: we previously assumed 'mrq' could be null (see line 158)
drivers/mmc/host/rtsx_pci_sd
Hello Micky Ching,
This is a semi-automatic email about new static checker warnings.
The patch c42deffd5b53: "mmc: rtsx: add support for pre_req and
post_req" from Feb 17, 2014, leads to the following Smatch complaint:
drivers/mmc/host/rtsx_pci_sdmmc.c:194 sd_finish_request()
Hello Micky Ching,
This is a semi-automatic email about new static checker warnings.
The patch c42deffd5b53: "mmc: rtsx: add support for pre_req and
post_req" from Feb 17, 2014, leads to the following Smatch complaint:
drivers/mmc/host/rtsx_pci_sdmmc.c:504 sd_get_rsp()
From: Micky Ching
Add support for non-blocking request, pre_req() runs dma_map_sg() and
post_req() runs dma_unmap_sg(). This patch can increase card read/write
speed, especially for high speed card and slow CPU(for some embedded
platform).
Users can get a great benefit from this patch. if CPU fr
From: Micky Ching
Add support for non-blocking request, pre_req() runs dma_map_sg() and
post_req() runs dma_unmap_sg(). This patch can increase card read/write
speed, especially for high speed card and slow CPU(for some embedded
platform).
Users can get a great benefit from this patch. if CPU fr
From: Micky Ching
Add support for non-blocking request, pre_req() runs dma_map_sg() and
post_req() runs dma_unmap_sg(). This patch can increase card read/write
speed, especially for high speed card and slow CPU(for some embedded
platform).
Users can get a great benefit from this patch. if CPU fr
22 matches
Mail list logo
