Skip to main content

Browse the archive

https://github.com/raspberrypi/linux
17 August 2024, 02:29:16 UTC
sort by:
Revision Author Date Message Commit Date
da91801 Phil Elwell 24 April 2022, 19:25:34 UTC overlays: Fix pitft28/35-resistive rotate params The drm drivers uses the property name "rotation", not "rotate" as used by the fbtft drivers. Fix suggested by notro. See: https://forums.raspberrypi.com/viewtopic.php?p=1996785#p1996785 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 24 April 2022, 19:58:19 UTC
a596311 Phil Elwell 19 April 2022, 18:57:29 UTC ARM: dts: Add i2c0mux node to Model B rev 1 The lack of an i2c0mux label prevents the i2c-rtc overlay from being applied. See: https://github.com/raspberrypi/linux/issues/4999 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 24 April 2022, 19:03:05 UTC
505e033 andrum99 24 April 2022, 16:23:23 UTC overlays: Add "drm" parameter to pitft28-resistive Add "drm" parameter to the pitft28-resistive, forcing use of the mi0283qt DRM driver. 24 April 2022, 19:03:05 UTC
421d48c Scovotto Davide 20 April 2022, 15:22:17 UTC tpm_tis_spi_main: Force probe routine to run... ...synchronously with driver and device registration when IMA is enabled Co-authored-by: Alberto Solavagione <albertosolavagione30@gmail.com> Co-developed-by: Alberto Solavagione <albertosolavagione30@gmail.com> Signed-off-by: Alberto Solavagione <albertosolavagione30@gmail.com> Signed-off-by: Davide Scovotto <scovottodavide@gmail.com> 24 April 2022, 19:02:31 UTC
12ed99e Alberto Solavagione 20 April 2022, 15:15:42 UTC clk-bcm2835: use subsys_initcall for the clock... ...driver when IMA is enabled Co-authored-by: Davide Scovotto <scovottodavide@gmail.com> Co-developed-by: Davide Scovotto <scovottodavide@gmail.com> Signed-off-by: Davide Scovotto <scovottodavide@gmail.com> Signed-off-by: Alberto Solavagione <albertosolavagione30@gmail.com> 24 April 2022, 19:01:51 UTC
bbf8d55 Maxime Ripard 15 April 2022, 13:26:07 UTC rpivid: Use clk_get_max_rate() The driver was using clk_round_rate() to figure out the maximum clock rate that was allowed for the HEVC clock. Since we have a function to return it directly now, let's use it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:19 UTC
ad942a3 Maxime Ripard 13 April 2022, 14:22:49 UTC drm/vc4: kms: Use maximum FIFO load for the HVS clock rate The core clock computation takes into account both the load due to the input (ie, planes) and its output (ie, encoders). However, while the input load needs to consider all the planes, and thus sum all of their associated loads, the output happens mostly in parallel. Therefore, we need to consider only the maximum of all the output loads, and not the sum like we were doing. This resulted in a clock rate way too high which could be discarded for being too high by the clock framework. Since recent changes, the clock framework will even downright reject it, leading to a core clock being too low for its current needs. Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:18 UTC
e138b34 Maxime Ripard 25 March 2022, 16:09:41 UTC drm/vc4: Make sure we don't end up with a core clock too high Following the clock rate range improvements to the clock framework, trying to set a disjoint range on a clock will now result in an error. Thus, we can't set a minimum rate higher than the maximum reported by the firmware, or clk_set_min_rate() will fail. Thus we need to clamp the rate we are about to ask for to the maximum rate possible on that clock. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:18 UTC
3de7298 Maxime Ripard 25 March 2022, 14:48:48 UTC drm/vc4: kms: Warn if clk_set_min_rate fails We currently ignore the clk_set_min_rate return code assuming it would succeed. However, it can fail if we ask for a rate higher than the current maximum for example. Since we can't fail in atomic_commit, at least warn on failure. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:17 UTC
176a0ef Maxime Ripard 24 March 2022, 10:57:57 UTC drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection In order to support higher HDMI frequencies, users have to set the hdmi_enable_4kp60 parameter in their config.txt file. We were detecting this so far by calling clk_round_rate on the core clock with the frequency we're supposed to run at when one of those modes is enabled. Whether or not the parameter was enabled could then be inferred by the returned rate since the maximum clock rate reported by the firmware was one of the side effect of setting that parameter. However, the recent clock rework we did changed what clk_round_rate was returning to always return the minimum allowed, and thus this test wasn't reliable anymore. Let's instead try to set a minimum on that clock for the rate we'd like to reach. If the maximum reported by the firmware is below the minimum we're trying to set, the clock framework will return an error which we then can use to infer whether the parameter is set or not. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:16 UTC
4809cf3 Maxime Ripard 15 April 2022, 13:00:44 UTC clk: tests: Add missing test case for ranges Let's add a test on the rate range after a reparenting. This fails for now, but it's worth having it to document the corner cases we don't support yet. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:16 UTC
0b1a5e3 Maxime Ripard 15 April 2022, 12:45:17 UTC clk: tests: Add some tests for clk_get_rate_range() Let's introduce a bunch of unit tests to make sure the values returned by clk_get_rate_range() are sane. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:15 UTC
0a841a6 Maxime Ripard 15 April 2022, 12:17:41 UTC clk: Add clk_get_rate_range With the recent introduction of clock drivers that will force their clock rate to either the minimum or maximum boundaries, it becomes harder for clock users to discover either boundary of their clock. Indeed, the best way to do that previously was to call clk_round_rate() on either 0 or ULONG_MAX and count on the driver to clamp the rate to the current boundary, but that won't work anymore. Since any other alternative (calling clk_set_rate_range() and looking at the returned value, calling clk_round_rate() still, or just doing nothing) depends on how the driver will behaves, we actually are punching a hole through the abstraction provided by the clock framework. In order to avoid any abstraction violation, let's create a bunch of accessors that will return the current minimum and maximum for a given clock. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:14 UTC
798d7a6 Maxime Ripard 16 March 2022, 08:41:49 UTC Revert "clk: Introduce a clock request API" This reverts commit 23fbabe348436e250deca7c5f2fd0caf620af174. 24 April 2022, 18:58:14 UTC
b3929bc Maxime Ripard 16 March 2022, 08:41:48 UTC Revert "clk: requests: Ignore if the pointer is null" This reverts commit f078b2c9b1901f6297154788ac07f56547ddcb7a. 24 April 2022, 18:58:13 UTC
cac7096 Maxime Ripard 16 March 2022, 08:41:44 UTC Revert "clk: requests: Dereference the request pointer after the check" This reverts commit 12917adc036f82c4fda3b80a068d0d51c947d6a6. 24 April 2022, 18:58:13 UTC
251b44f Maxime Ripard 16 March 2022, 08:58:31 UTC Revert "rpivid: Switch to new clock api" This reverts commit ec7556e20c2c29c3df9493248a1a4d60ed20ae38. 24 April 2022, 18:58:12 UTC
1a40b2e Maxime Ripard 16 March 2022, 08:53:03 UTC Revert "bcm2835-unicam: Switch to new clock api" This reverts commit 702228eb413876739f4fee8a9ec66b3e4e54efac. 24 April 2022, 18:58:11 UTC
3f6113f Maxime Ripard 16 March 2022, 08:52:34 UTC Revert "drm/vc4: hdmi: Convert to the new clock request API" This reverts commit 5dbb9357519a9479eacdda130713bf0dc44e069c. 24 April 2022, 18:58:11 UTC
ff11328 Maxime Ripard 16 March 2022, 08:51:44 UTC Revert "drm/vc4: Increase the core clock based on HVS load" This reverts commit 02c8543cc6940f8201e9beb601bd56421d911e83. 24 April 2022, 18:58:10 UTC
7272fed Maxime Ripard 16 March 2022, 08:51:32 UTC Revert "drm/vc4: kms: Move clock request to our HVS state" This reverts commit c65633a429b15f9d182a5bc7d6387fecbd5b7bb0. 24 April 2022, 18:58:09 UTC
83e5990 Maxime Ripard 17 January 2022, 16:36:23 UTC clk: bcm: rpi: Run some clocks at the minimum rate allowed The core clock and M2MC clocks are shared between some devices (Unicam controllers and the HVS, and the HDMI controllers, respectively) that will have various, varying, requirements depending on their current work load. Since those loads can require a fairly high clock rate in extreme conditions (up to ~600MHz), we can end up running those clocks at their maximum frequency even though we no longer require such a high rate. Fortunately, those devices don't require an exact rate but a minimum rate, and all the drivers are using clk_set_min_rate. Thus, we can just rely on the fact that the clk_request minimum (which is the aggregated minimum of all the clock users) is what we want at all times. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:09 UTC
7d87b82 Maxime Ripard 17 January 2022, 16:31:06 UTC clk: bcm: rpi: Set a default minimum rate The M2MC clock provides the state machine clock for both HDMI controllers. However, if no HDMI monitor is plugged in at boot, its clock rate will be left at 0 by the firmware and will make any register access end up in a CPU stall, even though the clock was enabled. We had some code in the HDMI controller to deal with this before, but it makes more sense to have it in the clock driver. Move it there. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:08 UTC
79c514b Maxime Ripard 17 January 2022, 16:19:30 UTC clk: bcm: rpi: Add variant structure We only export a bunch of firmware clocks, and some of them require special treatment. This has been do so far using some tests on the clock id in various places, but this is fairly hard to extend and doesn't scale very well. Since we'll need some more cases in the next patches, let's switch to a variant structure that defines the behaviour we need to have for a given clock. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:08 UTC
1c761a2 Maxime Ripard 05 April 2022, 13:20:27 UTC clk: Test the clock pointer in clk_hw_get_name() Unlike __clk_get_name(), clk_hw_get_name() doesn't test wether passed clk_hw pointer is NULL or not and dereferences it directly. This can then lead to NULL pointer dereference. Let's make sure the pointer isn't NULL before dereferencing it. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:07 UTC
aef474f Maxime Ripard 02 April 2022, 12:37:39 UTC clk: Zero the clk_rate_request structure In order to make sure we don't carry anything over from an already existing clk_rate_request pointer we would pass to clk_core_init_rate_req(), let's zero the entire structure before initializing it. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:06 UTC
8725d4b Maxime Ripard 02 April 2022, 12:36:59 UTC clk: Stop forwarding clk_rate_requests to the parent If the clock cannot modify its rate and has CLK_SET_RATE_PARENT, clk_mux_determine_rate_flags() and clk_core_round_rate_nolock() will call clk_core_round_rate_nolock() with its parent clock but use the request of the child node either directly (clk_core_round_rate_nolock()) or by copying it (clk_mux_determine_rate_flags()). Both cases are problematic since the parent will now have a request with the best parent fields of the child (so pointing to itself) and the boundaries of the child as well. clk_core_round_rate_nolock() is even worse since we would directly modify the caller structure if the parent was ever to modify its own parent or its parent rate, then returning to the caller a best parent that isn't a parent of the clock we just called clk_determine_rate() onto. Let's create a new function that will create a new request to forward to the parent, clk_core_forward_rate_req() and update the relevant call sites to that new function. Let's also add a test to make sure we avoid regressions there. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:05 UTC
293b7e9 Maxime Ripard 07 April 2022, 12:11:37 UTC clk: Introduce clk_core_has_parent() We will need to know if a clk_core pointer has a given parent in other functions, so let's create a clk_core_has_parent() function that clk_has_parent() will call into. For good measure, let's add some unit tests as well to make sure it works properly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:05 UTC
3951001 Maxime Ripard 02 April 2022, 11:52:55 UTC clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock clk_mux_determine_rate_flags() will call into __clk_determine_rate() with a clk_hw pointer, while it has access to the clk_core pointer already. This leads to back and forth between clk_hw and clk_core, while __clk_determine_rate will only call clk_core_round_rate_nolock() with the clk_core pointer it retrieved from the clk_hw. Let's simplify things a bit by calling into clk_core_round_rate_nolock directly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:04 UTC
43bc662 Maxime Ripard 02 April 2022, 12:06:53 UTC clk: Remove redundant clk_core_init_rate_req() call Since all the users of clk_core_round_rate_nolock() will now properly initialize, there's no need for it to initialize the request itself. This is even dangerous, as if the clock cannot change its rate by itself and has CLK_SET_RATE_PARENT, clk_core_round_rate_nolock() will call itself with the parent clock but the client clk_rate_request structure. We will then reinitialize the child request with the parent context (parent, boundaries, etc.), which is an issue if the parent ever changes its own parent or parent rate. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:03 UTC
6791372 Maxime Ripard 02 April 2022, 12:01:37 UTC clk: Add missing clk_core_init_rate_req calls Some callers of clk_core_round_rate_nolock() will initialize the clk_rate_request structure by hand, missing a few parameters that leads to inconsistencies in what drivers can expect from that structure. Let's use clk_core_init_rate_req() everywhere to make sure it's built in a consistent manner. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:03 UTC
6d698c4 Maxime Ripard 02 April 2022, 12:49:56 UTC clk: Introduce clk_hw_init_rate_request() Some drivers (at91, imx, qcom) use __clk_determine_rate directly, and thus will need to initialise a clk_rate_request structure. However, drivers don't have access to the function that the core uses to initialize that structure which could prove to be useful. Let's create a function for clock providers that will initialize a clk_rate_request for a given clk_hw pointer and a rate. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:02 UTC
3f4d5b7 Maxime Ripard 02 April 2022, 11:48:03 UTC clk: Change clk_core_init_rate_req prototype The expectation is that a clk_rate_request structure is supposed to be initialized using clk_core_init_rate_req(), yet the rate we want to request still needs to be set by hand. Let's just pass the rate as a function argument so that callers don't have any extra work to do. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:01 UTC
8796862 Maxime Ripard 02 April 2022, 11:45:05 UTC clk: Add our request boundaries in clk_core_init_rate_req The expectation is that a new clk_rate_request is initialized through a call to clk_core_init_rate_req(). However, at the moment it only fills the parent rate and clk_hw pointer, but omits the other fields such as the clock rate boundaries. Some users of that function will update them after calling it, but most don't. As we are passed the clk_core pointer, we have access to those boundaries in clk_core_init_rate_req() however, so let's just fill it there and remove it from the few callers that do it right. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:01 UTC
d09ea7a Maxime Ripard 01 April 2022, 13:27:09 UTC clk: Skip set_rate_range if our clock is orphan clk_set_rate_range will now force a clk_set_rate() call to core->req_rate. However, if our clock is orphan, req_rate will be 0 and we will thus end up calling a set_rate to 0 on potentially all that clock subtree. This can be fairly invasive and result in poor decisions. In such a case, let's just store the new range but bail out and skip the set_rate. When that clock is no longer orphan though, we should be enforcing the new range but we don't. Let's add a skipped test to make sure we don't forget about that corner case. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:58:00 UTC
f87f9a6 Maxime Ripard 01 April 2022, 13:26:46 UTC clk: Set req_rate on reparenting If a non-rate clock started by default with a parent that never registered, core->req_rate will be 0. The expectation is that whenever the parent will be registered, req_rate will be updated with the new value that has just been computed. However, if that clock is a mux, clk_set_parent() can also make that clock no longer orphan. In this case however, we never update req_rate. Let's make sure it's the case for the newly unorphan clock and all its children. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:59 UTC
9a2efba Maxime Ripard 01 April 2022, 09:09:29 UTC clk: Fix clk_get_parent() documentation The clk_get_parent() documentation in the header states that it will return a valid pointer, or an error pointer on failure. However, the documentation in the source file, and the code itself, will return also return NULL if there isn't any parent for that clock. Let's mention it. An orphan clock should return NULL too, so let's add a test for it. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:59 UTC
db3dfe0 Maxime Ripard 08 April 2022, 08:06:11 UTC clk: Take into account uncached clocks in clk_set_rate_range() clk_set_rate_range() will use the last requested rate for the clock when it calls into the driver set_rate hook. However, if CLK_GET_RATE_NOCACHE is set on that clock, the last requested rate might not be matching the current rate of the clock. In such a case, let's read out the rate from the hardware and use that in our set_rate instead. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:58 UTC
3b67ee7 Maxime Ripard 02 April 2022, 15:27:40 UTC clk: tests: Add some tests for orphan with multiple parents Let's leverage the dummy mux with multiple parents we have to create a mux whose default parent will never be registered, and thus will always be orphan by default. We can then create some tests to make sure that the clock API behaves properly in such a case, and that the transition to a non-orphan clock when we change the parent is done properly. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:58 UTC
04a42f7 Maxime Ripard 07 April 2022, 12:58:34 UTC clk: tests: Add tests for mux with multiple parents We'll need to test a few corner cases that occur when we have a mux clock whose default parent is missing. For now, let's create the context structure and the trivial ops, along with a test suite that just tests trivial things for now, without considering the orphan case. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:57 UTC
90fb271 Maxime Ripard 07 April 2022, 12:21:55 UTC clk: tests: Add tests for single parent mux We have a few tests for a mux with a single parent, testing the case where it used to be orphan. Let's leverage most of the code but register the clock properly to test a few trivial things. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:56 UTC
f2baee0 Maxime Ripard 08 April 2022, 07:54:39 UTC clk: tests: Add tests for uncached clock The clock framework supports clocks that can have their rate changed without the kernel knowing about it using the CLK_GET_RATE_NOCACHE flag. As its name suggests, this flag turns off the rate caching in the clock framework, reading out the rate from the hardware any time we need to read it. Let's add a couple of tests to make sure it works as intended. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:56 UTC
f7ce514 Maxime Ripard 01 April 2022, 12:53:49 UTC clk: tests: Add reference to the orphan mux bug report Some more context might be useful for unit-tests covering a previously reported bug, so let's add a link to the discussion for that bug. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:55 UTC
014ef84 Maxime Ripard 01 April 2022, 15:08:26 UTC clk: tests: Add test suites description We start to have a few test suites, and we'll add more, so it will get pretty confusing to figure out what is supposed to be tested in what suite. Let's add some comments to explain what setup they create, and what we should be testing in every suite. Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:54 UTC
5cda92b Maxime Ripard 25 March 2022, 16:11:44 UTC clk: Drop the rate range on clk_put() When clk_put() is called we don't make another clk_set_rate() call to re-evaluate the rate boundaries. This is unlike clk_set_rate_range() that evaluates the rate again each time it is called. However, clk_put() is essentially equivalent to clk_set_rate_range() since after clk_put() completes the consumer's boundaries shouldn't be enforced anymore. Let's add a call to clk_set_rate_range() in clk_put() to make sure those rate boundaries are dropped and the clock provider drivers can react. In order to be as non-intrusive as possible, we'll just make that call if the clock had non-default boundaries. Also add a few tests to make sure this case is covered. Fixes: c80ac50cbb37 ("clk: Always set the rate on clk_set_range_rate") Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx8mp Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> # exynos4210, meson g12b Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:54 UTC
76d88cf Maxime Ripard 25 March 2022, 10:27:28 UTC clk: test: Test clk_set_rate_range on orphan mux A bug recently affected the Tegra30 where calling clk_set_rate_range() on a clock would make it change its rate to the minimum. This was due to the clock in question being a mux that was orphan at registration, which lead to the clk_core req_rate being 0, and the clk_set_rate_range() function then calling clk_set_rate() with req_rate, effectively making that clock running at the minimum rate allowed, even though the initial rate was within that range. Make a test suite to create a mux initially orphan, and then make sure that if our clock rate was initially within a given range, then enforcing that range won't affect it. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:53 UTC
752217c Maxime Ripard 17 January 2022, 15:43:52 UTC clk: Add clk_drop_range In order to reset the range on a clock, we need to call clk_set_rate_range with a minimum of 0 and a maximum of ULONG_MAX. Since it's fairly inconvenient, let's introduce a clk_drop_range() function that will do just this. Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:53 UTC
80f87d6 Maxime Ripard 17 January 2022, 15:43:13 UTC clk: Always set the rate on clk_set_range_rate When we change a clock minimum or maximum using clk_set_rate_range(), clk_set_min_rate() or clk_set_max_rate(), the current code will only trigger a new rate change if the rate is outside of the new boundaries. However, a clock driver might want to always keep the clock rate to one of its boundary, for example the minimum to keep the power consumption as low as possible. Since they don't always get called though, clock providers don't have the opportunity to implement this behaviour. Let's trigger a clk_set_rate() on the previous requested rate every time clk_set_rate_range() is called. That way, providers that care about the new boundaries have a chance to adjust the rate, while providers that don't care about those new boundaries will return the same rate than before, which will be ignored by clk_set_rate() and won't result in a new rate change. Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:52 UTC
fe4d449 Maxime Ripard 17 January 2022, 15:38:10 UTC clk: Use clamp instead of open-coding our own The code in clk_set_rate_range() will, if the current rate is outside of the new range, force it to the minimum or maximum. Since it's running under the condition that the rate is either lower than the minimum, or higher than the maximum, this is equivalent to using clamp, while being less readable. Let's switch to using clamp instead. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:51 UTC
ee6f6ed Maxime Ripard 19 January 2022, 15:22:19 UTC clk: Introduce Kunit Tests for the framework Let's test various parts of the rate-related clock API with the kunit testing framework. Cc: kunit-dev@googlegroups.com Tested-by: Daniel Latypov <dlatypov@google.com> Suggested-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 24 April 2022, 18:57:51 UTC
502dcb9 Phil Elwell 19 April 2022, 19:21:26 UTC config: Enable the NFT_SYNPROXY module The NFT_SYNPROXY module is apparently useful for port scan protection, and at 11kB barely changes the size of the downloads. See: https://github.com/raspberrypi/linux/issues/4993 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 20 April 2022, 12:49:38 UTC
46eb204 Phil Elwell 19 April 2022, 16:12:34 UTC configs: (Re)Enable CONFIG_IR_TOY Somehow or other, CONFIG_IR_TOY=m got dropped from the standard Pi defconfigs around 5.13. Restore it. See: https://github.com/raspberrypi/linux/issues/4997 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 20 April 2022, 12:49:37 UTC
fffd642 Matthias Reichl 30 December 2021, 14:12:19 UTC drm/vc4: hdmi: Fix no video output on DVI monitors The drm edid parser doesn't signal RGB support on DVI monitors with old edid versions, leading to 8-bit RGB mode being rejected and no video on DVI monitors. As 8-bit RGB is mandatory on HDMI and DVI monitors anyways we can simply drop the RGB format check, aligning vc4 with other drivers. Signed-off-by: Matthias Reichl <hias@horus.com> 20 April 2022, 12:49:36 UTC
8096de7 Noralf Trønnes 13 April 2022, 17:28:35 UTC overlays: mipi-dbi-spi: width-mm and height-mm are mandatory There was a last minute change to the binding in commit 1ecc0c09f19f ("dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory"). This was done so userspace can calculate DPI. Update the overlay to ensure it will work with future kernels. The driver changes won't be backported to rpi-5.15. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> 19 April 2022, 12:06:56 UTC
0148df8 Dom Cobley 12 April 2022, 17:30:49 UTC config: Enable CONFIG_MODULE_COMPRESS_XZ See: https://github.com/raspberrypi/linux/issues/4966 Signed-off-by: Dom Cobley <popcornmix@gmail.com> 19 April 2022, 12:06:56 UTC
77789a0 Phil Elwell 13 April 2022, 12:50:30 UTC configs: bcm2711_defconfig: Enable KASLR Although KASLR is enabled in the old bcmrpi3_defconfig, it is omitted from bcm2711_defconfig. Correct that oversight. See: https://github.com/raspberrypi/linux/issues/4989 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 19 April 2022, 12:06:56 UTC
a31cabe Dom Cobley 30 March 2022, 16:49:31 UTC vc4_hdmi: Remove VC4_HDMI_SCHEDULER_CONTROL_VERT_ALWAYS_KEEPOUT This bit ensures data island packets are never generated when disallowed by HDCP. As no Pi boards support HDCP this is providing an unnecessary restriction Signed-off-by: Dom Cobley <popcornmix@gmail.com> 19 April 2022, 12:06:55 UTC
4ab15aa Matt Flax 11 April 2022, 16:28:07 UTC Add support for the AudioInjector.net bare i2s sound card Signed-off-by: Matt Flax <flatmax@flatmax.org> 19 April 2022, 12:06:55 UTC
a6e03d3 Dave Stevenson 10 June 2021, 16:42:47 UTC dtoverlays: Add overlay for Sony IMX258 image sensor Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
5273bfa Dave Stevenson 23 March 2022, 14:07:56 UTC defconfigs: Add IMX258 to the Pi defconfigs Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
99a32a9 Dave Stevenson 01 April 2022, 17:56:54 UTC media: i2c: imx258: Support faster pixel rate on binned modes With the binned modes, there is little point in faithfully reproducing the horizontal line length of 5352 pixels on the CSI2 bus, and the FIFO between the pixel array and MIPI serialiser allows us to remove that dependency. Allow the pixel array to run with the normal settings, with the MIPI serialiser at half the rate. This requires some additional information for the link frequency to pixel rate function that needs to be added to the configuration tables. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
a849d38 Dave Stevenson 01 April 2022, 17:54:12 UTC media: i2c: imx258: Set pixel_rate range to the same as the value With a read only control there is limited point in advertising a minimum and maximum for the control, so change to set the value, min, and max all to the selected pixel rate. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
3cf3c30 Dave Stevenson 31 March 2022, 16:12:12 UTC media: i2c: imx258: Issue reset before starting streaming Whilst not documented, register 0x0103 bit 0 is the soft reset for the sensor, so send it before trying to configure the sensor. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
a2405d1 Dave Stevenson 31 March 2022, 15:45:36 UTC media: i2c: imx258: Add support for long exposure modes The sensor has a register CIT_LSHIFT which extends the exposure and frame times by the specified power of 2 for longer exposure times. Add support for this by configuring this register via V4L2_CID_VBLANK and extending the V4L2_CID_EXPOSURE range accordingly. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
566ccf2 Dave Stevenson 31 March 2022, 14:39:40 UTC media: i2c: imx258: Correct max FRM_LENGTH_LINES value The data sheet states that the maximum value for registers 0x0340/0x0341 FRM_LENGTH_LINES is 65525(decimal), not the 0xFFFF defined in this driver. Correct this limit. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
3c30679 Dave Stevenson 31 March 2022, 14:33:59 UTC media: i2c: imx258: Allow configuration of clock lane behaviour The sensor supports the clock lane either remaining in HS mode during frame blanking, or dropping to LP11. Add configuration of the mode via V4L2_MBUS_CSI2_CONTINUOUS_CLOCK. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
a6cd9a7 Dave Stevenson 23 March 2022, 15:48:49 UTC media: i2c: imx258: Add get_selection for pixel array information Libcamera requires the cropping information for each mode, so add this information to the driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
f3fb2ff Dave Stevenson 16 June 2021, 16:19:17 UTC media: i2c: imx258: Follow normal V4L2 behaviours for clipping exposure V4L2 sensor drivers are expected are expected to clip the supported exposure range based on the VBLANK configured. IMX258 wasn't doing that as register 0x350 (FRM_LENGTH_CTL) switches it to a mode where frame length tracks coarse exposure time. Disable this mode and clip the range for V4L2_CID_EXPOSURE appropriately based on V4L2_CID_VBLANK. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
88d964f Dave Stevenson 16 June 2021, 15:27:06 UTC media: i2c: imx258: Add support for running on 2 CSI data lanes Extends the driver to also support 2 data lanes. Frame rates are obviously more restricted on 2 lanes, but some hardware simply hasn't wired more up. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:55 UTC
fe82488 Dave Stevenson 16 June 2021, 12:08:00 UTC media: i2c: imx258: Add support for 24MHz clock There's no reason why the clock must be 19.2MHz and nothing else (indeed this isn't even a frequency listed in the datasheet), so add support for 24MHz as well. The PLL settings result in slightly different link frequencies, so parameterise those. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
0cbe492 Dave Stevenson 15 June 2021, 18:01:46 UTC media: i2c: imx258: Register the ctrls from fwnode properties Use v4l2_ctrl_new_fwnode_properties to register the standard fwnode properties for the driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
5b53dee Dave Stevenson 15 June 2021, 17:56:33 UTC media: i2c: imx258: Make V4L2_CID_VBLANK configurable. The values and ranges of V4L2_CID_VBLANK are all computed, so there is no reason for it to be a read only control. Remove the register values from the mode lists, add the handler, and remove the read only flag. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
46a6f4b Dave Stevenson 15 June 2021, 17:45:40 UTC media: i2c: imx258: Add regulator control The device tree bindings define the relevant regulators for the sensor, so update the driver to request the regulators and control them at the appropriate times. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
56e81ba Dave Stevenson 15 June 2021, 17:38:46 UTC media: i2c: imx258: Remove redundant I2C writes. Registers 0x0202 and 0x0203 are written via the control handler for V4L2_CID_EXPOSURE, so are not needed from the mode lists. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
0897492 Dave Stevenson 15 June 2021, 17:29:52 UTC media: i2c: imx258: Implement HFLIP and VFLIP controls. The sensor supports H & V flips, so implement the relevant controls. Note that the Bayer order changes with these flips, therefore they set the V4L2_CTRL_FLAG_MODIFY_LAYOUT property. As we now support flips, remove the restriction of the sensor only probing if rotated 180 degrees, but do take that value and initialise VFLIP and HFLIP based on it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
5135b70 Dave Stevenson 30 March 2022, 13:55:01 UTC media: i2c: imx258: Disable digital cropping on binned modes The binned modes set DIG_CROP_X_OFFSET and DIG_CROP_IMAGE_WIDTH to less than the full image, even though the image being captured is meant to be a scaled version of the full array size. Reduce X_OFFSET to 0, and increase IMAGE_WIDTH to the full array. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
3c0fc57 Dave Stevenson 15 June 2021, 17:34:38 UTC media: i2c: imx258: Make image geometry meet sensor requirements The output image is defined as being 4208x3118 pixels in size. Y_ADD_STA register was set to 0, and Y_ADD_END to 3118, giving 3119 lines total. The datasheet lists a requirement for Y_ADD_STA to be a multiple of a power of 2 depending on binning/scaling mode (2 for full pixel, 4 for x2-bin/scale, 8 for (x2-bin)+(x2-subsample) or x4-bin, or 16 for (x4-bin)+(x2-subsample)). (Y_ADD_END – Y_ADD_STA + 1) also has to be a similar power of 2. The current configuration for the full res modes breaks that second requirement, and we can't increase Y_ADD_STA to 1 to retain exactly the same field of view as that then breaks the first requirement. For the binned modes, they are worse off as 3118 is not a multiple of 4. Increase the main mode to 4208x3120 so that it is the same FOV as the binned modes, with Y_ADD_STA at 0. Fix Y_ADD_STA and Y_ADD_END for the binned modes so that they meet the sensor requirements. This does change the Bayer order as the default configuration is for H&V flips to be enabled, so readout is from Y_STA_END to Y_ADD_STA, and this patch has changed Y_STA_END. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
ce7de91 Dave Stevenson 15 June 2021, 17:18:42 UTC media: i2c: imx258: Remove unused defines The IMX258_FLL_* defines are unused. Remove them. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:54 UTC
8859875 Dom Cobley 06 April 2022, 19:35:13 UTC drm/vc4_hdmi: Force modeset when bpc changes See: https://forum.libreelec.tv/thread/25427-le-10-0-2-on-rpi4-not-playing-files-that-10-0-1-had-no-problems-with/ The issue is that kodi changes hdmi mode to 3840x2160@24 initially with "max bcp=8" After decoding the first frame it changes property to "max bpc=12". Now vc4_hdmi_encoder_compute_config chooses vc4_state->output_bpc = 12 with output_format=VC4_HDMI_OUTPUT_RGB This requires scrambling as clock > 300MHz (and we have hdmi_enable_4kp60=1). vc4_hdmi_encoder_atomic_mode_set (without this PR's assignment to mode_changed) is currenly not called so we don't assign: vc4_hdmi->output_bpc = vc4_state->output_bpc which means vc4_hdmi_enable_scrambling never enables scrambling (as vc4_hdmi->output_bpc is still 8). But we do set the pixel clock in phy_init() to a clock frequency that requires scrambling. Signed-off-by: Dom Cobley <popcornmix@gmail.com> 19 April 2022, 12:06:54 UTC
7c826ca Maxime Ripard 13 December 2021, 12:47:51 UTC drm/edid: Don't clear YUV422 if using deep color The current code, when parsing the EDID Deep Color depths, that the YUV422 cannot be used, referring to the HDMI 1.3 Specification. This specification, in its section 6.2.4, indeed states: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is not permitted for any Deep Color mode. This indeed can be interpreted like the code does, but the HDMI 1.4 specification further clarifies that statement in its section 6.2.4: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is also 36-bit mode but does not require the further use of the Deep Color modes described in section 6.5.2 and 6.5.3. This means that, even though YUV422 can be used with 12 bit per color, it shouldn't be treated as a deep color mode. This deviates from the interpretation of the code and comment, so let's fix those. Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> 19 April 2022, 12:06:54 UTC
7826fa1 Maxime Ripard 31 March 2022, 13:27:43 UTC Revert "drm/vc4: hvs: Defer dlist slots deallocation" This reverts commit e99a1b69da07ee3b89a6b8005b854e6c04bfb450. 19 April 2022, 12:06:54 UTC
953ed8f Daniel Vetter 23 October 2020, 12:39:23 UTC drm/atomic-helpers: remove legacy_cursor_update hacks The stuff never really worked, and leads to lots of fun because it out-of-order frees atomic states. Which upsets KASAN, among other things. For async updates we now have a more solid solution with the ->atomic_async_check and ->atomic_async_commit hooks. Support for that for msm and vc4 landed. nouveau and i915 have their own commit routines, doing something similar. For everyone else it's probably better to remove the use-after-free bug, and encourage folks to use the async support instead. The affected drivers which register a legacy cursor plane and don't either use the new async stuff or their own commit routine are: amdgpu, atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. Inspired by an amdgpu bug report. v2: Drop RFC, I think with amdgpu converted over to use atomic_async_check/commit done in commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Date: Wed Dec 5 14:59:07 2018 -0500 drm/amd/display: Add fast path for cursor plane updates we don't have any driver anymore where we have userspace expecting solid legacy cursor support _and_ they are using the atomic helpers in their fully glory. So we can retire this. v3: Paper over msm and i915 regression. The complete_all is the only thing missing afaict. v4: Rebased on recent kernel, added extra link for vc4 bug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199425 Link: https://lore.kernel.org/all/20220221134155.125447-9-maxime@cerno.tech/ Cc: mikita.lipski@amd.com Cc: Michel Dänzer <michel@daenzer.net> Cc: harry.wentland@amd.com Cc: Rob Clark <robdclark@gmail.com> Cc: "Kazlauskas, Nicholas" <nicholas.kazlauskas@amd.com> Tested-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> 19 April 2022, 12:06:53 UTC
c919d04 Phil Elwell 03 April 2022, 14:27:46 UTC configs: Re-enable all GSPCA camera modules The GSPCA camera modules were lost due to change in a default value - when has that happened before? See: https://github.com/raspberrypi/linux/issues/4977 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 19 April 2022, 12:06:53 UTC
d6b1207 Dave Stevenson 01 April 2022, 10:31:38 UTC drm/vc4: Force trigger of dlist update on margins change When the margins are changed, the dlist needs to be regenerated with the changed updated dest regions for each of the planes. Setting the zpos_changed flag is sufficient to trigger that without doing a full modeset, therefore set it should the margins be changed. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:53 UTC
9a9fbaf Phil Elwell 31 March 2022, 16:55:51 UTC brcmfmac: Restore ISO3166 and 0 rev as a fallback Commit b0b524f079a2 ("brcmfmac: use ISO3166 country code and 0 rev as fallback") was a welcome addition for Raspberry Pi as it replaced an equivalent bit of downstream code. Commit 151a7c12c4fc reverted it because it broke BCM4359/9 devices. This is a renamed reversion of the reversion. See: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/217 Signed-off-by: Phil Elwell <phil@raspberrypi.com> 19 April 2022, 12:06:53 UTC
b61ff9c Dave Stevenson 31 March 2022, 11:05:04 UTC drm/panel: panel-ilitek9881c: Add prepare_upstream_first flag The panel sends MIPI DCS commands during prepare and is expecting the bus to remain in LP-11 state in-between. Set the prepare_upstream_first flag so that the upstream DSI host is prepared / pre_enabled first, and therefore the bus is in a defined state. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:53 UTC
9238175 Dave Stevenson 31 March 2022, 11:03:36 UTC drm/panel: ilitek-ili9881c: Clean up on mipi_dsi_attach failure mipi_dsi_attach is allowed to fail, and currently the probe code doesn't clean up (mainly drm_panel_remove) if this happens. Add cleanup code on failure. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:53 UTC
863d751 Ben Avison 30 March 2022, 10:43:25 UTC ARM: dts: Enable PMU on Cortex-A72 in AArch32 state There is no specific AArch32 driver for the Cortex-A72 PMU, but the Cortex-A7 one works and is much better than no PMU driver at all. Signed-off-by: Ben Avison <bavison@riscosopen.org> 19 April 2022, 12:06:53 UTC
17b7559 Phil Elwell 30 March 2022, 08:48:41 UTC pinctrl: bcm2835: Only return non-GPIOs to inputs Allowing GPIO state to persist allows the use of gpioset to control GPIO levels without having to use the --mode=wait feature. Signed-off-by: Phil Elwell <phil@raspberrypi.com> 19 April 2022, 12:06:53 UTC
6ef3aca David Plowman 29 March 2022, 15:10:06 UTC mm,page_alloc,cma: introduce a customisable threshold for allocating pages in cma On some platforms the cma area can be half the entire system memory, meaning that allocations start happening in the cma area immediately. This leads to fragmentation and subsequent fatal cma_alloc failures. We introduce an "alloc_in_cma_threshold" parameter which requires that this many sixteenths of the free pages must be in cma before it will try to use them. By default this is set to 12, but the previous behaviour can be restored by setting it to 8 on startup. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> 19 April 2022, 12:06:53 UTC
8a19194 Dave Stevenson 28 March 2022, 10:52:48 UTC bcm2835-codec: Return empty buffers to the VPU instead of queueing to vbuf2 The encoder can skip frames totally should rate control overshoot the target bitrate too far. In this situation it generates an output buffer of length 0. V4L2 treats a buffer of length 0 as an end of stream flag, which is not appropriate in this case, therefore we can not return that buffer to the client. The driver was returning the buffer to videobuf2 in the QUEUED state, however that buffer was then not dequeued again, so the number of buffers was reduced each time this happened. In the pathological case of using GStreamer's videotestsrc in mode 1 for noise, this happens sufficiently frequently to totally stall the pipeline. If the port is still enabled then return the buffer straight back to the VPU rather than to videobuf2. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> 19 April 2022, 12:06:53 UTC
03a8a92 Noralf Trønnes 27 March 2022, 16:54:17 UTC overlays/rpi-display: Add support for DRM driver Add a "drm" parameter that enables use of the drm/mi0283qt driver instead of fbtft/fb_ili9341. Also add a "backlight-pwm" parameter that can be used with the "drm" parameter. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> 19 April 2022, 12:06:53 UTC
5257571 Noralf Trønnes 26 March 2022, 17:59:27 UTC Revert "update rpi-display-overlay.dts pins for 5.10+" This reverts commit 97d1b136be6dbc81316259690fd15b4110a3606f. The fbtft backlight problem was fixed in 5.15.6 so this workaround has to be reverted to make backlight work again. Ref: https://github.com/notro/fbtft/issues/571 Signed-off-by: Noralf Trønnes <noralf@tronnes.org> 19 April 2022, 12:06:53 UTC
5c09bce Matt Flax 27 March 2022, 11:42:47 UTC audioinjector.net: stereo and zero, use dev_err_probe, report success Use dev_err_probe to follow best practice, and leave a message in the kernel log indicate the driver was started successfully. 19 April 2022, 12:06:52 UTC
8e0ddd2 Noralf Trønnes 07 March 2022, 16:05:49 UTC overlays: Add overlay for MIPI DBI displays Add an overlay that can be used with all displays that have a MIPI DBI compatible controller (pixels over SPI). Signed-off-by: Noralf Trønnes <noralf@tronnes.org> 19 April 2022, 12:06:52 UTC
219c021 Noralf Trønnes 02 March 2022, 17:17:44 UTC configs: Add MIPI DBI display driver Enable DRM_PANEL_MIPI_DBI as a module. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> 19 April 2022, 12:06:52 UTC
7386334 Noralf Trønnes 27 February 2022, 12:47:13 UTC drm/tiny: Add MIPI DBI compatible SPI driver commit 0e65e2e upstream. Add a driver that will work with most MIPI DBI compatible SPI panels. This avoids adding a driver for every new MIPI DBI compatible controller that is to be used by Linux. The 'compatible' Device Tree property with a '.bin' suffix will be used to load a firmware file that contains the controller configuration. Example (driver will load sainsmart18.bin): display@0 { compatible = "sainsmart18", "panel-mipi-dbi-spi"; ... }; v5: - kconfig: s/DRM_KMS_CMA_HELPER/DRM_GEM_CMA_HELPER/ (Sam) - kconfig: Add select VIDEOMODE_HELPERS (Sam) - kconfig: Add wiki url in the description (Sam) - Split out and use of_get_drm_panel_display_mode()(Sam) - Only use the first compatible to look for a firmware file since the binding mandates 2 compatibles. - Make having a firmware file mandatory so we can print an error message if it's missing to improve the user experience. It's very unlikely that a controller doesn't need to be initialized and if it doesn't, it's possible to have a firmware file containing only a DCS NOP. v4: - Move driver to drm/tiny where the other drivers of its kind are located. The driver module will not be shared with a future DPI driver after all. v3: - Move properties to DT (Maxime) - The MIPI DPI spec has optional support for DPI where the controller is configured over DBI. Rework the command functions so they can be moved to drm_mipi_dbi and shared with a future panel-mipi-dpi-spi driver v2: - Drop model property and use compatible instead (Rob) - Add wiki entry in MAINTAINERS Acked-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220227124713.39766-6-noralf@tronnes.org 19 April 2022, 12:06:52 UTC
d5770bb Noralf Trønnes 27 February 2022, 12:47:12 UTC drm/mipi-dbi: Add driver_private member to struct mipi_dbi_dev commit 1e7e8e1 upstream. devm_drm_dev_alloc() can't allocate structures that embed a structure which then again embeds drm_device. Workaround this by adding a driver_private pointer to struct mipi_dbi_dev which the driver can use for its additional state. v3: - Add documentation Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220227124713.39766-5-noralf@tronnes.org 19 April 2022, 12:06:52 UTC
7e68c37 Noralf Trønnes 27 February 2022, 12:47:11 UTC drm/modes: Add of_get_drm_panel_display_mode() commit 95ae342 upstream. Add a function to get a drm_display_mode from a panel-timing device tree subnode. Suggested-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220227124713.39766-4-noralf@tronnes.org 19 April 2022, 12:06:52 UTC
a2af830 Noralf Trønnes 27 February 2022, 12:47:09 UTC dt-bindings: display: add bindings for MIPI DBI compatible SPI panels commit 2f3468b upstream. Add binding for MIPI DBI compatible SPI panels. v6: - Fix indentation (Rob) v5: - Add sainsmart18 to compatible items (Rob) - Expand write-only description (Sam) v4: - There should only be two compatible (Maxime) - s/panel-dbi-spi/panel-mipi-dbi-spi/in compatible v3: - Move properties to Device Tree (Maxime) - Use contains for compatible (Maxime) - Add backlight property to example - Flesh out description v2: - Fix path for panel-common.yaml - Use unevaluatedProperties - Drop properties which are in the allOf section - Drop model property (Rob) Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220227124713.39766-2-noralf@tronnes.org 19 April 2022, 12:06:52 UTC
back to top