next: clang: x86_64: /intel_display.c:6012:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
Linux next-20230523 and next-20230524 the x86_64 and i386 builds failed with clang. Reported-by: Linux Kernel Functional Testing make --silent --keep-going \ --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=x86_64 \ SRCARCH=x86 CROSS_COMPILE=x86_64-linux-gnu- \ 'HOSTCC=sccache clang' 'CC=sccache clang' \ LLVM=1 LLVM_IAS=1 drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] case I915_FORMAT_MOD_X_TILED: ^ drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 'break;' to avoid fall-through case I915_FORMAT_MOD_X_TILED: ^ break; 1 error generated. log: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230524/testrun/17171777/suite/build/test/clang-lkftconfig/log - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230524/testrun/17171777/suite/build/test/clang-lkftconfig/history/ -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH net-next v4 2/6] dt-bindings: net: Brcm ASP 2.0 Ethernet controller
On Wed, May 24, 2023 at 07:51:07AM +0100, Conor Dooley wrote: > Hey Justin, > On Tue, May 23, 2023 at 04:27:12PM -0700, Justin Chen wrote: > > On Tue, May 23, 2023 at 3:55 PM Conor Dooley wrote: > > > On Tue, May 23, 2023 at 02:53:43PM -0700, Justin Chen wrote: > > > > > > > + compatible: > > > > +enum: > > > > + - brcm,asp-v2.0 > > > > + - brcm,bcm72165-asp > > > > + - brcm,asp-v2.1 > > > > + - brcm,bcm74165-asp > > > > > > > +compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0"; > > > > > > You can't do this, as Rob's bot has pointed out. Please test the > > > bindings :( You need one of these type of constructs: > > > > > > compatible: > > > oneOf: > > > - items: > > > - const: brcm,bcm72165-asp > > > - const: brcm,asp-v2.0 > > > - items: > > > - const: brcm,bcm74165-asp > > > - const: brcm,asp-v2.1 > > > > > > Although, given either you or Florian said there are likely to be > > > multiple parts, going for an enum, rather than const for the brcm,bcm.. > > > entry will prevent some churn. Up to you. > > > > > Urg so close. Thought it was a trivial change, so didn't bother > > retesting the binding. I think I have it right now... > > > > compatible: > > oneOf: > > - items: > > - enum: > > - brcm,bcm72165-asp > > - brcm,bcm74165-asp > > - enum: > > - brcm,asp-v2.0 > > - brcm,asp-v2.1 > > > > Something like this look good? > > I am still caffeine-less, but this implies that both of > "brcm,bcm72165-asp", "brcm,asp-v2.0" > _and_ > "brcm,bcm72165-asp", "brcm,asp-v2.1" > are. I suspect that that is not the case, unless "brcm,asp-v2.0" is a I a word. s/are/are valid/ > valid fallback for "brcm,asp-v2.1"? > The oneOf: also becomes redundant since you only have one items:. > > > Will submit a v5 tomorrow. > > BTW, when you do, could you use the address listed in MAINTAINERS rather > than the one you used for this version? > > Cheers, > Conor. signature.asc Description: PGP signature
[v2 0/4] Support Starry-himax83102-j02 and Starry-ili9882t TDDI MIPI-DSI panel
Compare V1:Add compatible for Starry himax83102-j02 and Starry-ili9882t in dt-bindings. Cong Yang (4): drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel dt-bindings: display: panel: Add compatible for Starry himax83102-j02 drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel dt-bindings: display: panel: Add compatible for Starry ili9882t .../display/panel/boe,tv101wum-nl6.yaml | 4 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 471 ++ 2 files changed, 475 insertions(+) -- 2.25.1
[v2 1/4] drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
The Starry-himax83102-j02 is a 10.51" WUXGA TFT panel. which fits in nicely
with the existing panel-boe-tv101wum-nl6 driver. From the datasheet[1], MIPI
needs to keep the LP11 state before the lcm_reset pin is pulled high, so
increase lp11_before_reset flag.
[1]: https://github.com/HimaxSoftware/Doc/tree/main/Himax_Chipset_Power_Sequence
Signed-off-by: Cong Yang
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 100 ++
1 file changed, 100 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index f5a6046f1d19..5c8ec263e11f 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -76,6 +76,75 @@ struct panel_init_cmd {
.len = sizeof((char[]){__VA_ARGS__}), \
.data = (char[]){__VA_ARGS__} }
+static const struct panel_init_cmd starry_himax83102_j02_init_cmd[] = {
+ _INIT_DCS_CMD(0xB9, 0x83, 0x10, 0x21, 0x55, 0x00),
+ _INIT_DCS_CMD(0xB1, 0x2C, 0xB5, 0xB5, 0x31, 0xF1, 0x31, 0xD7, 0x2F,
0x36, 0x36, 0x36, 0x36, 0x1A, 0x8B, 0x11,
+ 0x65, 0x00, 0x88, 0xFA, 0xFF, 0xFF, 0x8F, 0xFF, 0x08, 0x74,
0x33),
+ _INIT_DCS_CMD(0xB2, 0x00, 0x47, 0xB0, 0x80, 0x00, 0x12, 0x72, 0x3C,
0xA3, 0x03, 0x03, 0x00, 0x00, 0x88, 0xF5),
+ _INIT_DCS_CMD(0xB4, 0x76, 0x76, 0x76, 0x76, 0x76, 0x76, 0x63, 0x5C,
0x63, 0x5C, 0x01, 0x9E),
+ _INIT_DCS_CMD(0xE9, 0xCD),
+ _INIT_DCS_CMD(0xBA, 0x84),
+ _INIT_DCS_CMD(0xE9, 0x3F),
+ _INIT_DCS_CMD(0xBC, 0x1B, 0x04),
+ _INIT_DCS_CMD(0xBE, 0x20),
+ _INIT_DCS_CMD(0xBF, 0xFC, 0xC4),
+ _INIT_DCS_CMD(0xC0, 0x36, 0x36, 0x22, 0x11, 0x22, 0xA0, 0x61, 0x08,
0xF5, 0x03),
+ _INIT_DCS_CMD(0xE9, 0xCC),
+ _INIT_DCS_CMD(0xC7, 0x80),
+ _INIT_DCS_CMD(0xE9, 0x3F),
+ _INIT_DCS_CMD(0xE9, 0xC6),
+ _INIT_DCS_CMD(0xC8, 0x97),
+ _INIT_DCS_CMD(0xE9, 0x3F),
+ _INIT_DCS_CMD(0xC9, 0x00, 0x1E, 0x13, 0x88, 0x01),
+ _INIT_DCS_CMD(0xCB, 0x08, 0x13, 0x07, 0x00, 0x0F, 0x33),
+ _INIT_DCS_CMD(0xCC, 0x02),
+ _INIT_DCS_CMD(0xE9, 0xC4),
+ _INIT_DCS_CMD(0xD0, 0x03),
+ _INIT_DCS_CMD(0xE9, 0x3F),
+ _INIT_DCS_CMD(0xD1, 0x37, 0x06, 0x00, 0x02, 0x04, 0x0C, 0xFF),
+ _INIT_DCS_CMD(0xD2, 0x1F, 0x11, 0x1F),
+ _INIT_DCS_CMD(0xD3, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08, 0x00,
0x08, 0x37, 0x47, 0x34, 0x3B, 0x12, 0x12, 0x03,
+ 0x03, 0x32, 0x10, 0x10, 0x00, 0x10, 0x32, 0x10, 0x08, 0x00,
0x08, 0x32, 0x17, 0x94, 0x07, 0x94, 0x00, 0x00),
+ _INIT_DCS_CMD(0xD5, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18, 0x18, 0x19, 0x19, 0x40, 0x40, 0x1A, 0x1A,
+ 0x1B, 0x1B, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x20, 0x21, 0x28, 0x29, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18, 0x18, 0x18, 0x18, 0x18),
+ _INIT_DCS_CMD(0xD6, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18, 0x18, 0x40, 0x40, 0x19, 0x19, 0x1A, 0x1A,
+ 0x1B, 0x1B, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01, 0x00,
0x29, 0x28, 0x21, 0x20, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18, 0x18, 0x18, 0x18, 0x18),
+ _INIT_DCS_CMD(0xD8, 0xAA, 0xBA, 0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA,
0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA, 0xEA, 0xAA,
+ 0xAA, 0xA0, 0xAA, 0xBA, 0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA,
0xEA, 0xAA, 0xAA, 0xA0, 0xAA, 0xBA, 0xEA, 0xAA, 0xAA, 0xA0),
+ _INIT_DCS_CMD(0xE0, 0x00, 0x09, 0x14, 0x1E, 0x26, 0x48, 0x61, 0x67,
0x6C, 0x67, 0x7D, 0x7F, 0x80, 0x8B, 0x87, 0x8F, 0x98, 0xAB,
+ 0xAB, 0x55, 0x5C, 0x68, 0x73, 0x00, 0x09, 0x14, 0x1E, 0x26,
0x48, 0x61, 0x67, 0x6C, 0x67, 0x7D, 0x7F, 0x80, 0x8B, 0x87, 0x8F, 0x98, 0xAB,
0xAB, 0x55, 0x5C, 0x68, 0x73),
+ _INIT_DCS_CMD(0xE7, 0x0E, 0x10, 0x10, 0x21, 0x2B, 0x9A, 0x02, 0x54,
0x9A, 0x14, 0x14, 0x00, 0x00, 0x00, 0x00, 0x12, 0x05, 0x02, 0x02, 0x10),
+ _INIT_DCS_CMD(0xBD, 0x01),
+ _INIT_DCS_CMD(0xB1, 0x01, 0xBF, 0x11),
+ _INIT_DCS_CMD(0xCB, 0x86),
+ _INIT_DCS_CMD(0xD2, 0x3C, 0xFA),
+ _INIT_DCS_CMD(0xE9, 0xC5),
+ _INIT_DCS_CMD(0xD3, 0x00, 0x00, 0x00, 0x00, 0x80, 0x0C, 0x01),
+ _INIT_DCS_CMD(0xE9, 0x3F),
+ _INIT_DCS_CMD(0xE7, 0x02, 0x00, 0x28, 0x01, 0x7E, 0x0F, 0x7E, 0x10,
0xA0, 0x00, 0x00, 0x20, 0x40, 0x50, 0x40),
+ _INIT_DCS_CMD(0xBD, 0x02),
+ _INIT_DCS_CMD(0xD8, 0xFF, 0xFF, 0xBF, 0xFE, 0xAA, 0xA0, 0xFF, 0xFF,
0xBF, 0xFE, 0xAA, 0xA0),
+ _INIT_DCS_CMD(0xE7, 0xFE, 0x04, 0xFE, 0x04, 0xFE, 0x04, 0x03, 0x03,
0x03, 0x26, 0x00, 0x26, 0x81, 0x02, 0x40, 0x00, 0x20, 0x9E, 0x04, 0x03, 0x02,
0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00),
+ _INIT_DCS_CMD(0xBD, 0x03),
+ _INIT_DCS_CMD(0xE9, 0xC6),
+ _INIT_DCS_CMD(0xB4, 0x03, 0xFF, 0xF8),
+ _INIT_DCS_CMD(0xE9, 0x3F),
+ _INIT_DCS_CMD(0xD8, 0x00, 0x2A, 0xAA, 0xA8, 0x00, 0x00, 0x00, 0x2A,
0xAA, 0xA8, 0x00, 0x00, 0x00, 0x3F, 0xFF, 0xFC, 0x00, 0x00, 0x00, 0x3F, 0
[v2 2/4] dt-bindings: display: panel: Add compatible for Starry himax83102-j02
The STARRY himax83102-j02 is a 10.51" WUXGA TFT LCD panel, which fits in nicely with the existing panel-boe-tv101wum-nl6 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index aed55608ebf6..28a7beeb8f92 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -32,6 +32,8 @@ properties: - innolux,hj110iz-01a # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel - starry,2081101qfh032011-53g +# STARRY himax83102-j02 10.51" WUXGA TFT LCD panel + - starry,himax83102-j02 reg: description: the virtual channel number of a DSI peripheral -- 2.25.1
[v2 3/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with
the existing panel-boe-tv101wum-nl6 driver. From the datasheet,MIPI need
to keep the LP11 state before the lcm_reset pin is pulled high. So add
lp11_before_reset flag.
Signed-off-by: Cong Yang
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 ++
1 file changed, 371 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 5c8ec263e11f..896c8f4f1278 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -145,6 +145,346 @@ static const struct panel_init_cmd
starry_himax83102_j02_init_cmd[] = {
{},
};
+static const struct panel_init_cmd starry_ili9882t_init_cmd[] = {
+ _INIT_DELAY_CMD(5),
+ _INIT_DCS_CMD(0xFF, 0x98, 0x82, 0x01),
+ _INIT_DCS_CMD(0x00, 0x42),
+ _INIT_DCS_CMD(0x01, 0x11),
+ _INIT_DCS_CMD(0x02, 0x00),
+ _INIT_DCS_CMD(0x03, 0x00),
+
+ _INIT_DCS_CMD(0x04, 0x01),
+ _INIT_DCS_CMD(0x05, 0x11),
+ _INIT_DCS_CMD(0x06, 0x00),
+ _INIT_DCS_CMD(0x07, 0x00),
+
+ _INIT_DCS_CMD(0x08, 0x80),
+ _INIT_DCS_CMD(0x09, 0x81),
+ _INIT_DCS_CMD(0x0A, 0x71),
+ _INIT_DCS_CMD(0x0B, 0x00),
+
+ _INIT_DCS_CMD(0x0C, 0x00),
+ _INIT_DCS_CMD(0x0E, 0x1A),
+
+ _INIT_DCS_CMD(0x24, 0x00),
+ _INIT_DCS_CMD(0x25, 0x00),
+ _INIT_DCS_CMD(0x26, 0x00),
+ _INIT_DCS_CMD(0x27, 0x00),
+
+ _INIT_DCS_CMD(0x2C, 0xD4),
+ _INIT_DCS_CMD(0xB9, 0x40),
+
+ _INIT_DCS_CMD(0xB0, 0x11),
+
+ _INIT_DCS_CMD(0xE6, 0x32),
+ _INIT_DCS_CMD(0xD1, 0x30),
+
+ _INIT_DCS_CMD(0xD6, 0x55),
+
+ _INIT_DCS_CMD(0xD0, 0x01),
+ _INIT_DCS_CMD(0xE3, 0x93),
+ _INIT_DCS_CMD(0xE4, 0x00),
+ _INIT_DCS_CMD(0xE5, 0x80),
+
+ _INIT_DCS_CMD(0x31, 0x07),
+ _INIT_DCS_CMD(0x32, 0x07),
+ _INIT_DCS_CMD(0x33, 0x07),
+ _INIT_DCS_CMD(0x34, 0x07),
+ _INIT_DCS_CMD(0x35, 0x07),
+ _INIT_DCS_CMD(0x36, 0x01),
+ _INIT_DCS_CMD(0x37, 0x00),
+ _INIT_DCS_CMD(0x38, 0x28),
+ _INIT_DCS_CMD(0x39, 0x29),
+ _INIT_DCS_CMD(0x3A, 0x11),
+ _INIT_DCS_CMD(0x3B, 0x13),
+ _INIT_DCS_CMD(0x3C, 0x15),
+ _INIT_DCS_CMD(0x3D, 0x17),
+ _INIT_DCS_CMD(0x3E, 0x09),
+ _INIT_DCS_CMD(0x3F, 0x0D),
+ _INIT_DCS_CMD(0x40, 0x02),
+ _INIT_DCS_CMD(0x41, 0x02),
+ _INIT_DCS_CMD(0x42, 0x02),
+ _INIT_DCS_CMD(0x43, 0x02),
+ _INIT_DCS_CMD(0x44, 0x02),
+ _INIT_DCS_CMD(0x45, 0x02),
+ _INIT_DCS_CMD(0x46, 0x02),
+
+ _INIT_DCS_CMD(0x47, 0x07),
+ _INIT_DCS_CMD(0x48, 0x07),
+ _INIT_DCS_CMD(0x49, 0x07),
+ _INIT_DCS_CMD(0x4A, 0x07),
+ _INIT_DCS_CMD(0x4B, 0x07),
+ _INIT_DCS_CMD(0x4C, 0x01),
+ _INIT_DCS_CMD(0x4D, 0x00),
+ _INIT_DCS_CMD(0x4E, 0x28),
+ _INIT_DCS_CMD(0x4F, 0x29),
+ _INIT_DCS_CMD(0x50, 0x10),
+ _INIT_DCS_CMD(0x51, 0x12),
+ _INIT_DCS_CMD(0x52, 0x14),
+ _INIT_DCS_CMD(0x53, 0x16),
+ _INIT_DCS_CMD(0x54, 0x08),
+ _INIT_DCS_CMD(0x55, 0x0C),
+ _INIT_DCS_CMD(0x56, 0x02),
+ _INIT_DCS_CMD(0x57, 0x02),
+ _INIT_DCS_CMD(0x58, 0x02),
+ _INIT_DCS_CMD(0x59, 0x02),
+ _INIT_DCS_CMD(0x5A, 0x02),
+ _INIT_DCS_CMD(0x5B, 0x02),
+ _INIT_DCS_CMD(0x5C, 0x02),
+
+ _INIT_DCS_CMD(0x61, 0x07),
+ _INIT_DCS_CMD(0x62, 0x07),
+ _INIT_DCS_CMD(0x63, 0x07),
+ _INIT_DCS_CMD(0x64, 0x07),
+ _INIT_DCS_CMD(0x65, 0x07),
+ _INIT_DCS_CMD(0x66, 0x01),
+ _INIT_DCS_CMD(0x67, 0x00),
+ _INIT_DCS_CMD(0x68, 0x28),
+ _INIT_DCS_CMD(0x69, 0x29),
+ _INIT_DCS_CMD(0x6A, 0x16),
+ _INIT_DCS_CMD(0x6B, 0x14),
+ _INIT_DCS_CMD(0x6C, 0x12),
+ _INIT_DCS_CMD(0x6D, 0x10),
+ _INIT_DCS_CMD(0x6E, 0x0C),
+ _INIT_DCS_CMD(0x6F, 0x08),
+ _INIT_DCS_CMD(0x70, 0x02),
+ _INIT_DCS_CMD(0x71, 0x02),
+ _INIT_DCS_CMD(0x72, 0x02),
+ _INIT_DCS_CMD(0x73, 0x02),
+ _INIT_DCS_CMD(0x74, 0x02),
+ _INIT_DCS_CMD(0x75, 0x02),
+ _INIT_DCS_CMD(0x76, 0x02),
+
+ _INIT_DCS_CMD(0x77, 0x07),
+ _INIT_DCS_CMD(0x78, 0x07),
+ _INIT_DCS_CMD(0x79, 0x07),
+ _INIT_DCS_CMD(0x7A, 0x07),
+ _INIT_DCS_CMD(0x7B, 0x07),
+ _INIT_DCS_CMD(0x7C, 0x01),
+ _INIT_DCS_CMD(0x7D, 0x00),
+ _INIT_DCS_CMD(0x7E, 0x28),
+ _INIT_DCS_CMD(0x7F, 0x29),
+ _INIT_DCS_CMD(0x80, 0x17),
+ _INIT_DCS_CMD(0x81, 0x15),
+ _INIT_DCS_CMD(0x82, 0x13),
+ _INIT_DCS_CMD(0x83, 0x11),
+ _INIT_DCS_CMD(0x84, 0x0D),
+ _INIT_DCS_CMD(0x85, 0x09),
+ _INIT_DCS_CMD(0x86, 0x02),
+ _INIT_DCS_CMD(0x87, 0x07),
+ _INIT_DCS_CMD(0x88, 0x07),
+ _INIT_DCS_CMD(0x89, 0x07),
+ _INIT_DCS_CMD(0x8A, 0x07),
+ _INIT_DCS_CMD(0x8B, 0x07),
+ _INIT_DCS_CMD(0x8C, 0x07),
+
+ _INIT_DCS_C
[v2 4/4] dt-bindings: display: panel: Add compatible for Starry ili9882t
The STARRY ili9882t is a 10.51" WUXGA TFT LCD panel, which fits in nicely with the existing panel-boe-tv101wum-nl6 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index 28a7beeb8f92..906ef62709b8 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -34,6 +34,8 @@ properties: - starry,2081101qfh032011-53g # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel - starry,himax83102-j02 +# STARRY ili9882t 10.51" WUXGA TFT LCD panel + - starry,ili9882t reg: description: the virtual channel number of a DSI peripheral -- 2.25.1
[PATCH 0/5] accel/ivpu: Add debugfs support
Add debugfs support for ivpu driver, most importantly firmware loging and tracing. Andrzej Kacprowski (1): accel/ivpu: Print firmware name and version Krystian Pradzynski (1): accel/ivpu: Add fw_name file to debugfs Stanislaw Gruszka (3): accel/ivpu: Initial debugfs support accel/ivpu: Add firmware tracing support accel/ivpu: Add debugfs files for testing device reset drivers/accel/ivpu/Makefile | 4 +- drivers/accel/ivpu/ivpu_debugfs.c | 294 ++ drivers/accel/ivpu/ivpu_debugfs.h | 13 ++ drivers/accel/ivpu/ivpu_drv.c | 5 + drivers/accel/ivpu/ivpu_fw.c | 68 ++- drivers/accel/ivpu/ivpu_fw.h | 4 + drivers/accel/ivpu/ivpu_fw_log.c | 142 +++ drivers/accel/ivpu/ivpu_fw_log.h | 38 drivers/accel/ivpu/ivpu_pm.c | 1 + drivers/accel/ivpu/ivpu_pm.h | 1 + 10 files changed, 563 insertions(+), 7 deletions(-) create mode 100644 drivers/accel/ivpu/ivpu_debugfs.c create mode 100644 drivers/accel/ivpu/ivpu_debugfs.h create mode 100644 drivers/accel/ivpu/ivpu_fw_log.c create mode 100644 drivers/accel/ivpu/ivpu_fw_log.h -- 2.25.1
[PATCH 1/5] accel/ivpu: Initial debugfs support
Add initial debugfs support. Provide below functionality:
- print buffer objects
- print latest boot mode
- trigger vpu engine reset
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_debugfs.c | 74 +++
drivers/accel/ivpu/ivpu_debugfs.h | 13 ++
drivers/accel/ivpu/ivpu_drv.c | 5 +++
4 files changed, 93 insertions(+)
create mode 100644 drivers/accel/ivpu/ivpu_debugfs.c
create mode 100644 drivers/accel/ivpu/ivpu_debugfs.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 80f1fb3548ae..3ca2fb3936f6 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -2,6 +2,7 @@
# Copyright (C) 2023 Intel Corporation
intel_vpu-y := \
+ ivpu_debugfs.o \
ivpu_drv.o \
ivpu_fw.o \
ivpu_gem.o \
diff --git a/drivers/accel/ivpu/ivpu_debugfs.c
b/drivers/accel/ivpu/ivpu_debugfs.c
new file mode 100644
index ..df51ec008fb5
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_debugfs.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020-2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "ivpu_debugfs.h"
+#include "ivpu_drv.h"
+#include "ivpu_gem.h"
+#include "ivpu_jsm_msg.h"
+#include "ivpu_pm.h"
+
+static int bo_list_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct drm_printer p = drm_seq_file_printer(s);
+
+ ivpu_bo_list(node->minor->dev, &p);
+
+ return 0;
+}
+
+static int last_bootmode_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct ivpu_device *vdev = to_ivpu_device(node->minor->dev);
+
+ seq_printf(s, "%s\n", (vdev->pm->is_warmboot) ? "warmboot" :
"coldboot");
+
+ return 0;
+}
+
+static const struct drm_info_list vdev_debugfs_list[] = {
+ {"bo_list", bo_list_show, 0},
+ {"last_bootmode", last_bootmode_show, 0},
+};
+
+static ssize_t
+ivpu_reset_engine_fn(struct file *file, const char __user *user_buf, size_t
size, loff_t *pos)
+{
+ struct ivpu_device *vdev = file->private_data;
+
+ if (!size)
+ return -EINVAL;
+
+ if (ivpu_jsm_reset_engine(vdev, DRM_IVPU_ENGINE_COMPUTE))
+ return -ENODEV;
+ if (ivpu_jsm_reset_engine(vdev, DRM_IVPU_ENGINE_COPY))
+ return -ENODEV;
+
+ return size;
+}
+
+static const struct file_operations ivpu_reset_engine_fops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .write = ivpu_reset_engine_fn,
+};
+
+void ivpu_debugfs_init(struct drm_minor *minor)
+{
+ struct ivpu_device *vdev = to_ivpu_device(minor->dev);
+
+ drm_debugfs_create_files(vdev_debugfs_list,
ARRAY_SIZE(vdev_debugfs_list),
+minor->debugfs_root, minor);
+
+ debugfs_create_file("reset_engine", 0200, minor->debugfs_root, vdev,
+ &ivpu_reset_engine_fops);
+}
diff --git a/drivers/accel/ivpu/ivpu_debugfs.h
b/drivers/accel/ivpu/ivpu_debugfs.h
new file mode 100644
index ..78f80c1e00e4
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_debugfs.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020-2023 Intel Corporation
+ */
+
+#ifndef __IVPU_DEBUGFS_H__
+#define __IVPU_DEBUGFS_H__
+
+struct drm_minor;
+
+void ivpu_debugfs_init(struct drm_minor *minor);
+
+#endif /* __IVPU_DEBUGFS_H__ */
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 2df7643b843d..4c0345417c14 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -14,6 +14,7 @@
#include
#include "vpu_boot_api.h"
+#include "ivpu_debugfs.h"
#include "ivpu_drv.h"
#include "ivpu_fw.h"
#include "ivpu_gem.h"
@@ -378,6 +379,10 @@ static const struct drm_driver driver = {
.gem_prime_import = ivpu_gem_prime_import,
.gem_prime_mmap = drm_gem_prime_mmap,
+#if defined(CONFIG_DEBUG_FS)
+ .debugfs_init = ivpu_debugfs_init,
+#endif
+
.ioctls = ivpu_drm_ioctls,
.num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls),
.fops = &ivpu_fops,
--
2.25.1
[PATCH 2/5] accel/ivpu: Add firmware tracing support
Add support for firmware tracing and logging via debugfs.
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Makefile | 3 +-
drivers/accel/ivpu/ivpu_debugfs.c | 169 ++
drivers/accel/ivpu/ivpu_fw.c | 52 -
drivers/accel/ivpu/ivpu_fw.h | 3 +
drivers/accel/ivpu/ivpu_fw_log.c | 142 +
drivers/accel/ivpu/ivpu_fw_log.h | 38 +++
6 files changed, 404 insertions(+), 3 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_fw_log.c
create mode 100644 drivers/accel/ivpu/ivpu_fw_log.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 3ca2fb3936f6..9858d9fea36e 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -5,6 +5,7 @@ intel_vpu-y := \
ivpu_debugfs.o \
ivpu_drv.o \
ivpu_fw.o \
+ ivpu_fw_log.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
@@ -14,4 +15,4 @@ intel_vpu-y := \
ivpu_mmu_context.o \
ivpu_pm.o
-obj-$(CONFIG_DRM_ACCEL_IVPU) += intel_vpu.o
\ No newline at end of file
+obj-$(CONFIG_DRM_ACCEL_IVPU) += intel_vpu.o
diff --git a/drivers/accel/ivpu/ivpu_debugfs.c
b/drivers/accel/ivpu/ivpu_debugfs.c
index df51ec008fb5..a9180fae43b6 100644
--- a/drivers/accel/ivpu/ivpu_debugfs.c
+++ b/drivers/accel/ivpu/ivpu_debugfs.c
@@ -11,6 +11,8 @@
#include "ivpu_debugfs.h"
#include "ivpu_drv.h"
+#include "ivpu_fw.h"
+#include "ivpu_fw_log.h"
#include "ivpu_gem.h"
#include "ivpu_jsm_msg.h"
#include "ivpu_pm.h"
@@ -25,6 +27,46 @@ static int bo_list_show(struct seq_file *s, void *v)
return 0;
}
+static int fw_trace_capability_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct ivpu_device *vdev = to_ivpu_device(node->minor->dev);
+ u64 trace_hw_component_mask;
+ u32 trace_destination_mask;
+ int ret;
+
+ ret = ivpu_jsm_trace_get_capability(vdev, &trace_destination_mask,
+ &trace_hw_component_mask);
+ if (!ret) {
+ seq_printf(s,
+ "trace_destination_mask: %#18x\n"
+ "trace_hw_component_mask: %#18llx\n",
+ trace_destination_mask, trace_hw_component_mask);
+ }
+ return 0;
+}
+
+static int fw_trace_config_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct ivpu_device *vdev = to_ivpu_device(node->minor->dev);
+ /**
+* WA: VPU_JSM_MSG_TRACE_GET_CONFIG command is not working yet,
+* so we use values from vdev->fw instead of calling
ivpu_jsm_trace_get_config()
+*/
+ u32 trace_level = vdev->fw->trace_level;
+ u32 trace_destination_mask = vdev->fw->trace_destination_mask;
+ u64 trace_hw_component_mask = vdev->fw->trace_hw_component_mask;
+
+ seq_printf(s,
+ "trace_level: %#18x\n"
+ "trace_destination_mask: %#18x\n"
+ "trace_hw_component_mask: %#18llx\n",
+ trace_level, trace_destination_mask,
trace_hw_component_mask);
+
+ return 0;
+}
+
static int last_bootmode_show(struct seq_file *s, void *v)
{
struct drm_info_node *node = (struct drm_info_node *)s->private;
@@ -37,9 +79,127 @@ static int last_bootmode_show(struct seq_file *s, void *v)
static const struct drm_info_list vdev_debugfs_list[] = {
{"bo_list", bo_list_show, 0},
+ {"fw_trace_capability", fw_trace_capability_show, 0},
+ {"fw_trace_config", fw_trace_config_show, 0},
{"last_bootmode", last_bootmode_show, 0},
};
+static int fw_log_show(struct seq_file *s, void *v)
+{
+ struct ivpu_device *vdev = s->private;
+ struct drm_printer p = drm_seq_file_printer(s);
+
+ ivpu_fw_log_print(vdev, true, &p);
+ return 0;
+}
+
+static int fw_log_fops_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, fw_log_show, inode->i_private);
+}
+
+static ssize_t
+fw_log_fops_write(struct file *file, const char __user *user_buf, size_t size,
loff_t *pos)
+{
+ struct seq_file *s = file->private_data;
+ struct ivpu_device *vdev = s->private;
+
+ if (!size)
+ return -EINVAL;
+
+ ivpu_fw_log_clear(vdev);
+ return size;
+}
+
+static const struct file_operations fw_log_fops = {
+ .owner = THIS_MODULE,
+ .open = fw_log_fops_open,
+ .write = fw_log_fops_write,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static ssize_t
+fw_trace_destination_mask_fops_write(struct file *file, const char __user
*user_buf,
+size_t size, loff_t *pos)
+{
+ struct ivpu_device *vdev = file->private_data;
+ struct ivpu_fw_info *fw = vdev->fw;
+ u32 trace_destination_mask;
+
[PATCH 3/5] accel/ivpu: Add debugfs files for testing device reset
Add new debugfs files to validate device recovery functionality.
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_debugfs.c | 41 +++
drivers/accel/ivpu/ivpu_pm.c | 1 +
drivers/accel/ivpu/ivpu_pm.h | 1 +
3 files changed, 43 insertions(+)
diff --git a/drivers/accel/ivpu/ivpu_debugfs.c
b/drivers/accel/ivpu/ivpu_debugfs.c
index a9180fae43b6..e2502d2b53c0 100644
--- a/drivers/accel/ivpu/ivpu_debugfs.c
+++ b/drivers/accel/ivpu/ivpu_debugfs.c
@@ -77,11 +77,31 @@ static int last_bootmode_show(struct seq_file *s, void *v)
return 0;
}
+static int reset_counter_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct ivpu_device *vdev = to_ivpu_device(node->minor->dev);
+
+ seq_printf(s, "%d\n", atomic_read(&vdev->pm->reset_counter));
+ return 0;
+}
+
+static int reset_pending_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct ivpu_device *vdev = to_ivpu_device(node->minor->dev);
+
+ seq_printf(s, "%d\n", atomic_read(&vdev->pm->in_reset));
+ return 0;
+}
+
static const struct drm_info_list vdev_debugfs_list[] = {
{"bo_list", bo_list_show, 0},
{"fw_trace_capability", fw_trace_capability_show, 0},
{"fw_trace_config", fw_trace_config_show, 0},
{"last_bootmode", last_bootmode_show, 0},
+ {"reset_counter", reset_counter_show, 0},
+ {"reset_pending", reset_pending_show, 0},
};
static int fw_log_show(struct seq_file *s, void *v)
@@ -216,6 +236,24 @@ ivpu_reset_engine_fn(struct file *file, const char __user
*user_buf, size_t size
return size;
}
+static ssize_t
+ivpu_force_recovery_fn(struct file *file, const char __user *user_buf, size_t
size, loff_t *pos)
+{
+ struct ivpu_device *vdev = file->private_data;
+
+ if (!size)
+ return -EINVAL;
+
+ ivpu_pm_schedule_recovery(vdev);
+ return size;
+}
+
+static const struct file_operations ivpu_force_recovery_fops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .write = ivpu_force_recovery_fn,
+};
+
static const struct file_operations ivpu_reset_engine_fops = {
.owner = THIS_MODULE,
.open = simple_open,
@@ -229,6 +267,9 @@ void ivpu_debugfs_init(struct drm_minor *minor)
drm_debugfs_create_files(vdev_debugfs_list,
ARRAY_SIZE(vdev_debugfs_list),
minor->debugfs_root, minor);
+ debugfs_create_file("force_recovery", 0200, minor->debugfs_root, vdev,
+ &ivpu_force_recovery_fops);
+
debugfs_create_file("fw_log", 0644, minor->debugfs_root, vdev,
&fw_log_fops);
debugfs_create_file("fw_trace_destination_mask", 0200,
minor->debugfs_root, vdev,
diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c
index aa4d56dc52b3..e6f27daf5560 100644
--- a/drivers/accel/ivpu/ivpu_pm.c
+++ b/drivers/accel/ivpu/ivpu_pm.c
@@ -259,6 +259,7 @@ void ivpu_pm_reset_prepare_cb(struct pci_dev *pdev)
pm_runtime_get_sync(vdev->drm.dev);
ivpu_dbg(vdev, PM, "Pre-reset..\n");
+ atomic_inc(&vdev->pm->reset_counter);
atomic_set(&vdev->pm->in_reset, 1);
ivpu_shutdown(vdev);
ivpu_pm_prepare_cold_boot(vdev);
diff --git a/drivers/accel/ivpu/ivpu_pm.h b/drivers/accel/ivpu/ivpu_pm.h
index baca98187255..fd4eada1290f 100644
--- a/drivers/accel/ivpu/ivpu_pm.h
+++ b/drivers/accel/ivpu/ivpu_pm.h
@@ -14,6 +14,7 @@ struct ivpu_pm_info {
struct ivpu_device *vdev;
struct work_struct recovery_work;
atomic_t in_reset;
+ atomic_t reset_counter;
bool is_warmboot;
u32 suspend_reschedule_counter;
};
--
2.25.1
[PATCH 4/5] accel/ivpu: Print firmware name and version
From: Andrzej Kacprowski
Firmware file name and version are very important for debugging
customer issues - print them as INFO level message instead
of DEBUG message that is turned off by default.
Signed-off-by: Andrzej Kacprowski
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_fw.c | 16
drivers/accel/ivpu/ivpu_fw.h | 1 +
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 3599bb8706eb..317716482a15 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -52,13 +52,19 @@ static int ivpu_fw_request(struct ivpu_device *vdev)
int ret = -ENOENT;
int i;
- if (ivpu_firmware)
- return request_firmware(&vdev->fw->file, ivpu_firmware,
vdev->drm.dev);
+ if (ivpu_firmware) {
+ ret = request_firmware(&vdev->fw->file, ivpu_firmware,
vdev->drm.dev);
+ if (!ret)
+ vdev->fw->name = ivpu_firmware;
+ return ret;
+ }
for (i = 0; i < ARRAY_SIZE(fw_names); i++) {
ret = firmware_request_nowarn(&vdev->fw->file, fw_names[i],
vdev->drm.dev);
- if (!ret)
+ if (!ret) {
+ vdev->fw->name = fw_names[i];
return 0;
+ }
}
ivpu_err(vdev, "Failed to request firmware: %d\n", ret);
@@ -143,7 +149,9 @@ static int ivpu_fw_parse(struct ivpu_device *vdev)
}
ivpu_dbg(vdev, FW_BOOT, "Header version: 0x%x, format 0x%x\n",
fw_hdr->header_version, fw_hdr->image_format);
- ivpu_dbg(vdev, FW_BOOT, "FW version: %s\n", (char *)fw_hdr +
VPU_FW_HEADER_SIZE);
+
+ ivpu_info(vdev, "Firmware: %s, version: %s", fw->name,
+ (const char *)fw_hdr + VPU_FW_HEADER_SIZE);
if (IVPU_FW_CHECK_API(vdev, fw_hdr, BOOT, 3))
return -EINVAL;
diff --git a/drivers/accel/ivpu/ivpu_fw.h b/drivers/accel/ivpu/ivpu_fw.h
index 3cc3a1497a4a..8567fdf925fe 100644
--- a/drivers/accel/ivpu/ivpu_fw.h
+++ b/drivers/accel/ivpu/ivpu_fw.h
@@ -12,6 +12,7 @@ struct vpu_boot_params;
struct ivpu_fw_info {
const struct firmware *file;
+ const char *name;
struct ivpu_bo *mem;
struct ivpu_bo *mem_shave_nn;
struct ivpu_bo *mem_log_crit;
--
2.25.1
[PATCH 5/5] accel/ivpu: Add fw_name file to debugfs
From: Krystian Pradzynski
Add information about currently used firmware, makes test
automation of different firmware images easier.
Signed-off-by: Krystian Pradzynski
Reviewed-by: Stanislaw Gruszka
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_debugfs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/accel/ivpu/ivpu_debugfs.c
b/drivers/accel/ivpu/ivpu_debugfs.c
index e2502d2b53c0..5e5996fd4f9f 100644
--- a/drivers/accel/ivpu/ivpu_debugfs.c
+++ b/drivers/accel/ivpu/ivpu_debugfs.c
@@ -27,6 +27,15 @@ static int bo_list_show(struct seq_file *s, void *v)
return 0;
}
+static int fw_name_show(struct seq_file *s, void *v)
+{
+ struct drm_info_node *node = (struct drm_info_node *)s->private;
+ struct ivpu_device *vdev = to_ivpu_device(node->minor->dev);
+
+ seq_printf(s, "%s\n", vdev->fw->name);
+ return 0;
+}
+
static int fw_trace_capability_show(struct seq_file *s, void *v)
{
struct drm_info_node *node = (struct drm_info_node *)s->private;
@@ -97,6 +106,7 @@ static int reset_pending_show(struct seq_file *s, void *v)
static const struct drm_info_list vdev_debugfs_list[] = {
{"bo_list", bo_list_show, 0},
+ {"fw_name", fw_name_show, 0},
{"fw_trace_capability", fw_trace_capability_show, 0},
{"fw_trace_config", fw_trace_config_show, 0},
{"last_bootmode", last_bootmode_show, 0},
--
2.25.1
Re: [PATCH 0/5] accel/ivpu: Add debugfs support
On Wed, May 24, 2023 at 10:49 AM Stanislaw Gruszka wrote: > > Add debugfs support for ivpu driver, most importantly firmware loging > and tracing. Hi, Without looking at the code I have 2 comments/questions: 1. Please add an ABI documentation in Documentation/ABI/testing/ or Documentation/ABI/stable (if you are feeling courageous). You can see for example habana's file at Documentation/ABI/testing/debugfs-driver-habanalabs 2. Is this synced with Christian's upcoming changes to the debugfs infra in drm ? If not, I might suggest to sync with that and wait until those patches are merged because they change the layout of debugfs nodes. Oded > > Andrzej Kacprowski (1): > accel/ivpu: Print firmware name and version > > Krystian Pradzynski (1): > accel/ivpu: Add fw_name file to debugfs > > Stanislaw Gruszka (3): > accel/ivpu: Initial debugfs support > accel/ivpu: Add firmware tracing support > accel/ivpu: Add debugfs files for testing device reset > > drivers/accel/ivpu/Makefile | 4 +- > drivers/accel/ivpu/ivpu_debugfs.c | 294 ++ > drivers/accel/ivpu/ivpu_debugfs.h | 13 ++ > drivers/accel/ivpu/ivpu_drv.c | 5 + > drivers/accel/ivpu/ivpu_fw.c | 68 ++- > drivers/accel/ivpu/ivpu_fw.h | 4 + > drivers/accel/ivpu/ivpu_fw_log.c | 142 +++ > drivers/accel/ivpu/ivpu_fw_log.h | 38 > drivers/accel/ivpu/ivpu_pm.c | 1 + > drivers/accel/ivpu/ivpu_pm.h | 1 + > 10 files changed, 563 insertions(+), 7 deletions(-) > create mode 100644 drivers/accel/ivpu/ivpu_debugfs.c > create mode 100644 drivers/accel/ivpu/ivpu_debugfs.h > create mode 100644 drivers/accel/ivpu/ivpu_fw_log.c > create mode 100644 drivers/accel/ivpu/ivpu_fw_log.h > > -- > 2.25.1 >
Re: [PATCH] drm/msm/dp: add module parameter for PSR
On 24/05/2023 09:59, Johan Hovold wrote: On Tue, May 23, 2023 at 12:23:04PM -0700, Abhinav Kumar wrote: On 5/23/2023 8:24 AM, Johan Hovold wrote: On Fri, May 12, 2023 at 09:13:04PM +0300, Dmitry Baryshkov wrote: On 28/04/2023 02:28, Abhinav Kumar wrote: On sc7280 where eDP is the primary display, PSR is causing IGT breakage even for basic test cases like kms_atomic and kms_atomic_transition. Most often the issue starts with below stack so providing that as reference Call trace: ---[ end trace ]--- [drm-dp] dp_ctrl_push_idle: PUSH_IDLE pattern timedout Other basic use-cases still seem to work fine hence add a a module parameter to allow toggling psr enable/disable till PSR related issues are hashed out with IGT. For the reference: Bjorn reported that he has issues with VT on a PSR-enabled laptops. This patch fixes the issue for him Module parameters are almost never warranted, and it is definitely not the right way to handle a broken implementation. I've just sent a revert that unconditionally disables PSR support until the implementation has been fixed: https://lore.kernel.org/lkml/20230523151646.28366-1-johan+lin...@kernel.org/ I dont completely agree with this. Even the virtual terminal case was reported to be fixed by one user but not the other. So it was probably something missed out either in validation or reproduction steps of the user who reported it to be fixed OR the user who reported it not fixed. That needs to be investigated now. Yes, there may still be some time left to fix it, but it's pretty damn annoying to find that an issue reported two months ago still is not fixed at 6.4-rc3. (I even waited to make the switch to 6.4 so that I would not have to spend time on this.) I didn't see any mail from Bjorn saying that the series that claimed to fix the VT issue actually did fix the VT issue. There's only the comment above from Dmitry suggesting that disabling this feature is the only way to get a working terminal back. Originally this issue was reported by Doug, and at [1] he reported that an issue is fixed for him. So, for me it looks like we have hardware where VT works and hardware where it doesn't. Doug, can you please confirm whether you can reproduce the PSR+VT issue on 6.4-rc (without extra patches) or if the issue is fixed for you? [1] https://lore.kernel.org/dri-devel/CAD=FV=vshmqptsqfwjviezeerms-veotmfozejasuc9zsmj...@mail.gmail.com/ Regressions happen and sometimes there are corner cases that are harder to find, but this is a breakage of a fundamental feature that was reported before the code was even merged into mainline. We should have ideally gone with the modparam with the feature patches itself knowing that it gets enabled for all sinks if PSR is supported. Modparams are things of the past should not be used to enable broken features so that some vendor can tick of their internal lists of features that have been "mainlined". We have had a history of using modparam with i915 and IIRC amdgpu / radeon drivers to allow users to easily check whether new feature works for their hardware. My current understanding is that PSR+VT works for on some laptops and doesn't on some other laptops, which makes it a valid case. You can carry that single patch out-of-tree to enable this if you need it for some particular use case where you don't care about VTs. But hopefully you can just get this sorted quickly. If not, the revert I posted is the way to go rather than adding random module parameters. Johan -- With best wishes Dmitry
Re: [PATCH v2 RESEND 4/7] swiotlb: Dynamically allocated bounce buffers
On Wed, May 17, 2023 at 01:27:48PM +0200, Petr Tesařík wrote: > On Wed, 17 May 2023 08:35:10 +0200 > Petr Tesařík wrote: > > Anyway, my greatest objection to allocating additional swiotlb chunks is > > that _all_ of them must be searched to determine that the physical > > address does _not_ belong to a swiotlb, incurring performance penalty > > I thought about this part again, and I overlooked one option. We can > track only the _active_ swiotlbs for each device. If a device never > needs a swiotlb, there is no active swiotlb, and is_swiotlb_buffer() > short-circuits to false. This should avoid all collateral damage to > innocent devices. Does this work with dma-buf or does dma-buf not allow swiotlb bouncing? -- Catalin
[Linux-kernel-mentorship] [PATCH] drm/amdgpu: remove excess parameter description in amdgpu_device.c
This patch is part of the Linux Kernel Bug Fixing Summer screening tasks. By removing the extra description, several documentation compilation warnings such as the following have been fixed: > ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:758: warning: Excess function > parameter 'pcie_index' description in 'amdgpu_device_indirect_wreg' Note: I assume the description can be safely removed based on this earlier patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch?id=65ba96e91b689c23d6fa99c11cfd65965dcddc47 Signed-off-by: Ziqi Zhao --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5c7d40873ee2..58d8f60c6a3a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -747,8 +747,6 @@ u64 amdgpu_device_indirect_rreg64(struct amdgpu_device *adev, * amdgpu_device_indirect_wreg - write an indirect register address * * @adev: amdgpu_device pointer - * @pcie_index: mmio register offset - * @pcie_data: mmio register offset * @reg_addr: indirect register offset * @reg_data: indirect register data * @@ -778,8 +776,6 @@ void amdgpu_device_indirect_wreg(struct amdgpu_device *adev, * amdgpu_device_indirect_wreg64 - write a 64bits indirect register address * * @adev: amdgpu_device pointer - * @pcie_index: mmio register offset - * @pcie_data: mmio register offset * @reg_addr: indirect register offset * @reg_data: indirect register data * -- 2.34.1
Re: [RESEND PATCH v3] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
On 22.05.2023 17:14, Miquel Raynal wrote:
> Hi Arseniy,
>
> avkras...@sberdevices.ru wrote on Mon, 15 May 2023 12:49:50 +0300:
>
>> Hello @Miquel!
>>
>> Sorry, but who could review this patch? :) IIUC this logic is very hw
>> specific and we need
>> someone who knows it well? I tested this patch on our devices (with already
>> known Meson NAND
>> controller).
>
> + Jaime, who might test
>
>>
>> Thanks, Arseniy
>>
>> On 11.05.2023 21:21, Arseniy Krasnov wrote:
>>> Cc: Mason Yang and Boris Brezillon
>>>
>>>
>>> On 11.05.2023 18:21, Arseniy Krasnov wrote:
This adds support for OTP area access on MX30LFxG18AC chip series.
Changelog:
v1 -> v2:
* Add slab.h include due to kernel test robot error.
v2 -> v3:
* Use 'uint64_t' as input argument for 'do_div()' instead
of 'unsigned long' due to kernel test robot error.
Signed-off-by: Arseniy Krasnov
---
drivers/mtd/nand/raw/nand_macronix.c | 213 +++
1 file changed, 213 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 1472f925f386..2301f990678e 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -6,6 +6,7 @@
* Author: Boris Brezillon
*/
+#include
#include "linux/delay.h"
#include "internals.h"
@@ -31,6 +32,20 @@
#define MXIC_CMD_POWER_DOWN 0xB9
+#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90
+#define MACRONIX_30LFXG18AC_OTP_START_PAGE0
+#define MACRONIX_30LFXG18AC_OTP_PAGES 30
+#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE 2112
+#define MACRONIX_30LFXG18AC_OTP_START_BYTE\
+ (MACRONIX_30LFXG18AC_OTP_START_PAGE * \
+ MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
+#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES\
+ (MACRONIX_30LFXG18AC_OTP_PAGES *\
+ MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
+
+#define MACRONIX_30LFXG18AC_OTP_ENBIT(0)
+#define MACRONIX_30LFXG18AC_OTP_LOCKEDBIT(1)
+
struct nand_onfi_vendor_macronix {
u8 reserved;
u8 reliability_func;
@@ -316,6 +331,203 @@ static void
macronix_nand_deep_power_down_support(struct nand_chip *chip)
chip->ops.resume = mxic_nand_resume;
}
+static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd, size_t
len,
+ size_t *retlen,
+ struct otp_info *buf)
+{
+ if (len < sizeof(*buf))
+ return -EINVAL;
+
+ /* Don't know how to check that OTP is locked. */
>
> Jaime, any idea?
>
That will be great, because i didn't found any doc about that
Thanks
+ buf->locked = 0;
+ buf->start = MACRONIX_30LFXG18AC_OTP_START_BYTE;
+ buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
+
+ *retlen = sizeof(*buf);
+
+ return 0;
+}
+
+static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand)
+{
+ uint8_t feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
+
+ feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN;
+ return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
+ feature_buf);
+}
+
+static int macronix_30lfxg18ac_otp_disable(struct nand_chip *nand)
+{
+ uint8_t feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
+
+ return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
+ feature_buf);
+}
+
+static int __macronix_30lfxg18ac_rw_otp(struct mtd_info *mtd,
+ loff_t offs_in_flash,
+ size_t len, size_t *retlen,
+ u_char *buf, bool write)
+{
+ struct nand_chip *nand;
+ size_t bytes_handled;
+ off_t offs_in_page;
+ uint64_t page;
+ void *dma_buf;
+ int ret;
+
+ /* 'nand_prog/read_page_op()' may use 'buf' as DMA buffer,
+ * so allocate properly aligned memory for it. This is
+ * needed because cross page accesses may lead to unaligned
+ * buffer address for DMA.
+ */
+ dma_buf = kmalloc(MACRONIX_30LFXG18AC_OTP_PAGE_SIZE, GFP_KERNEL);
+ if (!dma_buf)
+ return -ENOMEM;
+
+ nand = mtd_to_nand(mtd);
+ nand_select_target(nand, 0);
+
+ ret = macronix_30lfxg18ac_otp_enable(nand);
+ if (ret)
+ goto out_otp;
+
+ page = offs_in_flash;
+ /* 'page' will be result of division. */
+ offs_in_page = do_div(page, MACRONIX_30LFXG18AC_OTP_PAGE_SIZE);
+ bytes_handled = 0;
+
+ while (bytes_handled < len &&
+ page < MACRONIX_
[PATCH v4] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
This adds support for OTP area access on MX30LFxG18AC chip series.
Signed-off-by: Arseniy Krasnov
---
v1 -> v2:
* Add slab.h include due to kernel test robot error.
v2 -> v3:
* Use 'uint64_t' as input argument for 'do_div()' instead
of 'unsigned long' due to kernel test robot error.
v3 -> v4:
* Use 'dev_err()' instead of 'WARN()'.
* Call 'match_string()' before checking 'supports_set_get_features'
in 'macronix_nand_setup_otp().
* Use 'u8' instead of 'uint8_t' as ./checkpatch.pl wants.
drivers/mtd/nand/raw/nand_macronix.c | 216 +++
1 file changed, 216 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 1472f925f386..be1ffa93bebb 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -6,6 +6,7 @@
* Author: Boris Brezillon
*/
+#include
#include "linux/delay.h"
#include "internals.h"
@@ -31,6 +32,20 @@
#define MXIC_CMD_POWER_DOWN 0xB9
+#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90
+#define MACRONIX_30LFXG18AC_OTP_START_PAGE 0
+#define MACRONIX_30LFXG18AC_OTP_PAGES 30
+#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE 2112
+#define MACRONIX_30LFXG18AC_OTP_START_BYTE \
+ (MACRONIX_30LFXG18AC_OTP_START_PAGE * \
+MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
+#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES \
+ (MACRONIX_30LFXG18AC_OTP_PAGES *\
+MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
+
+#define MACRONIX_30LFXG18AC_OTP_EN BIT(0)
+#define MACRONIX_30LFXG18AC_OTP_LOCKED BIT(1)
+
struct nand_onfi_vendor_macronix {
u8 reserved;
u8 reliability_func;
@@ -316,6 +331,206 @@ static void macronix_nand_deep_power_down_support(struct
nand_chip *chip)
chip->ops.resume = mxic_nand_resume;
}
+static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd, size_t len,
+ size_t *retlen,
+ struct otp_info *buf)
+{
+ if (len < sizeof(*buf))
+ return -EINVAL;
+
+ /* Don't know how to check that OTP is locked. */
+ buf->locked = 0;
+ buf->start = MACRONIX_30LFXG18AC_OTP_START_BYTE;
+ buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
+
+ *retlen = sizeof(*buf);
+
+ return 0;
+}
+
+static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand)
+{
+ u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
+
+ feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN;
+ return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
+feature_buf);
+}
+
+static int macronix_30lfxg18ac_otp_disable(struct nand_chip *nand)
+{
+ u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
+
+ return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
+feature_buf);
+}
+
+static int __macronix_30lfxg18ac_rw_otp(struct mtd_info *mtd,
+ loff_t offs_in_flash,
+ size_t len, size_t *retlen,
+ u_char *buf, bool write)
+{
+ struct nand_chip *nand;
+ size_t bytes_handled;
+ off_t offs_in_page;
+ void *dma_buf;
+ u64 page;
+ int ret;
+
+ /* 'nand_prog/read_page_op()' may use 'buf' as DMA buffer,
+* so allocate properly aligned memory for it. This is
+* needed because cross page accesses may lead to unaligned
+* buffer address for DMA.
+*/
+ dma_buf = kmalloc(MACRONIX_30LFXG18AC_OTP_PAGE_SIZE, GFP_KERNEL);
+ if (!dma_buf)
+ return -ENOMEM;
+
+ nand = mtd_to_nand(mtd);
+ nand_select_target(nand, 0);
+
+ ret = macronix_30lfxg18ac_otp_enable(nand);
+ if (ret)
+ goto out_otp;
+
+ page = offs_in_flash;
+ /* 'page' will be result of division. */
+ offs_in_page = do_div(page, MACRONIX_30LFXG18AC_OTP_PAGE_SIZE);
+ bytes_handled = 0;
+
+ while (bytes_handled < len &&
+ page < MACRONIX_30LFXG18AC_OTP_PAGES) {
+ size_t bytes_to_handle;
+
+ bytes_to_handle = min_t(size_t, len - bytes_handled,
+ MACRONIX_30LFXG18AC_OTP_PAGE_SIZE -
+ offs_in_page);
+
+ if (write) {
+ memcpy(dma_buf, &buf[bytes_handled], bytes_to_handle);
+ ret = nand_prog_page_op(nand, page, offs_in_page,
+ dma_buf, bytes_to_handle);
+ } else {
+ ret = nand_read_page_op(nand, page, offs_in_page,
+ dma_buf, bytes_to_handle);
+ if (!ret)
+ memcpy(&buf[bytes_handled], dma_buf,
+
Re: [RESEND PATCH v3] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
Hi Miquel
>
> Hi Arseniy,
>
> avkras...@sberdevices.ru wrote on Mon, 15 May 2023 12:49:50 +0300:
>
> > Hello @Miquel!
> >
> > Sorry, but who could review this patch? :) IIUC this logic is very hw
> > specific and we need
> > someone who knows it well? I tested this patch on our devices (with already
> > known Meson NAND
> > controller).
>
> + Jaime, who might test
>
> >
> > Thanks, Arseniy
> >
> > On 11.05.2023 21:21, Arseniy Krasnov wrote:
> > > Cc: Mason Yang and Boris Brezillon
> > >
> > >
> > > On 11.05.2023 18:21, Arseniy Krasnov wrote:
> > >> This adds support for OTP area access on MX30LFxG18AC chip series.
> > >>
> > >> Changelog:
> > >> v1 -> v2:
> > >> * Add slab.h include due to kernel test robot error.
> > >> v2 -> v3:
> > >> * Use 'uint64_t' as input argument for 'do_div()' instead
> > >> of 'unsigned long' due to kernel test robot error.
> > >>
> > >> Signed-off-by: Arseniy Krasnov
> > >> ---
> > >> drivers/mtd/nand/raw/nand_macronix.c | 213 +++
> > >> 1 file changed, 213 insertions(+)
> > >>
> > >> diff --git a/drivers/mtd/nand/raw/nand_macronix.c
> > >> b/drivers/mtd/nand/raw/nand_macronix.c
> > >> index 1472f925f386..2301f990678e 100644
> > >> --- a/drivers/mtd/nand/raw/nand_macronix.c
> > >> +++ b/drivers/mtd/nand/raw/nand_macronix.c
> > >> @@ -6,6 +6,7 @@
> > >> * Author: Boris Brezillon
> > >> */
> > >>
> > >> +#include
> > >> #include "linux/delay.h"
> > >> #include "internals.h"
> > >>
> > >> @@ -31,6 +32,20 @@
> > >>
> > >> #define MXIC_CMD_POWER_DOWN 0xB9
> > >>
> > >> +#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90
> > >> +#define MACRONIX_30LFXG18AC_OTP_START_PAGE0
> > >> +#define MACRONIX_30LFXG18AC_OTP_PAGES 30
> > >> +#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE 2112
> > >> +#define MACRONIX_30LFXG18AC_OTP_START_BYTE\
> > >> + (MACRONIX_30LFXG18AC_OTP_START_PAGE * \
> > >> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
> > >> +#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES\
> > >> + (MACRONIX_30LFXG18AC_OTP_PAGES *\
> > >> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
> > >> +
> > >> +#define MACRONIX_30LFXG18AC_OTP_ENBIT(0)
> > >> +#define MACRONIX_30LFXG18AC_OTP_LOCKEDBIT(1)
> > >> +
> > >> struct nand_onfi_vendor_macronix {
> > >>u8 reserved;
> > >>u8 reliability_func;
> > >> @@ -316,6 +331,203 @@ static void
> > >> macronix_nand_deep_power_down_support(struct nand_chip *chip)
> > >>chip->ops.resume = mxic_nand_resume;
> > >> }
> > >>
> > >> +static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd,
> > >> size_t len,
> > >> + size_t *retlen,
> > >> + struct otp_info *buf)
> > >> +{
> > >> + if (len < sizeof(*buf))
> > >> + return -EINVAL;
> > >> +
> > >> + /* Don't know how to check that OTP is locked. */
>
> Jaime, any idea?
OTP info could be check by GET_FEATURE command.
GET_FEATURE command with address 90h could read sub-feature
parameter table, P1 is "3" means OTP protection.
Thanks
Jaime
>
> > >> + buf->locked = 0;
> > >> + buf->start = MACRONIX_30LFXG18AC_OTP_START_BYTE;
> > >> + buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
> > >> +
> > >> + *retlen = sizeof(*buf);
> > >> +
> > >> + return 0;
> > >> +}
> > >> +
> > >> +static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand)
> > >> +{
> > >> + uint8_t feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> > >> +
> > >> + feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN;
> > >> + return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
> > >> + feature_buf);
> > >> +}
> > >> +
> > >> +static int macronix_30lfxg18ac_otp_disable(struct nand_chip *nand)
> > >> +{
> > >> + uint8_t feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> > >> +
> > >> + return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
> > >> + feature_buf);
> > >> +}
> > >> +
> > >> +static int __macronix_30lfxg18ac_rw_otp(struct mtd_info *mtd,
> > >> + loff_t offs_in_flash,
> > >> + size_t len, size_t *retlen,
> > >> + u_char *buf, bool write)
> > >> +{
> > >> + struct nand_chip *nand;
> > >> + size_t bytes_handled;
> > >> + off_t offs_in_page;
> > >> + uint64_t page;
> > >> + void *dma_buf;
> > >> + int ret;
> > >> +
> > >> + /* 'nand_prog/read_page_op()' may use 'buf' as DMA buffer,
> > >> + * so allocate properly aligned memory for it. This is
> > >> + * needed because cross page accesses may lead to unaligned
> > >> + * buffer address for DMA.
> > >> + */
> > >> + dma_buf = kmalloc(MACRONIX_30LFXG18AC_OTP_PAGE_SIZE, GFP_KERNEL);
> > >> + if (!dma_buf)
> > >> + return -ENOMEM;
> > >> +
> > >> + nand = mtd_to_nand(mtd);
> > >> + nand_select_target(nand, 0);
> > >> +
> > >> + ret = macronix_30lfxg18ac_otp_enable(nand);
> > >> + if
Re: [PATCH 0/7] Add a DRM driver to support AI Processing Unit (APU)
Jeffrey Hugo writes: > On 5/17/2023 8:52 AM, Alexandre Bailon wrote: >> This adds a DRM driver that implements communication between the CPU and an >> APU. The driver target embedded device that usually run inference using some >> prebuilt models. The goal is to provide common infrastructure that could be >> re-used to support many accelerators. Both kernel, userspace and firmware >> tries >> to use standard and existing to leverage the development and maintenance >> effort. >> The series implements two platform drivers, one for simulation and another >> one for >> the mt8183 (compatible with mt8365). > > This looks like the 3 existing Accel drivers. Why is this in DRM? Yes, this belongs in accel. I think Alex had some issues around the infra in accel with device nodes not appearing/opening properly, but I'll let him comment there. But either way, the right approach should be to fix any issues in accel and move it there. [...] >> .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 ++ >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/apu/Kconfig | 22 + >> drivers/gpu/drm/apu/Makefile | 10 + >> drivers/gpu/drm/apu/apu_drv.c | 282 + >> drivers/gpu/drm/apu/apu_gem.c | 230 +++ >> drivers/gpu/drm/apu/apu_internal.h| 205 ++ >> drivers/gpu/drm/apu/apu_sched.c | 592 ++ >> drivers/gpu/drm/apu/simu_apu.c| 313 + >> include/uapi/drm/apu_drm.h| 81 +++ > > "apu" seems too generic. We already have 3 "AI processing units" over > in drivers/accel already... Indeed, it is generic, but that's kind of the point for this driver since it's targetted at generalizing the interface with "AI processing units" on a growing number of embedded SoCs (ARM, RISC-V, etc.) In addition, the generic naming is intentional because the goal is bigger than the kernel and is working towards a generic, shared "libAPU" userspace[1], but also common firmware for DSP-style inference engines (e.g. analgous Sound Open Firmware for audio DSPs.) As usual, the various SoC vendors use different names (APU, NPU, NN unit, etc.) but we'd like a generic name for the class of devices targetted by this driver. And unfortunately, it looks like the equally generic "Versatile processing unit" is already taken Intel's drivers/accel/ivpu. :) Maybe since this is more about generalizing the interface between the CPU running linux and the APU, what about the name apu_if? But I guess that applies to the other 3 drivers in drivers/accell also. Hmmm... Naming things is hard[2], so we're definitly open to other ideas. Any suggestions? Kevin [1] https://gitlab.baylibre.com/baylibre/libapu/libapu [2] "There are 2 hard problems in computer science: cache invalidation, naming things and off-by-1 errors." -- https://twitter.com/secretGeek/status/7269997868
[PATCH v2] drm/nouveau: don't detect DSM for non-NVIDIA device
The call site of nouveau_dsm_pci_probe() uses single set of output
variables for all invocations. So, we must not write anything to them
unless it's an NVIDIA device. Otherwise, if we are called with another
device after the NVIDIA device, we'll clober the result of the NVIDIA
device.
For example, if the other device doesn't have _PR3 resources, the
detection later would miss the presence of power resource support, and
the rest of the code will keep using Optimus DSM, breaking power
management for that machine.
Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run
this detection on a non-NVIDIA device anyway. Thus, check at the
beginning of the detection code if this is an NVIDIA card, and just
return if it isn't.
This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-:
wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and
landed earlier, fixes runtime power management of the NVIDIA card in
Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code
will "timeout", sometimes hanging userspace.
As a bonus, we'll also stop preventing _PR3 usage from the bridge for
unrelated devices, which is always nice, I guess.
Signed-off-by: Ratchanan Srirattanamet
Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79
---
V1 -> V2:
- Update the changelog to indicate that it now actually fixes the issue.
- Add 'Closes:' tag.
drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 8cf096f841a9..a2ae8c21e4dc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -220,6 +220,9 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev,
acpi_handle *dhandle_out
int optimus_funcs;
struct pci_dev *parent_pdev;
+ if (pdev->vendor != PCI_VENDOR_ID_NVIDIA)
+ return;
+
*has_pr3 = false;
parent_pdev = pci_upstream_bridge(pdev);
if (parent_pdev) {
base-commit: 5fe326b4467689ef3690491ee2ad25ff4d81fe59
--
2.34.1
Re: [PATCH] MAINTAINERS: Add Carl/Pranjal as QAIC reviewers
On 5/23/2023 9:44 PM, Jeffrey Hugo wrote: Carl and Pranjal have been reviewing the QAIC patches. List them as reviewers so that they are copied on all developments which will make it easier for them to continue reviewing QAIC patches. Signed-off-by: Jeffrey Hugo --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7e0b87d5aa2e..a0ec9ee090a4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17381,6 +17381,8 @@ F: include/dt-bindings/clock/qcom,* QUALCOMM CLOUD AI (QAIC) DRIVER M:Jeffrey Hugo +R: Carl Vanderlip +R: Pranjal Ramajor Asha Kanojiya L:linux-arm-...@vger.kernel.org L:dri-devel@lists.freedesktop.org S:Supported ACK Reviewed-by: Pranjal Ramajor Asha Kanojiya
Re: [PATCH] MAINTAINERS: Add Carl/Pranjal as QAIC reviewers
On 5/23/2023 9:14 AM, Jeffrey Hugo wrote: Carl and Pranjal have been reviewing the QAIC patches. List them as reviewers so that they are copied on all developments which will make it easier for them to continue reviewing QAIC patches. Signed-off-by: Jeffrey Hugo --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7e0b87d5aa2e..a0ec9ee090a4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17381,6 +17381,8 @@ F: include/dt-bindings/clock/qcom,* QUALCOMM CLOUD AI (QAIC) DRIVER M:Jeffrey Hugo +R: Carl Vanderlip +R: Pranjal Ramajor Asha Kanojiya L:linux-arm-...@vger.kernel.org L:dri-devel@lists.freedesktop.org S:Supported ACK
Re: [RESEND PATCH v3] mtd: rawnand: macronix: OTP access for MX30LFxG18AC
On 24.05.2023 09:33, liao jaime wrote:
> Hi Miquel
>
>>
>> Hi Arseniy,
>>
>> avkras...@sberdevices.ru wrote on Mon, 15 May 2023 12:49:50 +0300:
>>
>>> Hello @Miquel!
>>>
>>> Sorry, but who could review this patch? :) IIUC this logic is very hw
>>> specific and we need
>>> someone who knows it well? I tested this patch on our devices (with already
>>> known Meson NAND
>>> controller).
>>
>> + Jaime, who might test
>>
>>>
>>> Thanks, Arseniy
>>>
>>> On 11.05.2023 21:21, Arseniy Krasnov wrote:
Cc: Mason Yang and Boris Brezillon
On 11.05.2023 18:21, Arseniy Krasnov wrote:
> This adds support for OTP area access on MX30LFxG18AC chip series.
>
> Changelog:
> v1 -> v2:
> * Add slab.h include due to kernel test robot error.
> v2 -> v3:
> * Use 'uint64_t' as input argument for 'do_div()' instead
> of 'unsigned long' due to kernel test robot error.
>
> Signed-off-by: Arseniy Krasnov
> ---
> drivers/mtd/nand/raw/nand_macronix.c | 213 +++
> 1 file changed, 213 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_macronix.c
> b/drivers/mtd/nand/raw/nand_macronix.c
> index 1472f925f386..2301f990678e 100644
> --- a/drivers/mtd/nand/raw/nand_macronix.c
> +++ b/drivers/mtd/nand/raw/nand_macronix.c
> @@ -6,6 +6,7 @@
> * Author: Boris Brezillon
> */
>
> +#include
> #include "linux/delay.h"
> #include "internals.h"
>
> @@ -31,6 +32,20 @@
>
> #define MXIC_CMD_POWER_DOWN 0xB9
>
> +#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90
> +#define MACRONIX_30LFXG18AC_OTP_START_PAGE0
> +#define MACRONIX_30LFXG18AC_OTP_PAGES 30
> +#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE 2112
> +#define MACRONIX_30LFXG18AC_OTP_START_BYTE\
> + (MACRONIX_30LFXG18AC_OTP_START_PAGE * \
> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
> +#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES\
> + (MACRONIX_30LFXG18AC_OTP_PAGES *\
> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
> +
> +#define MACRONIX_30LFXG18AC_OTP_ENBIT(0)
> +#define MACRONIX_30LFXG18AC_OTP_LOCKEDBIT(1)
> +
> struct nand_onfi_vendor_macronix {
>u8 reserved;
>u8 reliability_func;
> @@ -316,6 +331,203 @@ static void
> macronix_nand_deep_power_down_support(struct nand_chip *chip)
>chip->ops.resume = mxic_nand_resume;
> }
>
> +static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd, size_t
> len,
> + size_t *retlen,
> + struct otp_info *buf)
> +{
> + if (len < sizeof(*buf))
> + return -EINVAL;
> +
> + /* Don't know how to check that OTP is locked. */
>>
>> Jaime, any idea?
>
> OTP info could be check by GET_FEATURE command.
> GET_FEATURE command with address 90h could read sub-feature
> parameter table, P1 is "3" means OTP protection.
>
> Thanks
> Jaime
>
Hello Jaime, thanks for quick reply!
I have two devices - with locked and unlocked OTP. I call the following thing
for each of them:
@@ -339,6 +341,26 @@ static int macronix_30lfxg18ac_get_otp_info(struct
mtd_info *mtd, size_t len,
return -EINVAL;
/* Don't know how to check that OTP is locked. */
+ {
+ u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
+ struct nand_chip *nand;
+ int res;
+
+ nand = mtd_to_nand(mtd);
+
+ nand_select_target(nand, 0);
+
+ res = nand_get_features(nand, 0x90, feature_buf);
+
+ nand_deselect_target(nand);
+
+ printk(KERN_EMERG "\n\nRES %i OTP BUF %hhx %hhx %hhx
%hhx\n\n\n",
+ res,
+ feature_buf[0],
+ feature_buf[1],
+ feature_buf[2],
+ feature_buf[3]);
+ }
buf->locked = 0;
buf->start = MACRONIX_30LFXG18AC_OTP_START_BYTE;
buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
And get for both devices:
[4.228721] RES 0 OTP BUF 0 0 0 0
May be i'm doing something wrong?
Thanks, Arseniy
>>
> + buf->locked = 0;
> + buf->start = MACRONIX_30LFXG18AC_OTP_START_BYTE;
> + buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
> +
> + *retlen = sizeof(*buf);
> +
> + return 0;
> +}
> +
> +static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand)
> +{
> + uint8_t feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> +
> + feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN;
> + return nand_set_features(nand, ONFI_FEATURE_ADDR_30LFXG18AC_OTP,
> + feature_buf);
> +}
> +
> +static int
Re: [PATCH 06/36] drm/amd/display: add CRTC driver-specific property for gamma TF
On Tue, 23 May 2023 21:14:50 -0100
Melissa Wen wrote:
> Hook up driver-specific atomic operations for managing AMD color
> properties and create AMD driver-specific color management properties
> and attach them according to HW capabilities defined by `struct
> dc_color_caps`. Add enumerated transfer function property to DRM CRTC
> gamma to convert to wire encoding with or without a user gamma LUT.
> Enumerated TFs are not supported yet by the DRM color pipeline,
> therefore, create a DRM enum list with the predefined TFs supported by
> the AMD display driver.
>
> Co-developed-by: Joshua Ashton
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 36 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 8 +++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 22 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 ++-
> 4 files changed, 137 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 389396eac222..88af075e6c18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1247,6 +1247,38 @@ amdgpu_display_user_framebuffer_create(struct
> drm_device *dev,
> return &amdgpu_fb->base;
> }
>
> +static const struct drm_prop_enum_list drm_transfer_function_enum_list[] = {
> + { DRM_TRANSFER_FUNCTION_DEFAULT, "Default" },
> + { DRM_TRANSFER_FUNCTION_SRGB, "sRGB" },
> + { DRM_TRANSFER_FUNCTION_BT709, "BT.709" },
> + { DRM_TRANSFER_FUNCTION_PQ, "PQ (Perceptual Quantizer)" },
> + { DRM_TRANSFER_FUNCTION_LINEAR, "Linear" },
> + { DRM_TRANSFER_FUNCTION_UNITY, "Unity" },
> + { DRM_TRANSFER_FUNCTION_HLG, "HLG (Hybrid Log Gamma)" },
> + { DRM_TRANSFER_FUNCTION_GAMMA22, "Gamma 2.2" },
> + { DRM_TRANSFER_FUNCTION_GAMMA24, "Gamma 2.4" },
> + { DRM_TRANSFER_FUNCTION_GAMMA26, "Gamma 2.6" },
> +};
> +
> +#ifdef AMD_PRIVATE_COLOR
> +static int
> +amdgpu_display_create_color_properties(struct amdgpu_device *adev)
> +{
> + struct drm_property *prop;
> +
> + prop = drm_property_create_enum(adev_to_drm(adev),
> + DRM_MODE_PROP_ENUM,
> + "AMD_REGAMMA_TF",
Hi,
is this REGAMMA element capable of applying only optical-to-electrical
direction of the listed TFs?
I was expecting that the listed TF names would include an explanation
of the direction, for example "PQ EOTF" vs. "inverse PQ EOTF".
Very specifically "inverse EOTF" and not "OETF" because they
generally are not the same concept.
PQ defines only EOTF while HLG for example defines OETF (HLG defines
its EOTF as a combination of inverse HLG OETF and a parameterised HLG
OOTF). So if you say "PQ TF" I will assume it means
electrical-to-optical and if you say HLG TF I might assume
optical-to-electrical. I think these enum names should be more explicit
about what they refer to, to avoid any ambiguity.
What kind of TF is "Unity"?
This patch is not adding any docs for any of these. Is there another
patch that does?
I'm still confused about how this "private" API should be thought of.
Should it be documented at all? Is it free to use for userspace?
Was the expectation that only the Steam Deck distribution would enable
these in the kernel, and no-one else? And if anyone builds their own
kernel with these enabled? So my ask for docs may or may not be
warranted.
I don't like the names degamma/regamma/gamma at all. I don't like
calling something a LUT when it can have a parametric or enumerated
curve. I don't like calling an element a transfer function if it could
be a shaper or a combination of TF and shaper and maybe something else
(i.e. a LUT).
But that's nothing new. If the expectation is that no-one should use
these, then it's fine, and you don't need to CC me. You know I will
always respond with similar comments about documenting things, having
good names, etc. that is important for generic userspace, which is just
not needed for "no-users UAPI". ;-)
Thanks,
pq
> + drm_transfer_function_enum_list,
> +
> ARRAY_SIZE(drm_transfer_function_enum_list));
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.regamma_tf_property = prop;
> +
> + return 0;
> +}
> +#endif
> +
> const struct drm_mode_config_funcs amdgpu_mode_funcs = {
> .fb_create = amdgpu_display_user_framebuffer_create,
> };
> @@ -1323,6 +1355,10 @@ int amdgpu_display_modeset_create_props(struct
> amdgpu_device *adev)
> return -ENOMEM;
> }
>
> +#ifdef AMD_PRIVATE_COLOR
> + if (amdgpu_display_create_color_properties(adev))
> + return -ENOMEM;
> +#endif
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index
Re: [PATCH 0/5] accel/ivpu: Add debugfs support
Hi On Wed, May 24, 2023 at 10:55:08AM +0300, Oded Gabbay wrote: > On Wed, May 24, 2023 at 10:49 AM Stanislaw Gruszka > wrote: > > > > Add debugfs support for ivpu driver, most importantly firmware loging > > and tracing. > Hi, > Without looking at the code I have 2 comments/questions: > > 1. Please add an ABI documentation in Documentation/ABI/testing/ or > Documentation/ABI/stable (if you are feeling courageous). You can see > for example habana's file at > Documentation/ABI/testing/debugfs-driver-habanalabs We do not promise any ABI compatibility for debugfs for ivpu, we can add, remove or modify at any time. Hence make no sense to add documentation files to Documentation/ABI/ for us. > 2. Is this synced with Christian's upcoming changes to the debugfs > infra in drm ? If not, I might suggest to sync with that and wait > until those patches are merged because they change the layout of > debugfs nodes. Is not synced. We can wait before Christian changes get in, what hopefully will happen soon. But if not, ivpu debugfs can be modified along with the changes. I can assist with that. Regards Stanislaw
[PATCH v3 0/3] phy: mtk-mipi-csi: add driver for CSI phy
Adding a new driver for the MIPI CSI CD-PHY module v 0.5 embedded in some Mediatek soc, such as the MT8365 This driver was adapted from https://patchwork.kernel.org/project/linux-mediatek/cover/20200708104023.3225-1-louis@mediatek.com/ v1 can be found here: https://lore.kernel.org/all/20230403071929.360911-1-jstep...@baylibre.com/ v2 can be found here: https://lore.kernel.org/all/20230515090551.1251389-1-jstep...@baylibre.com/ Changelog Changes in v3: Binding file: - rename compatible string mediatek,phy-mipi-csi-0-5 -> mediatek,mt8365-csi-rx - rename binding file to be as compatible string - change property mediatek,is_cdphy -> mediatek,phy-type using an enum value instead of boolean for scalability - remove status property from example nodes - rename example node name 'mipi_rx_csi0: mipi_rx_csi0@11c1' -> 'csi0_rx: phy@11c1' - put reg address in lower case include/dt-bindings/phy/phy.h: - add PHY_TYPE_CDPHY definition Driver: - rename compatible string - rename property mediatek,is_cdphy -> mediatek,phy-type - rename CSIx* macro to CSIX* (x -> X) - fix style issue on the driver data structure - update MODULE_DESCRIPTION as suggested by Angelo and update the kconfig module description to match it - add dphy /cdphy eq tuning function to factor the code and increase readability - fix typo __PHY_MTK__MIPI_CSI__C_0_5_RX_REG_H_ --> __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H_ - reword commit message to update my contributions - added missing copyright - added module name in Kconfig Changes in v2: - fix all comments on bindings - move the binding chunk from driver to binding commit - fix dt_binding_check error (reported by DT_CHECKER_FLAGS) - use a more generic compatible string - add a new dt properties to simplify the driver "mediatek,is_cdphy" - rename the driver and the corresponding file to include version - drop of_match_ptr() - use devm_platform_ioremap_resource - use phy-mtk-io.h api instead of regmap - rework the driver to use dt nodes to declare PHY instead of an array in the driver - remove useless define for unused registers - remove support for CSI0A/B because it cannot be tested, and it simplifies the driver for a first review - edit commit message and bindings to be more descriptive about the hardware Florian Sylvestre (1): dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5 Julien Stephan (1): dt-bindings: phy: add PHY_TYPE_CDPHY definition Phi-bang Nguyen (1): phy: mtk-mipi-csi: add driver for CSI phy .../bindings/phy/mediatek,mt8365-csi-rx.yaml | 68 + MAINTAINERS | 7 + drivers/phy/mediatek/Kconfig | 8 + drivers/phy/mediatek/Makefile | 2 + .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h| 58 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c | 272 ++ include/dt-bindings/phy/phy.h | 3 +- 7 files changed, 417 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c -- 2.40.1
[PATCH v3 1/3] dt-bindings: phy: add PHY_TYPE_CDPHY definition
Add definition for CDPHY phy type that can be configured in either D-PHY mode or C-PHY mode Signed-off-by: Julien Stephan --- include/dt-bindings/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h index 6b901b342348..a19d85dbbf16 100644 --- a/include/dt-bindings/phy/phy.h +++ b/include/dt-bindings/phy/phy.h @@ -23,5 +23,6 @@ #define PHY_TYPE_DPHY 10 #define PHY_TYPE_CPHY 11 #define PHY_TYPE_USXGMII 12 +#define PHY_TYPE_CDPHY 13 #endif /* _DT_BINDINGS_PHY */ -- 2.40.1
[PATCH v3 2/3] dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5
From: Florian Sylvestre
This adds the bindings, for the MIPI CD-PHY module v0.5 embedded in
some Mediatek soc, such as the mt8365
Signed-off-by: Florian Sylvestre
Signed-off-by: Julien Stephan
---
.../bindings/phy/mediatek,mt8365-csi-rx.yaml | 67 +++
MAINTAINERS | 6 ++
2 files changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
new file mode 100644
index ..a1bd96a98051
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek, BayLibre
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt8365-csi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Sensor Interface MIPI CSI CD-PHY
+
+maintainers:
+ - Julien Stephan
+ - Andy Hsieh
+
+description:
+ The SENINF CD-PHY is a set of CD-PHY connected to the SENINF CSI-2
+ receivers. The number of PHYs depends on the SoC model.
+ Depending on the SoC model, each PHYs can be either CD-PHY or D-PHY only
+ capable.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8365-csi-rx
+
+ reg:
+maxItems: 1
+
+ '#phy-cells':
+const: 0
+
+ mediatek,phy-type:
+description:
+ Specify the phy type. Supported phy are D-PHY only or CD-PHY capable
phys.
+ See include/dt-bindings/phy/phy.h for constants.
+enum: [10, 13]
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - mediatek,phy-type
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ csi0_rx: phy@11c1 {
+compatible = "mediatek,mt8365-csi-rx";
+reg = <0 0x11c1 0 0x2000>;
+mediatek,phy-type = ;
+#phy-cells = <0>;
+ };
+
+ csi1_rx: phy@11c12000 {
+compatible = "mediatek,mt8365-csi-rx";
+reg = <0 0x11c12000 0 0x2000>;
+mediatek,phy-type = ;
+#phy-cells = <0>;
+ };
+};
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index b81e9fcc66cb..5da594fbb761 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13184,6 +13184,12 @@ F:
Documentation/devicetree/bindings/media/mediatek-vpu.txt
F: drivers/media/platform/mediatek/vcodec/
F: drivers/media/platform/mediatek/vpu/
+MEDIATEK MIPI-CSI CDPHY DRIVER
+M: Julien Stephan
+M: Andy Hsieh
+S: Supported
+F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
+
MEDIATEK MMC/SD/SDIO DRIVER
M: Chaotian Jing
S: Maintained
--
2.40.1
[PATCH v3 3/3] phy: mtk-mipi-csi: add driver for CSI phy
From: Phi-bang Nguyen This is a new driver that supports the MIPI CSI CD-PHY version 0.5 The number of PHYs depend on the SoC. Each PHY can support D-PHY only or CD-PHY configuration. The driver supports only D-PHY mode, so CD-PHY compatible PHY are configured in D-PHY mode. Signed-off-by: Louis Kuo Signed-off-by: Phi-bang Nguyen [Julien Stephan: refactor code] [Julien Stephan: simplify driver model: one instance per phy vs one instance for all phys] Co-developed-by: Julien Stephan Signed-off-by: Julien Stephan --- MAINTAINERS | 1 + drivers/phy/mediatek/Kconfig | 12 + drivers/phy/mediatek/Makefile | 2 + .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h| 62 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c | 278 ++ 5 files changed, 355 insertions(+) create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c diff --git a/MAINTAINERS b/MAINTAINERS index 5da594fbb761..e505023ffda1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13189,6 +13189,7 @@ M: Julien Stephan M: Andy Hsieh S: Supported F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml +F: drivers/phy/mediatek/phy-mtk-mipi-csi-0-5* MEDIATEK MMC/SD/SDIO DRIVER M: Chaotian Jing diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig index 3125ecb5d119..7088382ebc9e 100644 --- a/drivers/phy/mediatek/Kconfig +++ b/drivers/phy/mediatek/Kconfig @@ -74,3 +74,15 @@ config PHY_MTK_DP select GENERIC_PHY help Support DisplayPort PHY for MediaTek SoCs. + +config PHY_MTK_MIPI_CSI_0_5 + tristate "MediaTek MIPI CSI CD-PHY v0.5 Driver" + depends on ARCH_MEDIATEK || COMPILE_TEST + depends on OF + select GENERIC_PHY + help + Enable this to support the MIPI CSI CD-PHY receiver version 0.5. + The driver supports multiple CSI cdphy ports simultaneously. + + To compile this driver as a module, choose M here: the + module will be called phy-mtk-mipi-csi-0-5. diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile index c9a50395533e..63f2fa3ec7e5 100644 --- a/drivers/phy/mediatek/Makefile +++ b/drivers/phy/mediatek/Makefile @@ -19,3 +19,5 @@ phy-mtk-mipi-dsi-drv-y:= phy-mtk-mipi-dsi.o phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o + +obj-$(CONFIG_PHY_MTK_MIPI_CSI_0_5) += phy-mtk-mipi-csi-0-5.o diff --git a/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h new file mode 100644 index ..97b4c27a1699 --- /dev/null +++ b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h @@ -0,0 +1,62 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2023, MediaTek Inc. + * Copyright (c) 2023, BayLibre Inc. + */ + +#ifndef __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__ +#define __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__ + +/* + * CSI1 and CSI2 are identical, and similar to CSI0. All CSIX macros are + * applicable to the three PHYs. Where differences exist, they are denoted by + * macro names using CSI0 and CSI1, the latter being applicable to CSI1 and + * CSI2 alike. + */ + +#define MIPI_RX_ANA00_CSIXA0x +#define RG_CSI0A_CPHY_EN BIT(0) +#define RG_CSIXA_EQ_PROTECT_EN BIT(1) +#define RG_CSIXA_BG_LPF_EN BIT(2) +#define RG_CSIXA_BG_CORE_ENBIT(3) +#define RG_CSIXA_DPHY_L0_CKMODE_EN BIT(5) +#define RG_CSIXA_DPHY_L0_CKSEL BIT(6) +#define RG_CSIXA_DPHY_L1_CKMODE_EN BIT(8) +#define RG_CSIXA_DPHY_L1_CKSEL BIT(9) +#define RG_CSIXA_DPHY_L2_CKMODE_EN BIT(11) +#define RG_CSIXA_DPHY_L2_CKSEL BIT(12) + +#define MIPI_RX_ANA18_CSIXA0x0018 +#define RG_CSI0A_L0_T0AB_EQ_IS GENMASK(5, 4) +#define RG_CSI0A_L0_T0AB_EQ_BW GENMASK(7, 6) +#define RG_CSI0A_L1_T1AB_EQ_IS GENMASK(21, 20) +#define RG_CSI0A_L1_T1AB_EQ_BW GENMASK(23, 22) +#define RG_CSI0A_L2_T1BC_EQ_IS GENMASK(21, 20) +#define RG_CSI0A_L2_T1BC_EQ_BW GENMASK(23, 22) +#define RG_CSI1A_L0_EQ_IS GENMASK(5, 4) +#define RG_CSI1A_L0_EQ_BW GENMASK(7, 6) +#define RG_CSI1A_L1_EQ_IS GENMASK(21, 20) +#define RG_CSI1A_L1_EQ_BW GENMASK(23, 22) +#define RG_CSI1A_L2_EQ_IS GENMASK(5, 4) +#define RG_CSI1A_L2_EQ_BW GENMASK(7, 6) + +#define MIPI_RX_ANA1C_CSIXA0x001c +#define MIPI_RX_ANA20_CSI0A0x0020 + +#define MIPI_RX_ANA24_CSIXA
[PATCH v2] drm/panel: samsung-s6d7aa0: use pointer for drm_mode in panel desc struct
Fixes compilation issues with older GCC versions and Clang after
changes introduced in commit 6810bb390282 ("drm/panel: Add Samsung
S6D7AA0 panel controller driver"). Tested with GCC 13.1.1, GCC 6.4.0
and Clang 16.0.3.
Fixes the following errors with Clang:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer
element is not a compile-time constant
.drm_mode = s6d7aa0_lsl080al02_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: error: initializer
element is not a compile-time constant
.drm_mode = s6d7aa0_lsl080al03_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: error: initializer
element is not a compile-time constant
.drm_mode = s6d7aa0_ltl101at01_mode,
^~~
3 errors generated.
Fixes the following errors with GCC:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer
element is not constant
.drm_mode = s6d7aa0_lsl080al02_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: note: (near
initialization for 's6d7aa0_lsl080al02_desc.drm_mode')
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: error: initializer
element is not constant
.drm_mode = s6d7aa0_lsl080al03_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: note: (near
initialization for 's6d7aa0_lsl080al03_desc.drm_mode')
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: error: initializer
element is not constant
.drm_mode = s6d7aa0_ltl101at01_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: note: (near
initialization for 's6d7aa0_ltl101at01_desc.drm_mode')
Reported-by: Nathan Chancellor
Link:
https://lore.kernel.org/lkml/20230523180212.GA1401867@dev-arch.thelio-3990X
Reported-by: kernelci.org bot
Link: https://lore.kernel.org/llvm/646c6def.a70a0220.58c1a.9...@mx.google.com
Fixes: 6810bb390282 ("drm/panel: Add Samsung S6D7AA0 panel controller driver")
Signed-off-by: Artur Weber
---
v2: expanded commit message
---
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
index f532aa018428..102e1fc7ee38 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
@@ -37,7 +37,7 @@ struct s6d7aa0_panel_desc {
unsigned int panel_type;
int (*init_func)(struct s6d7aa0 *ctx);
int (*off_func)(struct s6d7aa0 *ctx);
- const struct drm_display_mode drm_mode;
+ const struct drm_display_mode *drm_mode;
unsigned long mode_flags;
u32 bus_flags;
bool has_backlight;
@@ -309,7 +309,7 @@ static const struct s6d7aa0_panel_desc
s6d7aa0_lsl080al02_desc = {
.panel_type = S6D7AA0_PANEL_LSL080AL02,
.init_func = s6d7aa0_lsl080al02_init,
.off_func = s6d7aa0_lsl080al02_off,
- .drm_mode = s6d7aa0_lsl080al02_mode,
+ .drm_mode = &s6d7aa0_lsl080al02_mode,
.mode_flags = MIPI_DSI_MODE_VSYNC_FLUSH | MIPI_DSI_MODE_VIDEO_NO_HFP,
.bus_flags = DRM_BUS_FLAG_DE_HIGH,
@@ -412,7 +412,7 @@ static const struct s6d7aa0_panel_desc
s6d7aa0_lsl080al03_desc = {
.panel_type = S6D7AA0_PANEL_LSL080AL03,
.init_func = s6d7aa0_lsl080al03_init,
.off_func = s6d7aa0_lsl080al03_off,
- .drm_mode = s6d7aa0_lsl080al03_mode,
+ .drm_mode = &s6d7aa0_lsl080al03_mode,
.mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET,
.bus_flags = 0,
@@ -440,7 +440,7 @@ static const struct s6d7aa0_panel_desc
s6d7aa0_ltl101at01_desc = {
.panel_type = S6D7AA0_PANEL_LTL101AT01,
.init_func = s6d7aa0_lsl080al03_init, /* Similar init to LSL080AL03 */
.off_func = s6d7aa0_lsl080al03_off,
- .drm_mode = s6d7aa0_ltl101at01_mode,
+ .drm_mode = &s6d7aa0_ltl101at01_mode,
.mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET,
.bus_flags = 0,
@@ -458,7 +458,7 @@ static int s6d7aa0_get_modes(struct drm_panel *panel,
if (!ctx)
return -EINVAL;
- mode = drm_mode_duplicate(connector->dev, &ctx->desc->drm_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->desc->drm_mode);
if (!mode)
return -ENOMEM;
base-commit: 37cee4876a45a5c3da79a83d34ed4f3c68548aef
--
2.40.1
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #87 from Stuart Foster (smf-li...@virginmedia.com) --- Is it worth the effort of bisecting this as it seems to be on a lot of kernel versions ? thanks -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/amd/display: clean up some inconsistent indenting
No functional modification involved. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.c:269 dcn314_update_bw_bounding_box_fpu() warn: inconsistent indenting. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5305 Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c index 318b9c2bc9be..c9afddd11589 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c @@ -265,8 +265,7 @@ void dcn314_update_bw_bounding_box_fpu(struct dc *dc, struct clk_bw_params *bw_p } dcn20_patch_bounding_box(dc, &dcn3_14_soc); - - dml_init_instance(&dc->dml, &dcn3_14_soc, &dcn3_14_ip, DML_PROJECT_DCN314); + dml_init_instance(&dc->dml, &dcn3_14_soc, &dcn3_14_ip, DML_PROJECT_DCN314); } static bool is_dual_plane(enum surface_pixel_format format) -- 2.20.1.7.g153144c
[PATCH 2/2] drm/amd/display: clean up some inconsistent indenting
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn321/dcn321_fpu.c:556
dcn321_update_bw_bounding_box_fpu() warn: inconsistent indenting.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5304
Signed-off-by: Jiapeng Chong
---
.../amd/display/dc/dml/dcn321/dcn321_fpu.c| 242 +-
1 file changed, 121 insertions(+), 121 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c
index ffd7c3c1b142..1aaff6f2d453 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c
@@ -553,148 +553,148 @@ void dcn321_update_bw_bounding_box_fpu(struct dc *dc,
struct clk_bw_params *bw_p
dc->dml.soc.dispclk_dppclk_vco_speed_mhz =
dc->clk_mgr->dentist_vco_freq_khz / 1000.0;
/* Overrides Clock levelsfrom CLK Mgr table entries as reported by PM
FW */
- if (dc->debug.use_legacy_soc_bb_mechanism) {
- unsigned int i = 0, j = 0, num_states = 0;
-
- unsigned int dcfclk_mhz[DC__VOLTAGE_STATES] = {0};
- unsigned int dram_speed_mts[DC__VOLTAGE_STATES] = {0};
- unsigned int
optimal_uclk_for_dcfclk_sta_targets[DC__VOLTAGE_STATES] = {0};
- unsigned int
optimal_dcfclk_for_uclk[DC__VOLTAGE_STATES] = {0};
-
- unsigned int dcfclk_sta_targets[DC__VOLTAGE_STATES] =
{615, 906, 1324, 1564};
- unsigned int num_dcfclk_sta_targets = 4,
num_uclk_states = 0;
- unsigned int max_dcfclk_mhz = 0, max_dispclk_mhz = 0,
max_dppclk_mhz = 0, max_phyclk_mhz = 0;
-
- for (i = 0; i < MAX_NUM_DPM_LVL; i++) {
- if (bw_params->clk_table.entries[i].dcfclk_mhz
> max_dcfclk_mhz)
- max_dcfclk_mhz =
bw_params->clk_table.entries[i].dcfclk_mhz;
- if (bw_params->clk_table.entries[i].dispclk_mhz
> max_dispclk_mhz)
- max_dispclk_mhz =
bw_params->clk_table.entries[i].dispclk_mhz;
- if (bw_params->clk_table.entries[i].dppclk_mhz
> max_dppclk_mhz)
- max_dppclk_mhz =
bw_params->clk_table.entries[i].dppclk_mhz;
- if (bw_params->clk_table.entries[i].phyclk_mhz
> max_phyclk_mhz)
- max_phyclk_mhz =
bw_params->clk_table.entries[i].phyclk_mhz;
- }
- if (!max_dcfclk_mhz)
- max_dcfclk_mhz =
dcn3_21_soc.clock_limits[0].dcfclk_mhz;
- if (!max_dispclk_mhz)
- max_dispclk_mhz =
dcn3_21_soc.clock_limits[0].dispclk_mhz;
- if (!max_dppclk_mhz)
- max_dppclk_mhz =
dcn3_21_soc.clock_limits[0].dppclk_mhz;
- if (!max_phyclk_mhz)
- max_phyclk_mhz =
dcn3_21_soc.clock_limits[0].phyclk_mhz;
-
- if (max_dcfclk_mhz >
dcfclk_sta_targets[num_dcfclk_sta_targets-1]) {
- // If max DCFCLK is greater than the max DCFCLK
STA target, insert into the DCFCLK STA target array
- dcfclk_sta_targets[num_dcfclk_sta_targets] =
max_dcfclk_mhz;
- num_dcfclk_sta_targets++;
- } else if (max_dcfclk_mhz <
dcfclk_sta_targets[num_dcfclk_sta_targets-1]) {
- // If max DCFCLK is less than the max DCFCLK
STA target, cap values and remove duplicates
- for (i = 0; i < num_dcfclk_sta_targets; i++) {
- if (dcfclk_sta_targets[i] >
max_dcfclk_mhz) {
- dcfclk_sta_targets[i] =
max_dcfclk_mhz;
- break;
- }
+ if (dc->debug.use_legacy_soc_bb_mechanism) {
+ unsigned int i = 0, j = 0, num_states = 0;
+
+ unsigned int dcfclk_mhz[DC__VOLTAGE_STATES] = {0};
+ unsigned int dram_speed_mts[DC__VOLTAGE_STATES] = {0};
+ unsigned int
optimal_uclk_for_dcfclk_sta_targets[DC__VOLTAGE_STATES] = {0};
+ unsigned int optimal_dcfclk_for_uclk[DC__VOLTAGE_STATES] = {0};
+
+ unsigned int dcfclk_sta_targets[DC__VOLTAGE_STATES] = {615,
906, 1324, 1564};
+ unsigned int num_dcfclk_sta_targets = 4, num_uclk_states = 0;
+ unsigned int max_dcfclk_mhz = 0, max_dispclk_mhz = 0,
max_dppclk_mhz = 0, max_phyclk_mhz = 0;
+
+ for (i = 0; i < MAX_NUM_DPM_LVL; i++) {
+ if (bw_params->clk_table.en
Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked
On 23.05.2023 17:19, Ashutosh Dixit wrote: pmu_needs_timer() keeps the timer running even when GT is parked, ostensibly to sample requested/actual frequencies. However frequency_sample() has the following: /* Report 0/0 (actual/requested) frequency while parked. */ if (!intel_gt_pm_get_if_awake(gt)) return; The above code prevents frequencies to be sampled while the GT is parked. So we might as well turn off the sampling timer itself in this case and save CPU cycles/power. v2: Instead of turning freq bits off, return false, since no counters will run after this change when GT is parked (Tvrtko) Signed-off-by: Ashutosh Dixit Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index a814583e19fd7..b47d890d4ada1 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -144,6 +144,10 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool gpu_active) struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu); u32 enable; + /* When GPU is idle, at present no counters need to run */ + if (!gpu_active) + return false; + What is then purpose of calling pmu_needs_timer with 2nd arg false? Why not just replace all occurrences of pmu_needs_timer(.., false) with false? And remove the 2nd argument. Regards Andrzej /* * Only some counters need the sampling timer. * @@ -157,17 +161,11 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool gpu_active) */ enable &= frequency_enabled_mask() | ENGINE_SAMPLE_MASK; - /* -* When the GPU is idle per-engine counters do not need to be -* running so clear those bits out. -*/ - if (!gpu_active) - enable &= ~ENGINE_SAMPLE_MASK; /* * Also there is software busyness tracking available we do not * need the timer for I915_SAMPLE_BUSY counter. */ - else if (i915->caps.scheduler & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS) + if (i915->caps.scheduler & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS) enable &= ~BIT(I915_SAMPLE_BUSY); /*
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Make PMU sample array two-dimensional
On 23.05.2023 17:19, Ashutosh Dixit wrote:
No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
2 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index b47d890d4ada1..137e0df9573ee 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -195,33 +195,6 @@ static inline s64 ktime_since_raw(const ktime_t kt)
return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
}
-static unsigned int
-__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
- unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
-
- GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
-
- return idx;
-}
-
-static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
- return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
-}
-
-static void
-store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 val)
-{
- pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
-}
-
-static void
-add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, u32 val,
u32 mul)
-{
- pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val,
mul);
-}
-
static u64 get_rc6(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -240,7 +213,7 @@ static u64 get_rc6(struct intel_gt *gt)
spin_lock_irqsave(&pmu->lock, flags);
if (awake) {
- store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
+ pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;
} else {
/*
* We think we are runtime suspended.
@@ -250,13 +223,13 @@ static u64 get_rc6(struct intel_gt *gt)
* counter value.
*/
val = ktime_since_raw(pmu->sleep_last[gt_id]);
- val += read_sample(pmu, gt_id, __I915_SAMPLE_RC6);
+ val += pmu->sample[gt_id][__I915_SAMPLE_RC6].cur;
}
- if (val < read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED))
- val = read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED);
+ if (val < pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur)
+ val = pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur;
else
- store_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED, val);
+ pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur = val;
spin_unlock_irqrestore(&pmu->lock, flags);
@@ -275,9 +248,8 @@ static void init_rc6(struct i915_pmu *pmu)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
u64 val = __get_rc6(gt);
- store_sample(pmu, i, __I915_SAMPLE_RC6, val);
- store_sample(pmu, i, __I915_SAMPLE_RC6_LAST_REPORTED,
-val);
+ pmu->sample[i][__I915_SAMPLE_RC6].cur = val;
+ pmu->sample[i][__I915_SAMPLE_RC6_LAST_REPORTED].cur =
val;
pmu->sleep_last[i] = ktime_get_raw();
}
}
@@ -287,7 +259,7 @@ static void park_rc6(struct intel_gt *gt)
{
struct i915_pmu *pmu = >->i915->pmu;
- store_sample(pmu, gt->info.id, __I915_SAMPLE_RC6, __get_rc6(gt));
+ pmu->sample[gt->info.id][__I915_SAMPLE_RC6].cur = __get_rc6(gt);
pmu->sleep_last[gt->info.id] = ktime_get_raw();
}
@@ -428,6 +400,12 @@ engines_sample(struct intel_gt *gt, unsigned int period_ns)
}
}
+static void
+add_sample_mult(struct i915_pmu_sample *sample, u32 val, u32 mul)
+{
+ sample->cur += mul_u32_u32(val, mul);
+}
+
static bool
frequency_sampling_enabled(struct i915_pmu *pmu, unsigned int gt)
{
@@ -467,12 +445,12 @@ frequency_sample(struct intel_gt *gt, unsigned int
period_ns)
if (!val)
val = intel_gpu_freq(rps, rps->cur_freq);
- add_sample_mult(pmu, gt_id, __I915_SAMPLE_FREQ_ACT,
+ add_sample_mult(&pmu->sample[gt_id][__I915_SAMPLE_FREQ_ACT],
val, period_ns / 1000);
}
if (pmu->enable & config_mask(__I915_PMU_REQUESTED_FREQUENCY(gt_id))) {
- add_sample_mult(pmu, gt_id, __I915_SAMPLE_FREQ_REQ,
+ add_sample_mult(&pmu->sample[gt_id][__I915_SAMPLE_FREQ_REQ],
intel_rps_get_requested_frequency(rps),
period_ns / 1000);
}
@@ -673,14 +651,12 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
switch (config) {
Re: [PATCH net-next v4 3/6] net: bcmasp: Add support for ASP2.0 Ethernet controller
On Tue, May 23, 2023 at 02:53:44PM -0700, Justin Chen wrote:
> Add support for the Broadcom ASP 2.0 Ethernet controller which is first
> introduced with 72165. This controller features two distinct Ethernet
> ports that can be independently operated.
>
> This patch supports:
>
> - Wake-on-LAN using magic packets
> - basic ethtool operations (link, counters, message level)
> - MAC destination address filtering (promiscuous, ALL_MULTI, etc.)
>
> Signed-off-by: Florian Fainelli
> Signed-off-by: Justin Chen
Hi Justin,
Reviewed-by: Simon Horman
As I see there will be a v5 I have added a few nits from my side.
Feel free to ignore them as you see fit.
...
> +int bcmasp_netfilt_check_dup(struct bcmasp_intf *intf,
> + struct ethtool_rx_flow_spec *fs)
nit: the return type of this function could be bool
> +{
> + struct bcmasp_priv *priv = intf->parent;
> + struct ethtool_rx_flow_spec *cur;
> + size_t fs_size = 0;
> + int i;
> +
> + for (i = 0; i < NUM_NET_FILTERS; i++) {
> + if (!priv->net_filters[i].claimed ||
> + priv->net_filters[i].port != intf->port)
> + continue;
> +
> + cur = &priv->net_filters[i].fs;
> +
> + if (cur->flow_type != fs->flow_type ||
> + cur->ring_cookie != fs->ring_cookie)
> + continue;
> +
> + switch (fs->flow_type & ~(FLOW_EXT | FLOW_MAC_EXT)) {
> + case ETHER_FLOW:
> + fs_size = sizeof(struct ethhdr);
> + break;
> + case IP_USER_FLOW:
> + fs_size = sizeof(struct ethtool_usrip4_spec);
> + break;
> + case TCP_V6_FLOW:
> + case UDP_V6_FLOW:
> + fs_size = sizeof(struct ethtool_tcpip6_spec);
> + break;
> + case TCP_V4_FLOW:
> + case UDP_V4_FLOW:
> + fs_size = sizeof(struct ethtool_tcpip4_spec);
> + break;
> + default:
> + continue;
> + }
> +
> + if (memcmp(&cur->h_u, &fs->h_u, fs_size) ||
> + memcmp(&cur->m_u, &fs->m_u, fs_size))
> + continue;
> +
> + if (cur->flow_type & FLOW_EXT) {
> + if (cur->h_ext.vlan_etype != fs->h_ext.vlan_etype ||
> + cur->m_ext.vlan_etype != fs->m_ext.vlan_etype ||
> + cur->h_ext.vlan_tci != fs->h_ext.vlan_tci ||
> + cur->m_ext.vlan_tci != fs->m_ext.vlan_tci ||
> + cur->h_ext.data[0] != fs->h_ext.data[0])
> + continue;
> + }
> + if (cur->flow_type & FLOW_MAC_EXT) {
> + if (memcmp(&cur->h_ext.h_dest,
> +&fs->h_ext.h_dest, ETH_ALEN) ||
> + memcmp(&cur->m_ext.h_dest,
> +&fs->m_ext.h_dest, ETH_ALEN))
> + continue;
> + }
> +
> + return 1;
> + }
> +
> + return 0;
> +}
...
> +static int bcmasp_is_port_valid(struct bcmasp_priv *priv, int port)
> +{
> + /* Quick sanity check
> + * Ports 0/1 reserved for unimac
> + * Max supported ports is 2
> + */
> + return (port == 0 || port == 1);
nit: unnecessary parentheses
> +}
...
[PATCH v4 01/13] fbdev: Add Kconfig options to select different fb_ops helpers
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig options to select them at once. This will help with making DRM's fbdev emulation code more modular, but can also be used to simplify fbdev's driver configs. v3: * fix select statement (Jingfeng) Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index e8889035c882..6df9bd09454a 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -158,6 +158,27 @@ config FB_DEFERRED_IO bool depends on FB +config FB_IO_HELPERS + bool + depends on FB + select FB_CFB_COPYAREA + select FB_CFB_FILLRECT + select FB_CFB_IMAGEBLIT + +config FB_SYS_HELPERS + bool + depends on FB + select FB_SYS_COPYAREA + select FB_SYS_FILLRECT + select FB_SYS_FOPS + select FB_SYS_IMAGEBLIT + +config FB_SYS_HELPERS_DEFERRED + bool + depends on FB + select FB_DEFERRED_IO + select FB_SYS_HELPERS + config FB_HECUBA tristate depends on FB -- 2.40.1
[PATCH v4 05/13] drm/gma500: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_IO_HELPERS option
Signed-off-by: Thomas Zimmermann
Cc: Patrik Jakobsson
---
drivers/gpu/drm/gma500/Kconfig | 1 +
drivers/gpu/drm/gma500/fbdev.c | 8 +++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 2efc0eb41c64..cd3d92725ed4 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -3,6 +3,7 @@ config DRM_GMA500
tristate "Intel GMA500/600/3600/3650 KMS Framebuffer"
depends on DRM && PCI && X86 && MMU
select DRM_KMS_HELPER
+ select FB_IO_HELPERS if DRM_FBDEV_EMULATION
select I2C
select I2C_ALGOBIT
# GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
diff --git a/drivers/gpu/drm/gma500/fbdev.c b/drivers/gpu/drm/gma500/fbdev.c
index 4f0309548b2b..955cbe9f05a7 100644
--- a/drivers/gpu/drm/gma500/fbdev.c
+++ b/drivers/gpu/drm/gma500/fbdev.c
@@ -5,6 +5,7 @@
*
**/
+#include
#include
#include
@@ -134,13 +135,10 @@ static void psb_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops psb_fbdev_fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_IO_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_setcolreg = psb_fbdev_fb_setcolreg,
- .fb_read = drm_fb_helper_cfb_read,
- .fb_write = drm_fb_helper_cfb_write,
- .fb_fillrect = drm_fb_helper_cfb_fillrect,
- .fb_copyarea = drm_fb_helper_cfb_copyarea,
- .fb_imageblit = drm_fb_helper_cfb_imageblit,
+ __FB_DEFAULT_IO_OPS_DRAW,
.fb_mmap = psb_fbdev_fb_mmap,
.fb_destroy = psb_fbdev_fb_destroy,
};
--
2.40.1
[PATCH v4 02/13] fbdev: Add initializer macros for struct fb_ops
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove a lot boilerplate code from fbdev drivers.
The drivers are supposed to use the macro that is required for its
framebuffer. Each macro is split into smaller helpers, so that
drivers with non-standard callbacks can pick and customize callbacks
as needed. There are individual helper macros for read/write, mmap
and drawing.
Signed-off-by: Thomas Zimmermann
---
include/linux/fb.h | 112 +
1 file changed, 112 insertions(+)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 2cf8efcb9e32..731472a2bb62 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -538,9 +538,31 @@ extern ssize_t fb_io_read(struct fb_info *info, char
__user *buf,
extern ssize_t fb_io_write(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
+/*
+ * Initializes struct fb_ops for framebuffers in I/O memory.
+ */
+
+#define __FB_DEFAULT_IO_OPS_RDWR \
+ .fb_read= fb_io_read, \
+ .fb_write = fb_io_write
+
+#define __FB_DEFAULT_IO_OPS_DRAW \
+.fb_fillrect = cfb_fillrect, \
+.fb_copyarea = cfb_copyarea, \
+.fb_imageblit = cfb_imageblit
+
+#define __FB_DEFAULT_IO_OPS_MMAP \
+ .fb_mmap= NULL // default implementation
+
+#define FB_DEFAULT_IO_OPS \
+ __FB_DEFAULT_IO_OPS_RDWR, \
+ __FB_DEFAULT_IO_OPS_DRAW, \
+ __FB_DEFAULT_IO_OPS_MMAP
+
/*
* Drawing operations where framebuffer is in system RAM
*/
+
extern void sys_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
extern void sys_copyarea(struct fb_info *info, const struct fb_copyarea *area);
extern void sys_imageblit(struct fb_info *info, const struct fb_image *image);
@@ -549,6 +571,27 @@ extern ssize_t fb_sys_read(struct fb_info *info, char
__user *buf,
extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf,
size_t count, loff_t *ppos);
+/*
+ * Initializes struct fb_ops for framebuffers in system memory.
+ */
+
+#define __FB_DEFAULT_SYS_OPS_RDWR \
+ .fb_read= fb_sys_read, \
+ .fb_write = fb_sys_write
+
+#define __FB_DEFAULT_SYS_OPS_DRAW \
+.fb_fillrect = sys_fillrect, \
+.fb_copyarea = sys_copyarea, \
+.fb_imageblit = sys_imageblit
+
+#define __FB_DEFAULT_SYS_OPS_MMAP \
+ .fb_mmap= NULL // default implementation
+
+#define FB_DEFAULT_SYS_OPS \
+ __FB_DEFAULT_SYS_OPS_RDWR, \
+ __FB_DEFAULT_SYS_OPS_DRAW, \
+ __FB_DEFAULT_SYS_OPS_MMAP
+
/* drivers/video/fbmem.c */
extern int register_framebuffer(struct fb_info *fb_info);
extern void unregister_framebuffer(struct fb_info *fb_info);
@@ -604,6 +647,75 @@ extern void fb_deferred_io_cleanup(struct fb_info *info);
extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
+/*
+ * Generate callbacks for deferred I/O
+ */
+
+#define __FB_GEN_DEFAULT_DEFERRED_OPS_RDWR(__prefix, __damage_range, __mode) \
+ static ssize_t __prefix ## _defio_read(struct fb_info *info, char
__user *buf, \
+ size_t count, loff_t *ppos) \
+ { \
+ return fb_ ## __mode ## _read(info, buf, count, ppos); \
+ } \
+ static ssize_t __prefix ## _defio_write(struct fb_info *info, const
char __user *buf, \
+ size_t count, loff_t *ppos) \
+ { \
+ unsigned long offset = *ppos; \
+ ssize_t ret = fb_ ## __mode ## _write(info, buf, count, ppos); \
+ if (ret > 0) \
+ __damage_range(info, offset, ret); \
+ return ret; \
+ }
+
+#define __FB_GEN_DEFAULT_DEFERRED_OPS_DRAW(__prefix, __damage_area, __mode) \
+ static void __prefix ## _defio_fillrect(struct fb_info *info, \
+ const struct fb_fillrect *rect)
\
+ { \
+ __mode ## _fillrect(info, rect); \
+ __damage_area(info, rect->dx, rect->dy, rect->width,
rect->height); \
+ } \
+ static void __prefix ## _defio_copyarea(struct fb_info *info, \
+ const struct fb_copyarea *area)
\
+ { \
+ __mode ## _copyarea(info, area); \
+ __damage_area(info, area->dx, area->dy, area->width,
area->height); \
+ } \
+ static void __prefix ## _defio_imageblit(struct fb_info *info, \
+const struct fb_image *image) \
+ { \
+ __mode ## _imageblit(info, image); \
+ __damage_
[PATCH v4 06/13] drm/radeon: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_IO_HELPERS option
Signed-off-by: Thomas Zimmermann
Acked-by: Alex Deucher
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
---
drivers/gpu/drm/radeon/Kconfig| 1 +
drivers/gpu/drm/radeon/radeon_fbdev.c | 9 +++--
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index e19d77d58810..fe498c8af1bb 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -11,6 +11,7 @@ config DRM_RADEON
select DRM_SUBALLOC_HELPER
select DRM_TTM
select DRM_TTM_HELPER
+ select FB_IO_HELPERS if DRM_FBDEV_EMULATION
select SND_HDA_COMPONENT if SND_HDA_CORE
select POWER_SUPPLY
select HWMON
diff --git a/drivers/gpu/drm/radeon/radeon_fbdev.c
b/drivers/gpu/drm/radeon/radeon_fbdev.c
index fe76e29910ef..28212c2d6c98 100644
--- a/drivers/gpu/drm/radeon/radeon_fbdev.c
+++ b/drivers/gpu/drm/radeon/radeon_fbdev.c
@@ -24,6 +24,7 @@
* David Airlie
*/
+#include
#include
#include
#include
@@ -190,14 +191,10 @@ static void radeon_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops radeon_fbdev_fb_ops = {
.owner = THIS_MODULE,
- DRM_FB_HELPER_DEFAULT_OPS,
.fb_open = radeon_fbdev_fb_open,
.fb_release = radeon_fbdev_fb_release,
- .fb_read = drm_fb_helper_cfb_read,
- .fb_write = drm_fb_helper_cfb_write,
- .fb_fillrect = drm_fb_helper_cfb_fillrect,
- .fb_copyarea = drm_fb_helper_cfb_copyarea,
- .fb_imageblit = drm_fb_helper_cfb_imageblit,
+ FB_DEFAULT_IO_OPS,
+ DRM_FB_HELPER_DEFAULT_OPS,
.fb_destroy = radeon_fbdev_fb_destroy,
};
--
2.40.1
[PATCH v4 00/13] drm/fbdev: Remove DRM's helpers for fbdev I/O
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_() and fb_sys_() helpers. The DRM functions don't provide any additional functionality for most DRM drivers. So remove them and call the fbdev I/O helpers directly. The DRM fbdev I/O wrappers were originally added because does not protect its content with CONFIG_FB. DRM fbdev emulation did not build if the config option had been disabled. This has been fixed. For fbdev-generic and i915, the wrappers added support for damage handling. But this is better handled within the two callers, as each is special in its damage handling. Patch 1 adds several internal Kconfig options that DRM drivers (and possibly other fbdev code) will use to select the correct set of I/O helpers. Patch 2 adds initializers for struct fb_ops and generator macros for the callback functions. These macros will simplify drivers. This patchset applies the new options and macros to DRM fbdev emulation, but regular fbdev drivers can use them as well. Patches 3 to 10 replace the DRM wrappers in a number of fbdev emulations. Patch 10 exports two helpers for damage handling. Patches 12 and 13 update fbdev-generic and i915 with the help of the exported functions. The patches also remove DRM's fbdev I/O helpers, which are now unused. DRM's fbdev helpers had to select fbdev I/O helpers for I/O and for system memory. Each fbdev emulation now selects the correct helpers for itself. Depending on the selected DRM drivers, kernel builds will now only contain the necessary fbdev I/O helpers and might be slightly smaller in size. v4: * use initializer and generator macros for struct fb_ops * partially support damage handling in msm (Dmitri) v3: * fix Kconfig options (Jingfeng) * minimize changes to exynos (Sam) v2: * simplify Kconfig handling (Sam) Thomas Zimmermann (13): fbdev: Add Kconfig options to select different fb_ops helpers fbdev: Add initializer macros for struct fb_ops drm/armada: Use regular fbdev I/O helpers drm/exynos: Use regular fbdev I/O helpers drm/gma500: Use regular fbdev I/O helpers drm/radeon: Use regular fbdev I/O helpers drm/fbdev-dma: Use regular fbdev I/O helpers drm/msm: Use regular fbdev I/O helpers drm/omapdrm: Use regular fbdev I/O helpers drm/tegra: Use regular fbdev I/O helpers drm/fb-helper: Export helpers for marking damage areas drm/fbdev-generic: Implement dedicated fbdev I/O helpers drm/i915: Implement dedicated fbdev I/O helpers drivers/gpu/drm/Kconfig| 10 +- drivers/gpu/drm/armada/Kconfig | 1 + drivers/gpu/drm/armada/armada_fbdev.c | 7 +- drivers/gpu/drm/drm_fb_helper.c| 236 ++--- drivers/gpu/drm/drm_fbdev_dma.c| 11 +- drivers/gpu/drm/drm_fbdev_generic.c| 11 +- drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 9 +- drivers/gpu/drm/gma500/Kconfig | 1 + drivers/gpu/drm/gma500/fbdev.c | 8 +- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/display/intel_fbdev.c | 14 +- drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/msm/msm_fbdev.c| 17 +- drivers/gpu/drm/omapdrm/Kconfig| 1 + drivers/gpu/drm/omapdrm/omap_fbdev.c | 11 +- drivers/gpu/drm/radeon/Kconfig | 1 + drivers/gpu/drm/radeon/radeon_fbdev.c | 9 +- drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/fbdev.c | 8 +- drivers/video/fbdev/Kconfig| 21 ++ include/drm/drm_fb_helper.h| 83 +--- include/linux/fb.h | 112 ++ 23 files changed, 212 insertions(+), 363 deletions(-) base-commit: 216281f91018b24567e59ae46ce7e96fb92063cf prerequisite-patch-id: 0aa359f6144c4015c140c8a6750be19099c676fb prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 prerequisite-patch-id: cbc453ee02fae02af22fbfdce56ab732c7a88c36 prerequisite-patch-id: 8bff2b12862e44027a25837ea7510f633d40839e prerequisite-patch-id: 97ac107455aff4e0ec039d166ecdd2430d20f22e -- 2.40.1
[PATCH v4 03/13] drm/armada: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_IO_HELPERS option
Signed-off-by: Thomas Zimmermann
Cc: Russell King
---
drivers/gpu/drm/armada/Kconfig| 1 +
drivers/gpu/drm/armada/armada_fbdev.c | 7 ++-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index f5c66d89ba99..5afade25e217 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -3,6 +3,7 @@ config DRM_ARMADA
tristate "DRM support for Marvell Armada SoCs"
depends on DRM && HAVE_CLK && ARM && MMU
select DRM_KMS_HELPER
+ select FB_IO_HELPERS if DRM_FBDEV_EMULATION
help
Support the "LCD" controllers found on the Marvell Armada 510
devices. There are two controllers on the device, each controller
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 0a5fd1aa86eb..3943e89cc06c 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
@@ -33,12 +34,8 @@ static void armada_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops armada_fb_ops = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IO_OPS,
DRM_FB_HELPER_DEFAULT_OPS,
- .fb_read= drm_fb_helper_cfb_read,
- .fb_write = drm_fb_helper_cfb_write,
- .fb_fillrect= drm_fb_helper_cfb_fillrect,
- .fb_copyarea= drm_fb_helper_cfb_copyarea,
- .fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_destroy = armada_fbdev_fb_destroy,
};
--
2.40.1
[PATCH v4 09/13] drm/omapdrm: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Signed-off-by: Thomas Zimmermann
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Kconfig | 1 +
drivers/gpu/drm/omapdrm/omap_fbdev.c | 11 +++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
index 76ded1568bd0..b4ac76c9f31b 100644
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -4,6 +4,7 @@ config DRM_OMAP
depends on DRM && OF
depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
+ select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
select VIDEOMODE_HELPERS
select HDMI
default n
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b950e93b3846..b7ccce0704a3 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -4,6 +4,8 @@
* Author: Rob Clark
*/
+#include
+
#include
#include
#include
@@ -95,20 +97,13 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
-
+ FB_DEFAULT_SYS_OPS,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
.fb_ioctl = drm_fb_helper_ioctl,
-
- .fb_read = drm_fb_helper_sys_read,
- .fb_write = drm_fb_helper_sys_write,
- .fb_fillrect = drm_fb_helper_sys_fillrect,
- .fb_copyarea = drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
-
.fb_destroy = omap_fbdev_fb_destroy,
};
--
2.40.1
[PATCH v4 11/13] drm/fb-helper: Export helpers for marking damage areas
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by themselves and the exported functions will be removed.
v4:
* update interfaces
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 22 ++
include/drm/drm_fb_helper.h | 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f0e9549b6bd7..cb03099fd2e3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -670,6 +670,28 @@ static void drm_fb_helper_memory_range_to_clip(struct
fb_info *info, off_t off,
drm_rect_init(clip, x1, y1, x2 - x1, y2 - y1);
}
+/* Don't use in new code. */
+void drm_fb_helper_damage_range(struct fb_info *info, off_t off, size_t len)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_rect damage_area;
+
+ drm_fb_helper_memory_range_to_clip(info, off, len, &damage_area);
+ drm_fb_helper_damage(fb_helper, damage_area.x1, damage_area.y1,
+drm_rect_width(&damage_area),
+drm_rect_height(&damage_area));
+}
+EXPORT_SYMBOL(drm_fb_helper_damage_range);
+
+/* Don't use in new code. */
+void drm_fb_helper_damage_area(struct fb_info *info, u32 x, u32 y, u32 width,
u32 height)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ drm_fb_helper_damage(fb_helper, x, y, width, height);
+}
+EXPORT_SYMBOL(drm_fb_helper_damage_area);
+
/**
* drm_fb_helper_deferred_io() - fbdev deferred_io callback function
* @info: fb_info struct pointer
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 72032c354a30..7d5804882be7 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -253,6 +253,9 @@ void drm_fb_helper_fill_info(struct fb_info *info,
struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes);
+void drm_fb_helper_damage_range(struct fb_info *info, off_t off, size_t len);
+void drm_fb_helper_damage_area(struct fb_info *info, u32 x, u32 y, u32 width,
u32 height);
+
void drm_fb_helper_deferred_io(struct fb_info *info, struct list_head
*pagereflist);
ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
--
2.40.1
[PATCH v4 04/13] drm/exynos: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v3:
* don't reorder Makefile rules (Sam)
v2:
* use FB_IO_HELPERS option
Signed-off-by: Thomas Zimmermann
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Alim Akhtar
---
drivers/gpu/drm/exynos/Kconfig| 1 +
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 9 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 0cb92d651ff1..7ca7e1dab52c 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -7,6 +7,7 @@ config DRM_EXYNOS
select DRM_DISPLAY_HELPER if DRM_EXYNOS_DP
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
+ select FB_IO_HELPERS if DRM_FBDEV_EMULATION
select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option if you have a Samsung SoC Exynos chipset.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index ea4b3d248aac..fdf65587f1fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -8,6 +8,8 @@
* Seung-Woo Kim
*/
+#include
+
#include
#include
#include
@@ -47,13 +49,10 @@ static void exynos_drm_fb_destroy(struct fb_info *info)
static const struct fb_ops exynos_drm_fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_IO_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
+ __FB_DEFAULT_IO_OPS_DRAW,
.fb_mmap= exynos_drm_fb_mmap,
- .fb_read= drm_fb_helper_cfb_read,
- .fb_write = drm_fb_helper_cfb_write,
- .fb_fillrect= drm_fb_helper_cfb_fillrect,
- .fb_copyarea= drm_fb_helper_cfb_copyarea,
- .fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_destroy = exynos_drm_fb_destroy,
};
--
2.40.1
[PATCH v4 08/13] drm/msm: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Msm's fbdev emulation has been incomplete as it didn't implement
damage handling. Partilly fix this by implementing damage handling
for write and draw operation. It is still missing for mmaped pages.
v4:
* use initializer macros for struct fb_ops
* partially support damage handling
v2:
* use FB_SYS_HELPERS option
Signed-off-by: Thomas Zimmermann
Reviewed-by: Dmitry Baryshkov
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_fbdev.c | 17 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 85f5ab1d552c..a78662bd6273 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -21,6 +21,7 @@ config DRM_MSM
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
select DRM_SCHED
+ select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
select SHMEM
select TMPFS
select QCOM_SCM
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index ce0ba6d1979a..fa9c1cbffae3 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -4,6 +4,8 @@
* Author: Rob Clark
*/
+#include
+
#include
#include
#include
@@ -23,6 +25,10 @@ module_param(fbdev, bool, 0600);
* fbdev funcs, to implement legacy fbdev interface on top of drm driver
*/
+FB_GEN_DEFAULT_DEFERRED_SYS_OPS(msm_fbdev,
+ drm_fb_helper_damage_range,
+ drm_fb_helper_damage_area)
+
static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct drm_fb_helper *helper = (struct drm_fb_helper *)info->par;
@@ -52,16 +58,9 @@ static void msm_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops msm_fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DEFERRED_OPS_RDWR(msm_fbdev),
DRM_FB_HELPER_DEFAULT_OPS,
-
- /* Note: to properly handle manual update displays, we wrap the
-* basic fbdev ops which write to the framebuffer
-*/
- .fb_read = drm_fb_helper_sys_read,
- .fb_write = drm_fb_helper_sys_write,
- .fb_fillrect = drm_fb_helper_sys_fillrect,
- .fb_copyarea = drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
+ __FB_DEFAULT_DEFERRED_OPS_DRAW(msm_fbdev),
.fb_mmap = msm_fbdev_mmap,
.fb_destroy = msm_fbdev_fb_destroy,
};
--
2.40.1
[PATCH v4 12/13] drm/fbdev-generic: Implement dedicated fbdev I/O helpers
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_SYS_HELPERS_DEFERRED option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 6 +-
drivers/gpu/drm/drm_fb_helper.c | 107
drivers/gpu/drm/drm_fbdev_generic.c | 11 ++-
include/drm/drm_fb_helper.h | 41 ---
4 files changed, 6 insertions(+), 159 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
config DRM_KMS_HELPER
tristate
depends on DRM
+ select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
help
CRTC helpers for KMS drivers.
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB_DEFERRED_IO
- select FB_SYS_FOPS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cb03099fd2e3..bab6b252f02a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
struct list_head *pagerefli
}
EXPORT_SYMBOL(drm_fb_helper_deferred_io);
-/**
- * drm_fb_helper_sys_read - Implements struct &fb_ops.fb_read for system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
- size_t count, loff_t *ppos)
-{
- return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct &fb_ops.fb_write for system
memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct drm_fb_helper *helper = info->par;
- loff_t pos = *ppos;
- ssize_t ret;
- struct drm_rect damage_area;
-
- ret = fb_sys_write(info, buf, count, ppos);
- if (ret <= 0)
- return ret;
-
- if (helper->funcs->fb_dirty) {
- drm_fb_helper_memory_range_to_clip(info, pos, ret,
&damage_area);
- drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
-drm_rect_width(&damage_area),
-drm_rect_height(&damage_area));
- }
-
- return ret;
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_write);
-
-/**
- * drm_fb_helper_sys_fillrect - wrapper around sys_fillrect
- * @info: fbdev registered by the helper
- * @rect: info about rectangle to fill
- *
- * A wrapper around sys_fillrect implemented by fbdev core
- */
-void drm_fb_helper_sys_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
-{
- struct drm_fb_helper *helper = info->par;
-
- sys_fillrect(info, rect);
-
- if (helper->funcs->fb_dirty)
- drm_fb_helper_damage(helper, rect->dx, rect->dy, rect->width,
rect->height);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_fillrect);
-
-/**
- * drm_fb_helper_sys_copyarea - wrapper around sys_copyarea
- * @info: fbdev registered by the helper
- * @area: info about area to copy
- *
- * A wrapper around sys_copyarea implemented by fbdev core
- */
-void drm_fb_helper_sys_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
-{
- struct drm_fb_helper *helper = info->par;
-
- sys_copyarea(info, area);
-
- if (helper->funcs->fb_dirty)
- drm_fb_helper_damage(helper, area->dx, area->dy, area->width,
area->height);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_copyarea);
-
-/**
- * drm_fb_helper_sys_imageblit - wrapper around sys_imageblit
- * @info: fbdev registered by the helper
- * @image: info about image
[PATCH v4 07/13] drm/fbdev-dma: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_fbdev_dma.c | 11 +--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ba3fb04bb691..77fb10ddd8a2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -223,6 +223,7 @@ config DRM_TTM_HELPER
config DRM_GEM_DMA_HELPER
tristate
depends on DRM
+ select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
help
Choose this if you need the GEM DMA helper functions
diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index 728deffcc0d9..d86773fa8ab0 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: MIT
+#include
+
#include
#include
#include
@@ -64,14 +66,11 @@ static const struct fb_ops drm_fbdev_dma_fb_ops = {
.owner = THIS_MODULE,
.fb_open = drm_fbdev_dma_fb_open,
.fb_release = drm_fbdev_dma_fb_release,
- .fb_read = drm_fb_helper_sys_read,
- .fb_write = drm_fb_helper_sys_write,
+ __FB_DEFAULT_SYS_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
- .fb_fillrect = drm_fb_helper_sys_fillrect,
- .fb_copyarea = drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
- .fb_destroy = drm_fbdev_dma_fb_destroy,
+ __FB_DEFAULT_SYS_OPS_DRAW,
.fb_mmap = drm_fbdev_dma_fb_mmap,
+ .fb_destroy = drm_fbdev_dma_fb_destroy,
};
/*
--
2.40.1
[PATCH v4 13/13] drm/i915: Implement dedicated fbdev I/O helpers
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it doesn't implement
deferred I/O and damage handling for mmaped pages.
v4:
* generate deferred-I/O helpers
* use initializer macros for fb_ops
v2:
* use FB_IO_HELPERS options
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: "Ville Syrjälä"
---
drivers/gpu/drm/Kconfig| 3 -
drivers/gpu/drm/drm_fb_helper.c| 107 -
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/display/intel_fbdev.c | 14 +--
include/drm/drm_fb_helper.h| 39
5 files changed, 9 insertions(+), 155 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 92a782827b7b..bb2e48cc6cd6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -133,9 +133,6 @@ config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPER
depends on FB=y || FB=DRM_KMS_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bab6b252f02a..9978147bbc8a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -736,113 +736,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
struct list_head *pagerefli
}
EXPORT_SYMBOL(drm_fb_helper_deferred_io);
-/**
- * drm_fb_helper_cfb_read - Implements struct &fb_ops.fb_read for I/O memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_cfb_read(struct fb_info *info, char __user *buf,
- size_t count, loff_t *ppos)
-{
- return fb_io_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_cfb_read);
-
-/**
- * drm_fb_helper_cfb_write - Implements struct &fb_ops.fb_write for I/O memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_cfb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct drm_fb_helper *helper = info->par;
- loff_t pos = *ppos;
- ssize_t ret;
- struct drm_rect damage_area;
-
- ret = fb_io_write(info, buf, count, ppos);
- if (ret <= 0)
- return ret;
-
- if (helper->funcs->fb_dirty) {
- drm_fb_helper_memory_range_to_clip(info, pos, ret,
&damage_area);
- drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
-drm_rect_width(&damage_area),
-drm_rect_height(&damage_area));
- }
-
- return ret;
-}
-EXPORT_SYMBOL(drm_fb_helper_cfb_write);
-
-/**
- * drm_fb_helper_cfb_fillrect - wrapper around cfb_fillrect
- * @info: fbdev registered by the helper
- * @rect: info about rectangle to fill
- *
- * A wrapper around cfb_fillrect implemented by fbdev core
- */
-void drm_fb_helper_cfb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
-{
- struct drm_fb_helper *helper = info->par;
-
- cfb_fillrect(info, rect);
-
- if (helper->funcs->fb_dirty)
- drm_fb_helper_damage(helper, rect->dx, rect->dy, rect->width,
rect->height);
-}
-EXPORT_SYMBOL(drm_fb_helper_cfb_fillrect);
-
-/**
- * drm_fb_helper_cfb_copyarea - wrapper around cfb_copyarea
- * @info: fbdev registered by the helper
- * @area: info about area to copy
- *
- * A wrapper around cfb_copyarea implemented by fbdev core
- */
-void drm_fb_helper_cfb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
-{
- struct drm_fb_helper *helper = info->par;
-
- cfb_copyarea(info, area);
-
- if (helper->funcs->fb_dirty)
- drm_fb_helper_damage(helper, area->dx, area->dy, area->width,
area->height);
-}
-EXPORT_SYMBOL(drm_fb_helper_cfb_copyarea);
-
-/**
- * drm_fb_helper_cfb_imageblit - wrapper around cfb_imageblit
- * @info: fbdev registered b
[PATCH v4 10/13] drm/tegra: Use regular fbdev I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Signed-off-by: Thomas Zimmermann
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: Jonathan Hunter
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/fbdev.c | 8 +++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 56453ca277c2..498313778175 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -12,6 +12,7 @@ config DRM_TEGRA
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
+ select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
select TEGRA_HOST1X
select INTERCONNECT
select IOMMU_IOVA
diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c
index dca9eccae466..e74d9be981c7 100644
--- a/drivers/gpu/drm/tegra/fbdev.c
+++ b/drivers/gpu/drm/tegra/fbdev.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
@@ -58,12 +59,9 @@ static void tegra_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_SYS_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
- .fb_read = drm_fb_helper_sys_read,
- .fb_write = drm_fb_helper_sys_write,
- .fb_fillrect = drm_fb_helper_sys_fillrect,
- .fb_copyarea = drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
+ __FB_DEFAULT_SYS_OPS_DRAW,
.fb_mmap = tegra_fb_mmap,
.fb_destroy = tegra_fbdev_fb_destroy,
};
--
2.40.1
Re: [PATCH net-next v4 6/6] MAINTAINERS: ASP 2.0 Ethernet driver maintainers
On Tue, May 23, 2023 at 02:53:47PM -0700, Justin Chen wrote: > Add maintainers entry for ASP 2.0 Ethernet driver. > > Signed-off-by: Florian Fainelli > Signed-off-by: Justin Chen Reviewed-by: Simon Horman
Re: [PATCH net-next v4 1/6] dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0
On Tue, May 23, 2023 at 02:53:42PM -0700, Justin Chen wrote: > The ASP 2.0 Ethernet controller uses a brcm unimac. > > Acked-by: Conor Dooley > Signed-off-by: Florian Fainelli > Signed-off-by: Justin Chen Reviewed-by: Simon Horman
Re: [PATCH net-next v4 4/6] net: phy: mdio-bcm-unimac: Add asp v2.0 support
On Tue, May 23, 2023 at 02:53:45PM -0700, Justin Chen wrote: > Add mdio compat string for ASP 2.0 ethernet driver. > > Signed-off-by: Florian Fainelli > Signed-off-by: Justin Chen > Reviewed-by: Andrew Lunn Reviewed-by: Simon Horman
Re: [PATCH net-next v4 5/6] net: phy: bcm7xxx: Add EPHY entry for 74165
On Tue, May 23, 2023 at 02:53:46PM -0700, Justin Chen wrote: > From: Florian Fainelli > > 74165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY, > utilize the recently defined 16nm EPHY macro to configure that PHY. > > Signed-off-by: Florian Fainelli > Signed-off-by: Justin Chen > Reviewed-by: Andrew Lunn Reviewed-by: Simon Horman
[PATCH v1 1/4] drm/mediatek: dsi: Use GENMASK() for register mask definitions
Change magic numerical masks with usage of the GENMASK() macro to improve readability. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_dsi.c | 46 -- 1 file changed, 24 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index b0ab38e59db9..246a3a338c1e 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -58,18 +58,18 @@ #define DSI_TXRX_CTRL 0x18 #define VC_NUM BIT(1) -#define LANE_NUM (0xf << 2) +#define LANE_NUM GENMASK(5, 2) #define DIS_EOTBIT(6) #define NULL_ENBIT(7) #define TE_FREERUN BIT(8) #define EXT_TE_EN BIT(9) #define EXT_TE_EDGEBIT(10) -#define MAX_RTN_SIZE (0xf << 12) +#define MAX_RTN_SIZE GENMASK(15, 12) #define HSTX_CKLP_EN BIT(16) #define DSI_PSCTRL 0x1c -#define DSI_PS_WC 0x3fff -#define DSI_PS_SEL (3 << 16) +#define DSI_PS_WC GENMASK(14, 0) +#define DSI_PS_SEL GENMASK(19, 16) #define PACKED_PS_16BIT_RGB565 (0 << 16) #define LOOSELY_PS_18BIT_RGB666(1 << 16) #define PACKED_PS_18BIT_RGB666 (2 << 16) @@ -108,26 +108,27 @@ #define LD0_WAKEUP_EN BIT(2) #define DSI_PHY_TIMECON0 0x110 -#define LPX(0xff << 0) -#define HS_PREP(0xff << 8) -#define HS_ZERO(0xff << 16) -#define HS_TRAIL (0xff << 24) +#define LPXGENMASK(7, 0) +#define HS_PREPGENMASK(15, 8) +#define HS_ZEROGENMASK(23, 16) +#define HS_TRAIL GENMASK(31, 24) #define DSI_PHY_TIMECON1 0x114 -#define TA_GO (0xff << 0) -#define TA_SURE(0xff << 8) -#define TA_GET (0xff << 16) -#define DA_HS_EXIT (0xff << 24) +#define TA_GO GENMASK(7, 0) +#define TA_SUREGENMASK(15, 8) +#define TA_GET GENMASK(23, 16) +#define DA_HS_EXIT GENMASK(31, 24) #define DSI_PHY_TIMECON2 0x118 -#define CONT_DET (0xff << 0) -#define CLK_ZERO (0xff << 16) -#define CLK_TRAIL (0xff << 24) +#define CONT_DET GENMASK(7, 0) +#define DA_HS_SYNC GENMASK(15, 8) +#define CLK_ZERO GENMASK(23, 16) +#define CLK_TRAIL GENMASK(31, 24) #define DSI_PHY_TIMECON3 0x11c -#define CLK_HS_PREP(0xff << 0) -#define CLK_HS_POST(0xff << 8) -#define CLK_HS_EXIT(0xff << 16) +#define CLK_HS_PREPGENMASK(7, 0) +#define CLK_HS_POSTGENMASK(15, 8) +#define CLK_HS_EXITGENMASK(23, 16) #define DSI_VM_CMD_CON 0x130 #define VM_CMD_EN BIT(0) @@ -137,13 +138,14 @@ #define FORCE_COMMIT BIT(0) #define BYPASS_SHADOW BIT(1) -#define CONFIG (0xff << 0) +/* CMDQ related bits */ +#define CONFIG GENMASK(7, 0) #define SHORT_PACKET 0 #define LONG_PACKET2 #define BTABIT(2) -#define DATA_ID(0xff << 8) -#define DATA_0 (0xff << 16) -#define DATA_1 (0xff << 24) +#define DATA_IDGENMASK(15, 8) +#define DATA_0 GENMASK(23, 16) +#define DATA_1 GENMASK(31, 24) #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0)) -- 2.40.1
[PATCH v1 4/4] drm/mediatek: dsi: Replace open-coded instance of HZ_PER_MHZ
In mtk_dsi_phy_timconfig(), we're dividing the `data_rate` variable,
expressed in Hz to retrieve a value in MHz: instead of open-coding,
use the HZ_PER_MHZ definition, available in linux/units.h.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index fbf1c232107d..19e2b042c9d5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -235,7 +236,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset,
u32 mask, u32 data)
static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, 100);
+ u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, HZ_PER_MHZ);
struct mtk_phy_timing *timing = &dsi->phy_timing;
timing->lpx = (60 * data_rate_mhz / (8 * 1000)) + 1;
--
2.40.1
[PATCH v1 0/4] MediaTek DRM - DSI driver cleanups
This series performs some cleanups for mtk_dsi, enhancing human
readability, using kernel provided macros where possible and
also reducing code size.
Tested on MT8173 and MT8192 Chromebooks (using a DSI<->DP bridge)
and on MT6795 Sony Xperia M5 (DSI video mode panel).
Please note:
This series depends and can be applied only on top of [1].
[1]:
https://lore.kernel.org/lkml/20230523104234.7849-1-angelogioacchino.delre...@collabora.com/
AngeloGioacchino Del Regno (4):
drm/mediatek: dsi: Use GENMASK() for register mask definitions
drm/mediatek: dsi: Cleanup functions mtk_dsi_ps_control{_vact}()
drm/mediatek: dsi: Use bitfield macros where useful
drm/mediatek: dsi: Replace open-coded instance of HZ_PER_MHZ
drivers/gpu/drm/mediatek/mtk_dsi.c | 198 +
1 file changed, 88 insertions(+), 110 deletions(-)
--
2.40.1
[PATCH v1 3/4] drm/mediatek: dsi: Use bitfield macros where useful
Instead of open coding bitshifting for various register fields,
use the bitfield macro FIELD_PREP(): this allows to enhance the
human readability, decrease likeliness of mistakes (and register
field overflowing) and also to simplify the code.
The latter is especially seen in mtk_dsi_rxtx_control(), where
it was possible to change a switch to a short for loop and to
also remove the need to check for maximum DSI lanes == 4 thanks
to the FIELD_PREP macro masking the value.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 95 --
1 file changed, 50 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 97d5b3083057..fbf1c232107d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -70,16 +70,19 @@
#define DSI_PSCTRL 0x1c
#define DSI_PS_WC GENMASK(14, 0)
#define DSI_PS_SEL GENMASK(19, 16)
-#define PACKED_PS_16BIT_RGB565 (0 << 16)
-#define LOOSELY_PS_18BIT_RGB666(1 << 16)
-#define PACKED_PS_18BIT_RGB666 (2 << 16)
-#define PACKED_PS_24BIT_RGB888 (3 << 16)
+#define PACKED_PS_16BIT_RGB565 0
+#define LOOSELY_PS_18BIT_RGB6661
+#define PACKED_PS_18BIT_RGB666 2
+#define PACKED_PS_24BIT_RGB888 3
#define DSI_VSA_NL 0x20
#define DSI_VBP_NL 0x24
#define DSI_VFP_NL 0x28
#define DSI_VACT_NL0x2C
+#define VACT_NLGENMASK(14, 0)
#define DSI_SIZE_CON 0x38
+#define DSI_HEIGHT GENMASK(30, 16)
+#define DSI_WIDTH GENMASK(14, 0)
#define DSI_HSA_WC 0x50
#define DSI_HBP_WC 0x54
#define DSI_HFP_WC 0x58
@@ -252,14 +255,23 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
timing->clk_hs_zero = timing->clk_hs_trail * 4;
timing->clk_hs_exit = 2 * timing->clk_hs_trail;
- timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
- timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
- timcon1 = timing->ta_go | timing->ta_sure << 8 |
- timing->ta_get << 16 | timing->da_hs_exit << 24;
- timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
- timing->clk_hs_trail << 24;
- timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
- timing->clk_hs_exit << 16;
+ timcon0 = FIELD_PREP(LPX, timing->lpx) |
+ FIELD_PREP(HS_PREP, timing->da_hs_prepare) |
+ FIELD_PREP(HS_ZERO, timing->da_hs_zero) |
+ FIELD_PREP(HS_TRAIL, timing->da_hs_trail);
+
+ timcon1 = FIELD_PREP(TA_GO, timing->ta_go) |
+ FIELD_PREP(TA_SURE, timing->ta_sure) |
+ FIELD_PREP(TA_GET, timing->ta_get) |
+ FIELD_PREP(DA_HS_EXIT, timing->da_hs_exit);
+
+ timcon2 = FIELD_PREP(DA_HS_SYNC, 1) |
+ FIELD_PREP(CLK_ZERO, timing->clk_hs_zero) |
+ FIELD_PREP(CLK_TRAIL, timing->clk_hs_trail);
+
+ timcon3 = FIELD_PREP(CLK_HS_PREP, timing->clk_hs_prepare) |
+ FIELD_PREP(CLK_HS_POST, timing->clk_hs_post) |
+ FIELD_PREP(CLK_HS_EXIT, timing->clk_hs_exit);
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -352,69 +364,61 @@ static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
{
- u32 tmp_reg;
+ u32 regval, tmp_reg = 0;
+ u8 i;
- switch (dsi->lanes) {
- case 1:
- tmp_reg = 1 << 2;
- break;
- case 2:
- tmp_reg = 3 << 2;
- break;
- case 3:
- tmp_reg = 7 << 2;
- break;
- case 4:
- tmp_reg = 0xf << 2;
- break;
- default:
- tmp_reg = 0xf << 2;
- break;
- }
+ /* Number of DSI lanes (max 4 lanes), each bit enables one DSI lane. */
+ for (i = 0; i < dsi->lanes; i++)
+ tmp_reg |= BIT(i);
+
+ regval = FIELD_PREP(LANE_NUM, tmp_reg);
if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
- tmp_reg |= HSTX_CKLP_EN;
+ regval |= HSTX_CKLP_EN;
if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
- tmp_reg |= DIS_EOT;
+ regval |= DIS_EOT;
- writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
+ writel(regval, dsi->regs + DSI_TXRX_CTRL);
}
static void mtk_dsi_ps_control(struct mtk_dsi *dsi, bool config_vact)
{
- struct videomode *vm = &dsi->vm;
- u32 dsi_buf_bpp, ps_wc;
- u32 ps_bpp_mode;
+ u32 dsi_buf_bpp, ps_val, ps_wc, vact_nl;
if (dsi->format == MIPI_DSI_FMT_RGB565)
[PATCH v1 2/4] drm/mediatek: dsi: Cleanup functions mtk_dsi_ps_control{_vact}()
Function mtk_dsi_ps_control() is a subset of mtk_dsi_ps_control_vact():
merge the two in one mtk_dsi_ps_control() function by adding one
function parameter `config_vact` which, when true, writes the VACT
related registers.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 76 +-
1 file changed, 23 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 246a3a338c1e..97d5b3083057 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -350,40 +350,6 @@ static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
}
-static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
-{
- struct videomode *vm = &dsi->vm;
- u32 dsi_buf_bpp, ps_wc;
- u32 ps_bpp_mode;
-
- if (dsi->format == MIPI_DSI_FMT_RGB565)
- dsi_buf_bpp = 2;
- else
- dsi_buf_bpp = 3;
-
- ps_wc = vm->hactive * dsi_buf_bpp;
- ps_bpp_mode = ps_wc;
-
- switch (dsi->format) {
- case MIPI_DSI_FMT_RGB888:
- ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
- break;
- case MIPI_DSI_FMT_RGB666:
- ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
- break;
- case MIPI_DSI_FMT_RGB666_PACKED:
- ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
- break;
- case MIPI_DSI_FMT_RGB565:
- ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
- break;
- }
-
- writel(vm->vactive, dsi->regs + DSI_VACT_NL);
- writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
- writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
-}
-
static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
{
u32 tmp_reg;
@@ -415,36 +381,40 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
}
-static void mtk_dsi_ps_control(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control(struct mtk_dsi *dsi, bool config_vact)
{
- u32 dsi_tmp_buf_bpp;
- u32 tmp_reg;
+ struct videomode *vm = &dsi->vm;
+ u32 dsi_buf_bpp, ps_wc;
+ u32 ps_bpp_mode;
+
+ if (dsi->format == MIPI_DSI_FMT_RGB565)
+ dsi_buf_bpp = 2;
+ else
+ dsi_buf_bpp = 3;
+
+ ps_wc = vm->hactive * dsi_buf_bpp;
+ ps_bpp_mode = ps_wc;
switch (dsi->format) {
case MIPI_DSI_FMT_RGB888:
- tmp_reg = PACKED_PS_24BIT_RGB888;
- dsi_tmp_buf_bpp = 3;
+ ps_bpp_mode |= PACKED_PS_24BIT_RGB888;
break;
case MIPI_DSI_FMT_RGB666:
- tmp_reg = LOOSELY_PS_18BIT_RGB666;
- dsi_tmp_buf_bpp = 3;
+ ps_bpp_mode |= PACKED_PS_18BIT_RGB666;
break;
case MIPI_DSI_FMT_RGB666_PACKED:
- tmp_reg = PACKED_PS_18BIT_RGB666;
- dsi_tmp_buf_bpp = 3;
+ ps_bpp_mode |= LOOSELY_PS_18BIT_RGB666;
break;
case MIPI_DSI_FMT_RGB565:
- tmp_reg = PACKED_PS_16BIT_RGB565;
- dsi_tmp_buf_bpp = 2;
- break;
- default:
- tmp_reg = PACKED_PS_24BIT_RGB888;
- dsi_tmp_buf_bpp = 3;
+ ps_bpp_mode |= PACKED_PS_16BIT_RGB565;
break;
}
- tmp_reg += dsi->vm.hactive * dsi_tmp_buf_bpp & DSI_PS_WC;
- writel(tmp_reg, dsi->regs + DSI_PSCTRL);
+ if (config_vact) {
+ writel(vm->vactive, dsi->regs + DSI_VACT_NL);
+ writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
+ }
+ writel(ps_bpp_mode, dsi->regs + DSI_PSCTRL);
}
static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
@@ -520,7 +490,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
- mtk_dsi_ps_control(dsi);
+ mtk_dsi_ps_control(dsi, false);
}
static void mtk_dsi_start(struct mtk_dsi *dsi)
@@ -665,7 +635,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_reset_engine(dsi);
mtk_dsi_phy_timconfig(dsi);
- mtk_dsi_ps_control_vact(dsi);
+ mtk_dsi_ps_control(dsi, true);
mtk_dsi_set_vm_cmd(dsi);
mtk_dsi_config_vdo_timing(dsi);
mtk_dsi_set_interrupt_enable(dsi);
--
2.40.1
Re: [PATCH v2] drm/panel: samsung-s6d7aa0: use pointer for drm_mode in panel desc struct
On 24/05/2023 10:43, Artur Weber wrote:
Fixes compilation issues with older GCC versions and Clang after
changes introduced in commit 6810bb390282 ("drm/panel: Add Samsung
S6D7AA0 panel controller driver"). Tested with GCC 13.1.1, GCC 6.4.0
and Clang 16.0.3.
Fixes the following errors with Clang:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer
element is not a compile-time constant
.drm_mode = s6d7aa0_lsl080al02_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: error: initializer
element is not a compile-time constant
.drm_mode = s6d7aa0_lsl080al03_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: error: initializer
element is not a compile-time constant
.drm_mode = s6d7aa0_ltl101at01_mode,
^~~
3 errors generated.
Fixes the following errors with GCC:
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: error: initializer
element is not constant
.drm_mode = s6d7aa0_lsl080al02_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:312:14: note: (near
initialization for 's6d7aa0_lsl080al02_desc.drm_mode')
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: error: initializer
element is not constant
.drm_mode = s6d7aa0_lsl080al03_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:415:14: note: (near
initialization for 's6d7aa0_lsl080al03_desc.drm_mode')
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: error: initializer
element is not constant
.drm_mode = s6d7aa0_ltl101at01_mode,
^~~
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c:443:14: note: (near
initialization for 's6d7aa0_ltl101at01_desc.drm_mode')
Reported-by: Nathan Chancellor
Link:
https://lore.kernel.org/lkml/20230523180212.GA1401867@dev-arch.thelio-3990X
Reported-by: kernelci.org bot
Link: https://lore.kernel.org/llvm/646c6def.a70a0220.58c1a.9...@mx.google.com
Fixes: 6810bb390282 ("drm/panel: Add Samsung S6D7AA0 panel controller driver")
Signed-off-by: Artur Weber
---
v2: expanded commit message
---
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
index f532aa018428..102e1fc7ee38 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
@@ -37,7 +37,7 @@ struct s6d7aa0_panel_desc {
unsigned int panel_type;
int (*init_func)(struct s6d7aa0 *ctx);
int (*off_func)(struct s6d7aa0 *ctx);
- const struct drm_display_mode drm_mode;
+ const struct drm_display_mode *drm_mode;
unsigned long mode_flags;
u32 bus_flags;
bool has_backlight;
@@ -309,7 +309,7 @@ static const struct s6d7aa0_panel_desc
s6d7aa0_lsl080al02_desc = {
.panel_type = S6D7AA0_PANEL_LSL080AL02,
.init_func = s6d7aa0_lsl080al02_init,
.off_func = s6d7aa0_lsl080al02_off,
- .drm_mode = s6d7aa0_lsl080al02_mode,
+ .drm_mode = &s6d7aa0_lsl080al02_mode,
.mode_flags = MIPI_DSI_MODE_VSYNC_FLUSH | MIPI_DSI_MODE_VIDEO_NO_HFP,
.bus_flags = DRM_BUS_FLAG_DE_HIGH,
@@ -412,7 +412,7 @@ static const struct s6d7aa0_panel_desc s6d7aa0_lsl080al03_desc = {
.panel_type = S6D7AA0_PANEL_LSL080AL03,
.init_func = s6d7aa0_lsl080al03_init,
.off_func = s6d7aa0_lsl080al03_off,
- .drm_mode = s6d7aa0_lsl080al03_mode,
+ .drm_mode = &s6d7aa0_lsl080al03_mode,
.mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET,
.bus_flags = 0,
@@ -440,7 +440,7 @@ static const struct s6d7aa0_panel_desc s6d7aa0_ltl101at01_desc = {
.panel_type = S6D7AA0_PANEL_LTL101AT01,
.init_func = s6d7aa0_lsl080al03_init, /* Similar init to LSL080AL03 */
.off_func = s6d7aa0_lsl080al03_off,
- .drm_mode = s6d7aa0_ltl101at01_mode,
+ .drm_mode = &s6d7aa0_ltl101at01_mode,
.mode_flags = MIPI_DSI_MODE_NO_EOT_PACKET,
.bus_flags = 0,
@@ -458,7 +458,7 @@ static int s6d7aa0_get_modes(struct drm_panel *panel,
if (!ctx)
return -EINVAL;
- mode = drm_mode_duplicate(connector->dev, &ctx->desc->drm_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->desc->drm_mode);
if (!mode)
return -ENOMEM;
base-commit: 37cee4876a45a5c3da79a83d34ed4f3c68548aef
Acked-by: Neil Armstrong
Re: [PATCH v3 2/3] dt-bindings: phy: add mediatek MIPI CD-PHY module v0.5
Il 24/05/23 10:30, Julien Stephan ha scritto:
From: Florian Sylvestre
This adds the bindings, for the MIPI CD-PHY module v0.5 embedded in
some Mediatek soc, such as the mt8365
Signed-off-by: Florian Sylvestre
Signed-off-by: Julien Stephan
---
.../bindings/phy/mediatek,mt8365-csi-rx.yaml | 67 +++
MAINTAINERS | 6 ++
2 files changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
new file mode 100644
index ..a1bd96a98051
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 MediaTek, BayLibre
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,mt8365-csi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Sensor Interface MIPI CSI CD-PHY
+
+maintainers:
+ - Julien Stephan
+ - Andy Hsieh
+
+description:
+ The SENINF CD-PHY is a set of CD-PHY connected to the SENINF CSI-2
+ receivers. The number of PHYs depends on the SoC model.
+ Depending on the SoC model, each PHYs can be either CD-PHY or D-PHY only
+ capable.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8365-csi-rx
+
+ reg:
+maxItems: 1
+
+ '#phy-cells':
+const: 0
+
+ mediatek,phy-type:
Instead of declaring a phy-type here like this, can't we instead declare that in
the phy cells, like we're doing with MTK TPHY and like other non-MediaTek PHYs
are
already doing?
device {
...
phys = <&csi0_rx PHY_TYPE_CDPHY>;
...
}
Regards,
Angelo
Re: [PATCH v3 1/3] dt-bindings: phy: add PHY_TYPE_CDPHY definition
Il 24/05/23 10:30, Julien Stephan ha scritto: Add definition for CDPHY phy type that can be configured in either D-PHY mode or C-PHY mode Signed-off-by: Julien Stephan Reviewed-by: AngeloGioacchino Del Regno --- include/dt-bindings/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h index 6b901b342348..a19d85dbbf16 100644 --- a/include/dt-bindings/phy/phy.h +++ b/include/dt-bindings/phy/phy.h @@ -23,5 +23,6 @@ #define PHY_TYPE_DPHY 10 #define PHY_TYPE_CPHY 11 #define PHY_TYPE_USXGMII 12 +#define PHY_TYPE_CDPHY 13 #endif /* _DT_BINDINGS_PHY */
Re: [PATCH v2] drm/panel: samsung-s6d7aa0: use pointer for drm_mode in panel desc struct
Hi,
On Wed, 24 May 2023 10:43:24 +0200, Artur Weber wrote:
> Fixes compilation issues with older GCC versions and Clang after
> changes introduced in commit 6810bb390282 ("drm/panel: Add Samsung
> S6D7AA0 panel controller driver"). Tested with GCC 13.1.1, GCC 6.4.0
> and Clang 16.0.3.
>
> Fixes the following errors with Clang:
>
> [...]
Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git
(drm-misc-next)
[1/1] drm/panel: samsung-s6d7aa0: use pointer for drm_mode in panel desc struct
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=6a038f0183dd5d3e289f6c1fe6962de9b31f8fd2
--
Neil
Re: [PATCH 1/2] drm/msm/dpu: drop SSPP register dumpers
On 2023-05-23 13:01:13, Abhinav Kumar wrote: > > > On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote: > > Drop SSPP-specifig debugfs register dumps in favour of using > > debugfs/dri/0/kms or devcoredump. > > > > I did see another series which removes src_blk from the catalog (I am > yet to review that one) . Lets assume that one is fine and this change > will be going on top of that one right? It replaces src_blk with directly accessing the blk (non-sub-block) directly, because they were overlapping anyway. > The concern I have with this change is that although I do agree that we > should be in favor of using debugfs/dri/0/kms ( i have used it a few > times and it works pretty well ), devcoredump does not have the support > to dump sub-blocks . Something which we should add with priority because > even with DSC blocks with the separation of enc/ctl blocks we need that > like I wrote in one of the responses. > > So the "len" of the blocks having sub-blocks will be ignored in favor of > the len of the sub-blocks. The sub-blocks are not always contiguous with their parent block, are they? It's probably better to print the sub-blocks separately with clear headers anyway rather than dumping the range parent_blk_base to max(parent_blk_base+len, parent_blk_base+sblk_base+sblk_len...). - Marijn > If we remove this without adding that support first, its a loss of debug > functionality. > > Can we retain these blocks and remove dpu_debugfs_create_regset32 in a > different way?
Re: [RFC] drm/msm/dp: Allow attaching a drm_panel
On Mon, May 22, 2023 at 02:53:48PM -0700, Bjorn Andersson wrote:
> On Mon, May 22, 2023 at 03:51:01PM -0500, Bjorn Andersson wrote:
> > On Fri, Oct 08, 2021 at 03:38:21PM +0300, Heikki Krogerus wrote:
> > > Hi,
> > >
> > > On Thu, Oct 07, 2021 at 09:15:12AM -0700, Bjorn Andersson wrote:
> > > > The one thing that I still don't understand though is, if the typec_mux
> > > > is used by the typec controller to inform _the_ mux about the function
> > > > to be used, what's up with the complexity in typec_mux_match()? This is
> > > > what lead me to believe that typec_mux was enabling/disabling individual
> > > > altmodes, rather just flipping the physical switch at the bottom.
> > >
> > > Ah, typec_mux_match() is a mess. I'm sorry about that. I think most of
> > > the code in that function is not used by anybody. If I remember
> > > correctly, all that complexity is attempting to solve some
> > > hypothetical corner case(s). Probable a case where we have multiple
> > > muxes per port to deal with.
> > >
> > > I think it would probable be best to clean the function to the bare
> > > minimum by keeping only the parts that are actually used today
> > > (attached).
> > >
> >
> > Sorry for not replying to this in a timely manner Heikki. I've been
> > ignoring this issue for a long time now, just adding "svid" to our dts
> > files. But, this obviously shows up in DT validation - and I'd prefer
> > not defining these properties as valid.
> >
> > The attached patch works as expected.
> >
>
> Sorry, I must have failed at applying the patch - it doesn't work...
>
> > Could you please spin this as a proper patch, so we can get it merged?
> >
> > Regards,
> > Bjorn
> >
> > > thanks,
> > >
> > > --
> > > heikki
> >
> > > diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
> > > index c8340de0ed495..44f168c9bd9bf 100644
> > > --- a/drivers/usb/typec/mux.c
> > > +++ b/drivers/usb/typec/mux.c
> > > @@ -193,56 +193,15 @@ static int mux_fwnode_match(struct device *dev,
> > > const void *fwnode)
> > > static void *typec_mux_match(struct fwnode_handle *fwnode, const char
> > > *id,
> > >void *data)
> > > {
> > > - const struct typec_altmode_desc *desc = data;
> > > struct device *dev;
> > > - bool match;
> > > - int nval;
> > > - u16 *val;
> > > - int ret;
> > > - int i;
> > >
> > > /*
> > > - * Check has the identifier already been "consumed". If it
> > > - * has, no need to do any extra connection identification.
> > > + * The connection identifier will be needed with device graph (OF
> > > graph).
> > > + * Device graph is not supported by this code yet, so bailing out.
> > >*/
> > > - match = !id;
> > > - if (match)
> > > - goto find_mux;
> > > -
> > > - /* Accessory Mode muxes */
> > > - if (!desc) {
> > > - match = fwnode_property_present(fwnode, "accessory");
> > > - if (match)
> > > - goto find_mux;
> > > - return NULL;
> > > - }
> > > -
> > > - /* Alternate Mode muxes */
> > > - nval = fwnode_property_count_u16(fwnode, "svid");
> > > - if (nval <= 0)
> > > - return NULL;
> > > -
> > > - val = kcalloc(nval, sizeof(*val), GFP_KERNEL);
> > > - if (!val)
> > > - return ERR_PTR(-ENOMEM);
> > > -
> > > - ret = fwnode_property_read_u16_array(fwnode, "svid", val, nval);
> > > - if (ret < 0) {
> > > - kfree(val);
> > > - return ERR_PTR(ret);
> > > - }
> > > -
> > > - for (i = 0; i < nval; i++) {
> > > - match = val[i] == desc->svid;
> > > - if (match) {
> > > - kfree(val);
> > > - goto find_mux;
> > > - }
> > > - }
> > > - kfree(val);
> > > - return NULL;
> > > + if (id)
>
> We pass id as "mode-switch", so this will never be NULL. But we also only
> want to consider endpoints with "mode-switch", otherwise we'll fail if
> any of the referred endpoints is not implementing a typec_mux...
>
> So this needs the same snippet we find in typec_switch_match():
>
> /*
>* Device graph (OF graph) does not give any means to identify the
>* device type or the device class of the remote port parent that
> @fwnode
>* represents, so in order to identify the type or the class of @fwnode
>* an additional device property is needed. With typec switches the
>* property is named "orientation-switch" (@id). The value of the device
>* property is ignored.
>*/
> if (id && !fwnode_property_present(fwnode, id))
> return NULL;
>
> With that, this works as expected!
Okay. I'll change that and send the patch out.
thanks,
--
heikki
Re: [PATCH 2/9] drm/panel: Check for already prepared/enabled in drm_panel
Hi,
On 23/05/2023 21:27, Douglas Anderson wrote:
In a whole pile of panel drivers, we have code to make the
prepare/unprepare/enable/disable callbacks behave as no-ops if they've
already been called. It's silly to have this code duplicated
everywhere. Add it to the core instead so that we can eventually
delete it from all the drivers. Note: to get some idea of the
duplicated code, try:
git grep 'if.*>prepared' -- drivers/gpu/drm/panel
git grep 'if.*>enabled' -- drivers/gpu/drm/panel
NOTE: arguably, the right thing to do here is actually to skip this
patch and simply remove all the extra checks from the individual
drivers. Perhaps the checks were needed at some point in time in the
past but maybe they no longer are? Certainly as we continue
transitioning over to "panel_bridge" then we expect there to be much
less variety in how these calls are made. When we're called as part of
the bridge chain, things should be pretty simple. In fact, there was
some discussion in the past about these checks [1], including a
discussion about whether the checks were needed and whether the calls
ought to be refcounted. At the time, I decided not to mess with it
because it felt too risky.
Looking closer at it now, I'm fairly certain that nothing in the
existing codebase is expecting these calls to be refcounted. The only
real question is whether someone is already doing something to ensure
prepare()/unprepare() match and enabled()/disable() match. I would say
that, even if there is something else ensuring that things match,
there's enough complexity that adding an extra bool and an extra
double-check here is a good idea. Let's add a drm_warn() to let people
know that it's considered a minor error to take advantage of
drm_panel's double-checking but we'll still make things work fine.
[1]
https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_panel.c | 49 -
include/drm/drm_panel.h | 14 +++
2 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index f634371c717a..4e1c4e42575b 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -105,11 +105,22 @@ EXPORT_SYMBOL(drm_panel_remove);
*/
int drm_panel_prepare(struct drm_panel *panel)
{
+ int ret;
+
if (!panel)
return -EINVAL;
- if (panel->funcs && panel->funcs->prepare)
- return panel->funcs->prepare(panel);
+ if (panel->prepared) {
+ dev_warn(panel->dev, "Skipping prepare of already prepared
panel\n");
+ return 0;
+ }
+
+ if (panel->funcs && panel->funcs->prepare) {
+ ret = panel->funcs->prepare(panel);
+ if (ret < 0)
+ return ret;
+ }
+ panel->prepared = true;
return 0;
}
@@ -128,11 +139,22 @@ EXPORT_SYMBOL(drm_panel_prepare);
*/
int drm_panel_unprepare(struct drm_panel *panel)
{
+ int ret;
+
if (!panel)
return -EINVAL;
- if (panel->funcs && panel->funcs->unprepare)
- return panel->funcs->unprepare(panel);
+ if (!panel->prepared) {
+ dev_warn(panel->dev, "Skipping unprepare of already unprepared
panel\n");
+ return 0;
+ }
+
+ if (panel->funcs && panel->funcs->unprepare) {
+ ret = panel->funcs->unprepare(panel);
+ if (ret < 0)
+ return ret;
+ }
+ panel->prepared = false;
return 0;
}
@@ -155,11 +177,17 @@ int drm_panel_enable(struct drm_panel *panel)
if (!panel)
return -EINVAL;
+ if (panel->enabled) {
+ dev_warn(panel->dev, "Skipping enable of already enabled
panel\n");
+ return 0;
+ }
+
if (panel->funcs && panel->funcs->enable) {
ret = panel->funcs->enable(panel);
if (ret < 0)
return ret;
}
+ panel->enabled = true;
ret = backlight_enable(panel->backlight);
if (ret < 0)
@@ -187,13 +215,22 @@ int drm_panel_disable(struct drm_panel *panel)
if (!panel)
return -EINVAL;
+ if (!panel->enabled) {
+ dev_warn(panel->dev, "Skipping disable of already disabled
panel\n");
+ return 0;
+ }
+
ret = backlight_disable(panel->backlight);
if (ret < 0)
DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
ret);
- if (panel->funcs && panel->funcs->disable)
- return panel->funcs->disable(panel);
+ if (panel->funcs && panel->funcs->disable) {
+ ret = panel->funcs->disable(panel);
+ if (ret < 0)
+ return ret;
+ }
+ panel->enabled = false;
r
Re: [PATCH 0/5] accel/ivpu: Add debugfs support
On Wed, May 24, 2023 at 11:29 AM Stanislaw Gruszka wrote: > > Hi > > On Wed, May 24, 2023 at 10:55:08AM +0300, Oded Gabbay wrote: > > On Wed, May 24, 2023 at 10:49 AM Stanislaw Gruszka > > wrote: > > > > > > Add debugfs support for ivpu driver, most importantly firmware loging > > > and tracing. > > Hi, > > Without looking at the code I have 2 comments/questions: > > > > 1. Please add an ABI documentation in Documentation/ABI/testing/ or > > Documentation/ABI/stable (if you are feeling courageous). You can see > > for example habana's file at > > Documentation/ABI/testing/debugfs-driver-habanalabs > > We do not promise any ABI compatibility for debugfs for ivpu, > we can add, remove or modify at any time. Hence make no sense to add > documentation files to Documentation/ABI/ for us. ok, I understand that documenting debugfs is not the norm in drm, so I'm not going to change that policy. > > > 2. Is this synced with Christian's upcoming changes to the debugfs > > infra in drm ? If not, I might suggest to sync with that and wait > > until those patches are merged because they change the layout of > > debugfs nodes. > > Is not synced. We can wait before Christian changes get in, what > hopefully will happen soon. But if not, ivpu debugfs can be modified > along with the changes. I can assist with that. I just thought you will prefer to do that, as it will change the layout and then you need to change your s/w stack, but it's up to you ofc. Thanks, Oded > > Regards > Stanislaw >
Re: [PATCH 1/2] drm/msm/dpu: drop SSPP register dumpers
On Wed, 24 May 2023 at 12:48, Marijn Suijten wrote: > > On 2023-05-23 13:01:13, Abhinav Kumar wrote: > > > > > > On 5/21/2023 10:21 AM, Dmitry Baryshkov wrote: > > > Drop SSPP-specifig debugfs register dumps in favour of using > > > debugfs/dri/0/kms or devcoredump. > > > > > > > I did see another series which removes src_blk from the catalog (I am > > yet to review that one) . Lets assume that one is fine and this change > > will be going on top of that one right? > > It replaces src_blk with directly accessing the blk (non-sub-block) > directly, because they were overlapping anyway. > > > The concern I have with this change is that although I do agree that we > > should be in favor of using debugfs/dri/0/kms ( i have used it a few > > times and it works pretty well ), devcoredump does not have the support > > to dump sub-blocks . Something which we should add with priority because > > even with DSC blocks with the separation of enc/ctl blocks we need that > > like I wrote in one of the responses. > > > > So the "len" of the blocks having sub-blocks will be ignored in favor of > > the len of the sub-blocks. > > The sub-blocks are not always contiguous with their parent block, are > they? It's probably better to print the sub-blocks separately with > clear headers anyway I hope this is what Abhinav meant. > rather than dumping the range parent_blk_base to > max(parent_blk_base+len, parent_blk_base+sblk_base+sblk_len...). > > - Marijn > > > If we remove this without adding that support first, its a loss of debug > > functionality. > > > > Can we retain these blocks and remove dpu_debugfs_create_regset32 in a > > different way? > > -- With best wishes Dmitry
Re: [PATCH 0/7] Add a DRM driver to support AI Processing Unit (APU)
On Wed, May 24, 2023 at 2:34 AM Kevin Hilman wrote: > > Jeffrey Hugo writes: > > > On 5/17/2023 8:52 AM, Alexandre Bailon wrote: > >> This adds a DRM driver that implements communication between the CPU and an > >> APU. The driver target embedded device that usually run inference using > >> some > >> prebuilt models. The goal is to provide common infrastructure that could be > >> re-used to support many accelerators. Both kernel, userspace and firmware > >> tries > >> to use standard and existing to leverage the development and maintenance > >> effort. > >> The series implements two platform drivers, one for simulation and another > >> one for > >> the mt8183 (compatible with mt8365). > > > > This looks like the 3 existing Accel drivers. Why is this in DRM? > > Yes, this belongs in accel. I think Alex had some issues around the > infra in accel with device nodes not appearing/opening properly, but > I'll let him comment there. But either way, the right approach should > be to fix any issues in accel and move it there. > > [...] > > >> .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 ++ > >> drivers/gpu/drm/Kconfig | 2 + > >> drivers/gpu/drm/Makefile | 1 + > >> drivers/gpu/drm/apu/Kconfig | 22 + > >> drivers/gpu/drm/apu/Makefile | 10 + > >> drivers/gpu/drm/apu/apu_drv.c | 282 + > >> drivers/gpu/drm/apu/apu_gem.c | 230 +++ > >> drivers/gpu/drm/apu/apu_internal.h| 205 ++ > >> drivers/gpu/drm/apu/apu_sched.c | 592 ++ > >> drivers/gpu/drm/apu/simu_apu.c| 313 + > >> include/uapi/drm/apu_drm.h| 81 +++ > > > > "apu" seems too generic. We already have 3 "AI processing units" over > > in drivers/accel already... > > Indeed, it is generic, but that's kind of the point for this driver > since it's targetted at generalizing the interface with "AI processing > units" on a growing number of embedded SoCs (ARM, RISC-V, etc.) In > addition, the generic naming is intentional because the goal is bigger > than the kernel and is working towards a generic, shared "libAPU" > userspace[1], but also common firmware for DSP-style inference engines > (e.g. analgous Sound Open Firmware for audio DSPs.) > > As usual, the various SoC vendors use different names (APU, NPU, NN > unit, etc.) but we'd like a generic name for the class of devices > targetted by this driver. And unfortunately, it looks like the equally > generic "Versatile processing unit" is already taken Intel's > drivers/accel/ivpu. :) > > Maybe since this is more about generalizing the interface between the > CPU running linux and the APU, what about the name apu_if? But I guess > that applies to the other 3 drivers in drivers/accell also. Hmmm... > > Naming things is hard[2], so we're definitly open to other ideas. Any > suggestions? Maybe model it according to the tiny driver in drm display ? You can then call it tiny_apu :-) Disclosure: It was Daniel's suggestion, he can chime in with more details on the tiny driver concept. Oded > > Kevin > > [1] https://gitlab.baylibre.com/baylibre/libapu/libapu > > [2] > "There are 2 hard problems in computer science: cache invalidation, > naming things and off-by-1 errors." > -- https://twitter.com/secretGeek/status/7269997868 >
[PATCH] drm/i915:fix kernel-doc trivial warnings
The test robot reports some make warnings. Fix those warnings: drivers/gpu/drm/i915/i915_gpu_error.c:2174: warning: Function parameter or member 'dump_flags' not described in 'i915_capture_error_state' drivers/gpu/drm/i915/i915_perf.c:5307: warning: Function parameter or member 'i915' not described in 'i915_perf_ioctl_version' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get' drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset' drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'OP' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'COND' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'US' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'Wmin' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or member 'Wmax' not described in '__wait_for' drivers/gpu/drm/i915/i915_scatterlist.h:164: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops' drivers/gpu/drm/i915/i915_scatterlist.h:187: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put' drivers/gpu/drm/i915/i915_scatterlist.h:198: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get' drivers/gpu/drm/i915/i915_scatterlist.h:214: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init' drivers/gpu/drm/i915/i915_vma_resource.h:129: warning: Function parameter or member 'wakeref' not described in 'i915_vma_resource' Reported-by: k2ci Signed-off-by: pengfuyuan --- drivers/gpu/drm/i915/i915_active.h | 14 +++--- drivers/gpu/drm/i915/i915_gpu_error.c| 1 + drivers/gpu/drm/i915/i915_perf.c | 1 + drivers/gpu/drm/i915/i915_scatterlist.h | 9 + drivers/gpu/drm/i915/i915_utils.h| 6 ++ drivers/gpu/drm/i915/i915_vma_resource.h | 1 + 6 files changed, 21 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_active.h b/drivers/gpu/drm/i915/i915_active.h index 7eb44132183a..77c676ecc263 100644 --- a/drivers/gpu/drm/i915/i915_active.h +++ b/drivers/gpu/drm/i915/i915_active.h @@ -49,9 +49,9 @@ void i915_active_noop(struct dma_fence *fence, struct dma_fence_cb *cb); /** * __i915_active_fence_init - prepares the activity tracker for use - * @active - the active tracker - * @fence - initial fence to track, can be NULL - * @func - a callback when then the tracker is retired (becomes idle), + * @active: the active tracker + * @fence: initial fence to track, can be NULL + * @fn: a callback when then the tracker is retired (becomes idle), * can be NULL * * i915_active_fence_init() prepares the embedded @active struct for use as @@ -77,8 +77,8 @@ __i915_active_fence_set(struct i915_active_fence *active, /** * i915_active_fence_set - updates the tracker to watch the current fence - * @active - the active tracker - * @rq - the request to watch + * @active: the active tracker + * @rq: the request to watch * * i915_active_fence_set() watches the given @rq for completion. While * that @rq is busy, the @active reports busy. When that @rq is signaled @@ -89,7 +89,7 @@ i915_active_fence_set(struct i915_active_fence *active, struct i915_request *rq); /** * i915_active_fence_get - return a reference to the active fence - * @active - the active tracker + * @active: the active tracker * * i915_active_fence_get() returns a reference to the active fence, * or NULL if the active tracker is idle. The reference is obtained under RCU, @@ -111,7 +111,7 @@ i915_active_fence_get(struct i915_active_fence *active) /** * i915_active_fence_isset - report whether the active tracker is assigned - * @active - the active tracker + * @active: the active tracker * * i915_active_fence_isset() returns true if the active tracker is currently * assigned to a fence. Due to the lazy retiring, that fence may be idle diff --git a/drivers/gpu/drm/i91
[PATCH] drm/i915/gt: fix kernel-doc trivial warnings
The test robot reports some make warnings.
Fix those warnings:
drivers/gpu/drm/i915/gt/intel_gtt.h:499: warning: Function parameter or
member 'vm' not described in 'i915_vm_resv_put'
drivers/gpu/drm/i915/gt/intel_context.h:108: warning: Function parameter or
member 'ce' not described in 'intel_context_lock_pinned'
drivers/gpu/drm/i915/gt/intel_context.h:123: warning: Function parameter or
member 'ce' not described in 'intel_context_is_pinned'
drivers/gpu/drm/i915/gt/intel_context.h:142: warning: Function parameter or
member 'ce' not described in 'intel_context_unlock_pinned
drivers/gpu/drm/i915/gt/intel_engine_types.h:293: warning: Function
parameter or member 'preempt_hang' not described in 'intel_engine_execlists'
Reported-by: k2ci
Signed-off-by: pengfuyuan
---
drivers/gpu/drm/i915/gt/intel_context.h | 6 +++---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 48f888c3da08..6b5eae7b88bc 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -97,7 +97,7 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
/**
* intel_context_lock_pinned - Stablises the 'pinned' status of the HW context
- * @ce - the context
+ * @ce: the context
*
* Acquire a lock on the pinned status of the HW context, such that the context
* can neither be bound to the GPU or unbound whilst the lock is held, i.e.
@@ -111,7 +111,7 @@ static inline int intel_context_lock_pinned(struct
intel_context *ce)
/**
* intel_context_is_pinned - Reports the 'pinned' status
- * @ce - the context
+ * @ce: the context
*
* While in use by the GPU, the context, along with its ring and page
* tables is pinned into memory and the GTT.
@@ -133,7 +133,7 @@ static inline void intel_context_cancel_request(struct
intel_context *ce,
/**
* intel_context_unlock_pinned - Releases the earlier locking of 'pinned'
status
- * @ce - the context
+ * @ce: the context
*
* Releases the lock earlier acquired by intel_context_unlock_pinned().
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 960291f88fd6..1fc1fc882097 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -289,6 +289,9 @@ struct intel_engine_execlists {
*/
u8 csb_head;
+ /**
+* @preempt_hang: preempt hang state for self-tests.
+*/
I915_SELFTEST_DECLARE(struct st_preempt_hang preempt_hang;)
};
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 69ce55f517f5..a9aa72a8c59c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -493,7 +493,7 @@ static inline void i915_vm_put(struct i915_address_space
*vm)
/**
* i915_vm_resv_put - Release a reference on the vm's reservation lock
- * @resv: Pointer to a reservation lock obtained from i915_vm_resv_get()
+ * @vm: Pointer to a reservation lock obtained from i915_vm_resv_release()
*/
static inline void i915_vm_resv_put(struct i915_address_space *vm)
{
--
2.25.1
No virus found
Checked by Hillstone Network AntiVirus
[PATCH] drm/i915/gt/uc:fix kernel-doc trivial warnings
The test robot reports some make warnings. Fix those warnings: drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'marker' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'read_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'write_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'size' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'sampled_write_ptr' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'wrap_offset' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flush_to_file' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'buffer_full_cnt' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'reserved' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'flags' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:491: warning: Function parameter or member 'version' not described in 'guc_log_buffer_state' drivers/gpu/drm/i915/gt/uc/intel_guc.h:274: warning: Function parameter or member 'dbgfs_node' not described in 'intel_guc' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'size' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'data' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'rd' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:27: warning: Function parameter or member 'wr' not described in '__guc_capture_bufstate' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'link' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'is_partial' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_class' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'eng_inst' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'guc_id' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'lrca' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:59: warning: Function parameter or member 'reginfo' not described in '__guc_capture_parsed_output' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'is_valid' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'ptr' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'size' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:163: warning: Function parameter or member 'status' not described in '__guc_capture_ads_cache' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'ads_null_cache' not described in 'intel_guc_state_capture' drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:216: warning: Function parameter or member 'max_mmio_per_node' not described in 'intel_guc_state_capture' Reported-by: k2ci Signed-off-by: pengfuyuan --- drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 27 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 18 + 3 files changed, 46 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h index 9d589c28f40f..84c74244a6a8 100644 --- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h +++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h @@ -18,6 +18,11 @@ struct file; * Book-keeping structure used to track read and write pointers * as we extract error capture data from the GuC-log-buffer's * error-capture reg
Re: [PATCH] dma-buf/sw_sync: Replace all non-returning strlcpy with strscpy
Hello Azeem, On Tue, 23 May 2023 at 22:52, Kees Cook wrote: > > On Tue, May 23, 2023 at 02:19:43AM +, Azeem Shaikh wrote: > > strlcpy() reads the entire source buffer first. > > This read may exceed the destination size limit. > > This is both inefficient and can lead to linear read > > overflows if a source string is not NUL-terminated [1]. > > In an effort to remove strlcpy() completely [2], replace > > strlcpy() here with strscpy(). > > No return values were used, so direct replacement is safe. > > > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > [2] https://github.com/KSPP/linux/issues/89 Thank you for the patch; I'll queue it up. > > > > Signed-off-by: Azeem Shaikh > > Reviewed-by: Kees Cook > > -- > Kees Cook Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH 0/7] Add a DRM driver to support AI Processing Unit (APU)
On Wed, May 24, 2023 at 01:27:00PM +0300, Oded Gabbay wrote: > On Wed, May 24, 2023 at 2:34 AM Kevin Hilman wrote: > > > > Jeffrey Hugo writes: > > > > > On 5/17/2023 8:52 AM, Alexandre Bailon wrote: > > >> This adds a DRM driver that implements communication between the CPU and > > >> an > > >> APU. The driver target embedded device that usually run inference using > > >> some > > >> prebuilt models. The goal is to provide common infrastructure that could > > >> be > > >> re-used to support many accelerators. Both kernel, userspace and > > >> firmware tries > > >> to use standard and existing to leverage the development and maintenance > > >> effort. > > >> The series implements two platform drivers, one for simulation and > > >> another one for > > >> the mt8183 (compatible with mt8365). > > > > > > This looks like the 3 existing Accel drivers. Why is this in DRM? > > > > Yes, this belongs in accel. I think Alex had some issues around the > > infra in accel with device nodes not appearing/opening properly, but > > I'll let him comment there. But either way, the right approach should > > be to fix any issues in accel and move it there. > > > > [...] > > > > >> .../devicetree/bindings/gpu/mtk,apu-drm.yaml | 38 ++ > > >> drivers/gpu/drm/Kconfig | 2 + > > >> drivers/gpu/drm/Makefile | 1 + > > >> drivers/gpu/drm/apu/Kconfig | 22 + > > >> drivers/gpu/drm/apu/Makefile | 10 + > > >> drivers/gpu/drm/apu/apu_drv.c | 282 + > > >> drivers/gpu/drm/apu/apu_gem.c | 230 +++ > > >> drivers/gpu/drm/apu/apu_internal.h| 205 ++ > > >> drivers/gpu/drm/apu/apu_sched.c | 592 ++ > > >> drivers/gpu/drm/apu/simu_apu.c| 313 + > > >> include/uapi/drm/apu_drm.h| 81 +++ > > > > > > "apu" seems too generic. We already have 3 "AI processing units" over > > > in drivers/accel already... > > > > Indeed, it is generic, but that's kind of the point for this driver > > since it's targetted at generalizing the interface with "AI processing > > units" on a growing number of embedded SoCs (ARM, RISC-V, etc.) In > > addition, the generic naming is intentional because the goal is bigger > > than the kernel and is working towards a generic, shared "libAPU" > > userspace[1], but also common firmware for DSP-style inference engines > > (e.g. analgous Sound Open Firmware for audio DSPs.) > > > > As usual, the various SoC vendors use different names (APU, NPU, NN > > unit, etc.) but we'd like a generic name for the class of devices > > targetted by this driver. And unfortunately, it looks like the equally > > generic "Versatile processing unit" is already taken Intel's > > drivers/accel/ivpu. :) > > > > Maybe since this is more about generalizing the interface between the > > CPU running linux and the APU, what about the name apu_if? But I guess > > that applies to the other 3 drivers in drivers/accell also. Hmmm... > > > > Naming things is hard[2], so we're definitly open to other ideas. Any > > suggestions? > Maybe model it according to the tiny driver in drm display ? You can > then call it tiny_apu :-) > Disclosure: It was Daniel's suggestion, he can chime in with more > details on the tiny driver concept. Yeah so maybe a bit more detail on my thoughts: First this smells like a need bypass of the entire "we want open userspace for accel drivers" rule. The rule isn't quite a strict as for drm gpu drivers (not sure we ended up documenting exactly what, but iirc the consensus was that for build-time only dependencies we're ok with downstream compilers), but it's still there. And at least from a quick look apu.ko and libapu just look like a generic accel interface, and that's not enough. For the big training engines it's more or less "enough to run pytorch, but it can be really slow", not sure what the right standard for these inference-only drivers should be. So that's the first reason why I don't like this. The other is that I think if we do end up with a pile of tiny accel drivers, we should probably look into something like simmpledrm for the tiny display drivers. Probably still IP specific ioctls (at least most) so that IP specific job knows and all that are easy, but then just pass to a framework that simplifies a drm gem driver to "write ptes" and "run job" callback, maybe with an optional "create/destroy vm/ctx" for hw which can do that. So maybe we end up with a drivers/accel/tiny and a bunch more helpers around the existing gem ones. The rule we have for drm/tiny is "1 file, less than 1kloc", and there's a bunch of them. I do think we can achieve the same for tiny accel inference engines (but it's still a bit a road). Maybe tiny accel is more like "less than 5kloc" since you need a bit more glue for the driver specific ioctl stuff - maybe that's only needed for the submit ioctl,
[PATCH] drm/i915/pxp:fix kernel-doc trivial warnings
The test robot reports some make warnings.
Fix those warnings:
drivers/gpu/drm/i915/pxp/intel_pxp_types.h:96: warning: Function parameter
or member 'dev_link' not described in 'intel_pxp'
Reported-by: k2ci
Signed-off-by: pengfuyuan
---
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
index 007de49e1ea4..41994a3294a0 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
@@ -33,7 +33,7 @@ struct intel_pxp {
*/
struct i915_pxp_component *pxp_component;
- /* @dev_link: Enforce module relationship for power management
ordering. */
+ /** @dev_link: Enforce module relationship for power management
ordering. */
struct device_link *dev_link;
/**
* @pxp_component_added: track if the pxp component has been added.
--
2.25.1
No virus found
Checked by Hillstone Network AntiVirus
Re: [PATCH v2] drm/ast: Fix long time waiting on s3/s4 resume
Hi,
sorry that this took so long.
Am 24.05.23 um 04:34 schrieb Jammy Huang:
Hi Thomas,
Could you help review this patch?
This is an issue leading to kernel panic found by Intel. Wendy has
confirmed issue resolved by this patch.
On 2023/4/14 下午 03:42, Jammy Huang wrote:
In resume, DP's launch function, ast_dp_launch, could wait at most 30
seconds before timeout to check if DP is enabled.
To avoid this problem, we only check if DP enable or not at driver probe.
You should say what the problem is. Has the DP always been disabled? Is
the DP only disabled after resume? Or is it a firmware bug?
If you have the name/email of "wendy.wang", you should probably mention
her in a Reported-by tag here.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217278
This should be
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217278
Signed-off-by: Jammy Huang
With these changes considered, feel free to add
Acked-by: Thomas Zimmermann
But I cannot test the patch or even verify the bugfix.
I do have comments below that you might want to consider as well.
---
v2 changes:
- Fix build error.
---
drivers/gpu/drm/ast/ast_dp.c | 55 +++---
drivers/gpu/drm/ast/ast_drv.h | 2 +-
drivers/gpu/drm/ast/ast_main.c | 11 +--
drivers/gpu/drm/ast/ast_post.c | 3 +-
4 files changed, 29 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
index 56483860306b..eee2f264c880 100644
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -119,53 +119,32 @@ int ast_astdp_read_edid(struct drm_device *dev,
u8 *ediddata)
/*
* Launch Aspeed DP
*/
-void ast_dp_launch(struct drm_device *dev, u8 bPower)
+void ast_dp_launch(struct drm_device *dev)
{
- u32 i = 0, j = 0, WaitCount = 1;
- u8 bDPTX = 0;
+ u32 i = 0;
u8 bDPExecute = 1;
-
struct ast_private *ast = to_ast_private(dev);
- // S3 come back, need more time to wait BMC ready.
- if (bPower)
- WaitCount = 300;
-
-
- // Wait total count by different condition.
- for (j = 0; j < WaitCount; j++) {
- bDPTX = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
TX_TYPE_MASK);
-
- if (bDPTX)
- break;
+ // Wait one second then timeout.
+ while (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
COPROCESSOR_LAUNCH) !=
+ COPROCESSOR_LAUNCH) {
+ i++;
+ // wait 100 ms
msleep(100);
- }
- // 0xE : ASTDP with DPMCU FW handling
- if (bDPTX == ASTDP_DPMCU_TX) {
- // Wait one second then timeout.
- i = 0;
-
- while (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
COPROCESSOR_LAUNCH) !=
- COPROCESSOR_LAUNCH) {
- i++;
- // wait 100 ms
- msleep(100);
-
- if (i >= 10) {
- // DP would not be ready.
- bDPExecute = 0;
- break;
- }
+ if (i >= 10) {
+ // DP would not be ready.
+ bDPExecute = 0;
+ break;
}
+ }
- if (bDPExecute)
- ast->tx_chip_types |= BIT(AST_TX_ASTDP);
+ if (!bDPExecute)
+ drm_err(dev, "Wait DPMCU executing timeout\n");
If waiting fails, should the function return an error? The caller could
then disable the DP functionality.
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5,
- (u8) ~ASTDP_HOST_EDID_READ_DONE_MASK,
- ASTDP_HOST_EDID_READ_DONE);
- }
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5,
+ (u8) ~ASTDP_HOST_EDID_READ_DONE_MASK,
+ ASTDP_HOST_EDID_READ_DONE);
}
diff --git a/drivers/gpu/drm/ast/ast_drv.h
b/drivers/gpu/drm/ast/ast_drv.h
index d51b81fea9c8..15e86394be4f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -498,7 +498,7 @@ struct ast_i2c_chan *ast_i2c_create(struct
drm_device *dev);
/* aspeed DP */
int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata);
-void ast_dp_launch(struct drm_device *dev, u8 bPower);
+void ast_dp_launch(struct drm_device *dev);
void ast_dp_power_on_off(struct drm_device *dev, bool no);
void ast_dp_set_on_off(struct drm_device *dev, bool no);
void ast_dp_set_mode(struct drm_crtc *crtc, struct
ast_vbios_mode_info *vbios_mode);
diff --git a/drivers/gpu/drm/ast/ast_main.c
b/drivers/gpu/drm/ast/ast_main.c
index f83ce77127cb..8ecddf20113f 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -254,8 +254,13 @@ static int ast_detect_chip(struct drm_device
*dev, bool *need_post)
case 0x0c:
ast->tx_chip_types = AST_TX_DP501_BIT;
}
- } else if (ast->chip == AST2600)
- ast_dp_launch(&ast->base, 0);
+ } else if (ast->chip == AST2600) {
+ if (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
TX_TYPE_MASK) ==
+ ASTDP_DPMCU_TX)
Re: [PATCH] drm/ast: Fix modeset failed on DisplayPort
Hi,
this patch also fell through the cracks. Apologies.
Am 24.05.23 um 04:29 schrieb Jammy Huang:
Hi Thomas,
Do you have other suggestion for this patch??
The main issue was that struct ast_private is now called struct
ast_device. So the current patch cannot be applied.
Please kindly advise.
On 2023/4/25 下午 03:39, Jammy Huang wrote:
Hi Thomas,
I think DP501 is OK. It doesn't use ioregs in ast_dp501_read_edid().
On 2023/4/25 下午 03:27, Thomas Zimmermann wrote:
Hi
Am 25.04.23 um 09:03 schrieb Jammy Huang:
If we switch display and update cursor together, it could lead to
modeset failed because of concurrent access to IO registers.
Add lock protection in DP's edid access to avoid this problem.
Thanks for the patch. I thought I fixed this issue already, but that
apparently only happened for SIL164 and VGA.
What about ast_dp501_connector_helper_get_modes()? Does it require
the locking as well?
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_mode.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c
b/drivers/gpu/drm/ast/ast_mode.c
index 984ec590a7e7..fe5f1fd61361 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1635,6 +1635,8 @@ static int ast_dp501_output_init(struct
ast_private *ast)
static int ast_astdp_connector_helper_get_modes(struct
drm_connector *connector)
{
void *edid;
+ struct drm_device *dev = connector->dev;
+ struct ast_private *ast = to_ast_private(dev);
We've meanwhile renamed ast_private to ast_device. Could you please
provide an updated patch for the drm-misc-next tree?
Best regards
Thomas
int succ;
int count;
@@ -1643,10 +1645,18 @@ static int
ast_astdp_connector_helper_get_modes(struct drm_connector *connector)
if (!edid)
goto err_drm_connector_update_edid_property;
+ /*
+ * Protect access to I/O registers from concurrent modesetting
+ * by acquiring the I/O-register lock.
+ */
+ mutex_lock(&ast->ioregs_lock);
+
succ = ast_astdp_read_edid(connector->dev, edid);
if (succ < 0)
goto err_kfree;
+ mutex_unlock(&ast->ioregs_lock);
+
drm_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
kfree(edid);
@@ -1654,6 +1664,7 @@ static int
ast_astdp_connector_helper_get_modes(struct drm_connector *connector)
return count;
err_kfree:
Here's a minor issue that the goto label should now be called
err_mutex_unlock.
Best regards
Thomas
+ mutex_unlock(&ast->ioregs_lock);
kfree(edid);
err_drm_connector_update_edid_property:
drm_connector_update_edid_property(connector, NULL);
base-commit: 61d325dcbc05d8fef88110d35ef7776f3ac3f68b
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] drm/i915:fix kernel-doc trivial warnings
On Wed, 24 May 2023, pengfuyuan wrote: > The test robot reports some make warnings. > > Fix those warnings: > drivers/gpu/drm/i915/i915_gpu_error.c:2174: warning: Function parameter > or member 'dump_flags' not described in 'i915_capture_error_state' > drivers/gpu/drm/i915/i915_perf.c:5307: warning: Function parameter or > member 'i915' not described in 'i915_perf_ioctl_version' > drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or > member 'active' not described in '__i915_active_fence_init' > drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or > member 'fence' not described in '__i915_active_fence_init' > drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or > member 'fn' not described in '__i915_active_fence_init' > drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or > member 'active' not described in 'i915_active_fence_set' > drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or > member 'rq' not described in 'i915_active_fence_set' > drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or > member 'active' not described in 'i915_active_fence_get' > drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or > member 'active' not described in 'i915_active_fence_isset' > drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or > member 'OP' not described in '__wait_for' > drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or > member 'COND' not described in '__wait_for' > drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or > member 'US' not described in '__wait_for' > drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or > member 'Wmin' not described in '__wait_for' > drivers/gpu/drm/i915/i915_utils.h:284: warning: Function parameter or > member 'Wmax' not described in '__wait_for' > drivers/gpu/drm/i915/i915_scatterlist.h:164: warning: Function parameter > or member 'release' not described in 'i915_refct_sgt_ops' > drivers/gpu/drm/i915/i915_scatterlist.h:187: warning: Function parameter > or member 'rsgt' not described in 'i915_refct_sgt_put' > drivers/gpu/drm/i915/i915_scatterlist.h:198: warning: Function parameter > or member 'rsgt' not described in 'i915_refct_sgt_get' > drivers/gpu/drm/i915/i915_scatterlist.h:214: warning: Function parameter > or member 'rsgt' not described in '__i915_refct_sgt_init' > drivers/gpu/drm/i915/i915_vma_resource.h:129: warning: Function parameter > or member 'wakeref' not described in 'i915_vma_resource' > > Reported-by: k2ci > Signed-off-by: pengfuyuan Thanks for your patches. However, this and all the other kernel-doc warnings have already been fixed by commits: c6948d8c221a drm/i915/ttm: fix i915_ttm_to_gem() kernel-doc 9d7fe94d3552 drm/i915/scatterlist: fix kernel-doc 08272a5a4187 drm/i915/gem: fix function pointer member kernel-doc e971121350e7 drm/i915/vma: fix struct i915_vma_bindinfo kernel-doc 8b2a7394e51d drm/i915/scatterlist: fix kernel-doc parameter documentation 70b9933c09b8 drm/i915/pxp: fix kernel-doc for member dev_link 7bc30374f84c drm/i915/pmu: drop kernel-doc 8802628237ac drm/i915/active: fix kernel-doc for function parameters f05e526e44cb drm/i915/guc: drop lots of kernel-doc markers 3a21c6b4298d drm/i915/guc: add dbgfs_node member kernel-doc 1f5cf999bedc drm/i915/engine: hide preempt_hang selftest member from kernel-doc e798a3b30dcb drm/i915/gtt: fix i915_vm_resv_put() kernel-doc parameter name 71ca9b87a72b drm/i915/context: fix kernel-doc parameter descriptions 9c55105be0a7 drm/i915/engine: fix kernel-doc function name for intel_engine_cleanup_common() faa19ce89b0b drm/i915/gem: fix i915_gem_object_lookup_rcu() kernel-doc parameter name d7b7332c0e99 drm/i915/request: drop kernel-doc 88629feedcc4 drm/i915/error: fix i915_capture_error_state() kernel-doc 9570b0390751 drm/i915/perf: fix i915_perf_ioctl_version() kernel-doc 144c3f7b1909 drm/i915/utils: drop kernel-doc from __wait_for() e1172b617a93 drm/i915/vma: fix kernel-doc function name for i915_vma_size() 67f2dd9f38ab drm/i915/gvt: fix intel_vgpu_alloc_resource() kernel-doc parameter b358793c3bf2 drm/i915/wakeref: fix kernel-doc comment efd812745405 drm/i915/tc: demote a kernel-doc comment to a regular comment Please use the drm-tip branch or linux-next to look at the latest source. BR, Jani. > --- > drivers/gpu/drm/i915/i915_active.h | 14 +++--- > drivers/gpu/drm/i915/i915_gpu_error.c| 1 + > drivers/gpu/drm/i915/i915_perf.c | 1 + > drivers/gpu/drm/i915/i915_scatterlist.h | 9 + > drivers/gpu/drm/i915/i915_utils.h| 6 ++ > drivers/gpu/drm/i915/i915_vma_resource.h | 1 + > 6 files changed, 21 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_active.h > b/drivers/gpu/drm/i915/i915_active.h > index 7eb44132183a..77c676ecc263 100644 > --- a/drive
Re: [PATCH 2/2] drm/i915/pmu: Make PMU sample array two-dimensional
On 23/05/2023 16:19, Ashutosh Dixit wrote:
No functional changes but we can remove some unsightly index computation
and read/write functions if we convert the PMU sample array from a
one-dimensional to a two-dimensional array.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_pmu.c | 60 ++---
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
2 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index b47d890d4ada1..137e0df9573ee 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -195,33 +195,6 @@ static inline s64 ktime_since_raw(const ktime_t kt)
return ktime_to_ns(ktime_sub(ktime_get_raw(), kt));
}
-static unsigned int
-__sample_idx(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
- unsigned int idx = gt_id * __I915_NUM_PMU_SAMPLERS + sample;
-
- GEM_BUG_ON(idx >= ARRAY_SIZE(pmu->sample));
-
- return idx;
-}
-
-static u64 read_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample)
-{
- return pmu->sample[__sample_idx(pmu, gt_id, sample)].cur;
-}
-
-static void
-store_sample(struct i915_pmu *pmu, unsigned int gt_id, int sample, u64 val)
-{
- pmu->sample[__sample_idx(pmu, gt_id, sample)].cur = val;
-}
-
-static void
-add_sample_mult(struct i915_pmu *pmu, unsigned int gt_id, int sample, u32 val,
u32 mul)
-{
- pmu->sample[__sample_idx(pmu, gt_id, sample)].cur += mul_u32_u32(val,
mul);
-}
IMO read and store helpers could have stayed and just changed the
implementation. Like add_sample_mult which you just moved. I would have
been a smaller patch. So dunno.. a bit of a reluctant r-b.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
-
static u64 get_rc6(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -240,7 +213,7 @@ static u64 get_rc6(struct intel_gt *gt)
spin_lock_irqsave(&pmu->lock, flags);
if (awake) {
- store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
+ pmu->sample[gt_id][__I915_SAMPLE_RC6].cur = val;
} else {
/*
* We think we are runtime suspended.
@@ -250,13 +223,13 @@ static u64 get_rc6(struct intel_gt *gt)
* counter value.
*/
val = ktime_since_raw(pmu->sleep_last[gt_id]);
- val += read_sample(pmu, gt_id, __I915_SAMPLE_RC6);
+ val += pmu->sample[gt_id][__I915_SAMPLE_RC6].cur;
}
- if (val < read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED))
- val = read_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED);
+ if (val < pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur)
+ val = pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur;
else
- store_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED, val);
+ pmu->sample[gt_id][__I915_SAMPLE_RC6_LAST_REPORTED].cur = val;
spin_unlock_irqrestore(&pmu->lock, flags);
@@ -275,9 +248,8 @@ static void init_rc6(struct i915_pmu *pmu)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
u64 val = __get_rc6(gt);
- store_sample(pmu, i, __I915_SAMPLE_RC6, val);
- store_sample(pmu, i, __I915_SAMPLE_RC6_LAST_REPORTED,
-val);
+ pmu->sample[i][__I915_SAMPLE_RC6].cur = val;
+ pmu->sample[i][__I915_SAMPLE_RC6_LAST_REPORTED].cur =
val;
pmu->sleep_last[i] = ktime_get_raw();
}
}
@@ -287,7 +259,7 @@ static void park_rc6(struct intel_gt *gt)
{
struct i915_pmu *pmu = >->i915->pmu;
- store_sample(pmu, gt->info.id, __I915_SAMPLE_RC6, __get_rc6(gt));
+ pmu->sample[gt->info.id][__I915_SAMPLE_RC6].cur = __get_rc6(gt);
pmu->sleep_last[gt->info.id] = ktime_get_raw();
}
@@ -428,6 +400,12 @@ engines_sample(struct intel_gt *gt, unsigned int period_ns)
}
}
+static void
+add_sample_mult(struct i915_pmu_sample *sample, u32 val, u32 mul)
+{
+ sample->cur += mul_u32_u32(val, mul);
+}
+
static bool
frequency_sampling_enabled(struct i915_pmu *pmu, unsigned int gt)
{
@@ -467,12 +445,12 @@ frequency_sample(struct intel_gt *gt, unsigned int
period_ns)
if (!val)
val = intel_gpu_freq(rps, rps->cur_freq);
- add_sample_mult(pmu, gt_id, __I915_SAMPLE_FREQ_ACT,
+ add_sample_mult(&pmu->sample[gt_id][__I915_SAMPLE_FREQ_ACT],
val, period_ns / 1000);
}
if (pmu->enable & config_mask(__I915_PMU_REQUESTED_FREQUENCY(gt_id))) {
- add_sample_mult(pmu, gt_id, __I915_SAMPLE_FREQ_REQ,
+ add_sample_mult(&pmu->sample[gt_id][__I915_SAMPLE_FREQ_REQ],
intel_rps_get_requeste
Re: [PATCH v2] drm/fb-helper: Fix height, width, and accel_flags in fb_var
Thanks a lot. Pushed to drm-misc-fixes.
Am 23.05.23 um 17:06 schrieb Geert Uytterhoeven:
Fbtest contains some very simple validation of the fbdev userspace API
contract. When used with shmob-drm, it reports the following warnings
and errors:
height changed from 68 to 0
height was rounded down
width changed from 111 to 0
width was rounded down
accel_flags changed from 0 to 1
The first part happens because __fill_var() resets the physical
dimensions of the first connector, as filled in by drm_setup_crtcs_fb().
Fix this by retaining the original values.
The last part happens because __fill_var() forces the FB_ACCELF_TEXT
flag on, while fbtest disables all acceleration on purpose, so it can
draw safely to the frame buffer. Fix this by setting accel_flags to
zero, as DRM does not implement any text console acceleration.
Note that this issue can also be seen in the output of fbset, which
reports "accel true".
Fixes: ee4cce0a8f03a333 ("drm/fb-helper: fix input validation gaps in
check_var")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Daniel Vetter
Tested-by: Sui Jingfeng
---
v2:
- Add Reviewed-by, Tested-by.
---
drivers/gpu/drm/drm_fb_helper.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f0e9549b6bd751de..8dc376b771d2cf22 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1379,17 +1379,19 @@ static void drm_fb_helper_fill_pixel_fmt(struct
fb_var_screeninfo *var,
}
}
-static void __fill_var(struct fb_var_screeninfo *var,
+static void __fill_var(struct fb_var_screeninfo *var, struct fb_info *info,
struct drm_framebuffer *fb)
{
int i;
var->xres_virtual = fb->width;
var->yres_virtual = fb->height;
- var->accel_flags = FB_ACCELF_TEXT;
+ var->accel_flags = 0;
var->bits_per_pixel = drm_format_info_bpp(fb->format, 0);
- var->height = var->width = 0;
+ var->height = info->var.height;
+ var->width = info->var.width;
+
var->left_margin = var->right_margin = 0;
var->upper_margin = var->lower_margin = 0;
var->hsync_len = var->vsync_len = 0;
@@ -1452,7 +1454,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
}
- __fill_var(var, fb);
+ __fill_var(var, info, fb);
/*
* fb_pan_display() validates this, but fb_set_par() doesn't and just
@@ -1908,7 +1910,7 @@ static void drm_fb_helper_fill_var(struct fb_info *info,
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xoffset = 0;
info->var.yoffset = 0;
- __fill_var(&info->var, fb);
+ __fill_var(&info->var, info, fb);
info->var.activate = FB_ACTIVATE_NOW;
drm_fb_helper_fill_pixel_fmt(&info->var, format);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v3 0/5] drm: shmobile: Fixes and enhancements
Hi Am 23.05.23 um 17:31 schrieb Geert Uytterhoeven: Hi all, Currently, there are two drivers for the LCD controller on Renesas SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs: 1. sh_mobile_lcdcfb, using the fbdev framework, 2. shmob_drm, using the DRM framework. However, only the former driver can be used, as all platform support integrates the former. None of these drivers support DT-based systems. This patch series is a first step to enable the SH-Mobile DRM driver for Renesas ARM-based SH-Mobile and R-Mobile SoCs. The next steps planned are to (1) add DT support (works, but needs a hack due to lack of (2)), and (2) convert the driver to atomic modesetting. Changes compared to v2[1]: - Add Reviewed-by. Changes compared to v1[2]: - Add Reviewed-by, - Drop dependency on ARM. This has been tested on the R-Mobile A1-based Atmark Techno Armadillo-800-EVA development board, using a temporary platform-enablement patch[3]. Thanks for applying to drm-misc! It's all been reviewed. Do you want me to merge the patchset? Best regards Thomas [1] https://lore.kernel.org/r/cover.1680273039.git.geert+rene...@glider.be/ [2] https://lore.kernel.org/r/cover.1681734821.git.geert+rene...@glider.be/ [3] https://lore.kernel.org/r/c03d4edbd650836bf6a96504df82338ec6d800ff.1680272980.git.geert+rene...@glider.be Geert Uytterhoeven (5): drm: shmobile: Use %p4cc to print fourcc codes drm: shmobile: Add support for DRM_FORMAT_XRGB drm: shmobile: Switch to drm_crtc_init_with_planes() drm: shmobile: Add missing call to drm_fbdev_generic_setup() drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms drivers/gpu/drm/shmobile/Kconfig | 4 +-- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 35 +++--- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 3 ++ drivers/gpu/drm/shmobile/shmob_drm_kms.c | 9 -- drivers/gpu/drm/shmobile/shmob_drm_plane.c | 5 5 files changed, 48 insertions(+), 8 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v6] drm/msm/dp: enable HDP plugin/unplugged interrupts at hpd_enable/disable
Kuogee Hsieh writes:
> The internal_hpd flag is set to true by dp_bridge_hpd_enable() and set to
> false by dp_bridge_hpd_disable() to handle GPIO pinmuxed into DP controller
> case. HDP related interrupts can not be enabled until internal_hpd is set
> to true. At current implementation dp_display_config_hpd() will initialize
> DP host controller first followed by enabling HDP related interrupts if
> internal_hpd was true at that time. Enable HDP related interrupts depends on
> internal_hpd status may leave system with DP driver host is in running state
> but without HDP related interrupts being enabled. This will prevent external
> display from being detected. Eliminated this dependency by moving HDP related
> interrupts enable/disable be done at dp_bridge_hpd_enable/disable() directly
> regardless of internal_hpd status.
>
> Changes in V3:
> -- dp_catalog_ctrl_hpd_enable() and dp_catalog_ctrl_hpd_disable()
> -- rewording ocmmit text
>
> Changes in V4:
> -- replace dp_display_config_hpd() with dp_display_host_start()
> -- move enable_irq() at dp_display_host_start();
>
> Changes in V5:
> -- replace dp_display_host_start() with dp_display_host_init()
>
> Changes in V6:
> -- squash remove enable_irq() and disable_irq()
>
> Fixes: cd198caddea7 ("drm/msm/dp: Rely on hpd_enable/disable callbacks")
> Signed-off-by: Kuogee Hsieh
Cherry-picked on top of v6.3.3 and verified fixes the USB-C DP
regression on sc7180 lazor. Thank you!
Tested-by: Leonard Lausen # on sc7180 lazor
Re: [PATCH v3 0/5] drm: shmobile: Fixes and enhancements
Hi Thomas,
On Wed, May 24, 2023 at 1:42 PM Thomas Zimmermann wrote:
> Am 23.05.23 um 17:31 schrieb Geert Uytterhoeven:
> > Currently, there are two drivers for the LCD controller on Renesas
> > SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
> >1. sh_mobile_lcdcfb, using the fbdev framework,
> >2. shmob_drm, using the DRM framework.
> > However, only the former driver can be used, as all platform support
> > integrates the former. None of these drivers support DT-based systems.
> >
> > This patch series is a first step to enable the SH-Mobile DRM driver for
> > Renesas ARM-based SH-Mobile and R-Mobile SoCs. The next steps planned are
> > to (1) add DT support (works, but needs a hack due to lack of (2)), and (2)
> > convert the driver to atomic modesetting.
> >
> > Changes compared to v2[1]:
> >- Add Reviewed-by.
> >
> > Changes compared to v1[2]:
> >- Add Reviewed-by,
> >- Drop dependency on ARM.
> >
> > This has been tested on the R-Mobile A1-based Atmark Techno
> > Armadillo-800-EVA development board, using a temporary
> > platform-enablement patch[3].
> >
> > Thanks for applying to drm-misc!
>
> It's all been reviewed. Do you want me to merge the patchset?
That would be great! Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
On 23/05/2023 09:37, Andi Shyti wrote: Hi Fei, finally... pushed in drm-intel-gt-next! :) I had to revert this (uapi commit only) by force pushing, luckily it was the top commit. 1) IGT is not merged yet. 2) The tools/include/uapi/drm/i915_drm.h part of the patch was not removed. Please fix both issues before re-sending and re-merging. Regards, Tvrtko
Re: [PATCH v3 0/5] drm: shmobile: Fixes and enhancements
Am 24.05.23 um 13:54 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, May 24, 2023 at 1:42 PM Thomas Zimmermann wrote:
Am 23.05.23 um 17:31 schrieb Geert Uytterhoeven:
Currently, there are two drivers for the LCD controller on Renesas
SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs:
1. sh_mobile_lcdcfb, using the fbdev framework,
2. shmob_drm, using the DRM framework.
However, only the former driver can be used, as all platform support
integrates the former. None of these drivers support DT-based systems.
This patch series is a first step to enable the SH-Mobile DRM driver for
Renesas ARM-based SH-Mobile and R-Mobile SoCs. The next steps planned are
to (1) add DT support (works, but needs a hack due to lack of (2)), and (2)
convert the driver to atomic modesetting.
Changes compared to v2[1]:
- Add Reviewed-by.
Changes compared to v1[2]:
- Add Reviewed-by,
- Drop dependency on ARM.
This has been tested on the R-Mobile A1-based Atmark Techno
Armadillo-800-EVA development board, using a temporary
platform-enablement patch[3].
Thanks for applying to drm-misc!
It's all been reviewed. Do you want me to merge the patchset?
That would be great! Thanks!
Done. Thanks for the patches.
Gr{oetje,eeting}s,
Geert
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
On 24/05/2023 12:56, Tvrtko Ursulin wrote: On 23/05/2023 09:37, Andi Shyti wrote: Hi Fei, finally... pushed in drm-intel-gt-next! :) I had to revert this (uapi commit only) by force pushing, luckily it was the top commit. 1) IGT is not merged yet. 2) The tools/include/uapi/drm/i915_drm.h part of the patch was not removed. Please fix both issues before re-sending and re-merging. 3) Please remove the BSpec 45101 reference too and replace it with a link to PRMs. I understand updated docs will land there soon which will include the necessary info. Regards, Tvrtko
Re: [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
Hi Tvrtko, > > finally... pushed in drm-intel-gt-next! :) > > I had to revert this (uapi commit only) by force pushing, luckily it was the > top commit. OK, sorry! > 1) > IGT is not merged yet. if igt is merged without the kernel it would fail, though. > 2) > The tools/include/uapi/drm/i915_drm.h part of the patch was not removed. Will follow up on these two points. Andi
Re: [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
Hi again, > > > finally... pushed in drm-intel-gt-next! :) > > > > I had to revert this (uapi commit only) by force pushing, luckily it was the > > top commit. > > OK, sorry! > > > 1) > > IGT is not merged yet. > > if igt is merged without the kernel it would fail, though. can we at least agree on having igt patches reviewed and merge them right after? > > 2) > > The tools/include/uapi/drm/i915_drm.h part of the patch was not removed. > > Will follow up on these two points. three... Andi
[PATCH 0/2] drm/panel: simple: Add support for Ampire AM-800480L1TMQW-T00H
Hi all,
This patch series adds support for the Ampire AM-800480L1TMQW-T00H 5"
WVGA TFT LCD panel, which can be found on e.g. the Atmark Techno
Armadillo-800-EVA development board.
It has been tested with a WIP DT-enhanced version of the shmob-drm
driver.
Thanks for your comments!
Geert Uytterhoeven (2):
dt-bindings: display: panel-simple: Add Ampire AM-800480L1TMQW-T00H
drm/panel: simple: Add Ampire AM-800480L1TMQW-T00H
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c | 33 +++
2 files changed, 35 insertions(+)
--
2.34.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 1/2] dt-bindings: display: panel-simple: Add Ampire AM-800480L1TMQW-T00H
Document support for the Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel. Signed-off-by: Geert Uytterhoeven --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 733e47da36e80896..f7c45e38d4b75b2e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -33,6 +33,8 @@ properties: - ampire,am-1280800n3tzqw-t00h # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel - ampire,am-480272h3tmqw-t01h +# Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel + - ampire,am-800480l1tmqw-t00h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - ampire,am800480r3tmqwa1h # Ampire AM-800600P5TMQW-TB8H 8.0" SVGA TFT LCD panel -- 2.34.1
[PATCH 2/2] drm/panel: simple: Add Ampire AM-800480L1TMQW-T00H
Add support for the Ampire AM-800480L1TMQW-T00H 5" WVGA TFT LCD panel.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/panel/panel-simple.c | 33
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5778824dffd47a31..467117c0b2c9d463 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -778,6 +778,36 @@ static const struct drm_display_mode
ampire_am800480r3tmqwa1h_mode = {
.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
};
+static const struct display_timing ampire_am_800480l1tmqw_t00h_timing = {
+ .pixelclock = { 2993, 3326, 3659 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 1, 40, 168 },
+ .hback_porch = { 88, 88, 88 },
+ .hsync_len = { 1, 128, 128 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 1, 35, 37 },
+ .vback_porch = { 8, 8, 8 },
+ .vsync_len = { 1, 2, 2 },
+ .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
+DISPLAY_FLAGS_SYNC_POSEDGE,
+};
+
+static const struct panel_desc ampire_am_800480l1tmqw_t00h = {
+ .timings = &ire_am_800480l1tmqw_t00h_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 111,
+ .height = 67,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct panel_desc ampire_am800480r3tmqwa1h = {
.modes = &ire_am800480r3tmqwa1h_mode,
.num_modes = 1,
@@ -3993,6 +4023,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
+ }, {
+ .compatible = "ampire,am-800480l1tmqw-t00h",
+ .data = &ire_am_800480l1tmqw_t00h,
}, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
--
2.34.1
Re: [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
On 24/05/2023 13:19, Andi Shyti wrote: Hi Tvrtko, finally... pushed in drm-intel-gt-next! :) I had to revert this (uapi commit only) by force pushing, luckily it was the top commit. OK, sorry! 1) IGT is not merged yet. if igt is merged without the kernel it would fail, though. Ideally it should skip, as with any new ABI testing. That way we can nicely test the older kernels with the same IGT code base (like drm-intel-fixes tree). So something like igt_require(has_pat_ext_something) should be doable. Or just igt_skip if most basic gem_create fails with the correct error code. 2) The tools/include/uapi/drm/i915_drm.h part of the patch was not removed. Will follow up on these two points. Thank you! Regards, Tvrtko
[PATCH] drm/panel: simple: Simplify matching using of_device_get_match_data()
Both the patform_driver and mipi_dsi_driver structures contain pointers
to the match table used, so the custom code to obtain match and match
data can be replaced by calls to of_device_get_match_data().
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/panel/panel-simple.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 467117c0b2c9d463..cce8e8b9c06a2ea0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4428,13 +4428,13 @@ MODULE_DEVICE_TABLE(of, platform_of_match);
static int panel_simple_platform_probe(struct platform_device *pdev)
{
- const struct of_device_id *id;
+ const struct panel_desc *desc;
- id = of_match_node(platform_of_match, pdev->dev.of_node);
- if (!id)
+ desc = of_device_get_match_data(&pdev->dev);
+ if (!desc)
return -ENODEV;
- return panel_simple_probe(&pdev->dev, id->data);
+ return panel_simple_probe(&pdev->dev, desc);
}
static int panel_simple_platform_remove(struct platform_device *pdev)
@@ -4707,15 +4707,12 @@ MODULE_DEVICE_TABLE(of, dsi_of_match);
static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi)
{
const struct panel_desc_dsi *desc;
- const struct of_device_id *id;
int err;
- id = of_match_node(dsi_of_match, dsi->dev.of_node);
- if (!id)
+ desc = of_device_get_match_data(&dsi->dev);
+ if (!desc)
return -ENODEV;
- desc = id->data;
-
err = panel_simple_probe(&dsi->dev, &desc->desc);
if (err < 0)
return err;
--
2.34.1
Re: [PATCH 12/13] drm/i915/dp: Get optimal link config to have best compressed bpp
On Tue, May 23, 2023 at 12:01:34PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 16, 2023 at 02:40:27PM +0300, Ville Syrjälä wrote:
> > On Tue, May 16, 2023 at 01:43:44PM +0300, Lisovskiy, Stanislav wrote:
> > > On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
> > > > Currently, we take the max lane, rate and pipe bpp, to get the maximum
> > > > compressed bpp possible. We then set the output bpp to this value.
> > > > This patch provides support to have max bpp, min rate and min lanes,
> > > > that can support the min compressed bpp.
> > > >
> > > > v2:
> > > > -Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
> > > > -Fix the checks for limits->max/min_bpp while iterating over list of
> > > > valid DSC bpcs. (Stan)
> > > >
> > > > v3:
> > > > -Refactor the code to have pipe bpp/compressed bpp computation and slice
> > > > count calculation separately for different cases.
> > > >
> > > > v4:
> > > > -Separate the pipe_bpp calculation for eDP and DP.
> > > >
> > > > Signed-off-by: Ankit Nautiyal
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 305 +++-
> > > > 1 file changed, 245 insertions(+), 60 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 39e2bf3d738d..578320220c9a 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -1642,6 +1642,209 @@ static bool intel_dp_dsc_supports_format(struct
> > > > intel_dp *intel_dp,
> > > > return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> > > > sink_dsc_format);
> > > > }
> > > >
> > > > +static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int
> > > > compressed_bpp,
> > > > +const struct drm_display_mode
> > > > *adjusted_mode)
> > > > +{
> > > > + int mode_rate =
> > > > intel_dp_link_required(adjusted_mode->crtc_clock, compressed_bpp);
> > > > + int link_avail = intel_dp_max_data_rate(link_rate, lane_count);
> > > > +
> > > > + return mode_rate <= link_avail;
> > > > +}
> > > > +
> > > > +static int dsc_compute_link_config(struct intel_dp *intel_dp,
> > > > + struct intel_crtc_state *pipe_config,
> > > > + struct link_config_limits *limits,
> > > > + int pipe_bpp,
> > > > + u16 compressed_bpp,
> > > > + int timeslots)
> > > > +{
> > > > + const struct drm_display_mode *adjusted_mode =
> > > > + &pipe_config->hw.adjusted_mode;
> > > > + int link_rate, lane_count;
> > > > + int dsc_max_bpp;
> > > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < intel_dp->num_common_rates; i++) {
> > > > + link_rate = intel_dp_common_rate(intel_dp, i);
> > > > + if (link_rate < limits->min_rate || link_rate >
> > > > limits->max_rate)
> > > > + continue;
> > > > +
> > > > + for (lane_count = limits->min_lane_count;
> > > > +lane_count <= limits->max_lane_count;
> > > > +lane_count <<= 1) {
> > > > + dsc_max_bpp =
> > > > intel_dp_dsc_get_max_compressed_bpp(dev_priv,
> > > > +
> > > > link_rate,
> > > > +
> > > > lane_count,
> > > > +
> > > > adjusted_mode->crtc_clock,
> > > > +
> > > > adjusted_mode->crtc_hdisplay,
> > > > +
> > > > pipe_config->bigjoiner_pipes,
> > > > +
> > > > pipe_config->output_format,
> > > > +
> > > > pipe_bpp, timeslots);
> > > > + /*
> > > > +* According to DSC 1.2a Section 4.1.1 Table
> > > > 4.1 the maximum
> > > > +* supported PPS value can be 63.9375 and with
> > > > the further
> > > > +* mention that bpp should be programmed double
> > > > the target bpp
> > > > +* restricting our target bpp to be 31.9375 at
> > > > max
> > > > +*/
> > > > + if (pipe_config->output_format ==
> > > > INTEL_OUTPUT_FORMAT_YCBCR420)
> > > > + dsc_max_bpp = min_t(u16, dsc_max_bpp,
> > > > 31);
> > > > +
> > > > + if (compressed_b
[PULL] drm-misc-next
Hi Dave and Daniel, here is this week's PR for drm-misc-next. I'm taking over while Maxime is away. There's support for a few more panels and bridges. In fbdev, I/O helpers are now implemented within the architecture code. DRM's shmobile driver received some updates. Best regards Thomas drm-misc-next-2023-05-24: drm-misc-next for v6.5: UAPI Changes: Cross-subsystem Changes: * fbdev: Move framebuffer I/O helpers to , fix naming * firmware: Init sysfb as early as possible Core Changes: * DRM scheduler: Rename interfaces * ttm: Store ttm_device_funcs in .rodata * Replace strlcpy() with strscpy() in various places * Cleanups Driver Changes: * bridge: analogix: Fix endless probe loop; samsung-dsim: Support swapping clock/data polarity; tc358767: Use devm_ Cleanups; * gma500: Fix I/O-memory access * panel: boe-tv101wum-nl6: Improve initialization; sharp-ls043t1le001: Mode fixes; simple: Add BOE EV121WXM-N10-1850 plus DT bindings; AddS6D7AA0 plus DT bindings; Cleanups * ssd1307x: Style fixes * sun4i: Release clocks * msm: Fix I/O-memory access * nouveau: Cleanups * shmobile: Support Renesas; Enable framebuffer console; Various fixes * vkms: Fix RGB565 conversion The following changes since commit 4795c78768bcbd58d4ffab650674d314dc6dd772: drm: sun4i: calculate proper DCLK rate for DSI (2023-05-10 16:03:19 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-05-24 for you to fetch changes up to 4bd65789ba847f39e37e0041c10aad5dff1760b6: drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms (2023-05-24 14:00:49 +0200) drm-misc-next for v6.5: UAPI Changes: Cross-subsystem Changes: * fbdev: Move framebuffer I/O helpers to , fix naming * firmware: Init sysfb as early as possible Core Changes: * DRM scheduler: Rename interfaces * ttm: Store ttm_device_funcs in .rodata * Replace strlcpy() with strscpy() in various places * Cleanups Driver Changes: * bridge: analogix: Fix endless probe loop; samsung-dsim: Support swapping clock/data polarity; tc358767: Use devm_ Cleanups; * gma500: Fix I/O-memory access * panel: boe-tv101wum-nl6: Improve initialization; sharp-ls043t1le001: Mode fixes; simple: Add BOE EV121WXM-N10-1850 plus DT bindings; AddS6D7AA0 plus DT bindings; Cleanups * ssd1307x: Style fixes * sun4i: Release clocks * msm: Fix I/O-memory access * nouveau: Cleanups * shmobile: Support Renesas; Enable framebuffer console; Various fixes * vkms: Fix RGB565 conversion Alexander Stein (1): drm/bridge: tc358767: Switch to devm MIPI-DSI helpers Anup Sharma (1): gpu: drm: bridge: No need to set device_driver owner Arnd Bergmann (1): drm/nouveau: dispnv50: fix missing-prototypes warning Artur Weber (4): dt-bindings: display: panel: Add Samsung S6D7AA0 LCD panel controller drm/panel: Add Samsung S6D7AA0 panel controller driver MAINTAINERS: Add entry for Samsung S6D7AA0 LCD panel controller driver drm/panel: samsung-s6d7aa0: use pointer for drm_mode in panel desc struct Azeem Shaikh (2): drm/bridge: dw-hdmi: Replace all non-returning strlcpy with strscpy dma-buf/sw_sync: Replace all non-returning strlcpy with strscpy Cong Yang (1): drm/panel: Modify innolux hj110iz panel initial code Dmitry Baryshkov (2): drm/panel: sharp-ls043t1le01: adjust mode settings drm/panel: sharp-ls043t1le01: drop dummy functions and data fields Fabio Estevam (1): dt-bindings: samsung,mipi-dsim: Add 'lane-polarities' Francesco Dolcini (1): drm/bridge: tc358768: remove unneeded semicolon Geert Uytterhoeven (5): drm: shmobile: Use %p4cc to print fourcc codes drm: shmobile: Add support for DRM_FORMAT_XRGB drm: shmobile: Switch to drm_crtc_init_with_planes() drm: shmobile: Add missing call to drm_fbdev_generic_setup() drm: shmobile: Make DRM_SHMOBILE visible on Renesas SoC platforms Huacai Chen (1): drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync Jani Nikula (1): drm/ttm: let struct ttm_device_funcs be placed in rodata Javier Martinez Canillas (1): drm/ssd130x: Fix include guard name Krzysztof Kozlowski (1): drm/nouveau: constify pointers to hwmon_channel_info Liu Ying (2): dt-bindings: display: simple: Add BOE EV121WXM-N10-1850 panel drm/panel: panel-simple: Add BOE EV121WXM-N10-1850 panel support Luben Tuikov (2): drm/sched: Rename to drm_sched_can_queue() drm/sched: Rename to drm_sched_wakeup_if_can_queue() Marek Vasut (2): dt-bindings: display: bridge: tc358867: Document TC358867/TC9595 compatible drm: bridge: samsung-dsim: Implement support for clock/data polarity swap Maíra Canal (2): drm
Re: [PATCH V7 0/6] drm: bridge: samsung-dsim: Support variable clocking
Hi Adam, On Tue, May 23, 2023 at 8:49 PM Adam Ford wrote: > Inki, > > I haven't heard back from you on whether or not you want the bindings > patch to be included with me resending the series as V7 or if you're > OK with a single, stand-alone patch. > Will you let me know? I have the patch standing by waiting for > instructions. If you're not the right person to ask, please let me > know who the right person is. Neil has also been collecting samsung-dsim patches. Maybe he can clarify.
Re: [PATCH V7 0/6] drm: bridge: samsung-dsim: Support variable clocking
On Wed, May 24, 2023 at 7:45 AM Fabio Estevam wrote: > > Hi Adam, > > On Tue, May 23, 2023 at 8:49 PM Adam Ford wrote: > > > Inki, > > > > I haven't heard back from you on whether or not you want the bindings > > patch to be included with me resending the series as V7 or if you're > > OK with a single, stand-alone patch. > > Will you let me know? I have the patch standing by waiting for > > instructions. If you're not the right person to ask, please let me > > know who the right person is. > > Neil has also been collecting samsung-dsim patches. Maybe he can clarify. If it matters, my preference all along was to do the bindings as a separate thing once the driver updates were merged into the tree. Since the bindings can be done in different ways, I was hoping to have a separate discussion on the right way to do the bindings. If they need to be part of the series, I can do that. adam
Re: [Intel-gfx] [PATCH v10 0/2] drm/i915: Allow user to set cache at BO creation
On 24/05/2023 13:30, Andi Shyti wrote: Hi again, finally... pushed in drm-intel-gt-next! :) I had to revert this (uapi commit only) by force pushing, luckily it was the top commit. OK, sorry! 1) IGT is not merged yet. if igt is merged without the kernel it would fail, though. can we at least agree on having igt patches reviewed and merge them right after? Yeah that okay, just make it _right_ after. :) Regards, Tvrtko
