On Mon, Sep 25, 2023 at 10:26:48AM -0700, Tanmay Shah wrote:
> Introduce device address in hardcode TCM table.
> Device address is used for address translation.
> Also, previous method(hack) to mask few bits from address
> to achieve address translation is removed
>
> Signed-o
Introduce device address in hardcode TCM table.
Device address is used for address translation.
Also, previous method(hack) to mask few bits from address
to achieve address translation is removed
Signed-off-by: Tanmay Shah
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 58
From: farah kassabri
when user uses virtual addresses to access dram through debugfs,
driver translate this address to physical and use it
for the access through the pcie bar.
in case dram page size is different than the dmmu
page size, we need to have special treatment
for adding the page offset
From: Bharat Gooty
commit da8ee66f56071aef0b5b0de41d2c2a97fa30c8a1 upstream.
Add a non-empty dma-ranges so that DMA address translation happens.
Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by empty
dma-ranges")
Signed-off-by: Bharat Gooty
Signed-off-by:
From: Bharat Gooty
commit da8ee66f56071aef0b5b0de41d2c2a97fa30c8a1 upstream.
Add a non-empty dma-ranges so that DMA address translation happens.
Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by empty
dma-ranges")
Signed-off-by: Bharat Gooty
Signed-off-by:
On Tue, 19 Jan 2021 11:04:44 +0530, Rayagonda Kokatanur
wrote:
> From: Bharat Gooty
>
> Add a non-empty dma-ranges so that dma address translation
> happens.
>
> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> empty dma-ranges")
&
On 1/18/2021 9:34 PM, Rayagonda Kokatanur wrote:
> From: Bharat Gooty
>
> Add a non-empty dma-ranges so that dma address translation
> happens.
>
> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> empty dma-ranges")
>
> Signed-
On Tue, Jan 19, 2021 at 6:34 AM Rayagonda Kokatanur
wrote:
>
> From: Bharat Gooty
>
> Add a non-empty dma-ranges so that dma address translation
> happens.
>
> Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by
> empty dma-ranges")
>
&g
From: Bharat Gooty
Add a non-empty dma-ranges so that dma address translation
happens.
Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by empty
dma-ranges")
Signed-off-by: Bharat Gooty
Signed-off-by: Rayagonda Kokatanur
---
arch/arm64/boot/dts/broadco
edac. The
> > only issue is getting the address translation to earlier notifiers. I
> > think we can add a new one in amd64_edac to run before others. Maybe this
> > can be a new priority class like MCE_PRIO_PREPROCESS, or something like
> > that for notifiers that fixup the
ECC errors, so it make sense to have it in amd64_edac. The
> only issue is getting the address translation to earlier notifiers. I
> think we can add a new one in amd64_edac to run before others. Maybe this
> can be a new priority class like MCE_PRIO_PREPROCESS, or something like
> that f
On Mon, Sep 28, 2020 at 11:47:59AM +0200, Borislav Petkov wrote:
> On Fri, Sep 25, 2020 at 02:51:27PM -0500, Yazen Ghannam wrote:
>
> > The address translation needs to be done before the notfiers that need
> > it, and EDAC comes after all of them. There's also the
s.
Unfortunately, that is correct. :-\
> The address translation needs to be done before the notfiers that need
> it, and EDAC comes after all of them. There's also the case where the
> EDAC interface isn't wanted, so amd64_edac will be unloaded.
I'd be interested
al address before the notifiers in the MCE chain can use it.
We can add support to get the physical address from firmware in some
cases. But it looks to me that we'll still need to keep updating the
translation code in the kernel to cover some platform/user
configurations. So it makes s
On Wed, Sep 23, 2020 at 11:25:10AM -0500, Yazen Ghannam wrote:
> I don't remember the original reason, and I was recently asked about
> this code living in a module. I did some looking after this ask, and I
> found that we should be using this translation to get a proper value for
> the memory erro
Channel
> > - Die
> > - Socket
> >
> > Rome (NPS = Nodes per Socket)
> > - None
> > - NPS0
> > - NPS1
> > - NPS2
> > - NPS4
> >
> > The fixes tag refers to the commit that allows amd64_edac_mod to load on
> > Rome systems.
&g
;
> The fixes tag refers to the commit that allows amd64_edac_mod to load on
> Rome systems.
Err, why? This is adding new stuff to an address translation function.
How does that fix amd64_edac loading on Rome?
> The module may report an incorrect system addresses on
> Rome systems dep
From: Muralidhara M K
Add support for new memory interleaving modes used in current AMD systems.
Check if the system is using a current Data Fabric version or a legacy
version as some bit and register definitions have changed.
Tested on AMD reference platforms with the following memory interlea
From: Yazen Ghannam
This patchset includes updates for the MCA Address Translation process
on recent AMD systems.
Patches 1 & 3:
Fixes an input to the address translation function. The translation
requires a physical Die ID (NodeId in AMD documentation) rather than a
logicial NUMA node ID.
On Sat, Aug 15, 2020 at 11:13:36AM +0200, Ingo Molnar wrote:
>
> * Yazen Ghannam wrote:
>
> > + /* Read D18F1x208 (System Fabric ID Mask 0). */
> > + if (amd_df_indirect_read(nid, 1, 0x208, umc, &tmp))
> > + goto out_err;
> > +
> > + /* Determine if system is a legacy Dat
* Yazen Ghannam wrote:
> + /* Read D18F1x208 (System Fabric ID Mask 0). */
> + if (amd_df_indirect_read(nid, 1, 0x208, umc, &tmp))
> + goto out_err;
> +
> + /* Determine if system is a legacy Data Fabric type. */
> + legacy_df = !(tmp & 0xFF);
1)
I see this pattern
From: Muralidhara M K
Add support for new memory interleaving schemes used in current AMD
systems.
Check if the system is using a current Data Fabric version or a legacy
version as some bit and register definitions have changed.
Tested on AMD reference platforms with the following memory interl
From: Yazen Ghannam
This patchset includes updates for the MCA Address Translation process
on recent AMD systems.
Patch 1:
Fixes an input to the address translation function. The translation
requires a physical Die ID (NodeId in AMD documentation) rather than a
logicial NUMA node ID. This is
The devices found behind this PCIe chip have unusual DMA mapping
constraints as there is an AMBA interconnect placed in between them and
the different PCI endpoints. The offset between physical memory
addresses and AMBA's view is provided by reading a PCI config register,
which is saved and used wh
Hi Bjorn,
thanks for having a look at it.
On Thu, 2019-10-17 at 17:41 -0500, Bjorn Helgaas wrote:
> Hi Nicolas,
>
> I'm hoping Christoph will chime in and one of the x86 guys will merge
> this, since I'm not a DMA expert. Trivial comments/questions below.
>
> On Wed, Oct 16, 2019 at 06:51:37PM
Hi Nicolas,
I'm hoping Christoph will chime in and one of the x86 guys will merge
this, since I'm not a DMA expert. Trivial comments/questions below.
On Wed, Oct 16, 2019 at 06:51:37PM +0200, Nicolas Saenz Julienne wrote:
> The devices found behind this PCIe chip have unusual DMA mapping
> const
The devices found behind this PCIe chip have unusual DMA mapping
constraints as there is an AMBA interconnect placed in between them and
the different PCI endpoints. The offset between physical memory
addresses and AMBA's view is provided by reading a PCI config register,
which is saved and used wh
The functions for parsing 'dma-ranges' ranges are buggy and fail to
handle several conditions. Add new tests for of_dma_get_range() and
for_each_of_pci_range().
With this test, we get 5 new failures which are fixed in subsequent
commits:
OF: translation of DMA address(0) to CPU address failed
no
Hi,
this is a second round of RFC patches to move forward on discussion about
proper kernel support for the TI DS90UB9xx serializer/deserializer chipsets
with I2C address translation.
RFCv2 is a major improvement over RFCv1, with several parts rewritten from
scratch. I2C address translationis
ach_client() and detach_client() callbacks to
>>i2c-core
>> * Patch 2 adds similar callbacks for the use of device drivers and,
>>most importantly, implements the ATR engine
>> * Patch 3 adds a farily complete DT bindings document, including the
>>alias ma
Em Tue, 8 Jan 2019 23:39:49 +0100
Luca Ceresoli escreveu:
> Hi,
>
> there has been some discussion on linux-media about video
> serializer/deserializer chipsets with remote I2C capabilities from TI
> [0] and Maxim [1]. I took part discussing how the remote I2C feature
> of such chips could be b
3.16.63-rc1 review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
Hi,
there has been some discussion on linux-media about video
serializer/deserializer chipsets with remote I2C capabilities from TI
[0] and Maxim [1]. I took part discussing how the remote I2C feature
of such chips could be best implemented in Linux while I was
implementing a driver for the Texas
On Mon, 2018-12-03 at 17:40:25 UTC, Christophe Leroy wrote:
> This patch adds a debugfs file to dump block address translation:
>
> ~# cat /sys/kernel/debug/powerpc/block_address_translation
> ---[ Instruction Block Address Translations ]---
> 0: -
> 1:
Le 16/11/2018 à 11:20, Michael Ellerman a écrit :
Christophe LEROY writes:
Le 15/11/2018 à 12:46, Michael Ellerman a écrit :
Christophe Leroy writes:
This patch adds a debugfs file to dump block address translation:
~# cat /sys/kernel/debug/block_address_translation
My instinct is
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Max Filippov
commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
The bootloader may pass physical address of the boot parameters structure
to the MMUv3 kernel in the register a2. Code in
On Mon, Sep 17, 2018 at 12:21:49PM +0100, Lorenzo Pieralisi wrote:
> On Wed, May 09, 2018 at 02:01:34PM +0200, Niklas Cassel wrote:
> > For PCI, the second and third cell in ranges specifies the upper and
> > lower target address for address translation. This target address will
On Wed, May 09, 2018 at 02:01:34PM +0200, Niklas Cassel wrote:
> For PCI, the second and third cell in ranges specifies the upper and
> lower target address for address translation. This target address will
> be used to program the internal address translation unit (iATU).
>
> The
Add support for the Coresight Address Translation Unit (CATU), which
provides improved scatter-gather functionality for TMC-ETR. The CATU
performs address translation for ETR based on a page table, which
contains address of 4KB sized data pages, but uses a different
format from that of the TMC-ETR
Add the initial support for Coresight Address Translation Unit, which
augments the TMC in Coresight SoC-600 by providing an improved Scatter
Gather mechanism. CATU is always connected to a single TMC-ETR and
converts the AXI address with a translated address (from a given SG
table with specific
On Tue, 2018-06-26 at 09:59 -0600, Mathieu Poirier wrote:
> On Mon, Jun 25, 2018 at 09:23:51AM -0700, Joe Perches wrote:
> > On Mon, 2018-06-25 at 12:22 +0100, Suzuki K Poulose wrote:
> > > Add the initial support for Coresight Address Translation Unit, which
> > > au
On Mon, Jun 25, 2018 at 09:23:51AM -0700, Joe Perches wrote:
> On Mon, 2018-06-25 at 12:22 +0100, Suzuki K Poulose wrote:
> > Add the initial support for Coresight Address Translation Unit, which
> > augments the TMC in Coresight SoC-600 by providing an improved Scatter
> > G
On Mon, 2018-06-25 at 12:22 +0100, Suzuki K Poulose wrote:
> Add the initial support for Coresight Address Translation Unit, which
> augments the TMC in Coresight SoC-600 by providing an improved Scatter
> Gather mechanism. CATU is always connected to a single TMC-ETR and
> conv
Add support for the Coresight Address Translation Unit (CATU), which
provides improved scatter-gather functionality for TMC-ETR. The CATU
performs address translation for ETR based on a page table, which
contains address of 4KB sized data pages, but uses a different
format from that of the TMC-ETR
Add the initial support for Coresight Address Translation Unit, which
augments the TMC in Coresight SoC-600 by providing an improved Scatter
Gather mechanism. CATU is always connected to a single TMC-ETR and
converts the AXI address with a translated address (from a given SG
table with specific
Hi Mathieu,
On 20/06/1822:41, Mathieu Poirier wrote:
Hi Suzuki,
On Mon, Jun 18, 2018 at 11:56:16AM +0100, Suzuki K Poulose wrote:
Add the initial support for Coresight Address Translation Unit, which
augments the TMC in Coresight SoC-600 by providing an improved Scatter
Gather mechanism. CATU
Hi Suzuki,
On Mon, Jun 18, 2018 at 11:56:16AM +0100, Suzuki K Poulose wrote:
> Add the initial support for Coresight Address Translation Unit, which
> augments the TMC in Coresight SoC-600 by providing an improved Scatter
> Gather mechanism. CATU is always connected to a single TM
Add support for the Coresight Address Translation Unit (CATU), which
provides improved scatter-gather functionality for TMC-ETR. The CATU
performs address translation for ETR based on a page table, which
contains address of 4KB sized data pages, but uses a different
format from that of the TMC-ETR
Add the initial support for Coresight Address Translation Unit, which
augments the TMC in Coresight SoC-600 by providing an improved Scatter
Gather mechanism. CATU is always connected to a single TMC-ETR and
converts the AXI address with a translated address (from a given SG
table with specific
For PCI, the second and third cell in ranges specifies the upper and
lower target address for address translation. This target address will
be used to program the internal address translation unit (iATU).
The current device tree configuration will program the iATU to translate
CPU accesses to
Firstly split the dev table entry copy into address translation part
and irq remapping part. Because these two parts could be enabled
independently.
Secondly do sanity check for address translation and irq remap of old
dev table entry separately.
Signed-off-by: Baoquan He
---
drivers/iommu
Firstly split the dev table entry copy into address translation part
and irq remapping part. Because these two parts could be enabled
independently.
Secondly do sanity check for address translation and irq remap of old
dev table entry separately.
Signed-off-by: Baoquan He
---
drivers/iommu
On Mon, 2017-04-03 at 09:51:44 UTC, Alistair Popple wrote:
> Nvlink2 supports address translation services (ATS) allowing devices
> to request address translations from an mmu known as the nest MMU
> which is setup to walk the CPU page tables.
>
> To access this functionality c
Nvlink2 supports address translation services (ATS) allowing devices
to request address translations from an mmu known as the nest MMU
which is setup to walk the CPU page tables.
To access this functionality certain firmware calls are required to
setup and manage hardware context tables in the
Hi Alistair,
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.11-rc3 next-20170324]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Alistair-Popple/drivers-of-base-c-Add-of_pr
Alistair Popple writes:
> diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
> index 6095575..fc61fca 100644
> --- a/arch/powerpc/include/asm/tlb.h
> +++ b/arch/powerpc/include/asm/tlb.h
> @@ -63,15 +63,21 @@ static inline void
> tlb_remove_check_page_size_change(struct
Nvlink2 supports address translation services (ATS) allowing devices
to request address translations from an mmu known as the nest MMU
which is setup to walk the CPU page tables.
To access this functionality certain firmware calls are required to
setup and manage hardware context tables in the
physical address translation for AMD Fam17h
The Unified Memory Controllers (UMCs) on Fam17h log a normalized address
in their MCA_ADDR registers. We need to convert that normalized address
to a system physical address in order to support a few facilities:
1) To offline poisoned pages in DRAM
6 17:57:27 -0500
Subject: [PATCH] x86/mce/AMD: Add system physical address translation for AMD
Fam17h
The Unified Memory Controllers (UMCs) on Fam17h log a normalized address
in their MCA_ADDR registers. We need to convert that normalized address
to a system phyisical address in order to suppor
ommitDate: Mon, 21 Nov 2016 10:00:22 +0100
>
> x86/mce/AMD: Add system physical address translation for AMD Fam17h
So this commit is still sick with the attached config:
arch/x86/built-in.o: In function `umc_normaddr_to_sysaddr':
(.text+0x65238): undefined reference to `amd_df_in
physical address translation for AMD Fam17h
The Unified Memory Controllers (UMCs) on Fam17h log a normalized address
in their MCA_ADDR registers. We need to convert that normalized address
to a system phyisical address in order to support a few facilities:
1) To offline poisoned pages in DRAM
system physical address translation for AMD Fam17h
The Unified Memory Controllers (UMCs) on Fam17h log a normalized address
in their MCA_ADDR registers. We need to convert that normalized address
to a system phyisical address in order to support a few facilities:
1) To offline poisoned pages in DRAM
system physical address translation for AMD Fam17h
The Unified Memory Controllers (UMCs) on Fam17h log a normalized address
in their MCA_ADDR registers. We need to convert that normalized address
to a system phyisical address in order to support a few facilities:
1) To offline poisoned pages in DRAM
4.7-stable review patch. If anyone has any objections, please let me know.
--
From: Alexandre Bounine
commit b30069291dc7f9b9a073c33d619818fe4a8e50de upstream.
Fix incorrect condition to identify involvment of a address translation
mechanism.
This bug results in NULL pointer
On Tue, Sep 6, 2016 at 9:49 AM, Dan Williams wrote:
> In pgoff_to_phys() 'pgoff' is already relative to base of the dax
> device, so we only need to compare if the current offset is within the
> current resource extent. Otherwise, we are double accounting the
> resource start offset when translat
In pgoff_to_phys() 'pgoff' is already relative to base of the dax
device, so we only need to compare if the current offset is within the
current resource extent. Otherwise, we are double accounting the
resource start offset when translating pgoff to a physical address.
Cc:
Signed-off-by: Dan Wil
Fix incorrect condition to identify involvment of a address translation
mechanism.
This bug results in NULL pointer kernel crash dump in cases when mapping
of inbound RapidIO address range is requested within existing aprture.
This patch is applicable to kernel versions >= v4.6.
Signed-off
4.7-stable review patch. If anyone has any objections, please let me know.
--
From: Vladimir Kondratiev
commit b4dff2874006e54b60ce4f4dbcfec9ab81c6aff4 upstream.
page should be calculated using physical address.
If platform uses non-trivial dma-to-phys memory translation,
dma_
Obsolete GRU MMR address translation
Use no-op messages in place of cross-partition interrupts when nacking a
put message in the GRU. This allows us to remove MMR's as a destination
from the GRU driver.
Tested-by: John Estabrook
Tested-by: Gary Kroening
Tested-by: Nathan Zimmer
Signed-o
From: Dimitri Sivanich
Use no-op messages in place of cross-partition interrupts when nacking a
put message in the GRU. This allows us to remove MMR's as a destination
from the GRU driver.
Signed-off-by: Dimitri Sivanich
Signed-off-by: Mike Travis
Tested-by: John Estabrook
Tested-by: Gary Kr
From: Dimitri Sivanich
Use no-op messages in place of cross-partition interrupts when nacking a
put message in the GRU. This allows us to remove MMR's as a destination
from the GRU driver.
Signed-off-by: Dimitri Sivanich
Signed-off-by: Mike Travis
Tested-by: John Estabrook
Tested-by: Gary Kr
From: Dimitri Sivanich
Use no-op messages in place of cross-partition interrupts when nacking a
put message in the GRU. This allows us to remove MMR's as a destination
from the GRU driver.
Signed-off-by: Dimitri Sivanich
Signed-off-by: Mike Travis
Tested-by: John Estabrook
Tested-by: Gary Kr
* Mike Travis wrote:
> /*
> + * Send a noop message in order to deliver a cross-partition interrupt
> + * to the SSI that contains the target message queue. Normally, the
> + * interrupt is automatically delivered by hardware following mesq
> + * operations, but some er
From: Dimitri Sivanich
Use no-op messages in place of cross-partition interrupts when nacking a
put message in the GRU. This allows us to remove MMR's as a destination
from the GRU driver.
Signed-off-by: Dimitri Sivanich
Signed-off-by: Mike Travis
Tested-by: John Estabrook
Tested-by: Gary Kr
* Kishon Vijay Abraham I [150904 05:12]:
> "ARM: dts: : add minimal l4 bus
> layout with control module support" moved pbias_regulator dt node
> from being a child node of ocp to be the child node of
> 'syscon'. Since 'syscon' doesn't have the '
"ARM: dts: : add minimal l4 bus
layout with control module support" moved pbias_regulator dt node
from being a child node of ocp to be the child node of
'syscon'. Since 'syscon' doesn't have the 'ranges' property,
address translation fails while tryi
esults in platform_get_resource returning
>> -EINVAL in pbias driver. This is because address translation fails
>> while trying to convert the address to resource which happens
>> during the device creation process during boot up.
>>
>> Even though after [1], reg property in
* Kishon Vijay Abraham I [150903 04:31]:
> pbias device stopped having memory resource after
> "ARM: dts: : add minimal l4 bus layout with control module
> support" got merged. This results in platform_get_resource returning
> -EINVAL in pbias driver. This is because add
pbias device stopped having memory resource after
"ARM: dts: : add minimal l4 bus layout with control module
support" got merged. This results in platform_get_resource returning
-EINVAL in pbias driver. This is because address translation fails
while trying to convert the address to reso
commit ("ARM: dts: dra7: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
scm_conf. Since scm_conf doesn't have the 'ranges'
property, address translation fails while trying
commit <72b10ac00eb1> ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
scm_conf. Since scm_conf doesn't have the 'ranges' property,
address translatio
commit <7415b0b4c645> ("ARM: dts: omap4: add minimal l4 bus layout
with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
omap4_padconf_global. Since omap4_padconf_global doesn't have the
'ranges' property,
commit ("ARM: dts: omap5: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
omap5_padconf_global. Since omap5_padconf_global doesn't have the
'ranges' property, address translat
the
core.
A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
different needs of the remoteproc
>> core/drivers (eg: loading). The functionality is achieved within the
>> remoteproc core, and is limited only for carveouts allocated within the
>> core.
>>
>> A new rproc ops, da_to_va, is added to provide flexibility to platform
>&g
achieved within the
> remoteproc core, and is limited only for carveouts allocated within the
> core.
>
> A new rproc ops, da_to_va, is added to provide flexibility to platform
> implementations to perform the address translation themselves when the
> above conditions cannot b
Cleanup the early DT/earlycon separation; remove the 'addr' parameter
from of_setup_earlycon() and get the uart phys addr directly with a
new wrapper function, of_flat_dt_translate_addr(). Limit
fdt_translate_address() to file scope.
Signed-off-by: Peter Hurley
---
drivers/of/fdt.c
the
core.
A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
Cleanup the early DT/earlycon separation; remove the 'addr' parameter
from of_setup_earlycon() and get the uart phys addr directly with a
new wrapper function, of_flat_dt_translate_addr(). Limit
fdt_translate_address() to file scope.
Signed-off-by: Peter Hurley
---
drivers/of/fdt.c
On Wed, Mar 4, 2015 at 11:24 AM, Peter Hurley wrote:
> Cleanup the early DT/earlycon separation; remove the 'addr' parameter
> from of_setup_earlycon() and get the uart phys addr directly with a
> new wrapper function, of_flat_dt_translate_addr(). Limit
> fdt_translate_address() to file scope.
>
>
the
core.
A new rproc ops, da_to_va, is added to provide flexibility to platform
implementations to perform the address translation themselves when the
above conditions cannot be met by the implementations. The rproc_da_to_va()
API is extended to invoke this ops if present, and fallback to regular
Cleanup the early DT/earlycon separation; remove the 'addr' parameter
from of_setup_earlycon() and get the uart phys addr directly with a
new wrapper function, of_flat_dt_translate_addr(). Limit
fdt_translate_address() to file scope.
Signed-off-by: Peter Hurley
---
drivers/of/fdt.c
From: Rob Herring
Copy u-boot's FDT address translation code from common/fdt_support. This
code was originally based on the kernel's unflattened DT address parsing
code.
This commit can be reverted once relicensing of this code to GPLv2/BSD
is done and it is added to libfdt.
Signed-o
oid *)__bus_to_virt((unsigned long)addr);
>
Thanks a lot Russell. Updated patch below for archive records.
>From 97a6f063270265d03ffcb010b9dc156b274631e7 Mon Sep 17 00:00:00 2001
From: Grygorii Strashko
Date: Thu, 24 Apr 2014 11:30:05 -0400
Subject: [PATCH v3 5/7] ARM: dma: Use dma_
On Fri, May 02, 2014 at 11:05:16AM -0400, Santosh Shilimkar wrote:
> On Friday 02 May 2014 10:58 AM, Russell King - ARM Linux wrote:
> > On Thu, Apr 24, 2014 at 11:30:05AM -0400, Santosh Shilimkar wrote:
> >> static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> >> {
> >> - retu
1 - 100 of 175 matches
Mail list logo
