Le 30/06/2020 à 23:18, Segher Boessenkool a écrit :
Hi again,
Thanks for your work so far!
On Tue, Jun 30, 2020 at 06:53:39PM +, Christophe Leroy wrote:
On 06/30/2020 04:33 PM, Segher Boessenkool wrote:
+ make -s CC=powerpc64-linux-gnu-gcc -j 160
In file included from /linux/include/li
This patch series enables the usage os new pmem flush and sync instructions on
POWER
architecture. POWER10 introduces two new variants of dcbf instructions (dcbstps
and dcbfps)
that can be used to write modified locations back to persistent storage.
Additionally,
POWER10 also introduce phwsync a
The PAPR based virtualized persistent memory devices are only supported on
POWER9 and above. In the followup patch, the kernel will switch the persistent
memory cache flush functions to use a new `dcbf` variant instruction. The new
instructions even though added in ISA 3.1 works even on P8 and P9 b
POWER10 introduces two new variants of dcbf instructions (dcbstps and dcbfps)
that can be used to write modified locations back to persistent storage.
Additionally, POWER10 also introduce phwsync and plwsync which can be used
to establish order of these writes to persistent storage.
This patch ex
Start using dcbstps; phwsync; sequence for flushing persistent memory range.
The new instructions are implemented as a variant of dcbf and hwsync and on
P8 and P9 they will be executed as those instructions. We avoid using them on
older hardware. This helps to avoid difficult to debug bugs.
Signed
Architectures like ppc64 provide persistent memory specific barriers
that will ensure that all stores for which the modifications are
written to persistent storage by preceding dcbfps and dcbstps
instructions have updated persistent storage before any data
access or data transfer caused by subseque
With kernel now supporting new pmem flush/sync instructions, we can now
enable the kernel to initialize the device. On P10 these devices would
appear with a new compatible string. For PAPR device we have
compatible "ibm,pmemory-v2"
and for OF pmem device we have
compatible "pmem-regi
pmem on POWER10 can now use phwsync instead of hwsync to ensure
all previous writes are architecturally visible for the platform
buffer flush.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/barrier.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/in
> static void *__vmalloc_node(unsigned long size, unsigned long align,
> - gfp_t gfp_mask, pgprot_t prot,
> - int node, const void *caller);
> + gfp_t gfp_mask, pgprot_t prot, unsigned long vm_flags,
> + int no
On Tue, Jun 30, 2020 at 09:56:07PM +0800, Shengjiu Wang wrote:
> The ASRC not only supports ideal ratio mode, but also supports
> internal ratio mode.
>
> For internal rato mode, the rate of clock source should be divided
> with no remainder by sample rate, otherwise there is sound
> distortion.
>
nvdimm expect the flush routines to just mark the cache clean. The barrier
that mark the store globally visible is done in nvdimm_flush().
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/lib/pmem.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/l
Hi Hari,
On 06/27/20 at 12:35am, Hari Bathini wrote:
> crashkernel region could have an overlap with special memory regions
> like opal, rtas, tce-table & such. These regions are referred to as
> exclude memory ranges. Setup this ranges during image probe in order
> to avoid them while finding the
On 06/29/20 at 05:26pm, Hari Bathini wrote:
> Hi Petr,
>
> On 29/06/20 5:09 pm, Petr Tesarik wrote:
> > Hi Hari,
> >
> > is there any good reason to add two more functions with a very similar
> > name to an existing function? AFAICS all you need is a way to call a
> > PPC64-specific function from
On 27/06/2020 03:46, Leonardo Bras wrote:
> On Wed, 2020-06-24 at 03:24 -0300, Leonardo Bras wrote:
>> As of today, enable_ddw() will return a non-null DMA address if the
>> created DDW maps the whole partition. If the address is valid,
>> iommu_bypass_supported_pSeriesLP() will consider iommu b
randconfig-a006-20200630
i386 randconfig-a002-20200701
i386 randconfig-a001-20200701
i386 randconfig-a006-20200701
i386 randconfig-a005-20200701
i386 randconfig-a004-20200701
i386
On 24/06/2020 16:24, Leonardo Bras wrote:
> As of today, if a DDW is created and can't map the whole partition, it's
> removed and the default DMA window "ibm,dma-window" is used instead.
>
> Usually this DDW is bigger than the default DMA window, so it would be
> better to make use of it inste
On 24/06/2020 16:24, Leonardo Bras wrote:
> Create defines to help handling ibm,ddw-applicable values, avoiding
> confusion about the index of given operations.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 40 +++---
> 1 file changed, 2
On 24/06/2020 16:24, Leonardo Bras wrote:
> From LoPAR level 2.8, "ibm,ddw-extensions" index 3 can make the number of
> outputs from "ibm,query-pe-dma-windows" go from 5 to 6.
>
> This change of output size is meant to expand the address size of
> largest_available_block PE TCE from 32-bit to 6
On 24/06/2020 16:24, Leonardo Bras wrote:
> On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
> default DMA window for the device, before attempting to configure a DDW,
> in order to make the maximum resources available for the next DDW to be
> created.
>
> This is a requ
Function headers will need a lot of work before they reach the
standards expected of kerneldoc. Demote them down to basic
comments/headers, for now at least.
Fixes the following W=1 kernel build warnings:
drivers/misc/cxl/hcalls.c:175: warning: Function parameter or member
'unit_address' not d
A nice attempt was made to provide kerneldoc headers for
read_template_version() and read_afu_lpc_memory_info() however,
the provided formatting does not match what is expected by
kerneldoc.
Fixes the following W=1 warnings:
drivers/misc/ocxl/config.c:286: warning: Function parameter or member '
The DRC index pointer us updated on an OPCODE_ADD, but never
actually read. Remove the used pointer and shift up OPCODE_ADD
to group with OPCODE_DELETE which also provides a noop.
Fixes the following W=1 kernel build warning:
drivers/misc/cxl/flash.c: In function ‘update_devicetree’:
drivers/m
On Wed 24-06-20 14:58:46, Srikar Dronamraju wrote:
> Currently Linux kernel with CONFIG_NUMA on a system with multiple
> possible nodes, marks node 0 as online at boot. However in practice,
> there are systems which have node 0 as memoryless and cpuless.
>
> This can cause numa_balancing to be
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/block/zram/zram_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 6e2ad90b17a376
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/block/ps3vram.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index 821d4d8b1d763e..5a1d1d137c7248 1
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
---
arch/m68k/emu/nfblock.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/emu/nfblock.c b
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/block/null_blk_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
index 82259242b9b5c9..
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/block/umem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index 1e2aa5ae27963c..5498f1cf36b3fe 100644
-
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/block/rsxx/dev.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index 3ba07ab30c84f5..6a4d8d26e32
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/block/drbd/drbd_main.c | 1 -
drivers/block/drbd/drbd_req.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/bl
Hi Jens,
this series moves the make_request_fn method into block_device_operations
with the much more descriptive ->submit_bio name. It then also gives
generic_make_request a more descriptive name, and further optimize the
path to issue to blk-mq, removing the need for the direct_make_request
byp
Nothing in bcache actually uses the ->queuedata field.
Signed-off-by: Christoph Hellwig
---
drivers/md/bcache/super.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 2014016f9a60d3..21aa168113d30b 100644
--- a/drivers/md/bcache/super
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/platforms/iss/simdisk.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/xtensa/platforms/iss/simdisk.c
b/arch/xtensa/platforms/iss/simdisk.c
Instead of setting up the queuedata as well just use one private data
field.
Signed-off-by: Christoph Hellwig
---
drivers/md/dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index e44473fe0f4873..c8d91f271c272e 100644
--- a/drivers/md/d
All bios can get remapped if submitted to partitions. No need to
comment on that.
Signed-off-by: Christoph Hellwig
---
fs/buffer.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 64fe82ec65ff1f..2725ebbcfdc246 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@
The "generic_make_request: " prefix has no value, and will soon become
stale.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 76cfd5709f66cd..95dca74534ff73 100644
--- a/block/bl
All registers disks must have a valid queue pointer, so don't bother to
log a warning for that case.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 95dca74534ff73..37
The queue can be trivially derived from the bio, so pass one less
argument.
Signed-off-by: Christoph Hellwig
---
block/blk-merge.c | 21 ++---
block/blk-mq.c| 2 +-
block/blk.h | 3 +--
drivers/block/drbd/drbd_req.c | 2 +-
drivers
The variable is only used once, so just open code the bio_sector()
there.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 37435d0d433564..28f60985dc75cc 100644
--- a/block/blk-co
The make_request_fn is a little weird in that it sits directly in
struct request_queue instead of an operation vector. Replace it with
a block_device_operations method called submit_bio (which describes much
better what it does). Also remove the request_queue argument to it, as
the queue can be d
Split out a __submit_bio_noacct helper for the actual de-recursion
algorithm, and simplify the loop by using a continue when we can't
enter the queue for a bio.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 143 +--
1 file changed, 75 inserti
generic_make_request has always been very confusingly misnamed, so rename
it to submit_bio_noacct to make it clear that it is submit_bio minus
accounting and a few checks.
Signed-off-by: Christoph Hellwig
---
Documentation/block/biodoc.rst| 2 +-
.../fault-injection/fault-inject
For blk-mq drivers bios can only be inserted for the same queue. So
bypass the complicated sorting logic in __submit_bio_noacct with
a blk-mq simpler submission helper.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 30 ++
1 file changed, 30 insertions(+)
d
Now that submit_bio_noacct has a decent blk-mq fast path there is no
more need for this bypass.
Signed-off-by: Christoph Hellwig
---
block/blk-core.c | 28
drivers/md/dm.c | 5 +
drivers/nvme/host/multipath.c | 2 +-
include/linux/blk
The patch series adds support for power10 PMU hardware.
Anju T Sudhakar (2):
powerpc/perf: Add support for outputting extended regs in perf
intr_regs
tools/perf: Add perf tools support for extended register capability in
powerpc
Athira Rajeev (5):
KVM: PPC: Book3S HV: Save/restore n
From: Madhavan Srinivasan
PowerISA v3.1 includes new performance monitoring unit(PMU)
special purpose registers (SPRs). They are
Monitor Mode Control Register 3 (MMCR3)
Sampled Instruction Event Register 2 (SIER2)
Sampled Instruction Event Register 3 (SIER3)
MMCR3 is added for further sampling
PowerISA v3.1 has added new performance monitoring unit (PMU)
special purpose registers (SPRs). They are
Monitor Mode Control Register 3 (MMCR3)
Sampled Instruction Event Register A (SIER2)
Sampled Instruction Event Register B (SIER3)
Patch addes support to save/restore these new
SPRs while enter
From: Madhavan Srinivasan
PowerISA v3.1 added three new perfromance
monitoring unit (PMU) speical purpose register (SPR).
They are Monitor Mode Control Register 3 (MMCR3),
Sampled Instruction Event Register 2 (SIER2),
Sampled Instruction Event Register 3 (SIER3).
Patch here adds a new dump funct
From: Madhavan Srinivasan
Add power10 feature function to dt_cpu_ftrs.c along
with a power10 specific init() to initialize pmu sprs.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/include/asm/reg.h| 3 +++
arch/powerpc/kernel/cpu_setup_power.S | 7 +++
arch/powerpc/kernel/dt
Base enablement patch to register performance monitoring
hardware support for power10. Patch introduce the raw event
encoding format, defines the supported list of events, config
fields for the event attributes and their corresponding bit values
which are exported via sysfs.
Patch also enhances th
Events of type PERF_TYPE_HW_CACHE was described for Power PMU
as: int (*cache_events)[type][op][result];
where type, op, result values unpacked from the event attribute config
value is used to generate the raw event code at runtime.
So far the event code values which used to create these cache-re
PowerISA v3.1 has few updates for the Branch History Rolling Buffer(BHRB).
First is the addition of BHRB disable bit and second new filtering
modes for BHRB.
BHRB disable is controlled via Monitor Mode Control Register A (MMCRA)
bit 26, namely "BHRB Recording Disable (BHRBRD)". This field controls
From: Anju T Sudhakar
Add support for perf extended register capability in powerpc.
The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to indicate the
PMU which support extended registers. The generic code define the mask
of extended registers as 0 for non supported architectures.
Patch add
From: Anju T Sudhakar
Add extended regs to sample_reg_mask in the tool side to use
with `-I?` option. Perf tools side uses extended mask to display
the platform supported register names (with -I? option) to the user
and also send this mask to the kernel to capture the extended registers
in each s
Include capability flag `PERF_PMU_CAP_EXTENDED_REGS` for power10
and expose MMCR3, SIER2, SIER3 registers as part of extended regs.
Also introduce `PERF_REG_PMU_MASK_31` to define extended mask
value at runtime for power10
Signed-off-by: Athira Rajeev
---
arch/powerpc/include/uapi/asm/perf_regs.
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: 3c0356e8994ed88e5234897c0ffee4188f8b9287 Automatic merge of
'master', 'next' and 'fixes' (2020-06-30 22:07)
elapsed time: 1282m
configs tested: 98
configs skipped: 1
The following configs have b
* Michal Hocko [2020-07-01 10:42:00]:
>
> >
> > 2. Also existence of dummy node also leads to inconsistent information. The
> > number of online nodes is inconsistent with the information in the
> > device-tree and resource-dump
> >
> > 3. When the dummy node is present, single node non-Numa s
On 01.07.20 12:04, Srikar Dronamraju wrote:
> * Michal Hocko [2020-07-01 10:42:00]:
>
>>
>>>
>>> 2. Also existence of dummy node also leads to inconsistent information. The
>>> number of online nodes is inconsistent with the information in the
>>> device-tree and resource-dump
>>>
>>> 3. When the
* David Hildenbrand [2020-07-01 12:15:54]:
> On 01.07.20 12:04, Srikar Dronamraju wrote:
> > * Michal Hocko [2020-07-01 10:42:00]:
> >
> >>
> >>>
> >>> 2. Also existence of dummy node also leads to inconsistent information.
> >>> The
> >>> number of online nodes is inconsistent with the inform
On 01.07.20 13:01, Srikar Dronamraju wrote:
> * David Hildenbrand [2020-07-01 12:15:54]:
>
>> On 01.07.20 12:04, Srikar Dronamraju wrote:
>>> * Michal Hocko [2020-07-01 10:42:00]:
>>>
>
> 2. Also existence of dummy node also leads to inconsistent information.
> The
> number
On Wed, Jul 01, 2020 at 05:20:54AM -0400, Athira Rajeev wrote:
> PowerISA v3.1 has added new performance monitoring unit (PMU)
> special purpose registers (SPRs). They are
>
> Monitor Mode Control Register 3 (MMCR3)
> Sampled Instruction Event Register A (SIER2)
> Sampled Instruction Event Registe
On 01.07.20 13:06, David Hildenbrand wrote:
> On 01.07.20 13:01, Srikar Dronamraju wrote:
>> * David Hildenbrand [2020-07-01 12:15:54]:
>>
>>> On 01.07.20 12:04, Srikar Dronamraju wrote:
* Michal Hocko [2020-07-01 10:42:00]:
>
>>
>> 2. Also existence of dummy node also leads
On Wed 01-07-20 13:30:57, David Hildenbrand wrote:
> On 01.07.20 13:06, David Hildenbrand wrote:
> > On 01.07.20 13:01, Srikar Dronamraju wrote:
> >> * David Hildenbrand [2020-07-01 12:15:54]:
> >>
> >>> On 01.07.20 12:04, Srikar Dronamraju wrote:
> * Michal Hocko [2020-07-01 10:42:00]:
> >>
On Tue 30-06-20 09:31:25, Srikar Dronamraju wrote:
> * Christopher Lameter [2020-06-29 14:58:40]:
>
> > On Wed, 24 Jun 2020, Srikar Dronamraju wrote:
> >
> > > Currently Linux kernel with CONFIG_NUMA on a system with multiple
> > > possible nodes, marks node 0 as online at boot. However in prac
On 07/01/2020 03:40 PM, Dave Young wrote:
> Hi Hari,
> On 06/27/20 at 12:35am, Hari Bathini wrote:
>> crashkernel region could have an overlap with special memory regions
>> like opal, rtas, tce-table & such. These regions are referred to as
>> exclude memory ranges. Setup this ranges during im
On Wed, Jul 01, 2020 at 09:31:18AM +0100, Lee Jones wrote:
> The DRC index pointer us updated on an OPCODE_ADD, but never
> actually read. Remove the used pointer and shift up OPCODE_ADD
> to group with OPCODE_DELETE which also provides a noop.
>
> Fixes the following W=1 kernel build warning:
>
On Wed, 2020-07-01 at 18:16 +1000, Alexey Kardashevskiy wrote:
>
> On 24/06/2020 16:24, Leonardo Bras wrote:
> > Create defines to help handling ibm,ddw-applicable values, avoiding
> > confusion about the index of given operations.
> >
> > Signed-off-by: Leonardo Bras
> > ---
> > arch/powerpc/p
On Wed, 01 Jul 2020, Greg KH wrote:
> On Wed, Jul 01, 2020 at 09:31:18AM +0100, Lee Jones wrote:
> > The DRC index pointer us updated on an OPCODE_ADD, but never
> > actually read. Remove the used pointer and shift up OPCODE_ADD
> > to group with OPCODE_DELETE which also provides a noop.
> >
> >
Changes since v1 [1]:
* Minor restructuring of code as suggested by Ira
* Renaming of few members of 'struct par_scm_perf_[stat|stats]'
* Fixed a bug where a NULL pointer was potentially passed to
virt_to_phys().
* Using Big endian type rather than cpu native type so receive data
from PHYP in 'str
Update papr_scm.c to query dimm performance statistics from PHYP via
H_SCM_PERFORMANCE_STATS hcall and export them to user-space as PAPR
specific NVDIMM attribute 'perf_stats' in sysfs. The patch also
provide a sysfs ABI documentation for the stats being reported and
their meanings.
During NVDIMM
We add support for reporting 'fuel-gauge' NVDIMM metric via
PAPR_PDSM_HEALTH pdsm payload. 'fuel-gauge' metric indicates the usage
life remaining of a papr-scm compatible NVDIMM. PHYP exposes this
metric via the H_SCM_PERFORMANCE_STATS.
The metric value is returned from the pdsm by extending the r
On 7/1/20 2:59 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series moves the make_request_fn method into block_device_operations
> with the much more descriptive ->submit_bio name. It then also gives
> generic_make_request a more descriptive name, and further optimize the
> path to issue to b
On Wed, 2020-07-01 at 18:17 +1000, Alexey Kardashevskiy wrote:
>
> > +#define DDW_EXT_SIZE 0
> > +#define DDW_EXT_RESET_DMA_WIN 1
> > +#define DDW_EXT_QUERY_OUT_SIZE 2
>
> #define DDW_EXT_LAST (DDW_EXT_QUERY_OUT_SIZE + 1)
> ...
>
>
> > +
> > static struct iommu_table_gro
On Wed, Jul 1, 2020 at 2:01 AM Christoph Hellwig wrote:
>
> The make_request_fn is a little weird in that it sits directly in
> struct request_queue instead of an operation vector. Replace it with
> a block_device_operations method called submit_bio (which describes much
> better what it does).
On 01/07/20 1:10 pm, Dave Young wrote:
> Hi Hari,
> On 06/27/20 at 12:35am, Hari Bathini wrote:
>> crashkernel region could have an overlap with special memory regions
>> like opal, rtas, tce-table & such. These regions are referred to as
>> exclude memory ranges. Setup this ranges during image
On Wed, Jul 01 2020 at 4:59am -0400,
Christoph Hellwig wrote:
> Instead of setting up the queuedata as well just use one private data
> field.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
On 01/07/20 1:16 pm, Dave Young wrote:
> On 06/29/20 at 05:26pm, Hari Bathini wrote:
>> Hi Petr,
>>
>> On 29/06/20 5:09 pm, Petr Tesarik wrote:
>>> Hi Hari,
>>>
>>> is there any good reason to add two more functions with a very similar
>>> name to an existing function? AFAICS all you need is a w
I cannot figure out how the xxxK reserved item works in:
Memory: 880608K/983040K available (9532K kernel code, 1104K rwdata, 3348K
rodata, 1088K init, 1201K bss, 36896K reserved ...
Is there a way to tune(lower it) this memory?
Jocke
On Wed, 2020-07-01 at 18:17 +1000, Alexey Kardashevskiy wrote:
>
> On 24/06/2020 16:24, Leonardo Bras wrote:
> > On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
> > default DMA window for the device, before attempting to configure a DDW,
> > in order to make the maximum re
On Wed, 2020-07-01 at 18:16 +1000, Alexey Kardashevskiy wrote:
>
> On 24/06/2020 16:24, Leonardo Bras wrote:
> > As of today, if a DDW is created and can't map the whole partition, it's
> > removed and the default DMA window "ibm,dma-window" is used instead.
> >
> > Usually this DDW is bigger tha
On Wed, 2020-07-01 at 18:04 +1000, Alexey Kardashevskiy wrote:
>
> On 27/06/2020 03:46, Leonardo Bras wrote:
> > On Wed, 2020-06-24 at 03:24 -0300, Leonardo Bras wrote:
> > > As of today, enable_ddw() will return a non-null DMA address if the
> > > created DDW maps the whole partition. If the addr
On Tue, 30 Jun 2020 21:56:07 +0800, Shengjiu Wang wrote:
> The ASRC not only supports ideal ratio mode, but also supports
> internal ratio mode.
>
> For internal rato mode, the rate of clock source should be divided
> with no remainder by sample rate, otherwise there is sound
> distortion.
>
> [.
On Mon, 29 Jun 2020 14:42:33 +0800, Shengjiu Wang wrote:
> When there is dedicated power domain bound with device, after probing
> the power will be disabled, then registers are not accessible in
> fsl_sai_dai_probe(), so regcache only need to be enabled in end of
> probe() and regcache_mark_dirty
On Wed, 2020-07-01 at 16:57 -0300, Leonardo Bras wrote:
> > It is not necessarily "direct" anymore as the name suggests, you may
> > want to change that. DMA64_PROPNAME, may be. Thanks,
> >
>
> Yeah, you are right.
> I will change this for next version, also changing the string name to
> reflect
On 02/07/2020 00:04, Leonardo Bras wrote:
> On Wed, 2020-07-01 at 18:17 +1000, Alexey Kardashevskiy wrote:
>>
>>> +#define DDW_EXT_SIZE 0
>>> +#define DDW_EXT_RESET_DMA_WIN 1
>>> +#define DDW_EXT_QUERY_OUT_SIZE 2
>>
>> #define DDW_EXT_LAST (DDW_EXT_QUERY_OUT_SIZE + 1)
>> .
On 01/07/2020 23:28, Leonardo Bras wrote:
> On Wed, 2020-07-01 at 18:16 +1000, Alexey Kardashevskiy wrote:
>>
>> On 24/06/2020 16:24, Leonardo Bras wrote:
>>> Create defines to help handling ibm,ddw-applicable values, avoiding
>>> confusion about the index of given operations.
>>>
>>> Signed-off
On 02/07/2020 05:48, Leonardo Bras wrote:
> On Wed, 2020-07-01 at 18:17 +1000, Alexey Kardashevskiy wrote:
>>
>> On 24/06/2020 16:24, Leonardo Bras wrote:
>>> On LoPAR "DMA Window Manipulation Calls", it's recommended to remove the
>>> default DMA window for the device, before attempting to conf
On Thu, 2020-07-02 at 10:18 +1000, Alexey Kardashevskiy wrote:
>
> On 02/07/2020 00:04, Leonardo Bras wrote:
> > On Wed, 2020-07-01 at 18:17 +1000, Alexey Kardashevskiy wrote:
> > > > +#define DDW_EXT_SIZE 0
> > > > +#define DDW_EXT_RESET_DMA_WIN 1
> > > > +#define DDW_EXT_QUERY_OUT_SIZ
On 02/07/2020 09:48, Leonardo Bras wrote:
> On Wed, 2020-07-01 at 16:57 -0300, Leonardo Bras wrote:
>>> It is not necessarily "direct" anymore as the name suggests, you may
>>> want to change that. DMA64_PROPNAME, may be. Thanks,
>>>
>>
>> Yeah, you are right.
>> I will change this for next vers
On Thu, 2020-07-02 at 10:21 +1000, Alexey Kardashevskiy wrote:
> > enum {
> >DDW_QUERY_PE_DMA_WIN,
> >DDW_CREATE_PE_DMA_WIN,
> >DDW_REMOVE_PE_DMA_WIN,
> >
> >DDW_APPLICABLE_SIZE
> > }
> > IMO, it looks better than all the defines before.
> >
> > What do you think?
On 02/07/2020 10:36, Leonardo Bras wrote:
> On Thu, 2020-07-02 at 10:21 +1000, Alexey Kardashevskiy wrote:
>>> enum {
>>>DDW_QUERY_PE_DMA_WIN,
>>>DDW_CREATE_PE_DMA_WIN,
>>>DDW_REMOVE_PE_DMA_WIN,
>>>
>>>DDW_APPLICABLE_SIZE
>>> }
>>> IMO, it looks better than all th
On Thu, 2020-07-02 at 10:43 +1000, Alexey Kardashevskiy wrote:
> > Or should one stick to #define in this case?
>
> imho a matter of taste but after some grepping it feels like #define is
> mostly used which does not mean it is a good idea. Keep it enum and see
> if it passed mpe's filter :)
Good
Joakim Tjernlund writes:
> I cannot figure out how the xxxK reserved item works in:
> Memory: 880608K/983040K available (9532K kernel code, 1104K rwdata, 3348K
> rodata, 1088K init, 1201K bss, 36896K reserved ...
It's calculated as:
(physpages - totalram_pages() - totalcma_pages)
The
On Thu, 2020-07-02 at 10:31 +1000, Alexey Kardashevskiy wrote:
> > In fact, there is a lot of places in this file where it's called direct
> > window. Should I replace everything?
> > Should it be in a separated patch?
>
> If it looks simple and you write a nice commit log explaining all that
> an
From: Dany Madden
[ Upstream commit 8b40eb73509f5704a0e8cd25de0163876299f1a7 ]
Continue the reset path when partner adapter is not ready or H_CLOSED is
returned from reset crq. This patch allows the CRQ init to proceed to
establish a valid CRQ for traffic to flow after reset.
Signed-off-by: Dan
From: "Aneesh Kumar K.V"
[ Upstream commit c1ed1754f271f6b7acb1bfdc8cfb62220fbed423 ]
With CONFIG_DEBUG_VIRTUAL=y, __pa() checks for addr value and if it's
less than PAGE_OFFSET it leads to a BUG().
#define __pa(x)
({
VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);
(unsign
From: Dany Madden
[ Upstream commit 8b40eb73509f5704a0e8cd25de0163876299f1a7 ]
Continue the reset path when partner adapter is not ready or H_CLOSED is
returned from reset crq. This patch allows the CRQ init to proceed to
establish a valid CRQ for traffic to flow after reset.
Signed-off-by: Dan
From: "Aneesh Kumar K.V"
[ Upstream commit c1ed1754f271f6b7acb1bfdc8cfb62220fbed423 ]
With CONFIG_DEBUG_VIRTUAL=y, __pa() checks for addr value and if it's
less than PAGE_OFFSET it leads to a BUG().
#define __pa(x)
({
VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET);
(unsign
powerpc has a variable number of PTRS_PER_*, set at runtime based
on the MMU that the kernel is booted under.
This means the PTRS_PER_* are no longer constants, and therefore
breaks the build.
Define default MAX_PTRS_PER_*s in the same style as MAX_PTRS_PER_P4D.
As KASAN is the only user at the m
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
This provides full inline instrumentation on radix, but does require
that you be able to specify the amount of physically contiguous memory
on the system at compile time. Mor
1 - 100 of 107 matches
Mail list logo
