| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
idpf uses Page Pool for data buffers with hardcoded buffer lengths of
4k for "classic" buffers and 2k for "short" ones. This is not flexible
and does not ensure optimal memory usage. Why would you need 4k buffers
when the MTU is 1500?
Use libeth for the data buffers and don't hardcode any buffer sizes. Let
them be calculated from the MTU for "classics" and then divide the
truesize by 2 for "short" ones. The memory usage is now greatly reduced
and 2 buffer queues starts make sense: on frames <= 1024, you'll recycle
(and resync) a page only after 4 HW writes rather than two.
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Currently, idpf uses the following model for the header buffers:
* buffers are allocated via dma_alloc_coherent();
* when receiving, napi_alloc_skb() is called and then the header is
copied to the newly allocated linear part.
This is far from optimal as DMA coherent zone is slow on many systems
and memcpy() neutralizes the idea and benefits of the header split. Not
speaking of that XDP can't be run on DMA coherent buffers, but at the
same time the idea of allocating an skb to run XDP program is ill.
Instead, use libeth to create page_pools for the header buffers, allocate
them dynamically and then build an skb via napi_build_skb() around them
with no memory copy. With one exception...
When you enable header split, you expect you'll always have a separate
header buffer, so that you could reserve headroom and tailroom only
there and then use full buffers for the data. For example, this is how
TCP zerocopy works -- you have to have the payload aligned to PAGE_SIZE.
The current hardware running idpf does *not* guarantee that you'll
always have headers placed separately. For example, on my setup, even
ICMP packets are written as one piece to the data buffers. You can't
build a valid skb around a data buffer in this case.
To not complicate things and not lose TCP zerocopy etc., when such thing
happens, use the empty header buffer and pull either full frame (if it's
short) or the Ethernet header there and build an skb around it. GRO
layer will pull more from the data buffer later. This W/A will hopefully
be removed one day.
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Unlike previous generations, idpf requires more buffer types for optimal
performance. This includes: header buffers, short buffers, and
no-overhead buffers (w/o headroom and tailroom, for TCP zerocopy when
the header split is enabled).
Introduce libeth Rx buffer type and calculate page_pool params
accordingly. All the HW-related details like buffer alignment are still
accounted. For the header buffers, pick 256 bytes as in most places in
the kernel (have you ever seen frames with bigger headers?).
Reviewed-by: Przemek Kitszel <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Enable it by default.
Reviewed-by: Hawking Zhang <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
regmap_multi_reg_read() is similar to regmap_bilk_read() but reads from
an array of non-sequential registers.
Signed-off-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Rename the confusingly named struct member fw_ver to wmfw_ver. It
contains the wmfw format version of the loaded wmfw file.
This commit also contains an update to wm_adsp for the new name.
Signed-off-by: Richard Fitzgerald <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Change the log message of the wmfw format version to include
the file name, and change the message to say "format" instead
of "Firmware version". Merge this with the message that logs
the timestamp.
The wmfw format version is information that is useful to have
logged because the behaviour of firmware controls depends on
the wmfw format. So "unexpected" behaviour could be caused by
having expectations based on one format of wmfw when a
different format has been loaded.
But the original message was confusing. It reported the file
format version but didn't actually log the name of the file it
referred to. It also called it "Firmware version", which is
confusing when a later message also logs a firmware version
that is the version of the actual firmware within the wmfw.
The logging of the firmware timestamp has been merged into this.
That was originally a dbg-only message, but as we are already
logging a line of info, we might as well add a few extra
characters to log the timestamp. The timestamp is now logged
in hexadecimal - it's not particularly useful as a decimal
value.
Signed-off-by: Richard Fitzgerald <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The wmfw_filename and bin_filename strings passed into cs_dsp_power_up()
and cs_dsp_adsp1_power_up() should be const char *.
Signed-off-by: Richard Fitzgerald <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Don't allocate a temporary buffer to hold a NUL-terminated copy
of the NAME/INFO string from the wmfw/bin. It can be printed
directly to the log. Also limit the maximum number of characters
that will be logged from this string.
The NAME/INFO blocks in the firmware files are an array of
characters with a length, not a NUL-terminated C string. The
original code allocated a temporary buffer to make a
NUL-terminated copy of the string and then passed that to
dev_info(). There's no need for this: printf formatting can
use "%.*s" to print a character array of a given length.
Signed-off-by: Richard Fitzgerald <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Page Pool Ethtool stats are deprecated since the Netlink Page Pool
interface introduction.
idpf receives big changes in Rx buffer management, including &page_pool
layout, so keeping these deprecated stats does only harm, not speaking
of that CONFIG_IDPF selects CONFIG_PAGE_POOL_STATS unconditionally,
while the latter is often turned off for better performance.
Remove all the references to PP stats from the Ethtool code. The stats
are still available in their full via the generic Netlink interface.
Reviewed-by: Przemek Kitszel <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
idpf's in-kernel parsed ptype structure is almost identical to the one
used in the previous Intel drivers, which means it can be converted to
use libeth's definitions and even helpers. The only difference is that
it doesn't use a constant table (libie), rather than one obtained from
the device.
Remove the driver counterpart and use libeth's helpers for hashes and
checksums. This slightly optimizes skb fields processing due to faster
checks. Also don't define big static array of ptypes in &idpf_vport --
allocate them dynamically. The pointer to it is anyway cached in
&idpf_rx_queue.
Reviewed-by: Przemek Kitszel <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Currently, all HW supporting idpf supports the singleq model, but none
of it advertises it by default, as splitq is supported and preferred
for multiple reasons. Still, this almost dead code often times adds
hotpath branches and redundant cacheline accesses.
While it can't currently be removed, add CONFIG_IDPF_SINGLEQ and build
the singleq code only when it's enabled manually. This corresponds to
-10 Kb of object code size and a good bunch of hotpath checks.
idpf_is_queue_model_split() works as a gate and compiles out to `true`
when the config option is disabled.
Reviewed-by: Przemek Kitszel <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
It makes no sense to have a second &net_device_ops struct (800 bytes of
rodata) with only one difference in .ndo_start_xmit, which can easily
be just one `if`. This `if` is a drop in the ocean and you won't see
any difference.
Define unified idpf_xmit_start(). The preparation for sending is the
same, just call either idpf_tx_splitq_frame() or idpf_tx_singleq_frame()
depending on the active model to actually map and send the skb.
Reviewed-by: Przemek Kitszel <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Now that the queue and queue vector structures are separated and laid
out optimally, group the fields as read-mostly, read-write, and cold
cachelines and add size assertions to make sure new features won't push
something out of its place and provoke perf regression.
Despite looking innocent, this gives up to 2% of perf bump on Rx.
Reviewed-by: Przemek Kitszel <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
With CONFIG_MAXSMP, sizeof(cpumask_t) is 1 Kb. The queue vector
structure has them embedded, which means 1 additional Kb of not
really hotpath data.
We have cpumask_var_t, which is either an embedded cpumask or a pointer
for allocating it dynamically when it's big. Use it instead of plain
cpumasks and put &idpf_q_vector on a good diet.
Also remove redundant pointer to the interrupt name from the structure.
request_irq() saves it and free_irq() returns it on deinit, so that you
can free the memory.
Reviewed-by: Przemek Kitszel <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Currently, sizeof(struct idpf_queue) is 32 Kb.
This is due to the 12-bit hashtable declaration at the end of the queue.
This HT is needed only for Tx queues when the flow scheduling mode is
enabled. But &idpf_queue is unified for all of the queue types,
provoking excessive memory usage.
The unified structure in general makes the code less effective via
suboptimal fields placement. You can't avoid that unless you make unions
each 2 fields. Even then, different field alignment etc., doesn't allow
you to optimize things to the limit.
Split &idpf_queue into 4 structures corresponding to the queue types:
RQ (Rx queue), SQ (Tx queue), FQ (buffer queue), and CQ (completion
queue). Place only needed fields there and shortcuts handy for hotpath.
Allocate the abovementioned hashtable dynamically and only when needed,
keeping &idpf_tx_queue relatively short (192 bytes, same as Rx). This HT
is used only for OOO completions, which aren't really hotpath anyway.
Note that this change must be done atomically, otherwise it's really
easy to get lost and miss something.
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
In C, we have structures and unions.
Casting `void *` via macros is not only error-prone, but also looks
confusing and awful in general.
In preparation for splitting the queue structs, replace it with a
union and direct array dereferences.
Reviewed-by: Przemek Kitszel <[email protected]>
Reviewed-by: Mina Almasry <[email protected]>
Signed-off-by: Alexander Lobakin <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
`sunxi_sram_regmap_config` is not modified and can be declared as const
to move its data to a read-only section.
Signed-off-by: Javier Carrasco <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Link: https://lore.kernel.org/r/20240705-sunxi-sram-const-regmap_config-v1-1-1b997cd65d0f@gmail.com
Signed-off-by: Chen-Yu Tsai <[email protected]>
|
|
Add support to request transmit DE stats from firmware through HTT stats
type 8. These stats give information about enqueued packets, discarded
packets, failed packets and other information such as power, bandwidth
information, number of retries, etc.
Sample output:
-------------
echo 8 > /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats_type
cat /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats
HTT_TX_DE_CMN_STATS_TLV:
mac_id = 0
tcl2fw_entry_count = 0
not_to_fw = 0
.....
HTT_TX_DE_EAPOL_PACKETS_STATS_TLV:
m1_packets = 0
m2_packets = 0
m3_packets = 0
.....
HTT_TX_DE_CLASSIFY_STATS_TLV:
arp_packets = 0
igmp_packets = 0
dhcp_packets = 0
.....
HTT_TX_DE_CLASSIFY_FAILED_STATS_TLV:
ap_bss_peer_not_found = 0
ap_bcast_mcast_no_peer = 0
sta_delete_in_progress = 0
.....
HTT_TX_DE_CLASSIFY_STATUS_STATS_TLV:
eok = 0
classify_done = 0
lookup_failed = 0
.....
HTT_TX_DE_ENQUEUE_PACKETS_STATS_TLV:
enqueued_pkts = 0
to_tqm = 0
to_tqm_bypass = 0
HTT_TX_DE_ENQUEUE_DISCARD_STATS_TLV:
discarded_pkts = 0
local_frames = 0
is_ext_msdu = 0
HTT_TX_DE_COMPL_STATS_TLV:
tcl_dummy_frame = 0
tqm_dummy_frame = 0
tqm_notify_frame = 0
.....
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Signed-off-by: Dinesh Karthikeyan <[email protected]>
Signed-off-by: Roopni Devanathan <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://patch.msgid.link/[email protected]
|
|
Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()
function access ath11k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To fix
this issue, modify ath11k_dp_process_rx() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://patch.msgid.link/[email protected]
|
|
Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()
function access ath12k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To
fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://patch.msgid.link/[email protected]
|
|
Commit 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template")
from Feb 28, 2024 (linux-next), leads to the following Smatch static
checker warning:
drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie()
warn: sleeping in atomic context
The reason is that ath11k_bcn_tx_status_event() will directly call might
sleep function ath11k_wmi_cmd_send() during RCU read-side critical
sections. The call trace is like:
ath11k_bcn_tx_status_event()
-> rcu_read_lock()
-> ath11k_mac_bcn_tx_event()
-> ath11k_mac_setup_bcn_tmpl()
……
-> ath11k_wmi_bcn_tmpl()
-> ath11k_wmi_cmd_send()
-> rcu_read_unlock()
Commit 886433a98425 ("ath11k: add support for BSS color change") added the
ath11k_mac_bcn_tx_event(), commit 01e782c89108 ("ath11k: fix warning
of RCU usage for ath11k_mac_get_arvif_by_vdev_id()") added the RCU lock
to avoid warning but also introduced this BUG.
Use work queue to avoid directly calling ath11k_mac_bcn_tx_event()
during RCU critical sections. No need to worry about the deletion of vif
because cancel_work_sync() will drop the work if it doesn't start or
block vif deletion until the running work is done.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Fixes: 3a415daa3e8b ("wifi: ath11k: add P2P IE in beacon template")
Reported-by: Dan Carpenter <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Kang Yang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://patch.msgid.link/[email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fix from Hans de Goede:
"One-liner fix for a dmi_system_id array in the toshiba_acpi driver not
being terminated properly.
Something which somehow has escaped detection since being introduced
in 2022 until now"
* tag 'platform-drivers-x86-v6.10-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: toshiba_acpi: Fix array out-of-bounds access
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fix from Rafael Wysocki:
"Fix the sorting of _CST output data in the ACPI processor idle driver
(Kuan-Wei Chiu)"
* tag 'acpi-6.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: processor_idle: Fix invalid comparison with insertion sort for latency
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"Fix two issues related to boost frequencies handling, one in the
cpufreq core and one in the ACPI cpufreq driver (Mario Limonciello)"
* tag 'pm-6.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: ACPI: Mark boost policy as enabled when setting boost
cpufreq: Allow drivers to advertise boost enabled
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fixes from Rafael Wysocki:
"These fix a possible NULL pointer dereference in a thermal governor,
fix up the handling of thermal zones enabled before their temperature
can be determined and fix list sorting during thermal zone temperature
updates.
Specifics:
- Prevent the Power Allocator thermal governor from dereferencing a
NULL pointer if it is bound to a tripless thermal zone (Nícolas
Prado)
- Prevent thermal zones enabled too early from staying effectively
dormant forever because their temperature cannot be determined
initially (Rafael Wysocki)
- Fix list sorting during thermal zone temperature updates to ensure
the proper ordering of trip crossing notifications (Rafael
Wysocki)"
* tag 'thermal-6.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: core: Fix list sorting in __thermal_zone_device_update()
thermal: core: Call monitor_thermal_zone() if zone temperature is invalid
thermal: gov_power_allocator: Return early in manage if trip_max is NULL
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree fix from Rob Herring:
- One fix for PASemi Nemo board interrupts
* tag 'devicetree-fixes-for-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
of/irq: Disable "interrupt-map" parsing for PASEMI Nemo
|
|
Currently the variables of type struct atmel_tcb_pwm_device
are named "tcbpwm", and variables of type atmel_tcb_pwm_chip are either
named "tcbpwm" (too!) or "tcbpwmc". Rename the chips with device name to
"tcbpwmc" to get a consistent naming.
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
The two outputs provided by the supported hardware share some settings,
so access to the other PWM is required when one of them is configured.
Instead of an explicit if to deterimine the other PWM just use
hwpwm ^ 1. Further atcbpwm is never NULL, so drop the corresponding
check.
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
While driving a PWM via the sysfs API it's hard to determine the right
order of writes to the pseudo files "period" and "duty_cycle":
If you want to go from duty_cycle/period = 50/100 to 150/300 you have to
write period first (because 150/100 is invalid). If however you start at
400/500 the duty_cycle must be configured first. The rule that works is:
If you increase period write period first, otherwise write duty_cycle
first. A complication however is that it's usually sensible to configure
the polarity before both period and duty_cycle. This can only be done if
the current state's duty_cycle and period configuration isn't bogus
though. It is still worse (but I think only theoretic) if you have a PWM
that only supports inverted polarity and you start with period = 0 and
polarity = normal. Then you can change neither period (because polarity
= normal is refused) nor polarity (because there is still period = 0).
To simplify the corner cases for userspace, let invalid target states
pass if the current state is invalid already.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
There are devm variants for clk_prepare_enable() and pwmchip_add(); and
clk_prepare_enable() can be done together with devm_clk_get(). This
allows to simplify the error paths in .probe() and drop .remove()
completely.
With the remove callback gone, the last user of platform_get_drvdata()
is gone and so the call to platform_set_drvdata() can be dropped, too.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Sean Anderson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
mutex_unlock
With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/28807cb5d9dbce66860f74829c0f57cd9c01373e.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.
There is just one caller left for mutex_lock(&export->lock). The code
flow is too complicated there to convert it to the compiler assisted
variant.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/210010f2e579a92476462726e18e0135f6854909.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/2102fe8189bdf1f02ff3785b551a69be27a65af4.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
While the debugfs operations don't technically depend on an initialized
class, they loop over the idr that only can get entries when the class
is properly initialized.
This also fixes the ugly (but harmless) corner case that the debugfs
file stays around after the pwm class failed to initialize.
While at it, add an appropriate error message when class initialization
fails.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Apply the pinctrl setting of sleep state when system enters
suspend state.
Restore to the default pinctrl setting when system resumes.
Signed-off-by: Shenwei Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
We no longer need empty runtime PM handles for PCI devices after
commits [1] and [2]. Drop them and let PCI core take care of power
state transitions.
[1] c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
[2] fa885b06ec7e ("PCI/PM: Allow runtime PM with no PM callbacks at all")
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Raag Jadav <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Use devm_pm_runtime_enable() helper to enable runtime PM and drop redundant
platform ->remove() callback.
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Raag Jadav <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
There is no semantic change, but it is a nicer on the eyes of a reader,
because
TIM_CCR1 + 4 * ch
encodes internal register knowledge, while
TIM_CCRx(ch + 1)
keeps that information completely in the header defining the registers.
While I expected this to not result in any changes in the binary, gcc 13
(as provided by Debian in the gcc-13-arm-linux-gnueabihf 13.2.0-12cross1
package) compiles the new version with an allmodconfig to more compact
code:
$ source/scripts/bloat-o-meter drivers/pwm/pwm-stm32.o-pre drivers/pwm/pwm-stm32.o
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-488 (-488)
Function old new delta
stm32_pwm_get_state 968 936 -32
stm32_pwm_apply_locked 1920 1464 -456
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/d7ef7a6158df4ba6687233b0e00d37796b069fb3.1718791090.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into HEAD
Immutable branch between MFD and Counter due for the v5.11 merge window
|
|
Add support for Amlogic S4 PWM.
Signed-off-by: Junyi Zhao <[email protected]>
Signed-off-by: Kelvin Zhang <[email protected]>
Reviewed-by: George Stark <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Add a software PWM which toggles a GPIO from a high-resolution timer.
This will naturally not be as accurate or as efficient as a hardware
PWM, but it is useful in some cases. I have for example used it for
evaluating LED brightness handling (via leds-pwm) on a board where the
LED was just hooked up to a GPIO, and for a simple verification of the
timer frequency on another platform.
Since high-resolution timers are used, sleeping GPIO chips are not
supported and are rejected in the probe function.
Signed-off-by: Vincent Whitchurch <[email protected]>
Co-developed-by: Stefan Wahren <[email protected]>
Signed-off-by: Stefan Wahren <[email protected]>
Co-developed-by: Linus Walleij <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Dhruva Gole <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
pwm_apply_state() is deprecated since commit c748a6d77c06a ("pwm: Rename
pwm_apply_state() to pwm_apply_might_sleep()").
Signed-off-by: Sean Young <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
The last user of this function outside of core.c is gone, so it can be
made static.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
The cros-ec device tree binding only uses #pwm-cells = <1>, and so there
is no period provided in the device tree. Up to now this was handled by
hardcoding the period to the only supported value in the custom xlate
callback. Apart from that, the default xlate callback (i.e.
of_pwm_xlate_with_flags()) handles this just fine (and better, e.g. by
checking args->args_count >= 1 before accessing args->args[0]).
To simplify make use of of_pwm_xlate_with_flags(), drop the custom
callback and provide the default period in .probe() already.
Apart from simplifying the driver this also drops the last non-core user
of pwm_request_from_chip() and so makes further simplifications
possible.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
The get_state() callback is never called (in a visible way) after there
is a consumer for a pwm device. The core handles loosing the information
about duty_cycle just fine.
Simplify the driver accordingly.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Tzung-Bi Shih <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Drop kdoc comment for channel to make W=1 builds happy]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Define all pwm core's symbols in the namespace "PWM". The necessary
module import statement is just added to the main header, this way every
file that knows about the public functions automatically has this
namespace available.
Thanks to Biju Das for pointing out a cut'n'paste failure in my initial
patch.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-imx1.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-imx27.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-intel-lgm.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-mediatek.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-pxa.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-samsung.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-spear.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pwm/pwm-visconti.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Signed-off-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Instead of using regmap_update_bits() and passing val=0, better use
regmap_clear_bits().
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Trevor Gamblin <[email protected]>
Reviewed-by: Nuno Sa <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|
|
Similar to commit 7d9199995412 ("pwm: jz4740: Use
regmap_{set,clear}_bits") convert two more regmap_update_bits() calls to
regmap_{set,clear}_bits() which were missed back then.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Paul Cercueil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>
|