Re: [PATCH v1 4/4] mfd: lm3533: Remove the driver
Hi Andy, kernel test robot noticed the following build errors: [auto build test ERROR on jic23-iio/togreg] [also build test ERROR on lee-backlight/for-backlight-fixes linus/master v6.10-rc1 next-20240531] [cannot apply to lee-backlight/for-backlight-next pavel-leds/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/backlight-lm3533_bl-Remove-the-driver/20240601-011153 base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg patch link: https://lore.kernel.org/r/20240531170844.1595468-5-andriy.shevchenko%40linux.intel.com patch subject: [PATCH v1 4/4] mfd: lm3533: Remove the driver config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20240601/202406010822.ovberegc-...@intel.com/config) compiler: alpha-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240601/202406010822.ovberegc-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202406010822.ovberegc-...@intel.com/ All errors (new ones prefixed by >>): >> drivers/mfd/lm3533-ctrlbank.c:13:10: fatal error: linux/mfd/lm3533.h: No >> such file or directory 13 | #include | ^~~~ compilation terminated. vim +13 drivers/mfd/lm3533-ctrlbank.c 16c5c023aac862 Johan Hovold 2012-05-03 12 16c5c023aac862 Johan Hovold 2012-05-03 @13 #include 16c5c023aac862 Johan Hovold 2012-05-03 14 16c5c023aac862 Johan Hovold 2012-05-03 15 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [git pull] drm fixes for 6.10-rc2
The pull request you sent on Sat, 1 Jun 2024 06:46:21 +1000: > https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-06-01 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cc8ed4d0a8486c7472cd72ec3c19957e509dc68c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] kernel/resource: optimize find_next_iomem_res
On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko < andriy.shevche...@linux.intel.com> wrote: > On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote: > > We can skip children resources when the parent resource does not cover > > the range. > > > > This should help vmf_insert_* users on x86, such as several DRM drivers. > > On my AMD Ryzen 5 7520C, when streaming data from cpu memory into amdgpu > > bo, the throughput goes from 5.1GB/s to 6.6GB/s. perf report says > > > > 34.69%--__do_fault > > 34.60%--amdgpu_gem_fault > > 34.00%--ttm_bo_vm_fault_reserved > > 32.95%--vmf_insert_pfn_prot > > 25.89%--track_pfn_insert > > 24.35%--lookup_memtype > > 21.77%--pat_pagerange_is_ram > > 20.80%--walk_system_ram_range > > 17.42%--find_next_iomem_res > > > > before this change, and > > > > 26.67%--__do_fault > > 26.57%--amdgpu_gem_fault > > 25.83%--ttm_bo_vm_fault_reserved > > 24.40%--vmf_insert_pfn_prot > > 14.30%--track_pfn_insert > > 12.20%--lookup_memtype > > 9.34%--pat_pagerange_is_ram > > 8.22%--walk_system_ram_range > > 5.09%--find_next_iomem_res > > > > after. > > Is there any documentation that explicitly says that the children resources > must not overlap parent's one? Do we have some test cases? (Either way they > needs to be added / expanded). > I think it's the opposite. The assumption here is that a child is always a subset of its parent. Thus, if the range to be checked is not covered by a parent, we can skip the children. That's guaranteed by __request_resource. I am less sure about __insert_resource but it appears to be the case too. FWIW, resource_is_exclusive has the same assumption already. It looks like I need to do some refactoring to add tests. > P.S> I'm not so sure about this change. It needs a thoroughly testing, esp. > in PCI case. Cc'ing to Ilpo. > What's special about PCI? -- > With Best Regards, > Andy Shevchenko > > >
Re: [PATCH] Documentation/accel/qaic: Fix typo 'phsyical'
On 5/31/2024 8:20 AM, Shuah Khan wrote: On 5/31/24 00:09, Danish Prakash wrote: (as part of LFX Linux Mentorship program) Please add proper commit log for this change. Looks like a good fix, and I'd love to take it, but the commit log needs some content. Signed-off-by: Danish Prakash --- Documentation/accel/qaic/qaic.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/accel/qaic/qaic.rst b/Documentation/accel/qaic/qaic.rst index efb7771273bb..628bf2f7a416 100644 --- a/Documentation/accel/qaic/qaic.rst +++ b/Documentation/accel/qaic/qaic.rst @@ -93,7 +93,7 @@ commands (does not impact QAIC). uAPI -QAIC creates an accel device per phsyical PCIe device. This accel device exists +QAIC creates an accel device per physical PCIe device. This accel device exists for as long as the PCIe device is known to Linux. The PCIe device may not be in the state to accept requests from userspace at thanks, -- Shuah
[git pull] drm fixes for 6.10-rc2
Hi Linus, This is the weekly fixes pull. Lots of small fixes across the board, one BUG_ON fix in shmem seems most important, otherwise amdgpu, i915, xe mostly with small fixes to all the other drivers. Dave. drm-fixes-2024-06-01: drm fixes for 6.10-rc2 shmem: - fix BUG_ON in COW handling - Warn when trying to pin imported objects buddy: - fix page size handling dma-buf: - sw-sync: Don't interfere with IRQ handling - Fix kthreads-handling error path i915: - Fix a race in audio component by registering it later - Make DPT object unshrinkable to avoid shrinking when framebuffer has not shrunk - Fix CCS id calculation to fix a perf regression - Fix selftest caching mode - Fix FIELD_PREP compiler warnings - Fix indefinite wait for GT wakeref release - Revert overeager multi-gt pm reference removal xe: - One pcode polling timeout change - One fix for deadlocks for faulting VMs - One error-path lock imbalance fix amdgpu: - RAS fix - Fix colorspace property for MST connectors - Fix for PCIe DPM - Silence UBSAN warning - GPUVM robustness fix - Partition fix - Drop deprecated I2C_CLASS_SPD amdkfd: - Revert unused changes for certain 11.0.3 devices - Simplify APU VRAM handling lima: - Fix dma_resv-related deadlock in object pin msm: - Remove build-time dependency on Python 3.9 nouveau: - nvif: Fix possible integer overflow panel: - lg-sw43408: Select DP helpers; Declare backlight ops as static - sitronix-st7789v: Various fixes for jt240mhqs_hwt_ek_e3 panel panfrost: - Fix dma_resv-related deadlock in object pin The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0: Linux 6.10-rc1 (2024-05-26 15:20:12 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-06-01 for you to fetch changes up to a2ce3f7752bfbb47e659574fc2e1e6942bca3c29: Merge tag 'drm-misc-fixes-2024-05-30' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes (2024-05-31 11:51:20 +1000) drm fixes for 6.10-rc2 shmem: - fix BUG_ON in COW handling - Warn when trying to pin imported objects buddy: - fix page size handling dma-buf: - sw-sync: Don't interfere with IRQ handling - Fix kthreads-handling error path i915: - Fix a race in audio component by registering it later - Make DPT object unshrinkable to avoid shrinking when framebuffer has not shrunk - Fix CCS id calculation to fix a perf regression - Fix selftest caching mode - Fix FIELD_PREP compiler warnings - Fix indefinite wait for GT wakeref release - Revert overeager multi-gt pm reference removal xe: - One pcode polling timeout change - One fix for deadlocks for faulting VMs - One error-path lock imbalance fix amdgpu: - RAS fix - Fix colorspace property for MST connectors - Fix for PCIe DPM - Silence UBSAN warning - GPUVM robustness fix - Partition fix - Drop deprecated I2C_CLASS_SPD amdkfd: - Revert unused changes for certain 11.0.3 devices - Simplify APU VRAM handling lima: - Fix dma_resv-related deadlock in object pin msm: - Remove build-time dependency on Python 3.9 nouveau: - nvif: Fix possible integer overflow panel: - lg-sw43408: Select DP helpers; Declare backlight ops as static - sitronix-st7789v: Various fixes for jt240mhqs_hwt_ek_e3 panel panfrost: - Fix dma_resv-related deadlock in object pin Abhinav Kumar (1): drm/msm: remove python 3.9 dependency for compiling msm Adrián Larumbe (3): drm/panfrost: Fix dma_resv deadlock at drm object pin time drm/lima: Fix dma_resv deadlock at drm object pin time drm/gem-shmem: Add import attachment warning to locked pin function Alex Deucher (4): drm/amdgpu: Adjust logic in amdgpu_device_partner_bandwidth() drm/amdgpu: silence UBSAN warning Revert "drm/amdkfd: fix gfx_target_version for certain 11.0.3 devices" drm/amdkfd: simplify APU VRAM handling Andi Shyti (1): drm/i915/gt: Fix CCS id's calculation for CCS mode setting Arnd Bergmann (1): drm/i915/guc: avoid FIELD_PREP warning Chris Wilson (1): drm/i915/gt: Disarm breadcrumbs if engines are already idle Daniel Vetter (1): Merge tag 'drm-misc-fixes-2024-05-16' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Dave Airlie (5): Merge tag 'drm-misc-fixes-2024-05-23' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Merge tag 'drm-intel-fixes-2024-05-30' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes Merge tag 'drm-xe-fixes-2024-05-30' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Merge tag 'amd-drm-fixes-6.10-2024-05-30' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2024-05-30' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Dmitry Baryshkov (2): drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER
[PATCH 1/2] dt-bindings: display: bridge: tc358867: Document default DP preemphasis
Document default DP port preemphasis configurable via new DT property "toshiba,pre-emphasis". This is useful in case the DP link properties are known and starting link training from preemphasis setting of 0 dB is not useful. The preemphasis can be set separately for both DP lanes in range 0=0dB, 1=3.5dB, 2=6dB . Signed-off-by: Marek Vasut --- Cc: Andrzej Hajda Cc: Conor Dooley Cc: Daniel Vetter Cc: David Airlie Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Krzysztof Kozlowski Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Neil Armstrong Cc: Rob Herring Cc: Robert Foss Cc: Thomas Zimmermann Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: ker...@dh-electronics.com --- .../display/bridge/toshiba,tc358767.yaml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index 2ad0cd6dd49e0..dcf56e996ee22 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -98,6 +98,24 @@ properties: reference to a valid eDP panel input endpoint node. This port is optional, treated as DP panel if not defined +properties: + endpoint: +$ref: /schemas/media/video-interfaces.yaml# +unevaluatedProperties: false + +properties: + toshiba,pre-emphasis: +description: + Display port output Pre-Emphasis settings for both ports. +$ref: /schemas/types.yaml#/definitions/uint32-array +minItems: 2 +maxItems: 2 +items: + enum: +- 0 # -6dB de-emphasis +- 1 # -3.5dB de-emphasis +- 2 # No de-emphasis + oneOf: - required: - port@0 -- 2.43.0
[PATCH 2/2] drm/bridge: tc358767: Add configurable default preemphasis
Make the default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis setting of 0 dB
is not useful. The preemphasis can be set separately for both DP lanes
in range 0=0dB, 1=3.5dB, 2=6dB .
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Conor Dooley
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Krzysztof Kozlowski
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 49 ++-
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 1243918320a7d..32639865fea07 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -241,6 +241,10 @@
/* Link Training */
#define DP0_SRCCTRL0x06a0
+#define DP0_SRCCTRL_PRE1 GENMASK(29, 28)
+#define DP0_SRCCTRL_SWG1 GENMASK(25, 24)
+#define DP0_SRCCTRL_PRE0 GENMASK(21, 20)
+#define DP0_SRCCTRL_SWG0 GENMASK(17, 16)
#define DP0_SRCCTRL_SCRMBLDIS BIT(13)
#define DP0_SRCCTRL_EN810B BIT(12)
#define DP0_SRCCTRL_NOTP (0 << 8)
@@ -278,6 +282,8 @@
#define AUDIFDATA6 0x0720 /* DP0 Audio Info Frame Bytes 27 to 24
*/
#define DP1_SRCCTRL0x07a0 /* DP1 Control Register */
+#define DP1_SRCCTRL_PREGENMASK(21, 20)
+#define DP1_SRCCTRL_SWGGENMASK(17, 16)
/* PHY */
#define DP_PHY_CTRL0x0800
@@ -369,6 +375,7 @@ struct tc_data {
u32 rev;
u8 assr;
+ u8 pre_emphasis[2];
struct gpio_desc*sd_gpio;
struct gpio_desc*reset_gpio;
@@ -1090,13 +1097,17 @@ static int tc_main_link_enable(struct tc_data *tc)
return ret;
}
- ret = regmap_write(tc->regmap, DP0_SRCCTRL, tc_srcctrl(tc));
+ ret = regmap_write(tc->regmap, DP0_SRCCTRL,
+ tc_srcctrl(tc) |
+ FIELD_PREP(DP0_SRCCTRL_PRE0, tc->pre_emphasis[0]) |
+ FIELD_PREP(DP0_SRCCTRL_PRE1, tc->pre_emphasis[1]));
if (ret)
return ret;
/* SSCG and BW27 on DP1 must be set to the same as on DP0 */
ret = regmap_write(tc->regmap, DP1_SRCCTRL,
(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
-((tc->link.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
+((tc->link.rate != 162000) ? DP0_SRCCTRL_BW27 : 0) |
+FIELD_PREP(DP1_SRCCTRL_PRE, tc->pre_emphasis[1]));
if (ret)
return ret;
@@ -1188,8 +1199,10 @@ static int tc_main_link_enable(struct tc_data *tc)
goto err_dpcd_write;
/* Reset voltage-swing & pre-emphasis */
- tmp[0] = tmp[1] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
- DP_TRAIN_PRE_EMPH_LEVEL_0;
+ tmp[0] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
+FIELD_PREP(DP_TRAIN_PRE_EMPHASIS_MASK, tc->pre_emphasis[0]);
+ tmp[1] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 |
+FIELD_PREP(DP_TRAIN_PRE_EMPHASIS_MASK, tc->pre_emphasis[1]);
ret = drm_dp_dpcd_write(aux, DP_TRAINING_LANE0_SET, tmp, 2);
if (ret < 0)
goto err_dpcd_write;
@@ -1213,7 +1226,9 @@ static int tc_main_link_enable(struct tc_data *tc)
ret = regmap_write(tc->regmap, DP0_SRCCTRL,
tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
DP0_SRCCTRL_AUTOCORRECT |
- DP0_SRCCTRL_TP1);
+ DP0_SRCCTRL_TP1 |
+ FIELD_PREP(DP0_SRCCTRL_PRE0, tc->pre_emphasis[0]) |
+ FIELD_PREP(DP0_SRCCTRL_PRE1, tc->pre_emphasis[1]));
if (ret)
return ret;
@@ -1248,7 +1263,9 @@ static int tc_main_link_enable(struct tc_data *tc)
ret = regmap_write(tc->regmap, DP0_SRCCTRL,
tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
DP0_SRCCTRL_AUTOCORRECT |
- DP0_SRCCTRL_TP2);
+ DP0_SRCCTRL_TP2 |
+ FIELD_PREP(DP0_SRCCTRL_PRE0, tc->pre_emphasis[0]) |
+ FIELD_PREP(DP0_SRCCTRL_PRE1, tc->pre_emphasis[1]));
if (ret)
return ret;
@@ -1274,7 +1291,9 @@ static int tc_main_link_enable(struct tc_data *tc)
/* Clear Training Pattern, set AutoCorrect Mode = 1 */
ret = regmap_write(tc->regmap, DP0_SRCCTRL,
[PATCH 4/6] drm/bridge: tc358767: Disable MIPI_DSI_CLOCK_NON_CONTINUOUS
The MIPI_DSI_CLOCK_NON_CONTINUOUS causes visible artifacts in high
resolution modes, disable it. Namely, in DSI->DP mode 1920x1200 24
bpp 59.95 Hz, with DSI bus at maximum 1 Gbps per lane setting, the
image contains jittering empty lines.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index f16728256991a..926921a8d29d7 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2303,7 +2303,7 @@ static int tc_mipi_dsi_host_attach(struct tc_data *tc)
dsi->lanes = dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ MIPI_DSI_MODE_LPM;
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
--
2.43.0
[PATCH 3/6] drm/bridge: tc358767: Drop line_pixel_subtract
This line_pixel_subtract is no longer needed now that the bridge can
request and obtain specific pixel clock on input to the bridge, with
clock frequency that matches the Pixel PLL frequency.
The line_pixel_subtract is now always 0, so drop it entirely.
The line_pixel_subtract was not reliable as it never worked when the
Pixel PLL and input clock were off just so that the required amount
of pixels to subtract would not be whole integer.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 252cc08dcc4a8..f16728256991a 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -382,9 +382,6 @@ struct tc_data {
/* HPD pin number (0 or 1) or -ENODEV */
int hpd_pin;
-
- /* Number of pixels to subtract from a line due to pixel clock delta */
- u32 line_pixel_subtract;
};
static inline struct tc_data *aux_to_tc(struct drm_dp_aux *a)
@@ -661,11 +658,7 @@ static int tc_pxl_pll_calc(struct tc_data *tc, u32 refclk,
u32 pixelclock,
return -EINVAL;
}
- tc->line_pixel_subtract = tc->mode.htotal -
- DIV_ROUND_UP(tc->mode.htotal * (u64)best_pixelclock,
(u64)pixelclock);
-
- dev_dbg(tc->dev, "PLL: got %d, delta %d (subtract %d px)\n",
best_pixelclock,
- best_delta, tc->line_pixel_subtract);
+ dev_dbg(tc->dev, "PLL: got %d, delta %d\n", best_pixelclock,
best_delta);
dev_dbg(tc->dev, "PLL: %d / %d / %d * %d / %d\n", refclk,
ext_div[best_pre], best_div, best_mul, ext_div[best_post]);
@@ -909,13 +902,6 @@ static int tc_set_common_video_mode(struct tc_data *tc,
upper_margin, lower_margin, vsync_len);
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
- if (right_margin > tc->line_pixel_subtract) {
- right_margin -= tc->line_pixel_subtract;
- } else {
- dev_err(tc->dev, "Bridge pixel clock too slow for mode\n");
- right_margin = 0;
- }
-
/*
* LCD Ctl Frame Size
* datasheet is not clear of vsdelay in case of DPI
--
2.43.0
[PATCH 5/6] drm/bridge: tc358767: Set LSCLK divider for SYSCLK to 1
The only information in the datasheet regarding this divider is a note
in SYS_PLLPARAM register documentation which states that when LSCLK is
270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when
LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test
confirms using LSCLK_DIV 1 has no adverse effects either. In the worst
case, the internal TC358767 clock would run faster.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 926921a8d29d7..156297131a6cc 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -738,7 +738,7 @@ static int tc_stream_clock_calc(struct tc_data *tc)
static int tc_set_syspllparam(struct tc_data *tc)
{
unsigned long rate;
- u32 pllparam = SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
+ u32 pllparam = SYSCLK_SEL_LSCLK | LSCLK_DIV_1;
rate = clk_get_rate(tc->refclk);
switch (rate) {
--
2.43.0
[PATCH 6/6] Revert "drm/bridge: tc358767: Set default CLRSIPO count"
This reverts commit 01338bb82fed40a6a234c2b36a92367c8671adf0. With clock improvements in place, this seems to be no longer necessary. Set the CLRSIPO to default setting recommended by manufacturer. Signed-off-by: Marek Vasut --- Cc: Andrzej Hajda Cc: Daniel Vetter Cc: David Airlie Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Neil Armstrong Cc: Robert Foss Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: ker...@dh-electronics.com --- drivers/gpu/drm/bridge/tc358767.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 156297131a6cc..1243918320a7d 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1356,10 +1356,10 @@ static int tc_dsi_rx_enable(struct tc_data *tc) u32 value; int ret; - regmap_write(tc->regmap, PPI_D0S_CLRSIPOCOUNT, 25); - regmap_write(tc->regmap, PPI_D1S_CLRSIPOCOUNT, 25); - regmap_write(tc->regmap, PPI_D2S_CLRSIPOCOUNT, 25); - regmap_write(tc->regmap, PPI_D3S_CLRSIPOCOUNT, 25); + regmap_write(tc->regmap, PPI_D0S_CLRSIPOCOUNT, 5); + regmap_write(tc->regmap, PPI_D1S_CLRSIPOCOUNT, 5); + regmap_write(tc->regmap, PPI_D2S_CLRSIPOCOUNT, 5); + regmap_write(tc->regmap, PPI_D3S_CLRSIPOCOUNT, 5); regmap_write(tc->regmap, PPI_D0S_ATMR, 0); regmap_write(tc->regmap, PPI_D1S_ATMR, 0); regmap_write(tc->regmap, PPI_TX_RX_TA, TTA_GET | TTA_SURE); -- 2.43.0
[PATCH 2/6] drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the
Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and
pass it down the display pipeline to obtain exactly this frequency on input
into this bridge.
The precise input frequency that matches the Pixel PLL frequency is
important for this bridge, as if the frequencies do not match, the
bridge does suffer VFIFO overruns or underruns.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 45af31414ce48..252cc08dcc4a8 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1619,6 +1619,18 @@ static int tc_dpi_atomic_check(struct drm_bridge *bridge,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct tc_data *tc = bridge_to_tc(bridge);
+ int adjusted_clock = 0;
+ int ret;
+
+ ret = tc_pxl_pll_calc(tc, clk_get_rate(tc->refclk),
+ crtc_state->adjusted_mode.clock * 1000,
+ _clock, NULL);
+ if (ret)
+ return ret;
+
+ crtc_state->adjusted_mode.clock = adjusted_clock / 1000;
+
/* DSI->DPI interface clock limitation: upto 100 MHz */
if (crtc_state->adjusted_mode.clock > 10)
return -EINVAL;
@@ -1631,6 +1643,18 @@ static int tc_edp_atomic_check(struct drm_bridge *bridge,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct tc_data *tc = bridge_to_tc(bridge);
+ int adjusted_clock = 0;
+ int ret;
+
+ ret = tc_pxl_pll_calc(tc, clk_get_rate(tc->refclk),
+ crtc_state->adjusted_mode.clock * 1000,
+ _clock, NULL);
+ if (ret)
+ return ret;
+
+ crtc_state->adjusted_mode.clock = adjusted_clock / 1000;
+
/* DPI->(e)DP interface clock limitation: upto 154 MHz */
if (crtc_state->adjusted_mode.clock > 154000)
return -EINVAL;
--
2.43.0
[PATCH 1/6] drm/bridge: tc358767: Split tc_pxl_pll_en() into parameter calculation and enablement
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL
parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc()
and then configures the Pixel PLL register.
This is a preparatory patch for further rework, where tc_pxl_pll_calc()
will also be used to find out the exact clock frequency generated by the
Pixel PLL. This frequency will be used as adjusted_mode clock frequency
and passed down the display pipeline to obtain exactly this frequency
on input into this bridge.
The precise input frequency that matches the Pixel PLL frequency is
important for this bridge, as if the frequencies do not match, the
bridge does suffer VFIFO overruns or underruns.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 32 ---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 029002938a5e8..45af31414ce48 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -580,9 +580,9 @@ static int tc_pllupdate(struct tc_data *tc, unsigned int
pllctrl)
return 0;
}
-static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
+static int tc_pxl_pll_calc(struct tc_data *tc, u32 refclk, u32 pixelclock,
+ int *out_best_pixelclock, u32 *out_pxl_pllparam)
{
- int ret;
int i_pre, best_pre = 1;
int i_post, best_post = 1;
int div, best_div = 1;
@@ -678,11 +678,6 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk,
u32 pixelclock)
if (best_mul == 128)
best_mul = 0;
- /* Power up PLL and switch to bypass */
- ret = regmap_write(tc->regmap, PXL_PLLCTRL, PLLBYP | PLLEN);
- if (ret)
- return ret;
-
pxl_pllparam = vco_hi << 24; /* For PLL VCO >= 300 MHz = 1 */
pxl_pllparam |= ext_div[best_pre] << 20; /* External Pre-divider */
pxl_pllparam |= ext_div[best_post] << 16; /* External Post-divider */
@@ -690,6 +685,29 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk,
u32 pixelclock)
pxl_pllparam |= best_div << 8; /* Divider for PLL RefClk */
pxl_pllparam |= best_mul; /* Multiplier for PLL */
+ if (out_best_pixelclock)
+ *out_best_pixelclock = best_pixelclock;
+
+ if (out_pxl_pllparam)
+ *out_pxl_pllparam = pxl_pllparam;
+
+ return 0;
+}
+
+static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
+{
+ u32 pxl_pllparam = 0;
+ int ret;
+
+ ret = tc_pxl_pll_calc(tc, refclk, pixelclock, NULL, _pllparam);
+ if (ret)
+ return ret;
+
+ /* Power up PLL and switch to bypass */
+ ret = regmap_write(tc->regmap, PXL_PLLCTRL, PLLBYP | PLLEN);
+ if (ret)
+ return ret;
+
ret = regmap_write(tc->regmap, PXL_PLLPARAM, pxl_pllparam);
if (ret)
return ret;
--
2.43.0
[PATCH 0/2] drm bridge: drop drm_bridge_chain_mode_fixup.
I had a few bridge related patches in an old branch. They were last posted here almost one year ago: https://lore.kernel.org/dri-devel/20220717174454.46616-1-...@ravnborg.org/ The following two patches gets rid of drm_bridge_chain_mode_fixup. The patches was already rb / ab - but due to the age a repost is due before applying the patches. Sam --- Sam Ravnborg (2): drm/mediatek: Drop chain_mode_fixup call in mode_valid() drm/bridge: Drop drm_bridge_chain_mode_fixup drivers/gpu/drm/drm_bridge.c| 37 - drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 --- include/drm/drm_bridge.h| 3 --- 3 files changed, 51 deletions(-) --- base-commit: c9402efe492bb46ccbf94fedc4783eb8f8747567 change-id: 20240531-bridge_chain_mode-9ed8528e92cd Best regards, -- Sam Ravnborg
[PATCH 1/2] drm/mediatek: Drop chain_mode_fixup call in mode_valid()
From: Sam Ravnborg
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the git history I could see this call was included in the original
version of the driver so there was no help there to find out why it was
added in the first place. But a lot has changed since the initial driver
were added and is seems safe to remove the call now.
v4:
- Link to v3:
https://lore.kernel.org/dri-devel/20220717174454.46616-4-...@ravnborg.org/
- Rebase, and added acks/rb
v3:
- Link to v2:
https://lore.kernel.org/dri-devel/20211020181901.2114645-6-...@ravnborg.org/
v2:
- Link to v1:
https://lore.kernel.org/dri-devel/20210722062246.2512666-6-...@ravnborg.org/
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
Acked-by: Chun-Kuang Hu
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: Dafna Hirschfeld
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 6e1cca97a654..0a90fe448d14 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1208,22 +1208,11 @@ mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
- struct drm_bridge *next_bridge;
dev_dbg(hdmi->dev, "xres=%d, yres=%d, refresh=%d, intl=%d clock=%d\n",
mode->hdisplay, mode->vdisplay, drm_mode_vrefresh(mode),
!!(mode->flags & DRM_MODE_FLAG_INTERLACE), mode->clock * 1000);
- next_bridge = drm_bridge_get_next_bridge(>bridge);
- if (next_bridge) {
- struct drm_display_mode adjusted_mode;
-
- drm_mode_init(_mode, mode);
- if (!drm_bridge_chain_mode_fixup(next_bridge, mode,
-_mode))
- return MODE_BAD;
- }
-
if (hdmi->conf) {
if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
return MODE_BAD;
--
2.34.1
[PATCH 2/2] drm/bridge: Drop drm_bridge_chain_mode_fixup
From: Sam Ravnborg
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_bridge.c | 37 -
include/drm/drm_bridge.h | 3 ---
2 files changed, 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 584d109330ab..d44f055dbe3e 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -467,43 +467,6 @@ void drm_bridge_detach(struct drm_bridge *bridge)
* needed, in order to gradually transition to the new model.
*/
-/**
- * drm_bridge_chain_mode_fixup - fixup proposed mode for all bridges in the
- * encoder chain
- * @bridge: bridge control structure
- * @mode: desired mode to be set for the bridge
- * @adjusted_mode: updated mode that works for this bridge
- *
- * Calls _bridge_funcs.mode_fixup for all the bridges in the
- * encoder chain, starting from the first bridge to the last.
- *
- * Note: the bridge passed should be the one closest to the encoder
- *
- * RETURNS:
- * true on success, false on failure
- */
-bool drm_bridge_chain_mode_fixup(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
- struct drm_encoder *encoder;
-
- if (!bridge)
- return true;
-
- encoder = bridge->encoder;
- list_for_each_entry_from(bridge, >bridge_chain, chain_node) {
- if (!bridge->funcs->mode_fixup)
- continue;
-
- if (!bridge->funcs->mode_fixup(bridge, mode, adjusted_mode))
- return false;
- }
-
- return true;
-}
-EXPORT_SYMBOL(drm_bridge_chain_mode_fixup);
-
/**
* drm_bridge_chain_mode_valid - validate the mode against all bridges in the
* encoder chain.
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 4baca0d9107b..5cf41f92d1f0 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -855,9 +855,6 @@ drm_bridge_chain_get_first_bridge(struct drm_encoder
*encoder)
#define drm_for_each_bridge_in_chain(encoder, bridge) \
list_for_each_entry(bridge, &(encoder)->bridge_chain, chain_node)
-bool drm_bridge_chain_mode_fixup(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode);
enum drm_mode_status
drm_bridge_chain_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
--
2.34.1
[PATCH] drm/vmwgfx: Don't destroy Screen Target when CRTC is enabled but inactive
drm_crtc_helper_funcs::atomic_disable can be called even when the CRTC is
still enabled. This can occur when the mode changes or the CRTC is set as
inactive.
In the case where the CRTC is being set as inactive we only want to
blank the screen. The Screen Target should remain intact as long as the
mode has not changed and CRTC is enabled.
This fixes a bug with GDM where locking the screen results in a permanent
black screen because the Screen Target is no longer defined.
Fixes: 7b0062036c3b ("drm/vmwgfx: Implement virtual crc generation")
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 2041c4d48daa..d2f523191314 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -414,6 +414,7 @@ static void vmw_stdu_crtc_atomic_disable(struct drm_crtc
*crtc,
{
struct vmw_private *dev_priv;
struct vmw_screen_target_display_unit *stdu;
+ struct drm_crtc_state *new_crtc_state;
int ret;
if (!crtc) {
@@ -423,6 +424,7 @@ static void vmw_stdu_crtc_atomic_disable(struct drm_crtc
*crtc,
stdu = vmw_crtc_to_stdu(crtc);
dev_priv = vmw_priv(crtc->dev);
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
if (dev_priv->vkms_enabled)
drm_crtc_vblank_off(crtc);
@@ -434,6 +436,14 @@ static void vmw_stdu_crtc_atomic_disable(struct drm_crtc
*crtc,
(void) vmw_stdu_update_st(dev_priv, stdu);
+ /* Don't destroy the Screen Target if we are only setting the
+* display as inactive
+*/
+ if (new_crtc_state->enable &&
+ !new_crtc_state->active &&
+ !new_crtc_state->mode_changed)
+ return;
+
ret = vmw_stdu_destroy_st(dev_priv, stdu);
if (ret)
DRM_ERROR("Failed to destroy Screen Target\n");
--
2.34.1
[PATCH] drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ
Make sure the connector is fully initialized before signalling any
HPD events via drm_kms_helper_hotplug_event(), otherwise this may
lead to NULL pointer dereference.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: ker...@dh-electronics.com
---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index eab3a529e8c4f..029002938a5e8 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2217,7 +2217,7 @@ static irqreturn_t tc_irq_handler(int irq, void *arg)
dev_err(tc->dev, "syserr %x\n", stat);
}
- if (tc->hpd_pin >= 0 && tc->bridge.dev) {
+ if (tc->hpd_pin >= 0 && tc->bridge.dev && tc->aux.drm_dev) {
/*
* H is triggered when the GPIO goes high.
*
--
2.43.0
[PATCH] drm/bridge: tc358767: Fix comment in tc_edp_mode_valid
Fix comment copy-paste error in tc_edp_mode_valid(), this function is validating DP/eDP clock, not DPI clock frequency. Update the comment to match. No functional change. Signed-off-by: Marek Vasut --- Cc: Andrzej Hajda Cc: Daniel Vetter Cc: David Airlie Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Neil Armstrong Cc: Robert Foss Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: ker...@dh-electronics.com --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 818aea4f40b68..eab3a529e8c4f 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1641,7 +1641,7 @@ tc_edp_mode_valid(struct drm_bridge *bridge, u32 req, avail; u32 bits_per_pixel = 24; - /* DPI interface clock limitation: upto 154 MHz */ + /* DPI->(e)DP interface clock limitation: up to 154 MHz */ if (mode->clock > 154000) return MODE_CLOCK_HIGH; -- 2.43.0
[PATCH] dt-bindings: display: bridge: tc358767: Keep enum sorted
Keep the list sorted numerically. No functional change. Signed-off-by: Marek Vasut --- Cc: Andrzej Hajda Cc: Conor Dooley Cc: Daniel Vetter Cc: David Airlie Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Krzysztof Kozlowski Cc: Laurent Pinchart Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Neil Armstrong Cc: Rob Herring Cc: Robert Foss Cc: Thomas Zimmermann Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: ker...@dh-electronics.com --- .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index ae894d996d21f..2ad0cd6dd49e0 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -25,8 +25,8 @@ properties: reg: enum: - - 0x68 - 0x0f + - 0x68 description: | i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins -- 2.43.0
[PATCH] drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock
In case an upstream bridge modified the required clock frequency in its .atomic_check callback by setting adjusted_mode.clock , make sure that clock frequency is generated by the LCDIFv3 block. This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767 with (e)DP output, where the TC358767 expects precise timing on its input side, the precise timing must be generated by the LCDIF. Signed-off-by: Marek Vasut --- Cc: Daniel Vetter Cc: David Airlie Cc: Fabio Estevam Cc: Lucas Stach Cc: Lukas F. Hartmann Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Pengutronix Kernel Team Cc: Sascha Hauer Cc: Shawn Guo Cc: Stefan Agner Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: i...@lists.linux.dev Cc: ker...@dh-electronics.com Cc: linux-arm-ker...@lists.infradead.org --- drivers/gpu/drm/mxsfb/lcdif_kms.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c b/drivers/gpu/drm/mxsfb/lcdif_kms.c index 2541d2de4e45f..dbd42cc1da87f 100644 --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c @@ -407,8 +407,7 @@ static void lcdif_crtc_mode_set_nofb(struct drm_crtc_state *crtc_state, struct drm_display_mode *m = _state->adjusted_mode; DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n", -m->crtc_clock, -(int)(clk_get_rate(lcdif->clk) / 1000)); +m->clock, (int)(clk_get_rate(lcdif->clk) / 1000)); DRM_DEV_DEBUG_DRIVER(drm->dev, "Bridge bus_flags: 0x%08X\n", lcdif_crtc_state->bus_flags); DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags); @@ -538,7 +537,7 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_device *drm = lcdif->drm; dma_addr_t paddr; - clk_set_rate(lcdif->clk, m->crtc_clock * 1000); + clk_set_rate(lcdif->clk, m->clock * 1000); pm_runtime_get_sync(drm->dev); -- 2.43.0
[PATCH v4 7/9] drm/msm/hdmi: get rid of hdmi_mode
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 11 ---
3 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 179da72f8f70..2e2883b9229b 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -25,7 +25,7 @@ void msm_hdmi_set_mode(struct hdmi *hdmi, bool power_on)
spin_lock_irqsave(>reg_lock, flags);
if (power_on) {
ctrl |= HDMI_CTRL_ENABLE;
- if (!hdmi->hdmi_mode) {
+ if (!hdmi->connector->display_info.is_hdmi) {
ctrl |= HDMI_CTRL_HDMI;
hdmi_write(hdmi, REG_HDMI_CTRL, ctrl);
ctrl &= ~HDMI_CTRL_HDMI;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 0ac034eaaf0f..b7fc1c5f1d1e 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -67,8 +67,6 @@ struct hdmi {
/* the encoder we are hooked to (outside of hdmi block) */
struct drm_encoder *encoder;
- bool hdmi_mode; /* are we in hdmi mode? */
-
int irq;
struct workqueue_struct *workq;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 9eecc9960e75..9258d3100042 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -346,17 +346,6 @@ static const struct drm_edid
*msm_hdmi_bridge_edid_read(struct drm_bridge *bridg
hdmi_write(hdmi, REG_HDMI_CTRL, hdmi_ctrl);
- if (drm_edid) {
- /*
-* FIXME: This should use connector->display_info.is_hdmi from a
-* path that has read the EDID and called
-* drm_edid_connector_update().
-*/
- const struct edid *edid = drm_edid_raw(drm_edid);
-
- hdmi->hdmi_mode = drm_detect_hdmi_monitor(edid);
- }
-
return drm_edid;
}
--
2.39.2
[PATCH v4 6/9] drm/msm/hdmi: make use of the drm_connector_hdmi framework
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 44 ++---
drivers/gpu/drm/msm/hdmi/hdmi.h| 16 +---
drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 74 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 170 -
5 files changed, 159 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1931ecf73e32..b5c78c1dd744 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -164,6 +164,8 @@ config DRM_MSM_HDMI
bool "Enable HDMI support in MSM DRM driver"
depends on DRM_MSM
default y
+ select DRM_DISPLAY_HDMI_HELPER
+ select DRM_DISPLAY_HDMI_STATE_HELPER
help
Compile in support for the HDMI output MSM DRM driver. It can
be a primary or a secondary display on device. Note that this is used
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 24abcb7254cc..179da72f8f70 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include "hdmi.h"
@@ -165,8 +166,6 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
hdmi->dev = dev;
hdmi->encoder = encoder;
- hdmi_audio_infoframe_init(>audio.infoframe);
-
ret = msm_hdmi_bridge_init(hdmi);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to create HDMI bridge: %d\n",
ret);
@@ -254,40 +253,12 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
void *data,
struct hdmi_codec_params *params)
{
struct hdmi *hdmi = dev_get_drvdata(dev);
- unsigned int chan;
- unsigned int channel_allocation = 0;
unsigned int rate;
- unsigned int level_shift = 0; /* 0dB */
- bool down_mix = false;
+ int ret;
DRM_DEV_DEBUG(dev, "%u Hz, %d bit, %d channels\n", params->sample_rate,
params->sample_width, params->cea.channels);
- switch (params->cea.channels) {
- case 2:
- /* FR and FL speakers */
- channel_allocation = 0;
- chan = MSM_HDMI_AUDIO_CHANNEL_2;
- break;
- case 4:
- /* FC, LFE, FR and FL speakers */
- channel_allocation = 0x3;
- chan = MSM_HDMI_AUDIO_CHANNEL_4;
- break;
- case 6:
- /* RR, RL, FC, LFE, FR and FL speakers */
- channel_allocation = 0x0B;
- chan = MSM_HDMI_AUDIO_CHANNEL_6;
- break;
- case 8:
- /* FRC, FLC, RR, RL, FC, LFE, FR and FL speakers */
- channel_allocation = 0x1F;
- chan = MSM_HDMI_AUDIO_CHANNEL_8;
- break;
- default:
- return -EINVAL;
- }
-
switch (params->sample_rate) {
case 32000:
rate = HDMI_SAMPLE_RATE_32KHZ;
@@ -316,9 +287,12 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
void *data,
return -EINVAL;
}
- msm_hdmi_audio_set_sample_rate(hdmi, rate);
- msm_hdmi_audio_info_setup(hdmi, 1, chan, channel_allocation,
- level_shift, down_mix);
+ ret =
drm_atomic_helper_connector_hdmi_update_audio_infoframe(hdmi->connector,
+
>cea);
+ if (ret)
+ return ret;
+
+ msm_hdmi_audio_info_setup(hdmi, rate, params->cea.channels);
return 0;
}
@@ -327,7 +301,7 @@ static void msm_hdmi_audio_shutdown(struct device *dev,
void *data)
{
struct hdmi *hdmi = dev_get_drvdata(dev);
- msm_hdmi_audio_info_setup(hdmi, 0, 0, 0, 0, 0);
+ msm_hdmi_audio_disable(hdmi);
}
static const struct hdmi_codec_ops msm_hdmi_audio_codec_ops = {
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 4586baf36415..0ac034eaaf0f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -24,8 +24,8 @@ struct hdmi_platform_config;
struct hdmi_audio {
bool enabled;
- struct hdmi_audio_infoframe infoframe;
int rate;
+ int channels;
};
struct hdmi_hdcp_ctrl;
@@ -199,12 +199,6 @@ static inline int msm_hdmi_pll_8996_init(struct
platform_device *pdev)
/*
* audio:
*/
-/* Supported HDMI Audio channels and rates */
-#defineMSM_HDMI_AUDIO_CHANNEL_20
-#defineMSM_HDMI_AUDIO_CHANNEL_41
-#defineMSM_HDMI_AUDIO_CHANNEL_62
-#defineMSM_HDMI_AUDIO_CHANNEL_83
-
#defineHDMI_SAMPLE_RATE_32KHZ 0
#defineHDMI_SAMPLE_RATE_44_1KHZ1
#define
[PATCH v4 5/9] drm/msm/hdmi: turn mode_set into atomic_enable
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Turn it into the
atomic_enable callback as suggested by the documentation.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index d839c71091dc..f259d6268c0f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -129,12 +129,25 @@ static void msm_hdmi_config_avi_infoframe(struct hdmi
*hdmi)
static void msm_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
struct drm_bridge_state
*old_bridge_state)
{
+ struct drm_atomic_state *state = old_bridge_state->base.state;
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
struct hdmi_phy *phy = hdmi->phy;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
+ const struct drm_display_mode *mode;
DBG("power up");
+ connector = drm_atomic_get_new_connector_for_encoder(state, encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+ mode = _state->adjusted_mode;
+
+ hdmi->pixclock = mode->clock * 1000;
+
if (!hdmi->power_on) {
msm_hdmi_phy_resource_enable(phy);
msm_hdmi_power_on(bridge);
@@ -177,18 +190,24 @@ static void msm_hdmi_bridge_atomic_post_disable(struct
drm_bridge *bridge,
}
}
-static void msm_hdmi_bridge_mode_set(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-const struct drm_display_mode *adjusted_mode)
+static void msm_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
+ struct drm_atomic_state *state = old_bridge_state->base.state;
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
+ struct drm_encoder *encoder = bridge->encoder;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
+ const struct drm_display_mode *mode;
int hstart, hend, vstart, vend;
uint32_t frame_ctrl;
- mode = adjusted_mode;
-
- hdmi->pixclock = mode->clock * 1000;
+ connector = drm_atomic_get_new_connector_for_encoder(state, encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+ mode = _state->adjusted_mode;
hstart = mode->htotal - mode->hsync_start;
hend = mode->htotal - mode->hsync_start + mode->hdisplay;
@@ -305,8 +324,8 @@ static const struct drm_bridge_funcs msm_hdmi_bridge_funcs
= {
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_pre_enable = msm_hdmi_bridge_atomic_pre_enable,
+ .atomic_enable = msm_hdmi_bridge_atomic_enable,
.atomic_post_disable = msm_hdmi_bridge_atomic_post_disable,
- .mode_set = msm_hdmi_bridge_mode_set,
.mode_valid = msm_hdmi_bridge_mode_valid,
.edid_read = msm_hdmi_bridge_edid_read,
.detect = msm_hdmi_bridge_detect,
--
2.39.2
[PATCH v4 0/9] drm/msm: make use of the HDMI connector infrastructure
This patchset sits on top Maxime's HDMI connector patchset ([1]). Currently this is an RFC exploring the interface between HDMI bridges and HDMI connector code. This has been lightly verified on the Qualcomm DB820c, which has native HDMI output. If this approach is considered to be acceptable, I'll finish MSM HDMI bridge conversion (reworking the Audio Infoframe code). Other bridges can follow the same approach (we have lt9611 / lt9611uxc / adv7511 on Qualcomm hardware). [1] https://patchwork.freedesktop.org/series/122421/ Signed-off-by: Dmitry Baryshkov --- Changes in v4: - Reworked drm_bridge_connector functions to remove ternary operators and to reduce indentation level (Maxime) - Added hdmi_ prefix to all HDMI-related drm_bridge_funcs calls (Maxime) - Made vendor and product mandatory to the HDMI bridges (Maxime) - Documented that max_bpc can be 8, 10 or 12 (Maxime) - Changed hdmi->pixclock to be set using tmds_char_rate instead of calculating that manually (Maxime) - Changed mode_valid to use helper function instead of manually doing mode->clock * 1000 - Removed hdmi_mode in favour of connector->display_info.is_hdmi - Link to v3: https://lore.kernel.org/r/20240530-bridge-hdmi-connector-v3-0-a1d184d68...@linaro.org Changes in v3: - Rebased on top of the merged HDMI connector patchset. - Changed drm_bridge_connector to use drmm_connector_init() (Maxime) - Added a check that write_infoframe callback is present if BRIDGE_OP_HDMI is set. - Moved drm_atomic_helper_connector_hdmi_check() call from drm_bridge_connector to the HDMI bridge driver to remove dependency from drm_kms_helpers on the optional HDMI state helpers. - Converted Audio InfoFrame handling code. - Added support for HDMI Vendor Specific and SPD InfoFrames. - Link to v2: https://lore.kernel.org/r/20240309-bridge-hdmi-connector-v2-0-1380bea3e...@linaro.org Changes in v2: - Dropped drm_connector_hdmi_setup(). Instead added drm_connector_hdmi_init() to be used by drm_bridge_connector. - Changed the drm_bridge_connector to act as a proxy for the HDMI connector infrastructure. This removes most of the logic from the bridge drivers. - Link to v1: https://lore.kernel.org/r/20240308-bridge-hdmi-connector-v1-0-90b693550...@linaro.org --- Dmitry Baryshkov (9): drm/connector: hdmi: accept NULL for Audio Infoframe drm/bridge-connector: switch to using drmm allocations drm/bridge-connector: implement glue code for HDMI connector drm/msm/hdmi: switch to atomic bridge callbacks drm/msm/hdmi: turn mode_set into atomic_enable drm/msm/hdmi: make use of the drm_connector_hdmi framework drm/msm/hdmi: get rid of hdmi_mode drm/msm/hdmi: update HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE definition drm/msm/hdmi: also send the SPD and HDMI Vendor Specific InfoFrames drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 +- drivers/gpu/drm/drm_bridge_connector.c | 109 +++-- drivers/gpu/drm/drm_debugfs.c | 2 + drivers/gpu/drm/msm/Kconfig | 2 + drivers/gpu/drm/msm/hdmi/hdmi.c | 46 +--- drivers/gpu/drm/msm/hdmi/hdmi.h | 18 +- drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 74 ++ drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 310 +++- drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +- include/drm/drm_bridge.h| 83 +++ 10 files changed, 472 insertions(+), 188 deletions(-) --- base-commit: 80100af925a09ff99fcd6604a5fd8101dd0d17fd change-id: 20240307-bridge-hdmi-connector-7e3754e661d0 Best regards, -- Dmitry Baryshkov
[PATCH v4 9/9] drm/msm/hdmi: also send the SPD and HDMI Vendor Specific InfoFrames
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format requirements. The msm-4.4 kernel uses GENERIC0 to send
HDR InfoFrame which we do not at this point anyway.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 9258d3100042..ad6258a2017a 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -69,6 +69,8 @@ static void power_off(struct drm_bridge *bridge)
}
#define AVI_IFRAME_LINE_NUMBER 1
+#define SPD_IFRAME_LINE_NUMBER 1
+#define VENSPEC_IFRAME_LINE_NUMBER 3
static int msm_hdmi_config_avi_infoframe(struct hdmi *hdmi,
const u8 *buffer, size_t len)
@@ -142,6 +144,74 @@ static int msm_hdmi_config_audio_infoframe(struct hdmi
*hdmi,
return 0;
}
+static int msm_hdmi_config_spd_infoframe(struct hdmi *hdmi,
+const u8 *buffer, size_t len)
+{
+ u32 buf[7] = {};
+ u32 val;
+ int i;
+
+ if (len != HDMI_INFOFRAME_SIZE(SPD) || len - 3 > sizeof(buf)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "failed to configure SPD infoframe\n");
+ return -EINVAL;
+ }
+
+ /* checksum gets written together with the body of the frame */
+ hdmi_write(hdmi, REG_HDMI_GENERIC1_HDR,
+ buffer[0] |
+ buffer[1] << 8 |
+ buffer[2] << 16);
+
+ memcpy(buf, [3], len - 3);
+
+ for (i = 0; i < ARRAY_SIZE(buf); i++)
+ hdmi_write(hdmi, REG_HDMI_GENERIC1(i), buf[i]);
+
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val |= HDMI_GEN_PKT_CTRL_GENERIC1_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC1_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC1_LINE(SPD_IFRAME_LINE_NUMBER);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ return 0;
+}
+
+static int msm_hdmi_config_hdmi_infoframe(struct hdmi *hdmi,
+ const u8 *buffer, size_t len)
+{
+ u32 buf[7] = {};
+ u32 val;
+ int i;
+
+ if (len < HDMI_INFOFRAME_HEADER_SIZE + HDMI_VENDOR_INFOFRAME_SIZE ||
+ len - 3 > sizeof(buf)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "failed to configure HDMI infoframe\n");
+ return -EINVAL;
+ }
+
+ /* checksum gets written together with the body of the frame */
+ hdmi_write(hdmi, REG_HDMI_GENERIC0_HDR,
+ buffer[0] |
+ buffer[1] << 8 |
+ buffer[2] << 16);
+
+ memcpy(buf, [3], len - 3);
+
+ for (i = 0; i < ARRAY_SIZE(buf); i++)
+ hdmi_write(hdmi, REG_HDMI_GENERIC0(i), buf[i]);
+
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val |= HDMI_GEN_PKT_CTRL_GENERIC0_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC0_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE |
+HDMI_GEN_PKT_CTRL_GENERIC0_LINE(VENSPEC_IFRAME_LINE_NUMBER);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ return 0;
+}
+
static int msm_hdmi_bridge_clear_infoframe(struct drm_bridge *bridge,
enum hdmi_infoframe_type type)
{
@@ -176,6 +246,25 @@ static int msm_hdmi_bridge_clear_infoframe(struct
drm_bridge *bridge,
break;
+ case HDMI_INFOFRAME_TYPE_SPD:
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val &= ~(HDMI_GEN_PKT_CTRL_GENERIC1_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC1_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC1_LINE__MASK);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ break;
+
+ case HDMI_INFOFRAME_TYPE_VENDOR:
+ val = hdmi_read(hdmi, REG_HDMI_GEN_PKT_CTRL);
+ val &= ~(HDMI_GEN_PKT_CTRL_GENERIC0_SEND |
+HDMI_GEN_PKT_CTRL_GENERIC0_CONT |
+HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE |
+HDMI_GEN_PKT_CTRL_GENERIC0_LINE__MASK);
+ hdmi_write(hdmi, REG_HDMI_GEN_PKT_CTRL, val);
+
+ break;
+
default:
drm_dbg_driver(hdmi_bridge->base.dev, "Unsupported infoframe
type %x\n", type);
}
@@ -197,6 +286,10 @@ static int msm_hdmi_bridge_write_infoframe(struct
drm_bridge *bridge,
return msm_hdmi_config_avi_infoframe(hdmi, buffer, len);
case HDMI_INFOFRAME_TYPE_AUDIO:
return msm_hdmi_config_audio_infoframe(hdmi, buffer, len);
+ case
[PATCH v4 8/9] drm/msm/hdmi: update HDMI_GEN_PKT_CTRL_GENERIC0_UPDATE definition
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to simplify its usage in the driver. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/registers/display/hdmi.xml b/drivers/gpu/drm/msm/registers/display/hdmi.xml index 6c81581016c7..fc711a842363 100644 --- a/drivers/gpu/drm/msm/registers/display/hdmi.xml +++ b/drivers/gpu/drm/msm/registers/display/hdmi.xml @@ -131,7 +131,7 @@ xsi:schemaLocation="https://gitlab.freedesktop.org/freedreno/ rules-fd.xsd"> --> - + -- 2.39.2
[PATCH v4 2/9] drm/bridge-connector: switch to using drmm allocations
Turn drm_bridge_connector to using drmm_kzalloc() and
drmm_connector_init() and drop the custom destroy function. The
drm_connector_unregister() and fwnode_handle_put() are already handled
by the drm_connector_cleanup() and so are safe to be dropped.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 982552c9f92c..e093fc8928dc 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -193,19 +194,6 @@ drm_bridge_connector_detect(struct drm_connector
*connector, bool force)
return status;
}
-static void drm_bridge_connector_destroy(struct drm_connector *connector)
-{
- struct drm_bridge_connector *bridge_connector =
- to_drm_bridge_connector(connector);
-
- drm_connector_unregister(connector);
- drm_connector_cleanup(connector);
-
- fwnode_handle_put(connector->fwnode);
-
- kfree(bridge_connector);
-}
-
static void drm_bridge_connector_debugfs_init(struct drm_connector *connector,
struct dentry *root)
{
@@ -224,7 +212,6 @@ static const struct drm_connector_funcs
drm_bridge_connector_funcs = {
.reset = drm_atomic_helper_connector_reset,
.detect = drm_bridge_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_bridge_connector_destroy,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
@@ -328,7 +315,7 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
int connector_type;
int ret;
- bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
+ bridge_connector = drmm_kzalloc(drm, sizeof(*bridge_connector),
GFP_KERNEL);
if (!bridge_connector)
return ERR_PTR(-ENOMEM);
@@ -383,9 +370,9 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
return ERR_PTR(-EINVAL);
}
- ret = drm_connector_init_with_ddc(drm, connector,
- _bridge_connector_funcs,
- connector_type, ddc);
+ ret = drmm_connector_init(drm, connector,
+ _bridge_connector_funcs,
+ connector_type, ddc);
if (ret) {
kfree(bridge_connector);
return ERR_PTR(ret);
--
2.39.2
[PATCH v4 4/9] drm/msm/hdmi: switch to atomic bridge callbacks
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 4a5b5112227f..d839c71091dc 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -126,7 +126,8 @@ static void msm_hdmi_config_avi_infoframe(struct hdmi *hdmi)
hdmi_write(hdmi, REG_HDMI_INFOFRAME_CTRL1, val);
}
-static void msm_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -152,7 +153,8 @@ static void msm_hdmi_bridge_pre_enable(struct drm_bridge
*bridge)
msm_hdmi_hdcp_on(hdmi->hdcp_ctrl);
}
-static void msm_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -299,8 +301,11 @@ static enum drm_mode_status
msm_hdmi_bridge_mode_valid(struct drm_bridge *bridge
}
static const struct drm_bridge_funcs msm_hdmi_bridge_funcs = {
- .pre_enable = msm_hdmi_bridge_pre_enable,
- .post_disable = msm_hdmi_bridge_post_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_pre_enable = msm_hdmi_bridge_atomic_pre_enable,
+ .atomic_post_disable = msm_hdmi_bridge_atomic_post_disable,
.mode_set = msm_hdmi_bridge_mode_set,
.mode_valid = msm_hdmi_bridge_mode_valid,
.edid_read = msm_hdmi_bridge_edid_read,
--
2.39.2
[PATCH v4 3/9] drm/bridge-connector: implement glue code for HDMI connector
In order to let bridge chains implement HDMI connector infrastructure,
add necessary glue code to the drm_bridge_connector. In case there is a
bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs
implementation.
Note, to simplify implementation, there can be only one bridge in a
chain that sets DRM_BRIDGE_OP_HDMI. Setting more than one is considered
an error. This limitation can be lifted later, if the need arises.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 96 --
drivers/gpu/drm/drm_debugfs.c | 2 +
include/drm/drm_bridge.h | 83 +
3 files changed, 178 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index e093fc8928dc..95af857b271d 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/**
* DOC: overview
@@ -87,6 +88,13 @@ struct drm_bridge_connector {
* connector modes detection, if any (see _BRIDGE_OP_MODES).
*/
struct drm_bridge *bridge_modes;
+ /**
+* @bridge_hdmi:
+*
+* The bridge in the chain that implements necessary support for the
+* HDMI connector infrastructure, if any (see _BRIDGE_OP_HDMI).
+*/
+ struct drm_bridge *bridge_hdmi;
};
#define to_drm_bridge_connector(x) \
@@ -287,6 +295,63 @@ static const struct drm_connector_helper_funcs
drm_bridge_connector_helper_funcs
.disable_hpd = drm_bridge_connector_disable_hpd,
};
+static enum drm_mode_status
+drm_bridge_connector_tmds_char_rate_valid(const struct drm_connector
*connector,
+ const struct drm_display_mode *mode,
+ unsigned long long tmds_rate)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return MODE_ERROR;
+
+ if (bridge->funcs->hdmi_tmds_char_rate_valid)
+ return bridge->funcs->hdmi_tmds_char_rate_valid(bridge, mode,
tmds_rate);
+ else
+ return MODE_OK;
+}
+
+static int drm_bridge_connector_clear_infoframe(struct drm_connector
*connector,
+ enum hdmi_infoframe_type type)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return -EINVAL;
+
+ if (bridge->funcs->hdmi_clear_infoframe)
+ return bridge->funcs->hdmi_clear_infoframe(bridge, type);
+ else
+ return 0;
+}
+
+static int drm_bridge_connector_write_infoframe(struct drm_connector
*connector,
+ enum hdmi_infoframe_type type,
+ const u8 *buffer, size_t len)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return -EINVAL;
+
+ return bridge->funcs->hdmi_write_infoframe(bridge, type, buffer, len);
+}
+
+static const struct drm_connector_hdmi_funcs drm_bridge_connector_hdmi_funcs =
{
+ .tmds_char_rate_valid = drm_bridge_connector_tmds_char_rate_valid,
+ .clear_infoframe = drm_bridge_connector_clear_infoframe,
+ .write_infoframe = drm_bridge_connector_write_infoframe,
+};
+
/*
-
* Bridge Connector Initialisation
*/
@@ -312,6 +377,8 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+ unsigned int supported_formats = BIT(HDMI_COLORSPACE_RGB);
+ unsigned int max_bpc = 8;
int connector_type;
int ret;
@@ -348,6 +415,19 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
bridge_connector->bridge_detect = bridge;
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
+ if (bridge->ops & DRM_BRIDGE_OP_HDMI) {
+ if (bridge_connector->bridge_hdmi)
+ return ERR_PTR(-EBUSY);
+ if (!bridge->funcs->hdmi_write_infoframe)
+ return ERR_PTR(-EINVAL);
+
+
[PATCH v4 1/9] drm/connector: hdmi: accept NULL for Audio Infoframe
Allow passing NULL as audio infoframe as a way to disable Audio
Infoframe generation.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index ce96837eea65..5356723d21f5 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -681,7 +681,7 @@
EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_update_infoframes);
/**
* drm_atomic_helper_connector_hdmi_update_audio_infoframe - Update the Audio
Infoframe
* @connector: A pointer to the HDMI connector
- * @frame: A pointer to the audio infoframe to write
+ * @frame: A pointer to the audio infoframe to write or NULL to disable
sending the frame
*
* This function is meant for HDMI connector drivers to update their
* audio infoframe. It will typically be used in one of the ALSA hooks
@@ -704,10 +704,16 @@
drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *co
mutex_lock(>hdmi.infoframes.lock);
- memcpy(>data, frame, sizeof(infoframe->data));
- infoframe->set = true;
+ if (frame) {
+ memcpy(>data, frame, sizeof(infoframe->data));
+ infoframe->set = true;
+
+ ret = write_infoframe(connector, infoframe);
+ } else {
+ infoframe->set = false;
- ret = write_infoframe(connector, infoframe);
+ ret = clear_infoframe(connector, infoframe);
+ }
mutex_unlock(>hdmi.infoframes.lock);
--
2.39.2
Re: [PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Aya Neo KUN
On Sun, Mar 10, 2024 at 11:04:00PM +0100, tjak...@math.uni-bielefeld.de wrote: > From: Tobias Jakobi > > Similar to the other Aya Neo devices this one features > again a portrait screen, here with a native resolution > of 1600x2560. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v4 05/13] drm/msm/dpu: move scaling limitations out of the hw_catalog
On Fri, May 31, 2024 at 12:20:24PM -0700, Abhinav Kumar wrote:
>
>
> On 5/31/2024 1:16 AM, Dmitry Baryshkov wrote:
> > On Fri, 31 May 2024 at 04:02, Abhinav Kumar
> > wrote:
> > >
> > >
> > >
> > > On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> > > > Max upscale / downscale factors are constant between platforms. In
> > > > preparation to adding support for virtual planes and allocating SSPP
> > > > blocks on demand move max scaling factors out of the HW catalog and
> > > > handle them in the dpu_plane directly. If any of the scaling blocks gets
> > > > different limitations, this will have to be handled separately, after
> > > > the plane refactoring.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov
> > > > ---
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4
> > > >drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16 +---
> > > >3 files changed, 13 insertions(+), 19 deletions(-)
> > > >
> > >
> > >
> > >
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > index 70d6a8989e1a..6360052523b5 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > @@ -785,12 +785,15 @@ static int dpu_plane_atomic_check_pipe(struct
> > > > dpu_plane *pdpu,
> > > >return 0;
> > > >}
> > > >
> > > > +#define MAX_UPSCALE_RATIO20
> > > > +#define MAX_DOWNSCALE_RATIO 4
> > > > +
> > > >static int dpu_plane_atomic_check(struct drm_plane *plane,
> > > > struct drm_atomic_state *state)
> > > >{
> > > >struct drm_plane_state *new_plane_state =
> > > > drm_atomic_get_new_plane_state(state,
> > > >
> > > > plane);
> > > > - int ret = 0, min_scale;
> > > > + int ret = 0, min_scale, max_scale;
> > > >struct dpu_plane *pdpu = to_dpu_plane(plane);
> > > >struct dpu_kms *kms = _dpu_plane_get_kms(>base);
> > > >u64 max_mdp_clk_rate = kms->perf.max_core_clk_rate;
> > > > @@ -822,10 +825,17 @@ static int dpu_plane_atomic_check(struct
> > > > drm_plane *plane,
> > > >pipe_hw_caps = pipe->sspp->cap;
> > > >sblk = pipe->sspp->cap->sblk;
> > > >
> > > > - min_scale = FRAC_16_16(1, sblk->maxupscale);
> > > > + if (sblk->scaler_blk.len) {
> > > > + min_scale = FRAC_16_16(1, MAX_UPSCALE_RATIO);
> > > > + max_scale = MAX_DOWNSCALE_RATIO << 16;
> > > > + } else {
> > > > + min_scale = 1 << 16;
> > > > + max_scale = 1 << 16;
> > >
> > > You can use DRM_PLANE_NO_SCALING instead.
> >
> > Ack
> >
> > >
> > > > + }
> > > > +
> > > >ret = drm_atomic_helper_check_plane_state(new_plane_state,
> > > > crtc_state,
> > > > min_scale,
> > > > - sblk->maxdwnscale << 16,
> > > > + max_scale,
> > > > true, true);
> > >
> > > I am missing something here.
> > >
> > > As per the documentation of this API, min and max are the scaling limits
> > > of both directions and not max_upscale and max_downscale.
> > >
> > > **
> > > 837 * drm_atomic_helper_check_plane_state() - Check plane state for
> > > validity
> > > 838 * @plane_state: plane state to check
> > > 839 * @crtc_state: CRTC state to check
> > > 840 * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> > > 841 * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> > > 842 * @can_position: is it legal to position the plane such that it
> > >
> > >
> > > But this change is passing max_upscale and max_downscale as the min and
> > > max resp. Isnt that wrong?
> >
> > First of all, please notice that I'm not changing the values that are
> > passed to the function. What was being passed beforehand gets passed
> > after this commit. I just moved it out of the catalog.
> >
>
> Ack.
>
> > Second, if we take a look at drm_calc_scale(), we can see that it
> > calculates src / dst and checks that it is within the min_scale and
> > max_scale boundaries, just like documented.
> > In our case, the boundaries are (I'm omitting 16.16 math):
> > - upscale 20 times. dst = 20 * src, scale = src/dst = 1/20
> > - downscale 4 times. dst = 1/4 * src, scale = src/dst = 4
> >
> > So, from the point of view of drm_calc_scale(), the min_scale is
> > 1/MAX_UPSCALE, max_scale = MAX_DOWNSCALE and the values the code is
> > passing are correct.
> >
>
> That part is fine. Agreed.
>
> But I do think, that API is not correct if the scaling limits are different
> in the Horizontal Vs Vertical direction as today it assumes the limits are
> same in both.
Agree. But if we ever
Re: [PATCH v4 05/13] drm/msm/dpu: move scaling limitations out of the hw_catalog
On 5/31/2024 1:16 AM, Dmitry Baryshkov wrote:
On Fri, 31 May 2024 at 04:02, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Max upscale / downscale factors are constant between platforms. In
preparation to adding support for virtual planes and allocating SSPP
blocks on demand move max scaling factors out of the HW catalog and
handle them in the dpu_plane directly. If any of the scaling blocks gets
different limitations, this will have to be handled separately, after
the plane refactoring.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16 +---
3 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 70d6a8989e1a..6360052523b5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -785,12 +785,15 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane
*pdpu,
return 0;
}
+#define MAX_UPSCALE_RATIO20
+#define MAX_DOWNSCALE_RATIO 4
+
static int dpu_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
- int ret = 0, min_scale;
+ int ret = 0, min_scale, max_scale;
struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_kms *kms = _dpu_plane_get_kms(>base);
u64 max_mdp_clk_rate = kms->perf.max_core_clk_rate;
@@ -822,10 +825,17 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
pipe_hw_caps = pipe->sspp->cap;
sblk = pipe->sspp->cap->sblk;
- min_scale = FRAC_16_16(1, sblk->maxupscale);
+ if (sblk->scaler_blk.len) {
+ min_scale = FRAC_16_16(1, MAX_UPSCALE_RATIO);
+ max_scale = MAX_DOWNSCALE_RATIO << 16;
+ } else {
+ min_scale = 1 << 16;
+ max_scale = 1 << 16;
You can use DRM_PLANE_NO_SCALING instead.
Ack
+ }
+
ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
min_scale,
- sblk->maxdwnscale << 16,
+ max_scale,
true, true);
I am missing something here.
As per the documentation of this API, min and max are the scaling limits
of both directions and not max_upscale and max_downscale.
**
837 * drm_atomic_helper_check_plane_state() - Check plane state for
validity
838 * @plane_state: plane state to check
839 * @crtc_state: CRTC state to check
840 * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
841 * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
842 * @can_position: is it legal to position the plane such that it
But this change is passing max_upscale and max_downscale as the min and
max resp. Isnt that wrong?
First of all, please notice that I'm not changing the values that are
passed to the function. What was being passed beforehand gets passed
after this commit. I just moved it out of the catalog.
Ack.
Second, if we take a look at drm_calc_scale(), we can see that it
calculates src / dst and checks that it is within the min_scale and
max_scale boundaries, just like documented.
In our case, the boundaries are (I'm omitting 16.16 math):
- upscale 20 times. dst = 20 * src, scale = src/dst = 1/20
- downscale 4 times. dst = 1/4 * src, scale = src/dst = 4
So, from the point of view of drm_calc_scale(), the min_scale is
1/MAX_UPSCALE, max_scale = MAX_DOWNSCALE and the values the code is
passing are correct.
That part is fine. Agreed.
But I do think, that API is not correct if the scaling limits are
different in the Horizontal Vs Vertical direction as today it assumes
the limits are same in both. Anyway, thats outside the scope of this
patch. So I am good for now.
if (ret) {
DPU_DEBUG_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
[linux-next:master] BUILD REGRESSION 0e1980c40b6edfa68b6acf926bab22448a6e40c9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 0e1980c40b6edfa68b6acf926bab22448a6e40c9 Add linux-next specific files for 20240531 Unverified Error/Warning (likely false positive, please contact us if interested): drivers/gpu/drm/xe/xe_drm_client.c:272 show_run_ticks() error: uninitialized symbol 'hwe'. drivers/gpu/drm/xe/xe_drm_client.c:292 show_run_ticks() error: uninitialized symbol 'gpu_timestamp'. drivers/gpu/drm/xe/xe_sched_job.c:283 xe_sched_job_arm() error: uninitialized symbol 'fence'. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | |-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- arc-allmodconfig | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- arc-allyesconfig | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- arc-randconfig-002-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- csky-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | |-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- csky-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | |-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- csky-randconfig-002-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-allmodconfig | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-allyesconfig | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-buildonly-randconfig-002-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-buildonly-randconfig-003-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-buildonly-randconfig-005-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-randconfig-001-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-randconfig-004-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-randconfig-015-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- i386-randconfig-141-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- loongarch-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | |-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- loongarch-defconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-hubbub-dcn401-dcn401_hubbub.o:warning:objtool:unexpected-relocation-symbol-type-in-.rela.discard.reachable | `-- drivers-thermal-thermal_trip.o:warning:objtool:unexpected-relocation-symbol-type-in-.rela.discard.reachable |-- loongarch-randconfig-002-20240531 | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- m68k-allmodconfig | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- m68k-allyesconfig | `-- drivers-regulator-rtq2208-regulator.c:warning:rtq2208_regulator_ldo_ops-defined-but-not-used |-- microblaze-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | |-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size | `--
Re: [PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Aya Neo KUN
On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:
From: Tobias Jakobi
Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d92f66e550c..5d3fb11fd45f 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -196,6 +196,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_MATCH(DMI_BOARD_NAME, "NEXT"),
},
.driver_data = (void *)_rightside_up,
+ }, {/* AYA NEO KUN */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AYANEO"),
+ DMI_MATCH(DMI_BOARD_NAME, "KUN"),
+ },
+ .driver_data = (void *)_rightside_up,
}, {/* Chuwi HiBook (CWI514) */
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
Trying yet another ping! Also adding Hans to the list of recipients, as
he committed the last quirk for an Ayaneo device. Someone pick this up,
pretty please! :-)
- Tobias
Re: [PATCH v15 00/29] drm/connector: Create HDMI Connector infrastructure
On Mon, 27 May 2024, Maxime Ripard wrote: > Let me know what you think, Sorry to report that this series generates a bunch of kernel-doc warnings in include/drm/drm_connector.h. Documenting nested struct members doesn't work as smoothly as you'd expect: ../include/drm/drm_connector.h:1138: warning: Excess struct member 'broadcast_rgb' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'infoframes' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'avi' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'hdr_drm' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'spd' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'vendor' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'is_limited_range' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'output_bpc' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'output_format' description in 'drm_connector_state' ../include/drm/drm_connector.h:1138: warning: Excess struct member 'tmds_char_rate' description in 'drm_connector_state' ../include/drm/drm_connector.h:2112: warning: Excess struct member 'vendor' description in 'drm_connector' ../include/drm/drm_connector.h:2112: warning: Excess struct member 'product' description in 'drm_connector' ../include/drm/drm_connector.h:2112: warning: Excess struct member 'supported_formats' description in 'drm_connector' ../include/drm/drm_connector.h:2112: warning: Excess struct member 'infoframes' description in 'drm_connector' ../include/drm/drm_connector.h:2112: warning: Excess struct member 'lock' description in 'drm_connector' ../include/drm/drm_connector.h:2112: warning: Excess struct member 'audio' description in 'drm_connector' Noticed this when I was rebasing [1]. Having that merged would find issues in headers at build time instead of 'make htmldocs'. In the mean time, this is the quick reproducer: $ scripts/kernel-doc -none include/drm/drm_connector.h BR, Jani. [1] https://lore.kernel.org/r/20240402140136.1722533-1-jani.nik...@intel.com -- Jani Nikula, Intel
Re: [PATCH v11 07/11] Documentation: core-api: Add math.h macros and functions
Hi, On 5/31/24 10:12 AM, Devarsh Thakkar wrote: > Add documentation for rounding, scaling, absolute value and difference, > 32-bit division related macros and functions exported by math.h header > file. > I don't see any kernel-doc for division functions in this header file. Do some division functions get rendered somehow? Thanks. > Signed-off-by: Devarsh Thakkar > --- > V11: Fix title for math function header > V10: Patch introduced > V1->V9 (No change) > --- > Documentation/core-api/kernel-api.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/core-api/kernel-api.rst > b/Documentation/core-api/kernel-api.rst > index ae92a2571388..7de494e76fa6 100644 > --- a/Documentation/core-api/kernel-api.rst > +++ b/Documentation/core-api/kernel-api.rst > @@ -185,6 +185,12 @@ Division Functions > .. kernel-doc:: lib/math/gcd.c > :export: > > +Rounding, absolute value, division and 32-bit scaling functions > +--- > + > +.. kernel-doc:: include/linux/math.h > + :internal: > + > UUID/GUID > - > -- #Randy https://people.kernel.org/tglx/notes-about-netiquette https://subspace.kernel.org/etiquette.html
Re: [PATCH][next] drm/amd/display: Fix a handful of spelling mistakes
Applied. Thanks!
Alex
On Fri, May 31, 2024 at 11:37 AM Randy Dunlap wrote:
>
>
>
> On 5/31/24 2:32 AM, Colin Ian King wrote:
> > There are a few spelling mistakes in dml2_printf messages. Fix them.
> >
> > Signed-off-by: Colin Ian King
>
>
> Reviewed-by: Randy Dunlap
>
> Thanks.
>
> > ---
> > .../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 6 +++---
> > .../display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c | 6 +++---
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> >
> > b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> > index 8062144a5a6d..e7e6751f4477 100644
> > ---
> > a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> > +++
> > b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> > @@ -5731,7 +5731,7 @@ static bool CalculatePrefetchSchedule(struct
> > dml2_core_internal_scratch *scratch
> > dml2_printf("DML: Tvm: %fus - time to fetch vm\n",
> > s->TimeForFetchingVM);
> > dml2_printf("DML: Tr0: %fus - time to fetch first row of data
> > pagetables\n", s->TimeForFetchingRowInVBlank);
> > dml2_printf("DML: Tsw: %fus = time to fetch enough pixel data
> > and cursor data to feed the scalers init position and detile\n",
> > (double)s->LinesToRequestPrefetchPixelData * s->LineTime);
> > - dml2_printf("DML: To: %fus - time for propogation from scaler
> > to optc\n", (*p->DSTYAfterScaler + ((double)(*p->DSTXAfterScaler) /
> > (double)p->myPipe->HTotal)) * s->LineTime);
> > + dml2_printf("DML: To: %fus - time for propagation from scaler
> > to optc\n", (*p->DSTYAfterScaler + ((double)(*p->DSTXAfterScaler) /
> > (double)p->myPipe->HTotal)) * s->LineTime);
> > dml2_printf("DML: Tvstartup - TSetup - Tcalc - TWait - Tpre -
> > To > 0\n");
> > dml2_printf("DML: Tslack(pre): %fus - time left over in
> > schedule\n", p->VStartup * s->LineTime - s->TimeForFetchingVM - 2 *
> > s->TimeForFetchingRowInVBlank - (*p->DSTYAfterScaler +
> > ((double)(*p->DSTXAfterScaler) / (double)p->myPipe->HTotal)) * s->LineTime
> > - p->TWait - p->TCalc - *p->TSetup);
> > dml2_printf("DML: row_bytes = dpte_row_bytes (per_pipe) =
> > PixelPTEBytesPerRow = : %u\n", p->PixelPTEBytesPerRow);
> > @@ -8268,7 +8268,7 @@ static bool dml_core_mode_support(struct
> > dml2_core_calcs_mode_support_ex *in_out
> > dml2_printf("DML::%s: mode_lib->ms.DCFCLK = %f\n", __func__,
> > mode_lib->ms.DCFCLK);
> > dml2_printf("DML::%s: mode_lib->ms.FabricClock = %f\n", __func__,
> > mode_lib->ms.FabricClock);
> > dml2_printf("DML::%s: mode_lib->ms.uclk_freq_mhz = %f\n", __func__,
> > mode_lib->ms.uclk_freq_mhz);
> > - dml2_printf("DML::%s: urgent latency tolarance = %f\n", __func__,
> > ((mode_lib->ip.rob_buffer_size_kbytes -
> > mode_lib->ip.pixel_chunk_size_kbytes) * 1024 / (mode_lib->ms.DCFCLK *
> > mode_lib->soc.return_bus_width_bytes)));
> > + dml2_printf("DML::%s: urgent latency tolerance = %f\n", __func__,
> > ((mode_lib->ip.rob_buffer_size_kbytes -
> > mode_lib->ip.pixel_chunk_size_kbytes) * 1024 / (mode_lib->ms.DCFCLK *
> > mode_lib->soc.return_bus_width_bytes)));
> > #endif
> >
> > mode_lib->ms.support.OutstandingRequestsSupport = true;
> > @@ -11089,7 +11089,7 @@ static bool dml_core_mode_programming(struct
> > dml2_core_calcs_mode_programming_ex
> > if
> > (display_cfg->plane_descriptors[k].immediate_flip &&
> > mode_lib->mp.ImmediateFlipSupportedForPipe[k] == false) {
> > mode_lib->mp.ImmediateFlipSupported =
> > false;
> > #ifdef __DML_VBA_DEBUG__
> > - dml2_printf("DML::%s: Pipe %0d not
> > supporing iflip!\n", __func__, k);
> > + dml2_printf("DML::%s: Pipe %0d not
> > supporting iflip!\n", __func__, k);
> > #endif
> > }
> > }
> > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> >
> > b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> > index f2e2250d28d3..6eb3fec87ec1 100644
> > ---
> > a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> > +++
> > b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> > @@ -1988,7 +1988,7 @@ bool dml2_core_shared_mode_support(struct
> > dml2_core_calcs_mode_support_ex *in_ou
> > dml2_printf("DML::%s: mode_lib->ms.FabricClock = %f\n", __func__,
> > mode_lib->ms.FabricClock);
> > dml2_printf("DML::%s: mode_lib->ms.uclk_freq_mhz = %f\n", __func__,
> > mode_lib->ms.uclk_freq_mhz);
> > dml2_printf("DML::%s: max_urgent_latency_us = %f\n", __func__,
> >
Re: [PATCH v2 2/2] drm: panel: nv3052c: Add WL-355608-A8 panel
On 5/30/2024 1:22 AM, Ryan Walklin wrote:
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
OEM used in a number of handheld gaming devices made by Anbernic.
Limited information is available online however the panel timing values
(below) have been obtained from the vendor BSP. The panel appears to
integrate a NV3052C LCD driver (or clone). Available devices address it
in SPI/RGB mode, with the timing signals generated from the device
SoC (Allwinner H700) and passed through.
Add a panel definition and display mode to the existing NV3502C driver.
It was assumed during bringup that the initialisation sequence was the
same as the existing Fascontek FS035VG158 panel, proved working during
experimentation, however subsequent dumping of the init sequence with a
logic analyser confirms one small change to VCOM_ADJ3 from 0x4a to 0x44,
therefore a separate set of registers is also added.
Timings:
| Active | FP | Sync | BP | Total
---||--|--|--|---
Horizontal | 640 | 64 | 20 | 46 | 770
Vertical | 480 | 21 | 4 | 15 | 520
Signed-off-by: Ryan Walklin
Co-developed-by: Hironori KIKUCHI
Signed-off-by: Hironori KIKUCHI
Reviewed-by: John Watts
Hi Ryan,
Acked-by: Jessica Zhang
Thanks,
Jessica Zhang
---
Changelog v1..v2:
- Update .compatible string to match dt-binding
- Add co-developer sign-off and review tags
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 225 ++
1 file changed, 225 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
index 1aab0c9ae52fa..ee0ce271205e3 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -433,6 +433,202 @@ static const struct nv3052c_reg fs035vg158_panel_regs[] =
{
{ 0x36, 0x0a }, // bgr = 1, ss = 1, gs = 0
};
+
+static const struct nv3052c_reg wl_355608_a8_panel_regs[] = {
+ // EXTC Command set enable, select page 1
+ { 0xff, 0x30 }, { 0xff, 0x52 }, { 0xff, 0x01 },
+ // Mostly unknown registers
+ { 0xe3, 0x00 },
+ { 0x40, 0x00 },
+ { 0x03, 0x40 },
+ { 0x04, 0x00 },
+ { 0x05, 0x03 },
+ { 0x08, 0x00 },
+ { 0x09, 0x07 },
+ { 0x0a, 0x01 },
+ { 0x0b, 0x32 },
+ { 0x0c, 0x32 },
+ { 0x0d, 0x0b },
+ { 0x0e, 0x00 },
+ { 0x23, 0xa0 },
+ { 0x24, 0x0c },
+ { 0x25, 0x06 },
+ { 0x26, 0x14 },
+ { 0x27, 0x14 },
+ { 0x38, 0xcc }, // VCOM_ADJ1
+ { 0x39, 0xd7 }, // VCOM_ADJ2
+ { 0x3a, 0x44 }, // VCOM_ADJ3
+ { 0x28, 0x40 },
+ { 0x29, 0x01 },
+ { 0x2a, 0xdf },
+ { 0x49, 0x3c },
+ { 0x91, 0x77 }, // EXTPW_CTRL2
+ { 0x92, 0x77 }, // EXTPW_CTRL3
+ { 0xa0, 0x55 },
+ { 0xa1, 0x50 },
+ { 0xa4, 0x9c },
+ { 0xa7, 0x02 },
+ { 0xa8, 0x01 },
+ { 0xa9, 0x01 },
+ { 0xaa, 0xfc },
+ { 0xab, 0x28 },
+ { 0xac, 0x06 },
+ { 0xad, 0x06 },
+ { 0xae, 0x06 },
+ { 0xaf, 0x03 },
+ { 0xb0, 0x08 },
+ { 0xb1, 0x26 },
+ { 0xb2, 0x28 },
+ { 0xb3, 0x28 },
+ { 0xb4, 0x33 },
+ { 0xb5, 0x08 },
+ { 0xb6, 0x26 },
+ { 0xb7, 0x08 },
+ { 0xb8, 0x26 },
+ { 0xf0, 0x00 },
+ { 0xf6, 0xc0 },
+ // EXTC Command set enable, select page 2
+ { 0xff, 0x30 }, { 0xff, 0x52 }, { 0xff, 0x02 },
+ // Set gray scale voltage to adjust gamma
+ { 0xb0, 0x0b }, // PGAMVR0
+ { 0xb1, 0x16 }, // PGAMVR1
+ { 0xb2, 0x17 }, // PGAMVR2
+ { 0xb3, 0x2c }, // PGAMVR3
+ { 0xb4, 0x32 }, // PGAMVR4
+ { 0xb5, 0x3b }, // PGAMVR5
+ { 0xb6, 0x29 }, // PGAMPR0
+ { 0xb7, 0x40 }, // PGAMPR1
+ { 0xb8, 0x0d }, // PGAMPK0
+ { 0xb9, 0x05 }, // PGAMPK1
+ { 0xba, 0x12 }, // PGAMPK2
+ { 0xbb, 0x10 }, // PGAMPK3
+ { 0xbc, 0x12 }, // PGAMPK4
+ { 0xbd, 0x15 }, // PGAMPK5
+ { 0xbe, 0x19 }, // PGAMPK6
+ { 0xbf, 0x0e }, // PGAMPK7
+ { 0xc0, 0x16 }, // PGAMPK8
+ { 0xc1, 0x0a }, // PGAMPK9
+ // Set gray scale voltage to adjust gamma
+ { 0xd0, 0x0c }, // NGAMVR0
+ { 0xd1, 0x17 }, // NGAMVR0
+ { 0xd2, 0x14 }, // NGAMVR1
+ { 0xd3, 0x2e }, // NGAMVR2
+ { 0xd4, 0x32 }, // NGAMVR3
+ { 0xd5, 0x3c }, // NGAMVR4
+ { 0xd6, 0x22 }, // NGAMPR0
+ { 0xd7, 0x3d }, // NGAMPR1
+ { 0xd8, 0x0d }, // NGAMPK0
+ { 0xd9, 0x07 }, // NGAMPK1
+ { 0xda, 0x13 }, // NGAMPK2
+ { 0xdb, 0x13 }, // NGAMPK3
+ { 0xdc, 0x11 }, // NGAMPK4
+ { 0xdd, 0x15 }, // NGAMPK5
+ { 0xde, 0x19 }, // NGAMPK6
+ { 0xdf, 0x10 }, // NGAMPK7
+ { 0xe0, 0x17 }, // NGAMPK8
+ { 0xe1, 0x0a }, // NGAMPK9
+ // EXTC Command set enable, select page 3
+ { 0xff, 0x30 }, { 0xff, 0x52 }, { 0xff, 0x03 },
+ // Set various
Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
On 5/31/2024 11:43 AM, Dmitry Baryshkov wrote: On Fri, May 31, 2024 at 10:18:07AM -0600, Jeffrey Hugo wrote: On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: There are two ways to describe an eDP panel in device tree. The recommended way is to add a device on the AUX bus, ideally using the edp-panel compatible. The legacy way is to define a top-level platform device for the panel. Document that adding support for eDP panels in a legacy way is strongly discouraged (if not forbidden at all). While we are at it, also drop legacy compatible strings and bindings for five panels. These compatible strings were never used by a DT file present in Linux kernel and most likely were never used with the upstream Linux kernel. The following compatibles were never used by the devices supported by the upstream kernel and are a subject to possible removal: - lg,lp097qx1-spa1 - samsung,lsn122dl01-c01 - sharp,ld-d5116z01b Ok to drop the sharp one I added. It should be able to be handled by the (newish) edp-panel, but I think the TI bridge driver needs some work for the specific platform (no I2C connection) to verify. Thanks. I'm tempted to merge the series as is now and drop sharp,ld-d5116z01b once you can confirm that it can be handled by edp-panel on your platform. Sounds good to me. -Jeff
Re: [PATCH v11 09/11] lib: math_kunit: Add tests for new macros related to rounding to nearest value
On Fri, May 31, 2024 at 10:46:28PM +0530, Devarsh Thakkar wrote: > Add tests for round_closest_up/down and roundclosest macros which round > to nearest multiple of specified argument. These are tested with kunit > tool as shared here [1]. > > [1]: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876 Make it a tag... > ...here Link: ... [1] > Signed-off-by: Devarsh Thakkar With the same caveat as per patch 1, Acked-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
On Fri, May 31, 2024 at 10:18:07AM -0600, Jeffrey Hugo wrote: > On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: > > There are two ways to describe an eDP panel in device tree. The > > recommended way is to add a device on the AUX bus, ideally using the > > edp-panel compatible. The legacy way is to define a top-level platform > > device for the panel. > > > > Document that adding support for eDP panels in a legacy way is strongly > > discouraged (if not forbidden at all). > > > > While we are at it, also drop legacy compatible strings and bindings for > > five panels. These compatible strings were never used by a DT file > > present in Linux kernel and most likely were never used with the > > upstream Linux kernel. > > > > The following compatibles were never used by the devices supported by > > the upstream kernel and are a subject to possible removal: > > > > - lg,lp097qx1-spa1 > > - samsung,lsn122dl01-c01 > > - sharp,ld-d5116z01b > > Ok to drop the sharp one I added. It should be able to be handled by the > (newish) edp-panel, but I think the TI bridge driver needs some work for the > specific platform (no I2C connection) to verify. Thanks. I'm tempted to merge the series as is now and drop sharp,ld-d5116z01b once you can confirm that it can be handled by edp-panel on your platform. -- With best wishes Dmitry
Re: [PATCH v11 06/11] math.h: Add macros for rounding to closest value
On Fri, May 31, 2024 at 10:41:36PM +0530, Devarsh Thakkar wrote: > Add below rounding related macros: > > round_closest_up(x, y) : Rounds x to closest multiple of y where y is a > power of 2, with a preference to round up in case two nearest values are > possible. > > round_closest_down(x, y) : Rounds x to closest multiple of y where y is a > power of 2, with a preference to round down in case two nearest values are > possible. > > roundclosest(x, y) : Rounds x to closest multiple of y, this macro should > generally be used only when y is not multiple of 2 as otherwise > round_closest* macros should be used which are much faster. > > Examples: > * round_closest_up(17, 4) = 16 > * round_closest_up(15, 4) = 16 > * round_closest_up(14, 4) = 16 > * round_closest_down(17, 4) = 16 > * round_closest_down(15, 4) = 16 > * round_closest_down(14, 4) = 12 > * roundclosest(21, 5) = 20 > * roundclosest(19, 5) = 20 > * roundclosest(17, 5) = 15 I don't know the estimation on how these will really useful or not, but I'm not objecting if people think it's needed API. Acked-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v11 07/11] Documentation: core-api: Add math.h macros and functions
On Fri, May 31, 2024 at 10:42:20PM +0530, Devarsh Thakkar wrote: > Add documentation for rounding, scaling, absolute value and difference, > 32-bit division related macros and functions exported by math.h header > file. As long as it renders correctly, fine to me Reviewed-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v11 08/11] lib: add basic KUnit test for lib/math
On Fri, May 31, 2024 at 10:43:05PM +0530, Devarsh Thakkar wrote: > From: Daniel Latypov > > Add basic test coverage for files that don't require any config options: > * part of math.h (what seem to be the most commonly used macros) > * gcd.c > * lcm.c > * int_sqrt.c > * reciprocal_div.c > (Ignored int_pow.c since it's a simple textbook algorithm.) > > These tests aren't particularly interesting, but they > * provide short and simple examples of parameterized tests > * provide a place to add tests for any new files in this dir > * are written so adding new test cases to cover edge cases should be > easy > * looking at code coverage, we hit all the branches in the .c files Reviewed-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 0/4] lm3533: Remove the outdated drivers
On Fri, May 31, 2024 at 06:15:46PM +0100, Lee Jones wrote: > On Fri, 31 May 2024, Andy Shevchenko wrote: > > On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote: > > > Driver is quite outdated from the Linux kernel internal APIs > > > perspective. In particular GPIO code is using legacy calls, > > > that started being replaced by a new API ca. 2014, i.e. ten > > > years ago. > > > > > > Suggested-by: Linus Walleij > > > > > drivers/mfd/lm3533-core.c | 645 --- > > > > Oops, still leftovers: one file and Kconfig/Makefile updates... > > If needed I'll send a v2, but now I leave it to Lee and Johan to decide > > the destiny of the drivers. > > Let's not rush into it. Take your time. Exactly, excellente fin de semaine! -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
Hi, On Fri, May 31, 2024 at 9:51 AM Jeffrey Hugo wrote: > > On 5/31/2024 10:20 AM, Doug Anderson wrote: > > Hi, > > > > On Fri, May 31, 2024 at 9:18 AM Jeffrey Hugo wrote: > >> > >> On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: > >>> There are two ways to describe an eDP panel in device tree. The > >>> recommended way is to add a device on the AUX bus, ideally using the > >>> edp-panel compatible. The legacy way is to define a top-level platform > >>> device for the panel. > >>> > >>> Document that adding support for eDP panels in a legacy way is strongly > >>> discouraged (if not forbidden at all). > >>> > >>> While we are at it, also drop legacy compatible strings and bindings for > >>> five panels. These compatible strings were never used by a DT file > >>> present in Linux kernel and most likely were never used with the > >>> upstream Linux kernel. > >>> > >>> The following compatibles were never used by the devices supported by > >>> the upstream kernel and are a subject to possible removal: > >>> > >>> - lg,lp097qx1-spa1 > >>> - samsung,lsn122dl01-c01 > >>> - sharp,ld-d5116z01b > >> > >> Ok to drop the sharp one I added. It should be able to be handled by > >> the (newish) edp-panel, but I think the TI bridge driver needs some work > >> for the specific platform (no I2C connection) to verify. > > > > Is the platform supported upstream? If so, which platform is it? Is > > the TI bridge chip the ti-sn65dsi86? If so, I'm confused how you could > > use that bridge chip without an i2c connection, but perhaps I'm > > misunderstanding. :-P > > Yes, the platform is upstream. The 8998 laptops (clamshell). It is the > ti-sn65si86. I suspect the I2C connection was not populated for cost > reasons, then determined its much more convenient to have it as every > generation after that I've seen has the I2C. > > If you check the datasheet closely, the I2C connection is optional. You > can also configure the bridge inband using DSI commands. This is what > the FW and Windows does. > > So, the DT binding needs to make the I2C property optional (this should > be backwards compatible). The driver needs to detect that the I2C > connection is not provided, and fall back to DSI commands. Regmap would > be nice for this, but I got pushback on the proposal. Then I got > sidetracked looking at other issues. Crazy! I'm sure I've skimmed over that part of the ti-sn65dsi86 datasheet before but I don't think I internalized it. I guess if you did it this way then you'd instantiate it as a platform device instead of an i2c device and that would be how you'd detect the difference. I could imagine this being a bit of a challenge to get working in the driver.
[PATCH v11 11/11] gpu: ipu-v3: Use generic macro for rounding closest to specified value
Use generic macro round_closest_up() for rounding closest to specified value instead of using local macro round_closest(). There is no change from functionality point of view as round_closest_up() is functionally same as the previously used local macro round_closest(). Signed-off-by: Devarsh Thakkar --- V11: No change V10: No change V9: No change V8: Update commit message V1->V7 : (No change, patch introduced in V7) --- drivers/gpu/ipu-v3/ipu-image-convert.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c b/drivers/gpu/ipu-v3/ipu-image-convert.c index 841316582ea9..5192a8b5c02c 100644 --- a/drivers/gpu/ipu-v3/ipu-image-convert.c +++ b/drivers/gpu/ipu-v3/ipu-image-convert.c @@ -477,8 +477,6 @@ static int calc_image_resize_coefficients(struct ipu_image_convert_ctx *ctx, return 0; } -#define round_closest(x, y) round_down((x) + (y)/2, (y)) - /* * Find the best aligned seam position for the given column / row index. * Rotation and image offsets are out of scope. @@ -565,7 +563,7 @@ static void find_best_seam(struct ipu_image_convert_ctx *ctx, * The closest input sample position that we could actually * start the input tile at, 19.13 fixed point. */ - in_pos_aligned = round_closest(in_pos, 8192U * in_align); + in_pos_aligned = round_closest_up(in_pos, 8192U * in_align); /* Convert 19.13 fixed point to integer */ in_pos_rounded = in_pos_aligned / 8192U; -- 2.39.1
[PATCH v11 10/11] media: imagination: Round to closest multiple for cropping region
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest values (high and low) are possible to raise the probability of
cropping rectangle falling inside the bound region.
This complies with the VIDIOC_G_SELECTION, VIDIOC_S_SELECTION ioctl
description as documented in v4l uapi [1] which specifies that driver
should choose crop rectangle as close as possible if no flags are passed by
user-space, as quoted below :
"``0`` - The driver can adjust the rectangle size freely and shall choose a
crop/compose rectangle as close as possible to the requested
one."
[1] :
https://www.kernel.org/doc/Documentation/userspace-api/media/v4l/vidioc-g-selection.rst
Signed-off-by: Devarsh Thakkar
---
V11: No change
V10: No change
V9: No change
V8: Update commit message with specification reference
V1->V7 (No change, patch introduced in V7)
---
drivers/media/platform/imagination/e5010-jpeg-enc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c
b/drivers/media/platform/imagination/e5010-jpeg-enc.c
index e701d573a26a..d65646f0c38c 100644
--- a/drivers/media/platform/imagination/e5010-jpeg-enc.c
+++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c
@@ -517,10 +517,10 @@ static int e5010_s_selection(struct file *file, void *fh,
struct v4l2_selection
switch (s->flags) {
case 0:
- s->r.width = round_down(s->r.width,
queue->fmt->frmsize.step_width);
- s->r.height = round_down(s->r.height,
queue->fmt->frmsize.step_height);
- s->r.left = round_down(s->r.left,
queue->fmt->frmsize.step_width);
- s->r.top = round_down(s->r.top, 2);
+ s->r.width = round_closest_down(s->r.width,
queue->fmt->frmsize.step_width);
+ s->r.height = round_closest_down(s->r.height,
queue->fmt->frmsize.step_height);
+ s->r.left = round_closest_down(s->r.left,
queue->fmt->frmsize.step_width);
+ s->r.top = round_closest_down(s->r.top, 2);
if (s->r.left + s->r.width > queue->width)
s->r.width = round_down(s->r.width + s->r.left -
queue->width,
--
2.39.1
Re: [PATCH v6 3/6] drm/msm/dpu: enable compression bit in cfg2 for DSC
On 5/29/2024 10:56 PM, Jun Nie wrote:
Enable compression bit in cfg2 register for DSC in the DSI case
per hardware version.
Signed-off-by: Jun Nie
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Neil Armstrong # on SM8650-QRD
Tested-by: Neil Armstrong # on SM8650-HDK
Reviewed-by: Dmitry Baryshkov
Hi Jun,
LGTM
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 8 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 3 ++-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 925ec6ada0e1..f2aab3e7c783 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -307,7 +307,8 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
spin_lock_irqsave(phys_enc->enc_spinlock, lock_flags);
phys_enc->hw_intf->ops.setup_timing_gen(phys_enc->hw_intf,
- _params, fmt);
+ _params, fmt,
+ phys_enc->dpu_kms->catalog->mdss_ver);
phys_enc->hw_ctl->ops.setup_intf_cfg(phys_enc->hw_ctl, _cfg);
/* setup which pp blk will connect to this intf */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index f97221423249..fa6debda0774 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -98,7 +98,8 @@
static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *intf,
const struct dpu_hw_intf_timing_params *p,
- const struct msm_format *fmt)
+ const struct msm_format *fmt,
+ const struct dpu_mdss_version *mdss_ver)
{
struct dpu_hw_blk_reg_map *c = >hw;
u32 hsync_period, vsync_period;
@@ -177,6 +178,11 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *intf,
if (p->wide_bus_en && !dp_intf)
data_width = p->width >> 1;
+ /* TODO: handle DSC+DP case, we only handle DSC+DSI case so far */
+ if (p->compression_en && !dp_intf &&
+ mdss_ver->core_major_ver >= 7)
+ intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+
hsync_data_start_x = hsync_start_x;
hsync_data_end_x = hsync_start_x + data_width - 1;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index f9015c67a574..ef947bf77693 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -81,7 +81,8 @@ struct dpu_hw_intf_cmd_mode_cfg {
struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
const struct dpu_hw_intf_timing_params *p,
- const struct msm_format *fmt);
+ const struct msm_format *fmt,
+ const struct dpu_mdss_version *mdss_ver);
void (*setup_prg_fetch)(struct dpu_hw_intf *intf,
const struct dpu_hw_intf_prog_fetch *fetch);
--
2.34.1
Re: [PATCH v1 0/4] lm3533: Remove the outdated drivers
+Cc: Johan (via kernel.org) On Fri, May 31, 2024 at 08:14:43PM +0300, Andy Shevchenko wrote: > On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote: > > Driver is quite outdated from the Linux kernel internal APIs > > perspective. In particular GPIO code is using legacy calls, > > that started being replaced by a new API ca. 2014, i.e. ten > > years ago. > > > > Suggested-by: Linus Walleij > > > drivers/mfd/lm3533-core.c | 645 --- > > Oops, still leftovers: one file and Kconfig/Makefile updates... > If needed I'll send a v2, but now I leave it to Lee and Johan to decide > the destiny of the drivers. -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 0/4] lm3533: Remove the outdated drivers
On Fri, May 31, 2024 at 06:14:25PM +0100, Lee Jones wrote: > Making sure Johan is aware of this with his new address. Right, in any case this is not the final version (a couple of leftovers). I have mentioned this series in the original thread. -- With Best Regards, Andy Shevchenko
[PATCH v11 09/11] lib: math_kunit: Add tests for new macros related to rounding to nearest value
Add tests for round_closest_up/down and roundclosest macros which round
to nearest multiple of specified argument. These are tested with kunit
tool as shared here [1].
[1]: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876
Signed-off-by: Devarsh Thakkar
---
V1->V11 (No change, patch introduced in V8)
---
lib/math/math_kunit.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/lib/math/math_kunit.c b/lib/math/math_kunit.c
index be27f2afb8e4..05022f010be6 100644
--- a/lib/math/math_kunit.c
+++ b/lib/math/math_kunit.c
@@ -70,6 +70,26 @@ static void round_down_test(struct kunit *test)
KUNIT_EXPECT_EQ(test, round_down((1 << 30) - 1, 1 << 29), 1 << 29);
}
+static void round_closest_up_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, round_closest_up(17, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_up(15, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_up(14, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_up((1 << 30) - 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_up((1 << 30) + 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_up((1 << 30) - 1, 2), 1 << 30);
+}
+
+static void round_closest_down_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, round_closest_down(17, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_down(15, 4), 16);
+ KUNIT_EXPECT_EQ(test, round_closest_down(14, 4), 12);
+ KUNIT_EXPECT_EQ(test, round_closest_down((1 << 30) - 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_down((1 << 30) + 1, 1 << 30), 1 <<
30);
+ KUNIT_EXPECT_EQ(test, round_closest_down((1 << 30) - 1, 2), (1 << 30) -
2);
+}
+
/* These versions can round to numbers that aren't a power of two */
static void roundup_test(struct kunit *test)
{
@@ -95,6 +115,18 @@ static void rounddown_test(struct kunit *test)
KUNIT_EXPECT_EQ(test, rounddown(4, 3), 3);
}
+static void roundclosest_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, roundclosest(21, 5), 20);
+ KUNIT_EXPECT_EQ(test, roundclosest(19, 5), 20);
+ KUNIT_EXPECT_EQ(test, roundclosest(17, 5), 15);
+ KUNIT_EXPECT_EQ(test, roundclosest((1 << 30), 3), (1 << 30) - 1);
+ KUNIT_EXPECT_EQ(test, roundclosest((1 << 30) - 1, 1 << 29), 1 << 30);
+
+ KUNIT_EXPECT_EQ(test, roundclosest(4, 3), 3);
+ KUNIT_EXPECT_EQ(test, roundclosest(5, 3), 6);
+}
+
static void div_round_up_test(struct kunit *test)
{
KUNIT_EXPECT_EQ(test, DIV_ROUND_UP(0, 1), 0);
@@ -272,8 +304,11 @@ static struct kunit_case math_test_cases[] = {
KUNIT_CASE(int_sqrt_test),
KUNIT_CASE(round_up_test),
KUNIT_CASE(round_down_test),
+ KUNIT_CASE(round_closest_up_test),
+ KUNIT_CASE(round_closest_down_test),
KUNIT_CASE(roundup_test),
KUNIT_CASE(rounddown_test),
+ KUNIT_CASE(roundclosest_test),
KUNIT_CASE(div_round_up_test),
KUNIT_CASE(div_round_closest_test),
KUNIT_CASE_PARAM(gcd_test, gcd_gen_params),
--
2.39.1
Re: [PATCH v1 0/4] lm3533: Remove the outdated drivers
On Fri, 31 May 2024, Andy Shevchenko wrote: > On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote: > > Driver is quite outdated from the Linux kernel internal APIs > > perspective. In particular GPIO code is using legacy calls, > > that started being replaced by a new API ca. 2014, i.e. ten > > years ago. > > > > Suggested-by: Linus Walleij > > > drivers/mfd/lm3533-core.c | 645 --- > > Oops, still leftovers: one file and Kconfig/Makefile updates... > If needed I'll send a v2, but now I leave it to Lee and Johan to decide > the destiny of the drivers. Let's not rush into it. Take your time. -- Lee Jones [李琼斯]
Re: [PATCH v1 0/4] lm3533: Remove the outdated drivers
On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote: > Driver is quite outdated from the Linux kernel internal APIs > perspective. In particular GPIO code is using legacy calls, > that started being replaced by a new API ca. 2014, i.e. ten > years ago. > > Suggested-by: Linus Walleij > drivers/mfd/lm3533-core.c | 645 --- Oops, still leftovers: one file and Kconfig/Makefile updates... If needed I'll send a v2, but now I leave it to Lee and Johan to decide the destiny of the drivers. -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 0/4] lm3533: Remove the outdated drivers
Making sure Johan is aware of this with his new address. On Fri, 31 May 2024, Andy Shevchenko wrote: > Driver is quite outdated from the Linux kernel internal APIs > perspective. In particular GPIO code is using legacy calls, > that started being replaced by a new API ca. 2014, i.e. ten > years ago. > > Suggested-by: Linus Walleij > > Andy Shevchenko (4): > backlight: lm3533_bl: Remove the driver > iio: light: lm3533-als: Remove the driver > leds: lm3533: Remove the driver > mfd: lm3533: Remove the driver > > drivers/iio/light/Kconfig | 17 - > drivers/iio/light/Makefile | 1 - > drivers/iio/light/lm3533-als.c | 922 > drivers/leds/Kconfig| 13 - > drivers/leds/Makefile | 1 - > drivers/leds/leds-lm3533.c | 755 --- > drivers/mfd/lm3533-core.c | 645 --- > drivers/video/backlight/Kconfig | 11 - > drivers/video/backlight/Makefile| 1 - > drivers/video/backlight/lm3533_bl.c | 399 > include/linux/mfd/lm3533.h | 100 --- > 11 files changed, 2865 deletions(-) > delete mode 100644 drivers/iio/light/lm3533-als.c > delete mode 100644 drivers/leds/leds-lm3533.c > delete mode 100644 drivers/mfd/lm3533-core.c > delete mode 100644 drivers/video/backlight/lm3533_bl.c > delete mode 100644 include/linux/mfd/lm3533.h > > -- > 2.43.0.rc1.1336.g36b5255a03ac > -- Lee Jones [李琼斯]
[PATCH v11 08/11] lib: add basic KUnit test for lib/math
From: Daniel Latypov
Add basic test coverage for files that don't require any config options:
* part of math.h (what seem to be the most commonly used macros)
* gcd.c
* lcm.c
* int_sqrt.c
* reciprocal_div.c
(Ignored int_pow.c since it's a simple textbook algorithm.)
These tests aren't particularly interesting, but they
* provide short and simple examples of parameterized tests
* provide a place to add tests for any new files in this dir
* are written so adding new test cases to cover edge cases should be
easy
* looking at code coverage, we hit all the branches in the .c files
Signed-off-by: Daniel Latypov
Reviewed-by: David Gow
[devarsht: Rebase to 6.9, remove kernel.h, update Kconfig and change license to
GPL]
Signed-off-by: Devarsh Thakkar
---
Changes since v10:
* Include headers per IWYU principle and add module description
Changes since v9:
* Added Kconfig dependency for KUNIT
Changes since v8:
* Remove unrequired header file linux/kernel.h
Changes since v7:
* Rebase to linux-next, change license to GPL as suggested by checkpatch.
Changes since v6:
* No change
Changes since v5:
* add in test cases for roundup/rounddown
* address misc comments from David
Changes since v4:
* add in test cases for some math.h macros (abs, round_up/round_down,
div_round_down/closest)
* use parameterized testing less to keep things terser
Changes since v3:
* fix `checkpatch.pl --strict` warnings
* add test cases for gcd(0,0) and lcm(0,0)
* minor: don't test both gcd(a,b) and gcd(b,a) when a == b
Changes since v2: mv math_test.c => math_kunit.c
Changes since v1:
* Rebase and rewrite to use the new parameterized testing support.
* misc: fix overflow in literal and inline int_sqrt format string.
* related: commit 1f0e943df68a ("Documentation: kunit: provide guidance
for testing many inputs") was merged explaining the patterns shown here.
* there's an in-flight patch to update it for parameterized testing.
---
lib/math/Kconfig | 14 ++
lib/math/Makefile | 1 +
lib/math/math_kunit.c | 294 ++
3 files changed, 309 insertions(+)
create mode 100644 lib/math/math_kunit.c
diff --git a/lib/math/Kconfig b/lib/math/Kconfig
index 0634b428d0cb..f738d8a433ea 100644
--- a/lib/math/Kconfig
+++ b/lib/math/Kconfig
@@ -15,3 +15,17 @@ config PRIME_NUMBERS
config RATIONAL
tristate
+
+config MATH_KUNIT_TEST
+ tristate "KUnit test for math helper functions"
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+
+ help
+ This builds unit test for math helper functions as defined in lib/math
+ and math.h.
+
+ For more information on KUNIT and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
diff --git a/lib/math/Makefile b/lib/math/Makefile
index 91fcdb0c9efe..dcf65d10dab2 100644
--- a/lib/math/Makefile
+++ b/lib/math/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_RATIONAL) += rational.o
obj-$(CONFIG_TEST_DIV64) += test_div64.o
obj-$(CONFIG_RATIONAL_KUNIT_TEST) += rational-test.o
+obj-$(CONFIG_MATH_KUNIT_TEST) += math_kunit.o
diff --git a/lib/math/math_kunit.c b/lib/math/math_kunit.c
new file mode 100644
index ..be27f2afb8e4
--- /dev/null
+++ b/lib/math/math_kunit.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Simple KUnit suite for math helper funcs that are always enabled.
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Daniel Latypov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void abs_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, abs((char)0), (char)0);
+ KUNIT_EXPECT_EQ(test, abs((char)42), (char)42);
+ KUNIT_EXPECT_EQ(test, abs((char)-42), (char)42);
+
+ /* The expression in the macro is actually promoted to an int. */
+ KUNIT_EXPECT_EQ(test, abs((short)0), 0);
+ KUNIT_EXPECT_EQ(test, abs((short)42), 42);
+ KUNIT_EXPECT_EQ(test, abs((short)-42), 42);
+
+ KUNIT_EXPECT_EQ(test, abs(0), 0);
+ KUNIT_EXPECT_EQ(test, abs(42), 42);
+ KUNIT_EXPECT_EQ(test, abs(-42), 42);
+
+ KUNIT_EXPECT_EQ(test, abs(0L), 0L);
+ KUNIT_EXPECT_EQ(test, abs(42L), 42L);
+ KUNIT_EXPECT_EQ(test, abs(-42L), 42L);
+
+ KUNIT_EXPECT_EQ(test, abs(0LL), 0LL);
+ KUNIT_EXPECT_EQ(test, abs(42LL), 42LL);
+ KUNIT_EXPECT_EQ(test, abs(-42LL), 42LL);
+
+ /* Unsigned types get casted to signed. */
+ KUNIT_EXPECT_EQ(test, abs(0ULL), 0LL);
+ KUNIT_EXPECT_EQ(test, abs(42ULL), 42LL);
+}
+
+static void int_sqrt_test(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, int_sqrt(0UL), 0UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(1UL), 1UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(4UL), 2UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(5UL), 2UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(8UL), 2UL);
+ KUNIT_EXPECT_EQ(test, int_sqrt(1UL << 30), 1UL << 15);
+}
+
[PATCH v11 07/11] Documentation: core-api: Add math.h macros and functions
Add documentation for rounding, scaling, absolute value and difference, 32-bit division related macros and functions exported by math.h header file. Signed-off-by: Devarsh Thakkar --- V11: Fix title for math function header V10: Patch introduced V1->V9 (No change) --- Documentation/core-api/kernel-api.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index ae92a2571388..7de494e76fa6 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -185,6 +185,12 @@ Division Functions .. kernel-doc:: lib/math/gcd.c :export: +Rounding, absolute value, division and 32-bit scaling functions +--- + +.. kernel-doc:: include/linux/math.h + :internal: + UUID/GUID - -- 2.39.1
[PATCH v11 06/11] math.h: Add macros for rounding to closest value
Add below rounding related macros: round_closest_up(x, y) : Rounds x to closest multiple of y where y is a power of 2, with a preference to round up in case two nearest values are possible. round_closest_down(x, y) : Rounds x to closest multiple of y where y is a power of 2, with a preference to round down in case two nearest values are possible. roundclosest(x, y) : Rounds x to closest multiple of y, this macro should generally be used only when y is not multiple of 2 as otherwise round_closest* macros should be used which are much faster. Examples: * round_closest_up(17, 4) = 16 * round_closest_up(15, 4) = 16 * round_closest_up(14, 4) = 16 * round_closest_down(17, 4) = 16 * round_closest_down(15, 4) = 16 * round_closest_down(14, 4) = 12 * roundclosest(21, 5) = 20 * roundclosest(19, 5) = 20 * roundclosest(17, 5) = 15 Signed-off-by: Devarsh Thakkar --- NOTE: This patch is inspired from the Mentor Graphics IPU driver [1] which uses similar macro locally and which is updated in further patch in the series to use this generic macro instead along with other drivers having similar requirements. [1]: https://elixir.bootlin.com/linux/v6.8.9/source/drivers/gpu/ipu-v3/ipu-image-convert.c#L480 V11: - Fix commenting style per review comments and remove extra whitespace V10: - Update example comment to fix formatting issues as observed with html docs V9: - No change V8: - Add new macro to round to nearest value for non-multiple of 2 - Update commit message as suggested: V1->V6 (No change, patch introduced in V7) --- include/linux/math.h | 63 1 file changed, 63 insertions(+) diff --git a/include/linux/math.h b/include/linux/math.h index dd4152711de7..79e3dfda77fc 100644 --- a/include/linux/math.h +++ b/include/linux/math.h @@ -34,6 +34,52 @@ */ #define round_down(x, y) ((x) & ~__round_mask(x, y)) +/** + * round_closest_up - round closest to be multiple of specified value (which is + *power of 2) with preference to rounding up + * @x: the value to round + * @y: multiple to round closest to (must be a power of 2) + * + * Rounds @x to closest multiple of @y (which must be a power of 2). + * The value can be either rounded up or rounded down depending upon rounded + * value's closeness to the specified value. If there are two closest possible + * values, i.e. the difference between the specified value and it's rounded up + * and rounded down values is same then preference is given to rounded up + * value. + * + * To perform arbitrary rounding to closest value (not multiple of 2), use + * roundclosest(). + * + * Examples: + * * round_closest_up(17, 4) = 16 + * * round_closest_up(15, 4) = 16 + * * round_closest_up(14, 4) = 16 + */ +#define round_closest_up(x, y) round_down((x) + (y) / 2, (y)) + +/** + * round_closest_down - round closest to be multiple of specified value (which + * is power of 2) with preference to rounding down + * @x: the value to round + * @y: multiple to round closest to (must be a power of 2) + * + * Rounds @x to closest multiple of @y (which must be a power of 2). + * The value can be either rounded up or rounded down depending upon rounded + * value's closeness to the specified value. If there are two closest possible + * values, i.e. the difference between the specified value and it's rounded up + * and rounded down values is same then preference is given to rounded up + * value. + * + * To perform arbitrary rounding to closest value (not multiple of 2), use + * roundclosest(). + * + * Examples: + * * round_closest_down(17, 4) = 16 + * * round_closest_down(15, 4) = 16 + * * round_closest_down(14, 4) = 12 + */ +#define round_closest_down(x, y) round_up((x) - (y) / 2, (y)) + #define DIV_ROUND_UP __KERNEL_DIV_ROUND_UP #define DIV_ROUND_DOWN_ULL(ll, d) \ @@ -77,6 +123,23 @@ } \ ) +/** + * roundclosest - round to nearest multiple + * @x: the value to round + * @y: multiple to round nearest to + * + * Rounds @x to nearest multiple of @y. + * The rounded value can be greater than or less than @x depending + * upon it's nearness to @x. If @y will always be a power of 2, consider + * using the faster round_closest_up() or round_closest_down(). + * + * Examples: + * * roundclosest(21, 5) = 20 + * * roundclosest(19, 5) = 20 + * * roundclosest(17, 5) = 15 + */ +#define roundclosest(x, y) rounddown((x) + (y) / 2, (y)) + /* * Divide positive or negative dividend by positive or negative divisor * and round to closest integer. Result is undefined for negative -- 2.39.1
[PATCH v1 3/4] leds: lm3533: Remove the driver
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/leds/Kconfig | 13 -
drivers/leds/Makefile | 1 -
drivers/leds/leds-lm3533.c | 755 -
3 files changed, 769 deletions(-)
delete mode 100644 drivers/leds/leds-lm3533.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 05e6af88b88c..4cdc3a687421 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -229,19 +229,6 @@ config LEDS_LM3532
controlled manually or using PWM input or using ambient
light automatically.
-config LEDS_LM3533
- tristate "LED support for LM3533"
- depends on LEDS_CLASS
- depends on MFD_LM3533
- help
- This option enables support for the LEDs on National Semiconductor /
- TI LM3533 Lighting Power chips.
-
- The LEDs can be controlled directly, through PWM input, or by the
- ambient-light-sensor interface. The chip supports
- hardware-accelerated blinking with maximum on and off periods of 9.8
- and 77 seconds respectively.
-
config LEDS_LM3642
tristate "LED support for LM3642 Chip"
depends on LEDS_CLASS && I2C
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index effdfc6f1e95..6bc8c412d3ac 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_LEDS_IS31FL319X) += leds-is31fl319x.o
obj-$(CONFIG_LEDS_IS31FL32XX) += leds-is31fl32xx.o
obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
obj-$(CONFIG_LEDS_LM3532) += leds-lm3532.o
-obj-$(CONFIG_LEDS_LM3533) += leds-lm3533.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_LM36274) += leds-lm36274.o
obj-$(CONFIG_LEDS_LM3642) += leds-lm3642.o
diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
deleted file mode 100644
index a3d33165d262..
--- a/drivers/leds/leds-lm3533.c
+++ /dev/null
@@ -1,755 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * leds-lm3533.c -- LM3533 LED driver
- *
- * Copyright (C) 2011-2012 Texas Instruments
- *
- * Author: Johan Hovold
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-
-#define LM3533_LVCTRLBANK_MIN 2
-#define LM3533_LVCTRLBANK_MAX 5
-#define LM3533_LVCTRLBANK_COUNT4
-#define LM3533_RISEFALLTIME_MAX7
-#define LM3533_ALS_CHANNEL_LV_MIN 1
-#define LM3533_ALS_CHANNEL_LV_MAX 2
-
-#define LM3533_REG_CTRLBANK_BCONF_BASE 0x1b
-#define LM3533_REG_PATTERN_ENABLE 0x28
-#define LM3533_REG_PATTERN_LOW_TIME_BASE 0x71
-#define LM3533_REG_PATTERN_HIGH_TIME_BASE 0x72
-#define LM3533_REG_PATTERN_RISETIME_BASE 0x74
-#define LM3533_REG_PATTERN_FALLTIME_BASE 0x75
-
-#define LM3533_REG_PATTERN_STEP0x10
-
-#define LM3533_REG_CTRLBANK_BCONF_MAPPING_MASK 0x04
-#define LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK 0x02
-#define LM3533_REG_CTRLBANK_BCONF_ALS_CHANNEL_MASK 0x01
-
-#define LM3533_LED_FLAG_PATTERN_ENABLE 1
-
-
-struct lm3533_led {
- struct lm3533 *lm3533;
- struct lm3533_ctrlbank cb;
- struct led_classdev cdev;
- int id;
-
- struct mutex mutex;
- unsigned long flags;
-};
-
-
-static inline struct lm3533_led *to_lm3533_led(struct led_classdev *cdev)
-{
- return container_of(cdev, struct lm3533_led, cdev);
-}
-
-static inline int lm3533_led_get_ctrlbank_id(struct lm3533_led *led)
-{
- return led->id + 2;
-}
-
-static inline u8 lm3533_led_get_lv_reg(struct lm3533_led *led, u8 base)
-{
- return base + led->id;
-}
-
-static inline u8 lm3533_led_get_pattern(struct lm3533_led *led)
-{
- return led->id;
-}
-
-static inline u8 lm3533_led_get_pattern_reg(struct lm3533_led *led,
- u8 base)
-{
- return base + lm3533_led_get_pattern(led) * LM3533_REG_PATTERN_STEP;
-}
-
-static int lm3533_led_pattern_enable(struct lm3533_led *led, int enable)
-{
- u8 mask;
- u8 val;
- int pattern;
- int state;
- int ret = 0;
-
- dev_dbg(led->cdev.dev, "%s - %d\n", __func__, enable);
-
- mutex_lock(>mutex);
-
- state = test_bit(LM3533_LED_FLAG_PATTERN_ENABLE, >flags);
- if ((enable && state) || (!enable && !state))
- goto out;
-
- pattern = lm3533_led_get_pattern(led);
- mask = 1 << (2 * pattern);
-
- if (enable)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(led->lm3533, LM3533_REG_PATTERN_ENABLE, val, mask);
- if (ret) {
- dev_err(led->cdev.dev, "failed to enable
[PATCH v1 0/4] lm3533: Remove the outdated drivers
Driver is quite outdated from the Linux kernel internal APIs perspective. In particular GPIO code is using legacy calls, that started being replaced by a new API ca. 2014, i.e. ten years ago. Suggested-by: Linus Walleij Andy Shevchenko (4): backlight: lm3533_bl: Remove the driver iio: light: lm3533-als: Remove the driver leds: lm3533: Remove the driver mfd: lm3533: Remove the driver drivers/iio/light/Kconfig | 17 - drivers/iio/light/Makefile | 1 - drivers/iio/light/lm3533-als.c | 922 drivers/leds/Kconfig| 13 - drivers/leds/Makefile | 1 - drivers/leds/leds-lm3533.c | 755 --- drivers/mfd/lm3533-core.c | 645 --- drivers/video/backlight/Kconfig | 11 - drivers/video/backlight/Makefile| 1 - drivers/video/backlight/lm3533_bl.c | 399 include/linux/mfd/lm3533.h | 100 --- 11 files changed, 2865 deletions(-) delete mode 100644 drivers/iio/light/lm3533-als.c delete mode 100644 drivers/leds/leds-lm3533.c delete mode 100644 drivers/mfd/lm3533-core.c delete mode 100644 drivers/video/backlight/lm3533_bl.c delete mode 100644 include/linux/mfd/lm3533.h -- 2.43.0.rc1.1336.g36b5255a03ac
[PATCH v1 1/4] backlight: lm3533_bl: Remove the driver
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/video/backlight/Kconfig | 11 -
drivers/video/backlight/Makefile| 1 -
drivers/video/backlight/lm3533_bl.c | 399
3 files changed, 411 deletions(-)
delete mode 100644 drivers/video/backlight/lm3533_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 230bca07b09d..91d6618d69a0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -198,17 +198,6 @@ config BACKLIGHT_KTZ8866
Say Y to enable the backlight driver for the Kinetic KTZ8866
found in Xiaomi Mi Pad 5 series.
-config BACKLIGHT_LM3533
- tristate "Backlight Driver for LM3533"
- depends on MFD_LM3533
- help
- Say Y to enable the backlight driver for National Semiconductor / TI
- LM3533 Lighting Power chips.
-
- The backlights can be controlled directly, through PWM input, or by
- the ambient-light-sensor interface. The chip supports 256 brightness
- levels.
-
config BACKLIGHT_LOCOMO
tristate "Sharp LOCOMO LCD/Backlight Driver"
depends on SHARP_LOCOMO
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 8d2cb252042d..fc75b9f059f9 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,7 +36,6 @@ obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO)+= ipaq_micro_bl.o
obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
obj-$(CONFIG_BACKLIGHT_KTD2801)+= ktd2801-backlight.o
obj-$(CONFIG_BACKLIGHT_KTZ8866)+= ktz8866.o
-obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
diff --git a/drivers/video/backlight/lm3533_bl.c
b/drivers/video/backlight/lm3533_bl.c
deleted file mode 100644
index 3e10d480cb7f..
--- a/drivers/video/backlight/lm3533_bl.c
+++ /dev/null
@@ -1,399 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * lm3533-bl.c -- LM3533 Backlight driver
- *
- * Copyright (C) 2011-2012 Texas Instruments
- *
- * Author: Johan Hovold
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-
-#define LM3533_HVCTRLBANK_COUNT2
-#define LM3533_BL_MAX_BRIGHTNESS 255
-
-#define LM3533_REG_CTRLBANK_AB_BCONF 0x1a
-
-
-struct lm3533_bl {
- struct lm3533 *lm3533;
- struct lm3533_ctrlbank cb;
- struct backlight_device *bd;
- int id;
-};
-
-
-static inline int lm3533_bl_get_ctrlbank_id(struct lm3533_bl *bl)
-{
- return bl->id;
-}
-
-static int lm3533_bl_update_status(struct backlight_device *bd)
-{
- struct lm3533_bl *bl = bl_get_data(bd);
-
- return lm3533_ctrlbank_set_brightness(>cb,
backlight_get_brightness(bd));
-}
-
-static int lm3533_bl_get_brightness(struct backlight_device *bd)
-{
- struct lm3533_bl *bl = bl_get_data(bd);
- u8 val;
- int ret;
-
- ret = lm3533_ctrlbank_get_brightness(>cb, );
- if (ret)
- return ret;
-
- return val;
-}
-
-static const struct backlight_ops lm3533_bl_ops = {
- .get_brightness = lm3533_bl_get_brightness,
- .update_status = lm3533_bl_update_status,
-};
-
-static ssize_t show_id(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct lm3533_bl *bl = dev_get_drvdata(dev);
-
- return scnprintf(buf, PAGE_SIZE, "%d\n", bl->id);
-}
-
-static ssize_t show_als_channel(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct lm3533_bl *bl = dev_get_drvdata(dev);
- unsigned channel = lm3533_bl_get_ctrlbank_id(bl);
-
- return scnprintf(buf, PAGE_SIZE, "%u\n", channel);
-}
-
-static ssize_t show_als_en(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct lm3533_bl *bl = dev_get_drvdata(dev);
- int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
- u8 val;
- u8 mask;
- bool enable;
- int ret;
-
- ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, );
- if (ret)
- return ret;
-
- mask = 1 << (2 * ctrlbank);
- enable = val & mask;
-
- return scnprintf(buf, PAGE_SIZE, "%d\n", enable);
-}
-
-static ssize_t store_als_en(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- struct lm3533_bl *bl = dev_get_drvdata(dev);
- int ctrlbank =
[PATCH v1 2/4] iio: light: lm3533-als: Remove the driver
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/iio/light/Kconfig | 17 -
drivers/iio/light/Makefile | 1 -
drivers/iio/light/lm3533-als.c | 922 -
3 files changed, 940 deletions(-)
delete mode 100644 drivers/iio/light/lm3533-als.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 9a587d403118..827eee527a62 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -358,23 +358,6 @@ config RPR0521
To compile this driver as a module, choose M here:
the module will be called rpr0521.
-config SENSORS_LM3533
- tristate "LM3533 ambient light sensor"
- depends on MFD_LM3533
- help
- If you say yes here you get support for the ambient light sensor
- interface on National Semiconductor / TI LM3533 Lighting Power
- chips.
-
- The sensor interface can be used to control the LEDs and backlights
- of the chip through defining five light zones and three sets of
- corresponding output-current values.
-
- The driver provides raw and mean adc readings along with the current
- light zone through sysfs. A threshold event can be generated on zone
- changes. The ALS-control output values can be set per zone for the
- three current output channels.
-
config LTR390
tristate "LTR-390UV-01 ambient light and UV sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index a30f906e91ba..6fd7b6f95d1d 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -31,7 +31,6 @@ obj-$(CONFIG_SENSORS_ISL29028)+= isl29028.o
obj-$(CONFIG_ISL29125) += isl29125.o
obj-$(CONFIG_ISL76682) += isl76682.o
obj-$(CONFIG_JSA1212) += jsa1212.o
-obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_LTR390) += ltr390.o
obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LTRF216A) += ltrf216a.o
diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
deleted file mode 100644
index 7800f7fa51b7..
--- a/drivers/iio/light/lm3533-als.c
+++ /dev/null
@@ -1,922 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * lm3533-als.c -- LM3533 Ambient Light Sensor driver
- *
- * Copyright (C) 2011-2012 Texas Instruments
- *
- * Author: Johan Hovold
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-
-#define LM3533_ALS_RESISTOR_MIN1
-#define LM3533_ALS_RESISTOR_MAX127
-#define LM3533_ALS_CHANNEL_CURRENT_MAX 2
-#define LM3533_ALS_THRESH_MAX 3
-#define LM3533_ALS_ZONE_MAX4
-
-#define LM3533_REG_ALS_RESISTOR_SELECT 0x30
-#define LM3533_REG_ALS_CONF0x31
-#define LM3533_REG_ALS_ZONE_INFO 0x34
-#define LM3533_REG_ALS_READ_ADC_RAW0x37
-#define LM3533_REG_ALS_READ_ADC_AVERAGE0x38
-#define LM3533_REG_ALS_BOUNDARY_BASE 0x50
-#define LM3533_REG_ALS_TARGET_BASE 0x60
-
-#define LM3533_ALS_ENABLE_MASK 0x01
-#define LM3533_ALS_INPUT_MODE_MASK 0x02
-#define LM3533_ALS_INT_ENABLE_MASK 0x01
-
-#define LM3533_ALS_ZONE_SHIFT 2
-#define LM3533_ALS_ZONE_MASK 0x1c
-
-#define LM3533_ALS_FLAG_INT_ENABLED1
-
-
-struct lm3533_als {
- struct lm3533 *lm3533;
- struct platform_device *pdev;
-
- unsigned long flags;
- int irq;
-
- atomic_t zone;
- struct mutex thresh_mutex;
-};
-
-
-static int lm3533_als_get_adc(struct iio_dev *indio_dev, bool average,
- int *adc)
-{
- struct lm3533_als *als = iio_priv(indio_dev);
- u8 reg;
- u8 val;
- int ret;
-
- if (average)
- reg = LM3533_REG_ALS_READ_ADC_AVERAGE;
- else
- reg = LM3533_REG_ALS_READ_ADC_RAW;
-
- ret = lm3533_read(als->lm3533, reg, );
- if (ret) {
- dev_err(_dev->dev, "failed to read adc\n");
- return ret;
- }
-
- *adc = val;
-
- return 0;
-}
-
-static int _lm3533_als_get_zone(struct iio_dev *indio_dev, u8 *zone)
-{
- struct lm3533_als *als = iio_priv(indio_dev);
- u8 val;
- int ret;
-
- ret = lm3533_read(als->lm3533, LM3533_REG_ALS_ZONE_INFO, );
- if (ret) {
- dev_err(_dev->dev, "failed to read zone\n");
- return ret;
- }
-
- val = (val & LM3533_ALS_ZONE_MASK) >> LM3533_ALS_ZONE_SHIFT;
- *zone = min_t(u8,
[PATCH v1 4/4] mfd: lm3533: Remove the driver
The driver has no in kernel users and requires a board file
to be instantiated. Remove basically a dead code.
If ever needed, it can be reinstantiated and converted to one
that uses firmware node interfaces.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/lm3533-core.c | 645 -
include/linux/mfd/lm3533.h | 100 --
2 files changed, 745 deletions(-)
delete mode 100644 drivers/mfd/lm3533-core.c
delete mode 100644 include/linux/mfd/lm3533.h
diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
deleted file mode 100644
index c211183cecb2..
--- a/drivers/mfd/lm3533-core.c
+++ /dev/null
@@ -1,645 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * lm3533-core.c -- LM3533 Core
- *
- * Copyright (C) 2011-2012 Texas Instruments
- *
- * Author: Johan Hovold
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-
-#define LM3533_BOOST_OVP_MASK 0x06
-#define LM3533_BOOST_OVP_SHIFT 1
-
-#define LM3533_BOOST_FREQ_MASK 0x01
-#define LM3533_BOOST_FREQ_SHIFT0
-
-#define LM3533_BL_ID_MASK 1
-#define LM3533_LED_ID_MASK 3
-#define LM3533_BL_ID_MAX 1
-#define LM3533_LED_ID_MAX 3
-
-#define LM3533_HVLED_ID_MAX2
-#define LM3533_LVLED_ID_MAX5
-
-#define LM3533_REG_OUTPUT_CONF10x10
-#define LM3533_REG_OUTPUT_CONF20x11
-#define LM3533_REG_BOOST_PWM 0x2c
-
-#define LM3533_REG_MAX 0xb2
-
-
-static struct mfd_cell lm3533_als_devs[] = {
- {
- .name = "lm3533-als",
- .id = -1,
- },
-};
-
-static struct mfd_cell lm3533_bl_devs[] = {
- {
- .name = "lm3533-backlight",
- .id = 0,
- },
- {
- .name = "lm3533-backlight",
- .id = 1,
- },
-};
-
-static struct mfd_cell lm3533_led_devs[] = {
- {
- .name = "lm3533-leds",
- .id = 0,
- },
- {
- .name = "lm3533-leds",
- .id = 1,
- },
- {
- .name = "lm3533-leds",
- .id = 2,
- },
- {
- .name = "lm3533-leds",
- .id = 3,
- },
-};
-
-int lm3533_read(struct lm3533 *lm3533, u8 reg, u8 *val)
-{
- int tmp;
- int ret;
-
- ret = regmap_read(lm3533->regmap, reg, );
- if (ret < 0) {
- dev_err(lm3533->dev, "failed to read register %02x: %d\n",
- reg, ret);
- return ret;
- }
-
- *val = tmp;
-
- dev_dbg(lm3533->dev, "read [%02x]: %02x\n", reg, *val);
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(lm3533_read);
-
-int lm3533_write(struct lm3533 *lm3533, u8 reg, u8 val)
-{
- int ret;
-
- dev_dbg(lm3533->dev, "write [%02x]: %02x\n", reg, val);
-
- ret = regmap_write(lm3533->regmap, reg, val);
- if (ret < 0) {
- dev_err(lm3533->dev, "failed to write register %02x: %d\n",
- reg, ret);
- }
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(lm3533_write);
-
-int lm3533_update(struct lm3533 *lm3533, u8 reg, u8 val, u8 mask)
-{
- int ret;
-
- dev_dbg(lm3533->dev, "update [%02x]: %02x/%02x\n", reg, val, mask);
-
- ret = regmap_update_bits(lm3533->regmap, reg, mask, val);
- if (ret < 0) {
- dev_err(lm3533->dev, "failed to update register %02x: %d\n",
- reg, ret);
- }
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(lm3533_update);
-
-static int lm3533_set_boost_freq(struct lm3533 *lm3533,
- enum lm3533_boost_freq freq)
-{
- int ret;
-
- ret = lm3533_update(lm3533, LM3533_REG_BOOST_PWM,
- freq << LM3533_BOOST_FREQ_SHIFT,
- LM3533_BOOST_FREQ_MASK);
- if (ret)
- dev_err(lm3533->dev, "failed to set boost frequency\n");
-
- return ret;
-}
-
-
-static int lm3533_set_boost_ovp(struct lm3533 *lm3533,
- enum lm3533_boost_ovp ovp)
-{
- int ret;
-
- ret = lm3533_update(lm3533, LM3533_REG_BOOST_PWM,
- ovp << LM3533_BOOST_OVP_SHIFT,
- LM3533_BOOST_OVP_MASK);
- if (ret)
- dev_err(lm3533->dev, "failed to set boost ovp\n");
-
- return ret;
-}
-
-/*
- * HVLED output config -- output hvled controlled by backlight bl
- */
-static int lm3533_set_hvled_config(struct lm3533 *lm3533, u8 hvled, u8 bl)
-{
- u8 val;
- u8 mask;
- int shift;
-
[PATCH v11 00/11] Add V4L2 M2M Driver for E5010 JPEG Encoder
This adds support for V4L2 M2M based driver for E5010 JPEG Encoder which is a stateful JPEG encoder from Imagination technologies and is present in TI AM62A SoC. While adding support for it, following additional framework changes were made: - Moved reference quantization and huffman tables provided in ITU-T-REC-T.81 to v4l2-jpeg.c as suggested in mailing list [1]. - Add macros to round to closest integer (either higher or lower) while rounding in order of 2. - Add KUnit tests for math functions. v4l2-compliance test : Link: https://gist.github.com/devarsht/1f039c631ca953a57f405cfce1b69e49 E5010 JPEG Encoder Manual tests : Performance: Link: https://gist.github.com/devarsht/c40672944fd71c9a53ab55adbfd9e28b Functionality: Link: https://gist.github.com/devarsht/8e88fcaabff016bb2bac83d89c9d23ce Compression Quality: Link: https://gist.github.com/devarsht/cbcc7cd97e8c48ba1486caa2b7884655 Multi Instance: Link: https://gist.github.com/devarsht/22c2fca08cd3441fb40f2c7a4cebc95a Crop support: Link: https://gist.github.com/devarsht/de6f5142f678bb1a5338abfd9f814abd Runtime PM: Link: https://gist.github.com/devarsht/70cd95d4440ddc678489d93885ddd4dd Math lib KUnit tests: Link: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876 [1]: https://lore.kernel.org/all/de46aefe-36da-4e1a-b4fa-b375b2749...@xs4all.nl/ Changelog: V10->V11: - Fix commenting for math.h, include headers per IWYU principle in math_kunit, update title for math.h kernel-doc V9->V10: - Update commenting style in math.h and add notes for new jpeg header macros - Add KUnit dependency for math_kunit V8->V9: - Remove kernel.h header file - Remove stale filler data on jpeg header in E5010 jpeg driver V7->V8: - Add KUnit tests for math functions - Add roundclosest() for supporting rounding for non-multiple of 2 - Update commit message as suggested - Add Reviewed-by and Acked-by tags to patches as received V6->V7: - Fix cropping support - Move reference huffman and quantization tables to v4l2-jpeg.c - Fix suspend/resume use-case - Add Reviewed-by V5->V6: - Fix sparse warnings V4->V5: - Sort the #includes in driver file alphabetically - Rename huffman and quantization tables to not use '_' - Add Reviewed-by tag V3->V4: - Use ti-specific compatible ti,am62a-jpeg-enc as secondary one in dt-binding - Remove clock-names as only single clock in dt-binding - Fix issue with default params setting - Correct v4l2 error prints - Simplify register write functions with single statement return values - Remove unrequired error checks from get_queue() - Drop explicit device_caps setting as it is already taken care by v4l2 core - Remove unrequired multiplanar checks and memset from s_fmt, g_fmt callback functions - Fix try_fmt callback to not update the queues - Remove unrequired contiguous format attribute from queue_init - Use dynamic allocation for video_device and remove unrequired assignments in probe() - Remove unrequired checks from queue_setup function - Return queued buffers back if start_streaming fails - Use ARRAY_SIZE in place of hard-coding - Use huffman and quantization tables from reference header file V2->V3: - Add DONOTMERGE patches for dts and defconfig - Update driver with below changes : - Correct license headers - Use more generic name core instead of jasper for base registers - Add Comment for forward declarations - Simplify quantization table calculations - Use v4l2_apply_frmsize_constraints for updating framesize and remove unrequired functions - Place TODO at top of file and in commit message too - Use dev_err_probe helper in probe function - Fix return value checking for failure scenarios in probe function - Use v4l2_err/info/warn helpers instead of dev_err/info/warn helpers - Fix unexpected indentation - Correct commit message - Update dt-bindings with below changes : - Add vendor specific compatible - Fix commit title and message - Update reg names - Update clocks to 1 - Fix dts example with proper naming V1->V2: - Send dt-bindings and driver together Patch-Diff between the series : V10->V11 Range diff : https://gist.github.com/devarsht/cd76372bff7c125f75d06ba009264b75 V9->V10 Range diff : https://gist.github.com/devarsht/b446acee460b8c65fb577d06b7bbc1da V8->V9 Range diff : https://gist.github.com/devarsht/3fd6c4e8031ab114248f93d01c8dfc74 V6->V7 Range diff : https://gist.github.com/devarsht/1db185b1e187eaf397e9e4c37066777e V5->V6 Range diff : https://gist.github.com/devarsht/c89180ac2b0d2814614f2b59d0705c19 V4->V5 Range diff : https://gist.github.com/devarsht/298790af819f299a0a05fec89371097b V3->V4 Range diff : https://gist.github.com/devarsht/22a744d999080de6e813bcfb5a596272 Previous patch series: V10: https://lore.kernel.org/all/20240530165925.2715837-1-devar...@ti.com/ V9: https://lore.kernel.org/all/20240526175655.1093707-1-devar...@ti.com/ V8: https://lore.kernel.org/all/20240517171532.748684-1-devar...@ti.com/ V7:
Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
On 5/31/2024 10:20 AM, Doug Anderson wrote: Hi, On Fri, May 31, 2024 at 9:18 AM Jeffrey Hugo wrote: On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: There are two ways to describe an eDP panel in device tree. The recommended way is to add a device on the AUX bus, ideally using the edp-panel compatible. The legacy way is to define a top-level platform device for the panel. Document that adding support for eDP panels in a legacy way is strongly discouraged (if not forbidden at all). While we are at it, also drop legacy compatible strings and bindings for five panels. These compatible strings were never used by a DT file present in Linux kernel and most likely were never used with the upstream Linux kernel. The following compatibles were never used by the devices supported by the upstream kernel and are a subject to possible removal: - lg,lp097qx1-spa1 - samsung,lsn122dl01-c01 - sharp,ld-d5116z01b Ok to drop the sharp one I added. It should be able to be handled by the (newish) edp-panel, but I think the TI bridge driver needs some work for the specific platform (no I2C connection) to verify. Is the platform supported upstream? If so, which platform is it? Is the TI bridge chip the ti-sn65dsi86? If so, I'm confused how you could use that bridge chip without an i2c connection, but perhaps I'm misunderstanding. :-P Yes, the platform is upstream. The 8998 laptops (clamshell). It is the ti-sn65si86. I suspect the I2C connection was not populated for cost reasons, then determined its much more convenient to have it as every generation after that I've seen has the I2C. If you check the datasheet closely, the I2C connection is optional. You can also configure the bridge inband using DSI commands. This is what the FW and Windows does. So, the DT binding needs to make the I2C property optional (this should be backwards compatible). The driver needs to detect that the I2C connection is not provided, and fall back to DSI commands. Regmap would be nice for this, but I got pushback on the proposal. Then I got sidetracked looking at other issues. -Jeff
Re: [PATCH v5 00/10] drm: zynqmp_dp: IRQ cleanups and debugfs support
On 5/3/24 15:29, Sean Anderson wrote: > This series cleans up the zyqnmp_dp IRQ and locking situation. Once > that's done, it adds debugfs support. The intent is to enable compliance > testing or to help debug signal-integrity issues. > > Last time I discussed converting the HPD work(s) to a threaded IRQ. I > did not end up doing that for this series since the steps would be > > - Add locking > - Move link retraining to a work function > - Harden the IRQ > - Merge the works into a threaded IRQ (omitted) > > Which with the exception of the final step is the same as leaving those > works as-is. Conversion to a threaded IRQ can be done as a follow-up. > > Changes in v5: > - Fix AUX bus not getting unregistered > - Rebase onto drm-misc/drm-misc-next > > Changes in v4: > - Rebase onto drm/drm-next > > Changes in v3: > - Don't delay work > - Convert to a hard IRQ > - Use AUX IRQs instead of polling > - Take dp->lock in zynqmp_dp_hpd_work_func > > Changes in v2: > - Rearrange zynqmp_dp for better padding > - Split off the HPD IRQ work into another commit > - Expand the commit message > - Document hpd_irq_work > - Document debugfs files > - Add ignore_aux_errors and ignore_hpd debugfs files to replace earlier > implicit functionality > - Attempt to fix unreproducable, spurious build warning > - Drop "Optionally ignore DPCD errors" in favor of a debugfs file > directly affecting zynqmp_dp_aux_transfer. > > Sean Anderson (10): > drm: zynqmp_kms: Fix AUX bus not getting unregistered > drm: zynqmp_dp: Rearrange zynqmp_dp for better padding > drm: zynqmp_dp: Don't delay work > drm: zynqmp_dp: Add locking > drm: zynqmp_dp: Don't retrain the link in our IRQ > drm: zynqmp_dp: Convert to a hard IRQ > drm: zynqmp_dp: Use AUX IRQs instead of polling > drm: zynqmp_dp: Split off several helper functions > drm: zynqmp_dp: Take dp->lock in zynqmp_dp_hpd_work_func > drm: zynqmp_dp: Add debugfs interface for compliance testing > > Documentation/gpu/drivers.rst | 1 + > Documentation/gpu/zynqmp.rst | 149 + > MAINTAINERS | 1 + > drivers/gpu/drm/xlnx/zynqmp_dp.c | 883 +++--- > drivers/gpu/drm/xlnx/zynqmp_kms.c | 12 +- > 5 files changed, 977 insertions(+), 69 deletions(-) > create mode 100644 Documentation/gpu/zynqmp.rst > ping --Sean
Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
Hi, On Fri, May 31, 2024 at 9:18 AM Jeffrey Hugo wrote: > > On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: > > There are two ways to describe an eDP panel in device tree. The > > recommended way is to add a device on the AUX bus, ideally using the > > edp-panel compatible. The legacy way is to define a top-level platform > > device for the panel. > > > > Document that adding support for eDP panels in a legacy way is strongly > > discouraged (if not forbidden at all). > > > > While we are at it, also drop legacy compatible strings and bindings for > > five panels. These compatible strings were never used by a DT file > > present in Linux kernel and most likely were never used with the > > upstream Linux kernel. > > > > The following compatibles were never used by the devices supported by > > the upstream kernel and are a subject to possible removal: > > > > - lg,lp097qx1-spa1 > > - samsung,lsn122dl01-c01 > > - sharp,ld-d5116z01b > > Ok to drop the sharp one I added. It should be able to be handled by > the (newish) edp-panel, but I think the TI bridge driver needs some work > for the specific platform (no I2C connection) to verify. Is the platform supported upstream? If so, which platform is it? Is the TI bridge chip the ti-sn65dsi86? If so, I'm confused how you could use that bridge chip without an i2c connection, but perhaps I'm misunderstanding. :-P Thanks! -Doug
Re: [PATCH v3 0/3] drm/panel-edp: remove several legacy compatibles used by the driver
On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote: There are two ways to describe an eDP panel in device tree. The recommended way is to add a device on the AUX bus, ideally using the edp-panel compatible. The legacy way is to define a top-level platform device for the panel. Document that adding support for eDP panels in a legacy way is strongly discouraged (if not forbidden at all). While we are at it, also drop legacy compatible strings and bindings for five panels. These compatible strings were never used by a DT file present in Linux kernel and most likely were never used with the upstream Linux kernel. The following compatibles were never used by the devices supported by the upstream kernel and are a subject to possible removal: - lg,lp097qx1-spa1 - samsung,lsn122dl01-c01 - sharp,ld-d5116z01b Ok to drop the sharp one I added. It should be able to be handled by the (newish) edp-panel, but I think the TI bridge driver needs some work for the specific platform (no I2C connection) to verify. -Jeff
Re: [PATCH] MAINTAINERS: Update Xe driver maintainers
On Fri, May 31, 2024 at 04:10:51PM GMT, Thomas Hellström wrote: Add Rodrigo Vivi as an Xe driver maintainer. Cc: David Airlie Cc: Daniel Vetter Cc: Rodrigo Vivi Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org shouldn't have a blank line here. Otherwise git doesn't consider the lines above as part of the trailer. Acked-by: Lucas De Marchi Maybe we should also add a T: git https://gitlab.freedesktop.org/drm/i915/kernel.git on the display side so we direct display patches to go through drm-intel like we are currently doing. But we can leave this for another patch. thanks Lucas De Marchi Signed-off-by: Thomas Hellström --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 572be0546e21..8f9982c99257 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11037,6 +11037,7 @@ F: include/uapi/drm/i915_drm.h INTEL DRM XE DRIVER (Lunar Lake and newer) M: Lucas De Marchi M: Thomas Hellström +M: Rodrigo Vivi L: intel...@lists.freedesktop.org S: Supported W: https://drm.pages.freedesktop.org/intel-docs/ -- 2.44.0
Re: [PATCH][next] drm/amd/display: Fix a handful of spelling mistakes
On 5/31/24 2:32 AM, Colin Ian King wrote:
> There are a few spelling mistakes in dml2_printf messages. Fix them.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Randy Dunlap
Thanks.
> ---
> .../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c | 6 +++---
> .../display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
>
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> index 8062144a5a6d..e7e6751f4477 100644
> ---
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> +++
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c
> @@ -5731,7 +5731,7 @@ static bool CalculatePrefetchSchedule(struct
> dml2_core_internal_scratch *scratch
> dml2_printf("DML: Tvm: %fus - time to fetch vm\n",
> s->TimeForFetchingVM);
> dml2_printf("DML: Tr0: %fus - time to fetch first row of data
> pagetables\n", s->TimeForFetchingRowInVBlank);
> dml2_printf("DML: Tsw: %fus = time to fetch enough pixel data
> and cursor data to feed the scalers init position and detile\n",
> (double)s->LinesToRequestPrefetchPixelData * s->LineTime);
> - dml2_printf("DML: To: %fus - time for propogation from scaler
> to optc\n", (*p->DSTYAfterScaler + ((double)(*p->DSTXAfterScaler) /
> (double)p->myPipe->HTotal)) * s->LineTime);
> + dml2_printf("DML: To: %fus - time for propagation from scaler
> to optc\n", (*p->DSTYAfterScaler + ((double)(*p->DSTXAfterScaler) /
> (double)p->myPipe->HTotal)) * s->LineTime);
> dml2_printf("DML: Tvstartup - TSetup - Tcalc - TWait - Tpre -
> To > 0\n");
> dml2_printf("DML: Tslack(pre): %fus - time left over in
> schedule\n", p->VStartup * s->LineTime - s->TimeForFetchingVM - 2 *
> s->TimeForFetchingRowInVBlank - (*p->DSTYAfterScaler +
> ((double)(*p->DSTXAfterScaler) / (double)p->myPipe->HTotal)) * s->LineTime -
> p->TWait - p->TCalc - *p->TSetup);
> dml2_printf("DML: row_bytes = dpte_row_bytes (per_pipe) =
> PixelPTEBytesPerRow = : %u\n", p->PixelPTEBytesPerRow);
> @@ -8268,7 +8268,7 @@ static bool dml_core_mode_support(struct
> dml2_core_calcs_mode_support_ex *in_out
> dml2_printf("DML::%s: mode_lib->ms.DCFCLK = %f\n", __func__,
> mode_lib->ms.DCFCLK);
> dml2_printf("DML::%s: mode_lib->ms.FabricClock = %f\n", __func__,
> mode_lib->ms.FabricClock);
> dml2_printf("DML::%s: mode_lib->ms.uclk_freq_mhz = %f\n", __func__,
> mode_lib->ms.uclk_freq_mhz);
> - dml2_printf("DML::%s: urgent latency tolarance = %f\n", __func__,
> ((mode_lib->ip.rob_buffer_size_kbytes - mode_lib->ip.pixel_chunk_size_kbytes)
> * 1024 / (mode_lib->ms.DCFCLK * mode_lib->soc.return_bus_width_bytes)));
> + dml2_printf("DML::%s: urgent latency tolerance = %f\n", __func__,
> ((mode_lib->ip.rob_buffer_size_kbytes - mode_lib->ip.pixel_chunk_size_kbytes)
> * 1024 / (mode_lib->ms.DCFCLK * mode_lib->soc.return_bus_width_bytes)));
> #endif
>
> mode_lib->ms.support.OutstandingRequestsSupport = true;
> @@ -11089,7 +11089,7 @@ static bool dml_core_mode_programming(struct
> dml2_core_calcs_mode_programming_ex
> if
> (display_cfg->plane_descriptors[k].immediate_flip &&
> mode_lib->mp.ImmediateFlipSupportedForPipe[k] == false) {
> mode_lib->mp.ImmediateFlipSupported =
> false;
> #ifdef __DML_VBA_DEBUG__
> - dml2_printf("DML::%s: Pipe %0d not
> supporing iflip!\n", __func__, k);
> + dml2_printf("DML::%s: Pipe %0d not
> supporting iflip!\n", __func__, k);
> #endif
> }
> }
> diff --git
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> index f2e2250d28d3..6eb3fec87ec1 100644
> ---
> a/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> +++
> b/drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c
> @@ -1988,7 +1988,7 @@ bool dml2_core_shared_mode_support(struct
> dml2_core_calcs_mode_support_ex *in_ou
> dml2_printf("DML::%s: mode_lib->ms.FabricClock = %f\n", __func__,
> mode_lib->ms.FabricClock);
> dml2_printf("DML::%s: mode_lib->ms.uclk_freq_mhz = %f\n", __func__,
> mode_lib->ms.uclk_freq_mhz);
> dml2_printf("DML::%s: max_urgent_latency_us = %f\n", __func__,
> mode_lib->ms.support.max_urgent_latency_us);
> - dml2_printf("DML::%s: urgent latency tolarance = %f\n", __func__,
> ((mode_lib->ip.rob_buffer_size_kbytes - mode_lib->ip.pixel_chunk_size_kbytes)
> * 1024 / (mode_lib->ms.DCFCLK * mode_lib->soc.return_bus_width_bytes)));
> + dml2_printf("DML::%s:
Re: [PATCH] kernel/resource: optimize find_next_iomem_res
On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote: > We can skip children resources when the parent resource does not cover > the range. > This should help vmf_insert_* users on x86, such as several DRM drivers. vmf_insert_*() > On my AMD Ryzen 5 7520C, when streaming data from cpu memory into amdgpu > bo, the throughput goes from 5.1GB/s to 6.6GB/s. perf report says Also in the $Subj (and pay attention to the prefix) "resource: ... find_next_iomem_res()" -- With Best Regards, Andy Shevchenko
Re: [PATCH] MAINTAINERS: Update Xe driver maintainers
On Fri, May 31, 2024 at 04:10:51PM +0200, Thomas Hellström wrote: > Add Rodrigo Vivi as an Xe driver maintainer. > > Cc: David Airlie > Cc: Daniel Vetter > Cc: Rodrigo Vivi Cc: Lucas De Marchi Acked-by: Rodrigo Vivi > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > > Signed-off-by: Thomas Hellström > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 572be0546e21..8f9982c99257 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11037,6 +11037,7 @@ F:include/uapi/drm/i915_drm.h > INTEL DRM XE DRIVER (Lunar Lake and newer) > M: Lucas De Marchi > M: Thomas Hellström > +M: Rodrigo Vivi > L: intel...@lists.freedesktop.org > S: Supported > W: https://drm.pages.freedesktop.org/intel-docs/ > -- > 2.44.0 >
Re: [PATCH 1/6] dt-bindings: clock: mediatek: Add mt8173 mfgtop
On Fri, May 31, 2024 at 03:29:06PM +0800, Chen-Yu Tsai wrote:
> On Thu, May 30, 2024 at 11:43 PM Conor Dooley wrote:
> >
> > On Thu, May 30, 2024 at 04:35:00PM +0800, Chen-Yu Tsai wrote:
> > > +#include
> > > +#include
> > > +
> > > +mfgtop: clock-controller@13fff000 {
> >
> > The label here is used, so drop it.
>
> Assume you mean _not_ used. Dropping. :D
Correct :D
signature.asc
Description: PGP signature
Re: [PATCH] drm/tegra: fix a possible null pointer dereference
On Fri May 31, 2024 at 3:56 PM CEST, Huai-Yuan Liu wrote:
> In malidp_tegra_crtc_reset, new memory is allocated with kzalloc, but
> no check is performed. Before calling __drm_atomic_helper_crtc_reset,
> mw_state should be checked to prevent possible null pointer dereferene.
Please check that all these variable name references actually are valid.
Also, "dereference".
> Fixes: b7e0b04ae450 ("drm/tegra: Convert to using
> __drm_atomic_helper_crtc_reset() for reset.")
> Signed-off-by: Huai-Yuan Liu
> ---
> drivers/gpu/drm/tegra/dc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index be61c9d1a4f0..7648e129c212 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1388,7 +1388,8 @@ static void tegra_crtc_reset(struct drm_crtc *crtc)
> if (crtc->state)
> tegra_crtc_atomic_destroy_state(crtc, crtc->state);
>
> - __drm_atomic_helper_crtc_reset(crtc, >base);
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
Looking at how other drivers do this, they call
__drm_atomic_helper_crtc_reset(crtc, NULL);
if they fail to allocate a new state. Any reason why we wouldn't want to
do the same thing here?
Thierry
signature.asc
Description: PGP signature
Re: [PATCH 3/6] dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
On Fri, May 31, 2024 at 8:37 AM Frank Binns wrote: > > Hi ChenYu, > > On Thu, 2024-05-30 at 16:35 +0800, Chen-Yu Tsai wrote: > > The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one > > of the Series6XT GPUs, another sub-family of the Rogue family. > > I've added Adam Ford who sent out some DT related patches [1] for the Renesas > variant of GX6250 and the GX6650 (another Series6XT GPU). > Thanks for including me. > > > > This was part of the very first few versions of the PowerVR submission, > > but was later dropped. The compatible string has been updated to follow > > the new naming scheme adopted for the AXE series. > > > > In a previous iteration of the PowerVR binding submission [1], the > > number of clocks required for the 6XT family was mentioned to be > > always 3. This is also reflected here. > > > > [1] > > https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.ca...@imgtec.com/ > > > > Signed-off-by: Chen-Yu Tsai > > --- > > .../bindings/gpu/img,powervr-rogue.yaml | 24 +++ > > 1 file changed, 20 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > index 256e252f8087..48aa205b66b4 100644 > > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > @@ -12,10 +12,17 @@ maintainers: > > > > properties: > >compatible: > > -items: > > - - enum: > > - - ti,am62-gpu > > - - const: img,img-axe # IMG AXE GPU model/revision is fully > > discoverable > > +oneOf: > > + - items: > > + - enum: > > + - mediatek,mt8173-gpu > > + # PowerVR 6XT GPU model/revision is fully discoverable > > + - const: img,powervr-6xt > > + - items: > > + - enum: > > + - ti,am62-gpu > > + # IMG AXE GPU model/revision is fully discoverable > > + - const: img,img-axe > > The Series6XT GPU models have differing numbers of power domains (either 2, 4 > or > 5). Whereas, the AXE GPUs have a single power domain, so I assume there should > be a related change here. > > The GX6250 has two power domains (lets call them A and B). There's a > constraint > that if domain B is powered then domain A must also be powered. > > In patch 6 [2] it's setting the power domain to MT8173_POWER_DOMAIN_MFG, > which I > believe corresponds to power domain B. I assume this works because the MTK > power > controller driver is encoding the constraint above, meaning that when we > disable > or enable MT8173_POWER_DOMAIN_MFG it's also disabling/enabling > MT8173_POWER_DOMA > IN_MFG_2D (domain A). > In the cover letter of this series, it was noted that the GPU enumerates, but it doesn' fully function yet. This is also the case for both of the Renesas variants I have been testing, and I was nicely asked to postpone my series until the driver was closer to being ready. Even if the driver isn't ready yet, it would be nice to move the bindings forward. adam > Thanks > Frank > > [1] https://lists.freedesktop.org/archives/dri-devel/2024-February/443548.html > [2] https://lists.freedesktop.org/archives/dri-devel/2024-May/455833.html > > > > >reg: > > maxItems: 1 > > @@ -56,6 +63,15 @@ allOf: > >properties: > > clocks: > >maxItems: 1 > > + - if: > > + properties: > > +compatible: > > + contains: > > +const: img,powervr-6xt > > +then: > > + properties: > > +clocks: > > + minItems: 3 > > > > examples: > >- |
Re: [PATCH] Documentation/accel/qaic: Fix typo 'phsyical'
On 5/31/24 00:09, Danish Prakash wrote: (as part of LFX Linux Mentorship program) Please add proper commit log for this change. Signed-off-by: Danish Prakash --- Documentation/accel/qaic/qaic.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/accel/qaic/qaic.rst b/Documentation/accel/qaic/qaic.rst index efb7771273bb..628bf2f7a416 100644 --- a/Documentation/accel/qaic/qaic.rst +++ b/Documentation/accel/qaic/qaic.rst @@ -93,7 +93,7 @@ commands (does not impact QAIC). uAPI -QAIC creates an accel device per phsyical PCIe device. This accel device exists +QAIC creates an accel device per physical PCIe device. This accel device exists for as long as the PCIe device is known to Linux. The PCIe device may not be in the state to accept requests from userspace at thanks, -- Shuah
Re: [PATCH v6 0/2] backlight: Add new lm3509 backlight driver
On Sun, 26 May 2024 12:51:28 +0200, Patrick Gansterer wrote: > This is a general driver for LM3509 backlight chip of TI. > LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with > Dual Current Sinks. This driver supports OLED/White LED select, brightness > control and sub/main control. > The datasheet can be found at http://www.ti.com/product/lm3509. > Applied, thanks! [1/2] dt-bindings: backlight: Add Texas Instruments LM3509 commit: 0aaee23d49a614b573ca51ab7758e77fcc3d7d14 [2/2] backlight: Add new lm3509 backlight driver commit: b72755f5b577357cac661cbf9048cad704eb4ad8 -- Lee Jones [李琼斯]
[PATCH] MAINTAINERS: Update Xe driver maintainers
Add Rodrigo Vivi as an Xe driver maintainer. Cc: David Airlie Cc: Daniel Vetter Cc: Rodrigo Vivi Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Thomas Hellström --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 572be0546e21..8f9982c99257 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11037,6 +11037,7 @@ F: include/uapi/drm/i915_drm.h INTEL DRM XE DRIVER (Lunar Lake and newer) M: Lucas De Marchi M: Thomas Hellström +M: Rodrigo Vivi L: intel...@lists.freedesktop.org S: Supported W: https://drm.pages.freedesktop.org/intel-docs/ -- 2.44.0
Re: [v4,1/2] drm/bridge: sii902x: Fix mode_valid hook
Hi, Jayesh
On 5/31/24 21:33, Sam Ravnborg wrote:
Hi Jayesh,
+
static const struct drm_bridge_funcs sii902x_bridge_funcs = {
.attach = sii902x_bridge_attach,
.mode_set = sii902x_bridge_mode_set,
@@ -516,6 +529,7 @@ static const struct drm_bridge_funcs sii902x_bridge_funcs =
{
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = sii902x_bridge_atomic_get_input_bus_fmts,
.atomic_check = sii902x_bridge_atomic_check,
+ .mode_valid = sii902x_bridge_mode_valid,
As you have the possibility to test the driver, it would be nice with a
follow-up patch that replaces the use of enable() / disable() with the
atomic counterparts.
enable() / disable() are deprecated, so it is nice to reduce their use.
I agree with Sam.
Please using atomic uniformally with a follow-up patch, the mixed
using of atomic API and non atomic API is a little bit confusing IMO.
Sam
Re: [PATCH 3/6] dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
Hi ChenYu, On Thu, 2024-05-30 at 16:35 +0800, Chen-Yu Tsai wrote: > The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one > of the Series6XT GPUs, another sub-family of the Rogue family. I've added Adam Ford who sent out some DT related patches [1] for the Renesas variant of GX6250 and the GX6650 (another Series6XT GPU). > > This was part of the very first few versions of the PowerVR submission, > but was later dropped. The compatible string has been updated to follow > the new naming scheme adopted for the AXE series. > > In a previous iteration of the PowerVR binding submission [1], the > number of clocks required for the 6XT family was mentioned to be > always 3. This is also reflected here. > > [1] > https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.ca...@imgtec.com/ > > Signed-off-by: Chen-Yu Tsai > --- > .../bindings/gpu/img,powervr-rogue.yaml | 24 +++ > 1 file changed, 20 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > index 256e252f8087..48aa205b66b4 100644 > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > @@ -12,10 +12,17 @@ maintainers: > > properties: >compatible: > -items: > - - enum: > - - ti,am62-gpu > - - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable > +oneOf: > + - items: > + - enum: > + - mediatek,mt8173-gpu > + # PowerVR 6XT GPU model/revision is fully discoverable > + - const: img,powervr-6xt > + - items: > + - enum: > + - ti,am62-gpu > + # IMG AXE GPU model/revision is fully discoverable > + - const: img,img-axe The Series6XT GPU models have differing numbers of power domains (either 2, 4 or 5). Whereas, the AXE GPUs have a single power domain, so I assume there should be a related change here. The GX6250 has two power domains (lets call them A and B). There's a constraint that if domain B is powered then domain A must also be powered. In patch 6 [2] it's setting the power domain to MT8173_POWER_DOMAIN_MFG, which I believe corresponds to power domain B. I assume this works because the MTK power controller driver is encoding the constraint above, meaning that when we disable or enable MT8173_POWER_DOMAIN_MFG it's also disabling/enabling MT8173_POWER_DOMA IN_MFG_2D (domain A). Thanks Frank [1] https://lists.freedesktop.org/archives/dri-devel/2024-February/443548.html [2] https://lists.freedesktop.org/archives/dri-devel/2024-May/455833.html > >reg: > maxItems: 1 > @@ -56,6 +63,15 @@ allOf: >properties: > clocks: >maxItems: 1 > + - if: > + properties: > +compatible: > + contains: > +const: img,powervr-6xt > +then: > + properties: > +clocks: > + minItems: 3 > > examples: >- |
Re: [v4,1/2] drm/bridge: sii902x: Fix mode_valid hook
Hi Jayesh,
> > +
> > static const struct drm_bridge_funcs sii902x_bridge_funcs = {
> > .attach = sii902x_bridge_attach,
> > .mode_set = sii902x_bridge_mode_set,
> > @@ -516,6 +529,7 @@ static const struct drm_bridge_funcs
> > sii902x_bridge_funcs = {
> > .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> > .atomic_get_input_bus_fmts = sii902x_bridge_atomic_get_input_bus_fmts,
> > .atomic_check = sii902x_bridge_atomic_check,
> > + .mode_valid = sii902x_bridge_mode_valid,
As you have the possibility to test the driver, it would be nice with a
follow-up patch that replaces the use of enable() / disable() with the
atomic counterparts.
enable() / disable() are deprecated, so it is nice to reduce their use.
Sam
Re: [PATCH v2 00/10] drm: move Intel drm headers to a subdirectory
On Thu, 30 May 2024, Jani Nikula wrote:
> We've accumulated enough Intel specific header files under include/drm
> that they warrant a subdirectory of their own. Clean up the top drm
> header directory by moving the Intel files under include/drm/intel.
>
> Since i915 is most impacted, I suggest merging the lot via
> drm-intel-next. Please ack if this is fine for you.
Pushed to drm-intel-next.
BR,
Jani.
>
> BR,
> Jani.
>
> Jani Nikula (10):
> drm: move intel-gtt.h under include/drm/intel
> drm: move i915_gsc_proxy_mei_interface.h under include/drm/intel
> drm: move i915_component.h under include/drm/intel
> drm: move intel_lpe_audio.h under include/drm/intel
> drm: move i915_drm.h under include/drm/intel
> drm: move i915_pxp_tee_interface.h under include/drm/intel
> drm: move i915_pciids.h under include/drm/intel
> drm: move xe_pciids.h under include/drm/intel
> drm: move i915_hdcp_interface.h under include/drm/intel
> MAINTAINERS: update i915 and xe entries for include/drm/intel
>
> Documentation/gpu/i915.rst | 2 +-
> MAINTAINERS| 5 +++--
> arch/x86/kernel/early-quirks.c | 4 ++--
> drivers/char/agp/intel-agp.c | 2 +-
> drivers/char/agp/intel-gtt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display_device.c| 2 +-
> drivers/gpu/drm/i915/display/intel_display_types.h | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_lpe_audio.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_rps.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 4 ++--
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> drivers/gpu/drm/i915/intel_pci_config.h| 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 ++--
> drivers/gpu/drm/i915/soc/intel_gmch.c | 2 +-
> drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 2 +-
> drivers/gpu/drm/xe/xe_ggtt.c | 2 +-
> drivers/gpu/drm/xe/xe_gsc_proxy.c | 4 ++--
> drivers/gpu/drm/xe/xe_pci.c| 2 +-
> drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c | 4 ++--
> drivers/misc/mei/hdcp/mei_hdcp.c | 4 ++--
> drivers/misc/mei/pxp/mei_pxp.c | 4 ++--
> drivers/platform/x86/intel_ips.c | 2 +-
> include/drm/{ => intel}/i915_component.h | 0
> include/drm/{ => intel}/i915_drm.h | 0
> include/drm/{ => intel}/i915_gsc_proxy_mei_interface.h | 0
> include/drm/{ => intel}/i915_hdcp_interface.h | 0
> include/drm/{ => intel}/i915_pciids.h | 0
> include/drm/{ => intel}/i915_pxp_tee_interface.h | 0
> include/drm/{ => intel}/intel-gtt.h| 0
> include/drm/{ => intel}/intel_lpe_audio.h | 0
> include/drm/{ => intel}/xe_pciids.h| 0
> include/sound/hdaudio.h| 2 +-
> sound/x86/intel_hdmi_audio.c | 2 +-
> 43 files changed, 44 insertions(+), 43 deletions(-)
> rename include/drm/{ => intel}/i915_component.h (100%)
> rename include/drm/{ => intel}/i915_drm.h (100%)
> rename include/drm/{ => intel}/i915_gsc_proxy_mei_interface.h (100%)
> rename include/drm/{ => intel}/i915_hdcp_interface.h (100%)
> rename include/drm/{ => intel}/i915_pciids.h (100%)
> rename include/drm/{ => intel}/i915_pxp_tee_interface.h (100%)
> rename include/drm/{ => intel}/intel-gtt.h (100%)
> rename include/drm/{ => intel}/intel_lpe_audio.h (100%)
> rename include/drm/{ => intel}/xe_pciids.h (100%)
--
Jani Nikula, Intel
Re: [v4,1/2] drm/bridge: sii902x: Fix mode_valid hook
Hi,
On 5/30/24 17:29, Jayesh Choudhary wrote:
Currently, mode_valid hook returns all mode as valid and it is
defined only in drm_connector_helper_funcs. With the introduction of
'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
bridge_attach call for cases when the encoder has this flag enabled.
So move the mode_valid hook to drm_bridge_funcs with proper clock
checks for maximum and minimum pixel clock supported by the bridge.
Signed-off-by: Jayesh Choudhary
Acked-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/sii902x.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 2fbeda9025bf..6a6055a4ccf9 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -163,6 +163,14 @@
#define SII902X_AUDIO_PORT_INDEX 3
+/*
+ * The maximum resolution supported by the HDMI bridge is 1080p@60Hz
+ * and 1920x1200 requiring a pixel clock of 165MHz and the minimum
+ * resolution supported is 480p@60Hz requiring a pixel clock of 25MHz
+ */
+#define SII902X_MIN_PIXEL_CLOCK_KHZ25000
+#define SII902X_MAX_PIXEL_CLOCK_KHZ165000
+
This bridge can drive 2560x1080@75Hz monitor(LG 34BL650), the pixel
clock can up to 181250 kHz. I remember that I have tested the native
mode with LS2K1000 SoC, and it do works in practice. And there are
also has 320x240 panels, maybe it's also usuable with this HDMI
transmitter
Well, the datasheet mentioned that it supports up to 165 MHz
dual-edge and single-edge modes. So I'm not against your patch,
just mention it to let you know.
struct sii902x {
struct i2c_client *i2c;
struct regmap *regmap;
@@ -310,17 +318,8 @@ static int sii902x_get_modes(struct drm_connector
*connector)
return num;
}
-static enum drm_mode_status sii902x_mode_valid(struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /* TODO: check mode */
-
- return MODE_OK;
-}
-
static const struct drm_connector_helper_funcs sii902x_connector_helper_funcs
= {
.get_modes = sii902x_get_modes,
- .mode_valid = sii902x_mode_valid,
};
static void sii902x_bridge_disable(struct drm_bridge *bridge)
@@ -504,6 +503,20 @@ static int sii902x_bridge_atomic_check(struct drm_bridge
*bridge,
return 0;
}
+static enum drm_mode_status
+sii902x_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < SII902X_MIN_PIXEL_CLOCK_KHZ)
+ return MODE_CLOCK_LOW;
+
+ if (mode->clock > SII902X_MAX_PIXEL_CLOCK_KHZ)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static const struct drm_bridge_funcs sii902x_bridge_funcs = {
.attach = sii902x_bridge_attach,
.mode_set = sii902x_bridge_mode_set,
@@ -516,6 +529,7 @@ static const struct drm_bridge_funcs sii902x_bridge_funcs =
{
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = sii902x_bridge_atomic_get_input_bus_fmts,
.atomic_check = sii902x_bridge_atomic_check,
+ .mode_valid = sii902x_bridge_mode_valid,
};
static int sii902x_mute(struct sii902x *sii902x, bool mute)
--
Best regards
Sui
Re: [PATCH v6,15/24] media: mediatek: vcodec: Add one plane format
Le jeudi 16 mai 2024 à 20:20 +0800, Yunfei Dong a écrit :
> Adding capture formats to support V4L2_PIX_FMT_MS21. This format has
> one plane and only be used for secure video playback at current period.
Please, replace "one plane" with "single allocation". This should disambiguate
the message a little bit, since MS21 remains a semi-planar format with 2 planes.
Nicolas
>
> Signed-off-by: Yunfei Dong
> ---
> .../platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c| 4 +++-
> .../mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c | 9 -
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> index 9107707de6c4..192b01ff3ede 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> @@ -49,7 +49,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_dec_ctx
> *ctx, int format_inde
> num_frame_count++;
> }
>
> - if (num_frame_count == 1 || (!ctx->is_10bit_bitstream && fmt->fourcc ==
> V4L2_PIX_FMT_MM21))
> + if ((!ctx->is_10bit_bitstream && fmt->fourcc == V4L2_PIX_FMT_MM21) ||
> + (ctx->is_secure_playback && fmt->fourcc == V4L2_PIX_FMT_MS21) ||
> + num_frame_count == 1)
> return true;
>
> q_data = >q_data[MTK_Q_DATA_SRC];
> diff --git
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> index b903e39fee89..fbea00517565 100644
> ---
> a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> +++
> b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> @@ -229,7 +229,7 @@ static const struct mtk_stateless_control
> mtk_stateless_controls[] = {
>
> #define NUM_CTRLS ARRAY_SIZE(mtk_stateless_controls)
>
> -static struct mtk_video_fmt mtk_video_formats[9];
> +static struct mtk_video_fmt mtk_video_formats[10];
>
> static struct mtk_video_fmt default_out_format;
> static struct mtk_video_fmt default_cap_format;
> @@ -770,6 +770,11 @@ static void mtk_vcodec_add_formats(unsigned int fourcc,
> mtk_video_formats[count_formats].type = MTK_FMT_FRAME;
> mtk_video_formats[count_formats].num_planes = 2;
> break;
> + case V4L2_PIX_FMT_MS21:
> + mtk_video_formats[count_formats].fourcc = fourcc;
> + mtk_video_formats[count_formats].type = MTK_FMT_FRAME;
> + mtk_video_formats[count_formats].num_planes = 1;
> + break;
> default:
> mtk_v4l2_vdec_err(ctx, "Can not add unsupported format type");
> return;
> @@ -798,6 +803,8 @@ static void mtk_vcodec_get_supported_formats(struct
> mtk_vcodec_dec_ctx *ctx)
> cap_format_count++;
> }
> if (ctx->dev->dec_capability & MTK_VDEC_FORMAT_MM21) {
> + mtk_vcodec_add_formats(V4L2_PIX_FMT_MS21, ctx);
> + cap_format_count++;
> mtk_vcodec_add_formats(V4L2_PIX_FMT_MM21, ctx);
> cap_format_count++;
> }
Re: [PATCH v6,14/24] media: mediatek: vcodec: Add capture format to support one plane memory
Hi,
Le jeudi 23 mai 2024 à 18:36 +0800, Chen-Yu Tsai a écrit :
> On Thu, May 23, 2024 at 6:14 PM Andrzej Pietrasiewicz
> wrote:
> >
> > Hi,
> >
> > I'm having second thoughts, please see inline,
> >
> > W dniu 22.05.2024 o 14:26, Andrzej Pietrasiewicz pisze:
> > > Hi Yunfei,
> > >
> > > W dniu 16.05.2024 o 14:20, Yunfei Dong pisze:
> > > > Define one uncompressed capture format V4L2_PIX_FMT_MS21 in order to
> > > > support one plane memory. The buffer size is luma + chroma, luma is
> > > > stored at the start and chrome is stored at the end.
> > > >
> > > > Signed-off-by: Yunfei Dong
> > > > ---
> > > > Documentation/userspace-api/media/v4l/pixfmt-reserved.rst | 8
> > > > drivers/media/v4l2-core/v4l2-common.c | 2 ++
> > > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> > > > include/uapi/linux/videodev2.h| 1 +
> > > > 4 files changed, 12 insertions(+)
> > > >
> > > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
> > > > b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
> > > > index 886ba7b08d6b..6ec899649d50 100644
> > > > --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
> > > > +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst
> > > > @@ -295,6 +295,14 @@ please make a proposal on the linux-media mailing
> > > > list.
> > > > - Compressed format used by Nuvoton NPCM video driver. This
> > > > format is
> > > > defined in Remote Framebuffer Protocol (RFC 6143, chapter
> > > > 7.7.4 Hextile
> > > > Encoding).
> > > > +* .. _V4L2-PIX-FMT-MS21:
> > > > +
> > > > + - ``V4L2_PIX_FMT_MS21``
> > > > + - 'MS21'
> > > > + - This format has one plane, luma and chroma are stored in a
> > > > contiguous
> > >
> > > Maybe s/one/single ?
> > >
> > > > +memory. Luma pixel in 16x32 tiles at the start, chroma pixel
> > > > in 16x16
> > >
> > > maybe the word "pixel" is reduntant here? What else than pixels could
> > > tile sizes mean?
> > > Any padding between luma and chroma?
> > >
> > > > +tiles at the end. The image height must be aligned with 32 and
> > > > the image
> > > > +width must be aligned with 16.
> > >
> > > Maybe aligned to?
> > >
> > > > .. raw:: latex
> > > > \normalsize
> > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c
> > > > b/drivers/media/v4l2-core/v4l2-common.c
> > > > index 4165c815faef..5ae54cf48dc7 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-common.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-common.c
> > > > @@ -271,6 +271,8 @@ const struct v4l2_format_info *v4l2_format_info(u32
> > > > format)
> > > > .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
> > > > { .format = V4L2_PIX_FMT_MT2110R, .pixel_enc =
> > > > V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10,
> > > > 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> > > > .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
> > > > +{ .format = V4L2_PIX_FMT_MS21, pixel_enc = V4L2_PIXEL_ENC_YUV,
> > > > .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = {
> > > > 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2,
> > > > + .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
> > > > /* YUV planar formats */
> > > > { .format = V4L2_PIX_FMT_NV12,.pixel_enc =
> > > > V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2,
> > > > 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
> > > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > index 4c76d17b4629..3a68f2b9e7a4 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > @@ -1529,6 +1529,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> > > > *fmt)
> > > > case V4L2_PIX_FMT_MT2110T:descr = "Mediatek 10bit Tile
> > > > Mode"; break;
> > > > case V4L2_PIX_FMT_MT2110R:descr = "Mediatek 10bit Raster
> > > > Mode"; break;
> > > > case V4L2_PIX_FMT_HEXTILE:descr = "Hextile Compressed
> > > > Format"; break;
> > > > +case V4L2_PIX_FMT_MS21:descr = "MediaTek One Plane
> > > > Format"; break;
> > >
> > > s/One/Single ?
> > >
> >
> > On the other hand "single" would be [in this case incorrectly] associated
> > with
> > single-planar API, which would be totally confusing.
> >
> > Still, the reality you are trying to model is complex: you use
> > MPLANE, yet there's a single plane in case of secure playback.
>
> I don't think that's a problem though. The NV12 format (seen above in
> the diff context) has the same attributes: 1 contiguous memory plane
> containing two component planes.
>
> And it's perfectly fine for MPLANE drivers to support these formats,
> Hantro being one of them that decodes to
Re: [PATCH v4 0/2] Add mode_valid and atomic_check hooks for sii902x bridge
Hi, On 5/30/24 17:29, Jayesh Choudhary wrote: Move the mode_valid hook to drm_bridge_funcs structure to take care of the case when the encoder attaches the bridge chain with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag in which case, the connector is not initialized in the bridge's attach call and mode_valid is not called. Good catch, as modes being supported is actually a capability of the bridge itself. The move make the driver reflect the hardware more.
Re: MAINTAINERS: drm: Drop sam as panel reviewer
Hi, On 5/31/24 05:14, Sam Ravnborg wrote: Drop myself as reviewer of panel patches, to reflect the reality. We lost one kindness reviewer for drivers of panel, unhappy! Not sure if it is proper to give you a NAK here. :( Best regards, Sui Signed-off-by: Sam Ravnborg Cc: Neil Armstrong --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index ac285040578e..38978699bef5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7567,7 +7567,6 @@ F:include/drm/gpu_scheduler.h DRM PANEL DRIVERS M:Neil Armstrong R:Jessica Zhang -R: Sam Ravnborg L:dri-devel@lists.freedesktop.org S:Maintained T:git https://gitlab.freedesktop.org/drm/misc/kernel.git
Re: [RESEND PATCH] accel/habanalabs/gaudi2: Use kvfree() for memory allocated with kvcalloc()
On 31/05/2024 13:46, Thorsten Blum wrote: > Use kvfree() to fix the following Coccinelle/coccicheck warning reported > by kfree_mismatch.cocci: > > WARNING kvmalloc is used to allocate this memory at line 10398 > > Signed-off-by: Thorsten Blum Reviewed-by: Tomer Tayar > --- > drivers/accel/habanalabs/gaudi2/gaudi2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c > b/drivers/accel/habanalabs/gaudi2/gaudi2.c > index fa1c4feb9f89..8024047962ec 100644 > --- a/drivers/accel/habanalabs/gaudi2/gaudi2.c > +++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c > @@ -10489,7 +10489,7 @@ static int gaudi2_memset_device_memory(struct > hl_device *hdev, u64 addr, u64 siz > (u64 *)(lin_dma_pkts_arr), DEBUGFS_WRITE64); > WREG32(sob_addr, 0); > > - kfree(lin_dma_pkts_arr); > + kvfree(lin_dma_pkts_arr); > > return rc; > }
[PATCH 3/3] drm/amd/display: switch to guid_gen() to generate valid GUIDs
Instead of just smashing jiffies into a GUID, use guid_gen() to generate
RFC 4122 compliant GUIDs.
Signed-off-by: Jani Nikula
---
Side note, it baffles me why amdgpu has a copy of this instead of
plumbing it into drm mst code.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 65ebc01dc90f..a1bd847857b8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2403,9 +2403,9 @@ static int dm_late_init(void *handle)
static void resume_mst_branch_status(struct drm_dp_mst_topology_mgr *mgr)
{
+ u8 buf[UUID_SIZE];
+ guid_t guid;
int ret;
- u8 guid[16];
- u64 tmp64;
mutex_lock(>lock);
if (!mgr->mst_primary)
@@ -2426,26 +2426,27 @@ static void resume_mst_branch_status(struct
drm_dp_mst_topology_mgr *mgr)
}
/* Some hubs forget their guids after they resume */
- ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
- if (ret != 16) {
+ ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, buf, sizeof(buf));
+ if (ret != sizeof(buf)) {
drm_dbg_kms(mgr->dev, "dpcd read failed - undocked during
suspend?\n");
goto out_fail;
}
- if (memchr_inv(guid, 0, 16) == NULL) {
- tmp64 = get_jiffies_64();
- memcpy([0], , sizeof(u64));
- memcpy([8], , sizeof(u64));
+ import_guid(, buf);
- ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, guid, 16);
+ if (guid_is_null()) {
+ guid_gen();
+ export_guid(buf, );
- if (ret != 16) {
+ ret = drm_dp_dpcd_write(mgr->aux, DP_GUID, buf, sizeof(buf));
+
+ if (ret != sizeof(buf)) {
drm_dbg_kms(mgr->dev, "check mstb guid failed -
undocked during suspend?\n");
goto out_fail;
}
}
- import_guid(>mst_primary->guid, guid);
+ guid_copy(>mst_primary->guid, );
out_fail:
mutex_unlock(>lock);
--
2.39.2
[PATCH 1/3] drm/mst: switch to guid_t type for GUID
The kernel has a guid_t type for GUIDs. Switch to using it, but avoid
any functional changes here.
Signed-off-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 67 +++
include/drm/display/drm_dp_mst_helper.h | 12 ++--
3 files changed, 45 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 516eb3968e26..65ebc01dc90f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2445,7 +2445,7 @@ static void resume_mst_branch_status(struct
drm_dp_mst_topology_mgr *mgr)
}
}
- memcpy(mgr->mst_primary->guid, guid, 16);
+ import_guid(>mst_primary->guid, guid);
out_fail:
mutex_unlock(>lock);
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 7f8e1cfbe19d..9b1f35b1a2da 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -89,7 +89,7 @@ static int drm_dp_send_enum_path_resources(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_branch *mstb,
struct drm_dp_mst_port *port);
static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
-u8 *guid);
+guid_t *guid);
static int drm_dp_mst_register_i2c_bus(struct drm_dp_mst_port *port);
static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port);
@@ -801,7 +801,7 @@ static bool drm_dp_sideband_parse_link_address(const struct
drm_dp_mst_topology_
int idx = 1;
int i;
- memcpy(repmsg->u.link_addr.guid, >msg[idx], 16);
+ import_guid(>u.link_addr.guid, >msg[idx]);
idx += 16;
repmsg->u.link_addr.nports = raw->msg[idx] & 0xf;
idx++;
@@ -829,7 +829,7 @@ static bool drm_dp_sideband_parse_link_address(const struct
drm_dp_mst_topology_
idx++;
if (idx > raw->curlen)
goto fail_len;
- memcpy(repmsg->u.link_addr.ports[i].peer_guid,
>msg[idx], 16);
+ import_guid(>u.link_addr.ports[i].peer_guid,
>msg[idx]);
idx += 16;
if (idx > raw->curlen)
goto fail_len;
@@ -1029,7 +1029,7 @@ static bool drm_dp_sideband_parse_reply(const struct
drm_dp_mst_topology_mgr *mg
msg->req_type = (raw->msg[0] & 0x7f);
if (msg->reply_type == DP_SIDEBAND_REPLY_NAK) {
- memcpy(msg->u.nak.guid, >msg[1], 16);
+ import_guid(>u.nak.guid, >msg[1]);
msg->u.nak.reason = raw->msg[17];
msg->u.nak.nak_data = raw->msg[18];
return false;
@@ -1078,7 +1078,7 @@ drm_dp_sideband_parse_connection_status_notify(const
struct drm_dp_mst_topology_
if (idx > raw->curlen)
goto fail_len;
- memcpy(msg->u.conn_stat.guid, >msg[idx], 16);
+ import_guid(>u.conn_stat.guid, >msg[idx]);
idx += 16;
if (idx > raw->curlen)
goto fail_len;
@@ -1107,7 +1107,7 @@ static bool
drm_dp_sideband_parse_resource_status_notify(const struct drm_dp_mst
if (idx > raw->curlen)
goto fail_len;
- memcpy(msg->u.resource_stat.guid, >msg[idx], 16);
+ import_guid(>u.resource_stat.guid, >msg[idx]);
idx += 16;
if (idx > raw->curlen)
goto fail_len;
@@ -2174,20 +2174,24 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
offset, size, buffer);
}
-static int drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, u8 *guid)
+static int drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, guid_t *guid)
{
int ret = 0;
- memcpy(mstb->guid, guid, 16);
+ guid_copy(>guid, guid);
+
+ if (!drm_dp_validate_guid(mstb->mgr, >guid)) {
+ u8 buf[UUID_SIZE];
+
+ export_guid(buf, >guid);
- if (!drm_dp_validate_guid(mstb->mgr, mstb->guid)) {
if (mstb->port_parent) {
ret = drm_dp_send_dpcd_write(mstb->mgr,
mstb->port_parent,
-DP_GUID, 16, mstb->guid);
+DP_GUID, sizeof(buf), buf);
} else {
ret = drm_dp_dpcd_write(mstb->mgr->aux,
- DP_GUID, mstb->guid, 16);
+ DP_GUID, buf, sizeof(buf));
}
}
@@ -2570,9 +2574,9 @@ static struct drm_dp_mst_branch
[PATCH 2/3] drm/mst: switch to guid_gen() to generate valid GUIDs
Instead of just smashing jiffies into a GUID, use guid_gen() to generate
RFC 4122 compliant GUIDs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 9b1f35b1a2da..1cb071daab8f 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -2698,18 +2698,10 @@ static void drm_dp_mst_link_probe_work(struct
work_struct *work)
static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
guid_t *guid)
{
- u64 salt;
- u8 buf[UUID_SIZE];
-
if (!guid_is_null(guid))
return true;
- salt = get_jiffies_64();
-
- memcpy([0], , sizeof(u64));
- memcpy([8], , sizeof(u64));
-
- import_guid(guid, buf);
+ guid_gen(guid);
return false;
}
--
2.39.2
[PATCH 0/3] drm/mst & drm/amd/display: switch to using guid_t
We have a guid_t type for GUIDs, switch to using it instead of hand rolling buffers. Convert to guid_gen() in separate patches to pinpoint the functional changes. BR, Jani. Jani Nikula (3): drm/mst: switch to guid_t type for GUID drm/mst: switch to guid_gen() to generate valid GUIDs drm/amd/display: switch to guid_gen() to generate valid GUIDs .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 67 ++- include/drm/display/drm_dp_mst_helper.h | 12 ++-- 3 files changed, 52 insertions(+), 50 deletions(-) -- 2.39.2
Re: [PATCH 4/6] drm/imagination: Add compatible string entry for Series6XT
On Thu, 2024-05-30 at 16:35 +0800, Chen-Yu Tsai wrote:
> The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
> of the Series6XT, another variation of the Rogue family of GPUs.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/imagination/pvr_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/imagination/pvr_drv.c
> b/drivers/gpu/drm/imagination/pvr_drv.c
> index 5c3b2d58d766..3d1a933c8303 100644
> --- a/drivers/gpu/drm/imagination/pvr_drv.c
> +++ b/drivers/gpu/drm/imagination/pvr_drv.c
> @@ -1475,6 +1475,7 @@ pvr_remove(struct platform_device *plat_dev)
>
> static const struct of_device_id dt_match[] = {
> { .compatible = "img,img-axe", .data = NULL },
> + { .compatible = "img,powervr-6xt", .data = NULL },
I assume that by adding this to the list of supported devices we're essentially
freezing the existing uapi. This concerns me, as we've not yet started running
Vulkan conformance on any Series6XT GPUs and there's a chance we may need to
make some tweaks.
I'm not really sure what the accepted approach is to hardware enablement /
experimental support. I'm not sure if it's sufficient to hide support behind a
Kconfig option and/or module parameter or whether we just have to hold this
patch back for the time being.
Thanks
Frank
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
Re: [PATCH 2/6] clk: mediatek: Add mt8173-mfgtop driver
On Thu, 2024-05-30 at 18:16 +0800, Chen-Yu Tsai wrote:
> On Thu, May 30, 2024 at 5:59 PM AngeloGioacchino Del Regno
> wrote:
> > Il 30/05/24 10:35, Chen-Yu Tsai ha scritto:
> > > The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
> > > in the datasheet, that contains clock gates, some power sequence signal
> > > delays, and other unknown registers that get toggled when the GPU is
> > > powered on.
> > >
> > > The clock gates are exposed as clocks provided by a clock controller,
> > > while the power sequencing bits are exposed as one singular power domain.
> > >
> > > Signed-off-by: Chen-Yu Tsai
> > > ---
> > > drivers/clk/mediatek/Kconfig | 9 +
> > > drivers/clk/mediatek/Makefile| 1 +
> > > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 240 +++
> > > 3 files changed, 250 insertions(+)
> > > create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
> > >
> > > diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> > > index 70a005e7e1b1..9e279c739f1c 100644
> > > --- a/drivers/clk/mediatek/Kconfig
> > > +++ b/drivers/clk/mediatek/Kconfig
> > > @@ -500,6 +500,15 @@ config COMMON_CLK_MT8173_IMGSYS
> > > help
> > > This driver supports MediaTek MT8173 imgsys clocks.
> > >
> > > +config COMMON_CLK_MT8173_MFGTOP
> > > + tristate "Clock and power driver for MediaTek MT8173 mfgtop"
> > > + depends on COMMON_CLK_MT8173
> > > + default COMMON_CLK_MT8173
> > > + select PM_GENERIC_DOMAINS
> > > + select PM_GENERIC_DOMAINS_OF
> > > + help
> > > + This driver supports MediaTek MT8173 mfgtop clocks and power
> > > domain.
> > > +
> > > config COMMON_CLK_MT8173_MMSYS
> > > tristate "Clock driver for MediaTek MT8173 mmsys"
> > > depends on COMMON_CLK_MT8173
> > > diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> > > index eeccfa039896..fdd3a76e12a1 100644
> > > --- a/drivers/clk/mediatek/Makefile
> > > +++ b/drivers/clk/mediatek/Makefile
> > > @@ -77,6 +77,7 @@ obj-$(CONFIG_COMMON_CLK_MT8167_VDECSYS) +=
> > > clk-mt8167-vdec.o
> > > obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173-apmixedsys.o
> > > clk-mt8173-infracfg.o \
> > > clk-mt8173-pericfg.o
> > > clk-mt8173-topckgen.o
> > > obj-$(CONFIG_COMMON_CLK_MT8173_IMGSYS) += clk-mt8173-img.o
> > > +obj-$(CONFIG_COMMON_CLK_MT8173_MFGTOP) += clk-mt8173-mfgtop.o
> > > obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
> > > obj-$(CONFIG_COMMON_CLK_MT8173_VDECSYS) += clk-mt8173-vdecsys.o
> > > obj-$(CONFIG_COMMON_CLK_MT8173_VENCSYS) += clk-mt8173-vencsys.o
> > > diff --git a/drivers/clk/mediatek/clk-mt8173-mfgtop.c
> > > b/drivers/clk/mediatek/clk-mt8173-mfgtop.c
> > > new file mode 100644
> > > index ..85fa7a7453ed
> > > --- /dev/null
> > > +++ b/drivers/clk/mediatek/clk-mt8173-mfgtop.c
> > > @@ -0,0 +1,240 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (c) 2024 Google LLC
> > > + * Author: Chen-Yu Tsai
> > > + *
> > > + * Based on driver in downstream ChromeOS v5.15 kernel.
> > > + *
> > > + * Copyright (c) 2014 MediaTek Inc.
> > > + * Author: Chiawen Lee
> > > + */
> > > +
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "clk-gate.h"
> > > +#include "clk-mtk.h"
> > > +
> > > +static const struct mtk_gate_regs mfg_cg_regs = {
> > > + .sta_ofs = 0x,
> > > + .clr_ofs = 0x0008,
> > > + .set_ofs = 0x0004,
> > > +};
> > > +
> > > +#define GATE_MFG(_id, _name, _parent, _shift, _flags)\
> > > + GATE_MTK_FLAGS(_id, _name, _parent, _cg_regs, _shift,
> > > _clk_gate_ops_setclr, _flags)
> >
> > Extra tabulation: please fix
>
> One tab instead of two? OK.
>
> > > +
> > > +/* TODO: The block actually has dividers for the core and mem clocks. */
> > > +static const struct mtk_gate mfg_clks[] = {
> > > + GATE_MFG(CLK_MFG_AXI, "mfg_axi", "axi_mfg_in_sel", 0,
> > > CLK_SET_RATE_PARENT),
> > > + GATE_MFG(CLK_MFG_MEM, "mfg_mem", "mem_mfg_in_sel", 1,
> > > CLK_SET_RATE_PARENT),
> > > + GATE_MFG(CLK_MFG_G3D, "mfg_g3d", "mfg_sel", 2, CLK_SET_RATE_PARENT),
> > > + GATE_MFG(CLK_MFG_26M, "mfg_26m", "clk26m", 3, 0),
> > > +};
> > > +
> > > +static const struct mtk_clk_desc mfg_desc = {
> > > + .clks = mfg_clks,
> > > + .num_clks = ARRAY_SIZE(mfg_clks),
> > > +};
> > > +
> > > +struct mt8173_mfgtop_data {
> > > + struct clk_hw_onecell_data *clk_data;
> > > + struct regmap *regmap;
> > > + struct generic_pm_domain genpd;
> > > + struct of_phandle_args parent_pd, child_pd;
> > > + struct clk *clk_26m;
> > > +};
> > > +
> > > +static const struct of_device_id of_match_clk_mt8173_mfgtop[] = {
> > > + { .compatible = "mediatek,mt8173-mfgtop", .data = _desc },
> > > + { /*
Re: [PATCH 0/6] powervr: MT8173 GPU support
Hi ChenYu, On Fri, 2024-05-31 at 12:00 +0800, Chen-Yu Tsai wrote: > On Thu, May 30, 2024 at 4:35 PM Chen-Yu Tsai wrote: > > Hi everyone, > > > > This series enables the PowerVR GPU found in the MT8173 SoC, found in > > some Chromebooks. Thank you for the patches, I'm really happy to see these! > > > > This version is different from the initial powervr driver submission [1] > > in that it splits out the GPU glue layer support out of the powervr > > driver and into a separate clock and power domain driver. The glue code > > is otherwise the same, and also the same as found in the ChromeOS > > kernels, with some extra comments and macro names added where possible. > > > > Patch 1 adds a binding for the glue layer, called mfgtop. The glue layer > > contains clock and power controls for the GPU. > > > > Patch 2 adds a driver for the glue layer. > > > > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the PowerVR > > binding. > > > > Patch 4 adds an entry for the PowerVR 6XT series GPU to the driver. > > > > Patch 5 corrects the clock for the GPU (called MFG) power domain. > > > > Patch 6 adds device nodes for the GPU and glue layer to the MT8173 dtsi > > file. > > > > Patch 2 and 6 depend on patch 1 to build. I suppose some common > > immutable tree would be needed from the MediaTek maintainers. > > > > The kernel driver successfully probes the hardware and loads the > > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination Technologies [2]. > > Userspace was tested with Mesa 24.0.8 from Debian Trixie rebuilt with > > the powervr vulkan driver enabled. `vulkaninfo` gives some information > > about the GPU (attached at the end), but running the `triangle` example > > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as recommended [4] > > failed with: > > > > Can't find a display and a display mode! > > > > Same program worked correctly on a BeaglePlay and displayed a color > > gradient triangle. Not sure what went wrong here. > > Frank mentioned over IRC that giving `triangle` a screen resolution would > make it work, and it did! Thanks Frank! No problem :) I've not dug into the display mode issue, but I'm wondering if it happens because there isn't a mode flagged as the preferred mode. > > OTOH I'm getting some extra warnings not seen on the BeaglePlay: > > MESA: error: No hard coded passthrough rta vertex shader. > Returning empty shader. > MESA: warning: ../src/imagination/vulkan/pvr_job_context.c:71: > FINISHME: Missing reset support for brn51764 > MESA: warning: ../src/imagination/vulkan/pvr_job_context.c:74: > FINISHME: Missing reset support for brn58839 > MESA: warning: ../src/imagination/vulkan/pvr_border.c:104: > FINISHME: Devices without tpu_border_colour_enhanced require entries > for compressed formats to be stored in the table pre-compressed. > > I also get a constant stream of kernel error messages, all the same: > > powervr 1300.gpu: [drm] Received unknown FWCCB command 2abc0069 > > And the first few frames seem to flicker. (Though that could also be the > display driver that's at fault.) The unknown commands are related to the GPU locking up, presumably because bad jobs are being submitted, likely due to missing bits of support for the Series6XT GPUs in the Vulkan driver / compiler. The unknown commands are the firmware notifying the host that the GPU has been reset. The GPU resets would explain the flickering you're seeing. Thanks Frank > > > For reference, on the BeaglePlay I see: > > MESA: error: No hard coded idfwdf program. Returning empty program. > MESA: error: No hard coded passthrough vertex shader. Returning > empty shader. > MESA: warning: > ../src/imagination/vulkan/pvr_descriptor_set.c:1073: FINISHME: Entry > tracker for allocations? > > > Regards > ChenYu > > > > Anyway, please have a look and test. > > > > > > Thanks > > ChenYu > > > > [1] > > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.wal...@imgtec.com/ > > [2] https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr > > [3] https://github.com/SaschaWillems/Vulkan > > [4] > > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f...@imgtec.com/ > > > > Chen-Yu Tsai (6): > > dt-bindings: clock: mediatek: Add mt8173 mfgtop > > clk: mediatek: Add mt8173-mfgtop driver > > dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU > > drm/imagination: Add compatible string entry for Series6XT > > arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock > > arm64: dts: mediatek: mt8173: Add GPU device nodes > > > > .../clock/mediatek,mt8173-mfgtop.yaml | 71 ++ > > .../bindings/gpu/img,powervr-rogue.yaml | 24 +- > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 26 +- > > drivers/clk/mediatek/Kconfig | 9 + > > drivers/clk/mediatek/Makefile | 1 + > > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 240
Re: [PATCH v10 07/11] Documentation: core-api: Add math.h macros and functions
Hi Randy, Thanks for the review. On 31/05/24 04:14, Randy Dunlap wrote: > > > On 5/30/24 10:17 AM, Devarsh Thakkar wrote: >> Add documentation for rounding, scaling, absolute value and difference, >> 32-bit division related macros and functions exported by math.h header >> file. >> >> Signed-off-by: Devarsh Thakkar >> --- >> V1->V9 (No change) >> V10: Patch introduced >> --- >> Documentation/core-api/kernel-api.rst | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/core-api/kernel-api.rst >> b/Documentation/core-api/kernel-api.rst >> index ae92a2571388..fb467783d491 100644 >> --- a/Documentation/core-api/kernel-api.rst >> +++ b/Documentation/core-api/kernel-api.rst >> @@ -185,6 +185,12 @@ Division Functions >> .. kernel-doc:: lib/math/gcd.c >> :export: >> >> +Rounding, absolute value, scaling and 32bit division functions > > 32-bit > please. > Good catch. Also I see some division functions supporting non-32bit functions too, so I would make it as below : Rounding, absolute value, division and 32-bit scaling functions --- Regards Devarsh
[RESEND PATCH] accel/habanalabs/gaudi2: Use kvfree() for memory allocated with kvcalloc()
Use kvfree() to fix the following Coccinelle/coccicheck warning reported by kfree_mismatch.cocci: WARNING kvmalloc is used to allocate this memory at line 10398 Signed-off-by: Thorsten Blum --- drivers/accel/habanalabs/gaudi2/gaudi2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c b/drivers/accel/habanalabs/gaudi2/gaudi2.c index fa1c4feb9f89..8024047962ec 100644 --- a/drivers/accel/habanalabs/gaudi2/gaudi2.c +++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c @@ -10489,7 +10489,7 @@ static int gaudi2_memset_device_memory(struct hl_device *hdev, u64 addr, u64 siz (u64 *)(lin_dma_pkts_arr), DEBUGFS_WRITE64); WREG32(sob_addr, 0); - kfree(lin_dma_pkts_arr); + kvfree(lin_dma_pkts_arr); return rc; } -- 2.45.1
Re: [PATCH 3/3] drm/panic: Add a kmsg dump screen
Jocelyn Falempe writes: > On 31/05/2024 11:32, Javier Martinez Canillas wrote: >> Jocelyn Falempe writes: >> >>> Add a kmsg dump option, which will display the last lines of kmsg, >>> and should be similar to fbcon. >>> Add a Kconfig choice for the panic screen, so that the user can >>> choose between this new kmsg dump, or the userfriendly option. >>> >>> Signed-off-by: Jocelyn Falempe >>> --- >>> drivers/gpu/drm/Kconfig | 21 + >>> drivers/gpu/drm/drm_panic.c | 151 +++- >>> 2 files changed, 136 insertions(+), 36 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >>> index 9703429de6b9..78d401b55102 100644 >>> --- a/drivers/gpu/drm/Kconfig >>> +++ b/drivers/gpu/drm/Kconfig >>> @@ -137,6 +137,27 @@ config DRM_PANIC_DEBUG >>> This is unsafe and should not be enabled on a production build. >>> If in doubt, say "N". >>> >>> +choice >>> + prompt "Panic screen formater" >>> + default DRM_PANIC_SCREEN_USERFRIENDLY >>> + depends on DRM_PANIC >>> + help >>> + This option enable to choose what will be displayed when a kernel >>> + panic occurs. >>> + >>> + config DRM_PANIC_SCREEN_USERFRIENDLY >>> + bool "Default user friendly message" >>> + help >>> + Only a short message telling the user to reboot the system. >>> + >>> + config DRM_PANIC_SCREEN_KMSG >>> + bool "Display the last lines of kmsg" >>> + help >>> + Display kmsg last lines on panic. >>> + Enable if you are a kernel developer, and want to debug a >>> + kernel panic. >>> +endchoice >> >> Why having it as a compile time option and not a runtime option ? AFAICT >> this could be a drm.panic_format= kernel command line parameter instead. > > Yes, I didn't think about it. That would allow to get more debug > information from a user without rebuilding the kernel. > > I'll prepare a v2 with that. > Awesome, thanks! > I prefer to use a drm.panic_screen=, as "format" might be confusing with > the color format ? > Indeed. I named _format because your prompt had "formater" in it, but agree that _screen makes more sense and is easier to understand. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
