On 08/04/2020 22:45, Christoph Hellwig wrote:
On Wed, Apr 08, 2020 at 10:43:00PM +0300, Grygorii Strashko wrote:
+static const char *type2name[5] = {
+ [dma_debug_single] = "single",
+ [dma_debug_sg] = "scather-gather",
+ [dma_debug_c
L=40 DMA_BIDIRECTIONAL dma map error check not applicable
Fixes: 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using
dma_map_page_attrs")
Signed-off-by: Grygorii Strashko
---
v2:
- witch to use named initializers.
kernel/dma/debug.c | 9 ++---
1 file changed, 6 insertions
On 08/04/2020 21:49, Christoph Hellwig wrote:
On Wed, Apr 08, 2020 at 09:48:04PM +0300, Grygorii Strashko wrote:
The commit 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using
dma_map_page_attrs") removed "dma_debug_page" enum, but missed to update
ty
or check not applicable
Fixes: 2e05ea5cdc1a ("dma-mapping: implement dma_map_single_attrs using
dma_map_page_attrs")
Signed-off-by: Grygorii Strashko
---
kernel/dma/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 2031ed
On 07/27/2018 03:11 PM, Robin Murphy wrote:
> On 2018-07-27 6:45 PM, Grygorii Strashko wrote:
>> On 07/23/2018 05:16 PM, Robin Murphy wrote:
>>> Whilst the notion of an upstream DMA restriction is most commonly seen
>>> in PCI host bridges saddled with a 32-b
On 07/27/2018 01:13 PM, Russell King - ARM Linux wrote:
> On Fri, Jul 27, 2018 at 12:36:00PM +0100, Robin Murphy wrote:
>> That is intentional. Consider a 32-bit device on a bus with an upstream DMA
>> range of 40 bits (which could easily happen with e.g. PCI). If the firmware
>> code gives
On 07/23/2018 05:16 PM, Robin Murphy wrote:
Whilst the notion of an upstream DMA restriction is most commonly seen
in PCI host bridges saddled with a 32-bit native interface, a more
general version of the same issue can exist on complex SoCs where a bus
or point-to-point interconnect link
On 07/27/2018 06:36 AM, Robin Murphy wrote:
On 27/07/18 01:22, Grygorii Strashko wrote:
[...]
the result of this change is pretty strange as for me :(
Resulted code:
/*
* If @dev is expected to be DMA-capable then the bus code that
created
* it should have initialised its
On 07/27/2018 05:55 AM, Robin Murphy wrote:
> Hi Grygorii,
>
> Thanks for the report.
>
> On 27/07/18 00:45, Grygorii Strashko wrote:
> [...]
>> With this series applied I can't boot TI ARM32 am574x-idk any more.
>>
>> And log output is full of "
On 07/23/2018 05:16 PM, Robin Murphy wrote:
> Whilst the common firmware code invoked by dma_configure() initialises
> devices' DMA masks according to limitations described by the respective
> properties ("dma-ranges" for OF and _DMA/IORT for ACPI), the nature of
> the dma_set_mask() API leads
On 07/26/2018 06:52 PM, Grygorii Strashko wrote:
>
>
> On 07/23/2018 05:16 PM, Robin Murphy wrote:
>> Now that we can track upstream DMA constraints properly with
>> bus_dma_mask instead of trying (and failing) to maintain it in
>> coherent_dma_mask,
On 07/23/2018 05:16 PM, Robin Murphy wrote:
> Now that we can track upstream DMA constraints properly with
> bus_dma_mask instead of trying (and failing) to maintain it in
> coherent_dma_mask, it doesn't make much sense for the firmware code to
> be touching the latter at all. It's merely
Hi Will,
On 09/08/2014 01:31 PM, Will Deacon wrote:
On Fri, Sep 05, 2014 at 04:37:41PM +0100, Grygorii Strashko wrote:
On 09/02/2014 08:56 PM, Will Deacon wrote:
set_arch_dma_coherent_ops is called from of_dma_configure in order to
swizzle the architectural dma-mapping functions over
13 matches
Mail list logo
