| Age | Commit message (Collapse) | Author |
|---|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-16-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-15-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-14-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-13-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-12-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-11-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-10-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-9-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-8-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-7-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-6-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-5-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-4-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-3-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-2-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function i2c_match_id() is used to fetch the matching ID from
the i2c_device_id table. This is often used to then retrieve the
matching driver_data. This can be done in one step with the helper
i2c_get_match_data().
This helper has a couple other benefits:
* It doesn't need the i2c_device_id passed in so we do not need
to have that forward declared, allowing us to remove those or
move the i2c_device_id table down to its more natural spot
with the other module info.
* It also checks for device match data, which allows for OF and
ACPI based probing. That means we do not have to manually check
those first and can remove those checks.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20241203200001.197295-1-afd@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Number of DAIs in the codec is not really a binding constant, because it
could grow, e.g. when we implement missing features.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20241209094442.38900-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Number of DAIs in the codec is not really a binding, because it could
grow, e.g. when we implement missing features. Add the define to the
driver, which will replace the one in the binding header.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20241209094442.38900-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add some new match table entries on Arrowlake for some coming cs42l43
laptops.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-11-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
As there are many combinations these follow a naming scheme to make
the content of link structures clearer:
cs35l56_<controller link>_<l or r><unique instance id>_adr
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-10-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add rt713_vb on SoundWire link 2 and rt1320 on SoundWire link 1 and 3
configuration support.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-9-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add rt713_vb on SoundWire link 2 and rt1320 on SoundWire link 1 and 3
configuration support.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-8-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add rt712_vb on SDW link 2 and 1 rt1320 on SDW link 1 configuration
support.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-7-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add debug message when SOC_SDW_CODEC_MIC is enabled (which informs the
machine driver to not bind in the cs42l43 microphone DAI link).
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-6-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In addition to changing the DMI match to examine the product name rather
than the SKU, this adds the quirk to inform the machine driver to not
bind in the cs42l43 microphone DAI link.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-5-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The log shows the number for different type of DAIs. Add "DAI link
numbers:" to make the log be more explicit.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ctx->ignore_internal_dmic is set when there is a dedicated SoundWire
DMIC is in the system. In other words, ignoring internal DMIC is
expected, not an error.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
mach_params->dmic_num will be used to set the cfg-mics value of
card->components string which should be the dmic channels. However
dmic_num is dmic link number and could be set due to the SOC_SDW_PCH_DMIC
quirk. Set mach_params->dmic_num to the default value if the dmic link
is created due to the SOC_SDW_PCH_DMIC quirk.
Fixes: 7db9f6361170 ("ASoC: Intel: sof_sdw: overwrite mach_params->dmic_num")
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20241206075903.195730-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Because DT check when compiling become very strict in these days,
we need to add reg = <x> if it has multi port/endpoint, otherwise
it will get error or warning. But it was not so strict and/or
mandatry before.
Current code is counting "endpoint" to get DAI ID, but it should count
"port" instead, otherwise strange ID will be used for DAI if it was multi
connected case (A). There is no issue if it was not multi connected (B).
One note is that this code will be used if neither port/endpoint doesn't
have reg = <x> property on DT.
case (A)
/* This should be handled as DAI-0 */
port@0 {
endpoint@0 { } /* It will be DAI-0 by endpoint count */
endpoint@1 { } /* It will be DAI-1 by endpoint count */
};
/* This should be handled as DAI-1 */
port@1 {
endpoint { } /* It will be DAI-2 by endpoint count */
};
case (B)
/* both endpoint cound and port count are same */
port@0 {
endpoint { ... }
};
port@1 {
endpoint { ... }
};
It will be issue if Audio-Graph-Card is used with Multi Connection.
No issue will be happen with Audio-Graph-Card2 / Simple-Card.
This patch uses for_each_of_graph_port() instead of
for_each_endpoint_of_node(), and thus, we can use "break" to quit
from loop. Because for_each_of_graph_port() uses __free(device_node)
inside.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87o71tfrdz.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Because DT check when compiling become very strict in these days,
we need to add reg = <x> if it has multi port/endpoint, otherwise
it will get error or warning. But it was not so strict and/or
mandatry before.
Current code uses reg number as DAI ID, but it will use "endpoint"
reg first and use "port" reg 2nd. But it should use port number as 1st (A)
if it was used for multi connected case. There is no priority for
port/endpoint if it was not multi connected (B).
case (A)
port {
/*
* "port" and "endpoint" are using different reg number.
* It should use <x> as DAI ID, not <y> not <z>
*/
reg = <x>;
endpoint@y { reg = <y>; ... };
endpoint@z { reg = <z>; ... };
};
case (B)
port {
/*
* Both port/endpoint are using same reg numer <x>.
*/
reg = <x>;
endpoint { reg = <x>; ... };
};
It will be issue if Audio-Graph-Card is used with Multi Connection.
No issue will be happen with Audio-Graph-Card2 / Simple-Card.
This patch swtich port/endpoint priority.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87plm9fre3.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
simple-card-utils handles many type of device_node, thus need to
use of_node_put() in many place. Let's use __free(device_node)
and avoid it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87r06pfre8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Platforms like i.MX93/91 only have one audio PLL. Some sample rates are
not supported. If the PLL source is used for 8kHz series rates, then
11kHz series rates can't be supported. Use fsl_asoc_constrain_rates()
to constrain rates according to PLL sources.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://patch.msgid.link/20241126115440.3929061-5-chancel.liu@nxp.com
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Platforms like i.MX93/91 only have one audio PLL. Some sample rates are
not supported. If the PLL source is used for 8kHz series rates, then
11kHz series rates can't be supported. Use fsl_asoc_constrain_rates()
to constrain rates according to PLL sources. This constraint is merely
applicable to playback cases on SPDIF only platforms.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://patch.msgid.link/20241126115440.3929061-4-chancel.liu@nxp.com
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
fsl_asoc_constrain_rates() is a common function to constrain rates.
Let's switch to this function.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://patch.msgid.link/20241126115440.3929061-3-chancel.liu@nxp.com
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Platforms like i.MX93/91 only have one audio PLL. Some sample rates are
not supported. Add common function to constrain rates according to
different clock sources.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://patch.msgid.link/20241126115440.3929061-2-chancel.liu@nxp.com
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
STIG mode is enabled by default for less than 8 bytes data read/write.
STIG mode doesn't work with Altera SocFPGA platform due hardware
limitation.
Add a quirks to disable STIG mode for Altera SoCFPGA platform.
Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
Link: https://patch.msgid.link/20241204063338.296959-1-niravkumar.l.rabara@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The early bail out that caused an out-of-bounds write was removed with
commit 5c018e378f91 ("spi: spi-rockchip: Fix out of bounds array
access")
Unfortunately that caused the PM runtime count to be unbalanced and
underflowed on the first call. To fix that reintroduce a no-op check
by reading the register directly.
Cc: stable@vger.kernel.org
Fixes: 5c018e378f91 ("spi: spi-rockchip: Fix out of bounds array access")
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/1f2b3af4-2b7a-4ac8-ab95-c80120ebf44c@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
A aspeed_spi_start_user() is not balanced by a corresponding
aspeed_spi_stop_user().
Add the missing call.
Fixes: e3228ed92893 ("spi: spi-mem: Convert Aspeed SMC driver to spi-mem")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/4052aa2f9a9ea342fa6af83fa991b55ce5d5819e.1732051814.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
AXP717 datasheet says that regulator ramp delay is 15.625 us/step,
which is 10mV in our case.
Add a AXP_DESC_RANGES_DELAY macro and update AXP_DESC_RANGES macro to
expand to AXP_DESC_RANGES_DELAY with ramp_delay = 0
For DCDC4, steps is 100mv
Add a AXP_DESC_DELAY macro and update AXP_DESC macro to
expand to AXP_DESC_DELAY with ramp_delay = 0
This patch fix crashes when using CPU DVFS.
Signed-off-by: Philippe Simons <simons.philippe@gmail.com>
Tested-by: Hironori KIKUCHI <kikuchan98@gmail.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Fixes: d2ac3df75c3a ("regulator: axp20x: add support for the AXP717")
Link: https://patch.msgid.link/20241208124308.5630-1-simons.philippe@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add description of the PMU node for the WCN6750B module.
Signed-off-by: Janaki Ramaiah Thota <quic_janathot@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20241209103455.9675-2-quic_janathot@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This has fixes for several boards which help my testing a lot.
|
|
Vincent and Dietmar noted that while
commit fc1892becd56 ("sched/eevdf: Fixup PELT vs DELAYED_DEQUEUE") fixes
the entity runnable stats, it does not adjust the cfs_rq runnable stats,
which are based off of h_nr_running.
Track h_nr_delayed such that we can discount those and adjust the
signal.
Fixes: fc1892becd56 ("sched/eevdf: Fixup PELT vs DELAYED_DEQUEUE")
Closes: https://lore.kernel.org/lkml/a9a45193-d0c6-4ba2-a822-464ad30b550e@arm.com/
Closes: https://lore.kernel.org/lkml/CAKfTPtCNUvWE_GX5LyvTF-WdxUT=ZgvZZv-4t=eWntg5uOFqiQ@mail.gmail.com/
[ Fixes checkpatch warnings and rebased ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reported-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reported-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20241202174606.4074512-3-vincent.guittot@linaro.org
|
|
We can't stop the tick of a rq if there are at least 2 tasks enqueued in
the whole hierarchy and not only at the root cfs rq.
rq->cfs.nr_running tracks the number of sched_entity at one level
whereas rq->cfs.h_nr_running tracks all queued tasks in the
hierarchy.
Fixes: 11cc374f4643b ("sched_ext: Simplify scx_can_stop_tick() invocation in sched_can_stop_tick()")
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lore.kernel.org/r/20241202174606.4074512-2-vincent.guittot@linaro.org
|
|
Adam reports that enabling NEXT_BUDDY insta triggers a WARN in
pick_next_entity().
Moving clear_buddies() up before the delayed dequeue bits ensures
no ->next buddy becomes delayed. Further ensure no new ->next buddy
ever starts as delayed.
Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue")
Reported-by: Adam Li <adamli@os.amperecomputing.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Adam Li <adamli@os.amperecomputing.com>
Link: https://lkml.kernel.org/r/670a0d54-e398-4b1f-8a6e-90784e2fdf89@amd.com
|
|
Replace "slab_priorities" with "slab_dependencies" in the error handler
to avoid memory leak.
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@outlook.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241127201042.29620-1-jiashengjiangcool@gmail.com
(cherry picked from commit 9bc5e7dc694d3112bbf0fa4c46ef0fa0f114937a)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
|
|
When the intel_context structure contains NULL,
it raises a NULL pointer dereference error in drm_info().
Fixes: e8a3319c31a1 ("drm/i915: Allow error capture without a request")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12309
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: <stable@vger.kernel.org> # v6.3+
Signed-off-by: Eugene Kobyak <eugene.kobyak@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/xmsgfynkhycw3cf56akp4he2ffg44vuratocsysaowbsnhutzi@augnqbm777at
(cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
|
|
DSB LUT register writes vs. palette anti-collision logic
appear to interact in interesting ways:
- posted DSB writes simply vanish into thin air while
anti-collision is active
- non-posted DSB writes actually get blocked by the anti-collision
logic, but unfortunately this ends up hogging the bus for
long enough that unrelated parallel CPU MMIO accesses start
to disappear instead
Even though we are updating the LUT during vblank we aren't
immune to the anti-collision logic because it kicks in briefly
for pipe prefill (initiated at frame start). The safe time
window for performing the LUT update is thus between the
undelayed vblank and frame start. Turns out that with low
enough CDCLK frequency (DSB execution speed depends on CDCLK)
we can exceed that.
As we are currently using non-posted writes for the legacy LUT
updates, in which case we can hit the far more severe failure
mode. The problem is exacerbated by the fact that non-posted
writes are much slower than posted writes (~4x it seems).
To mititage the problem let's switch to using posted DSB
writes for legacy LUT updates (which will involve using the
double write approach to avoid other problems with DSB
vs. legacy LUT writes). Despite writing each register twice
this will in fact make the legacy LUT update faster when
compared to the non-posted write approach, making the
problem less likely to appear. The failure mode is also
less severe.
This isn't the 100% solution we need though. That will involve
estimating how long the LUT update will take, and pushing
frame start and/or delayed vblank forward to guarantee that
the update will have finished by the time the pipe prefill
starts...
Cc: stable@vger.kernel.org
Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates")
Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12494
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
(cherry picked from commit 2504a316b35d49522f39cf0dc01830d7c36a9be4)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
|
|
Turns out the DSB indexed register write command has
rather significant initial overhead compared to the normal
MMIO write command. Based on some quick experiments on TGL
you have to write the register at least ~5 times for the
indexed write command to come out ahead. If you write the
register less times than that the MMIO write is faster.
So it seems my automagic indexed write logic was a bit
misguided. Go back to the original approach only use
indexed writes for the cases we know will benefit from
it (indexed LUT register updates).
Currently we shouldn't have any cases where this truly
matters (just some rare double writes to the precision
LUT index registers), but we will need to switch the
legacy LUT updates to write each LUT register twice (to
avoid some palette anti-collision logic troubles).
This would be close to the worst case for using indexed
writes (two writes per register, and 256 separate registers).
Using the MMIO write command should shave off around 30%
of the execution time compared to using the indexed write
command.
Cc: stable@vger.kernel.org
Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates")
Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
(cherry picked from commit ecba559a88ab8399a41893d7828caf4dccbeab6c)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
|
|
UAC 2 & 3 DAC's set bit 31 of the format to signal support for a
RAW_DATA type, typically used for DSD playback.
This is correctly tested by (format & UAC*_FORMAT_TYPE_I_RAW_DATA),
fp->dsd_raw = true; and call snd_usb_interface_dsd_format_quirks(),
however a confusing and unnecessary message gets printed because
the bit is not properly tested in the last "unsupported" if test:
if (format & ~0x3F) { ... }
For example the output:
usb 7-1: new high-speed USB device number 5 using xhci_hcd
usb 7-1: New USB device found, idVendor=262a, idProduct=9302, bcdDevice=0.01
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
usb 7-1: Product: TC44C
usb 7-1: Manufacturer: TC44C
usb 7-1: SerialNumber: 5000000001
hid-generic 0003:262A:9302.001E: No inputs registered, leaving
hid-generic 0003:262A:9302.001E: hidraw6: USB HID v1.00 Device [DDHIFI TC44C] on usb-0000:08:00.3-1/input0
usb 7-1: 2:4 : unsupported format bits 0x100000000
This last "unsupported format" is actually wrong: we know the
format is a RAW_DATA which we assume is DSD, so there is no need
to print the confusing message.
This we unset bit 31 of the format after recognizing it, to avoid
the message.
Suggested-by: Takashi Iwai <tiwai@suse.com>
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Link: https://patch.msgid.link/20241209090529.16134-2-adrian.ratiu@collabora.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is a UAC 2 DAC capable of raw DSD on intf 2 alt 4:
Bus 007 Device 004: ID 262a:9302 SAVITECH Corp. TC44C
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 [unknown]
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x262a SAVITECH Corp.
idProduct 0x9302 TC44C
bcdDevice 0.01
iManufacturer 1 DDHIFI
iProduct 2 TC44C
iSerial 6 5000000001
.......
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 0
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bmControls 0x00
bFormatType 1
bmFormats 0x80000000
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 0
.......
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Link: https://patch.msgid.link/20241209090529.16134-1-adrian.ratiu@collabora.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
