‐‐‐ Original Message ‐‐‐
On 2019年9月19日ThursdayPM6点25分, Paul Walmsley wrote:
> On Fri, 6 Sep 2019, Xiang Wang wrote:
>
> > From 12300865d1103618c9d4c375f7d7fbe601b6618c Mon Sep 17 00:00:00 2001
> > From: Xiang Wang me...@hardenedlinux.org
> > Date: Fri, 6
‐‐‐ Original Message ‐‐‐
On 2019年9月14日SaturdayAM3点04分, Palmer Dabbelt wrote:
> On Thu, 05 Sep 2019 23:51:15 PDT (-0700), me...@hardenedlinux.org wrote:
>
> > From 12300865d1103618c9d4c375f7d7fbe601b6618c Mon Sep 17 00:00:00 2001
> > From: Xiang Wang me...@hardened
>From 12300865d1103618c9d4c375f7d7fbe601b6618c Mon Sep 17 00:00:00 2001
From: Xiang Wang
Date: Fri, 6 Sep 2019 11:56:09 +0800
Subject: [PATCH] arch/riscv: disable too many harts before pick main boot hart
These harts with id greater than or equal to CONFIG_NR_CPUS need to be disabled.
But p
2015-10-15 17:40 GMT+08:00 Andy Shevchenko :
> On Thu, 2015-10-15 at 11:32 +0300, Jarkko Nikula wrote:
>> On 10/15/2015 08:46 AM, Xiang Wang wrote:
>> >
>> > In conclusion, we have 2 solutions to set the i2c controller speed
>> > mode (pci driver):
>> &g
2015-10-12 16:31 GMT+08:00 Andy Shevchenko :
> On Mon, 2015-10-12 at 15:41 +0800, Xiang Wang wrote:
>> Hi, Andy
>> Thanks for your comments.
>>
>> [Andy] Don't see a relationship between PCI driver and this ACPI
>> stuff.
>> Although this is a pci d
nware-core: i2c_dw_acpi_setup_speed can be used by both plat
and pci driver. Thanks
2015-10-09 17:31 GMT+08:00 Andy Shevchenko :
> On Fri, 2015-10-09 at 16:47 +0800, wangx...@gmail.com wrote:
>> From: Xiang Wang
>>
>> 1. Support setting hs_hcnt and hs_lcnt
>> 2. Get bus speed mode from AC
From: Xiang Wang
There might be such calling sequence for dma channel:
1. register dma device
dma_async_device_register
-> if (dma_has_cap(DMA_PRIVATE, device->cap_mask))
device->privatecnt++;
2. request channel
dma_request_slave_channel
-> of_dma_request_s
From: Xiang Wang
Commit 0dcaa2499b7d111bd70da5b0976c34210c850fb3 improved error
handling of sdhci_add_host. However, "err_of_parse" and "err_cd_req"
should be placed after "pm_runtime_disable(&pdev->dev)".
Signed-off-by: Xiang Wang
---
drivers/mmc/ho
2013/7/29 Vinod Koul :
> On Thu, Jul 25, 2013 at 10:22:50AM +0800, Xiang Wang wrote:
>
> Btw its generally a good idea to remove the parts not required for further
> discussion
>
>> Would you please explain a little more about why we should use
>> GFP_NOWAIT here? This
2013/7/5 Vinod Koul :
> On Tue, Jun 18, 2013 at 02:21:58PM +0800, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> pdev->phy is of type "struct mmp_pdma_phy *". But when
>> allocating memory for it, "struct mmp_pdma_chan" is used
>> by mistake.
Hi, maintainers
What's the status of this patch set V3? Sorry for pushing. Thanks!
2013/6/18 Xiang Wang :
> From: Xiang Wang
>
> This patch set deals with the issues that 1) phy channels are not protected
> in mmp_pdma. 2) dma request<->channel mapping is not cleared whe
2013/7/5 Vinod Koul :
> On Tue, Jun 18, 2013 at 04:41:20PM +0800, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> In some of our drivers (e.g. UART) we may stop a running DMA
>> before it finishes. So we need APIs to know how many bytes
>> have been transferred
Hi, all
Do you have any comments about this patch? Thanks!
2013/6/18 Xiang Wang :
> From: Xiang Wang
>
> In some of our drivers (e.g. UART) we may stop a running DMA
> before it finishes. So we need APIs to know how many bytes
> have been transferred.
>
> Sign
Hi,
Do you have any comments about this patch? Have modified according to
Vinod's advice. Thanks!
2013/6/18 Xiang Wang :
> From: Xiang Wang
>
> pdev->phy is of type "struct mmp_pdma_phy *". But when
> allocating memory for it, "struct mmp_pdma_chan" is use
Hi, all
Do you have any comments about this patch set? Thanks!
2013/6/18 Xiang Wang :
> From: Xiang Wang
>
> This patch set deals with the issues that 1) phy channels are not protected
> in mmp_pdma. 2) dma request<->channel mapping is not cleared when a phy chan
> is fre
2013/6/17 Vinod Koul :
> On Fri, May 31, 2013 at 04:21:25PM +0800, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> In some of our drivers (e.g. UART) we may stop a running DMA
>> before it finishes. So we need to know how many bytes have
>> been transferred
From: Xiang Wang
In some of our drivers (e.g. UART) we may stop a running DMA
before it finishes. So we need APIs to know how many bytes
have been transferred.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c | 88 +++
1 files changed, 80
2013/6/17 Vinod Koul :
> On Mon, Jun 03, 2013 at 04:02:08PM +0800, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> In mmp pdma, phy channels are allocated/freed dynamically
>> and frequently. But no proper protection is added.
>> Conflict will happen when multi-users
2013/6/17 Vinod Koul :
> On Tue, May 28, 2013 at 08:05:13PM +0800, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> pdev->phy is of type "struct mmp_pdma_phy *". But when
>> allocating memory for it, "struct mmp_pdma_chan" is used
>> by mistake.
From: Xiang Wang
This patch set deals with the issues that 1) phy channels are not protected
in mmp_pdma. 2) dma request<->channel mapping is not cleared when a phy chan
is freed.
Xiang Wang (2):
dma: mmp_pdma: add protect when alloc/free phy channels
dma: mmp_pdma: clear DRCMR when
From: Xiang Wang
In mmp pdma, phy channels are allocated/freed dynamically.
The mapping from DMA request to DMA channel number in DRCMR
should be cleared when a phy channel is freed. Otherwise
conflicts will happen when:
1. A is using channel 2 and free it after finished, but A
still maps to
From: Xiang Wang
In mmp pdma, phy channels are allocated/freed dynamically
and frequently. But no proper protection is added.
Conflict will happen when multi-users are requesting phy
channels at the same time. Use spinlock to protect.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c
From: Xiang Wang
pdev->phy is of type "struct mmp_pdma_phy *". But when
allocating memory for it, "struct mmp_pdma_chan" is used
by mistake.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/d
2013/6/6 Xiang Wang :
> From: Xiang Wang
>
> This patch set deals with the issues that 1) phy channels are not protected
> in mmp_pdma. 2) dma request<->channel mapping is not cleared when a phy chan
> is freed.
>
> Xiang Wang (2):
> dma: mmp_pdma: add protec
2013/5/31 Xiang Wang :
> 2013/5/28 Andy Shevchenko :
>> On Tue, May 28, 2013 at 3:05 PM, Xiang Wang wrote:
>>> From: Xiang Wang
>>>
>>> pdev->phy is of type "struct mmp_pdma_phy *". But when
>>> allocating memory for it, "struct
2013/6/6 Andy Shevchenko :
> On Thu, Jun 6, 2013 at 6:09 AM, Xiang Wang wrote:
>> 2013/6/3 Andy Shevchenko :
>>> On Mon, Jun 3, 2013 at 6:22 AM, Xiang Wang wrote:
>>>> 2013/5/31 Andy Shevchenko :
>>>>> On Fri, May 31, 2013 at 11:21 AM, Xiang Wang wr
2013/6/3 Andy Shevchenko :
> On Mon, Jun 3, 2013 at 6:22 AM, Xiang Wang wrote:
>> 2013/5/31 Andy Shevchenko :
>>> On Fri, May 31, 2013 at 11:21 AM, Xiang Wang wrote:
>>>> In some of our drivers (e.g. UART) we may stop a running DMA
>>>> before it finish
From: Xiang Wang
In mmp pdma, phy channels are allocated/freed dynamically
and frequently. But no proper protection is added.
Conflict will happen when multi-users are requesting phy
channels at the same time. Use spinlock to protect.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c
From: Xiang Wang
In mmp pdma, phy channels are allocated/freed dynamically.
The mapping from DMA request to DMA channel number in DRCMR
should be cleared when a phy channel is freed. Otherwise
conflicts will happen when:
1. A is using channel 2 and free it after finished, but A
still maps to
From: Xiang Wang
This patch set deals with the issues that 1) phy channels are not protected
in mmp_pdma. 2) dma request<->channel mapping is not cleared when a phy chan
is freed.
Xiang Wang (2):
dma: mmp_pdma: add protect when alloc/free phy channels
dma: mmp_pdma: clear DRCMR when
From: Xiang Wang
In mmp pdma, phy channels are allocated/freed dynamically
and frequently. But no proper protection is added.
Conflict will happen when multi-users are requesting phy
channels at the same time. Use spinlock to protect.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c
From: Xiang Wang
In mmp pdma, phy channels are allocated/freed dynamically.
The mapping from DMA request to DMA channel number in DRCMR
should be cleared when a phy channel is freed. Otherwise
conflicts will happen when:
1. A is using channel 2 and free it after finished, but A
still maps to
From: Xiang Wang
This patch set deals with the issues that 1) phy channels are not protected
in mmp_pdma. 2) dma request<->channel mapping is not cleared when a phy chan
is freed.
Xiang Wang (2):
dma: mmp_pdma: add protect when alloc/free phy channels
dma: mmp_pdma: clear DRCMR when
2013/5/31 Andy Shevchenko :
> On Fri, May 31, 2013 at 11:21 AM, Xiang Wang wrote:
>> In some of our drivers (e.g. UART) we may stop a running DMA
>> before it finishes. So we need to know how many bytes have
>> been transferred.
>
> Couple of comments below.
>
&
From: Xiang Wang
In some of our drivers (e.g. UART) we may stop a running DMA
before it finishes. So we need to know how many bytes have
been transferred.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c | 77 +++-
1 files changed, 69
2013/5/28 Andy Shevchenko :
> On Tue, May 28, 2013 at 3:05 PM, Xiang Wang wrote:
>> From: Xiang Wang
>>
>> pdev->phy is of type "struct mmp_pdma_phy *". But when
>> allocating memory for it, "struct mmp_pdma_chan" is used
>> by mistake
From: Xiang Wang
pdev->phy is of type "struct mmp_pdma_phy *". But when
allocating memory for it, "struct mmp_pdma_chan" is used
by mistake.
Signed-off-by: Xiang Wang
---
drivers/dma/mmp_pdma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/d
37 matches
Mail list logo
