| Age | Commit message (Collapse) | Author |
|---|
|
The return value of bcm2835_clock_rate_from_divisor is always unsigned
and also all caller expect this. So fix the declaration accordingly.
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20220904141037.38816-1-stefan.wahren@i2se.com
Reviewed-by: Ivan T. Ivanov <iivanov@suse.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
It was reported that RPi3[1] and RPi Zero 2W boards have issues with
the Bluetooth. It turns out that when switching from initial to
operation speed host and device no longer can talk each other because
host uses incorrect UART baud rate.
The UART driver used in this case is amba-pl011. Original fix, see
below Github link[2], was inside pl011 module, but somehow it didn't
look as the right place to fix. Beside that this original rounding
function is not exactly perfect for all possible clock values. So I
deiced to move the hack to the platform which actually need it.
The UART clock is initialised to be as close to the requested
frequency as possible without exceeding it. Now that there is a
clock manager that returns the actual frequencies, an expected
48MHz clock is reported as 47999625. If the requested baud rate
== requested clock/16, there is no headroom and the slight
reduction in actual clock rate results in failure.
If increasing a clock by less than 0.1% changes it from ..999..
to ..000.., round it up.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
[2] https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
Cc: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/20220912081306.24662-1-iivanov@suse.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
When testing for a series affecting the VEC, it was discovered that
turning off and on the VEC clock is crashing the system.
It turns out that, when disabling the VEC clock, it's the only child of
the PLLC-per clock which will also get disabled. The source of the crash
is PLLC-per being disabled.
It's likely that some other device might not take a clock reference that
it actually needs, but it's unclear which at this point. Let's make
PLLC-per critical so that we don't have that crash.
Reported-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220926084509.12233-1-maxime@cerno.tech
Reviewed-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
of_device_is_compatible() accepts const device node pointer, there is
no reason why of_device_compatible_match() can't do the same.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/YzY5MaU5N4A2st5R@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
In accordance with the way the MIPS platform is normally design there are
only six clock sources which need to be available on the kernel start in
order to one end up booting correctly:
+ CPU PLL: needed by the r4k and MIPS GIC timer drivers. The former one is
initialized by the arch code, while the later one is implemented in the
mips-gic-timer.c driver as the OF-declared timer.
+ PCIe PLL: required as a parental clock source for the APB/timer domains.
+ APB clock: needed in order to access all the SoC CSRs at least for the
timer OF-declared drivers.
+ APB Timer{0-2} clocks: these are the DW APB timers which drivers
dw_apb_timer_of.c are implemented as the OF-declared timers.
So as long as the clocks above are available early the kernel will
normally work. Let's convert the Baikal-T1 CCU drivers to the platform
device drivers keeping that in mind.
Generally speaking the conversion isn't that complicated since the driver
infrastructure has been designed as flexible enough for that. First we
need to add a new PLL/Divider clock features flag which indicates the
corresponding clock source as a basic one and that clock sources will be
available on the kernel early boot stages. Second the internal PLL/Divider
descriptors need to be initialized with -EPROBE_DEFER value as the
corresponding clock source is unavailable at the early stages. They will
be allocated and initialized on the Baikal-T1 clock platform driver probe
procedure. Finally the already available PLL/Divider init functions need
to be split up into two ones: init procedure performed in the framework of
the OF-declared clock initialization (of_clk_init()), and the probe
procedure called by the platform devices bus driver. Note the later method
will just continue the system clocks initialization started in the former
one.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-9-Sergey.Semin@baikalelectronics.ru
[sboyd@kernel.org: Remove module things because the Kconfig is still
bool]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Aside with a set of the trigger-like resets Baikal-T1 CCU provides two
additional blocks with directly controlled reset signals. In particular it
concerns DDR full and initial resets and various PCIe sub-domains resets.
Let's add the direct reset assertion/de-assertion of the corresponding
flags support into the Baikal-T1 CCU driver then. It will be required at
least for the PCIe platform driver. Obviously the DDR controller isn't
supposed to be fully reset in the kernel, so the corresponding controls
are added just for the sake of the interface implementation completeness.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20220929225402.9696-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Before adding the directly controlled resets support it's reasonable to
move the existing resets control functionality into a dedicated object for
the sake of the CCU dividers clock driver simplification. After the new
functionality was added clk-ccu-div.c would have got to a mixture of the
weakly dependent clocks and resets methods. Splitting the methods up into
the two objects will make the code easier to read and maintain. It shall
also improve the code scalability (though hopefully we won't need this
part that much in the future).
The reset control functionality is now implemented in the framework of a
single unit since splitting it up doesn't make much sense due to
relatively simple reset operations. The ccu-rst.c has been designed to be
looking like ccu-div.c or ccu-pll.c with two globally available methods
for the sake of the code unification and better code readability.
This commit doesn't provide any change in the CCU reset implementation
semantics. As before the driver will support the trigger-like CCU resets
only, which are responsible for the AXI-bus, APB-bus and SATA-ref blocks
reset. The assert/de-assert-capable reset controls support will be added
in the next commit.
Note the CCU Clock dividers and resets functionality split up was possible
due to not having any side-effects (at least we didn't found ones) of the
regmap-based concurrent access of the common CCU dividers/reset CSRs.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20220929225402.9696-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
It turns out the internal SATA reference clock signal will stay
unavailable for the SATA interface consumer until the buffer on it's way
is ungated. So aside with having the actual clock divider enabled we need
to ungate a buffer placed on the signal way to the SATA controller (most
likely some rudiment from the initial SoC release). Seeing the switch flag
is placed in the same register as the SATA-ref clock divider at a
non-standard ffset, let's implement it as a separate clock controller with
the set-rate propagation to the parental clock divider wrapper. As such
we'll be able to disable/enable and still change the original clock source
rate.
Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Baikal-T1 CCU reference manual says that both xGMAC reference and xGMAC
PTP clocks are generated by two different wrappers with the same constant
divider thus each producing a 156.25 MHz signal. But for some reason both
of these clock sources are gated by a single switch-flag in the CCU
registers space - CCU_SYS_XGMAC_BASE.BIT(0). In order to make the clocks
handled independently we need to define a shared parental gate so the base
clock signal would be switched off only if both of the child-clocks are
disabled.
Note the ID is intentionally set to -2 since we are going to add a one
more internal clock identifier in the next commit.
Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Most likely due to copy-paste mistake the divider has been set to 10 while
according to the SoC reference manual it's supposed to be 8 thus having
PTP clock frequency of 156.25 MHz.
Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20220929225402.9696-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
We have discovered random glitches during the system boot up procedure.
The problem investigation led us to the weird outcomes: when none of the
Renesas 5P49V6901 ports are explicitly enabled by the kernel driver, the
glitches disappeared. It was a mystery since the SoC external clock
domains were fed with different 5P49V6901 outputs. The driver code didn't
seem like bogus either. We almost despaired to find out a root cause when
the solution has been found for a more modern revision of the chip. It
turned out the 5P49V6901 clock generator stopped its output for a short
period of time during the VC5_OUT_DIV_CONTROL register writing. The same
problem was found for the 5P49V6965 revision of the chip and was
successfully fixed in commit fc336ae622df ("clk: vc5: fix output disabling
when enabling a FOD") by enabling the "bypass_sync" flag hidden inside
"Unused Factory Reserved Register". Even though the 5P49V6901 registers
description and programming guide doesn't provide any intel regarding that
flag, setting it up anyway in the officially unused register completely
eliminated the denoted glitches. Thus let's activate the functionality
submitted in commit fc336ae622df ("clk: vc5: fix output disabling when
enabling a FOD") for the Renesas 5P49V6901 chip too in order to remove the
ports implicit inter-dependency.
Fixes: dbf6b16f5683 ("clk: vc5: Add support for IDT VersaClock 5P49V6901")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20220929225402.9696-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
amd-drm-fixes-6.0-2022-09-30-1:
amdgpu:
- VCN 4.x fixes
- RLC fixes for GC 11.x
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220930210454.542719-1-alexander.deucher@amd.com
|
|
switch to common helper to initialize rlc firmware
for gfx11
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To initialzie rlc firmware according to rlc
firmware header version
v2: squash in backwards compat fix
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To initialize rlc firmware in header v2_4
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To initialize rlc firmware in header v2_3
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To initialize rlc firmware in header v2_2
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To initialize rlc firmware in header v2_1
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
To initialize rlc firmware in header v2_0
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
cache rlcv/rlcvp ucode version info in amdgpu_gfx
structure
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
dev_err() can be replace with dev_err_probe() which will check if error
code is -EPROBE_DEFER.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220913032228.985852-1-yangyingliang@huawei.com
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Fix spelling typo in comment.
Reported-by: k2ci <kernel-bot@kylinos.cn>
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Link: https://lore.kernel.org/r/20220905065833.1831473-1-13667453960@163.com
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The PXA168 has a peculiar setup with the AXI clock enable control for
the SDHC controllers. The bits in the SDH0 register control the AXI
clock enable for both SDH0 and SDH1. Likewise, the bits in the SDH2
register control both SDH2 and SDH3. This is modeled with two new
parentless clocks that control the shared bits.
Previously, SDH0 had to be enabled in order for SDH1 to be used, and
when SDH1 was enabled, unused bits in the SDH1 register were being
controlled. This fixes those issues. A future commit will add support
for these new shared clocks to be enabled by the PXA168 SDHC driver.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-13-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The PXA168 has four SDHC peripherals. This commit adds the last two.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-11-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
According to the datasheet, only bit 0 of APBC_GPIO should be controlled
for the clock enable. Bit 1 is marked as reserved (always write 0).
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-9-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The TWSI, KPC, PWM, and DFC peripherals didn't have their muxes modeled
in the code, but the PXA168 datasheet shows that they are indeed muxed:
- TWSI can be 31.2 MHz or 62.4 MHz
- KPC can be 32 kHz, 16 kHz, or 26 MHz
- PWM can be 13 MHz or 32 kHz
- DFC can be 156 MHz or 78 MHz
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-8-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The UART, SDHC, LCD, and CCIC peripherals' muxed parent clocks didn't
match the information provided by the PXA168 datasheet:
- The UART clocks can be 58.5 MHz or the UART PLL. Previously, the first
mux option was being calculated as 117 MHz, confirmed on hardware to
be incorrect.
- The SDHC clocks can be 48 MHz, 52 MHz, or 78 MHz. Previously, 48 MHz
and 52 MHz were swapped. 78 MHz wasn't listed as an option.
- The LCD clock can be 624 MHz or 312 Mhz. Previously, it was being
calculated as 312 MHz or 52 MHz.
- The CCIC clock can be 156 MHz or 78 MHz. Previously, it was being
calculated as 312 MHz or 52 MHz.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-7-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
While working on this series of patches, checkpatch recommended that
an extra const should be added to the mux parent arrays.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-6-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
This commit adds three new clocks that previously didn't exist, but are
needed in order to match the clock parenting as described in the PXA168
datasheet.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-5-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
These two clocks had multipliers and dividers that didn't match their
names. A subsequent commit goes through all of the existing peripherals
and ensure the correct clocks are being used everywhere.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-3-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
In preparation for adding additional peripherals over time, this commit
adds a bunch of extra APBC_* defines based on information from the
datasheet. It also reorganizes the list of defines to be ordered
sequentially by address (grouped by type).
Signed-off-by: Doug Brown <doug@schmorgal.com>
Link: https://lore.kernel.org/r/20220612192937.162952-2-doug@schmorgal.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes")
relaxed the handling of "dma-ranges" for any leaf node on the assumption
that it would still represent a usage error for the property to be
present on a non-bus leaf node. However there turns out to be a fiddly
case where a bus also represents a DMA-capable device in its own right,
such as a PCIe root complex with an integrated DMA engine on its
platform side. In such cases, "dma-ranges" translation is entirely valid
for devices discovered behind the bus, but should not be erroneously
applied to the bus controller device itself which operates in its
parent's address space. Fix this by restoring the previous behaviour for
the specific case where a device is configured via its own OF node,
since it is logical to assume that a device should never represent its
own parent bus.
Reported-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/112e8f3d3e7c054ecf5e12b5ac0aa5596ec00681.1664455433.git.robin.murphy@arm.com
Signed-off-by: Rob Herring <robh@kernel.org>
|
|
Add the list of clocks for the Unisoc UMS512, along with clock
initialization.
Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com>
Link: https://lore.kernel.org/r/20220909152421.278662-3-gengcixi@gmail.com
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Merge changes related to ACPI data-only tables handling and ACPI device
properties management, x86-specific ACPI code changes and ACPI SoC driver
changes for 6.1-rc1:
- Clean up the ACPI LPSS (Intel SoC) driver (Andy Shevchenko).
- Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable (Mario
Limonciello).
- Drop unused dev_fmt() and redundant 'HMAT' prefix from the HMAT
parsing code (Liu Shixin).
- Make ACPI FPDT parsing code avoid calling acpi_os_map_memory() on
invalid physical addresses (Hans de Goede).
- Silence missing-declarations warning related to Apple device
properties management (Lukas Wunner).
* acpi-properties:
ACPI: property: Silence missing-declarations warning in apple.c
* acpi-tables:
ACPI: HMAT: Drop unused dev_fmt() and redundant 'HMAT' prefix
ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address
* acpi-x86:
ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable
* acpi-soc:
ACPI: LPSS: Deduplicate skipping device in acpi_lpss_create_device()
ACPI: LPSS: Replace loop with first entry retrieval
|
|
Add a new label to deduplicate skipping device code in the
acpi_lpss_create_device(). No functional change intended.
While at it, convert the last conditional to use the classical
pattern, i.e.
if (err)
...handle err...
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After the commit 6505e452371d ("ACPI: LPSS: Use the helper
acpi_dev_get_memory_resources()") the list is empty or
contains only resource of IORESOURCE_MEM type. Hence, no
need to check for the type, and since we break after the
first found, no need to iterate over full list. That said,
replace loop with first entry retrieval.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Merge changes related to ACPI device enumeration and ACPI support for
platform devices for 6.1-rc1:
- Clean up ACPI platform devices support code (Andy Shevchenko, John
Garry).
- Clean up ACPI bus management code (Andy Shevchenko, ye xingchen).
- Add support for multiple DMA windows with different offsets to the
ACPI device enumeration code and use it on LoongArch (Jianmin Lv).
* acpi-scan:
LoongArch: Use acpi_arch_dma_setup() and remove ARCH_HAS_PHYS_TO_DMA
ACPI: scan: Support multiple DMA windows with different offsets
* acpi-bus:
ACPI: bus: Refactor ACPI matching functions for better readability
ACPI: bus: Drop kernel doc annotation from acpi_bus_notify()
ACPI: bus: Remove the unneeded result variable
* acpi-platform:
ACPI: platform: Use PLATFORM_DEVID_NONE in acpi_create_platform_device()
ACPI: platform: Sort forbidden_id_list[] in ascending order
ACPI: platform: Use sizeof(*pointer) instead of sizeof(type)
ACPI: platform: Remove redundant print on -ENOMEM
ACPI: platform: Get rid of redundant 'else'
|
|
Merge ACPI resource management and ACPI power management chages for
6.1-rc1:
- Filter out non-memory resources in is_memory(), add a helper
function to find all memory type resources of an ACPI device object
and use that function in 3 places (Heikki Krogerus).
- Add IRQ override quirks for Asus Vivobook K3402ZA/K3502ZA and ASUS
model S5402ZA (Tamim Khan, Kellen Renshaw).
- Fix acpi_dev_state_d0() kerneldoc (Sakari Ailus).
- Fix up suspend-to-idle support on ASUS Rembrandt laptops (Mario
Limonciello).
* acpi-resource:
ACPI: resource: Add ASUS model S5402ZA to quirks
usb: typec: intel_pmc_mux: Use the helper acpi_dev_get_memory_resources()
ACPI: resource: Skip IRQ override on Asus Vivobook K3402ZA/K3502ZA
ACPI: LPSS: Use the helper acpi_dev_get_memory_resources()
ACPI: APD: Use the helper acpi_dev_get_memory_resources()
ACPI: resource: Add helper function acpi_dev_get_memory_resources()
ACPI: resource: Filter out the non memory resources in is_memory()
* acpi-pm:
ACPI: x86: s2idle: Add another ID to s2idle_dmi_table
ACPI: x86: s2idle: Fix a NULL pointer dereference
ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13
ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7
ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID
ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt
ACPI: x86: s2idle: Move _HID handling for AMD systems into structures
ACPI: PM: Fix acpi_dev_state_d0() kerneldoc
|
|
Merge changes regarding the management of ACPI device objects for
6.1-rc1:
- Rename ACPI device object reference counting functions (Rafael
Wysocki).
- Rearrange ACPI device object initialization code (Rafael Wysocki).
- Drop parent field from struct acpi_device (Rafael Wysocki).
- Extend the the int3472-tps68470 driver to support multiple consumers
of a single TPS68470 along with the requisite framework-level
support (Daniel Scally).
* acpi-dev:
platform/x86: int3472: Add board data for Surface Go2 IR camera
platform/x86: int3472: Support multiple gpio lookups in board data
platform/x86: int3472: Support multiple clock consumers
ACPI: bus: Add iterator for dependent devices
ACPI: scan: Add acpi_dev_get_next_consumer_dev()
ACPI: property: Use acpi_dev_parent()
ACPI: Drop redundant acpi_dev_parent() header
ACPI: PM: Fix NULL argument handling in acpi_device_get/set_power()
ACPI: Drop parent field from struct acpi_device
ACPI: scan: Eliminate __acpi_device_add()
ACPI: scan: Rearrange initialization of ACPI device objects
ACPI: scan: Rename acpi_bus_get_parent() and rearrange it
ACPI: Rename acpi_bus_get/put_acpi_device()
|
|
On one of the Chrome system, if we define more than 12 trip points,
probe for thermal sensor fails with
"int3403 thermal: probe of INTC1046:03 failed with error -22"
and throws an error as
"thermal_sys: Error: Incorrect number of thermal trips".
The thermal_zone_device_register() interface needs maximum
number of trip points supported in a zone as an argument.
This number can't exceed THERMAL_MAX_TRIPS, which is currently
set to 12. To address this issue, THERMAL_MAX_TRIPS value
has to be increased.
This interface also has an argument to specify a mask of trips
which are writable. This mask is defined as an int.
This mask sets the ceiling for increasing maximum number of
supported trips. With the current implementation, maximum number
of trips can be supported is 31.
Also, THERMAL_MAX_TRIPS macro is used in one place only.
So, remove THERMAL_MAX_TRIPS macro and compare num_trips
directly with using a macro BITS_PER_TYPE(int)-1.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.1
Few stack changes and lots of driver changes in this round. brcmfmac
has more activity as usual and it gets new hardware support. ath11k
improves WCN6750 support and also other smaller features. And of
course changes all over.
Note: in early September wireless tree was merged to wireless-next to
avoid some conflicts with mac80211 patches, this shouldn't cause any
problems but wanted to mention anyway.
Major changes:
mac80211
- refactoring and preparation for Wi-Fi 7 Multi-Link Operation (MLO)
feature continues
brcmfmac
- support CYW43439 SDIO chipset
- support BCM4378 on Apple platforms
- support CYW89459 PCIe chipset
rtw89
- more work to get rtw8852c supported
- P2P support
- support for enabling and disabling MSDU aggregation via nl80211
mt76
- tx status reporting improvements
ath11k
- cold boot calibration support on WCN6750
- Target Wake Time (TWT) debugfs support for STA interface
- support to connect to a non-transmit MBSSID AP profile
- enable remain-on-channel support on WCN6750
- implement SRAM dump debugfs interface
- enable threaded NAPI on all hardware
- WoW support for WCN6750
- support to provide transmit power from firmware via nl80211
- support to get power save duration for each client
- spectral scan support for 160 MHz
wcn36xx
- add SNR from a received frame as a source of system entropy
* tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (231 commits)
wifi: rtl8xxxu: Improve rtl8xxxu_queue_select
wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM
wifi: rtl8xxxu: gen2: Enable 40 MHz channel width
wifi: rtw89: 8852b: configure DLE mem
wifi: rtw89: check DLE FIFO size with reserved size
wifi: rtw89: mac: correct register of report IMR
wifi: rtw89: pci: set power cut closed for 8852be
wifi: rtw89: pci: add to do PCI auto calibration
wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf
wifi: rtw89: add DMA busy checking bits to chip info
wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels
wifi: rtw89: pci: mask out unsupported TX channels
iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper
ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper
wifi: iwlwifi: Track scan_cmd allocation size explicitly
brcmfmac: Remove the call to "dtim_assoc" IOVAR
brcmfmac: increase dcmd maximum buffer size
brcmfmac: Support 89459 pcie
brcmfmac: increase default max WOWL patterns to 16
cw1200: fix incorrect check to determine if no element is found in list
...
====================
Link: https://lore.kernel.org/r/20220930150413.A7984C433D6@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Pull virtio fixes from Michael Tsirkin:
"Some last minute fixes.
The virtio-blk one is the most important one since it was actually
seen in the field, but the rest of them are small and clearly safe,
everything here has been in next for a while"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
vdpa/mlx5: Fix MQ to support non power of two num queues
vduse: prevent uninitialized memory accesses
virtio-blk: Fix WARN_ON_ONCE in virtio_queue_rq()
virtio_test: fixup for vq reset
virtio-crypto: fix memory-leak
vdpa/ifcvf: fix the calculation of queuepair
|
|
Pull block fixes from Jens Axboe:
"A single NVMe pull request via Christoph with a few fixes that should
go into the 6.0 release:
- Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices
(Michael Kelley)
- Disable Write Zeroes on Phison E3C/E4C (Tina Hsu)"
* tag 'block-6.0-2022-09-29' of git://git.kernel.dk/linux:
nvme-pci: disable Write Zeroes on Phison E3C/E4C
nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
"One more fix for the upcoming release:
- fix the check for pwm support on non-A8K platforms in gpio-mvebu"
* tag 'gpio-fixes-for-v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: mvebu: Fix check for pwm support on non-A8K platforms
|
|
This was fixed in initialize_cpsch before, but not in initialize_nocpsch.
Factor sdma bitmap initialization into a helper function to apply the
correct implementation in both cases without duplicating it.
v2: Added a range check
Reported-by: Ellis Michael <ellis@ellismichael.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Graham Sider <Graham.Sider@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Unified memory usage with xnack off is tracked to avoid oversubscribe
system memory, with xnack on, we don't track unified memory usage to
allow memory oversubscribe. When switching xnack mode from off to on,
subsequent free ranges allocated with xnack off will not unreserve
memory. When switching xnack mode from on to off, subsequent free ranges
allocated with xnack on will unreserve memory. Both cases cause memory
accounting unbalanced.
When switching xnack mode from on to off, need reserve already allocated
svm range memory. When switching xnack mode from off to on, need
unreserve already allocated svm range memory.
v6: Take prange lock to access range child list
v5: Handle prange child ranges
v4: Handle reservation memory failure
v3: Handle switching xnack mode race with svm_range_deferred_list_work
v2: Handle both switching xnack from on to off and from off to on cases
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Enable sram on vcn_4_0_2
Signed-off-by: Sonny Jiang <sonny.jiang@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Enable VCN DPG on GC11_0_1
Signed-off-by: Sonny Jiang <sonny.jiang@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Pull drm fixes from Dave Airlie:
"Last set of fixes for 6.0 hopefully - minor bridge fixes, i915 fixes,
and a bunch of amdgpu fixes for new IP blocks, along with a couple of
regression fixes. Should be all set for merge window next week.
amdgpu:
- GC 11.x fixes
- SMU 13.x fixes
- DCN 3.1.4 fixes
- DCN 3.2.x fixes
- GC 9.x fix
- Fence fix
- SR-IOV supend/resume fix
- PSR regression fix
i915:
- Restrict forced preemption to the active context
- Restrict perf_limit_reasons to the supported platforms - gen11+
bridge:
- analogix: Revert earlier suspend fix
- lt8912b: Fix corrupt display output"
* tag 'drm-fixes-2022-09-30-1' of git://anongit.freedesktop.org/drm/drm: (26 commits)
drm/amd/display: Prevent OTG shutdown during PSR SU
drm/i915/gt: Perf_limit_reasons are only available for Gen11+
drm/amdgpu: Add amdgpu suspend-resume code path under SRIOV
drm/amdgpu: Remove fence_process in count_emitted
drm/amdgpu: Correct the position in patch_cond_exec
drm/amd/display: fill in clock values when DPM is not enabled
drm/amd/display: Avoid unnecessary pixel rate divider programming
drm/amd/display: Remove assert for odm transition case
drm/amd/display: Fix typo in get_pixel_rate_div
drm/amd/display: Fix audio on display after unplugging another
drm/amd/display: Add explicit FIFO disable for DP blank
drm/amd/display: Wrap OTG disable workaround with FIFO control
drm/amd/display: Do DIO FIFO enable after DP video stream enable
drm/amd/display: Update DCN32 to use new SR latencies
drm/amd/display: Avoid avoid unnecessary pixel rate divider programming
drm/amdkfd: fix dropped interrupt in kfd_int_process_v11
drm/amdgpu: pass queue size and is_aql_queue to MES
drm/amdkfd: fix MQD init for GFX11 in init_mqd
drm/amd/pm: use adverse selection for dpm features unsupported by driver
drm/amd/pm: enable gfxoff feature for SMU 13.0.0
...
|
|
Although mlx5e_rq_free_shampo can be called unconditionally, it belongs
to case MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ. Move it there to allow to
add more init/cleanup actions to the striding RQ case.
If xdp_rxq_info_reg_mem_model fails, don't forget to destroy the page
pool.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
