From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11805C67861 for ; Fri, 5 Apr 2024 10:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:From:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=Z2M8YxQODUHT6ikWZCjCYjIw7/S6jCCTDOwoZpKOiS0=; b=mQu1f9LMqkWztt XUvDJjJa6sXJGk6N8Ba08DFEYT8scty0aCdpZsjHFbbBuXFo1BrJqGdJ+Zk2cgUOQoTXnS/fLGzO/ L9WGlV+CmUnGzhrqUCelTVj83iLMi6ErNQ0O/YrZwSMsXQV3jUh1eO0lh4SYTlk2wsLIz11A+BrLE F8FZXvB5IiDfpSOW2E0CI8KRKiuz44G1lj8h/MWOfklhT1ASDnDAGtYZs7U71UT1oKsMV+dV4J+nY lNimh6W56mDHyiIlLQY4TR6s8TpiSZAkaiLMiExoSBmcWVL4y+CoimoskSdRWmBkb8gKV03l3pzk4 1JZZkdfg/9iULArCGmWw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsgRs-00000006L64-3Qsa; Fri, 05 Apr 2024 10:05:29 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rsgRo-00000006L2l-3pOu for linux-arm-kernel@lists.infradead.org; Fri, 05 Apr 2024 10:05:27 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d47a92cfefso25352811fa.1 for ; Fri, 05 Apr 2024 03:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712311522; x=1712916322; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:subject:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=WwcV05X3lqi4MM+buZxa5Jcly8fqYYsYkniToo40n50=; b=F2JMsyh/vs/MrY/xvyyEzXpy4EDTQ8xlIHfGbhN3SqoeXqeWsEiyHM6JGY9SSGqI4G prGQ56cc19q/T79JJKjIZtKdyjBQz1x0INJd8+WMn0ReUlMobUiewdlo6f4Xnyn7VqDV DxHyD4y/WaN0XFm44hiKWH5kJbEHT6M4AALg0SlHeyt1OAtHLr0eino777Nh0+tqMZJT BpMLuT/Gi1/j2BaSCUZy2DbLo0hhKBHfHVRrKXHJKuwNfCpkXatCrOBfjkowBJAUh52e R8/iy+YlY8ESlH/AXZ4Q/v6sOiX5fIF3VSFXYCwfkZuXr26xxKesAX33rw09URF2kHwO HPuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712311522; x=1712916322; h=content-transfer-encoding:cc:to:subject:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=WwcV05X3lqi4MM+buZxa5Jcly8fqYYsYkniToo40n50=; b=niFSFeYKSO+owwcF17+AVJDQjInWkdlisvnjDObbHiU8xGjoBOUWv0ahWhvHxwIGDl wfLAFDdbgDzZOo7qGjU82hFshN0xeOZylHZVxxwmGA4joDcSTwkVrTasbm1ObBiebaeA IVpO4m8x3wsx9XeAui7eLxHKzBaOa1V9p+APqI8trKM5KBUqkqmQAqXI0pYIGHVIDAZf k2ADwnvzcjNTWpOvS3Ab/XZz95tKHvGhx98c6YS0KkVrqaIukvmQm3UOniWSfwoLZxtC 9Oxjzcj9qmZ5n2GGcRJTKHl7tg2ODoB63/lHG6hl9CE1r9x1/KlYqlO8ItUA7L4mSoUZ A4Rg== X-Gm-Message-State: AOJu0YzC/8e0ZWMcr25Ww1n3hRVq6rhZlSWDOzcLZ4K8BtOdKWUXu9RE abI9A8yuQumtEvwuwGqLHvB0G/6q2Av9T1ataBauwoSHJu+9wC7Sq3i6JJTY4xA= X-Google-Smtp-Source: AGHT+IF/mnkjD81MfQ9NRJLmv+Df3tYQPOjV/tVLAZmpQGuXJx5AC651mf0V7ABqFuKf8dZ5K3m+Xg== X-Received: by 2002:a2e:9b0b:0:b0:2d7:1830:d5f9 with SMTP id u11-20020a2e9b0b000000b002d71830d5f9mr742081lji.31.1712311521856; Fri, 05 Apr 2024 03:05:21 -0700 (PDT) Received: from [192.168.2.107] ([82.76.204.14]) by smtp.gmail.com with ESMTPSA id u11-20020a05600c210b00b00414674a1a40sm2312275wml.45.2024.04.05.03.05.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Apr 2024 03:05:21 -0700 (PDT) Message-ID: Date: Fri, 5 Apr 2024 11:05:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Tudor Ambarus Subject: GS101 pl330 AxCACHE To: Arnd Bergmann , =?UTF-8?B?6rmA7J6s7JuQL0pBRVdPTiBLSU0=?= , Vinod Koul , dmaengine@vger.kernel.org, bumyong.lee@samsung.com, surendran.k@samsung.com, l.stelmach@samsung.com, m.szyprowski@samsung.com Cc: linux-arm-kernel , linux-samsung-soc@vger.kernel.org, "linux-kernel@vger.kernel.org" , =?UTF-8?Q?Andr=C3=A9_Draszik?= , Peter Griffin , William McVicker , kernel-team@android.com, Sam Protsenko , Krzysztof Kozlowski , sugar.zhang@rock-chips.com, Alim Akhtar , Sylwester Nawrocki , Chanwoo Choi , jassisinghbrar@gmail.com, "Simek, Michal" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240405_030525_162758_232C1D78 X-CRM114-Status: GOOD ( 16.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, I'm trying to enable the pl330 DMA controller in GS101 and I'm facing some problems related to AxCACHE. I'm writing this with the hope that someone (from samsung?) knows a bit more about the pl330 integration and its AxCACHE use. For simplicity, let's consider just the DMA_MEM_TO_MEM case for the moment. With the current upstream pl330 driver I see that the dmatest module complains with errors like: [ 6572.661927][ T6358] dmatest: dma0chan0-copy0: dstbuf[0x18e0] not copied! Expected cf, got 3f Checked the downstream driver and found a fix: - desc->rqcfg.scctl = CCTRL0; - desc->rqcfg.dcctl = CCTRL0; + desc->rqcfg.scctl = CCTRL2; + desc->rqcfg.dcctl = CCTRL2; According to CoreLing DMA-330 TRM [1], the {dst,src}_cache_ctrl fields program the state of AxCACHE. AMBA AXI and ACE Protocol Specification [2] says that these signals specify the memory attributes of a request. - CTRL0 -> AxCACHE[3:0] = 0b0000 (Device non-bufferable) - CTRL2 -> AxCACHE[3:0] = 0b0010 (Normal Non-cacheable Non-bufferable) AxCACHE[1] bit is the Modifiable bit. I guess that GS101 can not meet the requirements of Non-modifiable transactions. But why? Culprit could be TREX, the non-coherent interconnect, which collects requests from different masters and sends the request to cache coherent interconnect and to System-Level Cache. But I can't pin-point the exact restriction that comes with it. Any hints here are appreciated. Thanks for reading up to here. Let's consider now the DMA_MEM_TO_DEV and DMA_DEV_TO_MEM cases. I guess that for simplicity the driver author chose to always set CCTRL0 for both src and dst regardless of the memory type, device or normal. This is possible because normal non-cacheable memory can be accessed by any Manager using a device memory transaction (see "A4.5 Mismatched memory attributes" section of [2]). This can be improved however, if we use CTRL0 (thus Device non-bufferable) for DEV, and CTRL2 (thus Normal Non-cacheable Non-bufferable) for MEM. I tried this suggestion on GS101 for a MEM to DEV transaction and I get timeouts. I tried the downstream driver as well. The downstream GS101 device tree defines all the USI nodes without DMA support, I guess the to/from DEV transactions are not sorted out yet. I enabled the DMA use for USI in downstream and ITMON complains with "Unsupported transaction error". Any feedback is welcomed. Thanks! ta [1] https://documentation-service.arm.com/static/5e8e25befd977155116a5ad9?token= [2] https://documentation-service.arm.com/static/602a9df190ee6824a1e02b98?token= _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel