| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The hardware can combine H&V syncs onto the output enable line
as composite syncs, so add the relevant configuration to do that.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-9-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
|
This allows easy analysis of display lists when debugging.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-8-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
|
Move from only supporting the default of pre-multiplied
alpha to supporting user specified blend mode using the
standardised property.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-7-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
|
The current plane margin calculation code clips the right and bottom
edges of the range based using the left and top margins.
This is obviously wrong, so let's fix it.
Fixes: 666e73587f90 ("drm/vc4: Take margin setup into account when updating planes")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-6-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
|
There is little harm in ignoring fractional coordinates
(they just get truncated).
Without this:
modetest -M vc4 -F tiles,gradient -s 32:1920x1080-60 -P89@74:1920x1080*.1.1@XR24
is rejected. We have the same issue in Kodi when trying to
use zoom options on video.
Note: even if all coordinates are fully integer. e.g.
src:[0,0,1920,1080] dest:[-10,-10,1940,1100]
it will still get rejected as drm_atomic_helper_check_plane_state
uses drm_rect_clip_scaled which transforms this to fractional src coords
Fixes: 21af94cf1a4c ("drm/vc4: Add support for scaling of display planes.")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-5-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
|
The core clock computation takes into account both the load due to the
input (ie, planes) and its output (ie, encoders).
However, while the input load needs to consider all the planes, and thus
sum all of their associated loads, the output happens mostly in
parallel.
Therefore, we need to consider only the maximum of all the output loads,
and not the sum like we were doing. This resulted in a clock rate way
too high which could be discarded for being too high by the clock
framework.
Since recent changes, the clock framework will even downright reject it,
leading to a core clock being too low for its current needs.
Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-4-maxime@cerno.tech
|
|
We currently ignore the clk_set_min_rate return code assuming it would
succeed. However, it can fail if we ask for a rate higher than the
current maximum for example.
Since we can't fail in atomic_commit, at least warn on failure.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-3-maxime@cerno.tech
|
|
vc4_drv isn't necessarily under the /soc node in DT as it is a
virtual device, but it is the one that does the allocations.
The DMA addresses are consumed by primarily the HVS or V3D, and
those require VideoCore cache alias address mapping, and so will be
under /soc.
During probe find the a suitable device node for HVS or V3D,
and adopt the DMA configuration of that node.
Cc: <stable@vger.kernel.org>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-2-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
|
blk_cleanup_disk is nothing but a trivial wrapper for put_disk now,
so remove it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20220619060552.1850436-7-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Ido Schimmel says:
====================
mlxsw: Unified bridge conversion - part 4/6
This is the fourth part of the conversion of mlxsw to the unified bridge
model.
Unlike previous parts that prepared mlxsw for the conversion, this part
actually starts the conversion. It focuses on flooding configuration and
converts mlxsw to the more "raw" APIs of the unified bridge model.
The patches configure the different stages of the flooding pipeline in
Spectrum that looks as follows (at a high-level):
+------------+ +----------+ +-------+
{FID, | | {Packet type, | | | | MID
DMAC} | FDB lookup | Bridge type} | SFGC | MID base | | Index
+--------> (miss) +----------------> register +-----------> Adder +------->
| | | | | |
| | | | | |
+------------+ +----+-----+ +---^---+
| |
Table | |
type | | Offset
| +-------+ |
| | | |
| | | |
+----->+ Mux +------+
| |
| |
+-^---^-+
| |
FID| |FID
| |offset
+ +
The multicast identifier (MID) index is used as an index to the port
group table (PGT) that contains a bitmap of ports via which a packet
needs to be replicated.
From the PGT table, the packet continues to the multicast port egress
(MPE) table that determines the packet's egress VLAN. This is a
two-dimensional table that is indexed by port and switch multicast port
to egress (SMPE) index. The latter can be thought of as a FID. Without
it, all the packets replicated via a certain port would get the same
VLAN, regardless of the bridge domain (FID).
Logically, these two steps look as follows:
PGT table MPE table
+-----------------------+ +---------------+
| | {Local port, | | Egress
MID index | Local ports bitmap #1 | SMPE index} | | VID
+------------> ... +---------------> +-------->
| Local ports bitmap #N | | |
| | SMPE | |
+-----------------------+ +---------------+
Local port
Patchset overview:
Patch #1 adds a variable to guard against mixed model configuration.
Will be removed in part 6 when mlxsw is fully converted to the unified
model.
Patches #2-#5 introduce two new FID attributes required for flooding
configuration in the new model:
1. 'flood_rsp': Instructs the firmware to handle flooding configuration
for this FID. Only set for router FIDs (rFIDs) which are used to connect
a {Port, VLAN} to the router block.
2. 'bridge_type': Allows the device to determine the flood table (i.e.,
base index to the PGT table) for the FID. The first type will be used
for FIDs in a VLAN-aware bridge and the second for FIDs representing
VLAN-unaware bridges.
Patch #6 configures the MPE table that determines the egress VLAN of a
packet that is forwarded according to L2 multicast / flood.
Patches #7-#11 add the PGT table and related APIs to allocate entries
and set / clear ports in them.
Patches #12-#13 convert the flooding configuration to use the new PGT
APIs.
====================
Link: https://lore.kernel.org/r/20220627070621.648499-1-idosch@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The PGT (Port Group Table) table maps an index to a bitmap of local ports
to which a packet needs to be replicated. This table is used for layer 2
multicast and flooding.
In the legacy model, software did not interact with PGT table directly.
Instead, it was accessed by firmware in response to registers such as SFTR
and SMID. In the new model, the SFTR register is deprecated and software
has full control over the PGT table using the SMID register.
Use the new PGT APIs to allocate entries for flooding as part of flood
tables initialization. Add mlxsw_sp_fid_flood_tables_fini() to free the
allocated indexes. In addition, use PGT APIs to add/remove ports from PGT
table. The existing code which configures the flood entries via SFTR2 will
be removed later.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The PGT (Port Group Table) table maps an index to a bitmap of local ports
to which a packet needs to be replicated. This table is used for layer 2
multicast and flooding.
The index to PGT table which is called 'mid_index', is a result of
'mid_base' + 'fid_offset'. Using the legacy bridge model, firmware
configures 'mid_base'. However, using the new model, software is
responsible to configure it via SFGC register. The first 15K entries will
be used for flooding and the rest for multicast. The table will look as
follows:
+----------------------------+
| |
| 802.1q, unicast flooding | 4K entries
| |
+----------------------------+
| |
| 802.1q, multicast flooding | 4K entries
| |
+----------------------------+
| |
| 802.1q, broadcast flooding | 4K entries
| |
+----------------------------+
| 802.1d, unicast flooding | 1K entries
+----------------------------+
| 802.1d, multicast flooding | 1K entries
+----------------------------+
| 802.1d, broadcast flooding | 1K entries
+----------------------------+
| |
| |
| Multicast entries | The rest of the table
| |
| |
+----------------------------+
Add 'pgt_base' to 'struct mlxsw_sp_fid_family' and use it to calculate
MID base, set 'SFGC.mid_base' as part of flood tables initialization.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Initialize PGT table as part of mlxsw_sp_init(). This table will be used
first in the next patch by FID code to set flooding entries, and later by
MDB code to add multicast entries.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Add an API to associate a PGT entry with SMPE index and add or remove a
port. This API will be used by FID code and MDB code, to add/remove port
from specific PGT entry.
When the first port is added to PGT entry, allocate the entry in the given
MID index, when the last port is removed from PGT entry, free it.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Currently when bitmap of ports is needed, 'unsigned long *' type is
used. The functions which use the bitmap assume its length according to
its name, i.e., each function which gets a bitmap of ports queries the
maximum number of ports and uses it as the size.
As preparation for the next patch which will use bitmap of ports, add a
dedicated structure for it. Refactor the existing code to use the new
structure.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
In Spectrum-1, the index into the MPE table - called switch multicast to
port egress VID (SMPE) - is derived from the PGT entry, whereas in
Spectrum-2 and later ASICs it is derived from the FID.
Therefore, in Spectrum-1, the SMPE index needs to be programmed as part of
the PGT entry via SMID register, while it is reserved for Spectrum-2 and
later ASICs.
Add 'pgt_smpe_index_valid' boolean as part of 'struct mlxsw_sp' and set
it to true for Spectrum-1 and to false for the later ASICs. Add
'smpe_index_valid' as part of 'struct mlxsw_sp_pgt' and set it according
to the value in 'struct mlxsw_sp' as part of PGT initialization.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The PGT (Port Group Table) table maps an index to a bitmap of local ports
to which a packet needs to be replicated. This table is used for layer 2
multicast and flooding.
In the legacy model, software did not interact with this table directly.
Instead, it was accessed by firmware in response to registers such as
SFTR and SMID. In the new model, the SFTR register is deprecated and
software has full control over the PGT table using the SMID register.
The entire state of the PGT table needs to be maintained in software
because member ports in a PGT entry needs to be reference counted to avoid
releasing entries which are still in use.
Add the following APIs:
1. mlxsw_sp_pgt_{init, fini}() - allocate/free the PGT table.
2. mlxsw_sp_pgt_mid_alloc_range() - allocate a range of MID indexes in PGT.
To be used by FID code during initialization to reserve specific PGT
indexes for flooding entries.
3. mlxsw_sp_pgt_mid_free_range() - free indexes in a given range.
4. mlxsw_sp_pgt_mid_alloc() - allocate one MID index in the PGT at a
non-specific range, just search for free index. To be used by MDB code.
5. mlxsw_sp_pgt_mid_free() - free the given index.
Note that alloc() functions do not allocate the entries in software, just
allocate IDs using 'idr'.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The device includes two main tables to support layer 2 multicast (i.e.,
MDB and flooding). These are the PGT (Port Group Table) table and the MPE
(Multicast Port Egress) table.
- PGT is {MID -> (bitmap of local_port, SPME index)}
- MPE is {(Local port, SMPE index) -> eVID}
In the legacy model, software did not interact with MPE table as it was
completely hidden in firmware. In the new model, software needs to
populate the table itself in order to map from {Local port, SMPE} to an
egress VID. This is done using the SMPE register.
Configure SMPE register when a {Local port, VID} are mapped/unmapped to a
802.1d and 802.1q emulated FIDs. The MPE table is not relevant for rFIDs as
firmware handles their flooding.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
In the unified bridge model, the bridge type FID attribute is no longer
configured by the firmware, but instead by software when creating and
editing a FID via SFMR register.
Set this field as part of FID creation and edition flow. Default to 0
(reserved) as long as the driver operates in the legacy bridge model.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Currently, 'bridge_type' is an attribute of 'struct mlxsw_sp_flood_table',
which is defined per FID family. Instead, it can be an attribute of
'struct mlxsw_sp_fid_family' as all flood tables in the same family are of
the same type. This change will ease the configuration of
'SFMR.flood_bridge_type' which will be added in the next patch.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Under the legacy bridge model, the field 'bridge_type' is used only
in SFGC register, to determine the type of flood table (FID/FID offset).
Under the unified bridge model, it will be used also in SFMR register.
When a BUM packet needs to be flooded, SFGC is used to provide the
'mid_base' for PGT table. The access to SFGC is by
{packet type, bridge type}. Under the unified bridge model, software is
responsible for configuring 'bridge_type' as part of SFMR.
As preparation for the new required configuration, rename
'enum mlxsw_reg_sfgc_bridge_type' to 'enum mlxsw_reg_bridge_type'. Then
it can be used also in SFMR. In addition, align the names of the values to
internal documentation.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Using unified bridge model, RITR register no longer configures the rFID
used for sub-port RIFs. It needs to be created by software via SFMR. Such
FIDs need to be created with a special flood indication using
'SFMR.flood_rsp=1'. It means that for such FIDs, router sub-port flooding
table will be used, this table is configured by firmware.
Set the above mentioned field as part of FID initialization and FID
edition, so then when other fields will be updated in SFMR, this field
will store the correct value and will not be overwritten.
Add 'flood_rsp' variable to 'struct mlxsw_sp_fid_family', set it to true
for rFID and to false for the rest.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
As part of transition to unified bridge model, many different firmware
configurations are done.
Some of the configuration that needs to be done for the unified bridge
model is not valid under the legacy model, and would be rejected by the
firmware. At the same time, the driver cannot switch to the unified bridge
model until all of the code has been converted.
To allow breaking the change into patches, and to not break driver
behavior during the transition, add a boolean variable to indicate bridge
model. Then, forbidden configurations will be skipped using the check -
"if (!mlxsw_sp->ubridge)".
The new variable is temporary for several sets, it will be removed when
firmware will be configured to work with unified bridge model.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Set the queue dying flag and call blk_mq_exit_queue from del_gendisk for
all disks that do not have separately allocated queues, and thus remove
the need to call blk_cleanup_queue for them.
Rename blk_cleanup_disk to blk_mq_destroy_queue to make it clear that
this function is intended only for separately allocated blk-mq queues.
This saves an extra queue freeze for devices without a separately
allocated queue.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20220619060552.1850436-6-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
These flags only apply to file system I/O, and all file system I/O is
already drained by del_gendisk and thus can't be in progress when
blk_cleanup_queue is called.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20220619060552.1850436-5-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Disallow setting the blk-mq state on any queue that is already dying as
setting the state even then is a bad idea, and remove the now unused
QUEUE_FLAG_DEAD flag.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20220619060552.1850436-4-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Use the proper helper to mark a surpise removal, remove the gendisk as
soon as possible when removing the device and implement the ->free_disk
callback to ensure the private data is alive as long as the gendisk has
references.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20220619060552.1850436-3-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
This file is a huge mess that iterates over all devices and is in the
way of fixing the device removal in this driver, so remove it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20220619060552.1850436-2-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Delete the redundant word 'and'.
Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20220618130854.12321-1-wangxiang@cdjrlc.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The documented yaml compat string for the apq8016 is
"qcom,apq8016-lpass-cpu" not "qcom,lpass-cpu-apq8016". Looking at the other
lpass compat strings the general form is "qcom,socnum-lpass-cpu".
We need to fix both the driver and dts to match.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20220628120435.3044939-2-bryan.odonoghue@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
document n_ramp_values field at struct regulator_desc, in order
to solve this warning:
include/linux/regulator/driver.h:434: warning: Function parameter or member 'n_ramp_values' not described in 'regulator_desc'
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Link: https://lore.kernel.org/r/15efc16e878aa327aa2769023bcdf959a795f41d.1656409369.git.mchehab@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The driver expects the pitch of the Intel CCS CC color planes to be
64 bytes aligned, adjust the modifier descriptions accordingly.
Cc: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com
|
|
Update the driver to use an immutable IRQ chip to fix this warning:
"not an immutable chip, please consider fixing it!"
Preserve per-chip labels by adding an ->irq_print_chip() callback.
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Link: https://lore.kernel.org/r/20220622185010.2022515-3-aidanmacdonald.0x0@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Instead of accessing ->hwirq directly, use irqd_to_hwirq().
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Link: https://lore.kernel.org/r/20220622185010.2022515-2-aidanmacdonald.0x0@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now. This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
The only exceptions to this are a few network and scsi drivers for m68k
Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
with the old interfaces and are probably not worth changing.
On alpha and parisc, virt_to_bus() were still used in asm/floppy.h.
alpha can use isa_virt_to_bus() like x86 does, and parisc can just
open-code the virt_to_phys() here, as this is architecture specific
code.
I tried updating the bus-virt-phys-mapping.rst documentation, which
started as an email from Linus to explain some details of the Linux-2.0
driver interfaces. The bits about virt_to_bus() were declared obsolete
backin 2000, and the rest is not all that relevant any more, so in the
end I just decided to remove the file completely.
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Currently, extable type EX_TYPE_FIXUP is no place to use, We can safely
remove it.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20220621072638.1273594-7-tongtiangen@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Currently, We use _cond_extable for cache maintenance uaccess helper
caches_clean_inval_user_pou(), so this should be moved over to
EX_TYPE_UACCESS_ERR_ZERO and rename _cond_extable to _cond_uaccess_extable
for clarity.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20220621072638.1273594-6-tongtiangen@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Currnetly, the extable type used by __arch_copy_from/to_user() is
EX_TYPE_FIXUP. In fact, It is more clearly to use meaningful
EX_TYPE_UACCESS_*.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Link: https://lore.kernel.org/r/20220621072638.1273594-5-tongtiangen@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
In subsequent patches we want to explciitly annotate uaccess fixups in
assembly files.
We have existing helpers for this for inline assembly, but due to
differing stringification requirements it's not possible to have a
single definition that we can use for both inline asm and plain asm
files. So as with other cases (e.g. gpr-regnum.h), we must prove
separate helprs for plain asm and inline asm.
So that we can do so, this patch adds helpers to define
EX_TYPE_UACCESS_ERR_ZERO fixups in plain assembly. These correspond 1-1
with the inline assembly versions except for the absence of
stringification. No plain assmebly heleprs are added for
EX_TYPE_LOAD_UNALIGNED_ZEROPAD fixups as these only exist for a single C
function.
For copy_{to,from}_user() we'll need fixups with regs and err, so I've
added _ASM_EXTABLE_UACCESS(insn, fixup), where both the error and zero
registers are WZR.
For clarity, the existing `_asm_extable` assemgbly maco is now defined
in terms of the _ASM_EXTABLE() CPP macro, making the CPP macros
canonical in all cases.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Link: https://lore.kernel.org/r/20220621072638.1273594-4-tongtiangen@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
In subsequent patches we'll need to fill in extable data fields in
regular assembly files. In preparation for this, move the definitions of
the extable data fields earlier in asm-extable.h so that they are
defined for both assembly and C files.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Link: https://lore.kernel.org/r/20220621072638.1273594-3-tongtiangen@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Currently, The extable type EX_TYPE_UACCESS_ERR_ZERO is used by
__get/put_kernel_nofault(), but those helpers are not uaccess type, so we
add a new extable type EX_TYPE_KACCESS_ERR_ZERO which can be used by
__get/put_kernel_no_fault().
This is also to prepare for distinguishing the two types in machine check
safe process.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20220621072638.1273594-2-tongtiangen@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Merge series from David Jander <david@protonic.nl>:
These patches optimize the spi_sync call for the common case that the
worker thread is idle and the queue is empty. It also opens the
possibility to potentially further optimize the async path also, since
it doesn't need to take into account the direct sync path anymore.
As an example for the performance gain, on an i.MX8MM SoC with a SPI CAN
controller attached (MCP2518FD), the time the interrupt line stays
active (which corresponds roughly with the time it takes to send 3
relatively short consecutive spi_sync messages) is reduced from 98us to
only 72us by this patch.
A note about message ordering:
This patch series should not change the behavior of message ordering when
coming from the same context. This means that if a client driver issues
one or more spi_async() messages immediately followed by a spi_sync()
message in the same context, it can still rely on these messages being
sent out in the order they were fired.
|
|
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>:
Support PDM format and DSD format.
Add new dts property to configure dataline. The SAI has multiple
successive FIFO registers, but in some use
case the required dataline/FIFOs are not successive.
|
|
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
After a set of SOF-specific changes, this patchset correct problematic
uses of pm_runtime_get_sync() in ASoC, or simplifies the flow with no
functional changes. Two patches for Intel platforms also add a test on
resume success.
Additional changes were initially suggested to completely remove the
use of pm_runtime_get_sync(). These changes were dropped since they
are way too invasive, specifically in cases where the return values
were not tested, which would lead to duplicate pm_runtime_put(). The
remaining uses of pm_runtime_get_sync() cannot really be blindly
modified without context and knowledge of each driver.
|
|
This function is supposed to return zero or negative error codes but it
accidentally returns true on failure.
Fixes: 92a020747d6c ("drm/i915: Split shared dpll .get_dplls() into compute and get phases")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YrVcHArNMTGCSy+9@kili
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
The platform can sometimes - depending on its settings - cause writes
to MCA_STATUS MSRs to get ignored, regardless of HWCR[McStatusWrEn]'s
value.
For further info see
PPR for AMD Family 19h, Model 01h, Revision B1 Processors, doc ID 55898
at https://bugzilla.kernel.org/show_bug.cgi?id=206537.
Therefore, probe for ignored writes to MCA_STATUS to determine if hardware
error injection is at all possible.
[ bp: Heavily massage commit message and patch. ]
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220214233640.70510-2-Smita.KoralahalliChannabasappa@amd.com
|
|
The addrconf_verify_rtnl() function uses a big if/elseif/elseif/... block
to categorize each address by what type of attention it needs. An
about-to-expire (RFC 4941) temporary address is one such category, but the
previous elseif branch catches addresses that have already run out their
prefered_lft. This means that if addrconf_verify_rtnl() fails to run in
the necessary time window (i.e. REGEN_ADVANCE time units before the end of
the prefered_lft), the temporary address will never be regenerated, and no
temporary addresses will be available until each one's valid_lft runs out
and manage_tempaddrs() begins anew.
Fix this by moving the entire temporary address regeneration case out of
that block. That block is supposed to implement the "destructive" part of
an address's lifecycle, and regenerating a fresh temporary address is not,
semantically speaking, actually tied to any particular lifecycle stage.
The age test is also changed from `age >= prefered_lft - regen_advance`
to `age + regen_advance >= prefered_lft` instead, to ensure no underflow
occurs if the system administrator increases the regen_advance to a value
greater than the already-set prefered_lft.
Note that this does not fix the problem of addrconf_verify_rtnl() sometimes
not running in time, resulting in the race condition described in RFC 4941
section 3.4 - it only ensures that the address is regenerated. Fixing THAT
problem may require either using jiffies instead of seconds for all time
arithmetic here, or always rounding up when regen_advance is converted to
seconds.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Link: https://lore.kernel.org/r/20220623181103.7033-1-CFSworks@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
at91_pm_secure_init() is used inside sama5d2_pm_init(), which has
the __init notation.
Pass the __init notation to at91_pm_secure_init() as well to fix the
following section mismatch warning:
WARNING: modpost: vmlinux.o(.text.unlikely+0x2138): Section mismatch in reference from the function at91_pm_secure_init() to the (unknown reference) .init.rodata:(unknown)
Fixes: f2f5cf78a333 ("ARM: at91: pm: add support for sama5d2 secure suspend")
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220622114810.1186330-1-festevam@gmail.com
|
|
Fix SoC detection for SAM9X60 SiPs:
SAM9X60D5M
SAM9X60D1G
SAM9X60D6K
Fixes: af3a10513cd6 ("drivers: soc: atmel: add per soc id and version match masks")
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220616081344.1978664-1-claudiu.beznea@microchip.com
|
|
The eeprom memories on the board are microchip 24aa025e48, which are 2 Kbits
and are compatible with at24c02 not at24c32.
Fixes: 68a95ef72cefe ("ARM: dts: at91: sama5d2-icp: add SAMA5D2-ICP")
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220607090455.80433-2-eugen.hristev@microchip.com
|
Dave Stevenson
Dom Cobley
Maxime Ripard
Christoph Hellwig
Paolo Abeni
Amit Cohen
Xiang wangx
Bryan O'Donoghue
Mauro Carvalho Chehab
Imre Deak
Aidan MacDonald
Arnd Bergmann
Tong Tiangen
Mark Rutland
Mark Brown
Dan Carpenter
Smita Koralahalli
Sam Edwards
Fabio Estevam
Mihai Sain
Eugen Hristev