IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Pull mailbox updates from Jassi Brar:
- imx: add support for i.MX95 ELE/V2X MU
- misc: I will be signing-off from my personal gmail id from now on
* tag 'mailbox-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox:
mailbox: imx: support i.MX95 Generic/ELE/V2X MU
mailbox: imx: populate sub-nodes
mailbox: imx: get RR/TR registers num from Parameter register
mailbox: imx: support return value of init
dt-bindings: mailbox: fsl,mu: add i.MX95 Generic/ELE/V2X MU compatible
Add i.MX95 Generic/ELE/V2X MU support, its register layout is same as
i.MX8ULP, but the Parameter registers would show different
TR/RR. Since the driver already supports get TR/RR from Parameter
registers, not hardcoding the number, this patch just add
the compatible entry to reuse i.MX8ULP S4 cfg data.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
Some MUs such as i.MX95 MU, have internal SRAM which could be used
for SCMI shared memory, so populate the sub-nodes to use the SRAM.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
i.MX8ULP, i.MX93 MU has a Parameter register encoded as below:
BIT: 15 --- 8 | 7 --- 0
RR_NUM TR_NUM
So to make driver easy to support more variants, get the RR/TR
registers number from Parameter register.
The patch only adds support the specific MU, such as ELE MU.
For generic MU, not add support for number larger than 4.
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Message Handling Unit version is v2.1.
When arm_mhuv2 working with the data protocol transfer mode.
We have split one mhu into two channels, and every channel
include four channel windows, the two channels share
one gic spi interrupt.
There is a problem with the sending scenario.
The first channel will take up 0-3 channel windows, and the second
channel take up 4-7 channel windows. When the first channel send the
data, and the receiver will clear all the four channels status.
Although we only enabled the interrupt on the last channel window with
register CH_INT_EN,the register CHCOMB_INT_ST0 will be 0xf, not be 0x8.
Currently we just clear the last channel windows int status with the
data proctol mode.So after that,the CHCOMB_INT_ST0 status will be 0x7,
not be the 0x0.
Then the second channel send the data, the receiver read the
data, clear all the four channel windows status, trigger the sender
interrupt. But currently the CHCOMB_INT_ST0 register will be 0xf7,
get_irq_chan_comb function will always return the first channel.
So this patch clear all channel windows int status to avoid this interrupt
confusion.
Signed-off-by: Xiaowu.ding <xiaowu.ding@jaguarmicro.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Similarly to previous commit e172258870 ("mailbox: qcom-apcs-ipc: do
not grow the of_device_id"), move compatibles with fallbacks in the
of_device_id table, to indicate these are not necessary. This only
shuffles the code. No functional impact.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Pull ACPI updates from Rafael Wysocki:
"These fix issues, add new quirks, rearrange the IRQ override quirk
definitions, add new helpers and switch over code to using them,
rework a couple of interfaces to be more flexible, eliminate strncpy()
usage from PNP, extend the ACPI PCC mailbox driver and clean up code.
This is based on ACPI thermal driver changes that are present in the
thermal control updates for 6.7-rc1 pull request (they are depended on
by the ACPI utilities updates). However, the ACPI thermal driver
changes are not included in the list of specific ACPI changes below.
Specifics:
- Add symbol definitions related to CDAT to the ACPICA code (Dave
Jiang)
- Use the acpi_device_is_present() helper in more places and rename
acpi_scan_device_not_present() to be about enumeration (James
Morse)
- Add __printf format attribute to acpi_os_vprintf() (Su Hui)
- Clean up departures from kernel coding style in the low-level
interface for ACPICA (Jonathan Bergh)
- Replace strncpy() with strscpy() in acpi_osi_setup() (Justin Stitt)
- Fail FPDT parsing on zero length records and add proper handling
for fpdt_process_subtable() to acpi_init_fpdt() (Vasily Khoruzhick)
- Rework acpi_handle_list handling so as to manage it dynamically,
including size computation (Rafael Wysocki)
- Clean up ACPI utilities code so as to make it follow the kernel
coding style (Jonathan Bergh)
- Consolidate IRQ trigger-type override DMI tables and drop .ident
values from dmi_system_id tables used for ACPI resources management
quirks (Hans de Goede)
- Add ACPI IRQ override for TongFang GMxXGxx (Werner Sembach)
- Allow _DSD buffer data only for byte accessors and document the
_DSD data buffer GUID (Andy Shevchenko)
- Drop BayTrail and Lynxpoint pinctrl device IDs from the ACPI LPSS
driver, because it does not need them (Raag Jadav)
- Add acpi_backlight=vendor quirk for Toshiba Portégé R100 (Ondrej
Zary)
- Add "vendor" backlight quirks for 3 Lenovo x86 Android tablets
(Hans de Goede)
- Move Xiaomi Mi Pad 2 backlight quirk to its own section (Hans de
Goede)
- Annotate struct prm_module_info with __counted_by (Kees Cook)
- Fix AER info corruption in aer_recover_queue() when error status
data has multiple sections (Shiju Jose)
- Make APEI use ERST maximum execution time for slow devices (Jeshua
Smith)
- Add support for platform notification handling to the PCC mailbox
driver and modify it to support shared interrupts for multiple
subspaces (Huisong Li)
- Define common macros to use when referring to various bitfields in
the PCC generic communications channel command and status fields
and use them in some drivers (Sudeep Holla)
- Add EC GPE detection quirk for HP 250 G7 Notebook PC (Jonathan
Denose)
- Fix and clean up create_pnp_modalias() and create_of_modalias()
(Christophe JAILLET)
- Modify 2 pieces of code to use acpi_evaluate_dsm_typed() (Andy
Shevchenko)
- Define acpi_dev_uid_match() for matching _UID and use it in several
places (Raag Jadav)
- Use acpi_device_uid() for fetching _UID in 2 places (Raag Jadav)
- Add context argument to acpi_dev_install_notify_handler() (Rafael
Wysocki)
- Clarify ACPI bus concepts in the ACPI device enumeration
documentation (Rafael Wysocki)
- Switch over the ACPI AC and ACPI PAD drivers to using the platform
driver interface which, is more logically consistent than binding a
driver directly to an ACPI device object, and clean them up (Michal
Wilczynski)
- Replace strncpy() in the PNP code with either memcpy() or strscpy()
as appropriate (Justin Stitt)
- Clean up coding style in pnp.h (GuoHua Cheng)"
* tag 'acpi-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (54 commits)
ACPI: resource: Do IRQ override on TongFang GMxXGxx
perf: arm_cspmu: use acpi_dev_hid_uid_match() for matching _HID and _UID
ACPI: EC: Add quirk for HP 250 G7 Notebook PC
ACPI: x86: use acpi_dev_uid_match() for matching _UID
ACPI: utils: use acpi_dev_uid_match() for matching _UID
pinctrl: intel: use acpi_dev_uid_match() for matching _UID
ACPI: utils: Introduce acpi_dev_uid_match() for matching _UID
ACPI: sysfs: Clean up create_pnp_modalias() and create_of_modalias()
ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias()
ACPI: acpi_pad: Rename ACPI device from device to adev
ACPI: acpi_pad: Use dev groups for sysfs
ACPI: acpi_pad: Replace acpi_driver with platform_driver
ACPI: APEI: Use ERST timeout for slow devices
ACPI: scan: Rename acpi_scan_device_not_present() to be about enumeration
PNP: replace deprecated strncpy() with memcpy()
PNP: ACPI: replace deprecated strncpy() with strscpy()
perf: qcom: use acpi_device_uid() for fetching _UID
ACPI: sysfs: use acpi_device_uid() for fetching _UID
ACPI: scan: Use the acpi_device_is_present() helper in more places
ACPI: AC: Rename ACPI device from device to adev
...
MediaTek found an issue with display HW registers configuration, and
located the reason in the CMDQ Mailbox driver; reporting the original
comment with the analysis of this problem by Jason-JH Lin:
GCE should config HW in every vblanking duration.
The stream done event is the start signal of vblanking.
If stream done event is sent between GCE clk_disable
and clk_enable. After GCE clk_enable the stream done event
may not appear immediately and have about 3us delay.
Normal case:
clk_disable -> get EventA -> clk_enable -> clear EventA
-> wait EventB -> get EventB -> config HW
Abnormal case:
clk_disable -> get EventA -> clk_enable -> EventA delay appear
-> clear EventA fail -> wait EventB but get EventA -> config HW
This abnormal case may configure display HW in the vactive or
non-vblanking duration.
From his analysis we get that the GCE may finish its event processing
after some amount of time (and not immediately after sending commands
to it); since the GCE is used for more than just display, and it gets
used frequently, solve this issue by implementing Runtime PM handlers
with autosuspend: this allows us to overcome to the remote processor
delay issues and reduce the clock enable()/disable() calls, while also
still managing to save some power, which is something that we wouldn't
be able to do if we just enable the GCE clocks at probe.
Speaking of which: if Runtime PM is not available there will obviously
be no way to get this power saving action so, in this case, the clocks
will be enabled at probe() time, kept enabled for the entire driver's
life and disabled at remove().
Reported-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The Message Unit(MU) General Purpose Control registers are used for
TX doorbell, but there is no hardware ACK support.
The current TX doorbell channel is using tasklet to emulate hardware
ACK support to kick the TX tick from controller driver side.
The new added TX doorbell channel V2 not using tasklet to emulate the
hardware ACK support. The behavior for the channel is just writing the
GCR register, and no else. This will be used for SCMI mailbox.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
If the platform acknowledge interrupt is level triggered, then it can
be shared by multiple subspaces provided each one has a unique platform
interrupt ack preserve and ack set masks.
If it can be shared, then we can request the irq with IRQF_SHARED and
IRQF_ONESHOT flags. The first one indicating it can be shared and the
latter one to keep the interrupt disabled until the hardirq handler
finished.
Further, since there is no way to detect if the interrupt is for a given
channel as the interrupt ack preserve and ack set masks are for clearing
the interrupt and not for reading the status(in case Irq Ack register
may be write-only on some platforms), we need a way to identify if the
given channel is in use and expecting the interrupt.
PCC type0, type1 and type5 do not support shared level triggered interrupt.
The methods of determining whether a given channel for remaining types
should respond to an interrupt are as follows:
- type2: Whether the interrupt belongs to a given channel is only
determined by the status field in Generic Communications Channel
Shared Memory Region, which is done in rx_callback of PCC client.
- type3: This channel checks chan_in_use flag first and then checks the
command complete bit(value '1' indicates that the command has
been completed).
- type4: Platform ensure that the default value of the command complete
bit corresponding to the type4 channel is '1'. This command
complete bit is '0' when receive a platform notification.
The new field, 'chan_in_use' is used by the type only support the
communication from OSPM to Platform (like type3) and should be completely
ignored by other types so as to avoid too many type unnecessary checks in
IRQ handler.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Currently, PCC driver doesn't support the processing of platform
notification for type 4 PCC subspaces.
According to ACPI specification, if platform sends a notification
to OSPM, it must clear the command complete bit and trigger platform
interrupt. OSPM needs to check whether the command complete bit is
cleared, clear platform interrupt, process command, and then set the
command complete and ring doorbell to the Platform.
Let us stash the value of the pcc type and use the same while processing
the interrupt of the channel. We also need to set the command complete
bit and ring doorbell in the interrupt handler for the type 4 channel to
complete the communication flow after processing the notification from
the Platform.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Breaking out early when a match is found leads to an incorrect num_chans
value when more than one ipcc mailbox channel is used by the same device.
Fixes: e9d50e4b4d ("mailbox: qcom-ipcc: Dynamic alloc for channel arrangement")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Convert platform_get_resource_byname() + devm_ioremap_resource() to a
single call to devm_platform_ioremap_resource_byname(), as this is
exactly what this function does.
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
There is no need to call the dev_err() function directly to print a custom
message when handling an error from platform_get_irq() function as
it is going to display an appropriate error message in case of a failure.
Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Fix some kernel-doc comments to silence the warnings:
drivers/mailbox/bcm-pdc-mailbox.c:707: warning: Function parameter or member 'pdcs' not described in 'pdc_tx_list_sg_add'
drivers/mailbox/bcm-pdc-mailbox.c:707: warning: Excess function parameter 'spu_idx' description in 'pdc_tx_list_sg_add'
drivers/mailbox/bcm-pdc-mailbox.c:875: warning: Function parameter or member 'pdcs' not described in 'pdc_rx_list_sg_add'
drivers/mailbox/bcm-pdc-mailbox.c:875: warning: Excess function parameter 'spu_idx' description in 'pdc_rx_list_sg_add'
drivers/mailbox/bcm-pdc-mailbox.c:966: warning: Function parameter or member 't' not described in 'pdc_tasklet_cb'
drivers/mailbox/bcm-pdc-mailbox.c:966: warning: Excess function parameter 'data' description in 'pdc_tasklet_cb'
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
mbox_test_request_channel() function returns NULL or
error value embedded in the pointer (PTR_ERR).
Evaluate the return value using IS_ERR_OR_NULL.
Signed-off-by: Minjie Du <duminjie@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Sec proxy/message manager data buffer is 60 bytes with the last of the
registers indicating transmission completion. This however poses a bit
of a challenge.
The backing memory for sec_proxy / message manager is regular memory,
and all sec proxy does is to trigger a burst of all 60 bytes of data
over to the target thread backing ring accelerator. It doesn't do a
memory scrub when it moves data out in the burst. When we transmit
multiple messages, remnants of previous message is also transmitted
which results in some random data being set in TISCI fields of
messages that have been expanded forward.
The entire concept of backward compatibility hinges on the fact that
the unused message fields remain 0x0 allowing for 0x0 value to be
specially considered when backward compatibility of message extension
is done.
So, instead of just writing the completion register, we continue
to fill the message buffer up with 0x0 (note: for partial message
involving completion, we already do this).
This allows us to scale and introduce ABI changes back also work with
other boot stages that may have left data in the internal memory.
While at this, be consistent and explicit with the data_reg pointer
increment.
Fixes: aace66b170 ("mailbox: Introduce TI message manager driver")
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
There was a bug where this code forgot to unlock the tdev->mutex if the
kzalloc() failed. Fix this issue, by moving the allocation outside the
lock.
Fixes: 2d1e952a2b ("mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Pull mailbox updates from Jassi Brar:
- mailbox api: allow direct registration to a channel and convert omap
and pcc to use mbox_bind_client
- omap and hi6220 : use of_property_read_bool
- test: fix double-free and use spinlock header
- rockchip and bcm-pdc: drop of_match_ptr
- mpfs: change config symbol
- mediatek gce: support MT6795
- qcom apcs: consolidate of_device_id and support IPQ9574
* tag 'mailbox-v6.4' of git://git.linaro.org/landing-teams/working/fujitsu/integration:
dt-bindings: mailbox: qcom: add compatible for IPQ9574 SoC
mailbox: qcom-apcs-ipc: do not grow the of_device_id
dt-bindings: mailbox: qcom,apcs-kpss-global: use fallbacks for few variants
dt-bindings: mailbox: mediatek,gce-mailbox: Add support for MT6795
mailbox: mpfs: convert SOC_MICROCHIP_POLARFIRE to ARCH_MICROCHIP_POLARFIRE
mailbox: bcm-pdc: drop of_match_ptr for ID table
mailbox: rockchip: drop of_match_ptr for ID table
mailbox: mailbox-test: Fix potential double-free in mbox_test_message_write()
mailbox: mailbox-test: Explicitly include header for spinlock support
mailbox: Use of_property_read_bool() for boolean properties
mailbox: pcc: Use mbox_bind_client
mailbox: omap: Use mbox_bind_client
mailbox: Allow direct registration to a channel
Re-organize the compatible devices and add a comment to avoid unneeded
of_device_id growth with every new SoC. These devices have quite a lot
of similarities and they can use only one compatible fallback for driver
binding.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
